Bug#1064292: pyside2: NMU diff for 64-bit time_t transition

[Steve Langasek]

Dear maintainer,

Please find attached a final version of this patch for the time_t
transition.  This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.

Thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru pyside2-5.15.12/debian/changelog pyside2-5.15.12/debian/changelog
--- pyside2-5.15.12/debian/changelog2024-02-08 08:13:11.0 +
+++ pyside2-5.15.12/debian/changelog2024-03-02 00:27:01.0 +
@@ -1,3 +1,10 @@
+pyside2 (5.15.12-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.  Closes: #1064292
+
+ -- Steve Langasek   Sat, 02 Mar 2024 00:27:01 +
+
 pyside2 (5.15.12-6) unstable; urgency=medium
 
   * Team upload.
diff -Nru pyside2-5.15.12/debian/control pyside2-5.15.12/debian/control
--- pyside2-5.15.12/debian/control  2024-02-08 08:13:11.0 +
+++ pyside2-5.15.12/debian/control  2024-03-02 00:27:01.0 +
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Qt/KDE Maintainers 
 Uploaders: Kurt Kremitzki 
-Build-Depends: chrpath,
+Build-Depends: dpkg-dev (>= 1.22.5), chrpath,
cmake (>= 3.1),
debhelper-compat (= 13),
dh-python,
@@ -76,13 +76,14 @@
  .
  This package contains the common documentation package.
 
-Package: libpyside2-py3-5.15
+Package: libpyside2-py3-5.15t64
+Breaks: libpyside2-py3-5.15 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
 Conflicts: libpyside2-py3-5.11, libpyside2-py3-5.13, libpyside2-py3-5.14
-Replaces: libpyside2-py3-5.11, libpyside2-py3-5.13, libpyside2-py3-5.14
-Provides: libpyside2-py3
+Replaces: libpyside2-py3-5.15, libpyside2-py3-5.11, libpyside2-py3-5.13, 
libpyside2-py3-5.14
+Provides: ${t64:Provides}, libpyside2-py3
 Description: Python 3 bindings for Qt5 (base files)
  pyside2 provides Python bindings for Qt 5.x framework.
  .
@@ -94,7 +95,7 @@
 Package: libpyside2-dev
 Section: libdevel
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, libpyside2-py3-5.15 (= 
${binary:Version})
+Depends: ${misc:Depends}, ${shlibs:Depends}, libpyside2-py3-5.15t64 (= 
${binary:Version})
 Description: Python bindings for Qt5 (development files)
  pyside2 provides Python bindings for Qt 5.x framework.
  .
@@ -127,13 +128,14 @@
  .
  Shiboken2 is the binding generator used to create the PySide2 bindings.
 
-Package: libshiboken2-py3-5.15
+Package: libshiboken2-py3-5.15t64
+Breaks: libshiboken2-py3-5.15 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
 Conflicts: libshiboken2-py3-5.11, libshiboken2-py3-5.13, libshiboken2-py3-5.14
-Replaces: libshiboken2-py3-5.11, libshiboken2-py3-5.13, libshiboken2-py3-5.14
-Provides: libshiboken2-py3
+Replaces: libshiboken2-py3-5.15, libshiboken2-py3-5.11, libshiboken2-py3-5.13, 
libshiboken2-py3-5.14
+Provides: ${t64:Provides}, libshiboken2-py3
 Description: CPython bindings generator for C++ libraries (Python3 shared 
library)
  Shiboken2 is a bindings generator for C++ libraries that outputs CPython
  source code. It collects information from library headers, and then
@@ -148,7 +150,7 @@
 Section: libdevel
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends},
- libshiboken2-py3-5.15 (= ${binary:Version}), shiboken2 (= ${binary:Version}), 
python3-dev
+ libshiboken2-py3-5.15t64 (= ${binary:Version}), shiboken2 (= 
${binary:Version}), python3-dev
 Description: CPython bindings generator for C++ libraries (development files)
  Shiboken2 is a bindings generator for C++ libraries that outputs CPython
  source code. It collects information from library headers, and then
diff -Nru pyside2-5.15.12/debian/libpyside2-py3-5.15.install 
pyside2-5.15.12/debian/libpyside2-py3-5.15.install
--- pyside2-5.15.12/debian/libpyside2-py3-5.15.install  2024-02-08 
08:13:11.0 +
+++ pyside2-5.15.12/debian/libpyside2-py3-5.15.install  1970-01-01 
00:00:00.0 +
@@ -1,4 +0,0 @@
-pyside3_install/py3*-relwithdebinfo/lib/libpyside2*.so.* 
usr/lib/${DEB_HOST_MULTIARCH}
-pyside3_install/py3*-relwithdebinfo/lib/python*/site-packages/PySide2/_git_pyside_version.py
 usr/lib/python3/dist-packages/PySide2
-pyside3_install/py3*-relwithdebinfo/lib/python*/site-packages/PySide2/__init__.py
 usr/lib/python3/dist-packages/PySide2
-pyside3_install/py3*-relwithdebinfo/lib/python*/site-packages/PySide2/_config.py
 usr/lib/python3/dist-packages/PySide2

Bug#1062390: t64 transition plans for these packages?

[Steve Langasek]

Hello,

All of these bugs have been un-tagged 'pending', so as a result our batch
NMU scripting is skipping over them and we are currently not NMUing them to
unstable.

However, the bugs have not been closed, suggesting that they are invalid;
and there is no information in the bugs about maintainer plans for handling
these packages.

Could you please clarify what your intention is here?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#1061881: akonadi-search: NMU diff for 64-bit time_t transition

[Steve Langasek]

Dear maintainer,

Please find attached a final version of this patch for the time_t
transition.  This patch is being uploaded to unstable.

Note that this adds a versioned build-dependency on dpkg-dev, to guard
against accidental backports with a wrong ABI.

Thanks!


-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru akonadi-search-22.12.3/debian/changelog 
akonadi-search-22.12.3/debian/changelog
--- akonadi-search-22.12.3/debian/changelog 2023-03-01 20:32:14.0 
+
+++ akonadi-search-22.12.3/debian/changelog 2024-02-28 00:39:18.0 
+
@@ -1,3 +1,10 @@
+akonadi-search (4:22.12.3-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.  Closes: #1061881
+
+ -- Steve Langasek   Wed, 28 Feb 2024 00:39:18 +
+
 akonadi-search (4:22.12.3-1) unstable; urgency=medium
 
   [ Patrick Franz ]
diff -Nru akonadi-search-22.12.3/debian/control 
akonadi-search-22.12.3/debian/control
--- akonadi-search-22.12.3/debian/control   2023-03-01 18:27:15.0 
+
+++ akonadi-search-22.12.3/debian/control   2024-02-28 00:39:18.0 
+
@@ -4,7 +4,7 @@
 Maintainer: Debian Qt/KDE Maintainers 
 Uploaders: Sandro Knauß ,
Patrick Franz ,
-Build-Depends: cmake (>= 3.16~),
+Build-Depends: dpkg-dev (>= 1.22.5), cmake (>= 3.16~),
debhelper-compat (= 13),
extra-cmake-modules (>= 5.99.0~),
gettext,
@@ -74,7 +74,9 @@
  .
  This package contains runtime plugins.
 
-Package: libkf5akonadisearchcore5
+Package: libkf5akonadisearchcore5t64
+Replaces: libkf5akonadisearchcore5
+Breaks: libkf5akonadisearchcore5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: libkf5akonadisearch-data (>= ${source:Version}),
@@ -85,18 +87,22 @@
 Description: Akonadi search core library
  Internal library used to search in the Akonadi PIM data server.
  This package contains the core library.
-Provides: ${ABI:VirtualPackage},
+Provides: ${t64:Provides}, ${ABI:VirtualPackage},
 
-Package: libkf5akonadisearchdebug5
+Package: libkf5akonadisearchdebug5t64
+Replaces: libkf5akonadisearchdebug5
+Breaks: libkf5akonadisearchdebug5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends},
 Description: Akonadi search debug library
  Internal library used to search in the Akonadi PIM data server.
  This package contains the debug library.
-Provides: ${ABI:VirtualPackage},
+Provides: ${t64:Provides}, ${ABI:VirtualPackage},
 
-Package: libkf5akonadisearchpim5
+Package: libkf5akonadisearchpim5t64
+Replaces: libkf5akonadisearchpim5
+Breaks: libkf5akonadisearchpim5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends},
@@ -104,13 +110,15 @@
 libkf5akonadisearch-plugins (= ${binary:Version}),
 Description: Akonadi search library
  Library used to search in the Akonadi PIM data server.
-Provides: ${ABI:VirtualPackage},
+Provides: ${t64:Provides}, ${ABI:VirtualPackage},
 
-Package: libkf5akonadisearchxapian5
+Package: libkf5akonadisearchxapian5t64
+Replaces: libkf5akonadisearchxapian5
+Breaks: libkf5akonadisearchxapian5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends},
 Description: Akonadi search xapian library
  Internal library used to search in the Akonadi PIM data server.
  This package contains the xapian library.
-Provides: ${ABI:VirtualPackage},
+Provides: ${t64:Provides}, ${ABI:VirtualPackage},
diff -Nru akonadi-search-22.12.3/debian/libkf5akonadisearchcore5.install 
akonadi-search-22.12.3/debian/libkf5akonadisearchcore5.install
--- akonadi-search-22.12.3/debian/libkf5akonadisearchcore5.install  
2022-12-20 00:37:22.0 +
+++ akonadi-search-22.12.3/debian/libkf5akonadisearchcore5.install  
1970-01-01 00:00:00.0 +
@@ -1,2 +0,0 @@
-usr/lib/*/libKF5AkonadiSearchCore.so.5
-usr/lib/*/libKF5AkonadiSearchCore.so.5.*
diff -Nru akonadi-search-22.12.3/debian/libkf5akonadisearchcore5t64.install 
akonadi-search-22.12.3/debian/libkf5akonadisearchcore5t64.install
--- akonadi-search-22.12.3/debian/libkf5akonadisearchcore5t64.install   
1970-01-01 00:00:00.0 +
+++ akonadi-search-22.12.3/debian/libkf5akonadisearchcore5t64.install   
2022-12-20 00:37:22.0 +
@@ -0,0 +1,2 @@
+usr/lib/*/libKF5AkonadiSearchCore.so.5
+usr/lib/*/libKF5AkonadiSearchCore.so.5.*
diff -Nru 
akonadi-search-22.12.3/debian/libkf5akonadisearchcore5t64.lintian-overrides 
akonadi-search-22.12.3/deb

Bug#1064292: pyside2: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: pyside2
Version: 5.15.12-6
Severity: important
Tags: patch pending sid trixie
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
pyside2 as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for pyside2
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru pyside2-5.15.12/debian/changelog pyside2-5.15.12/debian/changelog
--- pyside2-5.15.12/debian/changelog2024-02-08 08:13:11.0 +
+++ pyside2-5.15.12/debian/changelog2024-02-19 18:32:19.0 +
@@ -1,3 +1,10 @@
+pyside2 (5.15.12-6.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Mon, 19 Feb 2024 18:32:19 +
+
 pyside2 (5.15.12-6) unstable; urgency=medium
 
   * Team upload.
diff -Nru pyside2-5.15.12/debian/control pyside2-5.15.12/debian/control
--- pyside2-5.15.12/debian/control  2024-02-08 08:13:11.0 +
+++ pyside2-5.15.12/debian/control  2024-02-19 18:32:19.0 +
@@ -76,13 +76,14 @@
  .
  This package contains the common documentation package.
 
-Package: libpyside2-py3-5.15
+Package: libpyside2-py3-5.15t64
+Breaks: libpyside2-py3-5.15 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
 Conflicts: libpyside2-py3-5.11, libpyside2-py3-5.13, libpyside2-py3-5.14
-Replaces: libpyside2-py3-5.11, libpyside2-py3-5.13, libpyside2-py3-5.14
-Provides: libpyside2-py3
+Replaces: libpyside2-py3-5.15, libpyside2-py3-5.11, libpyside2-py3-5.13, 
libpyside2-py3-5.14
+Provides: ${t64:Provides}, libpyside2-py3
 Description: Python 3 bindings for Qt5 (base files)
  pyside2 provides Python bindings for Qt 5.x framework.
  .
@@ -94,7 +95,7 @@
 Package: libpyside2-dev
 Section: libdevel
 Architecture: any
-Depends: ${misc:Depends}, ${shlibs:Depends}, libpyside2-py3-5.15 (= 
${binary:Version})
+Depends: ${misc:Depends}, ${shlibs:Depends}, libpyside2-py3-5.15t64 (= 
${binary:Version})
 Description: Python bindings for Qt5 (development files)
  pyside2 provides Python bindings for Qt 5.x framework.
  .
@@ -127,13 +128,14 @@
  .
  Shiboken2 is the binding generator used to create the PySide2 bindings.
 
-Package: libshiboken2-py3-5.15
+Package: libshiboken2-py3-5.15t64
+Breaks: libshiboken2-py3-5.15 (<< ${source:Version})
 Section: libs
 Architecture: any
 Depends: ${misc:Depends}, ${python3:Depends}, ${shlibs:Depends}
 Conflicts: libshiboken2-py3-5.11, libshiboken2-py3-5.13, libshiboken2-py3-5.14
-Replaces: libshiboken2-py3-5.11, libshiboken2-py3-5.13, libshiboken2-py3-5.14
-Provides: libshiboken2-py3
+Replaces: libshiboken2-py3-5.15, libshiboken2-py3-5.11, libshiboken2-py3-5.13, 
libshiboken2-py3-5.14
+Provides: ${t64:Provides}, libshiboken2-py3
 Description: CPython bindings generator for C++ libraries (Python3 shared 
library)
  Shiboken2 is a bindings generator for C++ libraries that outputs CPython
  source code. It collects information from library headers, and then
@@ -148,7 +150,7 @@
 Section: libdevel
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends},
- libshiboken2-py3-5.15 (= ${binary:Version}), shiboken2 (= ${binary:Version}), 

Bug#1063121: kjs: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: kjs
Version: 5.107.0-1
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
kjs as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for kjs
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru kjs-5.107.0/debian/changelog kjs-5.107.0/debian/changelog
--- kjs-5.107.0/debian/changelog2023-06-18 14:08:39.0 +
+++ kjs-5.107.0/debian/changelog2024-02-05 07:44:23.0 +
@@ -1,3 +1,10 @@
+kjs (5.107.0-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Mon, 05 Feb 2024 07:44:23 +
+
 kjs (5.107.0-1) unstable; urgency=medium
 
   [ Aurélien COUDERC ]
diff -Nru kjs-5.107.0/debian/control kjs-5.107.0/debian/control
--- kjs-5.107.0/debian/control  2023-06-18 14:05:36.0 +
+++ kjs-5.107.0/debian/control  2024-02-05 07:44:23.0 +
@@ -18,7 +18,9 @@
 Vcs-Git: https://salsa.debian.org/qt-kde-team/kde/kjs.git
 Rules-Requires-Root: no
 
-Package: libkf5js5
+Package: libkf5js5t64
+Provides: ${t64:Provides}
+Replaces: libkf5js5
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends},
@@ -26,12 +28,15 @@
  Addon library to Qt which adds JavaScript scripting support.
  .
  This package is part of KDE Frameworks 5.
-Breaks: libkf5jsembed-dev (<< 5.54),
+Breaks: libkf5js5 (<< ${source:Version}), libkf5jsembed-dev (<< 5.54),
 libkf5jsembed5 (<< 5.54),
 libkf5khtml-bin (<< 5.54),
 libkf5khtml5 (<< 5.54),
 
-Package: libkf5jsapi5
+Package: libkf5jsapi5t64
+Provides: ${t64:Provides}
+Replaces: libkf5jsapi5
+Breaks: libkf5jsapi5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends},
@@ -43,8 +48,8 @@
 Package: libkf5kjs-dev
 Section: libdevel
 Architecture: any
-Depends: libkf5js5 (= ${binary:Version}),
- libkf5jsapi5 (= ${binary:Version}),
+Depends: libkf5js5t64 (= ${binary:Version}),
+ libkf5jsapi5t64 (= ${binary:Version}),
  libpcre3-dev,
  qtbase5-dev (>= 5.15.2~),
  ${misc:Depends},
