Bug#1069533: sayonara: Please package new upstream version

[Steve M]

Is this not an issue that would prevent such an update for the time being?


This package is part of the ongoing testing transition known as auto-qtbase-
opensource-src. Please avoid uploads unrelated to this transition, they would
likely delay it and require supplementary work from the release managers. On the
other hand, if your package has problems preventing it to migrate to testing,
please fix them as soon as possible. You can probably find supplementary
information in the debian-release archives or in the corresponding
release.debian.org bug.

This package is part of the ongoing testing transition known as libglib2.0-
0t64. Please avoid uploads unrelated to this transition, they would likely delay
it and require supplementary work from the release managers. On the other hand,
if your package has problems preventing it to migrate to testing, please fix
them as soon as possible. You can probably find supplementary information in the
debian-release archives or in the corresponding release.debian.org bug.



Thanks
-Steve




On Sat, 2024-04-20 at 09:19 -0400, Boyuan Yang wrote:
> Source: sayonara
> Version: 1.8.0-beta1-1
> Tags: sid
> X-Debbugs-CC: kokoye2...@gmail.com s...@swm1.com
> 
> Dear Debian sayonara package maintainers,
> 
> A new upstream release of package sayonara was released in Jan 2024.
> Since you are listed as Debian package maintainers, please consider
> upgrading its Debian package. If you have any questions, please let
> me know.
> 
> Thanks,
> Boyuan Yang

Bug#1067065: nmu: gringo_5.6.2-1

[Steve M. Robbins]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: gri...@packages.debian.org
Control: affects -1 + src:gringo
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gringo_5.6.2-1 . ANY . unstable . -m "Rebuild against updated python3.11
for 64-bit time transition"

Bug#1060239: RM: pstotext -- ROM; No upstream, superceeded by ps2ascii

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: pstot...@packages.debian.org
Control: affects -1 + src:pstotext

The pstotext package was removed from testing in 2018 due to grave bug
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895513

It has been orphaned since then, with no visible interest
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898667

The last upstream release was 2004 and there is no trace of upstream on the
internet that I can see.  There's a wayback capture from mid 2007 but it was
removed shortly afterwards.

https://web.archive.org/web/20070609094538/http://www.cs.wisc.edu/~ghost/doc/
pstotext.htm

Thus I suggest this package should be completely removed from Debian.

Bug#1057117:

[Steve M]

Neil,

Thank you for taking to time to test my packaging efforts and submit a bug
report. I just did a quick test and was unable to reproduce your bug on Debian
testing. This weekend when I have a little more time I'll try setting up a clean
Debian unstable environment and try again.

$ mkdir hello && cd hello && swift package init --type executable
Creating executable package: hello
Creating Package.swift
Creating README.md
Creating .gitignore
Creating Sources/
Creating Sources/hello/main.swift
Creating Tests/
Creating Tests/helloTests/
Creating Tests/helloTests/helloTests.swift
$ swift build
Building for debugging...
[6/6] Linking hello
Build complete! (1.16s)
$ .build/x86_64-pc-linux-gnu/debug/hello
Hello, world!
$ 


-Steve

Bug#1051525: RFS: wxformbuilder/3.10.1-1 [RFP] -- GUI designer for the wxWidgets toolkit

[Steve M]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "wxformbuilder":

 * Package name : wxformbuilder
   Version  : 3.10.1-1
   Upstream contact : Steffen Olszewski 
 * URL  : http://wxformbuilder.org/
 * License  : MIT, GPL-2+, BOOST, BSD-3-Clause, MD5, CC0-1.0, ZLIB
 * Vcs  : https://github.com/wxFormBuilder/wxFormBuilder
   Section  : devel

The source builds the following binary packages:

  wxformbuilder - GUI designer for the wxWidgets toolkit

To access further information about this package, please visit the following
URL:

  https://mentors.debian.net/package/wxformbuilder/

Alternatively, you can download the package with 'dget' using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/w/wxformbuilder/wxformbuilder_3.10.1-1.dsc

Changes for the initial release:

 wxformbuilder (3.10.1-1) unstable; urgency=low
 .
   * Initial release (Closes: #390135)

Regards,
Steve

Bug#1040268: RM: mriconvert -- ROM; Obsolete, abandoned upstream

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: mriconv...@packages.debian.org
Control: affects -1 + src:mriconvert

The functionality of this software is provided by dcm2niix.  Upstream has
stopped maintaining the software and providing source code.

Bug#1038887: passwordsafe: googletest no longer supports C++ prior to C++14

[Steve M. Robbins]

Source: passwordsafe
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

I saw autopkgtest failure for passwordsafe

133s /usr/include/gtest/internal/gtest-port.h:270:2: error: #error C++ versions
less than C++14 are not supported.
133s   270 | #error C++ versions less than C++14 are not supported.


https://ci.debian.net/data/autopkgtest/testing/amd64/p/passwordsafe/34717192/log.gz


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

Kernel: Linux 6.3.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1031953: libkf5screen8: Second monitor issues with NVIDIA

[Steve M. Robbins]

Package: libkf5screen8
Version: 4:5.27.0-1
Severity: normal
Tags: patch upstream

This is to note that the upstream bug titled "On X11 with proprietary NVIDIA
GPU drivers, external monitor disabled after reboot or wake-from-sleep" applies
to Debian package 4.27.0-1.

See https://bugs.kde.org/show_bug.cgi?id=460341

Today a fix has finally been found.  There are at least a few reports that it
solves the issue -- I've tested it myself and it does solve the symptom I've
been having since October 2022.

The patch is:
https://invent.kde.org/plasma/libkscreen/-/commit/1d237c29655c7e3fb15fb9b71e5f167bd207593f

I'd love to see it applied before the release.  Happy to do an upload myself if
that's preferred.

-Steve


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-5-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libkf5screen8 depends on:
ii  libc6  2.36-8
ii  libkf5screen-data  4:5.27.0-1.1
ii  libqt5core5a   5.15.8+dfsg-2
ii  libqt5dbus55.15.8+dfsg-2
ii  libqt5gui5 5.15.8+dfsg-2
ii  libqt5x11extras5   5.15.8-2
ii  libstdc++6 12.2.0-14

Versions of packages libkf5screen8 recommends:
ii  hwdata  0.367-1

libkf5screen8 suggests no packages.

-- no debconf information
diff --git a/backends/xrandr/xrandrconfig.cpp b/backends/xrandr/xrandrconfig.cpp
index 
4ab5b3c4e1f49752c80eb6fca4f39691954024f9..50910d44f766b755208c28bfdccee4821e9ed7e3
 100644
--- a/backends/xrandr/xrandrconfig.cpp
+++ b/backends/xrandr/xrandrconfig.cpp
@@ -128,11 +128,16 @@ void XRandRConfig::applyKScreenConfig(const 
KScreen::ConfigPtr )
 const QSize newScreenSize = screenSize(config);
 const QSize currentScreenSize = m_screen->currentSize();
 
-// Previously we initially set such screen size, that it can take the 
current
-// as well  as the new configuration, then we apply the output changes,
-// and finally then (if necessary) we reduce the screen size to
-// fix the new configuration precisely.Now we initially disable the output,
-// then set the target screen size, and finally we apply the output 
changes.
+// When the current screen configuration is bigger than the new size (like
+// when rotating an output), the XSetScreenSize can fail or apply the 
smaller
+// size only partially, because we apply the size (we have to) before the
+// output changes. To prevent all kinds of weird screen sizes from 
happening,
+// we initially set such screen size, that it can take the current as well
+// as the new configuration, then we apply the output changes, and finally 
then
+// (if necessary) we reduce the screen size to fix the new configuration 
precisely.
+const QSize intermediateScreenSize =
+QSize(qMax(newScreenSize.width(), currentScreenSize.width()), 
qMax(newScreenSize.height(), currentScreenSize.height()));
+
 int neededCrtcs = 0;
 
 // pairs of before/after
@@ -246,6 +251,7 @@ void XRandRConfig::applyKScreenConfig(const 
KScreen::ConfigPtr )
 qCDebug(KSCREEN_XRANDR) << "\tChange Screen Size:" << (newScreenSize != 
currentScreenSize);
 if (newScreenSize != currentScreenSize) {
 qCDebug(KSCREEN_XRANDR) << "\t\tOld:" << currentScreenSize << "\n"
+<< "\t\tIntermediate:" << 
intermediateScreenSize << "\n"
 << "\t\tNew:" << newScreenSize;
 }
 
@@ -280,14 +286,24 @@ void XRandRConfig::applyKScreenConfig(const 
KScreen::ConfigPtr )
 disableOutput(output);
 }
 
