Bug#1071028: viewnior: FTBFS with exiv2 0.28
Source: viewnior
Version: 1.8-3
Severity: important
Tags: patch ftbfs
Control: forwarded -1 https://github.com/hellosiyan/Viewnior/pull/134
Hi,
viewnior fails to build with the new stable series of the Exiv2 library,
i.e. 0.28.x; that version is available in experimental as of this
writing.
There are two upstream PRs to address this problem, i.e. PR 130 [1] and
PR 134, and sadly they have been sitting there for some months now
(viewnior does not seem an actively developed project). I chose PR 134,
as I find it as cleaner approach, I extracted the patch/commit from it,
and verified that it builds fine with both Exiv2 0.27 and Exiv2 0.28;
you can find it attached to this bug. Would you review this patch, and
upload it so that viewnior rebuilds cleanly once a newer Exiv2 is
uploaded to unstable?
In addition to the actual fix, I attached an update of the libexiv2-dev
build dependency, which is the result of the backported patch.
[1] https://github.com/hellosiyan/Viewnior/pull/130
[2] https://github.com/hellosiyan/Viewnior/pull/134
Thanks,
--
Pino
Author: Robert-André Mauchin
Description: Fix build with >=exiv2-0.28.0, raise minimum to 0.27.0
- enables use of EXIV2_TEST_VERSION macro
- add compatibility for exiv2-0.28.0
Forwarded: https://github.com/hellosiyan/Viewnior/pull/134
Last-Update: 2023-11-11
diff --git a/meson.build b/meson.build
index 8f91fb5..9ef9f09 100644
--- a/meson.build
+++ b/meson.build
@@ -28,7 +28,7 @@ viewnior_deps = [
dependency('gio-2.0', version: glib_ver),
dependency('shared-mime-info', version: '>= 0.20'),
dependency('gdk-pixbuf-2.0', version: '>= 0.21'),
- dependency('exiv2', version: '>= 0.21'),
+ dependency('exiv2', version: '>= 0.27'),
]
#
diff --git a/src/uni-exiv2.cpp b/src/uni-exiv2.cpp
index 0d14b9f..d03edd7 100644
--- a/src/uni-exiv2.cpp
+++ b/src/uni-exiv2.cpp
@@ -22,12 +22,21 @@
#include
#include
+#include
#include "uni-exiv2.hpp"
+#if EXIV2_TEST_VERSION(0,28,0)
+typedef Exiv2::Error Exiv2Error;
+typedef Exiv2::Image::UniquePtr ImagePtr;
+#else
+typedef Exiv2::AnyError Exiv2Error;
+typedef Exiv2::Image::AutoPtr ImagePtr;
+#endif
+
#define ARRAY_SIZE(array) (sizeof array/sizeof(array[0]))
-static Exiv2::Image::AutoPtr cached_image;
+static ImagePtr cached_image;
extern "C"
void
@@ -35,7 +44,7 @@ uni_read_exiv2_map(const char *uri, void (*callback)(const
char*, const char*, v
{
Exiv2::LogMsg::setLevel(Exiv2::LogMsg::mute);
try {
-Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(uri);
+ImagePtr image = Exiv2::ImageFactory::open(uri);
if ( image.get() == 0 ) {
return;
}
@@ -80,7 +89,7 @@ uni_read_exiv2_map(const char *uri, void (*callback)(const
char*, const char*, v
}
}
}
-} catch (Exiv2::AnyError& e) {
+} catch (Exiv2Error& e) {
std::cerr << "Exiv2: '" << e << "'\n";
}
}
@@ -103,7 +112,7 @@ uni_read_exiv2_to_cache(const char *uri)
}
cached_image->readMetadata();
-} catch (Exiv2::AnyError& e) {
+} catch (Exiv2Error& e) {
std::cerr << "Exiv2: '" << e << "'\n";
}
@@ -121,7 +130,7 @@ uni_write_exiv2_from_cache(const char *uri)
}
try {
-Exiv2::Image::AutoPtr image = Exiv2::ImageFactory::open(uri);
+ImagePtr image = Exiv2::ImageFactory::open(uri);
if ( image.get() == 0 ) {
return 2;
}
@@ -133,7 +142,7 @@ uni_write_exiv2_from_cache(const char *uri)
cached_image.reset(NULL);
return 0;
-} catch (Exiv2::AnyError& e) {
+} catch (Exiv2Error& e) {
std::cerr << "Exiv2: '" << e << "'\n";
}
--
2.43.0
--- a/debian/control
+++ b/debian/control
@@ -6,7 +6,7 @@ Build-Depends:
debhelper-compat (= 13),
meson,
intltool (>= 0.35.0),
- libexiv2-dev,
+ libexiv2-dev (>= 0.27.0),
libgtk-3-dev
Standards-Version: 4.6.2
Homepage: https://siyanpanayotov.com/project/viewnior/
Bug#1071027: hdrmerge: FTBFS with exiv2 0.28
Source: hdrmerge
Version: 0.5+git20200117-3.1
Severity: important
Tags: patch ftbfs
X-Debbugs-Cc: gur...@phys.ethz.ch
Control: forwarded -1 https://github.com/jcelaya/hdrmerge/pull/222
Hi,
hdrmerge fails to build with the new stable series of the Exiv2 library,
i.e. 0.28.x; that version is available in experimental as of this
writing.
There is a proposed patch upstream to fix this [1], and sadly it has
been sitting there for some months now (hdrmerge does not seem an
actively developed project). I extracted the patch/commit from that
upstream PR, and verified that it builds fine with both Exiv2 0.27 and
Exiv2 0.28; you can find it attached to this bug. Would you review this
patch, and upload it so that hdrmerge rebuilds cleanly once a newer
Exiv2 is uploaded to unstable?
[1] https://github.com/jcelaya/hdrmerge/pull/222
Thanks,
--
Pino
Author: Lukáš Jirkovský
Description: Adapt to Exiv2 0.28.0 API change.
Last-Update: 2023-08-03
Forwarded: https://github.com/jcelaya/hdrmerge/pull/222
diff --git a/src/ExifTransfer.cpp b/src/ExifTransfer.cpp
index bc8f4f9..0598172 100644
--- a/src/ExifTransfer.cpp
+++ b/src/ExifTransfer.cpp
@@ -41,7 +41,11 @@ private:
QString srcFile, dstFile;
const uint8_t * data;
size_t dataSize;
+#if EXIV2_TEST_VERSION(0,28,0)
+Exiv2::Image::UniquePtr src, dst;
+#else
Exiv2::Image::AutoPtr src, dst;
+#endif
void copyXMP();
void copyIPTC();
@@ -58,7 +62,11 @@ void hdrmerge::Exif::transfer(const QString & srcFile, const
QString & dstFile,
void ExifTransfer::copyMetadata() {
try {
+#if EXIV2_TEST_VERSION(0,28,0)
+dst = Exiv2::ImageFactory::open(BasicIo::UniquePtr(new MemIo(data,
dataSize)));
+#else
dst = Exiv2::ImageFactory::open(BasicIo::AutoPtr(new MemIo(data,
dataSize)));
+#endif
dst->readMetadata();
} catch (Exiv2::Error & e) {
std::cerr << "Exiv2 error: " << e.what() << std::endl;
diff --git a/src/RawParameters.cpp b/src/RawParameters.cpp
index 40b77de..e6a38eb 100644
--- a/src/RawParameters.cpp
+++ b/src/RawParameters.cpp
@@ -49,7 +49,11 @@ void RawParameters::loadCamXyzFromDng() {
cc[j][i] = i == j ? 1.0 : 0.0;
}
}
+#if EXIV2_TEST_VERSION(0,28,0)
+Exiv2::Image::UniquePtr src =
Exiv2::ImageFactory::open(fileName.toLocal8Bit().constData());
+#else
Exiv2::Image::AutoPtr src =
Exiv2::ImageFactory::open(fileName.toLocal8Bit().constData());
+#endif
src->readMetadata();
const Exiv2::ExifData & srcExif = src->exifData();
--
2.43.0
Bug#1064639: phototonic: FTBFS with exiv2 0.28
Source: phototonic Followup-For: Bug #1064639 Hi Laszlo, now that the time_t transition is over, would you please take a look at this patch for phototonic? I'm starting to prepare an Exiv2 0.28+ transition, and fixing this will drop one roadblock. Thanks in advance! -- Pino
Bug#1070806: RM: kseexpr/experimental -- ROM; 64bit time_t transition not needed
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: ksee...@packages.debian.org Control: affects -1 + src:kseexpr User: ftp.debian@packages.debian.org Usertags: remove Hi, please remove kseexpr from experimental: the 64bit time_t transition for it is not needed, as the only time_t reference is an unused typedef in a public header. Thanks, -- Pino
Bug#1070703: transition: libunibreak
Package: release.debian.org Severity: normal X-Debbugs-Cc: libunibr...@packages.debian.org Control: affects -1 + src:libunibreak User: release.debian@packages.debian.org Usertags: transition Hi, I'd like to request a transition slot for the update of the libunibreak library 5.1 to 6.1. Each new major version bumps the SOVERSION, and in this case there are only few new symbols. There are few users of libunibreak in Debian: - fbreader - krita - libass I verified that all of them build fine using the new version of libunibreak. Ben file: title = "libunibreak"; is_affected = .depends ~ "libunibreak5" | .depends ~ "libunibreak6"; is_good = .depends ~ "libunibreak6"; is_bad = .depends ~ "libunibreak5"; Thanks, -- Pino
Bug#1064639: phototonic: FTBFS with exiv2 0.28
Source: phototonic
Version: 2.1-3
Severity: important
Tags: upstream patch ftbfs fixed-upstream
Hi,
phototonic fails to build with the new stable series of the Exiv2
library, i.e. 0.28.x; that version is available in experimental as of
this writing.
The compatibility was fixed upstream with the following two commits:
-
https://github.com/oferkv/phototonic/commit/7de1014fd5e28cd1578847aa4847e463696938d9
-
https://github.com/oferkv/phototonic/commit/2d1ab87c5f8a840a3db5c9f478a7d20dfca1ec1f
They do not apply cleanly, as there were lots of changes upstream since
the last release; hence, I applied the changes manually into a single
patch, which is attached, and which maintains the compatibility with
Exiv2 0.27.x. Would you please review this patch, and upload it so that
phototonic rebuilds cleanly once a newer Exiv2 is uploaded to unstable?
Side note: the upstream project was switched to read-only few months
ago, with a note in its README:
"This project is unmaintained. See Geeqie for an alternative."
Thanks,
--
Pino
Author: Andreas Sturmlechner
Author: Pino Toscano
Description: Fix build with exiv2-0.28
Modelled after the upstream commits:
-
https://github.com/oferkv/phototonic/commit/7de1014fd5e28cd1578847aa4847e463696938d9
-
https://github.com/oferkv/phototonic/commit/2d1ab87c5f8a840a3db5c9f478a7d20dfca1ec1f
Origin: backport,
https://github.com/oferkv/phototonic/commit/7de1014fd5e28cd1578847aa4847e463696938d9,
https://github.com/oferkv/phototonic/commit/2d1ab87c5f8a840a3db5c9f478a7d20dfca1ec1f
Last-Update: 2024-02-25
--- a/ImageViewer.cpp
+++ b/ImageViewer.cpp
@@ -945,7 +945,11 @@ void ImageViewer::keyMoveEvent(int direc
}
void ImageViewer::saveImage() {
+#if EXIV2_TEST_VERSION(0,28,0)
+Exiv2::Image::UniquePtr image;
+#else
Exiv2::Image::AutoPtr image;
+#endif
bool exifError = false;
if (newImage) {
@@ -985,8 +989,13 @@ void ImageViewer::saveImage() {
}
void ImageViewer::saveImageAs() {
+#if EXIV2_TEST_VERSION(0,28,0)
+Exiv2::Image::UniquePtr exifImage;
+Exiv2::Image::UniquePtr newExifImage;
+#else
Exiv2::Image::AutoPtr exifImage;
Exiv2::Image::AutoPtr newExifImage;
+#endif
bool exifError = false;
setCursorHiding(false);
--- a/MetadataCache.cpp
+++ b/MetadataCache.cpp
@@ -64,7 +64,11 @@ void MetadataCache::clear() {
}
bool MetadataCache::loadImageMetadata(const QString ) {
+#if EXIV2_TEST_VERSION(0,28,0)
+Exiv2::Image::UniquePtr exifImage;
+#else
Exiv2::Image::AutoPtr exifImage;
+#endif
QSet tags;
long orientation = 0;
@@ -78,7 +82,11 @@ bool MetadataCache::loadImageMetadata(co
try {
Exiv2::ExifData = exifImage->exifData();
if (!exifData.empty()) {
+#if EXIV2_TEST_VERSION(0,28,0)
+orientation =
exifData["Exif.Image.Orientation"].value().toUint32();
+#else
orientation = exifData["Exif.Image.Orientation"].value().toLong();
+#endif
}
} catch (Exiv2::Error ) {
qWarning() << "Failed to read Exif metadata";
--- a/Phototonic.cpp
+++ b/Phototonic.cpp
@@ -3151,7 +3151,11 @@ void Phototonic::removeMetadata() {
if (ret == MessageBox::Yes) {
for (int file = 0; file < fileList.size(); ++file) {
+#if EXIV2_TEST_VERSION(0,28,0)
+Exiv2::Image::UniquePtr image;
+#else
Exiv2::Image::AutoPtr image;
+#endif
try {
image =
Exiv2::ImageFactory::open(fileList[file].toStdString());
image->clearMetadata();
--- a/Tags.cpp
+++ b/Tags.cpp
@@ -136,7 +136,11 @@ void ImageTags::addTag(QString tagName,
bool ImageTags::writeTagsToImage(QString , QSet
) {
QSet imageTags;
+#if EXIV2_TEST_VERSION(0,28,0)
+Exiv2::Image::UniquePtr exifImage;
+#else
Exiv2::Image::AutoPtr exifImage;
+#endif
try {
exifImage = Exiv2::ImageFactory::open(imageFileName.toStdString());
@@ -160,7 +164,11 @@ bool ImageTags::writeTagsToImage(QString
QSetIterator newTagsIt(newTags);
while (newTagsIt.hasNext()) {
QString tag = newTagsIt.next();
+#if EXIV2_TEST_VERSION(0,28,0)
+Exiv2::Value::UniquePtr value =
Exiv2::Value::create(Exiv2::string);
+#else
Exiv2::Value::AutoPtr value = Exiv2::Value::create(Exiv2::string);
+#endif
value->read(tag.toStdString());
Exiv2::IptcKey key("Iptc.Application2.Keywords");
newIptcData.add(key, value.get());
--- a/ThumbsViewer.cpp
+++ b/ThumbsViewer.cpp
@@ -210,7 +210,11 @@ void ThumbsViewer::updateImageInfoViewer
infoView->addEntry(key, val);
}
+#if EXIV2_TEST_VERSION(0,28,0)
+Exiv2::Image::UniquePtr exifImage;
+#else
Exiv2::Image::AutoPtr exifImage;
+#endif
try {
exifImage = Exiv2::ImageFactory::open(imageFullPath.toStdString());
exifImage->readMetadata();
Bug#1052253: transition: libunibreak
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: libunibr...@packages.debian.org Control: affects -1 + src:libunibreak Hi, I'd like to request a transition slot for the much needed update of the libunibreak library (from 1.1 to 5.1). The only dependency in Debian is fbreader, which I verified that builds fine using the new version of libunibreak. Ben file: title = "libunibreak"; is_affected = .depends ~ "libunibreak1" | .depends ~ "libunibreak5"; is_good = .depends ~ "libunibreak5"; is_bad = .depends ~ "libunibreak1"; Thanks, -- Pino
Bug#1052252: transition: grantlee5
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition X-Debbugs-Cc: grantl...@packages.debian.org, pkg-kde-t...@alioth-lists.debian.net Control: affects -1 + src:grantlee5 Hi, grantlee (packaged in Debian in src:grantlee5) is a library (two libraries, in practice) that has a stable API/ABI. The new release 5.3.x, currently in experimental, is generally usable by users built with the old version. The only gotcha is that plugins for it are installed and loaded from paths with the major and minor version in it, i.e. ../plugins/grantlee/./ This means that, after the upgrade to a new minor series, the plugins installed after building with the old version are not used anymore; usually software using grantlee and shipping plugins for it follows the grantlee version, so a simple rebuild is enough to fix the issue. Since I wanted to avoid uploading the new version and have to manually track external plugins and breaking users that rely on those plugins, I created a new simple dh_grantlee helper to track the dependency on the version the plugins were built for, adding the provide for it in one of the two grantlee libraries as "grantlee5-templates-MAJOR-MINOR". This is already in place in unstable starting from grantlee5 5.2.0-5, and the 4 sources that install plugins for it were already changed to use dh_grantlee, and thus now properly track their plugin dependency. Hence, I'd like to request a transition slot for uploading grantlee5 5.3.x to unstable, rebuilding the few dependencies needed: - kcalutils - kdevelop - libkf5grantleetheme - skrooge They all build fine with the new grantlee; I have the new version of kdevelop ready in experimental, and I can upload that rather than rebuilding the current version in unstable. Ben file: title = "grantlee5"; is_affected = .depends ~ "grantlee5-templates-5-2" | .depends ~ "grantlee5-templates-5-3"; is_good = .depends ~ "grantlee5-templates-5-3"; is_bad = .depends ~ "grantlee5-templates-5-2"; Thanks, -- Pino
Bug#1042366: RM: kchmviewer [armel ppc64el s390x] -- ROM; requires QtWebEngine
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: kchmvie...@packages.debian.org Control: affects -1 + src:kchmviewer Hi, the new version of src:kchmviewer requires QtWebEngine for the main interface: as result, it is built only on few architectures. Hence, please remove kchmviewer on the following architectures: armel ppc64el s390x Thanks, -- Pino
Bug#1042069: RM: libvirt-daemon-driver-storage-gluster [armel armhf i386 mipsel] -- RoQA; glusterfs soon to be 64bit-only
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: libv...@packages.debian.org Control: affects -1 + src:libvirt Hi, please remove the libvirt-daemon-driver-storage-gluster binary package on 32bit architectures: the libvirt 9.5.0-2 upload drops support for glusterfs on those architectures, as glusterfs itself is going to be 64bit-only soon (see [1], and #1039604). [1] https://tracker.debian.org/news/168/accepted-glusterfs-110-1-source-into-experimental/ Thanks, -- Pino
Bug#1041516: RM: kalgebra kalgebra-common [mipsel] -- ROM; qtwebengine-opensource-src FTBFS on mipsel
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: kalge...@packages.debian.org Control: affects -1 + src:kalgebra Control: block 1041268 by -1 Hi, please remove the kalgebra & kalgebra-common binary packages on mipsel: they used to be built because qtwebengine-opensource-src is available on mipsel. Since qtwebengine-opensource-src FTBFSes on mipsel, and it is scheduled for removal on architecture, please remove the cruft binaries. Please note that src:kalgebra still builds a kalgebramobile binary package on mipsel (like in all the architectures without QtWebEngine). Thanks, -- Pino
Bug#1041515: RM: kalendar [mipsel] -- ROM; qtwebengine-opensource-src FTBFS on mipsel
Package: ftp.debian.org Severity: normal User: ftp.debian@packages.debian.org Usertags: remove X-Debbugs-Cc: kalen...@packages.debian.org Control: affects -1 + src:kalendar Control: block 1041268 by -1 Hi, please remove kalendar from mipsel: it uses qtwebengine-opensource-src, which currently FTBFS on mipsel, and thus kalendar was excluded from building on mipsel. Thanks, -- Pino
Bug#1040957: xine-lib-1.2: FTBFS on hurd-i386
Source: xine-lib-1.2 Version: 1.2.13+hg20230710-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Control: found -1 1.2.12-1 Hi, xine-lib-1.2 currently FTBFSes on hurd-i386 [1]. The problem is that the VAAPI support is not available on hurd-i386, and libxine2-x unconditionally installs files that are built for that. The attached patch fixes the issue, by limiting the VAAPI plugins that were not already limited on some architectures (e.g. the wayland one) as !hurd-any, like the libva-dev build dependency. As I was tweaking/fixing the packaging for hurd-i386, I included also few more Hurd-related changes: - enable the smb plugin also on the Hurd, as samba is now built there - change the exclusion architecture pattern for the vcdo plugin to !hurd-any, as it applies to any Hurd architecture and not only to hurd-i386 [1] https://buildd.debian.org/status/fetch.php?pkg=xine-lib-1.2=hurd-i386=1.2.13%2Bhg20230710-1=1689013434=0 Thanks, -- Pino --- a/debian/control +++ b/debian/control @@ -30,7 +30,7 @@ Build-Depends: debhelper-compat (= 13), libpulse-dev, librsvg2-bin, libsdl1.2-compat-dev, - libsmbclient-dev [!hurd-i386], + libsmbclient-dev, libspeex-dev, libtheora-dev, libv4l-dev [linux-any], --- a/debian/libxine2-misc-plugins.install +++ b/debian/libxine2-misc-plugins.install @@ -9,11 +9,11 @@ debian/tmp/usr/lib/*/xine/plugins/*/xine debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_network.so [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_pvr.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_rtp.so -[!hurd-i386] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_smb.so +debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_smb.so #[linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_v4l.so [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_v4l2.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_vcd.so -[!hurd-i386] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_vcdo.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_inp_vcdo.so # audio output plugins [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_ao_out_alsa.so --- a/debian/libxine2-x.install +++ b/debian/libxine2-x.install @@ -5,7 +5,7 @@ debian/tmp/usr/lib/*/xine/plugins/*/xine debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_opengl.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_opengl2.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_sdl.so -[linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_vaapi.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_vaapi.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_xcbshm.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_xcbxv.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_out_xdirectfb.so @@ -17,7 +17,7 @@ debian/tmp/usr/lib/*/xine/plugins/*/xine debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_gl_egl_x11.so debian/tmp/usr/lib/*/xine/plugins/*/xineplug_vo_gl_glx.so [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_hw_frame_vaapi.so -debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_drm.so -debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_glx.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_drm.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_glx.so [linux-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_wl.so -debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_x11.so +[!hurd-any] debian/tmp/usr/lib/*/xine/plugins/*/xineplug_va_display_x11.so
Bug#1040582: stress-ng: improve the build dependencies (more availability, linux-any markers)
Source: stress-ng Version: 0.16.00-1 Severity: minor Tags: patch Hi, some of the build dependencies can be improved: - what is specific for Linux ought to be better marked as "linux-any", rather than excluding non-Linux architectures - some of the them are actually available on non-Linux too Attached there is a patch to improve them, with some extra details in the changelog. Thanks, -- Pino diff -Nru stress-ng-0.16.00/debian/changelog stress-ng-0.16.00/debian/changelog --- stress-ng-0.16.00/debian/changelog +++ stress-ng-0.16.00/debian/changelog @@ -1,3 +1,17 @@ +stress-ng (0.16.00-2) UNRELEASED; urgency=medium + + [ Pino Toscano ] + * Update/improve the build dependencies: +- enable libkeyutils-dev also on ia64, as it is available there as well +- enable libjudy-dev, libxxhash-dev, and libglvnd-dev on all the + architectures, as they are not specific to a certain OS +- switch the build dependencies that exist only on Linux from + "!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64" to "linux-any": + libkeyutils-dev, libapparmor-dev, apparmor, libaio-dev, libcap-dev, + libsctp-dev, libatomic1, libkmod-dev, libgbm-dev + + -- Colin Ian King Fri, 07 Jul 2023 19:47:54 +0200 + stress-ng (0.16.00-1) unstable; urgency=medium * Makefile: bump version to 0.16.00 diff -Nru stress-ng-0.16.00/debian/control stress-ng-0.16.00/debian/control --- stress-ng-0.16.00/debian/control +++ stress-ng-0.16.00/debian/control @@ -12,19 +12,19 @@ libgcrypt20-dev, libjpeg-dev, libmpfr-dev, - libkeyutils-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64 !linux-ia64], - libapparmor-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - apparmor [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libaio-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libcap-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libsctp-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], + libkeyutils-dev [linux-any], + libapparmor-dev [linux-any], + apparmor [linux-any], + libaio-dev [linux-any], + libcap-dev [linux-any], + libsctp-dev [linux-any], libipsec-mb-dev [amd64], - libjudy-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libatomic1 [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libkmod-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libxxhash-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libglvnd-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64], - libgbm-dev [!hurd-i386 !kfreebsd-i386 !kfreebsd-amd64] + libjudy-dev, + libatomic1 [linux-any], + libkmod-dev [linux-any], + libxxhash-dev, + libglvnd-dev, + libgbm-dev [linux-any] Homepage: https://github.com/ColinIanKing/stress-ng Package: stress-ng
Bug#1040418: nmu: libheif_1.16.2-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: libh...@packages.debian.org, ba...@struktur.de, sramac...@debian.org Control: affects -1 + src:libheif nmu libheif_1.16.2-1 . ANY . unstable . -m "rebuild on buildd" Please rebuild libheif (on all architectures, as it has M-A:same binaries), so it can migrate to testing; kimageformat will need it soon. Thanks, -- Pino
Bug#907152: vulkan: Porting to non-linux systems
Source: vulkan-loader Followup-For: Bug #907152 X-Debbugs-Cc: tjaal...@debian.org Control: tag -1 = upstream fixed-upstream Hi! The vulkan source changed a while since this bug was originally reported: it was split into components, with this bug reassigned to to the loader, and in it was ported to more architectures. I recently ported this to Hurd again, with good results: the upstream tests pass, and it was reviewed and merged upstream: https://github.com/KhronosGroup/Vulkan-Loader/pull/1244 Because of this, I submitted the enablement of src:vulkan-loader to non-Linux architectures, as the actual Hurd porting will come in soon in new upstream releases (I guess in versions greater than 1.3.250): https://salsa.debian.org/xorg-team/vulkan/vulkan-loader/-/merge_requests/14 I'm *not* submitting the upstream Hurd patch to downstream backport: the code upstream was refactored, so a good part of it would need to be rewritten, which is not that worth of effort for something that has never been available yet. -- Pino
Bug#1040123: sane-backends: FTBFS on hurd-386: unsupported parallel port IO
Source: sane-backends Version: 1.1.1-6 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Control: found -1 1.2.1-3 Hi, starting from sane-backends 1.1.1-6, there are in effect changes to the Debian packaging that cause --enable-parport-directio to be enabled only on hurd-386 [1][2][3]. In reality parallel port is not supported on the Hurd, and thus sane-backends FTBFS on hurd-i386 since 1.1.1-6 [4][5]. The fix here is to not use --enable-parport-directio, as it used to be in versions before 1.1.1-6; since the INS_CONF variable in d/rules is used only for this, then it can be dropped altogether. Easy patch attached. [1] https://git.jff.email/cgit/sane-backends.git/commit/debian/rules?id=a7fdf31671fc8393d8c50ad2e14668ce5d78282a [2] https://git.jff.email/cgit/sane-backends.git/commit/debian/rules?id=8a20544b5a6784e2c5ecbafc4ba2fa91c26c16aa [3] https://git.jff.email/cgit/sane-backends.git/commit/debian/rules?id=1e25318379249c8c4c2c55c741b409a858b1f52e [4] https://buildd.debian.org/status/fetch.php?pkg=sane-backends=hurd-i386=1.1.1-6=1664715955=0 [5] https://buildd.debian.org/status/fetch.php?pkg=sane-backends=hurd-i386=1.2.1-3=1688016732=0 Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -14,13 +14,6 @@ ifeq (,$(findstring nostrip,$(DEB_BUILD_ STRIP = "" endif -ifeq (,$(filter hurd-i386,$(DEB_HOST_ARCH))) - INS_CONF = "" -else - INS_CONF = --enable-parport-directio -endif - - %: dh $@ @@ -56,8 +49,7 @@ endif --enable-pnm-backend \ --with-usb \ --without-v4l \ - --disable-locking \ - $(INS_CONF) + --disable-locking override_dh_autoreconf: dh_autoreconf -Xlibtool.m4
Bug#1039055: qxmpp: please package qxmpp 1.5+
Source: qxmpp Severity: wishlist X-Debbugs-Cc: tehn...@debian.org Control: block 1036558 by -1 Hi, please package a upstream version of qxmpp, at least >= 1.5, currently 1.5.5; this is needed to update kaidan to 0.9.0+). Thanks! -- Pino
Bug#1021857: llvm-14-dev: ClangConfig.cmake is still broken
Package: llvm-14-dev Followup-For: Bug #1021857 Hi, (sending properly again) 1:14.0.6-6 does some changes, however it does not fix all of it; this is while trying to build qtcreator: CMake Error at /usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake:756 (message): The imported target "diagtool" references the file "/usr/lib/llvm-14/bin/diagtool" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/cmake/clang-14/ClangConfig.cmake:19 (include) cmake/FindClang.cmake:1 (find_package) CMakeLists.txt:100 (find_package) In practice, ClangTargets.cmake is still broken, as it tries to look for tools. I think that the "cmake-test" is incomplete, as it only tests the "LLVM" cmake module and not the "Clang" one; adding a new check for find_package(Clang) should help to make sure all the cmake bits are working as expected. Thanks, -- Pino
Bug#1021857: reopening 1021857
reopen 1021857 thanks 1:14.0.6-6 does some changes, however it does not fix all of it; this is while trying to build qtcreator: CMake Error at /usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake:756 (message): The imported target "diagtool" references the file "/usr/lib/llvm-14/bin/diagtool" but this file does not exist. Possible reasons include: * The file was deleted, renamed, or moved to another location. * An install or uninstall procedure did not complete successfully. * The installation package was faulty and contained "/usr/lib/llvm-14/lib/cmake/clang/ClangTargets.cmake" but not all the files it references. Call Stack (most recent call first): /usr/lib/cmake/clang-14/ClangConfig.cmake:19 (include) cmake/FindClang.cmake:1 (find_package) CMakeLists.txt:100 (find_package) Thanks, -- Pino
Bug#1019300: mp3guessenc: autopkgtests failure with grep 3.8: fgrep is deprecated
Source: mp3guessenc Version: 0.27.5+dfsg.1-1 Severity: serious Tags: patch Justification: breaks autopkgtests Hi, GNU grep 3.8 officially deprecates egrep and fgrep, and those two commands now issue a deprecation message on stderr [1]. The autopkgtests of mp3guessenc use fgrep, and while they still work fine, the extra messages on stderr are considered by default a failure, and thus the tests are marked as such. While autopkgtest has a "allow-stderr" restriction to not consider stderr output as failure in case it is expected, I think the better solution here is simply to switch away from fgrep to grep -F. This works fine with grep 3.8 and any older version. Patch attached for this. [1] https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html Thanks, -- Pino diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/changelog mp3guessenc-0.27.5+dfsg.1/debian/changelog --- mp3guessenc-0.27.5+dfsg.1/debian/changelog 2020-09-20 21:50:00.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/changelog 2022-09-07 08:12:34.0 +0200 @@ -1,3 +1,12 @@ +mp3guessenc (0.27.5+dfsg.1-2) UNRELEASED; urgency=medium + + [ Pino Toscano ] + * Switch from "fgrep" to "grep -F" in autopkgtests, as the former is +officially deprecated since grep 3.8, writing a deprecation message on +stderr that is considered as autopkgtest failure. + + -- Peter Blackman Wed, 07 Sep 2022 08:12:34 +0200 + mp3guessenc (0.27.5+dfsg.1-1) unstable; urgency=medium * New upstream version diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/a mp3guessenc-0.27.5+dfsg.1/debian/tests/a --- mp3guessenc-0.27.5+dfsg.1/debian/tests/a2020-07-16 10:49:55.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/a2022-09-07 08:12:13.0 +0200 @@ -6,7 +6,7 @@ mp3guessenc -a debian/flush.mp3 > a.tmp set -e # -fgrep 291 a.tmp +grep -F 291 a.tmp # rm a.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/f mp3guessenc-0.27.5+dfsg.1/debian/tests/f --- mp3guessenc-0.27.5+dfsg.1/debian/tests/f2020-07-16 10:43:15.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/f2022-09-07 08:12:13.0 +0200 @@ -6,8 +6,8 @@ mp3guessenc -f debian/flush.mp3 > f.tmp set -e # -fgrep "48 kbps" f.tmp -fgrep 550 f.tmp +grep -F "48 kbps" f.tmp +grep -F 550 f.tmp # rm f.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/i mp3guessenc-0.27.5+dfsg.1/debian/tests/i --- mp3guessenc-0.27.5+dfsg.1/debian/tests/i2020-07-16 10:48:58.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/i2022-09-07 08:12:13.0 +0200 @@ -6,8 +6,8 @@ mp3guessenc -i debian/flush.mp3 > i.tmp set -e # -fgrep 2020 i.tmp -fgrep Ambient i.tmp +grep -F 2020 i.tmp +grep -F Ambient i.tmp # rm i.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/m mp3guessenc-0.27.5+dfsg.1/debian/tests/m --- mp3guessenc-0.27.5+dfsg.1/debian/tests/m2020-07-16 10:44:39.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/m2022-09-07 08:12:13.0 +0200 @@ -6,8 +6,8 @@ mp3guessenc -f debian/flush.mp3 > f.tmp set -e # -fgrep "48 kbps" f.tmp -fgrep 550 f.tmp +grep -F "48 kbps" f.tmp +grep -F 550 f.tmp # rm f.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/n mp3guessenc-0.27.5+dfsg.1/debian/tests/n --- mp3guessenc-0.27.5+dfsg.1/debian/tests/n2020-07-16 11:08:27.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/n2022-09-07 08:12:13.0 +0200 @@ -11,7 +11,7 @@ fi set -e # -fgrep FhG n.tmp +grep -F FhG n.tmp # rm n.tmp diff -Nru mp3guessenc-0.27.5+dfsg.1/debian/tests/s mp3guessenc-0.27.5+dfsg.1/debian/tests/s --- mp3guessenc-0.27.5+dfsg.1/debian/tests/s2020-07-16 10:51:16.0 +0200 +++ mp3guessenc-0.27.5+dfsg.1/debian/tests/s2022-09-07 08:12:13.0 +0200 @@ -6,7 +6,7 @@ mp3guessenc -s debian/flush.mp3 > s.tmp set -e # -fgrep FhG s.tmp +grep -F FhG s.tmp # rm s.tmp
Bug#1017044: graphviz: please remove the Debian menu file
Package: graphviz Version: 2.42.2-7 Severity: minor Tags: patch Hi, graphviz currently provides a Debian menu file with two entries, for the dotty and lefty applications; however: - the Debian menu is deprecated for some years already [1] - none of the items in the menu file have icons - the applications are very niche - there are no desktop counterparts, nor requests for them either in Debian nor upstream Hence, rather than converting them to desktop files, I think it is a better idea to simply drop the old Debian menu file for now. In case there is a demand for those two applications, I think it would be better to ask upstream to provide proper desktop files for them. Attached there is a patch to simply drop the Debian menu file. [1] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html Thanks, -- Pino diff -Nru graphviz-2.42.2/debian/changelog graphviz-2.42.2/debian/changelog --- graphviz-2.42.2/debian/changelog2022-06-15 19:55:30.0 +0200 +++ graphviz-2.42.2/debian/changelog2022-08-12 11:28:29.0 +0200 @@ -1,3 +1,15 @@ +graphviz (2.42.2-7.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Drop the Debian menu file: +- the Debian menu is deprecated for some years already +- none of the items in the menu file have icons +- the applications are very niche +- there are no desktop counterparts, nor requests for them either in Debian + nor upstream + + -- Pino Toscano Fri, 12 Aug 2022 11:28:29 +0200 + graphviz (2.42.2-7) unstable; urgency=medium * Recommend fonts-liberation2 (closes: #1003006). diff -Nru graphviz-2.42.2/debian/graphviz.menu graphviz-2.42.2/debian/graphviz.menu --- graphviz-2.42.2/debian/graphviz.menu2014-12-10 16:25:41.0 +0100 +++ graphviz-2.42.2/debian/graphviz.menu1970-01-01 01:00:00.0 +0100 @@ -1,4 +0,0 @@ -?package(graphviz):needs="X11" section="Applications/Graphics" \ - title="dotty" command="/usr/bin/dotty" -?package(graphviz):needs="X11" section="Applications/Graphics" \ - title="lefty" command="/usr/bin/lefty"
Bug#1016148: RM: kwayland-server -- ROM; dropped source from upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-kde-t...@alioth-lists.debian.net Hi, please remove the kwayland-server source: its functionalities were moved to other KDE Plasma sources, and thus upstream dropped this. Thanks, -- Pino
Bug#1014672: gnunet-gtk: drop the not needed /usr/share/icons/gnunet-fs-gtk.png symlink
Package: gnunet-gtk Version: 0.16.0-2 Severity: minor Tags: patch Hi, gnunet-gtk ships a /usr/share/icons/gnunet-fs-gtk.png symlink to the application icon shipped in the XDG hicolor icon theme. This symlink is redundant, since the proper icons in various sizes are already available in the XDG hicolor icon theme. Hence, the symlink can be dropped. Easy patch attached for this. Thanks, -- Pino --- a/debian/gnunet-gtk.links +++ b/debian/gnunet-gtk.links @@ -1,2 +1 @@ -/usr/share/icons/hicolor/32x32/apps/gnunet-fs-gtk.png /usr/share/icons/gnunet-fs-gtk.png /usr/share/man/man1/gnunet-setup.1 /usr/share/man/man1/gnunet-setup-pkexec.1
Bug#1014632: RM: sapphire -- RoQA; FTBFS; dead upstream; unmaintained; very low popcon
Package: ftp.debian.org
Severity: normal
Hi,
sapphire has not seen a new upstream release since 2002 (!), and
upstream seems to have stopped working on it long long time ago.
Furthermore:
- the upstream website is a SourceForce page that only hosts very old
releases, and has no source repositories
- I cannot find anywhere a potential repository that continues the
development
- the last maintainer upload was in 2009, and since then it got only
one NMU in 2017
- currently FTBFSes due to the very old packaging
- it has a very low popcon count (19 at the time I'm writing this)
- plenty of alternatives ("minimalist/lightweights" WMs) exist
Hence, it looks to me it would be a better idea to simply remove
sapphire from Debian.
Thanks,
--
Pino
Bug#1014502: nmu: labplot_2.9.0-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, I just started a very small transition affecting cantor & labplot; I checked in advance that it should not affect existing transitions, nor it is affected by any currently ongoing. The new cantor was already uploaded and installed on all the architectures (which are few, as it requires Qt WebEngine). labplot builds fine with the new cantor (I checked this too). Hence, please: nmu labplot_2.9.0-1 . amd64 arm64 armhf i386 mips64el mipsel . unstable . -m "rebuild with cantor 22.04" Thanks, -- Pino
Bug#1013679: nmu: xq_0.0.7-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu Hi, please rebuild xq on amd64 after it was accepted from NEW; it is a simple tool, so rebuilding it only on amd64 is enough. nmu xq_0.0.7-1 . amd64 . unstable . -m "rebuild on buildd" Thanks, -- Pino
Bug#1012436: synaptic: please remove the unused 'menu' suggest
Package: synaptic
Version: 0.90.2
Severity: minor
Tags: patch
Hi,
synaptic currently suggests the 'menu' package. Looking back in the
history, it looks like this was due to the usage of su-to-root, used
to gain root permissions when launching synaptic from the Debian or
XDG/desktop menu. synaptic 0.75.12 switches to policykit for this,
dropping the usage of su-to-root.
Hence, I believe it is possible to safely drop the 'menu' suggest;
patch attached for this. I also dropped the conflict with an extremely
old version of 'menu', even older than what's in Debian Jessie.
Thanks,
--
Pino
diff -Nru synaptic-0.90.2/debian/changelog synaptic-0.90.2+nmu1/debian/changelog
--- synaptic-0.90.2/debian/changelog2020-11-16 09:56:34.0 +0100
+++ synaptic-0.90.2+nmu1/debian/changelog 2022-06-07 08:10:57.0
+0200
@@ -1,3 +1,11 @@
+synaptic (0.90.2+nmu1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+ * Stop suggesting 'menu', as it is not needed/used anymore since 0.75.12.
+ * Drop conflict with a very old version (at least pre-Jessie) of 'menu'.
+
+ -- Pino Toscano Tue, 07 Jun 2022 08:10:57 +0200
+
synaptic (0.90.2) unstable; urgency=medium
[ Heimen Stoffels ]
diff -Nru synaptic-0.90.2/debian/control synaptic-0.90.2+nmu1/debian/control
--- synaptic-0.90.2/debian/control 2020-11-16 09:56:34.0 +0100
+++ synaptic-0.90.2+nmu1/debian/control 2022-06-07 08:10:57.0 +0200
@@ -13,9 +13,8 @@
Package: synaptic
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, hicolor-icon-theme, policykit-1
-Conflicts: menu (<< 2.1.11)
Recommends: libgtk3-perl, xdg-utils
-Suggests: dwww, menu, deborphan, apt-xapian-index, tasksel,
software-properties-gtk
+Suggests: dwww, deborphan, apt-xapian-index, tasksel, software-properties-gtk
Description: Graphical package manager
Synaptic is a graphical package management tool based on GTK+ and APT.
Synaptic enables you to install, upgrade and remove software packages in
Bug#1012435: RM: oroborus -- RoQA; Upstream Dead; Orphaned; FTBFS; Unmaintained
Package: ftp.debian.org
Severity: normal
Control: block -1 by 1012421 1012433 1012434
Hi,
the oroborus source:
- had no maintainer upload in the past 11+ years, with a single NMU to
fix the build with GCC 10
- it was recently orphaned due to the maintainer retirement
- its upstream was the Debian source itself
- a very low popcon value (19 at the time of this writing)
- plenty of alternatives ("minimalist/lightweights" WMs) exist
Hence, it looks to me it would be a better idea to simply remove
oroborus from Debian.
Thanks,
--
Pino
Bug#1012434: RM: keylaunch -- RoQA; Upstream Dead; Orphaned; FTBFS; Unmaintained
Package: ftp.debian.org Severity: normal Hi, the keylaunch source: - had no upload in the past 11+ years - it was recently orphaned due to the maintainer retirement - its upstream was the Debian source itself (part of the oroborus project) - a very low popcon value (21 at the time of this writing) Hence, it looks to me it would be a better idea to simply remove desklaunch from Debian. Thanks, -- Pino
Bug#1012433: RM: desklaunch -- RoQA; Upstream Dead; Orphaned; FTBFS; Unmaintained
Package: ftp.debian.org Severity: normal Hi, the desklaunch source: - had no upload in the past 11+ years - it was recently orphaned due to the maintainer retirement - its upstream was the Debian source itself (part of the oroborus project) - a very low popcon value (26 at the time of this writing) Hence, it looks to me it would be a better idea to simply remove desklaunch from Debian. Thanks, -- Pino
Bug#1010716: llvm-toolchain-14: autopkgtest failure on arm64/armhf
Source: llvm-toolchain-14
Version: 1:14.0.3-1
Severity: important
Tags: patch
X-Debbugs-Cc: sylves...@debian.org
Hi,
the qualify-clang.sh script, invoked as one of the autopkgtests, fails
to complete successfully on arm64 & armhf for llvm-toolchain-14.
The reason for this is because the output of the preprocessing of the
"#include " source shrank a lot; when looking at arm64, the
difference between the output with llvm-13 and llvm-14 are solely the
empty lines:
- llvm-13: 165 lines, 71 non-empty lines
- llvm-14: 74 lines, 71 non-empty lines
- there is no difference in the non-empty lines
Compared to e.g. amd64, there are less lines due to the different fenv.h
provided by glibc:
- FE_TONEAREST, FE_DOWNWARD, FE_UPWARD, and FE_TOWARDZERO are
implemented as macros on arm64 (while as single enum on amd64), thus
disappearing after the preprocessing
- the fenv_t struct has much less fields: 14 on amd64 vs 2 on arm64
- femode_t is a simple typedef on arm64, rather than a struct
Similar comparisons can be done on armhf.
Hence,I believe a possible way forward is the following:
- remove the empty lines when counting the lines in the output of the
"#include " preprocessing
- reduce the number of required lines from 100 to 60; I don't know why
100 was chosen, as the commit that adds that [1] does not explain it;
since the current value of non-empty lines on arm64 is 71, I chose 60
rather than 70 mostly to keep room for a minimal removal
[1]
https://salsa.debian.org/pkg-llvm-team/llvm-toolchain/-/commit/4f47c2ac959dd05399da8fd2c40084ee86c25267#b53c2fe1e367d55eb53a487fda5ca85af65594aa_0_32
Attached there is a patch that implements both the changes described
above; with that, qualify-clang.sh fully completes successfully on
arm64.
Thanks,
--
Pino
--- a/debian/qualify-clang.sh
+++ b/debian/qualify-clang.sh
@@ -350,9 +350,9 @@ void increment(atomic_size_t *arg) {
clang-$VERSION -v -c foo.c &> /dev/null
echo "#include " > foo.cc
-NBLINES=$(clang++-$VERSION -P -E foo.cc|wc -l)
-if test $NBLINES -lt 100; then
-echo "Error: more than 100 lines should be returned"
+NBLINES=$(clang++-$VERSION -P -E foo.cc|grep .|wc -l)
+if test $NBLINES -lt 60; then
+echo "Error: more than 60 non-empty lines should be returned"
echo "output:"
clang++-$VERSION -P -E foo.cc
exit 42
Bug#1010419: texstudio: Stop shipping no more needed texstudio.xpm
Package: texstudio Version: 4.2.3+ds-1 Severity: minor Tags: patch Hi, the texstudio packaging manually installs the upstream texstudio.xpm file to /usr/share/pixmaps; considering that - the application icon is already installed in various sizes in the global XDG hicolor icon theme - /usr/share/pixmaps is considered a legacy locations (unthemed, unsized, etc) then it would make sense to not ship /usr/share/pixmaps/texstudio.xpm anymore. Patch attached for this. Thanks, -- Pino --- a/debian/texstudio.install +++ b/debian/texstudio.install @@ -6,6 +6,3 @@ usr/share/icons usr/share/texstudio/CREDITS/usr/share/doc/texstudio usr/share/texstudio/*.badWords usr/share/texstudio/*.stopWords* - -# installing from upstream -utilities/texstudio.xpm/usr/share/pixmaps
Bug#996614: RM: kf5-kdepim-apps-libs -- ROM; dropped source from upstream
Package: ftp.debian.org Severity: normal Hi, please remove the kf5-kdepim-apps-libs source: its functionalities were moved to other KDE PIM sources, and thus upstream dropped this. Thanks, -- Pino
Bug#996610: RM: cantor/experimental -- ROM; NVIU
Package: ftp.debian.org Severity: normal Hi, please remove cantor from experimental: it is a version older than what is available in unstable now, and it was not automatically removed (dunno why). Thanks, -- Pino
Bug#995970: lshw: misses changes from 02.18.85-0.6 & 02.18.85-0.7
Source: lshw Version: 02.19.git.2021.06.19.996aaad9c7-1 Severity: serious Justification: reverts past changes X-Debbugs-Cc: z...@debian.org Hi, the upload of lshw 02.19.git.2021.06.19.996aaad9c7-1 was done starting from 02.18.85-0.5, meaning that neither 02.18.85-0.6 nor 02.18.85-0.7 are acknowledged: - 02.18.85-0.6 contains Debian-only changes that indeed need to be applied - 02.18.85-0.7 contains the backport of a 2 years old upstream commit, which might be already contained in the packaged Git snapshot Please include them both, acknowledging them in changelog. Thanks, -- Pino
Bug#995967: mate-panel: drop the menu-xdg dependency
Package: mate-panel
Version: 1.24.1-1
Severity: minor
Tags: patch
Hi,
The Debian menu system was officially deprecated more than 6 years ago;
since then, Debian menu entries are being removed, making less and less
useful to show the old Debian menu converted to XDG entries.
Hence, no more require the old Debian menu system for MATE users: in
case any old Debian menu entry is wanted, it can be easily provided as
desktop file by the package that contains it.
[1] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html
Thanks,
--
Pino
>From bf9ea5ff88f3f4db6f670468c5b5a33872a61710 Mon Sep 17 00:00:00 2001
From: Pino Toscano
Date: Sat, 9 Oct 2021 10:05:18 +0200
Subject: [PATCH] Drop menu-xdg dependency from mate-panel
The Debian menu system was officially deprecated more than 6 years ago;
since then, Debian menu entries are being removed, making less and less
useful to show the old Debian menu converted to XDG entries.
Hence, no more require the old Debian menu system for MATE users: in
case any old Debian menu entry is wanted, it can be easily provided as
desktop file by the package that contains it.
[1] https://lists.debian.org/debian-devel-announce/2015/09/msg0.html
Gbp-Dch: Short
---
debian/control | 1 -
1 file changed, 1 deletion(-)
diff --git a/debian/control b/debian/control
index 593bbe2..d403af7 100644
--- a/debian/control
+++ b/debian/control
@@ -50,7 +50,6 @@ Depends: libmate-panel-applet-4-1 (= ${binary:Version}),
mate-menus,
mate-panel-common (= ${source:Version}),
mate-polkit,
- menu-xdg,
${misc:Depends},
${shlibs:Depends},
Breaks: mate-panel-common (<< 1.1.1-4),
--
2.33.0
Bug#995887: RM: subtitlecomposer [armel armhf] -- ROM; requires Desktop OpenGL
Package: ftp.debian.org Severity: normal Hi, please remove subtitlecomposer on armel & armhf. The new upstream version, 0.7.1, seems to require Desktop OpenGL, which is problematic to use together with the implicit EGL that Qt on those architectures defaults to. Thanks, -- Pino
Bug#995615: astyle: FTBFS on hurd-i386: unconditional PATH_MAX usage
Source: astyle
Version: 3.1-2
Severity: important
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
Control: forwarded -1 https://sourceforge.net/p/astyle/bugs/549/
Control: block -1 by 995612
Hi,
currently astyle cannot be built on hurd-i386.
The first issue is the unconditional requirement of Java, which is
not available/ported on Hurd; this was reported as #995612, as it does
not affect only Hurd.
The second issue, specific to Hurd, is the unconditional usage of
PATH_MAX; I reported the issue upstream with a patch [1]; however,
given that the project is basically no more developed further [2],
then I'm attaching it here as well, since apparently it will be needed
as Debian patch...
[1] https://sourceforge.net/p/astyle/bugs/549/
[2] https://sourceforge.net/p/astyle/bugs/548/
Thanks,
--
Pino
Author: Pino Toscano
Description: Use modern realpath() to avoid PATH_MAX
Last-Update: 2021-10-03
Forwarded: https://sourceforge.net/p/astyle/bugs/549/
--- a/src/astyle_main.cpp
+++ b/src/astyle_main.cpp
@@ -1379,13 +1379,12 @@
// Return the full path name or an empty string if failed.
string ASConsole::getFullPathName(const string& relativePath) const
{
- // ignore realPath attribute warning
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wunused-result"
- char fullPath[PATH_MAX];
- realpath(relativePath.c_str(), fullPath);
- return fullPath;
-#pragma GCC diagnostic pop
+ char *fullPath = realpath(relativePath.c_str(), nullptr);
+ if (fullPath == nullptr)
+ return string();
+ const string p(fullPath);
+ free(fullPath);
+ return p;
}
/**
Bug#995612: astyle: do not build the Java bindings on architectures without Java
Source: astyle
Version: 3.1-2
Severity: important
Tags: patch
Hi,
astyle currently cannot be built on architectures that do not have Java
(so default-jdk is not installable); since the Java bindings are
optional, it is possible to build astyle without them on those
architectures.
Attached there is a patch to do this. Sadly there is no "negative
architectures" in the list of architectures of a package, so the
drawbacks are:
- the hardcoded list of architectures without Java, for the default-jdk
build dependency
- the hardcoded list of architectures with Java, for the libastylej-jni
package
Thanks,
--
Pino
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,7 @@
Source: astyle
Section: devel
Priority: optional
-Build-Depends: debhelper (>= 11), default-jdk, dh-exec (>= 0.3), cmake
+Build-Depends: debhelper (>= 11), default-jdk [!hppa !hurd-i386
!kfreebsd-any], dh-exec (>= 0.3), cmake
Maintainer: Matteo Cypriani
Uploaders: Margarita Manterola
Standards-Version: 4.1.5
@@ -45,7 +45,7 @@
Package: libastylej-jni
Section: java
-Architecture: any
+Architecture: alpha amd64 arm64 armel armhf i386 ia64 m68k mips64el mipsel
powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32
Multi-Arch: same
Depends: ${shlibs:Depends}, ${misc:Depends}
Description: Java JNI library for Artistic Style
--- a/debian/rules
+++ b/debian/rules
@@ -7,12 +7,19 @@
export DEB_BUILD_MAINT_OPTIONS = hardening=+all
DPKG_EXPORT_BUILDFLAGS = 1
include /usr/share/dpkg/buildflags.mk
+include /usr/share/dpkg/architecture.mk
# Avoid unneeded library dependencies
LDFLAGS += -Wl,--as-needed
+ifneq (,$(filter libastylej-jni,$(shell dh_listpackages)))
+ EXTRA_CONFIGURE_ARGS += -DBUILD_JAVA_LIBS=on
+else
+ EXTRA_CONFIGURE_ARGS += -DBUILD_JAVA_LIBS=off
+endif
+
%:
dh $@
override_dh_auto_configure:
- dh_auto_configure -- -DBUILD_JAVA_LIBS=on -DBUILD_SHARED_LIBS=on
+ dh_auto_configure -- -DBUILD_SHARED_LIBS=on $(EXTRA_CONFIGURE_ARGS)
Bug#995575: colmap: FTBFS on hurd-i386: wrong reference to the build directory
Source: colmap Version: 3.6+really3.6-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Control: found -1 colmap/3.6+really3.6+git20210519-1 Hi, currently colmap fails to build on hurd-i386 [1]. The problem is that, in the colmap.install, the "obj-*-*-*" glob pattern is used to refer to the build directory. The default build directory for cmake is "obj-$DEB_HOST_GNU_TYPE", and considering that DEB_HOST_GNU_TYPE for hurd-i386 is "i686-gnu", then the pattern does not match the build directory. The fix is simple: simply use "obj-*" to refer to the build directory. Patch attached for this. [1] https://buildd.debian.org/status/fetch.php?pkg=colmap=hurd-i386=3.6%2Breally3.6-1=1632952345=0 Thanks, -- Pino --- a/debian/colmap.install +++ b/debian/colmap.install @@ -1,2 +1,2 @@ -obj-*-*-*/src/exe/colmap usr/bin +obj-*/src/exe/colmap usr/bin doc/COLMAP.desktop usr/share/applications
Bug#995574: googletest: please support GNU/Hurd
Source: googletest
Version: 1.11.0-2
Severity: important
Tags: upstream patch fixed-upstream
User: debian-h...@lists.debian.org
Usertags: hurd
Control: forwarded -1 https://github.com/google/googletest/pull/3200
Hi,
a couple of months ago, thanks to the effort of Mattias Ellert,
GoogleTest got support for GNU/Hurd [1], merged as commit
05e9fa23f7 [2].
Can you please backport it to the Debian package? This way, all the
sources that use GoogleTest from the system will benefit from it.
Attached there is a git format-patch version of the commit, which
applies almost cleanly (only with offsets in one file).
[1] https://github.com/google/googletest/pull/3200
[2]
https://github.com/google/googletest/commit/05e9fa23f74a4766294f858c16e87a1560261340
Thanks,
--
Pino
>From 05e9fa23f74a4766294f858c16e87a1560261340 Mon Sep 17 00:00:00 2001
From: Mattias Ellert
Date: Wed, 30 Dec 2020 13:50:04 +0100
Subject: [PATCH] Port to GNU/Hurd
---
googletest/include/gtest/internal/gtest-port-arch.h | 2 ++
googletest/include/gtest/internal/gtest-port.h | 9 ++---
googletest/src/gtest-port.cc| 2 +-
googletest/test/googletest-port-test.cc | 2 +-
googletest/test/gtest_help_test.py | 3 ++-
5 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/googletest/include/gtest/internal/gtest-port-arch.h
b/googletest/include/gtest/internal/gtest-port-arch.h
index 813bf2c6..a75cd5bb 100644
--- a/googletest/include/gtest/internal/gtest-port-arch.h
+++ b/googletest/include/gtest/internal/gtest-port-arch.h
@@ -78,6 +78,8 @@
# define GTEST_OS_FREEBSD 1
#elif defined __Fuchsia__
# define GTEST_OS_FUCHSIA 1
+#elif defined(__GNU__)
+# define GTEST_OS_GNU_HURD 1
#elif defined(__GLIBC__) && defined(__FreeBSD_kernel__)
# define GTEST_OS_GNU_KFREEBSD 1
#elif defined __linux__
diff --git a/googletest/include/gtest/internal/gtest-port.h
b/googletest/include/gtest/internal/gtest-port.h
index 6b66362f..f62f5876 100644
--- a/googletest/include/gtest/internal/gtest-port.h
+++ b/googletest/include/gtest/internal/gtest-port.h
@@ -116,6 +116,7 @@
// GTEST_OS_DRAGONFLY - DragonFlyBSD
// GTEST_OS_FREEBSD - FreeBSD
// GTEST_OS_FUCHSIA - Fuchsia
+// GTEST_OS_GNU_HURD - GNU/Hurd
// GTEST_OS_GNU_KFREEBSD - GNU/kFreeBSD
// GTEST_OS_HAIKU- Haiku
// GTEST_OS_HPUX - HP-UX
@@ -543,7 +544,7 @@ typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION;
(GTEST_OS_LINUX || GTEST_OS_MAC || GTEST_OS_HPUX || GTEST_OS_QNX ||
\
GTEST_OS_FREEBSD || GTEST_OS_NACL || GTEST_OS_NETBSD || GTEST_OS_FUCHSIA ||
\
GTEST_OS_DRAGONFLY || GTEST_OS_GNU_KFREEBSD || GTEST_OS_OPENBSD ||
\
- GTEST_OS_HAIKU)
+ GTEST_OS_HAIKU || GTEST_OS_GNU_HURD)
#endif // GTEST_HAS_PTHREAD
#if GTEST_HAS_PTHREAD
@@ -603,7 +604,8 @@ typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION;
(GTEST_OS_WINDOWS_DESKTOP && _MSC_VER) || GTEST_OS_WINDOWS_MINGW || \
GTEST_OS_AIX || GTEST_OS_HPUX || GTEST_OS_OPENBSD || GTEST_OS_QNX || \
GTEST_OS_FREEBSD || GTEST_OS_NETBSD || GTEST_OS_FUCHSIA || \
- GTEST_OS_DRAGONFLY || GTEST_OS_GNU_KFREEBSD || GTEST_OS_HAIKU)
+ GTEST_OS_DRAGONFLY || GTEST_OS_GNU_KFREEBSD || GTEST_OS_HAIKU || \
+ GTEST_OS_GNU_HURD)
# define GTEST_HAS_DEATH_TEST 1
#endif
@@ -623,7 +625,8 @@ typedef struct _RTL_CRITICAL_SECTION GTEST_CRITICAL_SECTION;
// Determines whether test results can be streamed to a socket.
#if GTEST_OS_LINUX || GTEST_OS_GNU_KFREEBSD || GTEST_OS_DRAGONFLY || \
-GTEST_OS_FREEBSD || GTEST_OS_NETBSD || GTEST_OS_OPENBSD
+GTEST_OS_FREEBSD || GTEST_OS_NETBSD || GTEST_OS_OPENBSD || \
+GTEST_OS_GNU_HURD
# define GTEST_CAN_STREAM_RESULTS_ 1
#endif
diff --git a/googletest/src/gtest-port.cc b/googletest/src/gtest-port.cc
index 3f39f71c..989c59ae 100644
--- a/googletest/src/gtest-port.cc
+++ b/googletest/src/gtest-port.cc
@@ -98,7 +98,7 @@ const int kStdOutFileno = STDOUT_FILENO;
const int kStdErrFileno = STDERR_FILENO;
#endif // _MSC_VER
-#if GTEST_OS_LINUX
+#if GTEST_OS_LINUX || GTEST_OS_GNU_HURD
namespace {
template
diff --git a/googletest/test/googletest-port-test.cc
b/googletest/test/googletest-port-test.cc
index 4a87df0b..e3ad4dde 100644
--- a/googletest/test/googletest-port-test.cc
+++ b/googletest/test/googletest-port-test.cc
@@ -280,7 +280,7 @@ TEST(FormatCompilerIndependentFileLocationTest,
FormatsUknownFileAndLine) {
#if GTEST_OS_LINUX || GTEST_OS_MAC || GTEST_OS_QNX || GTEST_OS_FUCHSIA || \
GTEST_OS_DRAGONFLY || GTEST_OS_FREEBSD || GTEST_OS_GNU_KFREEBSD || \
-GTEST_OS_NETBSD || GTEST_OS_OPENBSD
+GTEST_OS_NETBSD || GTEST_OS_OPENBSD || GTEST_OS_GNU_HURD
void* ThreadFunc(void* data) {
internal::Mutex* mutex = static_cast(data);
mutex->Lock();
diff --git a/googletest/test/gtest_help_test.py
b/googletest/test/gtest_help_test.py
index 8d953bbd..54d45047 100755
--- a/googletest/test/gtest_help_test.py
+++
Bug#992759: nmu: tagua_1.0~alpha2-16-g618c6a0-3
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, please rebuild tagua in unstable against the libkdegames recently uploaded. tagua builds fine with the newer libkdegames. nmu tagua_1.0~alpha2-16-g618c6a0-3 . ANY . unstable . -m "rebuild for libkdegames 21.08.0 (libkf5kdegamesprivate7)" Thanks, -- Pino
Bug#992758: nmu: calamares_3.2.36-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, please rebuild calamares in unstable against the newer kpmcore recently uploaded. calamares builds fine with the newer kpmcore. nmu calamares_3.2.36-1 . ANY . unstable . -m "rebuild against kpmcore 21.08.0 (libkpmcore11)" Thanks, -- Pino
Bug#992757: nmu: qtwebview-opensource-src_5.15.2-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, please rebuild qtwebview-opensource-src in unstable for the new qtwebengine 5.15.5 recently uploaded, so it depends on the new internal ABI dependency. qtwebview builds fine with the newer qtwebengine. nmu qtwebview-opensource-src_5.15.2-2 . ANY . unstable . -m "rebuild with qtwebengine-opensource-src 5.15.5 (qtwebengine-abi-5-15-5)" Thanks, -- Pino
Bug#992697: RM: cantor [armel ppc64el s390x] -- ROM; requires QtWebEngine
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: debian-qt-...@lists.debian.org Hi, the new version of src:cantor requires QtWebEngine for the main interface: as result, it is built only on few architectures. Hence, please remove cantor on the following architectures: armel ppc64el s390x Thanks, -- Pino
Bug#981515: kcoreaddons: please replace fam with gamin
block 981515 by 510368 thanks Hi, In data venerdì 20 agosto 2021 13:32:08 CEST, Chris Hofstaedtler ha scritto: > given we are now in the bookworm cycle - do you think kcoreaddons > could remove fam (or replace it with gamin if really needed)? As I wrote a couple of times in this bug already: #510368 must be fixed first. It seems like I forgot to set this dependency, so I'm adding it now. Also, considering that there is a huge queue of RM bugs on the FTP-masters side that have been attended so far a couple of times in this year (sigh), rushing this won't make any change, since the RM will be ignored for some time anyway. Also #2: considering that we are not even a week since the lift of the freeze and everybody and their dogs have already uploaded things of every sort of unstable, please give (me) some time for what is really not a priority. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#989007: usermode: please drop the custom XPM pixmaps
Package: usermode Version: 1.114-1 Severity: wishlist Tags: patch Hi, the Debian packaging converts 3 PNG icons to XPM pixmaps; they were used in the past by the Debian menu files, which were removed with version 1.109-1. Hence, there is no more need to convert them, dropping also the netpbm build dependency. Attached patch for this. Thanks, -- Pino >From 269b6b62379239e816e8a1fc2f0cc7e0f796f6d1 Mon Sep 17 00:00:00 2001 From: Pino Toscano Date: Sun, 23 May 2021 10:56:45 +0200 Subject: [PATCH] stop generating custom XPM pixmaps, as were only used with old Debian menu files (dropped in 1.109-1); drop netpbm B-D, no more needed --- debian/clean| 3 --- debian/control | 1 - debian/rules| 7 +-- debian/usermode.install | 1 - 4 files changed, 1 insertion(+), 11 deletions(-) delete mode 100644 debian/clean delete mode 100644 debian/usermode.install diff --git a/debian/clean b/debian/clean deleted file mode 100644 index 25ccdef..000 --- a/debian/clean +++ /dev/null @@ -1,3 +0,0 @@ -debian/disks.xpm -debian/password.xpm -debian/user_icon.xpm diff --git a/debian/control b/debian/control index ed9e78e..c9ecc0f 100644 --- a/debian/control +++ b/debian/control @@ -14,7 +14,6 @@ Build-Depends: libsm-dev, libuser1-dev, libxml-parser-perl, - netpbm, Rules-Requires-Root: no Standards-Version: 4.4.1 Homepage: https://pagure.io/usermode/ diff --git a/debian/rules b/debian/rules index d25cdb0..f8591a9 100755 --- a/debian/rules +++ b/debian/rules @@ -25,7 +25,7 @@ override_dh_auto_configure: MKFS=/sbin/mkfs \ FDFORMAT=/usr/bin/fdformat -override_dh_install: user_icon.xpm password.xpm disks.xpm +override_dh_install: dh_install # this functionality doesn't appear to be supported in Debian rm $(DEBDIR)/usr/bin/pam-panel-icon $(DEBDIR)/usr/share/pixmaps/badge-small.png @@ -40,10 +40,5 @@ override_dh_fixperms: dh_fixperms chmod 04755 $(DEBDIR)/usr/sbin/userhelper -%.xpm : %.png - pngtopnm -alpha $< | pnmscale -xysize 32 32 > debian/alpha.pnm - pngtopnm $< | pnmscale -xysize 32 32 | ppmtoxpm -alphamask=debian/alpha.pnm > debian/$@ - rm debian/alpha.pnm - override_dh_missing: dh_missing --fail-missing diff --git a/debian/usermode.install b/debian/usermode.install deleted file mode 100644 index e95a7b7..000 --- a/debian/usermode.install +++ /dev/null @@ -1 +0,0 @@ -debian/user_icon.xpm debian/password.xpm debian/disks.xpm usr/share/pixmaps -- 2.30.2
Bug#989005: RM: aewm -- RoQA; dead upstream; unmaintained; very low popcon
Package: ftp.debian.org
Severity: normal
Hi,
aewm has not seen a new upstream release since 2007, and upstream
seems to have stopped working on it long long time ago.
Furthermore:
- the upstream website is not available anymore
- I cannot find anywhere a potential repository that continues the
development
- it has been "maintained" in Debian with NMUs/QA uploads since 2011
- uses old tech/libs (GTK+ 2)
- it has a very low popcon count (38 at the time I'm writing this)
- plenty of alternatives ("minimalist/lightweights" WMs) exist
Hence, it looks to me it would be a better idea to simply remove aewm
from Debian.
Thanks,
--
Pino
Bug#988544: RM: bbmail -- RoQA; dead upstream; unmaintained; very low popcon
Package: ftp.debian.org Severity: normal Hi, bbmail has not seen a new upstream release since 2007, and upstream seems to have stopped working on bbtools long long time ago. Furthermore, bbmail was orphaned 5 years ago (see #832561), and at the time of this writing has a popcon count of 14. Hence, it looks to me it would be a better idea to simply remove bbmail from Debian, as I'm sure alternatives to this exist and are more maintained. Please also close #832561 when RM'ing bbmail. Thanks, -- Pino
Bug#988541: RM: keytouch-editor -- RoQA; dead upstream; useful only for dead software
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: lcy...@gmail.com Hi, keytouch-editor is an editor for creating files for keytouch [1]. keytouch was removed from Debian 10 years ago (!) (see #632110 [2]) because it was broken, and not receiving any maintainer attention anymore. keytouch-editor thus is somehow of not much of use in Debian; furthermore, it has not been developed upstream for a decade as well, and it has not been maintained in Debian either. Hence, I think it is a better idea to remove also keytouch-editor from Debian. [1] https://tracker.debian.org/pkg/keytouch [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=632110 Thanks, -- Pino
Bug#988272: xsane: improve the installation of files in binary packages
Source: xsane
Version: 0.999-11
Severity: minor
Tags: patch
Hi,
currently, the Debian build scripts (rules & debhelper files) ship only
some of the files installed by upstream, and copy manually a couple
more; this results in lack of files producing issues like #963185.
To improve the situation, IMHO the best approach is to ship everything
that upstream installs, and at most do few tweaks like the location of
the documentation, or avoid a full GPL copy. The attached patch does
this job; copying from the changelog:
* Improve the general installation, also to properly install all the files
provided by upstream and avoid issues like #963185:
- ship the complete /usr/share/sane/xsane directory in xsane-common, rather
than copying one specific file in xsane: this way nothing is missed
- replace the xsane-gpl.txt file with a symlink to the GPL 2 file in
/usr/share/common-licenses; xsane shows it in an about dialog
- add a lintian override for /usr/share/sane/xsane/xsane-eula.txt, as xsane
shows it in the about eula dialog
- keep relocating the documentation from /usr/share/sane/xsane/doc to
/usr/share/doc/xsane-common/html with symlinks for xsane
- move/install the application icons, and the custom OCR scripts from xsane
to xsane-common, as they are shared data
- stop manually installing xsane.xpm, and xsane.png, as the XPM icon is
already installed by upstream
- add proper breaks/replaces in xsane-common because of the files moved
from xsane
- drop debian/not-installed, as everything from upstream is installed now
- drop debian/xsane-common.docs, as there are no separate documentation
files to copy manually
- drop debian/xsane.dirs, as dh_install creates all the missing directories
As result of shipping exactly what upstream installs, there is also a
reduction in the installed sizes of the xsane, and xsane-common
binaries:
- xsane (on amd64): before is 2346 kb, after is 1630 kb
- xsane-common: before is 5522 kb, after is 4498 kb
Thanks,
--
Pino
diff -Nru xsane-0.999/debian/changelog xsane-0.999/debian/changelog
--- xsane-0.999/debian/changelog2021-05-04 14:31:47.0 +0200
+++ xsane-0.999/debian/changelog2021-05-09 08:16:22.0 +0200
@@ -1,3 +1,29 @@
+xsane (0.999-12) UNRELEASED; urgency=medium
+
+ [ Pino Toscano ]
+ * Improve the general installation, also to properly install all the files
+provided by upstream and avoid issues like #963185:
+- ship the complete /usr/share/sane/xsane directory in xsane-common, rather
+ than copying one specific file in xsane: this way nothing is missed
+- replace the xsane-gpl.txt file with a symlink to the GPL 2 file in
+ /usr/share/common-licenses; xsane shows it in an about dialog
+- add a lintian override for /usr/share/sane/xsane/xsane-eula.txt, as xsane
+ shows it in the about eula dialog
+- keep relocating the documentation from /usr/share/sane/xsane/doc to
+ /usr/share/doc/xsane-common/html with symlinks for xsane
+- move/install the application icons, and the custom OCR scripts from xsane
+ to xsane-common, as they are shared data
+- stop manually installing xsane.xpm, and xsane.png, as the XPM icon is
+ already installed by upstream
+- add proper breaks/replaces in xsane-common because of the files moved
+ from xsane
+- drop debian/not-installed, as everything from upstream is installed now
+- drop debian/xsane-common.docs, as there are no separate documentation
+ files to copy manually
+- drop debian/xsane.dirs, as dh_install creates all the missing directories
+
+ -- Jörg Frings-Fürst Sun, 09 May 2021 08:16:22 +0200
+
xsane (0.999-11) experimental; urgency=medium
* Fix FTBFS on hppa (Closes: #987841).
diff -Nru xsane-0.999/debian/control xsane-0.999/debian/control
--- xsane-0.999/debian/control 2021-05-02 19:13:09.0 +0200
+++ xsane-0.999/debian/control 2021-05-09 08:16:22.0 +0200
@@ -59,6 +59,10 @@
Multi-Arch: foreign
Depends: ${misc:Depends}
Recommends: xsane
+Breaks:
+ xsane (<< 0.999-11~),
+Replaces:
+ xsane (<< 0.999-11~),
Description: xsane architecture independent files
xsane can be run as a stand-alone program or through the GIMP image
manipulation program. In stand-alone mode, xsane can save an image
diff -Nru xsane-0.999/debian/not-installed xsane-0.999/debian/not-installed
--- xsane-0.999/debian/not-installed2020-08-24 21:25:26.0 +0200
+++ xsane-0.999/debian/not-installed1970-01-01 01:00:00.0 +0100
@@ -1,155 +0,0 @@
-usr/share/pixmaps/xsane.xpm
-usr/share/applications/xsane.desktop
-usr/share/sane/xsane/xsane-logo.xpm
-usr/share/sane/xsane/sane-xsane-logo.xpm
-usr/share/sane/xsane/sane-umax-logo.xpm
-usr/share/sane/xsane/sane-hp-logo.xpm
-usr/share/sane/xsane/sane-epson-logo.xpm
-usr/share/sane/xsane/UMAX-logo.xpm
-usr/share/sane/xsane/Plustek-logo.xpm
-usr/share/s
Bug#987873: RM: gadmintools-meta -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Control: block -1 by 987867 987868 987869 987870 987871 987872 Hi, please remove gadmintools-meta from Debian. It provides a metapackage to install the GAdmintools, which are requested to be removed from Debian as long dead upstream and unmaintained (and broken); see the following bugs: #987867, #987868, #987869, #987870, #987871, #987872 Thanks, -- Pino
Bug#987872: RM: gadmin-samba -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-samba from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987871: RM: gadmin-rsync -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-rsync from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987870: RM: gadmin-proftpd -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-proftpd from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. In addition, it appears to have been unusable in Debian for some years already, see #612037. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987869: RM: gadmin-openvpn-server -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-openvpn-server from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. In addition, it appears to have been unusable in Debian for some years already, see #768663 and #602870. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987868: RM: gadmin-openvpn-client -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-openvpn-client from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987867: RM: gadmin-bind -- RoQA; long dead upstream; unmaintained in Debian; uses old tech/libs
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: udi...@ubuntu.com Hi, please remove gadmin-bind from Debian. It is part of the GAdmintools that appears to be long unmaintained upstream (the last version is more than 7 years old), with even the webpages [1][2] as either squatted (see #668245, #692158) or unavailable. It was orphaned by Daniel Baumann more than 10 years ago, and it had practically no maintainer uploads since then. Furthermore, it uses old technologies (GTK+ 2) not supported anymore. The only reverse dependency is the gadmintools metapackage, whose removal (together with the other GAdmintools) will be filed shortly. [1] http://www.gadmintools.org/ [2] http://dalalven.dtdns.net/linux/gadmintools-webpage Thanks, -- Pino
Bug#987864: RM: trovacap -- RoQA; long dead upstream; partially obsolete data
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: da...@debian.org Hi, trovacap is an application that ships an offline list of all the Italian CAPs (that is, the Italian ZIP codes). The first problem is that upstream is long gone: the last release was done more than 10 years ago, and since then even the upstream web site vanished (apparently with no public code hosting nowhere else like github/gitlab/etc). The second, IMHO bigger issue, is that the list of known CAPs is shipped statically in the sources, and it was not kept up-to-date. Yes, there were changes in the CAPs in Italy in the last decade, at least 300 from from a quick search; while they don't seem too many compared to the list of municipalities, IMHO providing a wrong data to the user (especially for something important like sending mail) is not a good idea. Hence, I rather prefer to remove trovacap altogether than shipping an unmaintained and partially outdated application. CCing the maintainer for his opinion. Thanks, -- Pino
Bug#987078: usbview: Remove duplicated files from upstream, and files no more needed
Source: usbview
Version: 2.0-21-g6fe2f4f-2
Severity: wishlist
Tags: patch
Hi,
the current debian directory ships some file that shadows files provided
by upstream (e.g. the desktop file and the icons), and ships some files
that are not needed. Hence, the provided patch simplify things a bit:
- drop our own icons, as upstream now installs all the XDG icon themes
icons properly (PNG and SVG)
- drop the old Debian menu file, as a desktop file is provided, so by
Policy the menu file ought to not be shipped; furthermore, the old
menu system has been deprecated for 6 years
- use su-to-root in the desktop file as a patch rather than using a copy
of it: this reduces the maintenance cost, and it clearly separates
the changes applied to it
- use a debian/upstream/metadata file to reference the upstream Git
repository, according to DEP 12 (replacing the X- field)
The debdiff between a rebuild of 2.0-21-g6fe2f4f-2 and the provided
2.0-21-g6fe2f4f-3 is the following:
Files in first .deb but not in second
-
-rw-r--r-- root/root /usr/share/icons/hicolor/32x32/apps/usbview.xpm
-rw-r--r-- root/root /usr/share/menu/usbview
-rwxr-xr-x root/root DEBIAN/postinst
-rwxr-xr-x root/root DEBIAN/postrm
Control files: lines which differ (wdiff format)
Installed-Size: [-1201-] {+1191+}
Version: [-2.0-21-g6fe2f4f-2-] {+2.0-21-g6fe2f4f-3+}
Which is expected, as the XPM icon and the old Debian menu are to not
be shipped anymore.
Of course, I'm available to edit any part of it -- I personally see
these changes as improvement and cleanups.
Thanks,
--
Pino
diff -Nru usbview-2.0-21-g6fe2f4f/debian/changelog
usbview-2.0-21-g6fe2f4f/debian/changelog
--- usbview-2.0-21-g6fe2f4f/debian/changelog2018-06-04 11:52:41.0
+0200
+++ usbview-2.0-21-g6fe2f4f/debian/changelog2021-04-17 10:41:34.0
+0200
@@ -1,3 +1,19 @@
+usbview (2.0-21-g6fe2f4f-3) UNRELEASED; urgency=medium
+
+ [ Pino Toscano ]
+ * Drop debian/usbview.manpages, as upstream already installs the man page.
+ * Drop menu file, as usbview already provides a .desktop file.
+ * Drop our own copy of usbview.svg, as it is provided by upstream already.
+ * Stop manually convering icons, as upstream already installs all the needed
+hicolor icons.
+ * Make the usage of su-to-root for the desktop file as patch to the desktop
+file provided by upstream, rather than as fork of that file; this way,
+there is no need to maintain it.
+ * Create a debian/upstream/metadata with references to the upstream Git
+repository, removing the X-Vcs-Upstream-Git field from debian/control.
+
+ -- Mark Brown Sat, 17 Apr 2021 10:41:34 +0200
+
usbview (2.0-21-g6fe2f4f-2) unstable; urgency=low
* Add build dependency on librsvg2-bin since the imagemagick
diff -Nru usbview-2.0-21-g6fe2f4f/debian/clean
usbview-2.0-21-g6fe2f4f/debian/clean
--- usbview-2.0-21-g6fe2f4f/debian/clean2017-02-04 12:24:38.0
+0100
+++ usbview-2.0-21-g6fe2f4f/debian/clean1970-01-01 01:00:00.0
+0100
@@ -1 +0,0 @@
-debian/icons/*/*
diff -Nru usbview-2.0-21-g6fe2f4f/debian/control
usbview-2.0-21-g6fe2f4f/debian/control
--- usbview-2.0-21-g6fe2f4f/debian/control 2018-06-04 11:52:41.0
+0200
+++ usbview-2.0-21-g6fe2f4f/debian/control 2021-04-17 10:41:34.0
+0200
@@ -6,7 +6,6 @@
Homepage: http://www.kroah.com/linux-usb/
Build-Depends: debhelper (>= 9), dh-autoreconf, autoconf-archive,
imagemagick, libmagickcore-6.q16-2-extra, libgtk-3-dev, librsvg2-bin
-X-Vcs-Upstream-Git: git://github.com/gregkh/usbview.git
Package: usbview
Architecture: any
diff -Nru usbview-2.0-21-g6fe2f4f/debian/patches/desktop-use-su-to-exec.diff
usbview-2.0-21-g6fe2f4f/debian/patches/desktop-use-su-to-exec.diff
--- usbview-2.0-21-g6fe2f4f/debian/patches/desktop-use-su-to-exec.diff
1970-01-01 01:00:00.0 +0100
+++ usbview-2.0-21-g6fe2f4f/debian/patches/desktop-use-su-to-exec.diff
2021-04-17 10:41:34.0 +0200
@@ -0,0 +1,15 @@
+Author: Mark Brown
+Description: Make desktop entry use su-wrapper.
+Last-Update: 2015-04-25
+
+--- a/usbview.desktop
b/usbview.desktop
+@@ -2,7 +2,7 @@
+ Name=USBView
+ GenericName=USB Device Viewer
+ Comment=View USB devices attached to system
+-Exec=pkexec /usr/bin/usbview
++Exec=su-to-root -X -c /usr/bin/usbview
+ Icon=usbview
+ Terminal=false
+ Type=Application
diff -Nru usbview-2.0-21-g6fe2f4f/debian/patches/series
usbview-2.0-21-g6fe2f4f/debian/patches/series
--- usbview-2.0-21-g6fe2f4f/debian/patches/series 1970-01-01
01:00:00.0 +0100
+++ usbview-2.0-21-g6fe2f4f/debian/patches/series 2021-04-17
10:41:34.0 +0200
@@ -0,0 +1 @@
+desktop-use-su-to-exec.diff
diff -Nru usbview-2.0-21-g6fe2f4f/debian/rules
usbview-2.0-21-g6fe2f4f/debian/rules
--- usbview-2.0-21-g6fe2f4f/debian/rules2017-02-04 12:24:38.0
+0100
+++ usbview-2.0-21-g6fe2f4f/deb
Bug#983597: [PATCH] Segfault in libqt5quick5.so: QQuickItemLayer::~QQuickItemLayer()
Hi Dennis,
In data venerdì 26 febbraio 2021 22:48:43 CET, Dennis Filder ha scritto:
> If you decide to use the attached patch, please put the bugnumber in
> the Bug-Debian: field for me.
The patch you provided is the following:
--- qtdeclarative-opensource-src-5.15.2+dfsg/src/quick/items/qquickitem.cpp
2021-02-26 18:48:50.407487828 +0100
+++ qtdeclarative-opensource-src-5.15.2+dfsg/src/quick/items/qquickitem.cpp
2021-02-26 18:48:52.711491373 +0100
@@ -8335,8 +8335,8 @@
QQuickItemLayer::~QQuickItemLayer()
{
-delete m_effectSource;
-delete m_effect;
+if (m_effectSource) delete m_effectSource; // FIXME: consider Q_ASSERT()
here instead
+if (m_effect) delete m_effect; // FIXME: consider Q_ASSERT() here instead
}
/*!
Did you actually check that it fixes the problem for you?
The thing is, in C++ (at least since C++98) the delete operator is
defined to be a no-op for a null pointer, much like free() in C.
Hence, constructs like "if (foo) delete foo;" are essentially doing
null pointer checks twice, and with the same no-op result.
A possible cause of the crash could be that the item being deleted was
already deleted, and thus there was a stale pointer somewhere. That is
my own speculation though.
Because of this, I'm inclined to remove the "patch" tag from this bug;
I'd like to hear from Dmitry what he thinks about it (since he already
handled this bug).
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#981515: kcoreaddons: please replace fam with gamin
In data venerdì 5 marzo 2021 18:16:18 CET, Glenn Strauss ha scritto: > On Fri, Mar 05, 2021 at 05:12:17PM +0100, Pino Toscano wrote: > > > Personally, I'd argue that switching the FAM implementation across the > > distribution _is_ a "transition", and as such it ought to have been > > requested (if not even started) two months ago. > > In July 2020, #966273 was filed: RFA: fam -- File Alteration Monitor > > I posted in October 2020 on that bug where FAM was abandoned. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15 > Debian developers did not suggest "next steps" for over 3 months, > until the freeze occurred. > > The bug was not touched by a Debian Developer until 31 Jan 2021. This message was addressed only to bugs, one of them was assigned to "wnpp" and the other to libgamon0: this means that only the gamin maintainer (1 specific person, as there is no group maintenance) and who watches the bugs of wnpp and src:gamin actually read it. Becuase of this, its audience was limited, and neither the general list for Debian development (debian-devel) nor the release team (release-team) were notified/aware of it by default. I can understand your frustation, but that is not a reason to rush things just because of this. All the deadline for Debian releases have been more or less streamlined/standardized for at least the past 2 stable releases already, so every step is well known in advance. Because of this, for example, we were not able to provide Plasma 5.12 in Bullseye. > The solution is to remove FAM. And nobody, really, *nobody* ever said the opposite, so please stop repeating that it is not wanted. > Back on topic: > > If you take a moment to look in the kcoreaddons code, you can see that > kcoreaddons has multiple mechanisms for filesystem notification. > If FAM interfaces fail for any reason, kcoreaddons switches to an > alternative mechanism. > > https://invent.kde.org/frameworks/kcoreaddons/-/blob/master/src/lib/io/kdirwatch.cpp#L1611 > > Therefore, your FUD is unsubstantiated. Changing kcoreaddons to use > gamin, or to not use FAM or gamin, are both reasonable options. > As I posted in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#49 > gamin can be configured to poll NFS locations and so is a reasonable > substitution for FAM, not limited to inotify() as Sune suggested in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=981515#39 Sure, I well know that KDirWatch in kcoreaddons builds fine with either libfam or gamin as "FAM", I remember people doing this many years ago in other distributions. However, what I said is something completely different, let me summarize it in short points for easier understanding: - I am fine switching from libfam to gamin in the future - I am fine dropping libfam from Debian in the future - I want first libgamin to stop providing libfam - switching from libfam from gamin *is* switching FAM implementation, and thus which code is used for "FAM", and possibily different bugs; hence, this is *too late* to properly test is in Bullseye There is no FUD in what I said. > It is true that this relatively safe change is being requested during > the soft freeze and so should be scrutinized. However, that does not > make the requested change any more or less dangerous. It does mean > less time to test by people who, in your own words, might not be using > this feature: > > and these FAM/gamin bits do not get much of use these days So if, "less time to test by people who [...] might not be using this feature", this switch is even more dangerous. Thanks from proving my point. > I posit that the code in upstream kcoreaddons is already better tested > than would be Debian "testing" (existence in tree?) of an additional > month or two or three of the Debian kcoreaddons package configured to > use gamin (or to use neither FAM nor gamin). This "additional month or two or three" we are talking about is called "Debian freeze". Dependency changes like this are very much *not* the kind of changes we want to introduce during a freeze. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981515: kcoreaddons: please replace fam with gamin
Dear Glenn, In data venerdì 5 marzo 2021 16:41:40 CET, Glenn Strauss ha scritto: > In #981513, courier changed to use libgamin-dev, so > kcoreaddons is now the *only* remaining package using FAM. > > As such, there is considerably more risk to doing nothing > than there is to migrating to gamin. No, there is more risk in switching to a different library at this phase of the Debian freeze. > ==> Please change kcoreaddons to use libgamin-dev for Bullseye. > https://salsa.debian.org/qt-kde-team/kde/kcoreaddons/-/merge_requests/3 While I understand your motivation behind this change, I'll repeat once again what I said previously in this bug: this is *not* going to happen for Bullseye, full stop. The reason is that we are talking about switching to a different library for a functionality that is rarely used these days (but potentially can be), hence a switch at this phase is very risky, and gives basically no time to test or even get feedback about it. The freeze for transitions started almost two months ago, on January 13th: https://lists.debian.org/debian-devel-announce/2021/01/msg2.html Personally, I'd argue that switching the FAM implementation across the distribution _is_ a "transition", and as such it ought to have been requested (if not even started) two months ago. On February 13th, a "mild freeze" started: https://lists.debian.org/debian-devel-announce/2021/02/msg2.html while changes at the beginning of it still migrated to testing, IMHO the switch of a dependency raises the bar of the risk; while I can check it for things I upload and work for, this feature represents something corner-case, which I don't have neither the setup nor the time to properly test. This request was opened at the end of January (so in transition freeze already, and IMHO enough to make it out of scope for Bullseye), and my question about the timing for this got "not for Bullseye" as answer. All the more traffic for you, Glenn, started two days ago, already in a time frame where uploads to unstable will not migrate to testing anymore [1], and thus it will need exception from release-team, meaning it has to be something importat/serious enough (and this is not, as the status of it would be the same as in previous Debian releases). [1] automatic migration ends on March 13th, and the default migration time is 10 days, which means the last day for such uploads was March 2nd Moreover, I already stated that I really want #510368 fixed _before_ switching the dependency, and that bug has not been fixed yet (and unlikely to be for Bullseye). So, thanks again for the time and interest in this, but this will be handled only after both a) Bullseye is released b) #510368 is fixed. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#983680: RM: kcm-ufw/experimental -- RoQA; dead upstream; depends on removed KDE 4 libraries
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: sh...@sorbom.com Hi, please remove kcm-ufw from Debian (currently only in experimental). The last release upstream was more than 7 years ago, and it has seen basically no development since then. Furthermore, it was based on the KDE libraries 4.x, which were removed from Debian, so this source cannot be build anymore. Thanks, -- Pino
Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon
In data giovedì 18 febbraio 2021 15:20:53 CET, Горбешко Богдан ha scritto: > I had checked the upstream repository before reporting this issue > (that's where I got the filename), it still contains this version of the > icon. Reporting here, because I couldn't find an issue tracker on KDE > GitLab. https://bugs.kde.org is the KDE upstream bug tracking system. Please report it there, rather than on a downstream bug tracking system. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#983042: kdeconnect: Please redesign the sc-apps-kdeconnectindicatordark icon
Hi Bohdan, In data giovedì 18 febbraio 2021 14:40:52 CET, Bohdan Horbeshko ha scritto: > Package: kdeconnect > Version: 20.04.3-1 > Severity: wishlist > > Dear Maintainer, > > the current icon looks very similar to a broken image icon. I thought it > was broken for several months, until I squinted and found out that × is > actually K. Though when I glance over it, I still subconciously percieve > it as a broken image icon. Please redesign it to something more contrast > and distinct; the light version of the icon does not have this issue. Please note that we do not do upstream development, and this kind of change (i.e. artwork) ought to be done by upstream, either in kdeconnect itself or in the breeze icon theme. Please note also: > Kernel: Linux 5.8.0-3-amd64 (SMP w/2 CPU threads) > Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_CRAP, > TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=ru_UA.UTF-8, LC_CTYPE=ru_UA.UTF-8 (charmap=UTF-8), > LANGUAGE=ru_UA:ru > Shell: /bin/sh linked to /bin/bash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages kdeconnect depends on: > ii kde-cli-tools 4:5.17.5-2 > ii kio 5.70.1-1 > ii libc6 2.31-3 > ii libfakekey0 0.3+git20170516-2 > ii libkf5configcore5 5.70.0-1 kernel 5.8.0, Frameworks 5.70, Plasma 5.17, and kdeconnect 20.04: your system is ~6 month behind of the current Debian testing. Please fully dist-update your system when reporting bugs for unstable or testing, as otherwise there is the risk of reporting stale issues. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#969907: Bug#969537: epdfinfo crashing with mismatched libpoppler102 and libpoppler-glib8
Hi Simon, In data lunedì 15 febbraio 2021 13:07:13 CET, Simon McVittie ha scritto: > Control: retitle 969907 epdfinfo crashing with mismatched libpoppler102 and > libpoppler-glib8 > Control: tags 969907 + patch > > Sorry, this reply should have gone to the clone in libpoppler-glib8, > not to the archived original bug in epdfinfo (which I don't think was > ever really an epdfinfo bug). > > On Mon, 15 Feb 2021 at 12:03:35 +, Simon McVittie wrote: > > I don't think this is actually about whether libpoppler-glib added new ABI > > without bumping the shlibs version - it has a .symbols file that tracks > > the version in which each public symbol was added. > > > > Instead, I think this is about private symbols and partial > > upgrades. libpoppler102 and libpoppler-glib8 come from the same > > source package, so libpoppler-glib8 is very likely to make assumptions > > about private implementation details of the corresponding version of > > libpoppler102; many of the source files glib/*.cc that get compiled into > > libpoppler-glib8 have #include "poppler-private.h". This is fine if > > everyone does an `apt upgrade` with no pinning, but breaks down if people > > do arbitrary partial upgrades with pinning or interactively (leading to a > > "Frankendebian" system). > > > > If the upstream developers of poppler are asked to support a system where > > libpoppler102 and libpoppler-glib8 are at different versions, I'm pretty > > sure the first thing they will say is "don't". I think the same is > > appropriate for downstreams. Yes, this is correct. > > In Cairo and Pango (which have a similar structure with multiple binary > > packages making use of each other's implementation details), I added a > > debian/shlibs.local to make sure the binary packages all get lockstep > > dependencies. I think the same technique would be appropriate here. See > > attached. I honestly do not understand how this is even a problem, considering I fixed this more than 5 years ago: https://salsa.debian.org/freedesktop-team/poppler/-/commit/7929aa2d5ec9464fea755f622319d224787c4110 and indeed: $ apt-cache show libpoppler-glib8 Package: libpoppler-glib8 Source: poppler Version: 20.09.0-3.1 [...] Depends: libpoppler102 (= 20.09.0-3.1), libc6 (>= 2.14), libcairo2 (>= 1.12.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2) [...] So the strict dependency is already in place. If I check the version that was reported in the bug report, I see: $ debsnap -d . libpoppler-glib8 -a amd64 0.85.0-2 $ dpkg -I libpoppler-glib8_0.85.0-2_amd64.deb Package: libpoppler-glib8 Source: poppler Version: 0.85.0-2 Depends: libpoppler95 (= 0.85.0-2), libc6 (>= 2.14), libcairo2 (>= 1.12.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.41), libstdc++6 (>= 5.2) I'd rather think that the situation happened because elpa-pdf-tools-server links both to libpoppler and libpoppler-glib: the rebuild against poppler 20.09.0 (i.e. libpoppler102) make elpa-pdf-tools-server link to libpoppler102 (forcing the newer dependency to it), and setting an old dependency for libpoppler-glib because there is no need for a newer version. This was also a problem in case there was an incomplete dist-upgrade to the newer poppler, so the newer libpoppler was pulled in but the newer libpoppler-glib not. I remember having seen this in the past (when I used to maintain poppler), but it happened once and indeed it was due to an incomplete dist-upgrade. IMHO this will not happen in oldstable->stable dist-upgrades, as everything will be build with the newer libraries, and hopefully the dist-upgrade will be done fully. Another contributing factor is that emacs-pdf-tools "abuses" the libpoppler-glib internals, see server/poppler-hack.cc. I don't know why it does that, and I'd rather see the actual issues fixed in libpoppler-glib. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981679: Closing as per reporter request
reopen 981679 thanks Hi, In data giovedì 11 febbraio 2021 10:18:14 CET, Aurélien COUDERC ha scritto: > control: fixed -1 4:5.6.2-4 > > Thanks for the follow up. > Closing as per your request. > > What I read from upstream git log is that the commit you mention is on master > and the fix was actually backported to the 5.6 branch as > 4688d626c145711e35f3676dbd4c827b3b2ea7f6. The upload of kdevelop 4:5.6.2-4 fixes what Justin reported, i.e. that the clang plugin cannot parse the clang version string in more recent Debian clang versions. The original problem, though, is totally different: the clang plugin hardcodes the clang include directory and the clang version and, while it appears to have some logic to handle runtime version bumps, it seems it cannot fully cope with this situation. It looks like there is no more issue simply because the upload of kdevelop 5.6.2 (starting with 4:5.6.2-1) rebuilds with the latest clang, so it makes the problem "go away" until the next time the default clang version (currently 11) is updated in Debian. Because of this, the actual problem reported in this bug report *is* still valid, and I hope upstream can do something about it so we (in Debian) don't get breakages on clang version bumps. Luckly, I did changes in the packaging so it is possible to binNMU (i.e. a plain no-changes rebuild) kdevelop in such situations, and the rebuilt kdevelop will not migrate to testing until the newer clang version migrated too; it is mostly a workaround though. Julien: while I thank you for spotting the issue with the parsing of clang version string, I strongly recommend you to report *new* bugs for problems different that what reported. It is always easier to merge bugs in case they are actually the same issue, while adding different and unrelated issues to a bug makes it really hard to properly track what is fixed and what is not. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#981515: kcoreaddons: please replace fam with gamin
In data lunedì 1 febbraio 2021 00:00:47 CET, Chris Hofstaedtler ha scritto: > Source: kcoreaddons > Version: 5.54.0-1 > > Dear Maintainer, > > your package currently Depends on libfam0 (fam), which has > been requested to be removed in #966273. Please switch to gamin > instead. You can find more info, and an analysis of what probably > needs to be done for your package in this message from Glenn Strauss: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=966273#15 I wouldn't say that gamin is more maintained than FAM: - on the upstream side (gnome.org), it was moved the "Archive" section of the gnome gitlab - during the migration to gitlab, all the bugzilla tickets were closed instead of migrated too, because the project is archived - on the Debian side, gamin saw 4 uploads (one of them is an NMU) in the last 10 years - #510368 prevents to switch from FAM to gamin, as it will build against libgamin but still pulling libfam (or keep an old libfam as valid package satisfying the dependency) > Severity of this bug will probably raise over time. What is "over time" implying, please? I really hope this is not for bullseye: we are so close to its freeze, and these FAM/gamin bits do not get much of use these days, so the risk of release regressions seems medium/high to me. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#980879: RM: libqinfinity/experimental -- ROM; dead upstream, unused
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: pkg-kde-ext...@lists.alioth.debian.org Hi, please remove libqinfinity from experimental (the only suite where it is now). The last release upstream was 0.5.2, released more than 7 years ago, and the project is archived upstream (on kde.org). There were and still are no users of it. Thanks, -- Pino
Bug#966036: kajongg: Uses old name of sip module
Hi Dmitry,
apparently I missed this sip-related bug.
In data mercoledì 22 luglio 2020 13:31:19 CET, Dmitry Shachnev ha scritto:
> Source: kajongg
> Version: 4:19.12.3-1
> Usertags: sip5
>
> Dear Maintainer,
>
> You are receiving this bug because your package seems to be using PyQt5
> and has Python files with "import sip" lines.
>
> With the latest version of PyQt5 in experimental, the private sip module
> used by PyQt5 is called "PyQt5.sip", not just "sip". I am going to upload
> this version to unstable around end of August.
>
> You may need to update your imports to do something like this:
>
> try:
> from PyQt5 import sip
> except ModuleNotFoundError:
> import sip
>
> Alternatively, you may import sip after importing PyQt5. So the following
> will work too:
>
> from PyQt5 import QtCore
> import sip
>
> Please see the following link for details:
>
> https://www.riverbankcomputing.com/static/Docs/PyQt5/incompatibilities.html#importing-the-sip-module
>
> If you use sip for reasons unrelated to PyQt5, you may leave the old import
> as is, but please bear in mind that sip4 is deprecated.
>
> Also, calls like "sip.setapi('QDate', 2)" are not needed at all with PyQt5.
> They were needed only with PyQt4 and Python 2. It is safe to delete them.
>
> For the actual documentation of sip module, see the following link:
>
> https://www.riverbankcomputing.com/static/Docs/PyQt5/api/sip/sip-module.html
It seems the sip-related bits are still the same. It looks to me that
sip is used for the following this:
1) sip.unwrapinstance()
2) sip.SIP_VERSION_STR (printed in the about dialog)
3) sip.cast()
I do not know whether it is possible to "do stuff" without using them;
would it be possible for you (not a priority though) to send patches
upstream in case?
https://invent.kde.org/games/kajongg
It definitely should be easier than with krita... ;-)
Thanks,
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#977814: fixed in llvm-toolchain-11 1:11.0.1-1
In data venerdì 8 gennaio 2021 12:38:20 CET, Gianfranco Costamagna ha scritto: > llvm-toolchain-11 is now fixed, and clazy should be fixed too. No, llvm-toolchain-11 is not fixed yet. > Unfortunately clazy seems to be missing a "break" relationship against old > llvm, and britney uses > the broken testing version to test it. It makes no sense for clazy to break and old llvm, it should be rather the other way round... but it shouldn't be needed. Also, the version in testing is *not* broken. clazy in testing is perfectly working, and it was the llvm-toolchain-11 upload that broke it. > I don't know if we can hint to let it migrate anyway, Considering nothing was actually done to fix the problems I reported earlier in this bug, I don't think that letting the newer llvm-toolchain-11 migrate and break also testing is an acceptable way forward. Even more so when there was *no* attempt by the Debian LLVM Maintainers (of which you are part) to debug what was the issue. All this "fix" did was to apply the diff I mentioned, which was to fix only a small part of the problems I reported. Also, reading it further, even the shlibs of all the other libraries need to be fixed: they all specify old versions (like 9~something) that are satisfied by any llvm-toolchain-11 version available, including prereleases. > Let me know if you have a solution for this issue, The Debian LLVM Maintainers ought to help debug why updating a new version suddently breaks software built against old versions of it. Sorry if I seem harsh: LLVM is a key component in a modern Debian system, so uploading new versions and providing almost no help on problems does not seem like a good idea for the distribution. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#979577: qtcreator: Clang Code Model no longer finds 'stddef.h' since version 4.14.0-2
In data venerdì 8 gennaio 2021 16:52:02 CET, Michael Weghorn ha scritto: > Package: qtcreator > Version: 4.14.0-2 > Severity: normal > X-Debbugs-Cc: m.wegh...@posteo.de > > Dear Maintainer, > > since version 4.14.0-2, Qt Creator's Clang Code Model is unable to find the > 'stddef.h' header. It still works OK with version 4.14.0-1. qtcreator 4.14.0-2 has been available in unstable (which you use) for more than two weeks, so reading this problem now seems slightly awkward. Have you used qtcreator 4.14.0-2 (and it code model) successfully so far in the past two weeks? My suspect is the upload of llvm-toolchain-11 done yesterday, and your package list: > ii libclang1-11 1:11.0.1-2 show you updated to it. Can you please try to backport your LLVM/Clang 11 packages to the same version used to build qtcreator? You can get the list of installed packages using: $ dpkg -l '*llvm*11*' | grep ^ii $ dpkg -l '*clang*11*' | grep ^ii and then use the `debsnap` tool, part of the devscripts package, to download them, e.g.: $ debsnap -d . -a amd64 libclang-11 1:11.0.1~+rc2-1 (you will need to repeat that for all the packages you have installed, removing the :amd64 suffix in the packages that have multi-arch annotations). Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever
In data domenica 27 dicembre 2020 03:53:01 CET, Jonas Smedegaard ha scritto: > Version: 9.53.3~dfsg-6 > > Quoting Pino Toscano (2020-12-22 10:08:12) > > In data lunedì 21 dicembre 2020 18:23:12 CET, Simon McVittie ha scritto: > > > > On my side, rebuilding libspectre1 solved this on my system. > > > > > > If a simple rebuild with no source changes fixes the symptoms of a > > > bug, that might indicate an unintended ABI break in libgs9, or > > > perhaps a bug in the old libgs9 headers (but fixed in the new > > > headers) in code that gets inlined into libspectre at compile time. > > > > Both of them are issues in ghostscript anyway. > > This was fixed in Ghostscript since release 9.53.3~dfsg-6 - I just > forgot to mention it in changelog (that will be corrected in next > release). Oh nice, I did not notice it. I can confirm that using - libgs9 9.53.3~dfsg-6 - libspectre1 0.2.9-1 - evince 3.38.0-3 there are no problems opening PS files in evince. Thanks! -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#966405: libopenbabel-dev: CMake files do not reflect installation paths
Hi Andrius,
In data martedì 28 luglio 2020 07:33:15 CET, mer...@debian.org ha scritto:
> Package: libopenbabel-dev
> Control: forwarded -1 https://github.com/openbabel/openbabel/issues/2264
> Control: block 951674 by -1
>
> Paths in OpenBabel3Config.cmake do not reflect real installation paths
> in Debian systems, at least OpenBabel3_EXPORTS_FILE, which is set to
>
> ${OpenBabel3_INSTALL_PREFIX}/lib/cmake/openbabel3/OpenBabel3_EXPORTS.cmake
>
> while it should be
>
> /usr/lib//cmake/openbabel3/OpenBabel3_EXPORTS.cmake
I took a bit of time to investigate and hopefully fix this issue. The
results are:
- https://github.com/openbabel/openbabel/pull/2315 for fixing the CMake
configuration files upstream (they needed a bit of massaging)
- https://salsa.debian.org/debichem-team/openbabel/-/merge_requests/5
to fix the library directory in Debian builds
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.
Bug#881761: signon-plugin-oauth2 FTCBFS: does not pass cross tools to qmake and other issues
Hi Helmut, In data martedì 14 novembre 2017 22:32:01 CET, Helmut Grohne ha scritto: > Source: signon-plugin-oauth2 > Version: 0.22-1 > Tags: patch > User: helm...@debian.org > Usertags: rebootstrap > > signon-plugin-oauth2 fails to cross build from source for multiple > reasons: > * It does not pass cross tools to qmake. This task can be easily >deferred to dh_auto_configure these days, but it doesn't fully work, >so in the best case dh_auto_build will fail until debhelper is fixed. This was a bug, even more problematic than just for cross-building. I included this part in my recent signon-plugin-oauth2 0.25-1 upload. > * It uses uname -m to discover the host cpu, but that returns the build >cpu of course. > * It uses plain pkg-config, which is the build architecture pkg-config >while the host architecture one was expected. These two look like genuine bugs as well. Can you please send them as merge requests to the upstream repository? https://gitlab.com/accounts-sso/signon-plugin-oauth2 Upstream accepts MRs, so it should be easy to send them patches. I'd rather not include patches downstream that are kept there forever, adding more work to the already small enough attention that this package (and other Accounts SSO packages) already gets... Thanks in advance, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#978199: [Pkg-kde-extras] Bug#978199: libqapt: FTBFS: pkgcachegen.h:32:10: fatal error: xxhash.h: No such file or directory
)’ is deprecated: Use > > QProcess::start(const QString , const QStringList > > ,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 , OpenMode mode = ReadWrite); > > | ^ > > In file included from /usr/include/apt-pkg/deblistparser.h:15, > > from /<>/src/dependencyinfo.cpp:24: > > /usr/include/apt-pkg/pkgcachegen.h:32:10: fatal error: xxhash.h: No such > > file or directory > >32 | #include > > | ^~ It looks like a bug in one of the public headers of libapt-pkg, and already fixed upstream: https://salsa.debian.org/apt-team/apt/-/commit/ece7f5bb0afee0994a4fb4380e756ce725fe67a9 APT developers: please mark this bug as fixed in changelog. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#978164: kguiaddons: FTBFS on non-linux
tag 978164 + pending thanks In data sabato 26 dicembre 2020 21:54:19 CET, Samuel Thibault ha scritto: > Source: kguiaddons > Version: 5.77.0-3 > Severity: important > Tags: patch > User: debian-h...@lists.debian.org > Usertags: hurd > > Hello, > > kguiaddons currently doesn't build on non-Linux, where Wayland is not > available. The attached patch fixes this. Yes, I know. I already fixed it few days ago: https://salsa.debian.org/qt-kde-team/kde/kguiaddons/-/commit/1130cd0d8f0c95c9536a74034826fbb0ed5f0d8c -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#941721: kde-standard: Cannot open the desktop settings dialog
reassign 941721 dde-qt5integration retitle 941721 crash in libdstyleplugin.so severity 941721 important thanks Hi, sorry for the late answer. In data venerdì 4 ottobre 2019 11:28:48 CET, Mebus ha scritto: > Package: kde-standard > Version: 5:102 > Severity: normal > > Hallo, > > when I open the desktop settings dialog the whole desktop seems to crash and > restart. It happens right after I right click on the desktop. I am expecting > the destkop settings dialog to appear. Let's see the crash report: [KCrash Handler] #6 0x7fbcc97dbdd0 in QWidget::style() const () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #7 0x7fbcc1c28efb in dstyle::Style::drawComboBoxLabelControl(QStyleOption const*, QPainter*, QWidget const*) const () from /usr/lib/x86_64-linux-gnu/qt5/plugins/styles/libdstyleplugin.so #8 0x7fbcc1c17636 in dstyle::Style::drawControl(QStyle::ControlElement, QStyleOption const*, QPainter*, QWidget const*) const () from /usr/lib/x86_64-linux-gnu/qt5/plugins/styles/libdstyleplugin.so #9 0x7fbcb83f4d84 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/libqtquickcontrolsplugin.so #10 0x7fbcb83f57ec in ?? () from /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Controls/libqtquickcontrolsplugin.so #11 0x7fbcca798573 in QQuickWindowPrivate::polishItems() () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #12 0x7fbcca7275b5 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #13 0x7fbcca728615 in ?? () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #14 0x7fbcc90771d5 in QWindow::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #15 0x7fbcca7a22db in QQuickWindow::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Quick.so.5 #16 0x7fbcc97b64b1 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #17 0x7fbcc97bd950 in QApplication::notify(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #18 0x7fbcc8cbd5a9 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #19 0x7fbcc906c203 in QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #20 0x7fbcc906cead in QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #21 0x7fbcc904706b in QWindowSystemInterface::sendWindowSystemEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Gui.so.5 #22 0x7fbcc34473eb in ?? () from /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #23 0x7fbcc8cbc27b in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #24 0x7fbcc8cc4262 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #25 0x55990a38d1ab in ?? () #26 0x7fbcc873209b in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #27 0x55990a38d62a in _start () [Inferior 1 (process 1318) detached] It seems like it crashed in libdstyleplugin.so, which is a Deepin DE style plugin. Hence, I'm reassigning this bug to dde-qt5integration; Thank you for your report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#974566: [Pkg-kde-extras] Bug#974566: Bug#974566: labplot: Labplot fails to perform curve fitting with custom functions
In data venerdì 25 dicembre 2020 18:20:54 CET, Volkov YO via pkg-kde-extras ha scritto: > According to upstream tracker, the bug is fixed in labplot-2.8.2 onwards. Yes, I know that. OTOH, labplot 2.8.2 has not been released yet. > Please bump the package when possible. "bump the package" does not make much sense, FYI. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977329: krita segfaults when try to open with libQt5Gui.so.5.15.1
reassign 977329 lxqt-qtplugin retitle 977329 lxqt-plugin: platform theme needs fixes for Qt 5.15 tag 977329 = fixed-upstream severity 977329 serious thanks Hi, In data giovedì 24 dicembre 2020 20:48:32 CET, proctor ha scritto: > hi! thanks very much for your help. > > the krita segfault still happens with all latest updates, including the > most recent kernel 5.9.0-5-amd64 > > krita crashes at open. when i select the krita program from the menu > nothing happens at all. > when i run like this: > $ krita > Segmentation fault > > that's what happens > > i'm using lxqt Thanks for the detail about this, and most probably you have lxqt-qtplugin installed, right? I see that the there were various fixes upstream related to the compatibility with Qt 5.15 and color palettes, and I would not be surprised that any of these issues would cause a crash: https://github.com/lxqt/lxqt-qtplugin/issues/54 https://github.com/lxqt/lxqt-qtplugin/pull/55 https://github.com/lxqt/lxqt-qtplugin/commit/8cc32d94b4c9de74b5bcf27fae2d10e6b2b11caf It looks like everything is included in the new upstream release 0.16.0, which then needs to be packaged in Debian. Another check you can do is try to run krita in a different desktop environment / window manager than LxQt. Hence, I'm reassigning this to lxqt-qtplugin with proper metadata. Thanks for your report, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#978028: opencv: FTBFS on architectures without java
Source: opencv
Version: 4.5.1+dfsg-1
Severity: important
Tags: patch
Hi,
opencv 4.5.1+dfsg-1 fails to build on architectures without Java
support, like hurd-i386 [1].
This is because the libopencv4.5-java binary was changed from arch:all
to arch:any in version 4.5.1+dfsg-1, so on architectures without Java
the files to install in libopencv4.5-java are not found.
The solution is to restrict the architecture of the libopencv4.5-java
binary to the same list of architectures of the other Java-related
binary, i.e. libopencv4.5-jni. Patch attached for this.
[1]
https://buildd.debian.org/status/fetch.php?pkg=opencv=hurd-i386=4.5.1%2Bdfsg-1=1608798863=0
Thanks,
--
Pino
--- a/debian/control
+++ b/debian/control
@@ -1106,7 +1106,7 @@ Description: computer vision contrlib li
recognition, camera calibration and 3D reconstruction.
Package: libopencv4.5-java
-Architecture: any
+Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el s390x alpha
ia64 m68k powerpc ppc64 riscv64 sh4 sparc64 x32
Multi-Arch: no
Section: java
Depends: libopencv4.5-jni (>= ${binary:Version}),
Bug#848180: konsole: Includes application name in window title when configured not to do so
reassign 848180 src:qtbase-opensource-src qtbase-opensource-src/5.7.1~20161021+dfsg-6 retitle 848180 setWindowTitle() includes application name in window title when configured not to do so thanks In data venerdì 23 dicembre 2016 16:36:15 CET, Maximiliano Curia ha scritto: > ¡Hola Aaron! > > El 2016-12-13 a las 19:49 -0500, Aaron Schrab escribió: > > Package: konsole > > Version: 4:16.08.3-1 > > Severity: minor > > > After unchecking the "Show application name on the titlebar" option in the > > Configure Konsole dialog it still inludes " - Konsole" at the end of window > > titles. This occurs even after closing all Konsole windows and restarting > > the > > application. > > > I first observed this with version 4:16.08.2-2 of both the konsole and > > konsole-kpart packages. I upgraded both of those to 4:16.08.3-1 from > > unstable > > to check if the issue was still present (and I again made sure to close all > > windows after the upgrade). Before I installed the version from testing > > yesterday I hadn't used this package in long time, so I can't say how long > > this > > bug has existed. > > I can reproduce the issue, this seems to be a issue in kxmlgui rather than > konsole. konsole calls setCaption or setPlainCaption depending on the value > of > the user setting, the first on documents that it would add the application > name, and the second one that it wouldn't, but sadly this is no longer true ( > since this was ported to qt5), as setCaption is implemented as a single call > to setPlainCaption (and the responsible for adding the application name in > the > title is the qt qpa plugin). > > The setCaption and setPlainCaption documentation can be seen here: > https://cgit.kde.org/kxmlgui.git/tree/src/kmainwindow.h > > While the implementation can be seen here: > https://api.kde.org/frameworks/kxmlgui/html/kmainwindow_8cpp_source.html > > The qt documentation for setWindowTitle can be found here: > http://doc.qt.io/qt-5/qwidget.html#windowTitle-prop > > kxmlgui is missing a way to workaround the setWindowTitle use of the qpa > plugin, this may need to be scale to qtbase. Indeed, this is a Qt limitation: https://bugreports.qt.io/browse/QTBUG-75535 Hence, reassigning to Qt 5. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#942129: kio: no multiarch support.
severity 942129 wishlist thanks Hi, In data giovedì 10 ottobre 2019 19:57:05 CET, peter green ha scritto: > While trying to install a kde app for a foreign architecture. I noticed that > while libkf5declarative5 is multi-arch: same it can only be installed for one > architecture at a time, because it depends on kio and kio has no multi-arch > field. > > Unfortunately it seems kio contains a bunch of stuff in architecture-specific > paths which look like they may be used from other packages, but also contains > native binaries in /usr/bin , so it seems adding multi-arch support would > require splitting the package. > > Thoughts? Multi-arch is in general not something upstream supports; we have some changes mostly related to cross-building, but otherwise anything beyond that is mostly "nice to have". Some of the KDE Frameworks (such as kio) also have runtime components/daemons that can spawn D-Bus services and/or load plugins. This makes the scenario you described above as hard to do, and (personally speaking) not something to invest into unless there is a strong demand for it. Hence, I'm lowering the severity of this to wishlist. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#897275: llvm-6.0 should provide a pkg-config file
affects 897275 - src:qtcreator thanks In data martedì 1 maggio 2018 10:22:36 CET, hai scritto: > Package: llvm-6.0 (currently src:llvm-11) > Filename: /usr/lib/llvm-6.0/bin/llvm-config > Forwarded: https://bugs.llvm.org/show_bug.cgi?id=9405 > Tags: upstream > User: helm...@debian.org > Usertags: rebootstrap > Control: affects -1 + src:qtcreator This does not affect qtcreator anymore: starting from 4.14.0-2, qtcreator is now built using cmake, and thus the cmake config files of llvm/clang are used to detect it. -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#947361: krita: Keyboard doesn't respond after some popups (f.e show color selector) are opened.
tag 947361 + moreinfo thanks Hi, In data mercoledì 25 dicembre 2019 18:45:19 CET, Fenix ha scritto: > Package: krita > Version: 1:4.2.8.2+dfsg-1 > Severity: normal > > Dear Maintainer, > > Krita seems to have problems with some popups docks, for example > color selector, minimal shade selector... After this controls are showed > if they are hidden just moving the pointer outside its domain, keyboard > doesn't respond anymore, unless you change to another program or window. > > Brush preset, for example, works fine. This type of popup are close > clicking outside and not just moving pointer outside. > > > * What led up to the situation? > > 1.- Create new image. > 2.- Open, for example, a color selector (Shift + I) > 3.- Select a color and move the cursor outside the selector. It > will be vanished. > 4.- Try to open again the color selector with Shift + I or made > something with keyboard: change to full screen, undo action (ctrl-z)... > 5.- The keyboard will not repond. > 6.- Change to another program and back to Krita (Krita must lost the > focus). > 7.- Try again show color selector (Shift + I). It will work again. > > > * What exactly did you do (or not do) that was effective (or > ineffective)? > > If enter key is pressed just before choosing color in color > selector and with the pointer inside the control (for not hide it), the > keyboard works fine: accept other shourtuts. But if the popup is hide > only moving the pointer outside its domain, the keyboard will be stucked > into Krita. And only come back after loosing the focus into another > program or window. Can you still reproduce the issue with a more recent version of krita, like krita 4.4.1 currently available in testing? If so, can you please report the bug to the upstream development team, as they have more expertise than me? See the following page: https://docs.krita.org/en/untranslatable_pages/reporting_bugs.html Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977329: krita segfaults when try to open with libQt5Gui.so.5.15.1
tag 977329 + moreinfo thanks Hi, In data lunedì 14 dicembre 2020 02:12:14 CET, proctor ha scritto: > Package: krita > Version: 1:4.4.1+dfsg-1+b1 > Severity: important > X-Debbugs-Cc: damonswir...@gmail.com > > Dear Maintainer, > > *** Reporter, please consider answering these questions, where appropriate *** > >* What led up to the situation? >* What exactly did you do (or not do) that was effective (or > ineffective)? >* What was the outcome of this action? >* What outcome did you expect instead? > > *** End of the template - remove these template lines *** > > > krita will not open. when i try i get this in dmesg and syslog > > [327378.536890] krita[1273329]: segfault at 0 ip 7efdeea7c190 sp > 7fff99cbf6f8 error 4 in libQt5Gui.so.5.15.1[7efdee9fe000+4c3000] > [327378.536895] Code: e0 10 48 09 f0 48 c1 e0 10 4c 09 e8 49 89 40 04 31 c0 > 66 41 89 40 0c 48 83 c4 18 4c 89 c0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 90 <48> > 8b 06 8b 56 08 48 89 07 89 57 08 f0 83 00 01 c3 90 66 66 2e 0f > > krita does work on a similar system but with AMD video card (this machine > has nvidia card) so maybe this is a video driver problem instead? is so let > me know and i will try to file this bug there instead! Unfortunately this dmesg line is not exactly useful, it merely says it crashed "somewhere" within QtGui. Do you still get a crash in an up-to-date testing installation? What where you doing when krita crashed? Which desktop environment or WM are you running? Are you running a Wayland session or an Xorg session? In case you still get a crash: please follow these two pages to install the debug packages for krita, and get a stack trace of the crash: https://wiki.debian.org/HowToGetABacktrace https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#955730: krita does not start under wayland
severity 955730 wishlist retitle 955730 krita does not support wayland forwarded 955730 https://bugs.kde.org/show_bug.cgi?id=429079 thanks Hi, In data sabato 4 aprile 2020 11:22:08 CET, Nicolas Évrard ha scritto: > I have started to use sway as my primary window manager unfortunately > krita does not work with wayland it seems. Other Qt applications seems > to work just find (provided I set the right environment variable ie > QT_QPA_PLATFORM=wayland) krita has never supported Wayland so far. It uses various X technologies (e.g. tablet support, color management) that are not available under Wayland, or nobody worked on them in krita. There is an upstream bug mentioning this: https://bugs.kde.org/show_bug.cgi?id=429079 starting from the upcoming version 4.4.2, you will even get an error message with krita closing itself afterwards in case you are running under Wayland. Please run krita within XWayland until proper Wayland support is implemented in krita. Thanks, -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#977992: hyphy: FTBFS on hurd-i386: wrong reference to the build directory
Source: hyphy Version: 2.5.18+dfsg-1 Severity: important Tags: patch User: debian-h...@lists.debian.org Usertags: hurd Hi, currently hyphy fails to build on hurd-i386 [1]. The problem is that, in the dh_auto_test override, the "obj-*-*-*" glob pattern is used to refer to the build directory. The default build directory for cmake is "obj-$DEB_HOST_GNU_TYPE", and considering that DEB_HOST_GNU_TYPE for hurd-i386 is "i686-gnu", then the pattern does not match the build directory. The fix is simple: use the right variable to refer directly to the build directory, with no need to use globbing at all. Patch attached for this. [1] https://buildd.debian.org/status/fetch.php?pkg=hyphy=hurd-i386=2.5.24%2Bdfsg-1=1608548780=0 Thanks, -- Pino --- a/debian/rules +++ b/debian/rules @@ -33,7 +33,7 @@ override_dh_auto_build: override_dh_auto_test: ifeq (,$(filter nocheck,$(DEB_BUILD_OPTIONS))) - find "$$(echo obj-*-*-*/)" \ + find "obj-$(DEB_HOST_GNU_TYPE)/" \ -not -path "*/CMakeFiles/*" \ -type f,l \ -executable \
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#977754: evince does not display EPS or PS files anymore and shows "Loading..." forever
reassign 975387 libgs9 ghostscript/9.53.0~dfsg-1
retitle 975387 wrong size check for display_callback_v2_s struct
severity 975387 serious
forwarded 975387 https://bugs.ghostscript.com/show_bug.cgi?id=703301
tag 975387 + patch
merge 975387 975574
thanks
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.
The rebuild, while "easy as it seems", does not consider an important
fact. From what I see, libgs got new APIs in 9.53.0, and libspectre
does not (optionally) use any of them. This means that a rebuild most
probably would not cause libspectre to require the newer ghostscript,
migrating instantly to testing. Considering that what we have here
smells like a behaviour change, this means making libspectre unusable
for the users of testing, and I do not find this acceptable.
I checked the changes between ghostscript 9.52.1 and 9.53.3, and I found
one thing: gs 9.53.0 reworks a bit the display device stuff, adding a
v3 device_callback struct, and keeping the support for what is now v2:
http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=eed3bad23510e59278bdaa5f7d0ab01fc1a1c21b;hp=04e937862eaa7e66bb9a87109874112cd354bf6f
display_callback is actually used in libspectre, see spectre-device.c.
Because it relies on DISPLAY_VERSION_MAJOR/DISPLAY_VERSION_MINOR, this
explains why it works after a rebuild, as it will use the
device_callback v3. This also shows that a rebuild is a no-no, as it
will get in the situation I described earlier (i.e. stop working with
ghostscript in testing).
There is actually code in ghostscript to support the old device_callback
(v2, as built in libspectre during the last built), as it can be see in
devices/gdevdsp.c, function display_check_structure:
static int display_check_structure(gx_device_display *ddev)
[...]
else if (ddev->callback->size == sizeof(struct display_callback_v2_s)) {
/* V2 structure with added display_separation callback */
if (ddev->callback->size != sizeof(display_callback))
return_error(gs_error_rangecheck);
[...]
Considering that:
- sizeof(struct display_callback_v2_s) != sizeof(display_callback);
the addition to new stuff to display_callback was the reason for the
new struct in the first place, so of course the two structs do not
have the same size
- the last libspectre build uses display_callback v2, so the check:
ddev->callback->size == sizeof(struct display_callback_v2_s)
is true
then the check "ddev->callback->size != sizeof(display_callback)" will
be always false! Indeed, tried a simple patch to drop this, and evince
shows again PS files without rebuilding libspectre.
I submitted this as ghostscript bug:
https://bugs.ghostscript.com/show_bug.cgi?id=703301
Because of this, I'm reassigning 977754/975387 to ghostscript, merging
also 975574 to them, and setting the proper metadata. I'm also attaching
a copy of the patch I submitted upstream.
Thanks,
--
Pino Toscanodiff --git a/devices/gdevdsp.c b/devices/gdevdsp.c
index 0a66a0278..52087f8d6 100644
--- a/devices/gdevdsp.c
+++ b/devices/gdevdsp.c
@@ -1430,9 +1430,6 @@ static int display_check_structure(gx_device_display *ddev)
}
else if (ddev->callback->size == sizeof(struct display_callback_v2_s)) {
/* V2 structure with added display_separation callback */
-if (ddev->callback->size != sizeof(display_callback))
-return_error(gs_error_rangecheck);
-
if (ddev->callback->version_major != DISPLAY_VERSION_MAJOR_V2)
return_error(gs_error_rangecheck);
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#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#977414: boost1.74: FTBFS on hurd-i386
Source: boost1.74
Version: 1.74.0-4
Severity: important
Tags: patch upstream fixed-upstream
X-Debbugs-Cc: gl...@debian.org
Control: forwarded -1 https://github.com/boostorg/build/pull/676
Hi,
boost 1.71 currently fails to build on Hurd [1].
The issue is that boost build ("b2") now tries to get its path (i.e.
the full path of the running executable), and the function for this
is not implemented on Hurd; the effect is that launching b2 with a
relative path, like ./b2 as done at different times during the build,
fails.
I recently sent upstream few small improvements for Hurd [2], including
the fix for the aforementioned issue. The series was recently merged
upstream for the future 1.76.0, so I'm attaching here only the part
of it needed to make b2 run properly (the rest is improvements that can
definitely wait for newer boost versions).
[1]
https://buildd.debian.org/status/fetch.php?pkg=boost1.74=hurd-i386=1.74.0-4=1607921711=0
[2] https://github.com/boostorg/build/pull/676
Thanks,
--
Pino
Author: Pino Toscano
Description: Use /proc/self/exe for executable_path on Hurd
.
Use the Linux compatibility procfs translator to get the full path of
the current executable.
Origin:
https://github.com/boostorg/build/commit/25879fc24d96c89e817e7950ec92d6e2cb41e1b3
Applied-Upstream: 1.76.0
--- a/tools/build/src/engine/jam.cpp
+++ b/tools/build/src/engine/jam.cpp
@@ -747,7 +747,7 @@ char * executable_path( char const * arg
sysctl( mib, 4, buf, , NULL, 0 );
return ( !size || size == sizeof( buf ) ) ? NULL : strndup( buf, size );
}
-#elif defined(__linux__)
+#elif defined(__linux__) || defined(__GNU__)
# include
char * executable_path( char const * argv0 )
{
Bug#977366: kdenlive-data: please drop the old conffiles
Package: kdenlive-data Version: 20.12.0-1 Severity: normal Tags: patch Hi, there are few configuration files that in the past were shipped in /etc and, due to changes in newer versions of extra-cmake-modules, are now installed in own locations under /usr/share. Because of this, there are old conffiles that are left installed by upgrading from old installations: - /etc/xdg/kdenlive.categories - /etc/xdg/kdenlive_keyboardschemes.knsrc - /etc/xdg/kdenlive_renderprofiles.knsrc - /etc/xdg/kdenlive_titles.knsrc - /etc/xdg/kdenlive_wipes.knsrc *.categories files are now in /usr/share/qlogging-categories5/, and *.knrc files are now in /usr/share/knsrcfiles/. Luckly it is easy enough to solve: apply dpkg-maintscript-helper snippets to purge these old conffiles; patch attached for it. VERY IMPORTANT NOTE: please adjust *all* the versions in this patch to be the *exact* Debian version you will upload this change with: - if the upload fixing this will be 20.12.0-2, then adjust the versions to be 20.12.0-2~ - if the upload fixing this will be 20.12.1-1, then adjust the versions to be 20.12.1-1~ - and so on otherwise an old version already considers the removal done, and it will not even be attempted; this is why /etc/xdg/kdenlive.categories is still not removed, despite being in kdenlive-data.maintscript. Thanks, -- Pino diff -Nru a/debian/kdenlive-data.maintscript b/debian/kdenlive-data.maintscript --- a/debian/kdenlive-data.maintscript +++ b/debian/kdenlive-data.maintscript @@ -1 +1,5 @@ -rm_conffile /etc/xdg/kdenlive.categories 19.08.0-1.1~ +rm_conffile /etc/xdg/kdenlive.categories 20.12.0-1.1~ +rm_conffile /etc/xdg/kdenlive_keyboardschemes.knsrc 20.12.0-1.1~ +rm_conffile /etc/xdg/kdenlive_renderprofiles.knsrc 20.12.0-1.1~ +rm_conffile /etc/xdg/kdenlive_titles.knsrc 20.12.0-1.1~ +rm_conffile /etc/xdg/kdenlive_wipes.knsrc 20.12.0-1.1~
Bug#977365: kdenlive: please build and ship the user documentation
Source: kdenlive Version: 20.12.0-1 Severity: wishlist Tags: patch Hi, kdenlive has an user documentation in DocBook format, also translated in some languages. It is currently not build because of the missing KDocTools framework, as it can be easily seen in build logs: -- Could NOT find KF5DocTools (missing: KF5DocTools_DIR) -- Could NOT find KF5DocTools: found neither KF5DocToolsConfig.cmake nor kf5doctools-config.cmake The solution is simple: add the libkf5doctools-dev build dependency; there is no need to change kdenlive-data.install, as it already ships the whole /usr/share/doc. Patch attached for this. Thanks, -- Pino diff -Nru a/debian/control b/debian/control --- a/debian/control +++ b/debian/control @@ -27,6 +27,7 @@ libkf5config-dev, libkf5configwidgets-dev, libkf5coreaddons-dev, + libkf5doctools-dev, libkf5dbusaddons-dev, libkf5guiaddons-dev, libkf5iconthemes-dev,
Bug#976664: RM: digikam/experimental -- NVIU; old version not removed by autocruft removal
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: s...@debian.org Hi, please remove digikam in experimental, as it is older than what is available in unstable, and apparently it was not removed automatically already. Thanks, -- Pino
Bug#565968: Should support debian sid
In data mercoledì 20 gennaio 2010 11:02:15 CET, Guido Günther ha scritto: > On Wed, Jan 20, 2010 at 09:58:33AM +0100, Laurent Bigonville wrote: > > Package: virtinst > > Version: 0.500.1-2 > > Severity: wishlist > > > > Hi, > Thanks for your report. > > > > I think it could be interesting to add debian sid in the list of > > supported distribution > The distribution defines what we can assume is supported by the guest > (like e.g. vitio for network devices). Since "Sid" isn't a release we > can't make any assumptions. That's why we have Debian Squeeze in there > but not Unstable/Sid. The releasename "Sid" never changes but it's > features always change so having "Sid" in the list will only confuse > users. As data point: osinfo-db, which contains the various OSes virt-manager (and thus virt-install too) knows about, added a "debiantesting" OS some years ago with commit 9440d0a82a0eb9a80b66ca2b420c805f8ffe6234 [1]. It is available in Debian since version 0.20160728+git20161020-1. IMHO testing and unstable are generally close enough w.r.t features supported, so using "debiantesting" as ID for Debian unstable VMs should be good enough. It will not allow to directly install unstable though. [1] https://gitlab.com/libosinfo/osinfo-db/-/commit/9440d0a82a0eb9a80b66ca2b420c805f8ffe6234 -- Pino Toscano signature.asc Description: This is a digitally signed message part.
Bug#909389: virt-inst --location security concern
Hi, In data sabato 22 settembre 2018 22:51:36 CET, hai scritto: > Package: virtinst > Version: 1:1.4.0-5 > > I rediscovered a problem I found a couple of years ago, and thought I'd > report it properly this time. > > The problem is that "virt-install --location" does not verify > checksums/signatures of what is downloaded, and is thus vulnerable to a > network attack where someone replaces the kernel/initrd with a version > that is malicious. As far as I know, there is no way to tell virt- > install what checksums to expect. > > See earlier discussion here: https://www.redhat.com/archives/virt-tools > -list/2015-April/msg00214.html > > Quoting the manpage which gives http-URLs to use: > >--location OPTIONS > ... >Debian >http://ftp.us.debian.org/debian/dists/stable/main/instal > ler-amd64/ > >Ubuntu >http://us.archive.ubuntu.com/ubuntu/dists/wily/main/inst > aller-amd64/ > > A workaround is to replace the recommended http URLs with https URLs. > I checked that CA verification of the domain name works. This gives > some protection, but far from a GnuPG-based verification that would be > ideal. Upstream switched to https URLs with two commits: - a712549b2b9b0100907878fea18442be68b8d35f [1] - b1460ba0654c00527c8d5632d69b30c7030dc182 [2] which are both available in virt-manager 2.0.0. Note that even before the above fixes it was possible to pass https URLs to the installer location. Also, the upstream bug rh#1632132 [3] was recently closed, also for low priorities and not much interest shown in it. I'd tend to close this bug as well, however I'm not strongly for it. [1] https://github.com/virt-manager/virt-manager/commit/a712549b2b9b0100907878fea18442be68b8d35f [2] https://github.com/virt-manager/virt-manager/commit/b1460ba0654c00527c8d5632d69b30c7030dc182 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1632132 -- Pino Toscano signature.asc Description: This is a digitally signed message part.