diff -Nru kjs-5.107.0/debian/libkf5js5.install 
kjs-5.107.0/debian/libkf5js5.install
--- kjs-5.107.0/debian/libkf5js5.install2022-08-22 12:51:07.0 
+
+++ kjs-5.107.0/debian/libkf5js5.install1970-01-01 00:00:00.0 
+
@@ -1,2 +0,0 @@
-usr/lib/*/libKF5JS.so.5
-usr/lib/*/libKF5JS.so.5.*
diff -Nru kjs-5.107.0/debian/libkf5js5.symbols 
kjs-5.107.0/debian/libkf5js5.symbols
--- kjs-5.107.0/debian/libkf5js5.symbols2023-03-16 21:42:01.0 
+
+++ kjs-5.107.0/debian/libkf5js5.symbols1970-01-01 00:00:00.0 
+
@@ -1,504 +0,0 @@
-# SymbolsHelper-Confirmed: 5.94.0 amd64 i386
-libKF5JS.so.5 libkf5js5 #MINVER#
-* Build-Depends-Package: libkf5kjs-dev
- _ZN3KJS10Identifier11addSlowCaseEPNS_7UString3RepE@Base 4.96.0
- _ZN3KJS10Identifier3addEPKNS_5UCharEi@Base 4.96.0
- _ZN3KJS10Identifier3addEPKc@Base 4.96.0
- _ZN3KJS10Identifier5equalEPKNS_7UString3RepEPKNS_5UCharEi@Base 4.96.0
- _Z

Bug#1062927: stellarsolver: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: stellarsolver
Version: 2.5-1
Severity: serious
Tags: patch pending sid trixie
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