-if (currentScreenSize != newScreenSize) {
-for (const KScreen::OutputPtr  : toChange) {
-disableOutput(output);
-}
+if (intermediateScreenSize != currentScreenSize) {
+setScreenSize(intermediateScreenSize);
 }
 
 bool forceScreenSizeUpdate = false;
 
+for (const KScreen::OutputPtr  : toChange) {
+if (!changeOutput(output)) {
+/* If we disabled the output before changing it and XRandR failed
+ * to re-enable it, then update screen size too */
+if (toDisable.contains(output->id())) {
+output->setEnabled(false);
+qCDebug(KSCREEN_XRANDR) << "Output failed to change: " << 
output->name();
+forceScreenSizeUpdate = true;
+}
+}
+}
+
 for (const KScreen::OutputPtr  : toEnable) {
 if (!enableOutput(output)) {
 qCDebug(KSCREEN_XRANDR) << "Output failed to be Enabled: " << 
output->name();
@@ -302,7 +318,7 @@ void XRandRConfig::applyKScreenConfig(const 
KScreen::ConfigPtr 

Bug#969202: ITA: binutils-avr -- Binary utilities supporting Atmel's AVR targets

[Steve M]

Joshua,

It has been a little over a year since you changed binutils-avr from RFA to ITA.
Do you still intend to proceed with this adoption? If not, please consider
returning it to RFA as I am considering adopting avr-libc, binutils-avr, and
gcc-avr as a group.

Thanks
-Steve

Bug#1020803: RM: matrix-mirage -- ROM; Orphaned, possibly dead upstream, dependency qtav is dead upstream

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 1013...@bugs.debian.org, 1020...@bugs.debian.org

Note: I'm not technically the maintainer of matrix-mirage, but I didn't see a
more fitting category and it is orphaned.

Bug#1020397: RM: qtav -- ROM; Package is abandoned upstream

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 1004...@bugs.debian.org

See https://github.com/wang-
bin/QtAV/commit/fdc613dc99304f208cff0bb25b3ded14bb993237

Bug#1019863: opencv.jar: broken symbolic link to opencv4/opencv-454d.jar

[Steve M. Robbins]

Package: libopencv-java
Version: 4.6.0+dfsg-6+b1
Severity: important

This bug makes the build of (unrelated) package libsis-jhdf5-java fail.


$ dpkg --search /usr/share/java/opencv.jar
libopencv-java: /usr/share/java/opencv.jar
$ file /usr/share/java/opencv.jar
/usr/share/java/opencv.jar: broken symbolic link to opencv4/opencv-454d.jar


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-1-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libopencv-java depends on:
ii  libopencv406-jni  4.6.0+dfsg-6+b1

libopencv-java recommends no packages.

libopencv-java suggests no packages.

-- no debconf information

Bug#1018987: nmu: minc-tools_2.3.00+dfsg-9

[Steve M. Robbins]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu minc-tools_2.3.00+dfsg-9 . ANY . unstable . -m "rebuild against updated
libminc"

Bug#1018888: nmu: elastix_5.0.1-3+b1

[Steve M. Robbins]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu elastix_5.0.1-3+b1 . ANY . unstable . -m "Rebuild against updated
insighttoolkit5"

Bug#1018839: nmu: insighttoolkit5_5.2.1-5

[Steve M. Robbins]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu insighttoolkit5_5.2.1-5 . ANY . unstable . -m "Rebuild against updated 
libminc"

Bug#990047: timeshift: Not possible to browse content of snapshot via the gui

[Steve M]

On Mon, 2022-08-01 at 22:26 +, Ludovic Poujol wrote:
> Steeve,
> 
> Good question. And, you're right, thanks !
> 
> I thought it was some kind of "internal browser" provided with 
> timeshift. But after looking more closely, it was actually trying to 
> start VSCode ! :s And it's the one that do not like to be run as
> root.
> 
> Not sure why or how it decided to use it instead of the Gnome file 
> browser. But apt remove of it "fixed" the issue.
> 
> I don't see any settings for that in the timeshift GUI. I'm not sure
> how 
> I can force it to use the default gnome file browser :(
> 
> 
> Thanks
> 
> --
> Ludovic Poujol

Ludovic,

Timeshift first uses xdg-open to call the default tool of your desktop
environment as it in turn calls gvfs-open, kde-open, exo-open, gnome-
open, etc. as appropriate. On my Debian desktop with KDE running xdg-
open and kde-open launche Dolphin, but on my Pop_OS laptop xdg_open is
not installed and there is no gvfs-open for some reason.

In the event that xdg_open fails, Timeshift tries in order to launch
nemo, nautilus, thunar, io.elementary.files, pantheon-files, marlin,
and dolphin lastly.

In your case it seems that maybe xdg-open is resulting in "code" being
called due to your Gnome settings. The command `xdg-mime query default
inode/directory` should report out what the default file browser is set
to. You can also look in ~/.config/mimeapps.list to see what it is set
to. I think you can just edit this file or run a command similar to
`xdg-mime default org.gnome.Nautilus.desktop inode/directory` to make a
change.

Please let me know how this works out as it may be worth asking
upstream for a more robust means of opening the default file manager.

Thanks
-Steve

Bug#994704: timeshift: Unable to init server: connection refused. possible pkexec misconfiguration for timeshift-laucher command

[Steve M]

Bruno,

I've not been able to reproduce this problem. Does it still happen for
you?

Thanks
-Steve

Bug#990047: timeshift: Not possible to browse content of snapshot via the gui

[Steve M]

Ludovic,

This sounds to me like an issue with not being allowed to run your file
browser with root permissions. If this is still a problem for you,
which file browser are you using?

Thanks
-Steve

Bug#1016436: lldb-14: lldb malfunctions due to faulty python path (ModuleNotFoundError: No module named 'lldb.embedded_interpreter')

[Steve M. Robbins]

Package: lldb-14
Version: 1:14.0.6-2
Severity: normal

Dear Maintainer,

There is a misconfiguration somewhere in the build, that embeds a non-existent
python path:

  $ lldb -P
  /usr/lib/local/lib/python3.10/dist-packages

This causes lldb to emit an error when starting:

$ lldb
Traceback (most recent call last):
  File "", line 1, in 
ModuleNotFoundError: No module named 'lldb.embedded_interpreter'

See https://bugs.launchpad.net/ubuntu/+source/llvm-defaults/+bug/1972855 for 
full description and a workaround.



-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-3-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lldb-14 depends on:
ii  libc62.33-8
ii  libclang-cpp14   1:14.0.6-2
ii  libedit2 3.1-20210910-1
ii  libgcc-s112.1.0-7
ii  liblldb-14   1:14.0.6-2
ii  libllvm141:14.0.6-2
ii  libncurses6  6.3+20220423-2
ii  libstdc++6   12.1.0-7
ii  libtinfo66.3+20220423-2
ii  libxml2  2.9.14+dfsg-1+b1
ii  llvm-14-dev  1:14.0.6-2
ii  python3-lldb-14  1:14.0.6-2
ii  zlib1g   1:1.2.11.dfsg-4

lldb-14 recommends no packages.

lldb-14 suggests no packages.

-- no debconf information

Bug#1014891: timeshift: New upstream release 22.06.3

[Steve M]

On Wed, 2022-07-13 at 17:32 -0400, Boyuan Yang wrote:
> Package: timeshift
> Version: 22.06.1-0.1
> Severity: normal
> X-Debbugs-CC: s...@swm1.com
> 
> Dear Debian timeshift package maintainers,
> 
> A new upstream release is available at
> https://github.com/linuxmint/timeshift/releases/tag/22.06.3 . Please
> consider packaging it.
> 
> Thanks,
> Boyuan Yang

Boyuan,

Thank you for this alert and for preparing 22.06.4 in the Salsa git
repo. I had a very busy two weeks when this happened but am
anticipating more time now to work on Timeshift updates. I see that
22.06.5 has been released so I will work on merging in that update.

Thanks
-Steve

Bug#1013333: libidn12: Upgrade to libidn 1.40-1 breaks kmail

[Steve M. Robbins]

Package: libidn12
Version: 1.40-1
Severity: important

Dear Maintainer,

I had version 1.38-4 installed until I ran apt upgrade today.  After the 
upgrade, mail that originated
outside of my system seems to vanish.  The mail logs show a normal delivery (by 
postfix).  But kmail shows
no sign of the mail.  Nor does my android mail client that uses imap to read 
the same mailbox.

I downgraded libidn12 back to 1.38-4 (with NO other changes to packages or 
configuration) and kmail is working again.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (700, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.18.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libidn12 depends on:
ii  libc6  2.33-7

libidn12 recommends no packages.

libidn12 suggests no packages.

-- no debconf information

Bug#1005710: RM: elastix [i386] -- ROM; No longer targets i386

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal

The ITK v5 package only builds for amd64, so the elastix i386 binaries need 
removing to allow it to get to testing.
At least that's how I understand the excuse output
https://qa.debian.org/excuses.php?package=elastix

Thanks,
-Steve

Bug#992473: kmail: Unread messages suddenly pink

[Steve M. Robbins]

Package: kmail
Version: 4:20.08.3-1
Severity: normal

Dear Maintainer,

Today KMail decided to colour unread messages (in the message list) bright 
pink.  It was not pink previously.

-Steve


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kmail depends on:
ii  akonadi-server   4:20.08.3-3
ii  kdepim-runtime   4:20.08.3-1
ii  kio  5.83.0-2
ii  libc62.31-16
ii  libgcc-s111.2.0-2
ii  libgpgmepp6  1.14.0-1+b2
ii  libkf5akonadiagentbase5 [libkf5akonadiagentbase5-20.08]  4:20.08.3-3
ii  libkf5akonadicontact5 [libkf5akonadicontact5-20.08]  4:20.08.3-1
ii  libkf5akonadicore5abi2 [libkf5akonadicore5-20.08]4:20.08.3-3
ii  libkf5akonadimime5 [libkf5akonadimime5-20.08]4:20.08.3-1
ii  libkf5akonadisearch-bin  4:20.08.3-1
ii  libkf5akonadisearch-plugins  4:20.08.3-1
ii  libkf5akonadisearchdebug5 [libkf5akonadisearchdebug5-20.08]  4:20.08.3-1
ii  libkf5akonadisearchpim5 [libkf5akonadisearchpim5-20.08]  4:20.08.3-1
ii  libkf5akonadiwidgets5abi1 [libkf5akonadiwidgets5-20.08]  4:20.08.3-3
ii  libkf5bookmarks5 5.83.0-2
ii  libkf5calendarcore5abi2  5:5.83.0-2
ii  libkf5calendarutils5 [libkf5calendarutils5-20.08]4:20.08.3-1
ii  libkf5codecs55.83.0-2
ii  libkf5completion55.83.0-2
ii  libkf5configcore55.83.0-2
ii  libkf5configgui5 5.83.0-2
ii  libkf5configwidgets5 5.83.0-3
ii  libkf5contacts5  5:5.83.0-2
ii  libkf5coreaddons55.83.0-2
ii  libkf5crash5 5.83.0-2
ii  libkf5dbusaddons55.83.0-2
ii  libkf5grantleetheme-plugins  20.08.3-1
ii  libkf5gravatar5abi2 [libkf5gravatar5-20.08]  4:20.08.3-1
ii  libkf5guiaddons5 5.83.0-2
ii  libkf5i18n5  5.83.0-3
ii  libkf5iconthemes55.83.0-2
ii  libkf5identitymanagement5 [libkf5identitymanagement5-20.08]  20.08.3-1
ii  libkf5itemmodels55.83.0-2
ii  libkf5itemviews5 5.83.0-2
ii  libkf5jobwidgets55.83.0-2
ii  libkf5kcmutils5  5.83.0-2
ii  libkf5kiocore5   5.83.0-2
ii  libkf5kiofilewidgets55.83.0-2
ii  libkf5kiogui55.83.0-2
ii  libkf5kiowidgets55.83.0-2
ii  libkf5kontactinterface5 [libkf5kontactinterface5-20.08]  20.08.3-1
ii  libkf5ksieveui5 [libkf5ksieveui5-20.08]  4:20.08.3-1
ii  libkf5ldap5abi1 [libkf5ldap5-20.08]  20.08.3-1
ii  libkf5libkdepim5 [libkf5libkdepim5-20.08]4:20.08.3-1
ii  libkf5libkleo5 [libkf5libkleo5-20.08]4:20.08.3-1
ii  libkf5mailcommon5abi2 [libkf5mailcommon5-20.08]  4:20.08.3-1
ii  libkf5mailtransport5 [libkf5mailtransport5-20.08]20.08.3-1
ii  libkf5mailtransportakonadi5 [libkf5mailtransportakonadi5-20  20.08.3-1
ii  libkf5messagecomposer5abi1 [libkf5messagecomposer5-20.08]4:20.08.3-5
ii  libkf5messagecore5abi1 [libkf5messagecore5-20.08]4:20.08.3-5
ii  libkf5messagelist5abi1 [libkf5messagelist5-20.08]4:20.08.3-5
ii  libkf5messageviewer5abi1 [libkf5messageviewer5-20.08]4:20.08.3-5
ii  libkf5mime5abi1 [libkf5mime5-20.08]  20.08.3-1
ii  libkf5mimetreeparser5abi1 [libkf5mimetreeparser5-20.08]  4:20.08.3-5
ii  libkf5notifications5 5.83.0-2
ii  libkf5notifyconfig5  

Bug#992426: debianutils: Removal of tempfile breaks X login

[Steve M. Robbins]

Package: debianutils
Version: 5.0.1-1
Severity: important

Dear Maintainer,

The /etc/XSession script uses tempfile, so removal of that package breaks 
logging into X.


-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages debianutils depends on:
ii  libc6  2.31-15

debianutils recommends no packages.

debianutils suggests no packages.

-- no debconf information

Bug#991837: /usr/lib/python3/dist-packages/gbp/scripts/supercommand.py: import-orig failure

[Steve M. Robbins]

Package: git-buildpackage
Version: 0.9.22
Severity: normal
File: /usr/lib/python3/dist-packages/gbp/scripts/supercommand.py

Dear Maintainer,

I attempted to import a new version into 'experimental' branches using: "gbp 
import-orig --pristine-tar --upstream-branch=upstream-experimental 
--debian-branch=experimental  ~/Downloads/digikam-7.3.0.tar.xz"

It "failed to reproduce build of ../digikam_7.3.0.orig.tar.xz"

Run with --verbose:

gbp:debug: ['git', 'rev-parse', '--show-cdup']
gbp:debug: ['git', 'rev-parse', '--is-bare-repository']
gbp:debug: ['git', 'rev-parse', '--git-dir']
gbp:debug: ['git', 'for-each-ref', '--format=%(refname:short)', 'refs/heads/']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream-experimental']
gbp:debug: ['git', 'status', '--porcelain']
What is the upstream version? [7.3.0] 
gbp:debug: ['git', 'tag', '-l', 'upstream/7.3.0']
gbp:debug: tar ['-C', '../tmpbk46rf8d', '-a', '-xf', 
'/home/steve/Downloads/digikam-7.3.0.tar.xz'] []
gbp:debug: Unpacked '/home/steve/Downloads/digikam-7.3.0.tar.xz' to 
'../tmpbk46rf8d/digikam-7.3.0'
gbp:info: 
gbp:info: Importing '/home/steve/Downloads/digikam-7.3.0.tar.xz' to branch 
'upstream-experimental'...
gbp:info: Source package is digikam
gbp:info: Upstream version is 7.3.0
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/upstream-experimental']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream-experimental']
gbp:debug: ['git', 'add', '-f', '.']
gbp:debug: ['git', 'write-tree']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'upstream-experimental']
gbp:debug: ['git', 'commit-tree', 'f8eadb9d14b1596e9f6ab263a895230a71614291', 
'-p', '2090afd33254af7acfdd2fd5e57a77cc270fa584']
gbp:debug: ['git', 'update-ref', '-m', 'gbp: New upstream version 7.3.0', 
'refs/heads/upstream-experimental', '5f5a4bf691c048b5c7a9b9641b55af38193f2e23', 
'2090afd33254af7acfdd2fd5e57a77cc270fa584']
gbp:debug: ['git', 'show-ref', '--verify', 'refs/heads/pristine-tar']
gbp:debug: ['git', 'rev-parse', '--quiet', '--verify', 'pristine-tar']
gbp:debug: ['git', 'ls-tree', '-z', 'upstream-experimental', '--']
gbp:debug: ['git', 'mktree', '-z']
gbp:debug: pristine-tar [] ['commit', '../digikam_7.3.0.orig.tar.xz', 
'f8eadb9d14b1596e9f6ab263a895230a71614291']
gbp:error: Import of ../digikam_7.3.0.orig.tar.xz failed: Couldn't commit to 
'pristine-tar' with upstream 'f8eadb9d14b1596e9f6ab263a895230a71614291': 
pristine-xz failed to reproduce build of ../digikam_7.3.0.orig.tar.xz
(Please file a bug report.)
pristine-tar: failed to generate delta
gbp:error: Error detected, Will roll back changes.
gbp:info: Rolling back branch upstream-experimental by resetting it to 
2090afd33254af7acfdd2fd5e57a77cc270fa584
gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of 
upstream-experimental', 'refs/heads/upstream-experimental', 
'2090afd33254af7acfdd2fd5e57a77cc270fa584']
gbp:info: Rolling back branch pristine-tar by resetting it to 
0505953bee2887d1fef8d301b0d852773a178ac6
gbp:debug: ['git', 'update-ref', '-m', 'gbp import-orig: failure rollback of 
pristine-tar', 'refs/heads/pristine-tar', 
'0505953bee2887d1fef8d301b0d852773a178ac6']
gbp:error: Rolled back changes after import error.
gbp:debug: rm ['-rf', '../tmpbk46rf8d'] []


-- System Information:
Debian Release: 11.0
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.10.0-8-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages git-buildpackage depends on:
ii  devscripts 2.21.3
ii  git1:2.30.2-1
ii  man-db 2.9.4-2
ii  python33.9.2-3
ii  python3-dateutil   2.8.1-6
ii  python3-pkg-resources  52.0.0-4
ii  sensible-utils 0.0.14

Versions of packages git-buildpackage recommends:
ii  cowbuilder0.89
ii  pbuilder  0.231
ii  pristine-tar  1.49
ii  python3-requests  2.25.1+dfsg-2
ii  sbuild0.81.2

Versions of packages git-buildpackage suggests:
ii  python3-notify2  0.3-4
ii  sudo 1.9.5p2-3
ii  unzip6.0-26

-- no debconf information

Bug#975422: samba-common-bin: Cannot install 2:4.13.2+dfsg-2+b1: /run samba does not exist.

[Steve M. Robbins]

Package: samba-common-bin
Version: 2:4.13.2+dfsg-2+b1
Severity: important

Dear Maintainer,

Install failed as follows.  This was a second attempt so apt reports samba 
"already the newest version".  
But the first attempt had the same errors about /run/samba; I would have 
expected one of these packages
to create the directory if not already existing.

Also: I used to have samba until an update a couple days ago.  So maybe some 
samba upgrade removed that
dir?


$ sudo apt install samba
Reading package lists... Done
Building dependency tree   
Reading state information... Done
samba is already the newest version (2:4.13.2+dfsg-2+b1).
The following packages were automatically installed and are no longer required:
  i965-va-driver:i386 intel-media-va-driver:i386 libaom0:i386 libavcodec58:i386 
libavutil56:i386 libcodec2-0.9:i386 libdav1d4:i386 libdcmtk14 
libedataserver-1.2-24 libgomp1:i386 libigdgmm11:i386 libkdecorations2private6 
libmp3lame0:i386 libnuma1:i386 libperl5.30 libperl5.30:i386 libreoffice-kde5
  libshine3:i386 libsnappy1v5:i386 libsoxr0:i386 libspeex1:i386 
libstd-rust-1.46 libswresample3:i386 libtwolame0:i386 libva-drm2:i386 
libva-x11-2:i386 libva2:i386 libvdpau-va-gl1:i386 libvdpau1:i386 libvpx6:i386 
libwavpack1:i386 libwebpmux3:i386 libx264-160:i386 libx265-192:i386 
libxvidcore4:i386
  libzvbi0:i386 linux-kbuild-5.8 mesa-va-drivers:i386 mesa-vdpau-drivers:i386 
perl-modules-5.30 python3-crypto sphinx-rtd-theme-common va-driver-all:i386 
vdpau-driver-all:i386
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up samba-common-bin (2:4.13.2+dfsg-2+b1) ...
Checking smb.conf with testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
ERROR: lock directory /run/samba does not exist

ERROR: pid directory /run/samba does not exist

Server role: ROLE_STANDALONE

dpkg: error processing package samba-common-bin (--configure):
 installed samba-common-bin package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of samba:
 samba depends on samba-common-bin (= 2:4.13.2+dfsg-2+b1); however:
  Package samba-common-bin is not configured yet.

dpkg: error processing package samba (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 samba-common-bin
 samba
 install samba
Reading package lists... Done
Building dependency tree   
Reading state information... Done
samba is already the newest version (2:4.13.2+dfsg-2+b1).
The following packages were automatically installed and are no longer required:
  i965-va-driver:i386 intel-media-va-driver:i386 libaom0:i386 libavcodec58:i386 
libavutil56:i386 libcodec2-0.9:i386 libdav1d4:i386 libdcmtk14 
libedataserver-1.2-24 libgomp1:i386 libigdgmm11:i386 libkdecorations2private6 
libmp3lame0:i386 libnuma1:i386 libperl5.30 libperl5.30:i386 libreoffice-kde5
  libshine3:i386 libsnappy1v5:i386 libsoxr0:i386 libspeex1:i386 
libstd-rust-1.46 libswresample3:i386 libtwolame0:i386 libva-drm2:i386 
libva-x11-2:i386 libva2:i386 libvdpau-va-gl1:i386 libvdpau1:i386 libvpx6:i386 
libwavpack1:i386 libwebpmux3:i386 libx264-160:i386 libx265-192:i386 
libxvidcore4:i386
  libzvbi0:i386 linux-kbuild-5.8 mesa-va-drivers:i386 mesa-vdpau-drivers:i386 
perl-modules-5.30 python3-crypto sphinx-rtd-theme-common va-driver-all:i386 
vdpau-driver-all:i386
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
2 not fully installed or removed.
After this operation, 0 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Setting up samba-common-bin (2:4.13.2+dfsg-2+b1) ...
Checking smb.conf with testparm
Load smb config files from /etc/samba/smb.conf
Loaded services file OK.
Weak crypto is allowed
ERROR: lock directory /run/samba does not exist

ERROR: pid directory /run/samba does not exist

Server role: ROLE_STANDALONE

dpkg: error processing package samba-common-bin (--configure):
 installed samba-common-bin package post-installation script subprocess 
returned error exit status 1
dpkg: dependency problems prevent configuration of samba:
 samba depends on samba-common-bin (= 2:4.13.2+dfsg-2+b1); however:
  Package samba-common-bin is not configured yet.

dpkg: error processing package samba (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 samba-common-bin
 samba

Reading package lists... Done
Building dependency tree   
Reading state information... Done
samba is already the newest version (2:4.13.2+dfsg-2+b1).
The following packages were automatically installed and are no longer required:
  i965-va-driver:i386 intel-media-va-driver:i386 libaom0:i386 libavcodec58:i386 
libavutil56:i386 libcodec2-0.9:i386 libdav1d4:i386 

Bug#973001: seqan3: autopackage tests need updating for new googletest

[Steve M. Robbins]

Source: seqan3
Severity: normal

Dear Maintainer,

The autopkg tests need to be updated for the new googletest.  There are 
failures such as

/tmp/autopkgtest-lxc.u2mymoo7/downtmp/autopkgtest_tmp/unit/alphabet/cigar/../alphabet_test_template.hpp:86:
 Failure
Type parameterized test suite alphabet is defined via 
REGISTER_TYPED_TEST_SUITE_P, but never instantiated via 
INSTANTIATE_TYPED_TEST_SUITE_P. None of the test cases will run.

Ideally, TYPED_TEST_P definitions should only ever be included as part of 
binaries that intend to use them. (As opposed to, for example, being placed in 
a library that may be linked in to get other utilities.)



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#972944: ms-gsl: autopkgtests should build googletest from sources

[Steve M. Robbins]

Source: ms-gsl
Severity: normal

Dear Maintainer,

A new version of googletest has been uploaded and shortly thereafter I received 
word that ms-gsl autopkgtest has failed on arm64.   See https://ci.debian.net/
data/autopkgtest/testing/arm64/m/ms-gsl/7637851/log.gz

The error in that log looks like an underlinking problem (see below).  But I 
can't understand how that is possible, since gtest itself builds and runs unit 
tests itself
https://buildd.debian.org/status/fetch.php?
pkg=googletest=arm64=1.10.0.20201018-1=1603081647=0

My best guess is that there may be an incompatiblity between the test code 
built using g++8 and libgtest.a built with g++10.   The previous successful 
autopkgtest used googletest 1.10.0-3 that was built with g++9.

It used to be the case that googletest required everyone to build the gtest 
library from source and no libgtest.a was shipped.  I'd suggest going that 
route to avoid problems.  See https://github.com/google/googletest/blob/
master/googletest/README.md for building from sources (in /usr/src/
googletest).


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#972603: seqan: Needs update for new googletest

[Steve M. Robbins]

Source: seqan
Severity: normal

Dear Maintainer,

Hi,

Just uploaded a newer googletest and seqan is reporting autopkgtest failures.  
However, at least some failures appear to be due to changes in googletest that 
require
adapting the test code.  For example, the following [from 
https://ci.debian.net/data/autopkgtest/testing/amd64/s/seqan3/7629025/log.gz]


Type parameterized test suite alphabet is defined via 
REGISTER_TYPED_TEST_SUITE_P, but never instantiated via 
INSTANTIATE_TYPED_TEST_SUITE_P. None of the test cases will run.

Ideally, TYPED_TEST_P definitions should only ever be included as part of 
binaries that intend to use them. (As opposed to, for example, being placed in 
a library that may be linked in to get other utilities.)

To suppress this error for this test suite, insert the following line (in a 
non-header) in the namespace it is definedin in:

GTEST_ALLOW_UNINSTANTIATED_PARAMETERIZED_TEST(alphabet);




-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#971412: libdcmtk-dev: undeclared conflict with libcharls-dev

[Steve M. Robbins]

Package: libdcmtk-dev
Version: 3.6.4-2.1+b1
Severity: normal

Dear Maintainer,

I just attempted to install libcharls-dev, which failed:

  E: /var/cache/apt/archives/libcharls-dev_2.1.0+dfsg-1_amd64.deb: trying to 
overwrite '/usr/lib/x86_64-linux-gnu/libcharls.so', which is also in package 
libdcmtk-dev 3.6.4-2.1+b1

I would guess that libcharls-dev has a better claim to this file than 
libdcmtk-dev.  


-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (200, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.8.0-2-amd64 (SMP w/16 CPU threads)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libdcmtk-dev depends on:
ii  libcharls-dev  2.0.0+dfsg-1+b1
ii  libdcmtk14 3.6.4-2.1+b1
ii  libpng-dev 1.6.37-3
ii  libssl-dev 1.1.1g-1
ii  libtiff-dev4.1.0+git191117-2
ii  libwrap0-dev   7.6.q-30
ii  libxml2-dev2.9.10+dfsg-6

libdcmtk-dev recommends no packages.

Versions of packages libdcmtk-dev suggests:
pn  dcmtk-doc  

-- no debconf information

Bug#951629: RFS: timeshift/19.01+ds-2.1 [NMU] [RC] -- System restore utility

[Steve M]

On Wed, 19 Feb 2020 10:05:49 -0500 Boyuan Yang  wrote:

> Hi Steve, wrar,

> 

> On Wed, 19 Feb 2020 12:40:15 +0500 Andrey
Rahmatullin  wrote:

> > Control: tags -1 + moreinfo

> > 

> > Unfortunately you ignored 

> https://lists.debian.org/debian-mentors/2020/02/msg00124.html

> > lintian even tells you about the mangled
changelog.

> 

> I'm letting you know that I am keeping an eye on
package timeshift since I

> granted the original maintainer DM permission. I
know the original maintainer

> privately and it looks like he is extremely unlikely
to work on timeshift (and

> any other Debian work) in the foreseeable future.
For now, I will not work on

> fixing it or salvaging the package since it's a
perfectly valuable chance for

> you (Steve) to practice and participate in Debian's
work.

> 

> Steve: I took a look at the source package you
provided on mentors.debian.net.

> Actually wrar gave some valuable advice and there
are some bugs that *must* be

> fixed before anyone accept your work (namely the
duplicated changelog

> entries). If you are unsure about what changes you
made, please take advantage

> of the debdiff(1) tool and check the differences
between the existing version

> and your proposed version.

> 

> Please *DO* fix it and let us know when you are
ready. I will be glad to help

> you upload this NMU. Let me know if you have any
doubts.

> 

> -- 

> Thanks,

> Boyuan YangThank you both and kokoye2007for your feedback and for enduring my ignorance.wrar, for some reason I did not receive your very helpful reply on debian mentors that you linked me to. I will of course now follow your advise and clean things up.Boyua, I would be happy to assist or take over from the current maintainer in whatever capacity they desire.Thanks-Steve Meliza

Bug#944396: transition: exiv2

[Steve M. Robbins]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

New upstream, new soversion.

Ben file:

title = "exiv2";
is_affected = .depends ~ "libexiv2-14" | .depends ~ "libexiv2-27";
is_good = .depends ~ "libexiv2-27";
is_bad = .depends ~ "libexiv2-14";


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

Kernel: Linux 5.3.0-1-amd64 (SMP w/16 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#899274: KMail does not always remember the desired message list columns

[Steve M. Robbins]

Package: kmail
Version: 4:17.12.3-1
Severity: normal

In the folder list, KMail is able to display several columns: Name,
Unread, Total, and Size.  I have turned off all but Name.

Kmail regularly seems to ignore my wishes and displays all four
columns when I re-start.  But this does not happen all the time.




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

Kernel: Linux 4.16.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kmail depends on:
ii  akonadi-server   4:17.12.3-2+b1
ii  kdepim-runtime   4:17.12.3-2
ii  kio  5.45.0-1
ii  libc62.27-3
ii  libgcc1  1:8.1.0-3
ii  libgpgmepp6  1.11.1-1
ii  libkf5akonadiagentbase5  4:17.12.3-2+b1
ii  libkf5akonadicontact54:17.12.3-2
ii  libkf5akonadicore5abi1   4:17.12.3-2+b1
ii  libkf5akonadimime5   4:17.12.3-1
ii  libkf5akonadisearch-bin  4:17.12.3-1
ii  libkf5akonadisearch-plugins  4:17.12.3-1
ii  libkf5akonadisearchdebug54:17.12.3-1
ii  libkf5akonadisearchpim5  4:17.12.3-1
ii  libkf5akonadiwidgets5abi14:17.12.3-2+b1
ii  libkf5bookmarks5 5.45.0-1
ii  libkf5calendarcore5abi1  4:17.12.3-1
ii  libkf5calendarutils5 4:17.12.3-1
ii  libkf5codecs55.45.0-1
ii  libkf5completion55.45.0-1
ii  libkf5configcore55.45.0-1
ii  libkf5configgui5 5.45.0-1
ii  libkf5configwidgets5 5.45.0-1
ii  libkf5contacts5  4:17.12.3-1
ii  libkf5coreaddons55.45.0-1
ii  libkf5crash5 5.45.0-1
ii  libkf5dbusaddons55.45.0-1
ii  libkf5followupreminder5  4:17.12.3-1
ii  libkf5grantleetheme-plugins  17.12.3-1
ii  libkf5gravatar5abi1  4:17.12.3-1
ii  libkf5guiaddons5 5.45.0-1
ii  libkf5i18n5  5.45.0-1
ii  libkf5iconthemes55.45.0-1
ii  libkf5identitymanagement517.12.3-1
ii  libkf5itemmodels55.45.0-1
ii  libkf5itemviews5 5.45.0-1
ii  libkf5jobwidgets55.45.0-1
ii  libkf5kcmutils5  5.45.0-1
ii  libkf5kiocore5   5.45.0-1
ii  libkf5kiofilewidgets55.45.0-1
ii  libkf5kiowidgets55.45.0-1
ii  libkf5kontactinterface5  17.12.3-1
ii  libkf5ksieveui5  4:17.12.3-1
ii  libkf5libkdepim-plugins  4:17.12.3-1
ii  libkf5libkdepim5 4:17.12.3-1
ii  libkf5libkdepimakonadi5  4:17.12.3-1
ii  libkf5libkleo5   4:17.12.3-2
ii  libkf5mailcommon5abi14:17.12.3-1
ii  libkf5mailtransport5 17.12.3-1
ii  libkf5mailtransportakonadi5  17.12.3-1
ii  libkf5messagecomposer5   4:17.12.3-1
ii  libkf5messagecore5   4:17.12.3-1
ii  libkf5messagelist5   4:17.12.3-1
ii  libkf5messageviewer5 4:17.12.3-1
ii  libkf5mime5abi1  17.12.3-2
ii  libkf5mimetreeparser54:17.12.3-1
ii  libkf5notifications5 5.45.0-2
ii  libkf5notifyconfig5  5.45.0-2
ii  libkf5parts5 5.45.0-1
ii  libkf5pimcommon5abi1 4:17.12.3-1
ii  libkf5pimcommonakonadi5  4:17.12.3-1
ii  libkf5pimtextedit5abi1   17.12.3-2
ii  libkf5sendlater5 4:17.12.3-1
ii  libkf5service-bin5.45.0-1
ii  libkf5service5   5.45.0-1
ii  libkf5sonnetui5  5.45.0-1
ii  libkf5templateparser54:17.12.3-1
ii  libkf5textwidgets5   5.45.0-2
ii  libkf5tnef5  4:17.12.3-1
ii  libkf5wallet-bin 5.45.0-1
ii  libkf5wallet55.45.0-1
ii  libkf5webengineviewer5   4:17.12.3-1
ii  libkf5widgetsaddons5 5.45.0-1
ii  libkf5windowsystem5  5.45.0-1
ii  libkf5xmlgui55.45.0-1
ii  libqgpgme7   1.11.1-1
ii  libqt5core5a 5.10.1+dfsg-6+b1
ii  libqt5dbus5  5.10.1+dfsg-6+b1
ii  libqt5gui5   5.10.1+dfsg-6+b1
ii  libqt5network5   5.10.1+dfsg-6+b1
ii  libqt5widgets5   5.10.1+dfsg-6+b1
ii  libqt5xml5   5.10.1+dfsg-6+b1
ii  libstdc++6   8.1.0-3

Versions of packages kmail recommends:
ii  accountwizard   4:17.12.3-1
ii  gnupg   2.2.5-1
ii  kdepim-addons   17.12.3-2
ii  kdepim-themeeditors 4:17.12.3-1
ii  mbox-importer   4:17.12.3-1
ii  pim-data-exporter   4:17.12.3-1
ii  pim-sieve-editor4:17.12.3-1
ii  pinentry-gnome3 [pinentry-x11]  1.1.0-1+b1
ii  pinentry-gtk2 [pinentry-x11]1.1.0-1+b1
ii  pinentry-qt [pinentry-x11]  1.1.0-1+b1

Versions of packages kmail suggests:
pn  clamav
ii  crm114

Bug#897171: synergy: diff for NMU version 1.8.8-stable+dfsg.1-1.1

[Steve M. Robbins]

Control: tags 897171 + patch
Control: tags 897171 + pending

Dear maintainer,

I've prepared an NMU for synergy (versioned as 1.8.8-stable+dfsg.1-1.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.
-Steve

diff -Nru synergy-1.8.8-stable+dfsg.1/debian/changelog synergy-1.8.8-stable+dfsg.1/debian/changelog
--- synergy-1.8.8-stable+dfsg.1/debian/changelog	2017-03-11 17:38:53.0 -0600
+++ synergy-1.8.8-stable+dfsg.1/debian/changelog	2018-05-01 22:59:58.0 -0500
@@ -1,3 +1,10 @@
+synergy (1.8.8-stable+dfsg.1-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Update build-deps for googletest.  Closes: #897171.
+
+ -- Steve M. Robbins <s...@debian.org>  Tue, 01 May 2018 22:59:58 -0500
+
 synergy (1.8.8-stable+dfsg.1-1) unstable; urgency=low
 
   * New upstream version.
diff -Nru synergy-1.8.8-stable+dfsg.1/debian/control synergy-1.8.8-stable+dfsg.1/debian/control
--- synergy-1.8.8-stable+dfsg.1/debian/control	2017-03-11 17:38:53.0 -0600
+++ synergy-1.8.8-stable+dfsg.1/debian/control	2018-05-01 22:58:40.0 -0500
@@ -5,7 +5,7 @@
 Homepage: https://symless.com/synergy/
 Vcs-Git: https://github.com/epakai/synergy-debian.git
 Vcs-Browser: https://github.com/epakai/synergy-debian
-Build-Depends: cmake, debhelper (>=9), docbook, docbook-utils, libavahi-compat-libdnssd-dev, libqt4-dev, libssl-dev, libxinerama-dev, libxrandr-dev, libxtst-dev, libcurl4-gnutls-dev | libcurl-dev, google-mock, libgtest-dev
+Build-Depends: cmake, debhelper (>=9), docbook, docbook-utils, libavahi-compat-libdnssd-dev, libqt4-dev, libssl-dev, libxinerama-dev, libxrandr-dev, libxtst-dev, libcurl4-gnutls-dev | libcurl-dev, googletest, libgtest-dev, libgmock-dev
 Standards-Version: 3.9.8
 
 Package: synergy


signature.asc
Description: PGP signature

Bug#897174: Package erroneously expects googletest headers in /usr/include

[Steve M. Robbins]

On Sun, Apr 29, 2018 at 07:41:26AM -0500, Steve M. Robbins wrote:

> 1. Modify the build to look for headers in /usr/src/googletest.

Below is a patch to achieve this.

--- meson-0.46.0.orig/mesonbuild/dependencies/dev.py2018-03-03 
16:02:02.0 -0600
+++ meson-0.46.0/mesonbuild/dependencies/dev.py 2018-05-01 21:51:41.737194014 
-0500
@@ -48,7 +48,7 @@
 mlog.log('Dependency GTest found:', mlog.green('YES'), 
'(prebuilt)')
 elif self.detect_srcdir():
 self.is_found = True
-self.compile_args = ['-I' + self.src_include_dir]
+self.compile_args = ['-I' + d for d in self.src_include_dirs]
 self.link_args = []
 if self.main:
 self.sources = [self.all_src, self.main_src]
@@ -67,7 +67,7 @@
 os.path.join(self.src_dir, 'gtest-all.cc'))
 self.main_src = mesonlib.File.from_absolute_file(
 os.path.join(self.src_dir, 'gtest_main.cc'))
-self.src_include_dir = 
os.path.normpath(os.path.join(self.src_dir, '..'))
+self.src_include_dirs = [ 
os.path.normpath(os.path.join(self.src_dir, '..')),  
os.path.normpath(os.path.join(self.src_dir, '../include')) ]
 return True
 return False
 
@@ -96,7 +96,7 @@
 # Yes, we need both because there are multiple
 # versions of gmock that do different things.
 d2 = os.path.normpath(os.path.join(d, '..'))
-self.compile_args = ['-I' + d, '-I' + d2]
+self.compile_args = ['-I' + d, '-I' + d2, '-I' + d2 + 
'/include']
 self.link_args = []
 all_src = mesonlib.File.from_absolute_file(os.path.join(d, 
'gmock-all.cc'))
 main_src = mesonlib.File.from_absolute_file(os.path.join(d, 
'gmock_main.cc'))


The build-dependencies need adjusting as follows.


--- meson-0.46.0.orig/debian/control2018-04-22 11:42:22.0 -0500
+++ meson-0.46.0/debian/control 2018-05-01 22:03:25.962608495 -0500
@@ -21,8 +21,7 @@
   gobjc++ ,
   gnustep-make ,
   libgnustep-base-dev ,
-  libgtest-dev ,
-  google-mock ,
+  googletest ,
   qtbase5-dev ,
   qtbase5-dev-tools ,
   qttools5-dev-tools ,

-Steve


signature.asc
Description: PGP signature

Bug#897149: Package erroneously expects googletest headers in /usr/include

[Steve M. Robbins]

On Sun, Apr 29, 2018 at 01:36:08PM +0200, David Kalnischkies wrote:

> Not really knowledgeable enough about cmake through to know if that is
> the best we can do ??? it looks kinda ugly/dirty.

Your patch looks fine to me.  A slight improvement below avoids
repeating the /usr/src path.

 
> We could also switch to using the prebuilt library in libgtest-dev; it
> is happily picked up if available (which is why I didn't notice before).
> Not sure how the version constraints need to look to deal sanely with
> the constant name-changing of gtests packaging through???

Yeah, sorry about that.  If you are concerned with building in, say,
stable then be aware that the prebuilt library does not exist in
stable.  So using the sources would be a better option.


Here's a revised patch.

diff -u -r apt-1.6.1/test/libapt/CMakeLists.txt 
apt-fix/test/libapt/CMakeLists.txt
--- apt-1.6.1/test/libapt/CMakeLists.txt2018-04-20 05:08:18.0 
-0500
+++ apt-fix/test/libapt/CMakeLists.txt  2018-05-01 19:23:40.251529593 -0500
@@ -16,7 +16,7 @@
set(GTEST_LIBRARIES "-lgtest")
set(GTEST_DEPENDENCIES "gtest")
set(GTEST_FOUND TRUE)
-   find_path(GTEST_INCLUDE_DIRS NAMES gtest/gtest.h)
+   find_path(GTEST_INCLUDE_DIRS NAMES gtest/gtest.h PATHS 
${GTEST_ROOT}/include)
 
message(STATUS "Found GTest at ${GTEST_ROOT}, headers at 
${GTEST_INCLUDE_DIRS}")
 endif()


-Steve


signature.asc
Description: PGP signature

Bug#897176: Package erroneously expects googletest headers in /usr/include

[Steve M. Robbins]

Package: src:cctz
Severity: serious
Justification: fails to build from source (but built successfully in the past)

control: block 897104 by -1

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

Your package relies on this behaviour and now fails to build since
googletest version 1.8.0-9 no longer installs the duplicate header
files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve

Bug#897175: Package erroneously expects googletest headers in /usr/include

[Steve M. Robbins]

Package: src:fmtlib
Severity: serious
Justification: fails to build from source (but built successfully in the past)

control: block 897104 by -1

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

Your package relies on this behaviour and now fails to build since
googletest version 1.8.0-9 no longer installs the duplicate header
files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve

Bug#897174: Package erroneously expects googletest headers in /usr/include

[Steve M. Robbins]

Package: src:meson
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

Your package relies on this behaviour and now fails to build since
googletest version 1.8.0-9 no longer installs the duplicate header
files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve

Bug#897171: Package erroneously expects googletest headers in /usr/include

[Steve M. Robbins]

Package: src:synergy
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

Your package relies on this behaviour and now fails to build since
googletest version 1.8.0-9 no longer installs the duplicate header
files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve

Bug#897173: Package erroneously expects googletest headers in /usr/include

[Steve M. Robbins]

Package: src:aff4
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

Your package relies on this behaviour and now fails to build since
googletest version 1.8.0-9 no longer installs the duplicate header
files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve

Bug#897104: googletest: breakage due to files moved to other packages

[Steve M. Robbins]

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

All the listed packages rely on this behaviour and now fail to build
since googletest version 1.8.0-9 no longer installs the duplicate
header files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve


signature.asc
Description: PGP signature

Bug#897152: x

[Steve M. Robbins]

Package: src:flightcrew
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Subject: Package erroneously expects googletest headers in /usr/include
Package: apt
Version: 1.6.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)
control: block 897104 by -1

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

Your package relies on this behaviour and now fails to build since
googletest version 1.8.0-9 no longer installs the duplicate header
files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve

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

Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#897151: Package erroneously expects googletest headers in /usr/include

[Steve M. Robbins]

Package: src:protobuf
Severity: serious
Justification: fails to build from source (but built successfully in the past)

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

Your package relies on this behaviour and now fails to build since
googletest version 1.8.0-9 no longer installs the duplicate header
files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve

Bug#897149: Package erroneously expects googletest headers in /usr/include

[Steve M. Robbins]

Package: apt
Version: 1.6.1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

control: block 897104 by -1

Hi,

The googletest package provides full sources -- including header files
-- in /usr/src/googletest.  Prior to version 1.8.0-9, a second copy of
the headers was mistakenly installed into /usr/include.

Your package relies on this behaviour and now fails to build since
googletest version 1.8.0-9 no longer installs the duplicate header
files.

I can suggest three alternative approaches to fix this.

1. Modify the build to look for headers in /usr/src/googletest.

2. Change to using pre-build libraries, in which case you would switch
build-dependencies to libgtest-dev and libgmock-dev rather than using
googletest.

3. Add build-dependency on libgtest-dev to ensure the headers are
located in /usr/include as before.  If gmock is used, then add a
dependency on libgmock-dev as well.


-Steve

Bug#895713: FTBFS with googletest 1.8.0-7

[Steve M. Robbins]

Source: ros-catkin
Version: 0.7.11-1
Severity: serious
Justification: fails to build from source

Debian's googletest package used to ship only sources, not a compiled
libgtest.  The ros-catkin package has a build-dep on libgtest-dev.
However: at build time libgtest is probed for, not found, and C++
tests are not built:

-- gtest not found, C++ tests can not be built. Please install the gtest 
headers globally in your system to enable gtests

https://buildd.debian.org/status/fetch.php?pkg=ros-catkin=all=0.7.11-1=1522532229=0


In libgtest-dev 1.8.0-7, a compiled libgtest was added.  Now the
ros-catkin fails while attempting to build tests:

-- Found gtest: gtests will be built
CMake Error at cmake/test/gtest.cmake:369 (add_library):
  add_library cannot create imported target "gtest" because another target
  with the same name already exists.
Call Stack (most recent call first):
  cmake/all.cmake:147 (include)
  CMakeLists.txt:8 (include)


Additionally, the flaw in gtest.cmake appears to be the cause of
ros-rospack build failure tracked in Bug #895708 -- contrary to what
was previously written in that bug -- as the ros-rospack build fails
at the same lines in the installed version of gtest.cmake:

-- Found gtest: gtests will be built
CMake Error at /usr/share/catkin/cmake/test/gtest.cmake:369 (add_library):
  add_library cannot create imported target "gtest" because another target
  with the same name already exists.
Call Stack (most recent call first):
  /usr/share/catkin/cmake/all.cmake:147 (include)
  /usr/share/catkin/cmake/catkinConfig.cmake:20 (include)
  CMakeLists.txt:4 (find_package)


I suspect that other ROS packages will be similarly affected.

-Steve




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

Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#895707: gumbo-parser: diff for NMU version 0.10.1+dfsg-2.2

[Steve M. Robbins]

Control: tags 895707 + patch
Control: tags 895707 + pending

Dear maintainer,

I've prepared an NMU for gumbo-parser (versioned as 0.10.1+dfsg-2.2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.
diff -Nru gumbo-parser-0.10.1+dfsg/debian/changelog gumbo-parser-0.10.1+dfsg/debian/changelog
--- gumbo-parser-0.10.1+dfsg/debian/changelog	2015-12-30 12:45:37.0 -0600
+++ gumbo-parser-0.10.1+dfsg/debian/changelog	2018-04-14 18:20:28.0 -0500
@@ -1,3 +1,10 @@
+gumbo-parser (0.10.1+dfsg-2.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Tweak 00-tests.patch to ignore system libgtest (Closes: #895707)
+
+ -- Steve M. Robbins <s...@debian.org>  Sat, 14 Apr 2018 18:20:28 -0500
+
 gumbo-parser (0.10.1+dfsg-2.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru gumbo-parser-0.10.1+dfsg/debian/patches/00-tests.patch gumbo-parser-0.10.1+dfsg/debian/patches/00-tests.patch
--- gumbo-parser-0.10.1+dfsg/debian/patches/00-tests.patch	2015-12-30 12:22:04.0 -0600
+++ gumbo-parser-0.10.1+dfsg/debian/patches/00-tests.patch	2018-04-14 15:52:03.0 -0500
@@ -3,11 +3,15 @@
 Forwarded: not-needed
 Last-Update: 2014-10-13
 
 a/Makefile.am
-+++ b/Makefile.am
-@@ -9,31 +9,17 @@
+--- gumbo-parser-0.10.1+dfsg.orig/Makefile.am
 gumbo-parser-0.10.1+dfsg/Makefile.am
+@@ -7,35 +7,17 @@
  
- if !HAVE_SHARED_LIBGTEST
+ ACLOCAL_AMFLAGS = -I m4
+ 
+-if !HAVE_SHARED_LIBGTEST
++# Using Debian's libgtest-dev for tests
++GTEST_DIR = /usr/src/gtest
  
 -# Build gtest before we build protobuf tests.  We don't add gtest to SUBDIRS
 -# because then "make check" would also build and run all of gtest's own tests,
@@ -34,9 +38,6 @@
 -		echo "Making clean in gtest"; \
 -		cd gtest && $(MAKE) $(AM_MAKEFLAGS) clean; \
 -	fi
-+# Using Debian's libgtest-dev for tests
-+GTEST_DIR = /usr/src/gtest
-+
 +tests/gtest-all.o:
 +	$(CXX) $(CPPFLAGS) -I$(GTEST_DIR) $(CXXFLAGS) -c \
 +$(GTEST_DIR)/src/gtest-all.cc -o tests/gtest-all.o
@@ -44,19 +45,25 @@
 +tests/gtest_main.o:
 +	$(CXX) $(CPPFLAGS) -I$(GTEST_DIR) $(CXXFLAGS) -c \
 +$(GTEST_DIR)/src/gtest_main.cc -o tests/gtest_main.o
-+
  
- endif !HAVE_SHARED_LIBGTEST
+-endif !HAVE_SHARED_LIBGTEST
+ 
+ gentags: src/tag.in
+ 	@python gentags.py $<
+@@ -97,13 +79,9 @@
+ gumbo_test_DEPENDENCIES = libgumbo.la
+ gumbo_test_LDADD = libgumbo.la
  
-@@ -101,8 +87,9 @@
- # FIXME(bnoordhuis) Should be configurable by the user.
- gumbo_test_LDADD += -lgtest -lgtest_main
- else
+-if HAVE_SHARED_LIBGTEST
+-# FIXME(bnoordhuis) Should be configurable by the user.
+-gumbo_test_LDADD += -lgtest -lgtest_main
+-else
 -gumbo_test_DEPENDENCIES += check-local
 -gumbo_test_LDADD += gtest/lib/libgtest.la gtest/lib/libgtest_main.la
+-endif
 +gumbo_test_DEPENDENCIES += tests/gtest-all.o tests/gtest_main.o
 +gumbo_test_LDADD += tests/gtest-all.o tests/gtest_main.o
 +gumbo_test_LDFLAGS = -pthread
- endif
  
  noinst_PROGRAMS = clean_text find_links get_title positions_of_class benchmark serialize prettyprint
+ LDADD = libgumbo.la


signature.asc
Description: PGP signature

Bug#893884: [pkg-boost-devel] Bug#893884: libboost-locale1.62.0: LC_CTYPE overrides value of LC_ALL

[Steve M. Robbins]

On Fri, Mar 23, 2018 at 03:52:38PM +0100, Nicolas Dandrimont wrote:

> I've looked at the upstream history, but this source file has been imported
> as-is in SVN 7 years ago and hasn't been touched since, therefore I couldn't
> find the upstream rationale for this resolution order.

Did you ask upstream?  Or file a report in the upstream bug tracker?

Thanks,
-Steve



signature.asc
Description: PGP signature

Bug#886585: Suggests / Recommends two non-existent packages: python-scitools and python-mshr

[Steve M. Robbins]

Package: fenics
Version: 1:2017.1.0.1
Severity: minor

Hi,

I tried to install the Suggested and Recommended packages, but found two are 
non-existent.

python-scitools: appears to have existed at one time, but now removed from 
Debian; see 
https://packages.qa.debian.org/s/scitools/news/20160506T061253Z.html  This 
Recommends should probably be removed (?).

python-mshr: I guess this is the binary package of src:mshr that is stalled due 
to using embedded, modified copy of CGAL; c.f. 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824716  


-Steve


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

Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fenics depends on:
ii  dolfin-bin  2017.1.0-4
ii  dolfin-doc  2017.1.0-4
ii  libdolfin-dev   2017.1.0-4+b4
ii  python-dijitso  2017.1.0-3
ii  python-dolfin   2017.1.0-4+b4
ii  python-ffc  2017.1.0-2
ii  python-fiat 2017.1.0-2
ii  python-instant  2017.1.0-2
ii  python-ufl  2017.1.0-2
ii  python-ufl-doc  2017.1.0-2

Versions of packages fenics recommends:
pn  python-scitools  

Versions of packages fenics suggests:
pn  python-mshr  

-- no debconf information

Bug#886210: Downgrade "old-standards-version" to an info

[Steve M. Robbins]

Package: lintian
Version: 2.5.66
Severity: normal

I agree with suggestion by Niels Thykier (on debian-devel):

Andrey Rahmatullin:
> On Mon, Jan 01, 2018 at 05:26:35PM +, Sean Whitton wrote:
>> IMO the point of the field is to ensure that you /don't/ have to upgrade
>> to the latest version of Policy right away.  It allows you to keep track
>> of the version of Policy you are up-to-date with, so you can do it
>> later/someone more interested in the changes can do it.
>>
>> I think that Lintian shouldn't warn about not using the latest
>> Standards-Version; perhaps it should warn when you're using a really old
>> one.

This would just be a question of turning down the warning for
"old-standards-version" to an info.  We have a separate warning
(ancient-standards-version) that triggers when your S-V is (currently) 2
years behind.

IOW, trivially doable in lintian, please file a bug if you want this.


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

Kernel: Linux 4.14.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils  2.29.1-12
ii  bzip2 1.0.6-8.1
ii  diffstat  1.61-1+b1
ii  dpkg  1.19.0.4
ii  file  1:5.32-1
ii  gettext   0.19.8.1-4
ii  intltool-debian   0.35.0+20060710.4
ii  libapt-pkg-perl   0.1.33
ii  libarchive-zip-perl   1.60-1
ii  libclass-accessor-perl0.51-1
ii  libclone-perl 0.39-1
ii  libdpkg-perl  1.19.0.4
ii  libemail-valid-perl   1.202-1
ii  libfile-basedir-perl  0.07-1
ii  libipc-run-perl   0.96-1
ii  liblist-moreutils-perl0.416-1+b3
ii  libparse-debianchangelog-perl 1.2.0-12
ii  libperl5.24 [libdigest-sha-perl]  5.24.1-7
ii  libperl5.26 [libdigest-sha-perl]  5.26.1-3
ii  libtext-levenshtein-perl  0.13-1
ii  libtimedate-perl  2.3000-2
ii  liburi-perl   1.72-2
ii  libxml-simple-perl2.24-1
ii  libyaml-libyaml-perl  0.63-2+b2
ii  man-db2.7.6.1-4
ii  patchutils0.3.4-2
ii  perl  5.26.1-3
ii  t1utils   1.41-2
ii  xz-utils  5.2.2-1.3

Versions of packages lintian recommends:
ii  libperlio-gzip-perl  0.19-1+b4

Versions of packages lintian suggests:
pn  binutils-multiarch 
ii  dpkg-dev   1.19.0.4
ii  libhtml-parser-perl3.72-3+b2
ii  libtext-template-perl  1.47-1

-- no debconf information

Bug#881688: nmu: berkeley-express_1.5.1-3

[Steve M. Robbins]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: binnmu

nmu berkeley-express_1.5.1-3 . ANY . unstable . -m "Rebuild with current Boost 
libraries"

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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#844268: [pkg-boost-devel] Bug#844268: libboost1.62-doc doesn't contain the actual documentation

[Steve M. Robbins]

On Tue, Oct 24, 2017 at 02:04:44PM +0100, Dimitri John Ledkov wrote:
> On 24 October 2017 at 04:00, Steve M. Robbins <st...@sumost.ca> wrote:


> > If I re-enable the doc packages and build, lintian spews dozens of
> > errors of three kinds: privacy-breach-logo, privacy-breach-generic,
> > privacy-breach-uses-embedded-file.
> >
> > E: libboost1.65-doc: privacy-breach-logo 
> > usr/share/doc/libboost1.65-doc/HTML/doc/html/quickbook/syntax/block.html 
> > (http://sourceforge.net/sflogo.php?group_id=28447type=1)
> > W: libboost1.65-doc: privacy-breach-generic 
> > usr/share/doc/libboost1.65-doc/HTML/libs/assert/doc/html/assert.html 
> > (https://fonts.googleapis.com/css?family=open+sans:300,300italic,400,400italic,600,600italic%7cnoto+serif:400,400italic,700,700italic%7cdroid+sans+mono:400,700)
> > E: libboost1.65-doc: privacy-breach-uses-embedded-file 
> > usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/accessors_8hpp.html 
> > You may use the libjs-mathjax package. 
> > (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
> > E: libboost1.65-doc: privacy-breach-uses-embedded-file 
> > usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/adapt__adt_8hpp.html 
> > You may use the libjs-mathjax package. 
> > (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
> > E: libboost1.65-doc: privacy-breach-uses-embedded-file 
> > usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/adapt__struct_8hpp.html
> >  You may use the libjs-mathjax package. 
> > (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
> > E: libboost1.65-doc: privacy-breach-uses-embedded-file 
> > usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/adjust_8hpp.html You 
> > may use the libjs-mathjax package. 
> > (https://cdn.mathjax.org/mathjax/latest/mathjax.js)
> >
> >  etc.
> >
> 
> The google fonts in assert appear to be generated by calling asciidoc
> -> i wonder if debian's asciidoc can be made to not generate those
> and/or use local fonts?
> 
> For the mathjax, there appears to be support in Doxygen files to
> specify a url from libjs-mathjax package.
> 
> Let's see if we can fix up these docs to be offline, and also file
> issues as appropriate about things we cannot offline.

OK.  So the original approach -- the one that generated the big
lintian list -- is to simply use the files as they appear in the
source distribution.  To do what you suggest, I think we need to move
to a strategy that actually generates documentation during the package
build.  Will you look into setting that up?  The 1.65.1 is otherwise
ready to go, from my point of view.

Best,
-Steve


signature.asc
Description: PGP signature

Bug#844268: libboost1.62-doc doesn't contain the actual documentation

[Steve M. Robbins]

On Sun, Apr 23, 2017 at 11:55:15AM +0200, Klaus-J. Wolf wrote:
> Package: libboost1.62-doc
> Version: 1.62.0+dfsg-4
> Followup-For: Bug #844268
> 
> Dear Maintainer,
> 
> I have observed that the actual documentation is completely missing in
> this documentation package.  In duplicate bug report #850795 somebody
> explained that this has to do with Debian project's Javascript policy.
> I can only explain that I was incapable of finding any script elements
> in the original docs.

OK, it wasn't only javascript; also some basic HTML.

If I re-enable the doc packages and build, lintian spews dozens of
errors of three kinds: privacy-breach-logo, privacy-breach-generic,
privacy-breach-uses-embedded-file.

E: libboost1.65-doc: privacy-breach-logo 
usr/share/doc/libboost1.65-doc/HTML/doc/html/quickbook/syntax/block.html 
(http://sourceforge.net/sflogo.php?group_id=28447type=1)
W: libboost1.65-doc: privacy-breach-generic 
usr/share/doc/libboost1.65-doc/HTML/libs/assert/doc/html/assert.html 
(https://fonts.googleapis.com/css?family=open+sans:300,300italic,400,400italic,600,600italic%7cnoto+serif:400,400italic,700,700italic%7cdroid+sans+mono:400,700)
E: libboost1.65-doc: privacy-breach-uses-embedded-file 
usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/accessors_8hpp.html You 
may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: libboost1.65-doc: privacy-breach-uses-embedded-file 
usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/adapt__adt_8hpp.html You 
may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: libboost1.65-doc: privacy-breach-uses-embedded-file 
usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/adapt__struct_8hpp.html 
You may use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)
E: libboost1.65-doc: privacy-breach-uses-embedded-file 
usr/share/doc/libboost1.65-doc/HTML/libs/hana/doc/html/adjust_8hpp.html You may 
use the libjs-mathjax package. 
(https://cdn.mathjax.org/mathjax/latest/mathjax.js)

 etc.

-Steve


signature.asc
Description: PGP signature

Bug#873569: ITP: libmediawiki -- KDE C++ interface for MediaWiki based web service

[Steve M. Robbins]

Package: wnpp
Severity: wishlist
Owner: "Steve M. Robbins" <s...@debian.org>

* Package name: libmediawiki
  Upstream Author : Team maintained; see 
https://github.com/KDE/libmediawiki/blob/master/AUTHORS
* URL : https://cgit.kde.org/libmediawiki.git
* License : GPL 
  Programming Lang: C++
  Description : KDE C++ interface for MediaWiki based web service

This framework provides access to the API of MediaWiki 
(http://www.mediawiki.org)
based web services such as wikipedia (http://www.wikipedia.org).


This package is an optional dependency of DigiKam, needed to allow
photo export to a MediaWiki site.  Will maintain this within the
Debian KDE Extras Team.

Bug#727148: kino: diff for NMU version 1.3.4-2.3

[Steve M. Robbins]

Control: tags 727148 + patch
Control: tags 727148 + pending

Dear maintainer,

I've prepared an NMU for kino (versioned as 1.3.4-2.3) and
uploaded it.


Regards.
-Steve
diff -u kino-1.3.4/debian/changelog kino-1.3.4/debian/changelog
--- kino-1.3.4/debian/changelog
+++ kino-1.3.4/debian/changelog
@@ -1,3 +1,11 @@
+kino (1.3.4-2.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+
+  * Use distinct document names for doc-base (Closes: #727148).
+
+ -- Steve M. Robbins <s...@debian.org>  Tue, 15 Aug 2017 23:07:19 -0500
+
 kino (1.3.4-2.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -u kino-1.3.4/debian/kino.doc-base.en kino-1.3.4/debian/kino.doc-base.en
--- kino-1.3.4/debian/kino.doc-base.en
+++ kino-1.3.4/debian/kino.doc-base.en
@@ -1,4 +1,4 @@
-Document: kino-manual
+Document: kino-manual-en
 Title: Kino Manual
 Author: Arne Schirmacher, Dan Dannedy, Charlie Yates
 Section: Video
diff -u kino-1.3.4/debian/kino.doc-base.fr kino-1.3.4/debian/kino.doc-base.fr
--- kino-1.3.4/debian/kino.doc-base.fr
+++ kino-1.3.4/debian/kino.doc-base.fr
@@ -1,4 +1,4 @@
-Document: kino-manual
+Document: kino-manual-fr
 Title: Manuel de Kino 
 Author: Arne Schirmacher, Dan Dannedy, Charlie Yates
 Section: Video


signature.asc
Description: PGP signature

Bug#865447: Not suitable for release -- please keep out of testing

[Steve M. Robbins]

Source: boost1.61
Severity: grave

Package has been superceded by later Boost.  Should not be in testing.
In fact, was removed from testing earlier [1] but returned because I
did not file this bug soon enough.  Package is also marked for removal
from unstable [2].

-Steve
[1] https://packages.qa.debian.org/b/boost1.61/news/20170202T163914Z.html
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=865392

-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#865392: RM: boost1.61 -- ROM; Obsoleted by newer Boost

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal

Hi,

This package was removed from testing during a transition to boost1.62
[1] but was mistakenly re-introduced into testing recently.  Please
remove the package from the archive -- both unstable and testing.

[1] https://packages.qa.debian.org/b/boost1.61/news/20170202T163914Z.html

Thanks,
-Steve

Bug#857507: mesh generation module 'mshr' missing

[Steve M. Robbins]

Package: python-dolfin
Version: 2016.2.0-2
Severity: normal

The second tutorial script 'ft02_poisson_membrane.py' [1] fails to run because 
the
python module 'mshr' is missing:

$ python ft02_poisson_membrane.py 
Traceback (most recent call last):
  File "ft02_poisson_membrane.py", line 12, in 
from mshr import *
ImportError: No module named mshr
Aborted (core dumped)


The tutorial makes it sound like mshr is an expected part of the source 
distribution.


[1] 
https://github.com/hplgit/fenics-tutorial/blob/master/pub/python/vol1/ft02_poisson_membrane.py



-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-dolfin depends on:
ii  libc6 2.24-9
ii  libdolfin-dev 2016.2.0-2
ii  libdolfin2016.2   2016.2.0-2
ii  libgcc1   1:6.3.0-8
ii  libgomp1  6.3.0-8
ii  libopenmpi2   2.0.2-2
ii  libpetsc3.7.5 [libpetsc3.7]   3.7.5+dfsg1-4+b1
ii  libpython2.7  2.7.13-2
ii  libslepc3.7.3 [libslepc3.7]   3.7.3+dfsg1-5
ii  libstdc++66.3.0-8
ii  python2.7.13-2
ii  python-dijitso2016.2.0-1
ii  python-ffc2016.2.0-1
ii  python-instant2016.2.0-2
ii  python-numpy [python-numpy-abi9]  1:1.12.0-2
ii  python-petsc4py   3.7.0-2+b2
ii  python-ply3.9-1
ii  python-six1.10.0-4
ii  python-slepc4py   3.7.0-2+b4
ii  python-sympy  1.0-3
ii  python-ufl2016.2.0-2
pn  python:any
ii  swig3.0   3.0.10-1.1

python-dolfin recommends no packages.

Versions of packages python-dolfin suggests:
ii  dolfin-doc  2016.2.0-2

-- no debconf information

Bug#857491: Computation of top_dir is fooled by README

[Steve M. Robbins]

Package: python-sfepy
Version: 2016.2-2
Severity: normal

I tried to run the examples using:

  sfepy-run simple examples/diffusion/poisson_short_syntax.py

and obtained:

  sfepy: left over: ['verbose', '__builtins__', '__file__', '__doc__', 
'__name__', 'data_dir', '__package__', '_filename']
  sfepy: reading mesh [line2, tri3, quad4, tetra4, hexa8] 
(/usr/lib/python2.7/dist-packages/meshes/3d/cylinder.mesh)...

... which fails because the mesh path is wrong.  There needs to be a sfepy 
after dist-packages.


The root cause of this is the computation of "top_dir" in version.py:

# If installed, up_dir is '.', otherwise (in (git) source directory) '..'.
for up_dir in ['..', '.']:
top_dir = op.normpath(op.realpath(op.join(op.dirname(__file__),
  up_dir)))
aux = op.join(top_dir, 'README')
if op.isfile(aux):
break
else:
raise RuntimeError('cannot determine SfePy top level directory!')

The trouble is that ".." is tried first and there happens to be a README file
at that path: /usr/lib/python2.7/dist-packages/README !

There's an obvious Debian-only fix to remove '..' in version.py, which is
what I've done locally for now.




-- System Information:
Debian Release: 9.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages python-sfepy depends on:
ii  ipython   5.1.0-3
ii  libc6 2.24-9
ii  libsuitesparse-dev1:4.5.4-1
ii  mayavi2   4.5.0-1
ii  python2.7.13-2
ii  python-matplotlib 2.0.0+dfsg1-2
ii  python-numpy [python-numpy-abi9]  1:1.12.0-2
ii  python-pyparsing  2.1.10+dfsg1-1
ii  python-scipy  0.18.1-2
ii  python-sparse 1.1.1-1
ii  python-tables 3.3.0-5
pn  python:any

python-sfepy recommends no packages.

python-sfepy suggests no packages.

-- no debconf information

Bug#592834: Grub messages during upgrade

[Steve M]

Last couple of upgrades have seen similar results to the below:

Generating grub configuration file ...
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9473: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9473: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9486: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9486: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9499: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9499: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9512: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9512: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9572: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 9572: 
/usr/sbin/grub-probe
Found linux image: /boot/vmlinuz-4.4.0-66-generic
Found initrd image: /boot/initrd.img-4.4.0-66-generic
Found linux image: /boot/vmlinuz-4.4.0-65-generic
Found initrd image: /boot/initrd.img-4.4.0-65-generic
Found linux image: /boot/vmlinuz-4.4.0-64-generic
Found initrd image: /boot/initrd.img-4.4.0-64-generic
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 10044: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on vgs invocation. Parent PID 10044: 
/usr/sbin/grub-probe
File descriptor 3 (pipe:[53933]) leaked on lvs invocation. Parent PID 10213: 
/bin/sh
Failed to probe /dev/sdb1 for filesystem type
Failed to probe /dev/sdc1 for filesystem type
Failed to probe /dev/sdd1 for filesystem type
done
update-rc.d: warning: start and stop actions are no longer supported; falling 
back to defaults
Processing triggers for libc-bin (2.23-0ubuntu5) ...Processing triggers for 
initramfs-tools (0.122ubuntu8.8) ...
update-initramfs: Generating /boot/initrd.img-4.4.0-66-generic

Bug#737016: Bug#834131: Video support still not working

[Steve M. Robbins]

On Wednesday, December 21, 2016 1:30:39 PM CST Lisandro Damián Nicanor Pérez 
Meyer wrote:

> Well, the FRP was not done by a team member nor, as far as I know, anyone
> one the team is thinking in packaging it.
> 
> I'm CCing the RFP bug to see if he's still interested in packaging it. El se
> I would suggest you to consider packaging it yourself.

Having heard nothing, I will go ahead with packaging QtAV.  

I'd really rather do this as a team-maintained package.  Is this something 
that would be suitable for KDE Extras?  

Thanks,
-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#568897: [debhelper-devel] Bug#568897: Bug#568897: debhelper: DEB_BUILD_OPTIONS=nocheck should prevent override_dh_auto_test rule to be run

[Steve M. Robbins]

Peter,

You raise a lot of interesting questions about the general handling of 
DEB_BUILD_OPTIONS in the various tools.  I haven't got any real answer for the 
general question -- and, truthfully, your questions lead me to think it needs 
to be considered on a case-by-case basis -- so I'd like to close by bringing 
the discussion back to the narrow question of handling "nocheck".


On Tuesday, December 13, 2016 10:33:18 AM CST Peter Pentchev wrote:

> Um, no, not really, those were practically two different statements.  I was
> suggesting that somebody might write (or not have converted yet) a rules
> file that invokes dh_auto_test directly from within the "build" target, and
> then I gave '"build", "binary", etc' as an enumeration of examples of
> targets that somebody might invoke the dh_* commands directly from :)

I think it is fine if the debhelper author wants to keep the behaviour of 
dh_auto_test.  That is certainly the conservative approach.  *This* feature 
request is to ask that "nocheck" inhibit running tests whether they are (a) 
relying on the implicit dh_auto_test or (b) using rule override_dh_auto_test.  
In short: treat both approaches the same. 

-Steve




signature.asc
Description: This is a digitally signed message part.

Bug#568897: [debhelper-devel] Bug#568897: debhelper: DEB_BUILD_OPTIONS=nocheck should prevent override_dh_auto_test rule to be run

[Steve M. Robbins]

On Monday, December 12, 2016 10:57:20 AM CST Peter Pentchev wrote:
> On Sun, Dec 11, 2016 at 08:22:09PM -0600, Steve M. Robbins wrote:

> > Alternatively: if the logic was all in dh (to skip both dh_auto_test
> > and override_dh_auto_test), then it would not need to be in
> > dh_auto_test at all.
> 
> It may still need to be in dh_auto_test for packages that still do not
> use the override targets at all, but invoke the dh_* commands explicitly
> from the "build", "binary", etc targets.  None of mine do, but I bet that
> there are still some in the archive :)

You're suggesting someone would use dh_auto_test from within a binary target?   
Interesting use case.   

My feeling is that DEB_BUILD_OPTIONS represent global build options, so I 
think I'd design it into dh rather than individual tools.  You're right that 
it would be a breaking change, but I think one could use a debhelper 
compatibility level to remove the functionality from the tools.  

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#568897: debhelper: DEB_BUILD_OPTIONS=nocheck should prevent override_dh_auto_test rule to be run

[Steve M. Robbins]

I, too, think this would be a valuable addition.


On Tue, Feb 09, 2010 at 02:38:34PM -0500, Joey Hess wrote:

> If I did this, I would need to also make override_dh_strip to be
> skipped when DEB_BUILD_OPTIONS=nostrip.

Yes, would also be nice.


> One reason to dislike this is it would mean redundant tests in
> dh that'd have to be maintained in parallel with the tests in the
> commands.

Agree that it would take work to implement, though I would think that
the tests could be centralized and used by both dh and dh_auto_test.
Alternatively: if the logic was all in dh (to skip both dh_auto_test
and override_dh_auto_test), then it would not need to be in
dh_auto_test at all.


> Perhaps a better reason to dislike this is that it violates least
> suprise when rules file refactoring. One can move anything into an
> override target, even if it does not really match the overridden
> debhelper command, and expect it to be run at the appropriate point.
> 
> Here's an example that would cause the package to FTBFS if nocheck
> were tested.
> 
> override_dh_auto_test:
>   # the test suite does not 100% pass at present,
>   # but the output is useful documentation for users
>   (dh_auto_test; echo $?) > test-results
> 
> override_dh_install:
>   dh_install test-results /usr/share/doc/alien/

One could also argue that THIS EXAMPLE violates the principle of least
surprise -- in two ways.  First, from the builder's point of view: I
might set "nocheck" (say, for resource constraint considerations) but
have the checks run anyway.  Secondly, from a short-on-time debian
maintainer's [1] point of view: I might initially use the default
dh_auto_test, but then find I need to do something a bit special and
write the override -- and be surprised that I've unwittingly broken
the "nocheck" feature.

Perhaps unsurprisingly, I believe my examples are more common than
Joey's :-), so I second the original feature request.

-Steve

[1] This just happened to me, which is why I'm writing to support this
feature request.


signature.asc
Description: PGP signature

Bug#846464: apt: Please drop B-D on googletest on unsupported architectures

[Steve M. Robbins]

Control: retitle -1 gtest-port_test fails on m68k

On Friday, December 9, 2016 12:40:59 PM CST David Kalnischkies wrote:
> On Wed, Dec 07, 2016 at 11:28:09PM -0600, Steve M. Robbins wrote:

> Given that this is proven to be false by now I think we can all move on
> more or less pretending it never happened – so from my PoV feel free to
> close the bugreport or take it as m68k port-bug. I think John is
> actually involved in m68k porting, so he might be able to lend a hand!

Agree: I'll leave it open as an m68k port bug.  
What is your opinion as to bug severity?

> More than I can at least as I can only provide a pad on the back and
> a "that sounds strange indeed". Although, exceptions are a tricky beast
> and "costly", so I see why a compiler would like to optimize them out if
> given the chance… but that is not really helping.  Does upstream know
> about it? Also, Debian isn't the only distro with ports – we might
> 'only' be the ones with the most – so in theory others should see such
> issues, too.

To clarify: the exception test failure happens on amd64, so it should be 
visible in essentially any other distribution.  Dmitri did report it upstream 
[1] but there has been no response.  My googling for 
"gtest_catch_exceptions_test failure" only turned up the Debian discussions.  
This is what makes me suspect something about the Debian tool chain.   
 
-Steve

[1] https://github.com/google/googletest/issues/845


signature.asc
Description: This is a digitally signed message part.

Bug#846464: apt: Please drop B-D on googletest on unsupported architectures

[Steve M. Robbins]

Hi,

Executive summary: the build failures are mostly solved -- save for one test 
failure on m68k.

On Thursday, December 1, 2016 1:16:43 PM CST David Kalnischkies wrote:

> So @googletest maintainers, please state what you can/want to do about
> it or not.  Being a build-dependency of apt provides some benefits, 

... such as ?  :-)


> also carries a cost in that there basically is no distinction between
> release, non-release and unofficial port architectures.  If you
> can't/won't pay that price that is fine, we (as in deity@l.d.o) just
> need to know and we will figure something out – I just want to ask first
> before we rush into evaluating and moving to other testing frameworks,
> which is time better spent on other bugs if we can help it…

OK, so the root cause of the issues was that one of the tests in googletest's 
own test suite was failing when I first built it.  The failure went away if I 
built without optimization, so that is what I did for the first 3 uploads (the 
build is ONLY used for the test suite, so I figured lack of optimization is 
acceptable).  I don't know whether this failure (gtest_catch_exceptions_test) 
is a bug in GoogleTest or in Debian's toolchain as no-one else seems to be 
reporting it.  

Anyway, for some reason, building with no optimization caused failures in many 
architectures -- typically overflowing a symbol table; c.f. #845274.   It was 
surprising to me that optimiziation would affect the number of symbols 
produced.  In any case, rev 3 fixed that issue but inadvertently caused a 
different set of problems because setting CXXFLAGS disables the dpkg hardening 
flags.  Rev 4 fixes that, re-enables optimization, but drops the failing test.  
There are two architectures left to hear from, but -- apart from m68k -- all 
others have successfully built now.

I do intend to look into the m68k failure, but would really appreciate some 
help with it.  And with the failure of gtest_catch_exceptions_test -- which 
I'd prefer to reinstate once fixed.

I'm not certain what the original question was, but maybe the above helps.  If 
not, please elaborate.

Best,
-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#846254: compile error with gcc-6

[Steve M. Robbins]

On Tue, Nov 29, 2016 at 04:32:21PM +0100, Thorsten Alteholz wrote:

> building the alljoyn packages (alljoyn-core-1504, alljoyn-core-1509,
> alljoyn-core-1604) with googletest and gcc-6 gives the following compile
> error. I guess the "#include " jusst needs to be replaced by
> "#include " for gcc-6 now.

FWIW: I found a smaller minimal test case:

  g++ -c -D_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC -I/usr/src/gtest 
-I/usr/src/gtest/include /usr/src/gtest/src/gtest-all.cc

Removing -D_GLIBCXX_USE_C99_FP_MACROS_DYNAMIC makes the compile problem go away.

I can't find any docs on that macro so I'm not sure whether its use is 
legitimate.  On the other hand,
I imagine using  should also be fine so I'll make that change.

-Steve


signature.asc
Description: PGP signature

Bug#845721: Cannot install libc6:i386 -- Breaks: libc6:i386 (!= 2.24-7) but -7 does not exist

[Steve M. Robbins]

Thanks Adam + Aurelien,

On Saturday, November 26, 2016 3:11:21 PM CST Aurelien Jarno wrote:
> On 2016-11-26 11:02, Adam D. Barratt wrote:
> > On Sat, 2016-11-26 at 01:02 -0600, Steve M. Robbins wrote:

> > > I don't know how to make sense of these "breaks" versions.  libc6
> > > doesn't even have a revision -7.  Should both of those be
> > > "breaks ... != 2.24-6"?
> > 
> > -7 was uploaded a little over 10 hours ago. Looking at the dak log that
> > would make sense in terms of what you're seeing - the amd64 build of -7
> > made it into the 0152UTC dinstall by a few minutes, so would have been
> > available on mirrors when you filed this report, with the i386 build
> > being part of the subsequent 0752 dinstall.

Seems I was a victim of timing!   I checked the PTS when filing the bug and 
there was no trace of -7 that I could see.  All is well now.  

Thanks again,
-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#845721: Cannot install libc6:i386 -- Breaks: libc6:i386 (!= 2.24-7) but -7 does not exist

[Steve M. Robbins]

Package: libc6
Version: 2.24-7
Severity: normal

Tried to install libc6:i386 but cannot.

$ sudo apt-get install libc6:i386
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 cli-common : Depends: perl but it is not going to be installed
 libc6 : Breaks: libc6:i386 (!= 2.24-7) but 2.24-5 is to be installed
 libc6:i386 : Breaks: libc6 (!= 2.24-5) but 2.24-7 is to be installed
[...]

I don't know how to make sense of these "breaks" versions.  libc6
doesn't even have a revision -7.  Should both of those be
"breaks ... != 2.24-6"?

-Steve


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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libc6 depends on:
ii  libgcc1  1:6.2.1-5

libc6 recommends no packages.

Versions of packages libc6 suggests:
ii  cdebconf [debconf-2.0]  0.219
ii  debconf [debconf-2.0]   1.5.59
ii  glibc-doc   2.24-7
ii  libc-l10n   2.24-7
ii  locales 2.24-7

-- debconf information:
* glibc/disable-screensaver:
  glibc/kernel-too-old:
* glibc/upgrade: true
* glibc/restart-services: spamassassin samba openbsd-inetd exim4 cron atd 
apache2
  glibc/kernel-not-supported:
  glibc/restart-failed:
* libraries/restart-without-asking: true

Bug#845717: RM: gtest -- ROM; Superceded by source package googletest

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal

The binaries produced by source package gtest are now produced by
source package googletest.  So the former is obsolete and can be
removed.

Thanks,
-Steve

Bug#844721: libgtest-dev isn't replacing dir with symlink on upgrade

[Steve M. Robbins]

On Sunday, November 20, 2016 1:13:32 PM CST David Kalnischkies wrote:
> On Sat, Nov 19, 2016 at 10:06:17PM -0600, Steve M. Robbins wrote:
> > On Fri, Nov 18, 2016 at 01:29:07PM +0100, David Kalnischkies wrote:
> > > You should also update your README.Debian and the descriptions with the
> > > new paths and the transitional package as [...]
> > 
> > Thanks.  Updated README.Debian.  Not sure what you mean about the
> > descriptions -- there is nothing in the control file about the
> > paths. (?)
> 
> I was refering to saying in the description of libgtest-dev perhaps
> something to the effect that it is a (mostly) empty transitional
> package.

Ah, right.  Good idea.

Thanks
-Steve



signature.asc
Description: This is a digitally signed message part.

Bug#792163: Reviewing kipi-plugins dependencies

[Steve M. Robbins]

On Wednesday, November 16, 2016 9:11:56 AM CST you wrote:
> On 16/11/16 06:49, Steve M. Robbins wrote:
> > On Tuesday, November 15, 2016 2:05:27 PM CST Simon Frei wrote:
> >> I second this request. Please make konqueror a suggested package instead
> >> of a recommended. Digikam is aiming to be a cross-platform/-DE
> >> applications, especially since version 5 where many parts have been
> >> ported to QT from KDE framework.
> > 
> > I agree in principle.  Before making the change, I want to check the code
> > to see whether or not anything actually calls konqueror.
> > 
> > -Steve
> 
> I just had a quick grep look and the only place "konqueror" shows up as
> a string is in flashexport and remotestorage. In both cases there is no
> explicit call to konqueror, only calls to QDesktopServices::openUrl or
> KRun::runUrl (or konqueror is just used as an example in a UI string).
> So removing konqueror shouldn't be a problem.

Great, thanks for checking!
-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#829645: src:gtest: Cannot build against libgtest-dev with std=c++11

[Steve M. Robbins]

Hi,

On Mon, Jul 04, 2016 at 05:51:20PM -0700, Afif Elghraoui wrote:
> Package: src:gtest
> Version: 1.7.0-4
> Severity: important

The googletest package has recently been updated to 1.8.0
and built with gcc 6.  So I expect this issue is gone, but
I'd like you to test it and let me know because I can't
easily reproduce it even with version 1.7.0-4.

> I'm trying to enable tests for the pbbam package, but there is a
> compilation error that is triggered by simply including gtest.h:

I attempted to reproduce using the following file, but it succeeds
without error.

#include 

int main()
{
return 0;
}


> 
> Line 43 of my file /<>/tests/src/test_AlignmentPrinter.cpp has:
> 
> #include 

I am unable to compile tests/src/test_AlignmentPrinter.cpp; I get this
error:

g++ --std=c++11 -c tests/src/test_AlignmentPrinter.cpp 
tests/src/test_AlignmentPrinter.cpp:42:22: fatal error: TestData.h: No such 
file or directory
 #include "TestData.h"
  ^
compilation terminated.


Can you let me know if the new package fixes this bug?

Thanks!
-Steve


signature.asc
Description: PGP signature

Bug#844495: [pkg-boost-devel] Bug#844495: Bug#844490: FTBFS with boost1.62

[Steve M. Robbins]

On Wednesday, November 16, 2016 12:16:22 PM CST Thibaut Paumard wrote:
> Control: tags 844490 +pending
> Control: severity 844495 normal
> 
> For the record, the bug appears when doing:
> 
> acos(cos(alpha100)*cos(delta100));
> 
> where the type of alpha100 and delta100 is
> boost::multiprecision::cpp_dec_float_100.
> 
> I've realized that, when acos() does not return, delta100 above is
> always zero. I can simplify the case by simply doing
> acos(cos(alpha100))
> 
> in which case acos() also does not return. Does not look like a memory
> leak after all.
> 
> However, doing just that in an isolated main function does not exhibit
> the bug (I've also tried activating all the hardening features)

So when you say "doing just that" in isolated main ... do you mean
doing
acos(cos(alpha100)*cos(delta100)) 
or
acos(cos(alpha100))?

Did you succeed to find any small test case at all?  It would be good to have 
one and report it upstream.

Thanks,
-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#844721: libgtest-dev isn't replacing dir with symlink on upgrade

[Steve M. Robbins]

On Fri, Nov 18, 2016 at 01:29:07PM +0100, David Kalnischkies wrote:

> libgtest-dev contains in 1.8.0-1 a symlink to the new on-disk location.
> That works for new installs, but doesn't on upgrades ??? a user ends up
> with an empty /usr/src/gtest in that case.  You need to work with
> maintainerscripts here, see "man dpkg-maintscript-helper" and especially
> the section about dir_to_symlink for details on how and why.

I agree that upgrades should work and regret not testing that case.
Thank you very much for a very precise pointer to the fix!  Will
upload very soon.

> You should also update your README.Debian and the descriptions with the
> new paths and the transitional package as [...]

Thanks.  Updated README.Debian.  Not sure what you mean about the
descriptions -- there is nothing in the control file about the
paths. (?)


> btw: Upstream seems to have retired their remark on compiling googletest
> on your own as I can't find it any longer on their website and e.g. in
> the RPM/BSD worlds you get a binary only.

Hmm.  The code still has a lot of #if/#ifdef code in it including at
least one "#ifdef NDEBUG".  I haven't done an in-depth look, but I'd
think the advice about not distributing a compiled version would still
hold.

Best,
-Steve


signature.asc
Description: PGP signature

Bug#792163: Reviewing kipi-plugins dependencies

[Steve M. Robbins]

On Tuesday, November 15, 2016 2:05:27 PM CST Simon Frei wrote:
> I second this request. Please make konqueror a suggested package instead
> of a recommended. Digikam is aiming to be a cross-platform/-DE
> applications, especially since version 5 where many parts have been
> ported to QT from KDE framework.

I agree in principle.  Before making the change, I want to check the code to 
see whether or not anything actually calls konqueror.

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#844373: ros-image-common: FTBFS (incompatible build-dependencies)

[Steve M. Robbins]

On Tuesday, November 15, 2016 1:02:10 AM CST Santiago Vila wrote:
> Package: librospack-dev,libgtest-dev,src:ros-image-common
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build ros-image-common in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
> 
> 
>  [...]
> Unpacking librospack-dev (2.3.1-1+b1) ...
> dpkg: error processing archive
> /tmp/apt-dpkg-install-dJJuDK/111-librospack-dev_2.3.1-1+b1_amd64.deb
> (--unpack): trying to overwrite '/usr/include/gtest/gtest-death-test.h',
> which is also in package libgtest-dev:amd64 1.7.0-4 dpkg-deb: error:
> subprocess paste was killed by signal (Broken pipe)

I think it should be clear that /usr/include/gtest is owned by libgtest-dev, 
so I'll reassign the bug to librospack-dev.

Best case: librospack-dev can use Debian's libgtest-dev.  If not, then please 
place the files somewhere else.

> OTOH, if one of the packages librospack-dev or libgtest-dev should not
> contain the file, then please reassign to the package at fault and
> also send an "affects" command to the control address, so that we can
> still see that this bug affects src:ros-image-common in its BTS web page.
> 
> Sorry that I can't tell for sure which one of those cases is the truth,
> I just detected this problem by trying to build ros-image-common.
> 
> Thanks.



signature.asc
Description: This is a digitally signed message part.

Bug#841412: digikam: FTBFS: error with opencv 3.1

[Steve M. Robbins]

On Thu, Oct 20, 2016 at 07:13:38PM +0900, Nobuhiro Iwamatsu wrote:
> Source: digikam
> Version: 5.2.0-1
> Severity: important
> Justification: fails to build from source
> 
> Dear Maintainer,
> 
> I am scheduled to transition of opencv.
>https://release.debian.org/transitions/html/auto-opencv.html
> This package is target to transition. I tested build with opencv 3.1.
> As a result, FTBFS with opencv 3.1.

Digikam has configuration option ENABLE_OPENCV3, set OFF by default.
Should be a simple matter of flipping it ON.

-Steve


signature.asc
Description: PGP signature

Bug#774053: bug digikam

[Steve M. Robbins]

On Wed, Jul 06, 2016 at 08:38:14PM +0200, Luc Castermans wrote:
> I observe similar behaviour, also with CPU remaining at 100%. Below I used
> strace().   You can see
> I needed to kill the process to get rid of it.

Was this with Digikam version 4.4.0, as the original poster?

-Steve


signature.asc
Description: PGP signature

Bug#838152: kipi-plugins: Missing dependencies on KDE packages

[Steve M. Robbins]

On Sat, Sep 17, 2016 at 09:50:12PM +0200, Eike von Seggern wrote:

> after installing digikam with kipi-plugins on a non-KDE system, I cannot
> export files via 'Export->Export to remote storage'. On stderr, I get
> messages similar to:
>   "klauncher not running"
>   "no service file for klauncher"
>   "kinit not found in $PATH"
> 
> (I can try to reproduce the exact messages if necessary).
> 
> The problem looks similar to 801308 and
> http://askubuntu.com/questions/617955/problem-with-kde-programs-after-upgrading-to-15-04
> . Following the recommendations in the latter, I've installed
>  * kinit
>  * kio
>  * kio-extras
>  * kded5

So I tried to reproduce this issue with 5.2.0-3, but failed.  One difference 
from the
initial report is that installing digikam+kipi-plugins forced the install of 
kio.  I
did not have the other three you listed installed.  But in any case, the export 
worked.

Can you possibly try removing the four above and see if the problem recurs?

Thanks,
-Steve


signature.asc
Description: PGP signature

Bug#842112: digikam: Export menu does not open - workaround

[Steve M. Robbins]

On Thursday, November 10, 2016 8:20:12 PM CST you wrote:
> I had the same issue on my setup.
> Installing kipi-plugins package solved the problem for me.
> Shouldn't kipi-plugins be in dependencies of digikam package?

Thank you!   I un-installed kipi-plugins and now I can reproduce the problem.  

I agree that digikam should have a dependency; at least the Recommends level 
-- which is what "showfoto" has -- if not a full Depends.

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#842928: [pkg-boost-devel] Bug#842928: libboost-python1.62.0 exports Python 2 symbols for Python 3

[Steve M. Robbins]

On Wednesday, November 2, 2016 12:46:41 PM CDT Khoyo wrote:
> Package: libboost-python1.62.0
> 
> Version: 1.62.0+dfsg-2
> 
> This fails with libboost-python 1.62, but works with 1.61:
> 
>  % g++ -I/usr/include/python3.5m/ conftest.cc -lboost_python-py35
> -lpython3.5m /tmp/cc6JvhrE.o: In function `PyInit_empty':


Can you send "conftest.cc" -- or some other file -- so we can reproduce?

Thanks,
-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#834131: Video support still not working

[Steve M. Robbins]

Hi Martin & Simon,

In my testing yesterday, I found that before the "fix", NONE of my video
files played on digikam.  After I built with ENABLE_MEDIAPLAYER=ON, then
at least some of my videos played.  But not all of them.

I wanted to ask whether this matches your experience. 


On Tue, Nov 01, 2016 at 02:02:20PM +0100, Martin Steigerwald wrote:
> Am Dienstag, 1. November 2016, 13:34:32 CET schrieb Simon Frei:
> > I can confirm this problem. This is already reported and closed upstream
> > as a QTmultimedia issue:
> > https://bugs.kde.org/show_bug.cgi?id=366387
> > Installing the mentioned gstreamer1.0-plugins-bad does not help and I am
> > not aware of an issue reported to QT.

The videos that did NOT play for me did emit a message about GStreamer
plugins, as the KDE bug alludes to.  I do have "good", "bad", and
"ugly" plugins installed.  So I'm at a loss here.


> Hmmm, okay, seems this issue is unrelated to Digikam then.
> 
> Steve, would you like me to report a new bug against this? If so, against 
> which package, maybe libqt5multimedia5?

That sounds like the right one.

Thanks!
-Steve


signature.asc
Description: PGP signature

Bug#842112: digikam: Export menu does not open

[Steve M. Robbins]

Control: tags + moreinfo

On Wednesday, October 26, 2016 12:12:05 AM CDT you wrote:
> Package: digikam
> Version: 4:5.2.0-2
> Severity: normal
> 
> In the top menubar the Export dropbdown menu does not open. It gets selected
> as all the other menus, but nothing is shown. This also happens on a clean
> install (no configuration). This is also present in 5.1.0-1, but was not
> present in 5.1.0-2 and is not present when compiling digikam from source,
> so I assume (!) this is packaging related.

I'm not able to replicate this.  On the first attempt, I had to wait a bit 
because Digikam was busy scanning my photo folders.  But eventually it was 
responsive.  On subsequent executions, the Export menu popped up immediately.

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#841947: [pkg-boost-devel] Bug#841947: libboost-*1.61-dev: Please build static libs with -fPIC

[Steve M. Robbins]

My understanding is that you have to first build boost with the
pie-enabled compiler chain, then build your package with the new
boost.

c.f. https://wiki.ubuntu.com/SecurityTeam/PIE


Note that using -fPIC on static libs is against current Debian Policy.

-Steve


On Mon, Oct 24, 2016 at 08:19:13PM +0200, Gilles Filippini wrote:
> Source: boost1.61
> Version: 1.61.0+dfsg-3
> Severity: serious
> Justification: make other packages FTBFS
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Hi,
> 
> When rebuilding the psi4 package on amd6', it FTBFS with:
> 
> [100%] Linking CXX executable ../../../bin/psi4
> cd /<>/builddir/src/bin/psi4 && /usr/bin/cmake -E 
> cmake_link_script CMakeFiles/psi4.dir/link.txt --verbose=1
> /usr/bin/c++   -DRESTRICT=__restrict__ -Xlinker -export-dynamic -fPIC 
> -std=c++11 -fopenmp -O2 -g -DNDEBUG   
> CMakeFiles/psi4_objlib.dir/export_psio.cc.o 
> CMakeFiles/psi4_objlib.dir/export_mints.cc.o 
> CMakeFiles/psi4_objlib.dir/psi_stop.cc.o 
> CMakeFiles/psi4_objlib.dir/export_functional.cc.o 
> CMakeFiles/psi4_objlib.dir/export_oeprop.cc.o 
> CMakeFiles/psi4_objlib.dir/export_plugins.cc.o 
> CMakeFiles/psi4_objlib.dir/export_blas_lapack.cc.o 
> CMakeFiles/psi4_objlib.dir/export_benchmarks.cc.o 
> CMakeFiles/psi4_objlib.dir/export_efp.cc.o 
> CMakeFiles/psi4_objlib.dir/export_cubeprop.cc.o 
> CMakeFiles/psi4_objlib.dir/clean.cc.o 
> CMakeFiles/psi4_objlib.dir/create_new_plugin.cc.o 
> CMakeFiles/psi4_objlib.dir/script.cc.o 
> CMakeFiles/psi4_objlib.dir/set_memory.cc.o 
> CMakeFiles/psi4_objlib.dir/read_options.cc.o 
> CMakeFiles/psi4_objlib.dir/export_libparallel.cc.o 
> CMakeFiles/versioned_code.dir/version.cc.o 
> CMakeFiles/versioned_code.dir/python.cc.o 
> CMakeFiles/versioned_code.dir/psi_start.cc.o CMakeFiles/versioned_code.dir
>  /psi4.cc.o  -o ../../../bin/psi4 -rdynamic -lutil -lm -lrt -ldl -lpython2.7 
> -Wl,--whole-archive ../../../lib/libadc.a ../../../lib/libccdensity.a 
> ../../../lib/libccenergy.a ../../../lib/libcceom.a ../../../lib/libcchbar.a 
> ../../../lib/libcclambda.a ../../../lib/libccresponse.a 
> ../../../lib/libccsort.a ../../../lib/libcctransort.a 
> ../../../lib/libcctriples.a ../../../lib/libdcft.a ../../../lib/libdetci.a 
> ../../../lib/libdfmp2.a ../../../lib/libdfocc.a ../../../lib/libefp.a 
> ../../../lib/libfindif.a ../../../lib/libfisapt.a ../../../lib/libfnocc.a 
> ../../../lib/libmcscf.a ../../../lib/libmints_wrapper.a 
> ../../../lib/libmrcc.a ../../../lib/libocc.a ../../../lib/liboptking.a 
> ../../../lib/libpsimrcc.a ../../../lib/libsapt.a ../../../lib/libscf.a 
> ../../../lib/libscfgrad.a ../../../lib/libthermo.a ../../../lib/libtransqt2.a 
> ../../../lib/libdmrg.a ../../../lib/lib3index.a ../../../lib/libciomr.a 
> ../../../lib/libdiis.a ../../../lib/libdisp.a ../../../lib/libdpd.a 
> ../../../lib/libefp_solver.a .
>  ./../../lib/libfock.a ../../../lib/libfunctional.a -Wl,--whole-archive 
> ../../../lib/libiwl.a -Wl,--no-whole-archive ../../../lib/libmints.a 
> ../../../lib/libmoinfo.a ../../../lib/liboptions.a ../../../lib/libparallel.a 
> ../../../lib/libparallel2.a ../../../lib/libplugin.a 
> ../../../lib/libsapt_solver.a ../../../lib/libscf_solver.a 
> ../../../lib/libthce.a ../../../lib/libtrans.a ../../../lib/libpsi4util.a 
> ../../../lib/libpsio.a ../../../lib/libPsiUtil.a ../../../lib/libqt.a 
> ../../../lib/libcubeprop.a ../../../lib/libinterface_libefp.a 
> -Wl,--no-whole-archive -Wl,-Bstatic -lboost_filesystem -lboost_python 
> -lboost_regex -lboost_serialization -lboost_system -lboost_timer 
> -lboost_chrono -lboost_thread -lboost_date_time -lboost_atomic -Wl,-Bdynamic 
> -lpthread -llapack -lblas -lpython2.7 -lblas -llapack -lint -lderiv -lutil 
> -ldl -lrt -lm /usr/lib/x86_64-linux-gnu/libchemps2.so -lchemps2 
> /usr/lib/x86_64-linux-gnu/hdf5/serial/lib/libhdf5.so -lsz -lz -lpthread -lm 
> -lpython2.7 -ldl -Wl,-rpath,/usr/l
>  ib/x86_64-linux-gnu/hdf5/serial/lib 
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_filesystem.a(operations.o):
>  relocation R_X86_64_32S against symbol 
> `_ZN5boost6detail15sp_counted_base7destroyEv' can not be used when making a 
> shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_filesystem.a(path.o):
>  relocation R_X86_64_32 against `.rodata.str1.8' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_python.a(list.o):
>  relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_python.a(dict.o):
>  relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making 
> a shared object; recompile with -fPIC
> /usr/bin/ld: 
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../x86_64-linux-gnu/libboost_python.a(tuple.o):
>  relocation R_X86_64_32 

Bug#837490: libpapyrus3-dev: Please build libPapyrus3.a with -fPIC

[Steve M. Robbins]

On Mon, Sep 12, 2016 at 01:18:32AM +0200, Balint Reczey wrote:

> /usr/bin/ld:
> /usr/lib/gcc/x86_64-linux-gnu/6/../../../../lib/libPapyrus3.a(PapyError3.c.o):
> relocation
>  R_X86_64_32 against `.rodata.str1.8' can not be used when making a
> shared object; recompile with -fPIC
> ...

The Ubuntu notes [1] for this may apply:

Relocation Linking Failure

A dynamically linked program that pulls in a static library that was not 
built with -fPIC. These give an error like: 

relocation R_X86_64_32 against '[SYMBOL]' can not be used when
making a shared object; recompile with -fPIC To address these
types of issues, the package providing the static object needs
to be rebuilt (usually just a no-change rebuild against the
pie-by-default compiler) before rebuilding the failed package.

Did you try rebuilding libpapyrus3-dev and then using that to build gdcm?


[1] https://wiki.ubuntu.com/SecurityTeam/PIE

-Steve


signature.asc
Description: PGP signature

Bug#837490: libpapyrus3-dev: Please build libPapyrus3.a with -fPIC

[Steve M. Robbins]

On Mon, Sep 12, 2016 at 01:18:32AM +0200, Balint Reczey wrote:

> During a rebuild of all packages in sid, gdcm
> failed to build on amd64 with patched GCC and dpkg. The root
> cause seems to be that libPapyrus3.a is shipped as a non-PIC library.

That cannot be the root cause.  Debian Policy [1] is to build static
libs without -fPIC

 10.2 Libraries

 [...]  As to the static libraries, the common case is not to have
 relocatable code, since there is no benefit, unless in specific
 cases; therefore the static version must not be compiled with the
 -fPIC flag. Any exception to this rule should be discussed on the
 mailing list debian-de...@lists.debian.org, and the reasons for
 compiling with the -fPIC flag must be recorded in the file
 README.Debian.


[1] https://www.debian.org/doc/debian-policy/ch-files.html#s-libraries

-Steve


signature.asc
Description: PGP signature

Bug#841412: digikam: FTBFS: error with opencv 3.1

[Steve M. Robbins]

Hello Nobuhiro,


On Thursday, October 20, 2016 7:13:38 PM CDT you wrote:

> I am scheduled to transition of opencv.
>https://release.debian.org/transitions/html/auto-opencv.html
> This package is target to transition. I tested build with opencv 3.1.

Thanks for checking the build!  

In the log snippet, we see: 

> /usr/bin/cc  -g -O2 -fdebug-prefix-map=/build/digikam-5.2.0=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2  -std=iso9899:1990 -fno-common -Wall -Wextra
> -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long
> -Wpointer-arith -Wundef -Wmissing-format-attribute -Wwrite-strings
> -Werror=implicit-function-declaration -std=iso9899:1990 -fno-common
> -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security
> -Wno-long-long -Wpointer-arith -Wundef -Wmissing-format-attribute
> -Wwrite-strings -Werror=implicit-function-declaration
> -std=iso9899:1990 -fno-common -Wall -Wextra -Wcast-align
> -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith
> -Wundef -Wmissing-format-attribute -Wwrite-strings
> -Werror=implicit-function-declaration
> -DCHECK_FUNCTION_EXISTS=pthread_create   -Wl,-z,relro -Wl,--as-needed
> CMakeFiles/cmTC_280c4.dir/CheckFunctionExists.c.o  -o cmTC_280c4
> -rdynamic -lpthreads
> /usr/bin/ld: cannot find -lpthreads
> collect2: error: ld returned 1 exit status
> CMakeFiles/cmTC_280c4.dir/build.make:97: recipe for target 'cmTC_280c4'

The build -- seems like the configure step -- is attempting to link with "-
lpthreads".  This does not happen in previous successful builds [1].   In 
fact, the test build "CheckFunctionExists.c.o" does not appear in successful 
build logs.  Something is different in your environment.  

Or maybe with opencv 3.1.  I see you have uploaded to experimental; will try a 
build myself.

[1] https://buildd.debian.org/status/fetch.php?
pkg=digikam=amd64=4%3A5.2.0-1=1474888437

> failed make[3]: *** [cmTC_280c4] Error 1
> make[3]: Leaving directory
> '/build/digikam-5.2.0/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
> Makefile:126: recipe for target 'cmTC_280c4/fast' failed
> make[2]: *** [cmTC_280c4/fast] Error 2
> make[2]: Leaving directory
> '/build/digikam-5.2.0/obj-x86_64-linux-gnu/CMakeFiles/CMakeTmp'
> 
> 
> dh_auto_configure: cmake .. -DCMAKE_INSTALL_PREFIX=/usr
> -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=None
> -DCMAKE_INSTALL_SYSCONFDIR=/etc -DCMAKE_INSTALL_LOCALSTATEDIR=/var
> -DCMAKE_BUILD_TYPE=Debian -DCMAKE_INSTALL_RPATH=/usr/lib/digikam
> -DDIGIKAMSC_COMPILE_DOC=on -DDIGIKAMSC_COMPILE_PO=on
> -DENABLE_MYSQLSUPPORT=ON -DENABLE_INTERNALMYSQL=ON returned exit code
> 1
> debian/rules:22: recipe for target 'override_dh_auto_configure' failed
> make[1]: *** [override_dh_auto_configure] Error 255
> make[1]: Leaving directory '/build/digikam-5.2.0'
> debian/rules:15: recipe for target 'build' failed
> make: *** [build] Error 2
> dpkg-buildpackage: error: debian/rules build gave error exit status 2
> I: copying local configuration
> 
> --
> Could you check your package?
> 
> Best regards,
>   Nobuhiro



signature.asc
Description: This is a digitally signed message part.

Bug#840908: Uscan's Sourceforge reflector is too naive

[Steve M. Robbins]

On Sunday, October 16, 2016 11:48:32 AM CDT Paul Wise wrote:
> On Sun, Oct 16, 2016 at 10:24 AM, Steve M. Robbins wrote:
> > My suggestion is that the ones with "snapshots" in the path are simply
> > filtered out from list displayed by the reflector as these are not
> > release files.
> 
> That sounds like an ugly hack that I would rather not see implemented.

I can't disagree.  :-)  
If I knew how to fix it in the watch file, I would do so.


> The are two issues here:
> 
> The redirector was designed in the days when there were no directories
> on the sf.net files section.

I see.  One other thing I will mention is that the current reflector does
show two occurrences of "boost_1_62_0.tar.bz2".  (And just now it even shows 
the path and a "direct link" that I'm pretty sure weren't present earlier 
today!)  However, both occurrences link to the same reflector URL [1] that ends 
up at the wrong URL on sf.net.

[1] https://qa.debian.org/watch/sf.php/boost/boost_1_62_0.tar.bz2


> Your upstream isn't naming snapshot tarballs correctly. This should be
> fixed either in boost upstream 

I know this is the popular Debian perception and certainly it is a nuisance 
that the filenames are not unique.  All I will say is that the folks releasing 
Boost are not novices and likely have a defensible reason for their madness.  
More to the point: it is out there and if uscan can be made more flexible, it 
would be appreciated.

> or in the boost watch files. Modifying
> the boost watch file is dependent on the fix for the above issue.

OK.  Thanks for looking into this!

Best,
-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#840908: Uscan's Sourceforge reflector is too naive

[Steve M. Robbins]

Package: qa.debian.org
Severity: normal

The uscan download from sourceforge doesn't download what you expect
for boost.  The reason is that the link provided by the reflector page
[1] is incorrect: it leads to a "snapshot" url [2].  The correct
URL is [3].

Paul Wise indicated [4] that the reflector is a proxy for the RSS
feed and indeed both URLs are present:

  
https://sourceforge.net/projects/boost/files/boost/snapshots/master/boost_1_62_0.tar.bz2/download
  
https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.tar.bz2/download

My suggestion is that the ones with "snapshots" in the path are simply
filtered out from list displayed by the reflector as these are not
release files.


[1] https://qa.debian.org/watch/sf.php/boost/
[2] 
https://sourceforge.net/projects/boost/files/boost/snapshots/master/boost_1_62_0.tar.bz2/download
[3] 
https://sourceforge.net/projects/boost/files/boost/1.62.0/boost_1_62_0.tar.bz2/download
[4] https://lists.debian.org/debian-devel/2016/10/msg00292.html


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

Kernel: Linux 4.7.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Bug#840841: digikam: fails to upgrade from jessie to stretch: gets removed, not upgraded

[Steve M. Robbins]

Hello,

Thanks for the bug report. 

On Saturday, October 15, 2016 3:35:24 PM CDT you wrote:

> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.

The output you quoted doesn't indicate WHY it was to be removed.  Do you know?

> # ok, lets try to install it in stretch
> 5m45.0s DEBUG: Starting command: ['chroot', '/tmp/piupartss/tmp_SRqAA',
> 'apt-get', '-y', 'install', 'digikam'] 5m45.6s DUMP:
>   Reading package lists...
>   Building dependency tree...
>   Reading state information...
>   Some packages could not be installed. This may mean that you have
>   requested an impossible situation or if you are using the unstable
>   distribution that some required packages have not yet been created
>   or been moved out of Incoming.
>   The following information may help to resolve the situation:
> 
>   The following packages have unmet dependencies:
>digikam : Depends: digikam-private-libs (= 4:5.2.0-1) but it is not going
> to be installed E: Unable to correct problems, you have held broken
> packages.

I can assure you it is installable in sid.  What broken packages were being 
held?

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#840245: RM: boost1.58 -- ROM; Superceeded and no longer builds with GCC 6

[Steve M. Robbins]

Package: ftp.debian.org
Severity: normal


Thanks,
-Steve

Bug#838886: digikam: new upstream release (with patch)

[Steve M. Robbins]

On Monday, September 26, 2016 1:35:52 PM CDT you wrote:

> I attach the patch against the current svn, maybe it helps.

Yes, that's fantastic, thanks!  Just applied it to SVN.  Hope to have the 
debian upload done shortly.

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#838787: [pkg-boost-devel] Bug#838787: libboost1.61-doc doesn't contain the actual documentation

[Steve M. Robbins]

On Saturday, September 24, 2016 11:28:43 PM CDT Evgeny Kapun wrote:
> Package: libboost1.61-doc
> Version: 1.61.0+dfsg-2.1
> 
> The package libboost1.61-doc is supposed to include Boost documentation. It
> doesn't. 

Yes, unfortunately.  My best advice to you is use the online docs at http://
www.boost.org/doc/libs/1_61_0/

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#802587: at least, warn about absence of libgtest library package

[Steve M. Robbins]

On Sunday, September 18, 2016 10:51:16 AM CDT Ghislain Vaillant wrote:

>  > but it is in conflict with the well-established standard way
>  > of how libraries are distributed in Debian.
> 
> This is incorrect. Header-only libraries are present in the Debian
> archive, such as libboost-dev or libeigen3-dev. A -dev package does
> not automatically have an accompanying shlib package.

True.  But as Joachim later pointed out: -dev packages do typically provide a 
ready-to-use library -- whether it be header-only or accompanied (by 
dependency) with link libraries.

In fact, we did previously distribute a compiled Google Test -- until I came 
across the upstream recommendation to not do so.   So in the past, the name 
libgtest-dev was much more in keeping with traditional practices.  

In hindsight, I probably should have just changed the package name.  But at 
the very least it could be more clearly labelled.  I agree with that much and 
I do apologize for not acting on this bug report.


> This has nothing to do with libgtest-dev being deceptive, but with you
> failing to understand how modern integration of GTest with CMake is
> supposed to happen in accordance with upstream recommendations.

I don't think there's any need to call out perceived personal failings.

> Modern integration uses ExternalProject_Add to fetch the gtest source,
> [...]

I did not know about this technique, so I learned something.  Thanks!

Best,
-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#838150: ITP: itktools -- command line tools based on the ITK, intended for image processing

[Steve M. Robbins]

Package: wnpp
Severity: wishlist
Owner: "Steve M. Robbins" <s...@debian.org>

* Package name: itktools
  Version : 0.3.2
  Upstream Author : Marius Staring, Stefan Klein, David Doria
* URL : https://github.com/ITKTools/ITKTools
* License : Apache 2.0
  Programming Lang: C++
  Description : command line tools based on the ITK, intended for image 
processing

Practical command line tools based on the ITK, intended for image
processing. These tools are designed to take one or more input
image(s) from the command line, perform a single operation, and
produce an output image. For example smoothing of an image can be done
with the tool pxgaussianimagefilter.

Note: these tools (specifically pxcastconvert) are required to run the
Elastix test suite.

Bug#834175: digikam: please depend on the default version of boost

[Steve M. Robbins]

Hi,

I'll switch it back shortly.

On Friday, August 12, 2016 7:37:33 PM CDT Mattia Rizzolo wrote:

> for some reason you swapped your build-dependency on the metapackage
> libboost-graph-dev to the versioned libboost-graph1.60-dev.

Here's the story: I worked on digikam 5.0.0 a month ago, when the default 
boost was 1.58.   That didn't work, so I used 1.60 which, at the time, was the 
latest.  I forgot about this when I built 5.1.0.  

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#834118: Undeclared conflict with package pngtools

[Steve M. Robbins]

Package: libpng-tools
Version: 1.6.24-1
Severity: normal

Cannot co-install with pngtools:

Preparing to unpack .../libpng-tools_1.6.24-1_amd64.deb ...
Unpacking libpng-tools (1.6.24-1) over (1.6.23-1) ...
dpkg: error processing archive 
/var/cache/apt/archives/libpng-tools_1.6.24-1_amd64.deb (--unpack):
 trying to overwrite '/usr/bin/pngcp', which is also in package pngtools 0.4-1.3
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/libpng-tools_1.6.24-1_amd64.deb




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

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages libpng-tools depends on:
ii  libc62.23-4
iu  libpng16-16  1.6.24-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

libpng-tools recommends no packages.

libpng-tools suggests no packages.

-- no debconf information

Bug#803456: Digikam 5.0.0 uploaded

[Steve M. Robbins]

On Wednesday, August 3, 2016 10:59:30 PM CDT you wrote:
> Hi,
> 
> First a big thanks at Steve for packaging digikam!
> I proposed an information on the welcome page about the configuration
> transition. I hope this is included before 5.1.0:
> https://bugs.kde.org/show_bug.cgi?id=364258#c18

Thank you for that!  I see it was merged by Gilles.

> I will keep you posted. I would really like to see digikam5 in
> non-experimental debian repo soon!
> 
> On a side note: Is bug triaging on this package welcomed?

Yes, please!  And thank you!

-Steve


signature.asc
Description: This is a digitally signed message part.

Bug#833636: Re%3A compile error with gcc-6

[Steve M. Robbins]

Help me reproduce the problem.  I can't find "alljoyn" sources:

steve@riemann{NMU}apt source alljoyn
Reading package lists... Done
E: Unable to find a source package for alljoyn

-Steve


signature.asc
Description: This is a digitally signed message part.