NOTICE: these changes must not be uploaded to unstable yet!

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
stellarsolver as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for stellarsolver
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru stellarsolver-2.5/debian/changelog stellarsolver-2.5/debian/changelog
--- stellarsolver-2.5/debian/changelog  2023-08-18 04:04:30.0 +
+++ stellarsolver-2.5/debian/changelog  2024-02-04 00:37:07.0 +
@@ -1,3 +1,10 @@
+stellarsolver (2.5-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Sun, 04 Feb 2024 00:37:07 +
+
 stellarsolver (2.5-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru stellarsolver-2.5/debian/control stellarsolver-2.5/debian/control
--- stellarsolver-2.5/debian/control2023-08-18 03:54:27.0 +
+++ stellarsolver-2.5/debian/control2024-02-04 00:37:07.0 +
@@ -16,7 +16,10 @@
 Vcs-Browser: https://salsa.debian.org/qt-kde-team/3rdparty/stellarsolver
 Homepage: https://github.com/rlancaste/stellarsolver
 
-Package: libstellarsolver2
+Package: libstellarsolver2t64
+Provides: ${t64:Provides}
+Replaces: libstellarsolver2
+Breaks: libstellarsolver2 (<< ${source:Version})
 Section: libs
 Architecture: any
 Multi-Arch: same
@@ -28,7 +31,7 @@
 
 Package: libstellarsolver-dev
 Architecture: any
-Depends: libstellarsolver2 (= ${binary:Version}),
+Depends: libstellarsolver2t64 (= ${binary:Version}),
  libcfitsio-dev,
  qtbase5-dev,
  ${misc:Depends}
diff -Nru stellarsolver-2.5/debian/libstellarsolver2.install 
stellarsolver-2.5/debian/libstellarsolver2.install
--- stellarsolver-2.5/debian/libstellarsolver2.install  2022-05-21 
04:01:51.0 +
+++ stellarsolver-2.5/debian/libstellarsolver2.install  1970-01-01 
00:00:00.0 +
@@ -1,2 +0,0 @@
-usr/lib/*/libstellarsolver.so.2
-usr/lib/*/libstellarsolver.so.2.*
diff -Nru stellarsolver-2.5/debian/libstellarsolver2t64.install 
stellarsolver-2.5/debian/libstellarsolver2t64.install
--- stellarsolver-2.5/debian/libstellarsolver2t64.install   1970-01-01 
00:00:00.0 +
+++ stellarsolver-2.5/debian/libstellarsolver2t64.install   2022-05-21 
04:01:51.0 +
@@ -0,0 +1,2 @@
+usr/lib/*/libstellarsolver.so.2
+usr/lib/*/libstellarsolver.so.2.*
diff -Nru stellarsolver-2.5/debian/libstellarsolver2t64.lintian-overrides 
stellarsolver-2.5/debian/libstellarsolver2t64.lintian-overrides
--- stellarsolver-2.5/debian/libstellarsolver2t64.lintian-overrides 
1970-01-01 00:00:00.0 +
+++ stellarsolver-2.5/debian/libstellarsolver2t64.lintian-overrides 
2024-02-04 00:37:07.0 +
@@ -0,0 +1 @@
+libstellarsolver2t64: package-name-doesnt-match-sonames libstellarsolver2

Bug#1062485: libnova: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libnova
Version: 0.16-5
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libnova as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for libnova
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libnova-0.16/debian/changelog libnova-0.16/debian/changelog
--- libnova-0.16/debian/changelog   2020-11-08 08:55:47.0 +
+++ libnova-0.16/debian/changelog   2024-02-01 17:01:22.0 +
@@ -1,3 +1,10 @@
+libnova (0.16-5.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Thu, 01 Feb 2024 17:01:22 +
+
 libnova (0.16-5) unstable; urgency=medium
 
   * Team upload.
diff -Nru libnova-0.16/debian/control libnova-0.16/debian/control
--- libnova-0.16/debian/control 2020-11-08 08:20:45.0 +
+++ libnova-0.16/debian/control 2024-02-01 17:01:21.0 +
@@ -10,7 +10,10 @@
 Vcs-Browser: https://salsa.debian.org/qt-kde-team/3rdparty/libnova
 Vcs-Git: https://salsa.debian.org/qt-kde-team/3rdparty/libnova.git
 
-Package: libnova-0.16-0
+Package: libnova-0.16-0t64
+Provides: ${t64:Provides}
+Replaces: libnova-0.16-0
+Breaks: libnova-0.16-0 (<< ${source:Version})
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}
 Pre-Depends: ${misc:Pre-Depends}
@@ -23,7 +26,7 @@
 Architecture: any
 Multi-Arch: same
 Section: libdevel
-Depends: libnova-0.16-0 (= ${binary:Version}),
+Depends: libnova-0.16-0t64 (= ${binary:Version}),
  libnova-dev-bin (= ${binary:Version}),
  ${misc:Depends},
  ${shlibs:Depends},
diff -Nru libnova-0.16/debian/libnova-0.16-0.install 
libnova-0.16/debian/libnova-0.16-0.install
--- libnova-0.16/debian/libnova-0.16-0.install  2020-11-08 08:01:23.0 
+
+++ libnova-0.16/debian/libnova-0.16-0.install  1970-01-01 00:00:00.0 
+
@@ -1,2 +0,0 @@
-usr/lib/*/libnova-0.16.so.0
-usr/lib/*/libnova-0.16.so.0.*
diff -Nru libnova-0.16/debian/libnova-0.16-0t64.install 
libnova-0.16/debian/libnova-0.16-0t64.install
--- libnova-0.16/debian/libnova-0.16-0t64.install   1970-01-01 
00:00:00.0 +
+++ libnova-0.16/debian/libnova-0.16-0t64.install   2020-11-08 
08:01:23.0 +
@@ -0,0 +1,2 @@
+usr/lib/*/libnova-0.16.so.0
+usr/lib/*/libnova-0.16.so.0.*
diff -Nru libnova-0.16/debian/libnova-0.16-0t64.lintian-overrides 
libnova-0.16/debian/libnova-0.16-0t64.lintian-overrides
--- libnova-0.16/debian/libnova-0.16-0t64.lintian-overrides 1970-01-01 
00:00:00.0 +
+++ libnova-0.16/debian/libnova-0.16-0t64.lintian-overrides 2024-02-01 
17:01:21.0 +
@@ -0,0 +1 @@
+libnova-0.16-0t64: package-name-doesnt-match-sonames libnova-0.16-0

Bug#1062390: libkf5libkleo: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: libkf5libkleo
Version: 4:22.12.3-1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
libkf5libkleo as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for libkf5libkleo
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libkf5libkleo-22.12.3/debian/changelog 
libkf5libkleo-22.12.3/debian/changelog
--- libkf5libkleo-22.12.3/debian/changelog  2023-03-01 20:31:35.0 
+
+++ libkf5libkleo-22.12.3/debian/changelog  2024-02-01 08:46:33.0 
+
@@ -1,3 +1,10 @@
+libkf5libkleo (4:22.12.3-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Thu, 01 Feb 2024 08:46:33 +
+
 libkf5libkleo (4:22.12.3-1) unstable; urgency=medium
 
   [ Patrick Franz ]
diff -Nru libkf5libkleo-22.12.3/debian/control 
libkf5libkleo-22.12.3/debian/control
--- libkf5libkleo-22.12.3/debian/control2023-03-01 18:22:52.0 
+
+++ libkf5libkleo-22.12.3/debian/control2024-02-01 08:46:33.0 
+
@@ -32,8 +32,8 @@
 Package: libkf5libkleo-data
 Architecture: all
 Depends: ${misc:Depends},
-Breaks: libkf5libkleo5 (<= 4:16.04),
-Replaces: libkf5libkleo5 (<= 4:16.04),
+Breaks: libkf5libkleo5t64 (<= 4:16.04),
+Replaces: libkf5libkleo5t64 (<= 4:16.04),
 Multi-Arch: foreign
 Description: KDE PIM cryptographic library, data files
  This package contains the data files used by libkleo, a library for Kleopatra
@@ -54,7 +54,7 @@
  libkf5coreaddons-dev (>= 5.99.0~),
  libkf5i18n-dev (>= 5.99.0~),
  libkf5itemmodels-dev (>= 5.99.0~),
- libkf5libkleo5 (= ${binary:Version}),
+ libkf5libkleo5t64 (= ${binary:Version}),
  libkf5pimtextedit-dev (>= 22.12.3~),
  libkf5widgetsaddons-dev (>= 5.99.0~),
  qtbase5-dev (>= 5.15.2~),
@@ -65,7 +65,9 @@
  .
  This package is part of the KDE PIM module.
 
-Package: libkf5libkleo5
+Package: libkf5libkleo5t64
+Replaces: libkf5libkleo5
+Breaks: libkf5libkleo5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: libkf5libkleo-data (= ${source:Version}),
@@ -76,4 +78,4 @@
  using certificate-based crypto.
  .
  This package is part of the KDE PIM module.
-Provides: ${ABI:VirtualPackage},
+Provides: ${ABI:VirtualPackage},, ${t64:Provides}
diff -Nru libkf5libkleo-22.12.3/debian/libkf5libkleo5.install 
libkf5libkleo-22.12.3/debian/libkf5libkleo5.install
--- libkf5libkleo-22.12.3/debian/libkf5libkleo5.install 2022-12-20 
00:37:31.0 +
+++ libkf5libkleo-22.12.3/debian/libkf5libkleo5.install 1970-01-01 
00:00:00.0 +
@@ -1,2 +0,0 @@
-usr/lib/*/libKF5Libkleo.so.5
-usr/lib/*/libKF5Libkleo.so.5.*
diff -Nru libkf5libkleo-22.12.3/debian/libkf5libkleo5t64.install 
libkf5libkleo-22.12.3/debian/libkf5libkleo5t64.install
--- libkf5libkleo-22.12.3/debian/libkf5libkleo5t64.install  1970-01-01 
00:00:00.0 +
+++ libkf5libkleo-22.12.3/debian/libkf5libkleo5t64.install  2022-12-20 
00:37:31.0 +
@@ -0,0 +1,2 @@
+usr/lib/*/libKF5Libkleo.so.5
+usr/lib/*/libKF5Libkleo.so.5.*
di

Bug#1061881: akonadi-search: NMU diff for 64-bit time_t transition

[Steve Langasek]

Source: akonadi-search
Version: 4:22.12.3-1
Severity: serious
Tags: patch pending
Justification: library ABI skew on upgrade
User: debian-...@lists.debian.org
Usertags: time-t

Dear maintainer,

As part of the 64-bit time_t transition required to support 32-bit
architectures in 2038 and beyond
(https://wiki.debian.org/ReleaseGoals/64bit-time), we have identified
akonadi-search as a source package shipping runtime libraries whose ABI
either is affected by the change in size of time_t, or could not be
analyzed via abi-compliance-checker (and therefore to be on the safe
side we assume is affected).

To ensure that inconsistent combinations of libraries with their
reverse-dependencies are never installed together, it is necessary to
have a library transition, which is most easily done by renaming the
runtime library package.

Since turning on 64-bit time_t is being handled centrally through a change
to the default dpkg-buildflags (https://bugs.debian.org/1037136), it is
important that libraries affected by this ABI change all be uploaded close
together in time.  Therefore I have prepared a 0-day NMU for akonadi-search
which will initially be uploaded to experimental if possible, then to
unstable after packages have cleared binary NEW.

Please find the patch for this NMU attached.

If you have any concerns about this patch, please reach out ASAP.  Although
this package will be uploaded to experimental immediately, there will be a
period of several days before we begin uploads to unstable; so if information
becomes available that your package should not be included in the transition,
there is time for us to amend the planned uploads.



-- System Information:
Debian Release: trixie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 6.5.0-14-generic (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru akonadi-search-22.12.3/debian/changelog 
akonadi-search-22.12.3/debian/changelog
--- akonadi-search-22.12.3/debian/changelog 2023-03-01 20:32:14.0 
+
+++ akonadi-search-22.12.3/debian/changelog 2024-01-29 23:05:33.0 
+
@@ -1,3 +1,10 @@
+akonadi-search (4:22.12.3-1.1) experimental; urgency=medium
+
+  * Non-maintainer upload.
+  * Rename libraries for 64-bit time_t transition.
+
+ -- Steve Langasek   Mon, 29 Jan 2024 23:05:33 +
+
 akonadi-search (4:22.12.3-1) unstable; urgency=medium
 
   [ Patrick Franz ]
diff -Nru akonadi-search-22.12.3/debian/control 
akonadi-search-22.12.3/debian/control
--- akonadi-search-22.12.3/debian/control   2023-03-01 18:27:15.0 
+
+++ akonadi-search-22.12.3/debian/control   2024-01-29 23:05:33.0 
+
@@ -74,7 +74,9 @@
  .
  This package contains runtime plugins.
 
-Package: libkf5akonadisearchcore5
+Package: libkf5akonadisearchcore5t64
+Replaces: libkf5akonadisearchcore5
+Breaks: libkf5akonadisearchcore5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: libkf5akonadisearch-data (>= ${source:Version}),
@@ -85,18 +87,22 @@
 Description: Akonadi search core library
  Internal library used to search in the Akonadi PIM data server.
  This package contains the core library.
-Provides: ${ABI:VirtualPackage},
+Provides: ${ABI:VirtualPackage},, ${t64:Provides}
 
-Package: libkf5akonadisearchdebug5
+Package: libkf5akonadisearchdebug5t64
+Replaces: libkf5akonadisearchdebug5
+Breaks: libkf5akonadisearchdebug5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends},
 Description: Akonadi search debug library
  Internal library used to search in the Akonadi PIM data server.
  This package contains the debug library.
-Provides: ${ABI:VirtualPackage},
+Provides: ${ABI:VirtualPackage},, ${t64:Provides}
 
-Package: libkf5akonadisearchpim5
+Package: libkf5akonadisearchpim5t64
+Replaces: libkf5akonadisearchpim5
+Breaks: libkf5akonadisearchpim5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends},
@@ -104,13 +110,15 @@
 libkf5akonadisearch-plugins (= ${binary:Version}),
 Description: Akonadi search library
  Library used to search in the Akonadi PIM data server.
-Provides: ${ABI:VirtualPackage},
+Provides: ${ABI:VirtualPackage},, ${t64:Provides}
 
-Package: libkf5akonadisearchxapian5
+Package: libkf5akonadisearchxapian5t64
+Replaces: libkf5akonadisearchxapian5
+Breaks: libkf5akonadisearchxapian5 (<< ${source:Version})
 Architecture: any
 Multi-Arch: same
 Depends: ${misc:Depends}, ${shlibs:Depends},
 Description: Akonadi search xapian library
  Internal library used to search in the Akonadi PIM data server.
  This package contains the xapian library.
-Provides: ${ABI:VirtualPackage},
+Provides: ${ABI:VirtualPackage},

Bug#1061689: kdevelop512-libs: identified for time_t transition but no ABI in shlibs

[Steve Langasek]

Package: kdevelop512-libs
Version: 4:23.08.1-2
Severity: serious
User: debian-...@lists.debian.org
Usertags: time-t

Hi Pino,

Analysis of the archive for the 64-bit time_t transition[0][1] identifies
kdevelop512-libs as an affected package, on the basis that the headers could
not be compiled and analyzed out of the box using abi-compliance-checker[2],
so we have to assume it's affected.

However, kdevelop512-libs's shlibs file declares a dependency on a library
package name that contains no ABI information:

$ cat DEBIAN/shlibs
libKDevPlatformDebugger 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformDocumentation 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformInterfaces 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformLanguage 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformOutputView 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformProject 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformSerialization 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformShell 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformSublime 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformUtil 512 kdevelop512-libs (>= 4:23.08.1)
libKDevPlatformVcs 512 kdevelop512-libs (>= 4:23.08.1)
$

It is therefore not obvious that we should rename the package to
'kdevelop512-libs-t64' as part of this transition.

Looking at the archive, there are packages that depend on these libraries
built from other source packages, kdevelop-php and kdevelop-python.

Since there is no self-evident thing to do with the library package name
here, we will not be handling this package as part of the mass NMUs. 
Instead I am filing a serious bug because partial upgrades from bookworm to
trixie on 32-bit architectures will result in ABI skew and may result in
broken behavior.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org

[0] https://wiki.debian.org/ReleaseGoals/64bit-time
[1] https://lists.debian.org/debian-devel/2024/01/msg00041.html
[2] 
https://adrien.dcln.fr/misc/armhf-time_t/2024-01-17/logs/kdevelop-dev/base/log.txt


signature.asc
Description: PGP signature

Bug#1034830: qtbase5-private-dev ships header that requires cbor.h without dependency

[Steve Langasek]

 as
  qt5/QtPrintSupport/5.15.8/QtPrintSupport/private/qprint_p.h
- qt5/QtTest/5.15.8/QtTest/private/qxctestlogger_p.h, which includes
  dispatch/dispatch.h; was in libdispatch-dev but removed from archive
- qt5/QtWidgets/5.15.8/QtWidgets/private/qt_widgets_pch.h, which includes
  ../../gui/kernel/qt_gui_pch.h, but this file is available at
  qt5/QtGui/5.15.8/QtGui/private/qt_gui_pch.h
- qt5/QtXcb/5.15.8/QtXcb/private/qxcbconnection.h, which includes
  xcb/randr.h from libxcb-randr0-dev
- qt5/QtXcb/5.15.8/QtXcb/private/qxcbclipboard.h, which includes
  xcb/xfixes.h from libxcb-xfixes0-dev
- qt5/QtXcb/5.15.8/QtXcb/private/qxcbscreen.h, which includes xcb/xinerama.h
  from libxcb-xinerama0-dev
- qt5/QtXcb/5.15.8/QtXcb/private/qxcbimage.h, which includes xcb/xcb_image.h
  from libxcb-image0-dev
- qt5/QtXcb/5.15.8/QtXcb/private/qxcbkeyboard.h, which includes
  xcb/xcb_keysyms.h from libxcb-keysyms1-dev
- qt5/QtXcb/5.15.8/QtXcb/private/qxcbkeyboard.h, which includes xcb/xkb.h
  from libxcb-xkb-dev
- qt5/QtXcb/5.15.8/QtXcb/private/qxcbkeyboard.h, which includes
  xkbcommon/xkbcommon-x11.h from libxkbcommon-x11-dev
- qt5/QtXcb/5.15.8/QtXcb/private/qxcbwindow.h, which includes xcb/sync.h
  from libxcb-sync-dev
- qt5/QtCore/5.15.8/QtCore/private/qfunctions_fake_env_p.h references a
  non-existent 'errno_t' type

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Bug#950127: pyside2 fails all autopkg tests

[Steve Langasek]

Package: pyside2
Followup-For: Bug #950127
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

These tests fail because the test dependencies are always buggy when there
is more than one supported version of python in the archive; the tests
invoke py3versions to enumerate the versions of python to test against, but
there is no test dependency on python3-all, so no version of python other
than the default python3 is guaranteed to be installed.

The attached patch should fix this; I've uploaded this change to Ubuntu. 
Please consider including it in Debian as well.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru pyside2-5.14.0/debian/control pyside2-5.14.0/debian/control
--- pyside2-5.14.0/debian/control   2020-02-10 16:13:30.0 -0800
+++ pyside2-5.14.0/debian/control   2020-02-17 16:43:21.0 -0800
@@ -1,8 +1,7 @@
 Source: pyside2
 Section: python
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Qt/KDE Maintainers 

+Maintainer: Debian Qt/KDE Maintainers 
 Uploaders: Sophie Brun ,
Raphaël Hertzog ,
   Sebastien Delafond 
diff -Nru pyside2-5.14.0/debian/tests/control 
pyside2-5.14.0/debian/tests/control
--- pyside2-5.14.0/debian/tests/control 2020-02-10 16:13:08.0 -0800
+++ pyside2-5.14.0/debian/tests/control 2020-02-17 16:43:21.0 -0800
@@ -1,156 +1,156 @@
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtcore 
PySide2.QtCore
-Depends: python3-pyside2.qtcore
+Depends: python3-pyside2.qtcore, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtwidgets 
PySide2.QtWidgets
-Depends: python3-pyside2.qtwidgets
+Depends: python3-pyside2.qtwidgets, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qt3drender 
PySide2.Qt3DRender
-Depends: python3-pyside2.qt3drender
+Depends: python3-pyside2.qt3drender, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtquick 
PySide2.QtQuick
-Depends: python3-pyside2.qtquick
+Depends: python3-pyside2.qtquick, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qtpositioning PySide2.QtPositioning
-Depends: python3-pyside2.qtpositioning
+Depends: python3-pyside2.qtpositioning, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtx11extras 
PySide2.QtX11Extras
-Depends: python3-pyside2.qtx11extras
+Depends: python3-pyside2.qtx11extras, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtqml 
PySide2.QtQml
-Depends: python3-pyside2.qtqml
+Depends: python3-pyside2.qtqml, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qtwebenginecore PySide2.QtWebEngineCore
-Depends: python3-pyside2.qtwebenginecore
+Depends: python3-pyside2.qtwebenginecore, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qttexttospeech PySide2.QtTextToSpeech
-Depends: python3-pyside2.qttexttospeech
+Depends: python3-pyside2.qttexttospeech, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qthelp 
PySide2.QtHelp
-Depends: python3-pyside2.qthelp
+Depends: python3-pyside2.qthelp, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qtscripttools PySide2.QtScriptTools
-Depends: python3-pyside2.qtscripttools
+Depends: python3-pyside2.qtscripttools, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtnetwork 
PySide2.QtNetwork
-Depends: python3-pyside2.qtnetwork
+Depends: python3-pyside2.qtnetwork, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qtmultimediawidgets PySide2.QtMultimediaWidgets
-Depends: python3-pyside2.qtmultimediawidgets
+Depends: python3-pyside2.qtmultimediawidgets, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtlocation 
PySide2.QtLocation
-Depends: python3-pyside2.qtlocation
+Depends: python3-pyside2.qtlocation, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qt3dlogic 
PySide2.Qt3DLogic

Bug#939362: grantlee5: FTBFS with Qt 5.12.4 in experimental

[Steve Langasek]

Source: grantlee5
Version: 5.1.0-2.1
Severity: serious
Tags: experimental
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan

Dear maintainers,

The grantlee5 package fails to build with the version of Qt in experimental,
5.12.4.  This was discovered because Ubuntu also has Qt 5.12.4 in its devel
series, so grantlee5 5.1.0-2.1 has failed to build on all architectures:

[...]
FAIL!  : TestInternationalization::testIntegers(integer-02) Compared values are 
not the same
   Actual   (frLocalizer->localizeNumber(integer)): "7\u202F000"
   Expected (frInteger)   : "7\u00A"
   Loc: [/<>/templates/tests/testinternationalization.cpp(838)]
[...]
Totals: 67 passed, 8 failed, 0 skipped, 0 blacklisted, 22ms
* Finished testing of TestInternationalization *

11/12 Test #12: plainmarkupbuildertest ...   Passed0.03 sec
12/12 Test #11: htmlbuildertest ..   Passed0.04 sec

92% tests passed, 1 tests failed out of 12

Total Test time (real) =   0.12 sec

The following tests FAILED:
 10 - testinternationalization (Failed)
Errors while running CTest
make[2]: *** [Makefile:76: test] Error 8
[...]

  (https://launchpad.net/ubuntu/+source/grantlee5/5.1.0-2.1)

I don't know why the behavior of Qt has changed, but this will eventually
become a serious bug on grantlee5 in unstable once Qt is updated there.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Bug#707851: Soften the the wording recommending menu files: let's do it in Jessie.

[Steve Langasek]

On Sun, Jan 05, 2014 at 02:53:12PM +0900, Charles Plessy wrote:
 9.6. Menus
 --

  Two menu systems are used in Debian: the _FreeDesktop menu_ and the
  1   _Debian menu system_.  Packages shipping applications that belong to
  one or both menu systems should provide the necessary entry files to
  integrate with them.

I don't think this is off to a particularly good start.  The purpose of
Policy is to provide maintainers with concrete guidance about how to
integrate with the rest of the system.  Telling maintainers there are these
two systems and you can integrate with either of them as appropriate is not
really providing much guidance.  It doesn't tell maintainers how to
determine which menu system their package belongs to, and it doesn't tell
maintainers of packages that want to consume a menu which one they should
use.

Furthermore, I think the idea of an application belonging to one system or
the other is misplaced.  The purpose of both the original menu system and
the freedesktop standard is to give users consistent, menu-driven access to
the software installed on the computer.  While a given desktop environment
is going to give precedence to software that is integrated with that desktop
environment, users should be able to expect that they can access all
software installed on the system through the GUI, via the appropriate
submenus.  Telling maintainers to integrate with one of two different menu
systems does not achieve this.

So if the Debian menu system is insufficiently expressive to meet our needs,
we should be giving clear advice for the use of the fdo menu system.

 * Unless hidden by default, the desktop entry must point to a PNG
   or SVG icon with a transparent background, providing at least the
   22x22 size, and preferably up to 64x64.  The icon should be
   neutral enough to ingrate well with the default icon themes.  It

integrate

 * In doubt, the package maintainer should coordinate with the
   maintainers of menu implementations through the _debian-desktop_
   mailing list in order to avoid problems with categories or bad
   interactions with other icons.  Especially for packages which are
   part of installation tasks, the contents of the
   `NotShowIn'/`OnlyShowIn' keys should be validated by the
   maintainers of the relevant environments.

As a first cut this seems ok, but I would prefer to see more concrete
guidance recorded in policy about what values of NotShowIn/OnlyShowIn should
be used and when.

 9.7. Multimedia handlers
 

  Media types (formerly known as MIME types, Multipurpose Internet Mail
  3   Extensions, RFCs 2045-2049) is a mechanism for encoding files and data
  streams and providing meta-information about them, in particular their
  type and format (e.g.  `image/png', `text/html', `audio/ogg').

  #   Registration of media type handlers allows programs like mail user
  #   agents and web browsers to invoke these handlers to view, edit or
  #   display media types they don't support directly.

  Packages which provide programs to view/show/play, compose, edit or
  print media types should register them using either the _FreeDesktop_
  system or the _mailcap_ system.

Again, I do not believe an either/or recommendation is appropriate here. 
This is abdicating the responsibility of Policy to provide concrete advice
to maintainers.

I believe we are at the point that we should be recommending a preference
for the fdo MIME interfaces, together with appropriate transition handling
to ensure proper integration with mime-support.  It's possible that the
transition is already handled transparently by the mime-support package and
its triggers, such that no additional dependencies need to be added anywhere
(since /etc/mailcap is already owned by mime-support, clearly any package
which is consuming it should already be depending on it).  In that case, no
additional policy language is needed, other than to make it clear which of
these two interfaces we are recommending that maintainers use.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#639300: Bug#707301: release-notes: odbcinst1debian2 : Breaks: tdsodbc ( 0.82-8) but 0.82-7 is to be installed

[Steve Langasek]

-mysql [ amd64 ]  none 
- 1.7.2-3  ( misc ) (= 1.7.2-3)
  Considering akonadi-backend-mysql:amd64 -1 as a solution to 
akonadi-server:amd64 1
  Try Installing akonadi-backend-mysql [ amd64 ]  none - 1.7.2-3  ( misc ) 
before changing akonadi-server:amd64
Investigating (1) tdsodbc [ amd64 ]  0.82-7 - 0.91-2  ( libs )
Broken tdsodbc:amd64 Breaks on libiodbc2 [ amd64 ]  3.52.6-4 - 3.52.7-2  ( 
libs )
  Considering libiodbc2:amd64 2 as a solution to tdsodbc:amd64 0
  Holding Back tdsodbc:amd64 rather than change libiodbc2:amd64
Investigating (2) odbcinst1debian2 [ amd64 ]  2.2.14p2-1 - 2.2.14p2-5  ( 
libs )
Broken odbcinst1debian2:amd64 Breaks on tdsodbc [ amd64 ]  0.82-7 - 0.91-2  
( libs ) ( 0.82-8)
  Considering tdsodbc:amd64 0 as a solution to odbcinst1debian2:amd64 3
  Upgrading tdsodbc:amd64 due to Breaks field in odbcinst1debian2:amd64
Investigating (2) tdsodbc [ amd64 ]  0.82-7 - 0.91-2  ( libs )
Broken tdsodbc:amd64 Breaks on libiodbc2 [ amd64 ]  3.52.6-4 - 3.52.7-2  ( 
libs )
  Considering libiodbc2:amd64 2 as a solution to tdsodbc:amd64 0
  Holding Back tdsodbc:amd64 rather than change libiodbc2:amd64

snip here - repeats until recursion limit is reached

Done
The following packages have unmet dependencies:
 odbcinst1debian2 : Breaks: tdsodbc ( 0.82-8) but 0.82-7 is to be installed
E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.


-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru soprano-2.7.6+dfsg.1/debian/changelog soprano-2.7.6+dfsg.1/debian/changelog
--- soprano-2.7.6+dfsg.1/debian/changelog	2013-03-01 07:57:01.0 -0800
+++ soprano-2.7.6+dfsg.1/debian/changelog	2013-05-11 11:44:33.0 -0700
@@ -1,3 +1,11 @@
+soprano (2.7.6+dfsg.1-2wheezy1.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Build without iODBC, to make KDE co-installable with multiarch-enabled
+ODBC drivers.  Closes: #639300, LP: #901638.
+
+ -- Steve Langasek vor...@debian.org  Sat, 11 May 2013 11:25:31 -0700
+
 soprano (2.7.6+dfsg.1-2wheezy1) testing-proposed-updates; urgency=low
 
   * Team upload.
diff -Nru soprano-2.7.6+dfsg.1/debian/control soprano-2.7.6+dfsg.1/debian/control
--- soprano-2.7.6+dfsg.1/debian/control	2013-02-07 05:40:14.0 -0800
+++ soprano-2.7.6+dfsg.1/debian/control	2013-05-11 11:25:18.0 -0700
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (= 7.4.15), cmake (= 2.6.2), pkg-kde-tools (= 0.12),
  dpkg-dev (= 1.15.5), libclucene-dev (= 0.9.21b), libqt4-dev (= 4:4.5.3),
  libraptor1-dev (= 1.4.16), librdf0-dev (= 1.0.13),
- doxygen (= 1.7.1), graphviz, libiodbc2-dev
+ doxygen (= 1.7.1), graphviz, libvirtodbc0, unixodbc-dev
 Standards-Version: 3.9.3
 Homepage: http://soprano.sourceforge.net
 Vcs-Browser: http://git.debian.org/?p=pkg-kde/kde-req/soprano.git
@@ -15,7 +15,7 @@
 Package: soprano-daemon
 Section: utils
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}
+Depends: libvirtodbc0, ${shlibs:Depends}, ${misc:Depends}
 Recommends: libsoprano4 (= ${binary:Version})
 Suggests: virtuoso-minimal
 Breaks: libsoprano4 ( 2.3.0+dfsg.1-1), libsoprano-dev ( 2.3.0+dfsg.1-1)
diff -Nru soprano-2.7.6+dfsg.1/debian/patches/no-odbc-dm soprano-2.7.6+dfsg.1/debian/patches/no-odbc-dm
--- soprano-2.7.6+dfsg.1/debian/patches/no-odbc-dm	1969-12-31 16:00:00.0 -0800
+++ soprano-2.7.6+dfsg.1/debian/patches/no-odbc-dm	2013-05-11 11:24:46.0 -0700
@@ -0,0 +1,41 @@
+Description: Build without iODBC
+ Add support for soprano to link directly against virtodbc_r.so instead of
+ using the libiodbc driver manager.  Given that virtuoso is hard-coded as
+ the driver, the use of a driver manager is an unnecessary indirection; and
+ the manner of the hard-coding makes it harder than it ought to be to
+ switch from iODBC to UnixODBC - so just eliminate the DM entirely.
+ .
+ This does mean we're using an rpath, but that's a lesser evil given that
+ the path to the library is otherwise hard-coded in the source anyway.
+Author: Steve Langasek vor...@debian.org
+Bug-Debian: http://bugs.debian.org/639300
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/901638
+
+Index: soprano-2.7.5+dfsg.1/cmake/modules/FindIODBC.cmake
+===
+--- soprano-2.7.5+dfsg.1.orig/cmake/modules/FindIODBC.cmake
 soprano-2.7.5+dfsg.1/cmake/modules/FindIODBC.cmake
+@@ -57,10 +57,7 @@
+   ${iodbc_INCLUDE_DIRS}
+   )
+ 
+-find_library(IODBC_LIBRARIES NAMES iodbc
+-  HINTS
+-  ${iodbc_LIBRARY_DIRS}
+-  )
++set(IODBC_LIBRARIES /usr/lib/odbc/virtodbc_r.so)
+ 
+ if (IODBC_LIBRARIES AND IODBC_INCLUDE_DIR)
+ #  set(IODBC_INCLUDE_DIR ${IODBC_INCLUDE_DIR}/iodbc)
+Index: soprano-2.7.5+dfsg.1/backends/virtuoso/CMakeLists.txt

Bug#639300: Bug#707301: release-notes: odbcinst1debian2 : Breaks: tdsodbc ( 0.82-8) but 0.82-7 is to be installed

[Steve Langasek]

On Sat, May 11, 2013 at 09:18:03PM +0200, Sune Vuorela wrote:
 [recipients trimmed]
  I recommend applying the patch from bug #639300 in a stable update, instead
  of leaving akonadi/virtuoso un-coinstallable with all ODBC drivers in
  wheezy.  Attached is an updated patch for this issue.

 My recommendation is to have unixodbc drop the useless and broken Breaks.

The breaks are not from unixodbc, they are from the ODBC *drivers*, which
are no longer in a path that libiodbc2 will find.  No one has stepped up to
make libiodbc2 multiarch-capable, and I find it unlikely that this would be
acceptable to fix in a stable update.  Thus the breaks are legitimate and
correct.

  KDE maintainers: would you prefer to prepare a different fix yourselves for
  this issue, or upload this patch yourself?

 I guess I can NMU unixodbc if you prefer, given that is the good fix.

No, you have misunderstood the problem.

 iodbc is what upstream and most distributions uses here, and I see no reason 
 to deviate from upstream here. 

 iodbc is the one supported and written by virtuoso upstream, so that's the
 one we prefer to use.

iodbc is the one being *abused* by virtuoso upstream.  Soprano does not work
with arbitrary ODBC drivers; the use of a driver manager (in this case,
iODBC) is a pointless indirection - as I've demonstrated, with my tested
patch.  The iodbc package in Debian has been unmaintained for years; a
simple patch to soprano to remove the dependency on iodbc altogether is all
that's needed here.

If you're willing to maintain libiodbc2 just for the sake of virtuoso, then
fine, maintain it.  But no one has been maintaining it for 4 years, and it
went out the door broken and unusable as an ODBC DM because no one has
ported it for use with multiarch while almost all of the ODBC drivers have
been multiarch-enabled in wheezy.  The only reason this bug doesn't affect
soprano as well is that soprano isn't *using* it as a DM except in the
loosest sense of the word.  So as things stand now, libiodbc2 is useless as
a DM because it's incompatible with any of the drivers that users are going
to configure it to use, and the Breaks are there to reflect that and ensure
partial upgrades don't give users broken ODBC for other squeeze revdeps of
libiodbc2.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#582953: kmail deleted all non-local incoming mail settings on upgrade

[Steve Langasek]

tags 582953 wheezy-ignore
thanks

As noted in message #55, this issue has been present since at least etch. 
It has seen no activity since September 2011, and it's never been reproduced
except by someone reporting similar behavior on an unsupported filesystem
(ZFS).  I don't see any way that we would drop kmail from the wheezy release
for this bug, or delay the wheezy release for it, and it's clear that no
action is going to be taken on the bug if people can't reproduce it. 
Therefore, I'm marking this bug wheezy-ignore.

Juha, I think this bug is never going to be fixed unless someone can give us
a clear path to reproducing it.  I think you're the person in a best
position to do this.  I don't want to close this bug or downgrade it since
the symptoms describe do still qualify as grave, but without some more
input from those affected, I just don't think it's realistic that it will
get fixed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev

[Steve Langasek]

Hey there,

This patch to soprano has been included in Ubuntu now for a couple of weeks
and nothing's exploded.  I see that the KDE transition is also done now. 
Could this change be included in the Debian package?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev

[Steve Langasek]

On Tue, Mar 06, 2012 at 09:47:40AM +0100, Sebastian Trüg wrote:
 to be honest: I did not know that this was even possible. I would gladly
 apply this to upstream Soprano if you could provide a generic non-Debian
 specific patch.

I'm not very cmake literate, so I probably won't be able to provide a
generic patch on my own.  Maybe one of the Debian KDE maintainers can help?

Effectively what we need is an implementation of findVirtuosoDriver() in
cmake:

return Soprano::findLibraryPath( virtodbc_r, QStringList(), QStringList() 
 QLatin1String( virtuoso/plugins/ )  QLatin1String( odbc/ ) );

We can't use find_library() because this isn't strictly speaking a library
(it has no soname, it's not named libfoo.so so we can't link against it
with -l); it's a DSO, and it happens to be possible to link against DSOs
when using glibc, and it happens to be *safe* in this case because we have a
stable ABI as defined by ODBC.  I don't know if there's a similar cmake
idiom for finding DSOs.  I guess you can use find_path()?

And as I said, linking to a DSO isn't portable to all Unices.  So the code
should probably still give preference to libiodbc if it's available.


 Also did you test this? Did you run the Virtuoso unit test?

I ran virtuosobackendtest from the tree, which I think is what you're
referring to.  Linking directly to virtodbc_r.so gives the same test results
as linking to libiodbc (23 pass, 3 fail).

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


 On 03/06/2012 08:47 AM, Steve Langasek wrote:
  Hi Sebastian, nice to meet you!
  
  On Tue, Mar 06, 2012 at 01:34:45AM +0100, Pino Toscano wrote:
  
  Alle martedì 6 marzo 2012, Steve Langasek ha scritto:
  I'm surprised to say that after sitting on this bug for far too long,
  it turns out that it's trivial to fix.  Although it had been
  reported that soprano would not work with unixodbc, once I actually
  installed virtuoso, which the soprano test suite silently depends
  on, I get the same results from test/virtuosobackendtest when built
  against either iODBC or UnixODBC.
  
  I remember Sebastian Trueg (main soprano upstream) strongly recommending 
  against using unixODBC (e.g. in [2], just last September), so I'm not 
  sure whether this switch would break anything in the semantic desktop 
  stack.
  (Disclaimer: I don't use Nepomuk myself.)
  
  Sebastian, what is the current status of soprano wrt unixODBC/iODBC?
  Which problems would result in using unixODBC?
  
  [2] http://trueg.wordpress.com/2011/09/22/about-strigi-soprano-virtuoso-
  clucene-and-libstreamanalyzer/
  
  Right, so I've read the comment in that blog entry about needing libiodbc
  because of RDF extensions.  But I've reviewed the libiodbc source, and can't
  find any evidence that such extensions exist - there's a single RDF define
  in the iodbcext.h header, but a copy of this header is shipped in the
  soprano source and there are no uses of the define anyway.  As best as I can
  tell, the only extensions are in the virtuoso driver, which libiodbc2 merely
  passes the requests through to - and unixodbc would appear to do the very
  same.
  
  The one thing I have found that's different between iODBC and UnixODBC (but
  not represented in the previous patch) is that UnixODBC will not allow
  look-up of a driver by filename alone; it requires that the filename match
  the filename for a driver registered with odbcinst.ini.  This seems like a
  feature that we could patch into UnixODBC easily enough if needed.  (And
  apparently there was something wrong with my previous testing that I didn't
  catch this.)
  
  However, I wonder why it makes sense for soprano to use a driver manager at
  all, given that it appears soprano can *only* use the virtuoso driver as a
  backend.  Wouldn't it be simpler to call into the virtuoso driver directly
  and omit the driver manager, on Unix?
  
  Attached is a revised patch to the Debian that implements the above
  proposal.  Since UnixODBC is no longer involved (except as a provider of the
  sql.h header) there should not be any compatibility issues here.  It may not
  be portable to non-Linux systems, but maybe it would be an acceptable distro
  patch, Pino?
  
  I'm happy to upload this as an NMU if you would like.  It's probably
  worth an upload ASAP rather than waiting for 2.7.5+dfsg.1-1 to
  migrate to testing, since it's hard to have usable ODBC drivers for
  soprano until it's fixed.
  
  We're currently just started our KDE 4.7 transition, which includes also 
  a soprano update from 2.6 to 2.7; if possible, I think IMHO it would be 
  desiderable to wait for such dependency change, in case, after the 
  transition is over (hopefully in two weeks, if everything goes fine).
  Would

Bug#639300: please build against unixodbc-dev instead of libiodbc2-dev

[Steve Langasek]

tags 639300 patch
thanks

Dear maintainers,

I'm surprised to say that after sitting on this bug for far too long, it
turns out that it's trivial to fix.  Although it had been reported that
soprano would not work with unixodbc, once I actually installed virtuoso,
which the soprano test suite silently depends on, I get the same results
from test/virtuosobackendtest when built against either iODBC or UnixODBC.

So I think the attached patch would be safe to apply to soprano, fixing this
longstanding issue.

I'm happy to upload this as an NMU if you would like.  It's probably worth
an upload ASAP rather than waiting for 2.7.5+dfsg.1-1 to migrate to testing,
since it's hard to have usable ODBC drivers for soprano until it's fixed.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru soprano-2.7.5+dfsg.1/debian/changelog soprano-2.7.5+dfsg.1/debian/changelog
--- soprano-2.7.5+dfsg.1/debian/changelog	2012-03-04 20:55:08.0 +
+++ soprano-2.7.5+dfsg.1/debian/changelog	2012-03-05 23:49:53.0 +
@@ -1,3 +1,10 @@
+soprano (2.7.5+dfsg.1-1.1) UNRELEASED; urgency=low
+
+  * Non-maintainer upload.
+  * Build against unixodbc.  Closes: #639300, LP: #901638.
+
+ -- Steve Langasek vor...@debian.org  Mon, 05 Mar 2012 23:49:13 +
+
 soprano (2.7.5+dfsg.1-1) unstable; urgency=low
 
   * Team upload.
diff -Nru soprano-2.7.5+dfsg.1/debian/control soprano-2.7.5+dfsg.1/debian/control
--- soprano-2.7.5+dfsg.1/debian/control	2012-03-04 20:43:25.0 +
+++ soprano-2.7.5+dfsg.1/debian/control	2012-03-05 23:49:41.0 +
@@ -6,7 +6,7 @@
 Build-Depends: debhelper (= 7.4.15), cmake (= 2.6.2), pkg-kde-tools (= 0.12),
  dpkg-dev (= 1.15.5), libclucene-dev (= 0.9.21b), libqt4-dev (= 4.5.3),
  libraptor1-dev (= 1.4.16), librdf0-dev (= 1.0.13),
- doxygen (= 1.7.1), graphviz, libiodbc2-dev
+ doxygen (= 1.7.1), graphviz, unixodbc-dev
 Standards-Version: 3.9.2
 Homepage: http://soprano.sourceforge.net
 Vcs-Browser: http://git.debian.org/?p=pkg-kde/kde-req/soprano.git
diff -Nru soprano-2.7.5+dfsg.1/debian/patches/series soprano-2.7.5+dfsg.1/debian/patches/series
--- soprano-2.7.5+dfsg.1/debian/patches/series	2012-03-04 20:33:22.0 +
+++ soprano-2.7.5+dfsg.1/debian/patches/series	2012-03-05 23:49:41.0 +
@@ -2,3 +2,4 @@
 disable_usr_lib_install_rpath.diff
 doxyfile_generate_tagfile.diff
 redland_raptor2_support.h
+unixodbc
diff -Nru soprano-2.7.5+dfsg.1/debian/patches/unixodbc soprano-2.7.5+dfsg.1/debian/patches/unixodbc
--- soprano-2.7.5+dfsg.1/debian/patches/unixodbc	1970-01-01 00:00:00.0 +
+++ soprano-2.7.5+dfsg.1/debian/patches/unixodbc	2012-03-05 23:49:41.0 +
@@ -0,0 +1,21 @@
+Description: Build against unixodbc
+ Add support for soprano to build against unixodbc.  Thanks to some hints
+ from Alban Browaeys, I've found that the virtuosobackendtest test suite
+ works just as well with either unixodbc or iodbc, you just have to have
+ the virtuoso-opensource-6.1-bin package installed first to avoid
+ incomprehensible test failures.
+Author: Steve Langasek vor...@debian.org
+Bug-Debian: http://bugs.debian.org/639300
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/901638
+
+--- soprano-2.6.0+dfsg.1.orig/cmake/modules/FindIODBC.cmake
 soprano-2.6.0+dfsg.1/cmake/modules/FindIODBC.cmake
+@@ -57,7 +57,7 @@ find_path(IODBC_INCLUDE_DIR sql.h
+   ${iodbc_INCLUDE_DIRS}
+   )
+ 
+-find_library(IODBC_LIBRARIES NAMES iodbc
++find_library(IODBC_LIBRARIES NAMES odbc iodbc
+   HINTS
+   ${iodbc_LIBRARY_DIRS}
+   )

Bug#639300: libiodbc2 -- iODBC Driver Manager orphaned

[Steve Langasek]

On Sat, Nov 19, 2011 at 02:14:56PM +0100, glpk xypron wrote:
  This week with Christoph Berg's help, unixodbc has been converted for
  multiarch in unstable along with the common drivers: libmyodbc,
  tdsodbc, and odbc-postgresql.  The converted drivers are now all installed 
  in
  /usr/lib/arch/odbc, and the /etc/odbcinst.ini config has been updated to
  use relative paths instead of absolute ones.

  libiodbc2, which has been orphaned for nearly three years, has *not* been
  updated for multiarch, and so libiodbc will fail to locate these drivers on
  disk.  As a result, these drivers declare a Breaks: against libiodbc2.

 I guess the problem is not about iODBC finding shared drivers like
 libmyodbc.

You guess wrong.  I put the Breaks there, I'm telling you why they were
added.

 Instead a driver build against unixODBC is not compatible with one build
 against iODBC.  See bug #598787.

The lack of 100% compatibility between iODBC and unixODBC is another issue;
it's one that could be solved if there were a good reason to keep two ODBC
driver managers in the archive, but there isn't.  Thus we should just get
rid of libiodbc; but this is currently blocked on soprano's lack of
compatibility with unixodbc.

 This means if both iODBC and unixODBC are kept, separate packages
 for libmyodbc are needed.

That will absolutely never happen.

 I guess the next step should be to ask the upstream author
 of iODBC, if iODBC will be supported in future.

No, the next step is to figure out how to fix soprano, and then remove iODBC
from the archive.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Re: odbc-postgresql: can't be installed together with KDE any more

[Steve Langasek]

reassign 639300 soprano
retitle 639300 please build against unixodbc-dev instead of libiodbc2-dev
thanks

Hi folks,

This week with Christoph Berg's help, unixodbc has been converted for
multiarch in unstable along with the common drivers: libmyodbc, tdsodbc, and
odbc-postgresql.  The converted drivers are now all installed in
/usr/lib/arch/odbc, and the /etc/odbcinst.ini config has been updated to
use relative paths instead of absolute ones.

libiodbc2, which has been orphaned for nearly three years, has *not* been
updated for multiarch, and so libiodbc will fail to locate these drivers on
disk.  As a result, these drivers declare a Breaks: against libiodbc2.

I do not intend to update libiodbc2 for multiarch.  Instead, I would like to
propose its removal from the archive.  Historically, we have carried both
unixodbc and libiodbc2 in the archive to avoid a circular build-dependency:
Qt build-depends on ODBC for its database support, and UnixODBC
build-depends on Qt for its GUI tools.  The most recent upstream version of
UnixODBC resolves this, because in addition to being updated for Qt4, the
latest upstream release also splits the GUI tools into a separate source
distribution, which I have just uploaded to unstable.

So I am reassigning this bug to soprano.  KDE maintainers, please switch
soprano to build against unixodbc-dev instead of libiodbc2-dev.

(I will file separate bugs against the other reverse-dependencies, but for
soprano someone has beaten me to it.)

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#620576: kdelibs: please wipe out dependency_libs from .la files (Policy 10.2)

[Steve Langasek]

Package: kdelibs
Version: 4:3.5.10.dfsg.1-5
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu natty ubuntu-patch

Hi folks,

The attached patch has just been applied to the Ubuntu kdelibs package, to
null out the dependency_libs field in the libtool .la file being shipped in
the -dev package.  This is generally a good idea because it avoids causing
consumers of your library to require other .la files listed here to be
available at build time when they're not actually needed (i.e., in the
dynamic linking common case).  It's specifically a good idea right now
because multiarch is imminent, and that means the .la files referenced here
are going to *move* soon, causing build failures for anything using libtool
to build against kdelibs.  As long as kdelibs is going to need a rebuild to
fix up the invalid .la references, it would be nice to get rid of them
altogether.

(Alternatively, since I guess kde3 libs are supposed to be dropped soon, you
might just let this go unfixed and become a FTBFS for reverse-deps?  Your
call...)

Thanks,
--
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru kdelibs-3.5.10.dfsg.1/debian/rules kdelibs-3.5.10.dfsg.1/debian/rules
--- kdelibs-3.5.10.dfsg.1/debian/rules	2010-10-15 09:41:54.0 -0700
+++ kdelibs-3.5.10.dfsg.1/debian/rules	2011-04-02 12:59:52.0 -0700
@@ -91,6 +91,11 @@
 	  rm -f LIST; \
 	fi
 
+common-install-arch::
+	for file in debian/tmp/usr/lib/*.la; do \
+		sed -i /dependency_libs/ s/'.*'/''/ $$file ; \
+	done
+
 common-binary-predeb-indep::
 	-for file in `find ./ -name '*.pot'`; do\
 		if [ ! `echo $$file | grep './po/'` ]  [ ! `echo $$file | grep './debian/'` ]; then\

Re: Bug#507710: linux-image-2.6.26-1-amd64: CPU overload, Sound server fatal error.

[Steve Langasek]

reassign 507710 kdebase
thanks

On Wed, Dec 03, 2008 at 09:26:51PM +0100, Peter wrote:
 Package: linux-image-2.6.26-1-amd64
 Version: 2.6.26-10
 Severity: critical
 Justification: breaks the whole system

 Dear readers,
 At startup i get a pop-up with the message CPU overload, Sound server
 fatal error, aborting in my KDE3 environment.
 And than i have no sound anymore.
 I can't find any messages in the syslog or the messages logfile.

 My system is Sid/Lenny with kernel 2.6.26-1-amd64
 I have a dualboot with Opensuse, when i startup with Opensuse the CPU
 overload problem does not occur.

 The problem does not occur when i boot with the 2.6.24-1-amd64, but then
 i can't use my internal ATL1E networkcard.

This is far from proof positive that there's a kernel bug.  Frankly, I don't
even know what this error means, or what component is responsible for it; I
think we need a KDE maintainer to tell us what CPU overload means before
we can treat this as a kernel bug.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
[EMAIL PROTECTED] [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#393378: Bug#393356: Source package contains non-free IETF RFC/I-D's

[Steve Langasek]

tags 393356 etch-ignore
tags 393357 etch-ignore
tags 393358 etch-ignore 
tags 393359 etch-ignore
tags 393360 etch-ignore 
tags 393361 etch-ignore 
tags 393364 etch-ignore 
tags 393365 etch-ignore 
tags 393366 etch-ignore 
tags 393367 etch-ignore 
tags 393368 etch-ignore 
tags 393369 etch-ignore 
tags 393370 etch-ignore 
tags 393371 etch-ignore 
tags 393372 etch-ignore 
tags 393373 etch-ignore 
tags 393374 etch-ignore 
tags 393375 etch-ignore 
tags 393376 etch-ignore 
tags 393377 etch-ignore 
tags 393378 etch-ignore 
tags 393379 etch-ignore 
tags 393380 etch-ignore 
tags 393381 etch-ignore 
tags 393382 etch-ignore 
tags 393383 etch-ignore 
tags 393384 etch-ignore 
tags 393385 etch-ignore 
tags 393386 etch-ignore 
tags 393387 etch-ignore 
tags 393388 etch-ignore 
tags 393389 etch-ignore 
tags 393390 etch-ignore 
tags 393391 etch-ignore 
tags 393392 etch-ignore 
tags 393393 etch-ignore 
tags 393394 etch-ignore 
tags 393395 etch-ignore 
tags 393396 etch-ignore 
tags 393397 etch-ignore 
tags 393398 etch-ignore 
tags 393399 etch-ignore 
tags 393400 etch-ignore 
tags 393402 etch-ignore 
tags 393403 etch-ignore 
tags 393405 etch-ignore 
tags 393406 etch-ignore 
tags 393408 etch-ignore 
tags 393409 etch-ignore 
tags 393410 etch-ignore 
tags 393411 etch-ignore 
tags 393412 etch-ignore 
tags 393413 etch-ignore 
tags 393414 etch-ignore 
tags 393415 etch-ignore 
tags 393416 etch-ignore 
tags 393417 etch-ignore 
tags 393418 etch-ignore 
tags 393419 etch-ignore 
tags 393420 etch-ignore 
tags 393421 etch-ignore 
tags 393422 etch-ignore 
tags 393423 etch-ignore 
tags 393424 etch-ignore 
tags 393425 etch-ignore
thanks

Hi Simon,

On Mon, Oct 16, 2006 at 11:51:17AM +0200, Simon Josefsson wrote:
 This bug has been filed on multiple packages, and general discussions
 are kindly requested to take place on debian-legal or debian-devel in
 the thread with Subject: Non-free IETF RFC/I-Ds in source packages.

 It seems this source package contains the following files from the
 IETF under non-free license terms:

 apg-2.2.3/doc/rfc0972.txt 
 apg-2.2.3/doc/rfc1750.txt 

 The license on RFC/I-Ds is not DFSG-free, see:
  * http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=199810
  * http://release.debian.org/removing-non-free-documentation
  * http://wiki.debian.org/NonFreeIETFDocuments

 The etch release policy says binary and source packages must each be free:
  * http://release.debian.org/etch_rc_policy.txt

 The severity is serious, because this violates the Debian policy:
  * http://www.debian.org/doc/debian-policy/ch-archive.html#s-dfsg

 There are (at least) three ways to fix this problem.  In order of
 preference:

 1. Ask the author of the RFC to re-license the RFC under a free
license.  A template for this e-mail request can be found at
http://wiki.debian.org/NonFreeIETFDocuments

 2. Remove the non-free material from the source, e.g., by re-packaging
the upstream archive and adding a 'dfsg' version name to it.

 3. Move the package to non-free.

 I went over many packages looking for names of likely non-free files,
 and there may be false positives.  If this is the case for your
 package, I'm sorry for the noise.  I'll modify the scripts to take
 into account false positives when I learn of them, and publish the
 list of exceptions under Known exceptions at
 http://wiki.debian.org/NonFreeIETFDocuments.

Andi Barth and I have discussed these bugs, and we believe these bugs should
be granted an exception for etch, for the following reasons:

- As you mention, this mass-filing is based on file names and may include
  false positives for this reason.  Given this uncertainty, which covers
  both files that may not actually contain RFCs and RFCs that may be
  distributed with separate permissions from the authors, I do not consider
  it reasonable for the burden to be on the maintainers (and the release
  team) to demonstrate any particular bug to be a false-positive before the
  package can be included in the release.
- The time between the bug filing and the scheduled release of etch is now
  relatively short, and I don't believe, given the comparatively small
  impact of these bugs (where RC bugs are concerned), that they should
  warrant either delaying the release of etch or requiring the removal of a
  package so affected.  It is normal to allow some latitude for such license
  issues while they are being investigated/addressed.

I'm happy to see that a number of maintainers have already made uploads (or
are preparing uploads) to address these bugs, and I would encourage all
maintainers to try to address such bugs in their packages for release.  I am
also certainly happy to grant freeze exceptions for uploads fixing these
bugs.  We only will not treat these as bugs that must be fixed prior to
release.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED

Re: intent to do a poppler transition

[Steve Langasek]

On Thu, Oct 05, 2006 at 12:01:50PM +0200, Ondřej Surý wrote:
  - Since the API changed, shouldn't the -dev package change its name, or
is this information in the Library Packaging Guide controversial?  Or
even if it's generally consensual, should the name still be kept
unchanged because plain libpoppler doesn't guarantee any API anyway? 

 Step 1:
 Looks like ideal move would be to create libpoppler0.5-dev; -glib and
 -qt bindings didn't change API, so they could keep their name.

Six packages build-depend on libpoppler-dev, but I understand that only one
of them is affected by the API change; so it seems my concern about
cost/benefit of changing the package name still applies here.

 Step 2:
 And I will introduce debian specific SONAME for libpoppler, so we are
 not hit by random ABI changes.

Sounds good to me...

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: intent to do a poppler transition

[Steve Langasek]

On Tue, Oct 03, 2006 at 04:29:59PM +0200, Frank Küster wrote:
  0.5.4-2 is in experimental (i386) and can be used as base for
  transition.

 Well, we can use them as a base for testing.  However, it seems as if
 starting the transition would be a bit premature.  I have seen a couple
 of questions that are not yet answered:

 - Since the API changed, shouldn't the -dev package change its name, or
   is this information in the Library Packaging Guide controversial?

Yes, this is a very controversial recommendation in the library packaging
guide.  The recommendation there is to change the -dev package name for
*any* API changes, no matter how small a subset of reverse-dependencies may
be affected.  If there are 9 packages build-depending on poppler, 8 of them
can be binNMUed and one of them requires source changes to work with the new
version, it's not an effective use of developer resources to impose a -dev
package name change that will force maintainers of all 9 packages to make
sourceful uploads.

 - In any case, shouldn't we carefully check all affected packages,
   whether they FTBFS and whether they still work?  This would IMO
   require a phase where all of them are in experimental, except poppler
   itself in case it gets a new dev package name.

Yes, given the current release schedule, this new libpoppler transition will
only be considered for etch if someone does rebuild and test all the
reverse-dependencies, providing any necessary patches and documenting these
to the release team.

This doesn't require uploading all of the packages to experimental; anyone
wishing to work on this transition can do so in the environment of their
choice and report the results to debian-release and the BTS.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Re: Broken dependency of Kcontrol on Librwa1394

[Steve Langasek]

On Mon, Sep 25, 2006 at 06:38:10PM +0200, Pierre Habouzit wrote:
 Le lun 25 septembre 2006 15:11, [EMAIL PROTECTED] a écrit :
  Hi, further to my mail yesterday about the broken dependency of
  kcontrol on libraw1394-5, please find below a message sent to the
  libraw1394 maintainer and his answer.

  Is there a way to improve coordination amongst Debian maintainers and
  stop this finger-pointing attitude?

 there is no finger pointing going on. kdebase needs a binNMU (a rebuild) 
 to be built against the last version of the libraw1394. A thing that 
 ludovic should have asked for every reverse depends of that library.

  A user.

 But I'm partly responsible of this because I forgot to ask him to look 
 into this, and I was his sponsor for the libraw1394 package (here 
 speaking with my KDE packager hat on).

 

 libraw1394 transition, the following 5 packages still have a Depends 
 upon libraw1397-5:

 Package: gstreamer0.10-plugins-good
 Package: kcontrol
 Package: lynkeos.app
 Package: motion
 Package: wengophone

There are actually quite a number of other packages still having this
dependency, though perhaps not all on the architecture you were looking at.

Anyway, except for kdebase and gst-plugins-good0.10, which were deferred on
account of some other lib transitions, these packages were all scheduled for
binNMUs -- but a lot of them failed for one reason or another.  Those that
could be given back have been given back, leaving only three packages not
being rebuild: lynkeos.app, which needs updated for the (spurious) gnustep
-dev name change; wengophone, which FTBFS with a problem in its install
target; and motion, which FTBFS with bug #389304.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#388382: kdemultimedia-kio-plugins: wrong lame encoding option results in static-like files copying audio CD via konqueror

[Steve Langasek]

severity 388382 normal
thanks

On Wed, Sep 20, 2006 at 09:58:20AM +0200, Alberto Marmodoro wrote:
 Package: kdemultimedia-kio-plugins
 Version: 4:3.5.4-1
 Severity: grave
 Justification: causes non-serious data loss

This is not data loss; I assure you, ripping CDs is a non-destructive
operation. :)

 The default command line configuration, or any modification of it
 accessible through kcontrol interface, will spawn lame with the -x
 option.
 This results in mp3 files containing almost white noise like sounds, at
 least on this powerpc arch, with lame version 3.96.1.

mp3 support is also a secondary feature of kdemultimedia-kio-plugins; lame
isn't even included in Debian, the primary target of CD ripping with this
package is ogg vorbis files.  So this bug is also not grave by the unusable
or mostly so metric, therefore I'm downgrading the report.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#342545: qt-x11-free build fails

[Steve Langasek]

tags 342545 patch
thanks

Right, here's an off-the-cuff patch, which gets me past the point of the
SIGBUS on paer.

The same bug exists in the handling of Inf and NaN, but I didn't bother
patching for those since those constants should always be defined on Debian
systems and the related code paths never triggered.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/
diff -u qt-x11-free-3.3.6/debian/changelog qt-x11-free-3.3.6/debian/changelog
--- qt-x11-free-3.3.6/debian/changelog
+++ qt-x11-free-3.3.6/debian/changelog
@@ -1,3 +1,11 @@
+qt-x11-free (3:3.3.6-3.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Fix the bogus assumption in src/tools/qlocale.cpp that a char[] can be
+cast to a double *.  Closes: #342545.
+
+ -- Steve Langasek [EMAIL PROTECTED]  Thu, 24 Aug 2006 00:17:09 -0600
+
 qt-x11-free (3:3.3.6-3) unstable; urgency=low
 
   +++ Changes by Christopher Martin
only in patch2:
unchanged:
--- qt-x11-free-3.3.6.orig/src/tools/qlocale.cpp
+++ qt-x11-free-3.3.6/src/tools/qlocale.cpp
@@ -122,13 +122,24 @@
 #endif
 
 // We can't rely on -NAN, since all operations on a NAN should return a NAN.
+static double be_neg_nan; 
+static double le_neg_nan;
 static const unsigned char be_neg_nan_bytes[] = { 0xff, 0xf8, 0, 0, 0, 0, 0, 0 
};
 static const unsigned char le_neg_nan_bytes[] = { 0, 0, 0, 0, 0, 0, 0xf8, 0xff 
};
+static bool neg_nan_init = false;
+
 static inline double negNan()
 {
+if (!neg_nan_init)
+{
+memcpy(be_neg_nan,be_neg_nan_bytes,sizeof(be_neg_nan_bytes));
+memcpy(le_neg_nan,le_neg_nan_bytes,sizeof(le_neg_nan_bytes));
+neg_nan_init = true;
+}
 return (ByteOrder == BigEndian ?
-*((const double *) be_neg_nan_bytes) :
-*((const double *) le_neg_nan_bytes));
+be_neg_nan : 
+le_neg_nan);
+
 }
 
 // Sizes as defined by the ISO C99 standard - fallback


signature.asc
Description: Digital signature

Bug#342545: [parisc-linux] Re: Bug#342545: qt-x11-free FTBFS

[Steve Langasek]

On Thu, Aug 24, 2006 at 09:50:23PM -0400, John David Anglin wrote:

  This might be a nan bug.  There is one GCC nan fix that's only
  installed on the trunk:

  2006-05-24  John David Anglin  [EMAIL PROTECTED]

  PR target/27627
  * pa/pa-modes.def: Use mips_single_format, mips_double_format and
  mips_quad_format formats instead of ieee_single_format,
  ieee_double_format and ieee_quad_format formats, respectively.

 Just saw your patch.  Watch out, there are at least two different
 representations for nans.  In GCC, they are called mips and ieee.
 However, as far as I can tell, PA-RISC used the mips format before
 mips.  Both formats are complient with the original IEEE standard,
 so it's also a bit of a misnomer to call the other format the IEEE
 format.

Uh, my patch only attempts to correct for the bad alignment assumptions in
the existing code that cause build failures on hppa; invalid assumptions
about the byte representations of -NaN on particular platforms can be
someone else's problem if and when it becomes an issue. ;)

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#342545: qt-x11-free build fails

[Steve Langasek]

Right, so I noticed paer has been re-opened post-compromise, so I had a look
at this:

Program received signal SIGBUS, Bus error.
[Switching to Thread 16384 (LWP 19108)]
0x40cb2150 in negNan () at tools/qlocale.cpp:131
131 *((const double *) le_neg_nan_bytes));
(gdb) bt
#0  0x40cb2150 in negNan () at tools/qlocale.cpp:131
#1  0x40cbbe80 in qIsNan (d=3) at tools/qlocale.cpp:167
#2  0x40cbe6f4 in QLocalePrivate::doubleToString (this=0x40e48110, d=3, 
precision=6, form=QLocalePrivate::DFSignificantDigits, width=0, flags=0)
at tools/qlocale.cpp:3221
#3  0x40ce3604 in QString::setNum (this=0xc038adc8, n=3, f=103 'g', prec=6)
at tools/qstring.cpp:5282
#4  0x40bb46b4 in QDomElement::setAttribute (this=0xc038acd0, 
[EMAIL PROTECTED], value=3) at xml/qdom.cpp:4333
#5  0x0006684c in DomTool::fixDocument ([EMAIL PROTECTED])
at ../shared/domtool.cpp:389
#6  0x0001d420 in main (argc=6, argv=0xc038a528) at main.cpp:298
(gdb) 

I'd say that's pretty clearly not a libgcc bug.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#342545: qt-x11-free FTBFS

[Steve Langasek]

On Sun, Aug 06, 2006 at 02:03:29PM -0400, Christopher Martin wrote:
 On Sunday 30 July 2006 17:50, Marc 'HE' Brockschmidt wrote:
  Discussion in IRC showed that doko suspects libgcc2 deps in one of
  the build-deps to be the problem. A quick check revealed that
  libglu1-mesa still does that, so I requested a bin-NMU. Hopefully,
  after that was done, a reschedule will work out.

 qt-x11-free was retried on hppa, but failed again. However, I see no 
 evidence that a bin-NMU of libglu1-mesa was ever done, so this isn't 
 shocking.

It hasn't been, because I can't see any way that libglu1-mesa could have
anything to do with the failure in question.  libglu1-mesa should not be a
dependency of the tool that's failing with SIGBUS in the build log.

I would suggest that someone should investigate this further and get a clear
answer on the nature of the bug, because I really don't buy that libgcc skew
is to blame.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#368883: qt4-x11: FTBFS on alpha

[Steve Langasek]

reopen 368883
thanks

 * debian/patches/17_alpha_ice.dpatch: new patch from Steve Langasek to
  fix FTBFS on alpha (Closes: #368883)
  (urgency set to high for that fix).

sigh Except that, by adding in the new upstream release at the same time,
qt4-x11 is now hitting the same error in a different part of the code...

[...]
g++ -c -pipe -I/usr/include/mysql -I/usr/include/freetype2 
-I/usr/include/postgresql -g -fvisibility=hidden -fvisibility-inlines-hidden 
-Wall -W -D_REENTRANT -fPIC  -DQT_SHARED -DQT_BUILD_OPENGL_LIB 
-DQT_NO_CAST_TO_ASCII -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_GUI_LIB -DQT_CORE_LIB 
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/linux-g++ -I. 
-I../../include/QtCore -I../../include/QtGui -I../../include 
-I../../include/QtOpenGL -I/usr/include/freetype2 -I/usr/X11R6/include 
-I/usr/X11R6/include -I.moc/debug-shared -I. -o .obj/debug-shared/qgl.o qgl.cpp
../../include/QtCore/../../src/corelib/thread/qthreadstorage.h: In constructor 
'QThreadStorageT::QThreadStorage() [with T = QGLThreadContext*]':
../../include/QtCore/../../src/corelib/thread/qthreadstorage.h:116: internal 
compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see URL:file:///usr/share/doc/gcc-4.0/README.Bugs.
make[4]: *** [.obj/debug-shared/qgl.o] Error 1
[...]

So, reopening.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#368883: qt4-x11: FTBFS on alpha

[Steve Langasek]

tags 368883 patch
thanks

So, having diagnosed that this is an interaction between
-fvisibility-inlines-hidden and referencing inlined methods (bug #369642),
the obvious workaround is to keep the problematic methods from getting
inlined.

The attached patch should do this; unfortunately, I haven't tested it
completely because qt4-x11 is also missing a build-conflict with
unixodbc-dev, and I don't have the patience to try to build it a second time
on alpha.  Please consider applying the patch, I don't believe it has
negative side-effects for other archs.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/
diff -u qt4-x11-4.1.2/debian/changelog qt4-x11-4.1.2/debian/changelog
--- qt4-x11-4.1.2/debian/changelog
+++ qt4-x11-4.1.2/debian/changelog
@@ -1,3 +1,11 @@
+qt4-x11 (4.1.2-2.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * Workaround for -fvisibility-inlines-hidden on alpha: break out the
+static methods so they're not inlined.  Closes: #368883.
+
+ -- Steve Langasek [EMAIL PROTECTED]  Tue, 30 May 2006 19:56:44 -0700
+
 qt4-x11 (4.1.2-2) unstable; urgency=low
 
   * debian/libqt4-debug-dev.install, debian/libqt4-dev.install: added
only in patch2:
unchanged:
--- qt4-x11-4.1.2.orig/src/corelib/global/qlibraryinfo.cpp
+++ qt4-x11-4.1.2/src/corelib/global/qlibraryinfo.cpp
@@ -47,14 +47,7 @@
 {
 public:
 static QSettings *findConfiguration();
-static void cleanup()
-{
-QLibrarySettings *ls = qt_library_settings();
-if (ls) {
-delete static_castQSettings *(ls-settings);
-ls-settings = 0;
-}
-}
+static void cleanup();
 static QSettings *configuration()
 {
 QLibrarySettings *ls = qt_library_settings();
@@ -64,6 +57,15 @@
 Q_GLOBAL_STATIC(QLibrarySettings, qt_library_settings)
 };
 
+void QLibraryInfoPrivate::cleanup()
+{
+QLibrarySettings *ls = qt_library_settings();
+if (ls) {
+delete static_castQSettings *(ls-settings);
+ls-settings = 0;
+}
+}
+
 QLibrarySettings::QLibrarySettings()
 {
 settings = QLibraryInfoPrivate::findConfiguration();
only in patch2:
unchanged:
--- qt4-x11-4.1.2.orig/src/corelib/tools/qhash.h
+++ qt4-x11-4.1.2/src/corelib/tools/qhash.h
@@ -396,7 +396,7 @@
 }
 
 template class Key, class T
-Q_INLINE_TEMPLATE void QHashKey, T::duplicateNode(QHashData::Node *node, 
void *newNode)
+void QHashKey, T::duplicateNode(QHashData::Node *node, void *newNode)
 {
 Node *concreteNode = concrete(node);
 if (QTypeInfoT::isDummy) {


signature.asc
Description: Digital signature

Bug#368883: qt4-x11: FTBFS on alpha

[Steve Langasek]

clone 368883 -1
reassign -1 g++-4.0
severity -1 important
thanks

This ICE also happens with g++-4.1 and gcc-snapshot.

Working on a minimal test case.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#362924: xorg 7 breaks kdm

[Steve Langasek]

severity 362924 normal
quit

On Sun, Apr 16, 2006 at 04:00:31PM +0200, Arne Anka wrote:
 Package: kdm
 Version: 4:3.5.2-1
 Severity: grave
 Justification: renders package unusable

 after upgrade to xorg 7 kdm fails to start:
 kdm[15418]: X server /usr/X11R6/bin/X cannot be executed
 no wonder -- there's no /usr/X11R6/bin/X anymore.

There is if you upgrade to the latest xorg packages.

Ideally, packages should still be updated to reference /usr/bin instead of
/usr/X11R6/bin, but this is no longer required for etch.

If the maintainers are going to point to /usr/bin/X for etch, one of two
things is required:

- provide a fallback to /usr/X11R6/bin/X if /usr/bin/X is not found, or
- depend on x11-common (= 1:7.0.0)

and I would strongly advise *against* the latter, since it will make it much
harder for apt to calculate an upgrade path from sarge to etch.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#353321: knetworkconf: conflict with old gnome-system-tools

[Steve Langasek]

On Fri, Feb 17, 2006 at 03:11:32PM +0100, Marc Glisse wrote:
 Package: knetworkconf
 Version: 4:3.5.1-1
 Severity: grave
 Justification: renders package unusable

 Upgrading from sarge gives:

 Dépaquetage de knetworkconf (à partir de 
 .../knetworkconf_4%3a3.5.1-1_i386.deb) ...
 dpkg : erreur de traitement de 
 /var/cache/apt/archives/knetworkconf_4%3a3.5.1-1_i386.deb (--unpack) :
  tentative de remplacement de 
 « /usr/lib/pkgconfig/system-tools-backends.pc », qui appartient aussi au 
 paquet gnome-system-tools

 I believe a conflict with old versions of gnome-system-tools might help.

The current version of system-tools-backends-dev *still* contains that file.
I'm thinking that this is a bug in knetworkconf, for a namespace collision
with an existing .pc file.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#350066: Tellico FTBS, libkcal.la references libXft.la which does not exist anymore

[Steve Langasek]

On Fri, Jan 27, 2006 at 01:14:14AM +, Regis Boudin wrote:
 Package: kdepim
 Version: 3.5.0-5
 Severity: grave

 Trying to build a snapshot of tellico, it FTBS because of a
 missing /usr/lib/libXft.la file. I tried to rebuild the latest version
 of tellico with pbuilder, which also failed with the same error.

 All the .la files from the kdepim dev packages
 reference /usr/lib/libXft.la, if the build was done with libxft-dev 
 2.1.8. However, the file was removed last week with xft 2.1.8.2-1,
 making the packages linking against any of the kdepim libs FTBFS, hence
 the grave severity.
 i386 if affected, but some arches are not, such as i64.

 I tried rebuilding kdepim and installing the generated packages, and I
 could successfully build tellico.
 
 I am not sure if the solution is to rebuild kdepim with the new xft, or
 include libXft.la back, so I CC the xft maintainer, but something needs
 to be done.

Given that xft also supports pkg-config, AFAICT there's no specific reason
that libxft-dev should need to include libXft.la anymore.  The important
thing is to know whether or not it's coming back, or whether we should
requeue kdepim for rebuilding.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#347400: Bug#347407: Request for advice - Re: Bug#347401

[Steve Langasek]

On Sat, Jan 14, 2006 at 12:01:42PM +0100, Torsten Werner wrote:
 Steve Langasek schrieb:
  Yep, this is exactly what you want to see when using pkg-config for shared
  linking on a GNU ELF platform; everything else is extraneous.

 But I need Magick++:

 $ Magick++-config --ldflags --libs
 -L/usr/lib -L/usr/X11R6/lib -L/usr/lib/graphviz -lfreetype -lz -L/usr/lib
 -lMagick++ -lWand -lMagick -llcms -ltiff -lfreetype -ljasper -ljpeg
 -lpng -ldpstk -ldps -lXext -lXt -lSM -lICE -lX11 -lbz2 -lxml2 -lz
 -lpthread -lm -lpthread

 $ pkg-config --libs ImageMagick++
 -L/usr/X11R6/lib -L/usr/lib/graphviz -llcms -ltiff -lfreetype -ljasper
 -ljpeg -lpng -ldpstk -ldps -lXext -lXt -lSM -lICE -lX11 -lbz2 -lxml2 -lz
 -lm -lpthread -lMagick++ -lMagick

 I do not see any advantage in using pkg-config and I think that the bug
 should be fixed in ImageMagick anyway, shouldn't it?

Yeah... if pkg-config --libs ImageMagick++ is spitting this out, that's an
imagemagick bug. :/

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#348020: kdelibs-data conflict with libdjvulibre15 over a file /usr/share/mimelnk/image/x-djvu.desktop

[Steve Langasek]

severity 348020 normal
thanks

On Sat, Jan 14, 2006 at 07:08:42AM +0100, Rafal Maj wrote:

 I can not install libdjvulibre15 (upgrade it to version 3.5.16-2) while
 installing/upgrading kdelibs-data to 4:3.5.0-3. Perhaps this is a bug in
 dependiences or something?

It's a bug in an old version of libdjvulibre15 that you have installed.

KDE maintainers, it might be worth adding a Replaces: libdjvulibre15 (
$fixed_version) to kdelibs-data at the same time you fix bug #347218.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#347400: Request for advice - Re: Bug#347401

[Steve Langasek]

Hi Mike,

On Wed, Jan 11, 2006 at 10:18:20PM +1100, Mike Williams wrote:

 So maintainers, please take the advice given in that mail and fix your
 packages to a) not use the output of Magick-config --libs when linking, and
 b) use the Debian version of libtool (if applicable).

 (One alternative to using Magick-config --libs seems to be to use 
 pkg-config
 -- not because ImageMagick gets its pkg-config support right, but because 
 it
 happens to get it right in a way that benefits us. ;)

 Steve, can you give me some advice?  I'm attempting to fix this 
 librmagick-ruby bug by switching from Magick-config to pkg-config. 

 Attached is the patch I'm planning to apply ... basically, it avoids 
 using $CFLAGS and $LDFLAGS values computing by configure (using 
 Magick-config) and uses output from pkg-config instead. 

 In my case, Magick-config --libs outputs

-lMagick -llcms -ltiff -lfreetype -ljasper -ljpeg -lpng -ldpstk
-ldps -lXext -lXt -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lpthread -lm
-lpthread

 whereas pkg-config --libs ImageMagick returns just

-lMagick

 So, does it sound like this change will do the job?

Yep, this is exactly what you want to see when using pkg-config for shared
linking on a GNU ELF platform; everything else is extraneous.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#340704: rar support violates DFSG #4

[Steve Langasek]

severity 340704 important
severity 340705 important
severity 340706 important
severity 340707 important
thanks

Hi Robert,

Sorry, I have to disagree with these bug severities; Suggests: are just not
important enough in our packaging system to treat them as release-critical,
regardless of what's being suggested, and it is generally considered
acceptable to Suggest: non-free packages from main anyway.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#340704: rar support violates DFSG #4

[Steve Langasek]

On Fri, Nov 25, 2005 at 01:34:23PM +0100, Robert Millan wrote:
 On Fri, Nov 25, 2005 at 02:41:49AM -0800, Steve Langasek wrote:

  Sorry, I have to disagree with these bug severities; Suggests: are just not
  important enough in our packaging system to treat them as release-critical,
  regardless of what's being suggested,

 My concern is about the rar writing support itself, not about Suggests.  The
 Suggests tag is just an indication that either the application supports
 generating rar archives (or that there's a mistake, and the maintainer just
 mean to suggest unrar instead).

  and it is generally considered
  acceptable to Suggest: non-free packages from main anyway.

 Well, that's not the problem.  If the application needs unrar to extract rar
 archives, then suggesting unrar is ok [1].  It's the fact that the application
 supports creating rar archives that I believe violates the DFSG.

 Does this explanation satisfy you?  If it does, I'd like to rise the severity
 back to serious (I don't think it's an issue for the release, being only 4
 bugs).

 OTOH, if you think my interpretation of DFSG is inadequate, I could try to
 expose it better, and we could also move this to -legal (perhaps I should have
 started there in first place).

Yes, I still disagree with this reasoning.  People of conscience may
disagree on whether *preventing* the creation of files that can't be read
with free software is serving the goals of the DFSG.  In the absence of
agreement on this point, I don't think it's right to treat this as a
release-critical bug unless the *maintainer* agrees with you.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#337690: ksayit: KSayit crashes on startup

[Steve Langasek]

block 337690 by 336114
thanks

On Sat, Nov 05, 2005 at 04:29:35PM -0400, Josh Metzler wrote:
 On Saturday 05 November 2005 02:50 pm, Ronny Standtke wrote:
  Package: ksayit
  Version: 4:3.4.2-2
  Severity: grave
  Justification: renders package unusable
 
 
  KSayit crashes on startup. Here is the backtrace:
 ...
  #3  0xb799bb6e in __gnu_cxx::__pooltrue::_M_reclaim_block ()
 from /usr/lib/libstdc++.so.6
  #4  0xb7c2b632 in __gnu_cxx::__mt_allocArts::ParamDef,
 __gnu_cxx::__common_pool_policy__gnu_cxx::__pool, true
 ::deallocate () from /usr/lib/libartskde.so.1
 ...

 This is a result of a toolchain bug #336114, and unfortunately there is not 
 much that the debian-qt-kde maintainers until they are told how it will be 
 solved.  If you really need ksayit working, recompiling kdelibs with the 
 current g++ should work around this problem.

Which would then break again when the toolchain is fixed; the ABI change
needs to be reverted, so anything built with the current g++ will have to be
rebuilt again.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Bug#317098: how long is this going to take?

[Steve Langasek]

On Sat, Jul 16, 2005 at 02:57:22PM +1000, Caveman wrote:
 Its been 9 days since this bug was first listed. Whats the trouble
 with getting it fixed?
 I would have thought this would be a rather major program that the
 maintainer would have wanted to fix quickly.
 But we don't seem to have had a word from him.

No KDE applications are currently buildable in unstable due to the C++ ABI
transition.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#311710: kdelibs: Does not have a versioned dependency on libmad0

[Steve Langasek]

tags 311710 sarge
thanks

The practical impact of this bug is not release-critical for etch, since
partial upgrades from sarge-etch will not be affected: only partial
upgrades from woody to sarge can be.  Tagging it appropriately.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#311712: kwifimanager: Does not have a versioned dependency on libmad0

[Steve Langasek]

tags 311712 sarge
thanks

The practical impact of this bug is limited to partial upgrades from woody
to sarge; tagging appropriately.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: A Prisonner of the dependency hell

[Steve Langasek]

On Sat, May 28, 2005 at 02:46:52PM +0200, Bill Allombert wrote:
 On Fri, May 27, 2005 at 04:49:14PM -0700, Steve Langasek wrote:
  On Sat, May 28, 2005 at 01:03:13AM +0200, Bill Allombert wrote:
   I need to attract your attention on bug #310490.

   This show a pure woody system that cannot be upgraded to sarge
   using the recommended way witout basically removing KDE.
   This bug is 100% reproducible, but I have not yet completly
   tracked the problem, though I have seen pretty awkward behaviour from
   apt. In particular 'apt-get install fontconfig' fails with a message
   claiming that defoma cannot installed while defoma is up-to-date.

   Upgrading with dselect work much better.

   I did not try yet to upgrade using aptitude in interactive mode.

  I don't suppose there's a smaller test case involving fewer packages?

 OK, I have done that:
 1) debootstrap woody
 2) install konqueror,libqt3 and aptitude

Did you install konqueror and libqt3 with aptitude, or with another tool?
If konqueror is installed with aptitude, allowing libqt3 to be pulled in
automatically, does aptitude do a better job of conflict resolution on
upgrade?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: A Prisonner of the dependency hell

[Steve Langasek]

Hi Bill,

On Sat, May 28, 2005 at 01:03:13AM +0200, Bill Allombert wrote:
 I need to attract your attention on bug #310490.

 This show a pure woody system that cannot be upgraded to sarge
 using the recommended way witout basically removing KDE.
 This bug is 100% reproducible, but I have not yet completly
 tracked the problem, though I have seen pretty awkward behaviour from
 apt. In particular 'apt-get install fontconfig' fails with a message
 claiming that defoma cannot installed while defoma is up-to-date.

 Upgrading with dselect work much better.

 I did not try yet to upgrade using aptitude in interactive mode.

I don't suppose there's a smaller test case involving fewer packages?

I know KDE upgrade tests had been done at one point.  Maybe someone on the
KDE team can shed light on this problem?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Kopete unusable for MSN, kdenetwork 3.3.2-4 fixes

[Steve Langasek]

Hi,

On Fri, May 20, 2005 at 04:17:20AM +0200, Adeodato Simó wrote:
   Since yesterday evening, the Kopete version in sarge is no longer able
   to log into MSN Messenger accounts due to (it seems) an update in the
   Microsoft servers.

   Bug #309745 arrived to the Debian BTS this morning making us aware of
   the problem, and in the afternoon we were informed that a bugfix was
   available from upstream's SVN.

   We've uploaded kdenetwork 3.3.2-4 to sid a while ago, containing a
   backport to the 3.3 branch of KDE of the upstream fix, and we would
   like to see this version shipped with Sarge if possible.

   Sorry for making this request so close to the deadline for bugfixes at
   severity important, but please take into account that the problem has
   only existed for little longer than 24 hours now.

   The changelog entry follows, and the diff is about 900 lines including
   an update to a Makefile.in file. There's then a lot of code deleted that
   gets substituted by two files copied from the long-existing project
   KMess.

+diff -u -Nrua kdenetwork-3.3.2/kopete/protocols/msn.orig/Makefile.am 
kdenetwork-3.3.2/kopete/protocols/msn/Makefile.am
+--- kdenetwork-3.3.2/kopete/protocols/msn.orig/Makefile.am 2005-05-19 
20:57:29.0 +0200
 kdenetwork-3.3.2/kopete/protocols/msn/Makefile.am  2005-05-19 
20:59:10.0 +0200
+@@ -5,6 +5,8 @@
+   $(KOPETE_INCLUDES) \
+   $(all_includes)
+ 
++KDE_OPTIONS = nofinal
++
+ kde_module_LTLIBRARIES = kopete_msn.la
+ lib_LTLIBRARIES = libkopete_msn_shared.la
+ 

What does this change mean?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#309349: gnome-menus: conflicts with kdelibs-data

[Steve Langasek]

On Mon, May 16, 2005 at 11:09:52PM +0200, Encolpe DEGOUTE wrote:
 Sebastien Bacher a écrit :
 severity 309349 serious
 tag 309349 experimental
 merge 309349 307098
 thanks

 Le lundi 16 mai 2005 à 18:37 +0200, Encolpe DEGOUTE a écrit :

 /var/cache/apt/archives/gnome-menus_2.10.1-1_i386.deb (--unpack):
 trying to overwrite `/etc/xdg/menus/applications.menu', which is also
 in package kdelibs-data
 Errors were encountered while processing:
 /var/cache/apt/archives/gnome-menus_2.10.1-1_i386.deb

 Please look on the bugs before filling duplicates (and this bug
 concerned only experimental, it should use the associated tag).

 This bug concerns unstable now.

No, it does not.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#301127: kaboodle dies with sigsev or so when trying to play an mpeg

[Steve Langasek]

On Wed, Mar 23, 2005 at 05:28:59PM -0500, Justin Pryzby wrote:
 On Wed, Mar 23, 2005 at 10:39:16PM +0100, Dirk Salva wrote:
  Package: kaboodle
  Version: 4:3.3.1-2
  Severity: grave
  Justification: renders package unusable

  When I start trying to view an mpeg or something else (like from leech.dk),
  kaboodle only starts, but does not play. When I push play-button, it
  breaks with a sigsev (KDE-crash-notifier) or so. Under 32bit sarge the same
  video-file works fine. Asus A8V Deluxe, NVidia 6600GT, 1GB RAM.
 Can you run it under GDB and see if the backtrace is usable?

   $ gdb kaboodle
run
bt

 Can someone test this on a 64 bit architecture other than amd64?  This
 is sarge-ignore if the other 64 bit archs work.

If someone can provide me a reasonably-sized sample video file that's known
to work with kaboodle on i386 and known to fail on amd64, I can test it on
an alpha here.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#274779: file conflicts in libsmokeqt1 libsmokeqt-dev libqt-perl

[Steve Langasek]

On Sat, Jan 08, 2005 at 02:08:08AM +0100, Adeodato Simó wrote:

  The proper solution here is probably to continue using the bundled smokeqt
  code on mips/mipsel, and build-depend on libsmokeqt-dev on the other
  architectures.  This is certain to last through the sarge timeframe, as
  fixing gij for mips(el) is a post-sarge task.

   Patch implementing that attached, sending here as accorded on irc.
   Including a gzipped copy to prevent charset mangling.

I'm uploading an NMU based on this patch.  Attached is the final patch,
which includes some small fixes for rpath handling introduced by the
previous NMU.

Thanks,
-- 
Steve Langasek
postmodern programmer
diff -u libqt-perl-3.008/debian/changelog libqt-perl-3.008/debian/changelog
--- libqt-perl-3.008/debian/changelog
+++ libqt-perl-3.008/debian/changelog
@@ -1,3 +1,17 @@
+libqt-perl (3.008-1.2) unstable; urgency=high
+
+  * Non-maintainer upload, with thanks to Adeodato Simó for his help in
+preparing it
+  * High-urgency upload for sarge-targetted RC bugfix
+  * Revert the changes in the previous upload for mips and mipsel,
+required for libqt-perl to be buildable on all arches and eligible
+for sarge.  (See discussion in Bug#274779).
+  * Make sure to keep --disable-rpath on all architectures and re-add
+LD_RUN_PATH='', as this is still needed.
+  * Make libqt-perl conflict libsmokeqt1 and libsmokeqt-dev on mipsen.
+
+ -- Steve Langasek [EMAIL PROTECTED]  Fri,  7 Jan 2005 18:13:13 -0800
+
 libqt-perl (3.008-1.1) unstable; urgency=low
 
   * Non maintainer upload.
@@ -10,7 +24,7 @@
 - remove chrpath on no-longer built libsmokeqt.so, remove Build-Dependency
   on chrpath too.
 
- -- Adeodato Sim� [EMAIL PROTECTED]  Thu, 07 Oct 2004 20:55:04 +0200
+ -- Adeodato Simó [EMAIL PROTECTED]  Thu, 07 Oct 2004 20:55:04 +0200
 
 libqt-perl (3.008-1) unstable; urgency=low
 
diff -u libqt-perl-3.008/debian/rules libqt-perl-3.008/debian/rules
--- libqt-perl-3.008/debian/rules
+++ libqt-perl-3.008/debian/rules
@@ -13,6 +13,16 @@
 # from having to guess our platform (since we know it already)
 DEB_HOST_GNU_TYPE   ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
+DEB_HOST_ARCH   ?= $(shell dpkg-architecture -qDEB_HOST_ARCH)
+
+MISSING_LIBSMOKEQT_ARCHES = mips mipsel
+
+ifneq (,$(findstring $(DEB_HOST_ARCH),$(MISSING_LIBSMOKEQT_ARCHES)))
+   EXTRA_CONFIGURE_ARGS := --enable-smoke
+   CONFLICTS := libsmokeqt1, libsmokeqt-dev
+else
+   RUN_CHRPATH := /bin/true
+endif
 
 
 CFLAGS = -Wall -g
@@ -32,7 +42,7 @@
aclocal-1.7
automake-1.7
autoconf
-   ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) 
--prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info 
--with-qt-dir=/usr/share/qt3
+   ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) 
--prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info 
--with-qt-dir=/usr/share/qt3 --disable-rpath $(EXTRA_CONFIGURE_ARGS)
 
 
 build: build-stamp
@@ -40,9 +50,9 @@
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE) #LD_RUN_PATH=
+   $(MAKE) LD_RUN_PATH=
 
-   #chrpath -d smoke/qt/.libs/libsmokeqt.so
+   $(RUN_CHRPATH) chrpath -d smoke/qt/.libs/libsmokeqt.so
 
touch build-stamp
 
@@ -125,7 +135,7 @@
dh_installdeb
 #  dh_perl
dh_shlibdeps
-   dh_gencontrol
+   dh_gencontrol -- -Vmipsen:Conflicts=$(CONFLICTS)
dh_md5sums
dh_builddeb
 
diff -u libqt-perl-3.008/debian/control libqt-perl-3.008/debian/control
--- libqt-perl-3.008/debian/control
+++ libqt-perl-3.008/debian/control
@@ -2,13 +2,14 @@
 Section: perl
 Priority: optional
 Maintainer: Peter Hawkins [EMAIL PROTECTED]
-Build-Depends: debhelper ( 3.0.0), libqt3-mt-dev, perl (= 5.8.0), 
automake1.7, autoconf, libsmokeqt-dev ( 4:3.2.3-1)
+Build-Depends: debhelper ( 3.0.0), libqt3-mt-dev, perl (= 5.8.0), 
automake1.7, autoconf, chrpath [mips mipsel], libsmokeqt-dev ( 4:3.2.3-1) 
[!mips !mipsel]
 Build-Conflicts: libqt-perl
 Standards-Version: 3.6.1
 
 Package: libqt-perl
 Architecture: any
 Depends: ${perl:Depends}, ${shlibs:Depends}
+Conflicts: ${mipsen:Conflicts}
 Description: Perl bindings for the Qt library
  This module lets you use the Qt library from Perl.
  It provides an object-oriented interface and is easy to use.


signature.asc
Description: Digital signature

Bug#274779: file conflicts in libsmokeqt1 libsmokeqt-dev libqt-perl

[Steve Langasek]

ok, here's the current status of this particular bug:

- libqt-perl has been fixed in unstable to build-depend on libsmokeqt-dev
- libsmokeqt-dev comes from the kdebindings source package
- kdebindings build-depends on gij
- gij is unavailable on mips and mipsel (due to the xgot/multigot problem on
  those platforms)
- therefore, the current libqt-perl will never be built on those
  architectures, remain perpetually out-of-sync, and the fix will not
  propagate to testing.

The proper solution here is probably to continue using the bundled smokeqt
code on mips/mipsel, and build-depend on libsmokeqt-dev on the other
architectures.  This is certain to last through the sarge timeframe, as
fixing gij for mips(el) is a post-sarge task.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: Final polishing of the KDE 3.3 transition

[Steve Langasek]

On Sun, Jan 02, 2005 at 08:32:20PM +0100, Adeodato Simó wrote:
   The gcc-3.4/libunwind transition having happened on Dec 31st, KDE 3.3
   is mostly ready to enter sarge. In this mail, I will make a summary of
   the last issues that need to be addressed:

 (a) #266478, the dummy bug new kdelibs should not enter testing
 alone, should be closed now. If some RM mails to -done, that
 would be nice. (But see (d) below - I have not already closed
 it since I wanted some feedback first.)

This bug is now closed.

 (c) Unless some RM objects, the latest security bugs won't get fixed
 before the transition, and uploads to address them will be done
 shortly after the transition with urgency=high.

 I talked to Andreas about this too, and he agreed to it since
 all the vulnerabilities are present in the current sarge
 packages as well.

I agree that the impact of the KDE blockage is sufficient that we shouldn't
be holding KDE out of testing for bugs that aren't specific to unstable.

 We now request for instructions about how to proceed so that the
 affected bugs are not included in the RC bug count. One of:

   1. vorlon those security bugs will have to be temporarily
  downgraded

   2. vorlon the only other way is to use force hints, and
  using force hints would override the safety we were trying
  to put in place.

   3. calc you could set a temporary sarge-ignore tag?

   4. dato or temporaly leave all of them as +sarge only, right?

 (but: vorlon I think I prefer to lie about the severity
 rather than lie about the tags; Kamion may have a different
 opinion as a bugmaster.)

This preference isn't strong enough that I would want it to hold anything
up; all the options are kludges, so we might as well pick one and get on
with things.

 (d) Given the number of packges that are stalled by kdelibs [1] and
 not covered by this transition (i.e., not in the hands of the
 KDE packagers), I expressed two concerns back in November [last
 section of 2].

  [1] http://bjorn.haxx.se/debian/testing.pl?waiting=kdelibs
  [2]http://lists.debian.org/debian-release/2004/11/msg00154.html

 As for the second concern, I'm only mildly drawing some
 attention from RMs to it: kdelibs entering sarge will mean a
 bunch of packages with *big* differences migrating, so I always
 thought that the Release Team would prefer these migrations to
 happen smoothly, and semi-controlled (plus what I say in the
 mail), and the only scheme I could came up with was the mass
 bug-filing.

This is not really a major concern; if there are RC bugs that haven't been
detected yet, there's no sense in sitting around waiting for them to be
filed.  If you have specific issues in mind that you suspect may be RC, it
would be best to investigate them before the affected packages reach
testing, of course.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#276013: all kde apps segfault on startup on alpha

[Steve Langasek]

Unreproducible on alpha here; I think this should probably be
downgraded.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#270389: kdelibs: t-p-u upload FTBFS on m68k

[Steve Langasek]

On Wed, Sep 15, 2004 at 10:50:45AM +0200, Michael Schmitz wrote:
   Usually meinproc errors we have seen so far have been building machine
   running out of ram/disk space. Since all the other builds came out fine,
   this seems probable this time too.

  Ok.  m68k porters, is it possible for this kdelibs t-p-u upload
  to be requeued on a beefier machine?

 Beefier than which one?

According to 
http://buildd.debian.org/fetch.php?pkg=kdelibsver=4%3A3.2.3-3.sarge.2arch=m68kstamp=1094188856file=logas=raw,
this was kullervo.

Just to be on the safe side, I'll remind everyone that this upload needs
to be built against testing, not against unstable.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#270389: kdelibs: t-p-u upload FTBFS on m68k

[Steve Langasek]

On Tue, Sep 07, 2004 at 11:59:35AM +0300, Riku Voipio wrote:
 On Tue, Sep 07, 2004 at 12:03:17AM -0700, Steve Langasek wrote:
  Trying to build kdelibs 3.2.3-3.sarge.2 on m68k failed with the error:

  Making all in kspell
  make[4]: Entering directory 
  `/build/buildd/kdelibs-3.2.3/obj-m68k-linux/doc/kspell'
  ../../kdoctools/meinproc --srcdir=../../../kdoctools --check --cache 
  index.cache.bz2 ../../../doc/kspell/index.docbook
  make[4]: *** [index.cache.bz2] Error 139

 Usually meinproc errors we have seen so far have been building machine 
 running out of ram/disk space. Since all the other builds came out fine, 
 this seems probable this time too.

Ok.  m68k porters, is it possible for this kdelibs t-p-u upload
to be requeued on a beefier machine?

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#269519: kshisen: desktop file Exec option should not contain full path to command

[Steve Langasek]

clone 269519 -1
severity 269519 important
reassign -1 kicker
retitle -1 kicker broken when .desktop file includes an absolute path
thanks

This really seems to be a bug in kicker, not in kshisen.  It's obviously
rather difficult to launch an application without a full path if it lies
outside the search path, and clearly it's possible for a user to have a
path that doesn't include /usr/games.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#270389: kdelibs: t-p-u upload FTBFS on m68k

[Steve Langasek]

Package: kdelibs
Version: 4:3.2.3-3.sarge.2
Severity: serious

Trying to build kdelibs 3.2.3-3.sarge.2 on m68k failed with the error:

Making all in kspell
make[4]: Entering directory 
`/build/buildd/kdelibs-3.2.3/obj-m68k-linux/doc/kspell'
../../kdoctools/meinproc --srcdir=../../../kdoctools --check --cache 
index.cache.bz2 ../../../doc/kspell/index.docbook
make[4]: *** [index.cache.bz2] Error 139
make[4]: Leaving directory 
`/build/buildd/kdelibs-3.2.3/obj-m68k-linux/doc/kspell'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/build/buildd/kdelibs-3.2.3/obj-m68k-linux/doc'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/build/buildd/kdelibs-3.2.3/obj-m68k-linux'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/build/buildd/kdelibs-3.2.3/obj-m68k-linux'
make: *** [build-arch-stamp] Error 2

More information can be found at
http://buildd.debian.org/fetch.php?pkg=kdelibsver=4%3A3.2.3-3.sarge.2arch=m68kstamp=1094188856file=logas=raw.

This is a serious bug, as it prevents a fixed kdelibs package from being
included in sarge.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

arts 1.3 + kde 3.2?

[Steve Langasek]

Bug #269132 was opened to hold arts 1.3 out of testing, on the grounds
that it has not been tested with kde 3.2.  Has anyone had time to do
such a test?  It would be good to know if the 50-some packages blocked
by arts currently will need to make other arrangements for sarge.

Please cc: debian-release on replies.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#268966: kdegraphics NMU to t-p-u (tiff4/exif10/kdelibs 3.2.3 rebuild)

[Steve Langasek]

Package: kdegraphics
Version: 3.2.3-1.1

With permission from Ben Burton, I'm uploading an NMU of kdegraphics to
testing-proposed-updates to get it back into testing following its
removal as part of the tiff/libexif transition.  Please find the diff
attached.

-- 
Steve Langasek
postmodern programmer
diff -u kdegraphics-3.2.3/debian/control kdegraphics-3.2.3/debian/control
--- kdegraphics-3.2.3/debian/control
+++ kdegraphics-3.2.3/debian/control
@@ -3,7 +3,7 @@
 Priority: optional
 Maintainer: Debian Qt/KDE Maintainers debian-qt-kde@lists.debian.org
 Uploaders: Christopher L Cheney [EMAIL PROTECTED]
-Build-Depends: automake1.8, debhelper ( 4.2.0), gawk, gettext, imlib11-dev, 
kdelibs4-dev (= 4:3.2.3-4), libexif-dev, libfribidi-dev, libglut3-dev, 
libgphoto2-2-dev, libgtk1.2-dev, libpaper-dev, libsane-dev (= 1.0.9-3), 
libtiff4-dev, libusb-dev, sharutils, tetex-bin, texinfo, xlibs-static-pic, 
xpdf-utils
+Build-Depends: automake1.8, debhelper ( 4.2.0), gawk, gettext, imlib11-dev, 
kdelibs4-dev (= 4:3.2.3), libexif-dev (= 0.6.9-1), libfribidi-dev, 
libglut3-dev, libgphoto2-2-dev, libgtk1.2-dev, libpaper-dev, libsane-dev (= 
1.0.9-3), libtiff4-dev, libusb-dev, sharutils, tetex-bin, texinfo, 
xlibs-static-pic, xpdf-utils
 Standards-Version: 3.6.1.0
 
 Package: kdegraphics
diff -u kdegraphics-3.2.3/debian/changelog kdegraphics-3.2.3/debian/changelog
--- kdegraphics-3.2.3/debian/changelog
+++ kdegraphics-3.2.3/debian/changelog
@@ -1,3 +1,14 @@
+kdegraphics (4:3.2.3-1.1) testing-proposed-updates; urgency=low
+
+  * Non-maintainer upload with approval from Ben Burton.
+  * Re-upload kdegraphics to testing, having been removed to make way
+for new library sonames in sarge.
+  * Build-Depends: libexif-dev (= 0.6.9-1).
+  * Relax the build-dependencies on kdelibs4-dev, since the strict
+build-dep isn't needed to avoid a dependency on libtiff3g.
+
+ -- Steve Langasek [EMAIL PROTECTED]  Sun, 29 Aug 2004 02:18:05 -0700
+
 kdegraphics (4:3.2.3-1) unstable; urgency=high
 
   * New upstream release.


signature.asc
Description: Digital signature

Bug#267232: kaddressbook: Does not start, even though GUI appears

[Steve Langasek]

tags 267232 sid
thanks

This bug does indeed appear to be specific to sid.

Thanks,
-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: KDE 3.3 and sarge

[Steve Langasek]

On Sun, Aug 15, 2004 at 03:16:35PM +0200, Rene Engelhard wrote:
 Steve Langasek wrote:
  still outstanding requirement to get rid of libtiff3g for sarge.  Ben
  Burton has already expressed his willingness to NMU these packages if
  necessary; Chris, if you are available to work on this yourself, I am of
  course happy to work with you to get these packages ready for sarge.
  These uploads will in any case have to wait for libtiff4 to reach sarge,
  which should happen in two to three days once the new libtiff3g package
  is built on all architectures.

 And kdelibs-data AGAIN caused file conflicts with
 openoffice.org-mimelnk. See
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265852repeatmerged=no.

 Should that be upgraded to serious and then tagged sarge-ignore since it
 only is something with KDE 3.3?

This is a serious bug, but it should be tagged sid, not sarge-ignore.  A
sid tag will block the conflicting KDE3.3 from reaching sarge, a
sarge-ignore tag would let it in unimpeded.

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Re: KDE 3.3 and sarge

[Steve Langasek]

On Sun, Aug 15, 2004 at 12:38:16PM -0700, Steve Langasek wrote:
 On Sun, Aug 15, 2004 at 03:16:35PM +0200, Rene Engelhard wrote:
  Steve Langasek wrote:
   still outstanding requirement to get rid of libtiff3g for sarge.  Ben
   Burton has already expressed his willingness to NMU these packages if
   necessary; Chris, if you are available to work on this yourself, I am of
   course happy to work with you to get these packages ready for sarge.
   These uploads will in any case have to wait for libtiff4 to reach sarge,
   which should happen in two to three days once the new libtiff3g package
   is built on all architectures.

  And kdelibs-data AGAIN caused file conflicts with
  openoffice.org-mimelnk. See
  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=265852repeatmerged=no.

  Should that be upgraded to serious and then tagged sarge-ignore since it
  only is something with KDE 3.3?

 This is a serious bug, but it should be tagged sid, not sarge-ignore.  A
 sid tag will block the conflicting KDE3.3 from reaching sarge, a
 sarge-ignore tag would let it in unimpeded.

Oh, right.  Yes, the bug on openoffice ought to be tagged sarge-ignore,
and the bug on kde3.3 would be tagged sid.

Thanks,
-- 
Steve Langasek
postmodern programmer




signature.asc
Description: Digital signature

Bug#240288: Fake bug: It's probably not yet a good idea for kdelibs 3.2 to propagate to testing.

[Steve Langasek]

I'm somewhat concerned about this particular bug.  If a fake bug is
necessary to keep the new kdelibs out of testing, this seems to indicate
that any breakages that would result from an updated kdelibs without an
updated kdebase are not expressed in the package relationships, which
means they will still be a problem for partial upgrade scenarios even
after kdebase is ready and this bug is closed.

The other possibility is that kdelibs *will* break parts of kdebase if
it precedes kdebase into testing, but that this is already documented
appropriately using Conflicts between the relevant binary packages, in
which case this bug is redundant and can be closed.

You say that having split kdebase/kdelibs version is not a good idea
for various reasons.  Could you please enumerate them?

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature

Bug#203722: How to handle the -mieee SIGFPE problem in normal Debian packages

[Steve Langasek]

On Mon, Feb 09, 2004 at 04:54:06PM +0100, Dominique Devriese wrote:

 Please respect the Mail-Followup-To, as I'm not subscribed to this
 list, and the discussion is relevant to #203722.

 I'm currently looking at the following bug report
 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=203722
 about a frequent SIGFPE on an alpha machine.  I guess we all know the
 cause of this bug, namely the non-standard alpha FPU semantics.

 My question is about how to handle this bug:
 IIUC, there are the following options:

 1 Fix upstream FP calculations to not trigger SIGFPEs. this is
   unfortunately not an option imho, because of lack of interest of
   developers.
 2 make all KDE programs install a SIG_IGN SIGFPE handler.  This can be
   done in kdelibs, and would be little work.
 3 make upstream configure detect alpha and compile with -mieee if so.
 4 wait for the gcc alpha patch to be included into gcc, which was
   posted on this list recently.

 What option would you suggest the Debian KDE packages take ?  I don't
 think there is any very FP-intensive code in the KDE packages, so
 performance is not really that much of an issue.

Even if gcc will soon adopt a patch to make -mieee the default, there
will be older versions of gcc around for a while.  This is a bug *now*,
and there's no reason not to add the -mieee explicitly to the compiler
flags for the time being: it will just become a no-op later once this is
the gcc default.

If you prefer to integrate this into the upstream configure rules,
that's fine, though it's trivial to do it in debian/rules instead (see
pseudopatch on one of the other bugs).

-- 
Steve Langasek
postmodern programmer


pgpgJ7cvP8ecX.pgp
Description: PGP signature

Bug#231374: libkjs chokes and dies on alpha while trying intercoursing with evil CC website javascript

[Steve Langasek]

Package: kdelibs4
Version: 4:3.1.5-1
Severity: important
Tags: patch

Trying to load the bill payment website of an evil credit card company
who-will-remain-nameless (until after I've destroyed them until the
fourth generation), konqueror crashes on my alpha with a SIGFPE.  An
easy fix for this would be to add something like the following snippet
to the debian/rules for kdelibs:

# Enable IEEE-conformant floating point math on alphas (not the default)
ifeq (alpha-linux,$(DEB_HOST_GNU_TYPE))
  CFLAGS += -mieee
endif

If for some reason you feel inclined to muck around with the actual
handling of this signal, here is the backtrace generated:

(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...[New Thread 16384 (LWP 32483)]
(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...0x02000181c360 in waitpid ()
   from /lib/libpthread.so.0
#0  0x02000181c360 in waitpid () from /lib/libpthread.so.0
#1  0x02b50490 in KCrash::defaultCrashHandler(int) ()
   from /usr/lib/libkdecore.so.4
#2  0x02000181b428 in __pthread_sighandler () from /lib/libpthread.so.0
#3  0x020001c47900 in sigset () from /lib/libc.so.6.1
#4  0x020002bb8a74 in KJS::roundValue(KJS::ExecState*, KJS::Value const)
() from /usr/lib/libkjs.so.1
#5  0x020002bf3754 in KJS::ValueImp::toInt32(KJS::ExecState*) const ()
   from /usr/lib/libkjs.so.1
#6  0x020002bf4148 in KJS::Value::toInt32(KJS::ExecState*) const ()
   from /usr/lib/libkjs.so.1
#7  0x020002bc37bc in KJS::AssignNode::value(KJS::ExecState*) const ()
   from /usr/lib/libkjs.so.1
#8  0x020002bc5e10 in KJS::ExprStatementNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#9  0x020002bce6d4 in KJS::SourceElementNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#10 0x020002bcec18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#11 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#12 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#13 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#14 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#15 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#16 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#17 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#18 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#19 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#20 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#21 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#22 0x020002bceb18 in KJS::SourceElementsNode::execute(KJS::ExecState*) ()
   from /usr/lib/libkjs.so.1
#23 0x020002bceb18 in 

Re: Rethinking Qt headers (should the header packages be recombined?)

[Steve Langasek]

On Wed, Feb 26, 2003 at 08:01:51PM -0500, Matt Zimmerman wrote:
 On Thu, Feb 27, 2003 at 12:16:44AM +1100, Ben Burton wrote:

  The consequences I see are as follows.  Say a user doesn't have
  libqt3-compat-headers installed (since there's no obvious reason to have
  it installed; none of the usual -dev packages depend on it).  They
  download a random Qt/KDE application to build, and it doesn't compile.
  They're confused, since it builds everywhere else under Qt3.  After some
  rummaging around, they discover that oh, on a *debian* system you need the
  extra libqt3-compat-headers package.  The user installs
  libqt3-compat-headers so that it builds properly, and if they're nice
  they'll even notify the upstream developer that their application uses
  legacy headers.

 I do not think that the package split makes sense.

 It is not justifiable to burden Debian users and Debian package maintainers
 with these legacy issues.  A deprecated header file should issue a #warning
 explaining that it is deprecated (and, ideally, what replaces it).  Simply
 breaking the builds of a lot of existing software (packaged and not) does
 not make sense here.

Even better, if you look inside the replacement headers, you'll find
that the *official* headers contain backwards-compatible #defines for
all of the deprecated classes.  So you can #include qmemarray.h, and
continue using QArray as your class type.

So what do we gain by weaning developers off the old headers again?

-- 
Steve Langasek
postmodern programmer


pgpZSq3lj6QlD.pgp
Description: PGP signature