Bug#1034310: [digikam] [Bug 466170] Digikam 7.9.0 (and 7.8.0) crashes on startup

[Steve Robbins]

I’ve just uploaded new version with upstream patch for the splash screen.  
Would love to know I how it works on your system. 

Sent from my iPhone

> On Apr 26, 2023, at 8:24 AM, Steve Robbins  wrote:
> 
> I understood that upstream fixed a splash screen bug from your traces.  I do 
> plan to look into applying that patch.  
> 
> But I thought that even after disabling the splash screen you were seeing a 
> second crash?  That is what I’m trying to figure out. 
> 
> Sent from my iPhone
> 
>>> On Apr 26, 2023, at 1:24 AM, Rainer Dorsch  wrote:
>>> 
>> 
>> Hi Steve,
>> 
>> Am Mittwoch, 26. April 2023, 05:49:03 CEST schrieben Sie:
>> > On Tuesday, April 25, 2023 12:50:39 P.M. CDT Rainer Dorsch wrote:
>> > > Am Dienstag, 25. April 2023, 03:51:44 CEST schrieben Sie:
>> > > > I'd be interested to know if the issue persists on your system after
>> > > > upgrading.
>> > >
>> > > Yes, it repros always.
>> >
>> > OK.
>> >
>> > > -- System Information:
>> > > Debian Release: 12.0
>> > >
>> > >   APT prefers testing-security
>> > >   APT policy: (500, 'testing-security'), (500, 'testing-debug'), (105,
>> > >
>> > > 'testing')
>> > > Architecture: amd64 (x86_64)
>> > > Foreign Architectures: i386
>> > >
>> > > Kernel: Linux 6.1.0-7-amd64 (SMP w/6 CPU threads; PREEMPT)
>> > > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
>> > > LANGUAGE=de:en_US
>> >
>> > I'm still not able to reproduce the issue.  Today I was trying with the 
>> > same
>> > locale as you (de_DE.UTF-8).   I have seen issues in the past with certain
>> > locales -- typically in software that isn't careful enough and gets into
>> > trouble when a locale switches the period and comma in number formats.
>> 
>> Be aware that upstream also was unable to repro the issue and finally they 
>> managed to understand and fix the problem by the traces I was able to 
>> generated.
>> 
>> > Even though I wasn't able to reproduce the problem here, it would be
>> > interesting if you can try with locale set to en_US for example:
>> 
>> There is no change if I unset LANG:
>> 
>> rd@h370:~/tmp.nobackup$ unset LANG
>> rd@h370:~/tmp.nobackup$ digikam
>> digikam.facedb: Cannot found faces engine model "shapepredictor.dat"
>> digikam.facedb: Faces recognition feature cannot be used!
>> digikam.facedb: Cannot found faces engine DNN model 
>> "openface_nn4.small2.v1.t7"
>> digikam.facedb: Faces recognition feature cannot be used!
>> kf.xmlgui: Unhandled container to remove :  Digikam::DigikamApp
>> ASSERT: "!isEmpty()" in file 
>> /usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h, line 363
>> 21 -- exe=/usr/bin/digikam
>> 13 -- platform=xcb
>> 11 -- display=:0
>> 16 -- appname=digikam
>> 17 -- apppath=/usr/bin
>> 9 -- signal=6
>> 11 -- pid=459194
>> 17 -- appversion=7.9.0
>> 20 -- programname=digiKam
>> 31 -- bugaddress=sub...@bugs.kde.org
>> KCrash: crashing... crashRecursionCounter = 2
>> KCrash: Application Name = digikam path = /usr/bin pid = 459194
>> KCrash: Arguments: /usr/bin/digikam
>> KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi
>> 
>> [1]+  Stopped digikam
>> rd@h370:~/tmp.nobackup$
>> 
>> > I have no idea where else to look.  Given that no-one else has reported
>> > this, I'm leaning towards downgrading the severity to keep digikam in the
>> > upcoming release.
>> 
>> That is certainly and option. For me as a user it would be helpful if you 
>> would highlight in the changelog that I get during the upgrade the 
>> information to disable the splash screen if they run into this issue.
>> 
>> Alternatively you could apply the bugfix
>> 
>> https://invent.kde.org/graphics/digikam/-/commit/28977ed2aac8a3575b979725e3141dd94b104833
>> 
>> to the Debian package. I can test if it fixes the problem for me.
>> 
>> Thanks
>> Rainer
>> 
>> --
>> Rainer Dorsch
>> http://bokomoko.de/

Bug#950731: FTBFS on ppc64el :

[Steve Robbins]

Thanks!   Do you know why only ppc64el fails?

On February 5, 2020 7:19:17 a.m. CST, "Frédéric Bonnard"  
wrote:
>Package: src:digikam
>Version: 4:6.4.0+dfsg-1
>Control: tags -1 ftbfs patch
>
>--
>
>Dear maintainer,
>latest 4:6.4.0+dfsg-1 fails to build on ppc64el here :
>https://buildd.debian.org/status/fetch.php?pkg=digikam=ppc64el=4%3A6.4.0%2Bdfsg-1=1580716901=0
>
>Opencv undefines vector, bool and pixel on purpose (
>https://en.wikipedia.org/wiki/AltiVec#Issues )
>
>I wrote a patch to fix this :
>https://salsa.debian.org/debian/digikam/merge_requests/1
>
>Regards,
>
>
>F.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#936740: Fixed in rev -3

[Steve Robbins]

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#803978: digikam: Digikam image editor frequently crashes on PgUp/PgDown

[Steve Robbins]

On Tuesday, November 3, 2015 2:09:22 PM CST you wrote:
> Package: digikam
> Version: 4:4.4.0-1.1
> Severity: normal
> 
> Dear Maintainer,
> 
> when switching between images using the PgUp/PgDown keys from within
> digikam's image editor, the application frequently crashes, seemingly at
> random. With "frequently" I mean someting like every 10th or so picture
> -- which is way too much when browsing through an album containing >
> 1000 photos. (Well, actually there are some images with which the crash
> seems to occur more often than with others, but there still seems to be
> a random process involved.)

I cannot reproduce this issue using Digikam 5.9.0.  I am using the following 
test steps:

1. start digikam 
2. in "Thumbnails" display, select 30 images
3. Click "Image Editor"
4. Rapidly switch using PageUp/PageDown

I observe no crashes.  Can you still reproduce?

-S

Bug#743824: digikam: Digikam no longer displays any album thumbnails

[Steve Robbins]

On Monday, April 16, 2018 6:28:01 AM CST you wrote:
> On 16/04/18 04:02, Michael Haag wrote:
> > On Mon, Apr 16, 2018, at 05:07, Simon Frei wrote:
> >> This is 99% a problem with qt >=5.9.3, which was fixed in 5.7.0:
> >> https://bugs.kde.org/show_bug.cgi?id=387373
> > 
> > So the bug has been reintroduced? I'm on Qt 5.10.1.
> 
> Ah I see the ambiguity in my statement: Problem exists with version
> 5.9.3 and newer of QT and 5.6.0 and older of digikam. So you (and debian
> testing) being on QT 5.10.1 and digikam 5.6.0 are affected. Now that
> Steve uploaded digikam 5.9.0 to unstable, this problem will soon
> disappear in testing too.

Dare I ask: did the problem disappear?
I am running 5.9.0 and cannot reproduce.

Thanks,
-Steve

Bug#759618: recheck the option

[Steve Robbins]

Hi,

The issue has returned with kmail (4:18.08.1-1).  Even though I have "Prefer 
HTML to plain text", messages all show up with the following text within a red 
box: 

Note: This HTML message may contain external references to images etc. For 
security/privacy reasons external references are not loaded. If you trust the 
sender of this message then you can load the external references for this 
message by clicking here.



On Mon, 15 Sep 2014 22:10:35 -0500 "Steve M. Robbins"  wrote:
> On Thu, Sep 11, 2014 at 04:48:21PM -0400, Brian DeRocher wrote:
> > I saw this too.  Unchecking and rechecking "Prefer HTML to plain text" 
seems to fix the issue.
> 
> Thanks for the tip!  For me, I had to:
> 
> 1. Uncheck "Prefer HTML to plain text"
> 2. Click "Apply"
> 3. Re-check "Prefer HTML to plain text"
> 4. Click "Apply"

This workaround no longer works.

-Steve
 

Bug#910237: Bug

[Steve Robbins]

On Monday, October 8, 2018 1:58:13 AM CDT Graham Inggs wrote:
> Hi Steve / Doug
> 
> On Mon, 8 Oct 2018 at 07:27, Steve Robbins  wrote:
> > This level seems a bit extreme, to me, considering the guidelines in
> > https:// www.debian.org/Bugs/Developer
> 
> Severity serious is correct.  From the RC policy document [1]:
> 
> Packages must autobuild without failure on all architectures on which
> they are supported.

Right, and googletest autobuilds while mathicgb does not.  So my reading is 
that this criteria applies to a bug in mathicgb, not googletest.

 
> > Moreover, it's not clear that the bug lies with googletest.
> 
> Yes, there is at least an RC bug in googletest or mathicgb, hence Paul
> wrote:
> On Wed, 3 Oct 2018 at 20:27, Paul Gevers  wrote:
> > Due to the nature of this issue, I filed
> > this bug report against both packages. Can you please investigate the
> > situation and reassign the bug to the right package?

Yes.  Clearly there is a change in the interface that mathicgb is using.  I 
can't tell whether the change to googletest was incidental or deliberate.  In 
the former case, there would be a bug in googletest.  However, it would not be 
serious in my reading of the criteria ("is a severe violation of Debian policy 
(roughly, it violates a must or required directive), or, in the package 
maintainer's or release manager's opinion, makes the package unsuitable for 
release").

> Googletest 1.8.1-1 should not migrate to testing as long as mathicgb
> FTBFS.  

This is the assertion that I don't understand.

-Steve

Bug#910237: Bug

[Steve Robbins]

Control: severity -1 normal

On Fri, 5 Oct 2018 15:40:46 +0200 Paul Gevers  wrote:

> Anyways, mathicgb now FTBFS on the reproducibility infrastructure with
> the same message (or at least one close to it), hence raising severity.

This level seems a bit extreme, to me, considering the guidelines in https://
www.debian.org/Bugs/Developer

Moreover, it's not clear that the bug lies with googletest.

-Steve

Bug#910305: easyloggingpp FTBFS: configure: error: cannot find install-sh, install.sh, or shtool in build-aux ".."/build-aux

[Steve Robbins]

On Thursday, October 4, 2018 12:37:45 PM CDT Sven Joachim wrote:

> Almost certainly it is has been triggered by the recent upload of
> googletest, since the gtest-source directory is just a copy (via cp -a)
> of /usr/src/googletest/googletest.  Looks like that googletest upload
> broke out-of-tree builds.

Yes, it is triggered by new googletest; but the root cause is more subtle.  
The easyloggingpp package uses this rule to build gtest:

override_dh_auto_configure:
# We need to build googletest first
mkdir gtest-build
cp -a /usr/src/googletest/googletest gtest-source
dh_auto_configure -Dgtest-source -Bgtest-build
dh_auto_build -Dgtest-source -Bgtest-build

If you look at the "good" build log [1], you'll see that the above code was 
actually configuring & building with cmake.  With googletest 1.8.1, it flipped 
to using automake -- due to the presence of file "configure".  Unfortunately, 
the autoconf build is broken.

Suggest you add "--buildsystem=cmake" to the dh_auto_configure line.  Then it 
builds fine with googletest 1.8.1.

Best,
-Steve

[1] https://buildd.debian.org/status/fetch.php?
pkg=easyloggingpp=all=9.96.5%2Bdfsg-1=1536739463=0

Bug#910237: googletest breaks mathicgb autopkgtest: invalid cast

[Steve Robbins]

On Wednesday, October 3, 2018 1:26:14 PM CDT Paul Gevers wrote:

> Currently this regression is contributing to the delay of the migration
> of googletest to testing [1]. Due to the nature of this issue, I filed
> this bug report against both packages. Can you please investigate the
> situation and reassign the bug to the right package? If needed, please
> change the bug's severity.

I had a look, but it's over my head.  Suggest to file bug upstream.

-Steve

Bug#904316: transition: boost-defaults

[Steve Robbins]

On Sunday, September 23, 2018 2:59:10 AM CDT Giovanni Mascellani wrote:

> I would suggest to avoid too much speculation on this point: uploading a
> new release to unstable is alone rather time consuming, because (beside
> the technical challenges of correctly installing dozens of binary
> packages) we have to fill a debian/copyright file for around 50k files
> with hundreds of contributors (this is why we were still stuck at 1.62).

If debian/copyright is indeed a blocker -- and it is for me, the primary 
reason I have stepped back from boost packaging -- then I think time is well 
spent on the unresolved policy issues around this file.

-Steve

Bug#901148: Also hit

[Steve Robbins]

On Saturday, June 23, 2018 11:14:39 AM CDT you wrote:
> Hi, I can also confirm I'm affected by this and agree that the severity
> should be grave. It's not even trivial to debug where the problem comes
> from [...]

Fully agree.  Was also bitten by this bug and it cost me several hours of 
google debugging, since I normally don't worry about sound -- it has "just 
worked" for quite some time now.  And kudos for all those who made that 
happen!

-Steve

Bug#795021: DDPO: Filter out packages with no version >= testing?

[Steve Robbins]

On Saturday, June 9, 2018 1:38:43 PM CDT Christoph Berg wrote:

> > In the DDPO display, I have some packages that have been removed from
> > unstable and testing, but remain in stable, oldstable, etc.  I'd like
> > to filter these out from the display.
> > In the Display Configuration, I set the "Version" flag to "testing and
> > newer" thinking it would do the trick.  It removes the columns related
> > to other versions.  But all packages remain listed, even if the
> > package has no version in testing and newer.
> > 
> > Can you either modify the filtering of "Version" or add some way
> > to achive my goal?
> 
> I tweaked the Version setting some time ago to do exactly that. Please
> let me know if there's anything missing.

It's perfect.  Works just as I would expect.

Thank you!
-Steve

Bug#896559: googletest: please separate source and "prebuilt library" packages

[Steve Robbins]

On Sunday, April 22, 2018 5:27:07 AM CDT you wrote:
> Package: googletest
> Version: 1.8.0-8
> Severity: important
> 
> Dear maintainer. Now that #868234 has been resolved,
> the package installs sources into /usr/src,
> and the prebuild library, + headers into /usr/include.
> 
> This is somewhat problematic.
> Now if one does not want to use the prebuilt library,
> but build it in tree (anyone who cares will do that),
> the headers from the prebuild library will still be in
> the search path.

I agree it is not optimal.  I have prepared a new revision that implements 
your suggestion #4.  In the upcoming revision:

Package googletest installs sources only
Package libgtest-dev installs headers + lib for gtest
New package libgmock-dev installs headers + lib for gmock

Let me know if this works for you.  I've just pushed it to Salsa:
https://salsa.debian.org/debian/googletest 


> There are several solutions:
> 1. Don't provide prebuild library.
> 2. Don't install sources in googletest package,
>tell people to use $ apt-get source.  BAD.
> 3. Install headers into some prefix, so they won't be automatically used.
> 4. Keep googletest with only the sources, and package
>built library + headers as a separate package, googletest-prebuilt.
> 5. 3+4 Probably the best one.

I don't believe #3 is worth the trouble because (a) it breaks the automatic 
detection I've seen in some packages; and (b) the headers in /usr/src/googlest 
and in /usr/include are identical, so there's no real issue if the latter is 
used for a source build.

Best,
-Steve


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

Bug#868234:

[Steve Robbins]

On Sunday, April 22, 2018 5:15:03 AM CDT you wrote:
> Why does the subject of this issue contains "(now enabled by upstream)"
> even though the content explicitly talks that upstream does *NOT*
> recommend doing that?

I believe the answer lies in the first paragraph:

googletest recommended against a system-wide installation of gtest and
disabled the install target on their build system.  While it seems
they maintain this odd recommendation, they have backtracked on
disabling the installation and since version 1.8 have added install
rules for cmake.

I read "now enabled by upstream" as referring to the  "added install rules".

-Steve


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

Bug#896454: gfal2 FTBFS with googletest >= 1.8.0-7

[Steve Robbins]

On Saturday, April 21, 2018 3:44:49 AM CDT you wrote:

> make[1]: Entering directory '/build/1st/gfal2-2.15.4'
> dh_missing --fail-missing
> dh_missing: usr/lib/x86_64-linux-gnu/libgtest_main.a exists in debian/tmp
> but is not installed to anywhere dh_missing:
> usr/lib/x86_64-linux-gnu/libgtest.a exists in debian/tmp but is not
> installed to anywhere dh_missing: missing files, aborting

The googletest binaries now use the "triplet" library path, so the rules need 
adjusting from

   rm debian/tmp/usr/lib/libgtest.a
   rm debian/tmp/usr/lib/libgtest_main.a

to something like
   rm debian/tmp/usr/lib/*/libgtest.a
   rm debian/tmp/usr/lib/*/libgtest_main.a

-Steve

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

Bug#896453: davix FTBFS with googletest >= 1.8.0-7

[Steve Robbins]

The googletest binaries now use the "triplet" library path, so the rules need 
adjusting from

   rm debian/tmp/usr/lib/libgtest.a
   rm debian/tmp/usr/lib/libgtest_main.a

to something like
   rm debian/tmp/usr/lib/*/libgtest.a
   rm debian/tmp/usr/lib/*/libgtest_main.a

-Steve


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

Bug#743824: digikam: Digikam no longer displays any album thumbnails

[Steve Robbins]

On Sunday, April 15, 2018 5:01:48 AM CDT MH wrote:
> Package: digikam
> Version: 4:5.6.0-4+b2
> Followup-For: Bug #743824
> 
> Dear Maintainer,
> 
> Digikam v. 5.6.0 in Debian Buster (Build date: Dec 21 2017 (target: Debian))
> no longer displays thumbnails under any of the albums in my collection. As
> far as I can tell, there has been no recent update of digikam and it has
> been functioning normally.

1. When you say "it has been functioning normally" -- do you mean to say that 
you had been running 5.6.0-4+b2 (the December 21 build) and it was showing the 
thumbnails but then suddenly STOPPED showing thumbnails?  

2. If so, was there any change to dependency packages on or near the day it 
stopped working?

> I tried deleting the databases, rebuilding thumbnails, purging digikam and
> reinstalling. Problem remains. No error messages displayed at any time.

3. Is digikam configured with external SQL database?

Thanks,
-Steve


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

Bug#895708: Pushed fix for googletest-induced build failure

[Steve Robbins]

Hi,

I pushed a fix for the build failure to the salsa git repo -- it links the 
test binary with -lpthread.  This is enough to build in a clean (pbuilder) 
environment.  If you want me to make a team-upload to debian to fix it, just 
let me know.  Otherwise, I'll leave it in your hands.

Cheers,
-Steve


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

Bug#895713: FTBFS with googletest 1.8.0-7

[Steve Robbins]

severity 895713 normal
tags 895713 + patch
thanks

On Saturday, April 14, 2018 7:10:33 PM CDT you wrote:

> Debian's googletest package used to ship only sources, not a compiled
> libgtest.  The ros-catkin package has a build-dep on libgtest-dev.

I was mistaken on the second point; ros-catkin does NOT build-depend on 
libgtest-dev.  I got confused while rebuilding it on my development system 
with gtest installed.  This configuration does provoke the errors described.  
At present, however, ros-catkin rebuilds fine on a clean (pbuilder) 
environment.  So I'm downgrading this bug.

If, in future, you decide to enable tests, you will run into this bug.  It 
looks to me like the gtest and gtest_main libraries are already set by
"find_package(GTest QUIET)".  Removing the lines in catkin's gtest.cmake (see 
patch) fixes the build for me.


> 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)

This is again what I observed on my development system.  When built in a clean 
environment -- e.g. see [1] -- this error does not occur, although #895708 
does.  I'm not sure why.

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/ros-rospack.html

-Steve
diff --git a/cmake/test/gtest.cmake b/cmake/test/gtest.cmake
index c12f67f..ace642a 100755
--- a/cmake/test/gtest.cmake
+++ b/cmake/test/gtest.cmake
@@ -366,10 +366,6 @@ if(NOT GMOCK_FOUND)
 endif()
   else()
 message(STATUS "Found gtest: gtests will be built")
-add_library(gtest SHARED IMPORTED)
-set_target_properties(gtest PROPERTIES IMPORTED_LOCATION "${GTEST_LIBRARIES}")
-add_library(gtest_main SHARED IMPORTED)
-set_target_properties(gtest_main PROPERTIES IMPORTED_LOCATION "${GTEST_MAIN_LIBRARIES}")
 set(GTEST_FOUND ${GTEST_FOUND} CACHE INTERNAL "")
 set(GTEST_INCLUDE_DIRS ${GTEST_INCLUDE_DIRS} CACHE INTERNAL "")
 set(GTEST_LIBRARIES ${GTEST_LIBRARIES} CACHE INTERNAL "")


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

Bug#895505: googletest 1.8.0-7 makes many packages FTBFS

[Steve Robbins]

clone 895505 -1 -2 
reassign -1 gumbo-parser
reassign -2 ros-rospack
retitle -1 use gtest sources or use -pthread with system libgtest
retitle -2 use gtest sources or use -pthread with system libgtest
tags 895505 + pending
thanks

On Thursday, April 12, 2018 1:28:45 AM CDT you wrote:
> Package: googletest
> Version: 1.8.0-7
> Severity: serious
> Control: affects -1 src:gumbo-parser src:ros-rospack src:colobot
> src:arrayfire src:opensurgsim src:rapidjson src:gfal2 src:kodi src:davix
> src:libqtdbustest src:properties-cpp src:libqtdbusmock

Two independent changes to googletest 1.8.0-7 led to the failures:

1. The shipped /usr/src/gtest/CMakeLists.txt has a bug that makes it unuseable 
-- install TARGETS is now a variable that relies on include(GNUInstallDirs).  
Bug #895505 is tracking this issue.

2. A compiled library is now included.  gumbo-parser and ros-rospack 
dynamically detect this and attempt to use it without using -pthread.  These 
packages need to either ignore the system lib and use the sources or link with 
-pthread.  This is being tracked in the two cloned bugs.

-Steve


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

Bug#895505: googletest 1.8.0-7 makes many packages FTBFS

[Steve Robbins]

Adrian:

Thanks for the rapid feedback!

On Thursday, April 12, 2018 1:28:45 AM CDT you wrote:
> Package: googletest
> Version: 1.8.0-7
> Severity: serious
> Control: affects -1 src:gumbo-parser src:ros-rospack src:colobot
> src:arrayfire src:opensurgsim src:rapidjson src:gfal2 src:kodi src:davix
> src:libqtdbustest src:properties-cpp src:libqtdbusmock

> I do not know whether these are one or more regressions in googletest,
> or whether these are bugs in the packages that now FTBFS.

Three of the links listed:

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gumbo-parser.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/
rapidjson.html
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/
libqtdbustest.html

lead to build logs that indeed are probably regressions due to the new 
googletest.  I will propose patches for each.

The remaining links lead to a summary page that says things like 
"build_id_differences_only".  Is this truly a build failure?  Can you point me 
to a build log?

Thanks again,
-Steve


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

Bug#893515: digikam: FTBFS with kdepim 17.12.2

[Steve Robbins]

On Sunday, April 8, 2018 1:25:42 PM CDT Simon Frei wrote:
> I totally understand that, I am just trying to get infos to you as
> debian maintainer from my (at the moment admittedly almost non-existing)
> involvement upstream. Exiv2 0.26 will likely not get into testing.
> Upstream does backport a lot of security fixes to 0.26, but negated
> creating a dot release on request, and is focussing on 0.27. It was
> planned to release an rc in early 2018, but from what I read in the
> issue tracker, that's not going to happen asap.

Yes, fair enough.   I'm not entirely opposed to patching digikam to accept the 
older exiv2.  That was going to be my Plan B in any case, but you make a good 
case to do it immediately and work on updating exiv2 in parallel.

-S
 


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

Bug#893515: digikam: FTBFS with kdepim 17.12.2

[Steve Robbins]

On Sunday, April 8, 2018 1:03:29 PM CDT Simon Frei wrote:
> Digikam still works with exiv2 0.25. It's just that a lot of fixes have
> gone into 0.26 that prevent crashs in digikam, that's why its cmake file
> has a >=0.26 dependency.

Well, the digikam build with 0.25 just stops with an error -- as you say, its 
from the cmake file.  It's possible this is just to "prevent crashes", but I 
hate to second-guess upstream.  Moreover, preventing crashes is good.  So I'd 
prefer to focus on getting exiv2 0.26 into Debian.

-Steve


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

Bug#893515: digikam: FTBFS with kdepim 17.12.2

[Steve Robbins]

On Monday, March 19, 2018 10:48:38 AM CDT you wrote:

> digikam 5.6.0-4 can't be compiled with KDE Pim 17.12.2, it failes
> because kcalcore was been refactored to use QDateTime instead of
> KDateTime. 

I have DigiKam 5.9.0 compiled locally and it works.  Unfortunately, it depends 
on exiv2 0.26 that only exists in experimental.  So the digikam upload will 
also be to experimental.

-Steve


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

Bug#888070: [pkg-boost-devel] Bug#888070: boost CUDA compatibility

[Steve Robbins]

On Monday, January 22, 2018 9:51:23 PM CST Lumin wrote:

> It seems that updating boost to a newer version may solve this
> problem.

You can find sources to build a Boost 1.65.1 package here:
svn://anonscm.debian.org/pkg-boost/boost/

There is no binary package available for 1.65.1 and I have no estimate on when 
there might be one.

Best,
-Steve


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

Bug#866435: I'd volunteer to fix this bug and would move the packaging to Git

[Steve Robbins]

On Sunday, January 7, 2018 1:37:36 AM CST Andreas Tille wrote:
> Hi Steve,
> 
> it seems this package is not yet in Git.  I'd volunteer to move it
> to Git and fix the bug.  Is this OK for you?

That would be awesome.  Please do so!

Thanks,
-Steve


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

Bug#883987: [pkg-boost-devel] Bug#883987: boost1.62: FTBFS error: partial specialization ... after instantiation ... (with patch)

[Steve Robbins]

On Saturday, January 6, 2018 5:25:28 AM CST Pierre Saramito wrote:
> Hi all,
> 
> Any news from the boost package maintainers for this bug ?
> 
> A patch is available for this bug (see attachement)
> and it should be easy to fix it now.

Appreciate the reminder.  I should be able to upload today.

-Steve


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

Bug#732663: sparc & liblo

[Steve Robbins]

On Sunday, December 24, 2017 12:04:26 PM CST you wrote:
> Hi Steve,
> 
> Yes, liblo still (forcibly) fails on sparc. The failure is enforced in
> debian/rules 

Ah, thanks.  Now I see it :-)


> so I don't need a patch for it. So unfortunately you still
> need to avoid liblo in sparc/sparc64. Sorry.

Will do.
 
> Saludos
> 
> On Sun, Dec 24, 2017 at 12:51 AM, Steve Robbins <st...@sumost.ca> wrote:
> > Hello Felipe,
> > 
> > I'm unsure of the current state of liblo w.r.t. the SPARC architecture. 
> > At
> > one point -- see below -- it was forcibly failing.  But latest changelog
> > (0.29-1) reads "drop all debian packages".  So I presume the forced
> > failure is
> > gone?   Does liblo work now or do I still need to do something with
> > nyquist --
> > a user of liblo.
> > 
> > Thanks,
> > -Stev
> > 
> > On Thursday, December 19, 2013 10:13:21 PM CST you wrote:
> > > Dear maintainers of liblo-reverse dependencies, I forward you the mail
> > > in which I request the removal of liblo in sparc. If your package can
> > > opt out of using liblo and you want to support sparc, please drop the
> > > dependency there, as liblo will no longer be available in that
> > > architecture. Otherwise, your package will have to be removed from
> > > sparc.
> > > 
> > > Thanks
> > > 
> > > 
> > > 732386: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732386
> > > 
> > > 
> > > -- Forwarded message --
> > > From: Felipe Sateler <fsate...@debian.org>
> > > Date: Tue, Dec 17, 2013 at 10:49 AM
> > > Subject: Bug#732386: RM: liblo [sparc] -- ANAIS; Does not work, never
> > > has
> > > To: Debian Bug Tracking System <sub...@bugs.debian.org>
> > > 
> > > 
> > > Package: ftp.debian.org
> > > Severity: normal
> > > 
> > > liblo (all binaries) needs to be removed from sparc. I doesn't work, and
> > > never has. Please see bug #721617 for details (TLDR; unaligned access
> > > and SIGBUS). Upstream may or may not fix the issue eventually.
> > > 
> > > I have just uploaded a version (0.26~repack-8) that purposely fails on
> > > sparc and sparc64, so that it doesn't build again.



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

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

[Steve Robbins]

On Friday, December 22, 2017 5:28:36 PM CST Scott Kitterman wrote:
> On Tue, 20 Jun 2017 18:25:16 -0500 "Steve M. Robbins"  
wrote:
> > 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
> 
> half a year later, the rdepends on release architectures still has:
> 
> Checking reverse dependencies...
> # Broken Depends:
> libbitcoin: libbitcoin-dev [amd64 mips64el]

Removed from testing over a year ago and fails to build on all architectures.  

> lightspark: lightspark-common [amd64 arm64 armel armhf i386 mips mips64el

Removed from testing over a year ago and fails to build on all architectures.  
Mattia Rizzolo just filed a removal bug: #885024


> swift-im: libswiften-dev [amd64 arm64 armel armhf mips mips64el mipsel

Not in testing and fails to build on all architectures.

> Can you work on getting these updated or removed so we can get this done?

I'd say it is safe to remove the old boost.  None of the above build on any 
architecture  -- so removing boost won't make anything worse.

-Steve


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

Bug#880884: marked as done (qtav: Adapt to libva 2)

[Steve Robbins]

Hello Sebastian,

On Sunday, November 12, 2017 7:21:30 PM CST Sebastian Ramacher wrote:

> >[ Pino Toscano ]
> >* Remove manual library and va-driver dependencies. (Closes: #880884)
> 
> I am afraid that this change is not enough. qtav still needs to be ported to
> the new libva.  Currently it links libva2, 

Concretely, what needs to be "ported"?  The sources build against libva2 as 
you say.  Aside from dlopen issues, below, what needs to change?

> but dlopens libva.so.1,
> libva-x11.so.1, and maybe others. 

How did you determine this?   I looked for dlopen in the code and found 
nothing.  Grepping for "libva" came up only with this code setting a 
"detail_display" property. 

VideoDecoderVAAPI::VideoDecoderVAAPI()
: VideoDecoderFFmpegHW(*new VideoDecoderVAAPIPrivate())
{
setDisplayPriority(QStringList() << QStringLiteral("X11") <<  
QStringLiteral("DRM") << QStringLiteral("GLX"));
// dynamic properties about static property details. used by UI
// format: detail_property
setProperty("detail_surfaces", tr("Decoding surfaces") + QStringLiteral(" 
") + tr("0: auto"));
setProperty("detail_derive", tr("Maybe faster"));
setProperty("detail_display", QString("%1\n%2\n%3")
.arg("X11: libva-x11.so is required")
.arg("GLX: libva-glx.so is required")
.arg("DRM: Support 0-copy only with EGL. May work without X11. 
libva-drm.so is required")
);
}

I have no clue how this property is used, but it clearly does not specify the 
SO VERSION of any library.  So are we sure the problem lies within qtav?  Is 
it possibly a manifestation of #881521?

Thanks,
-Steve


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

Bug#834131: digikam: no video playback and no video thumbnails

[Steve Robbins]

Yes.   I have been waiting for qtav to enter Debian.   That just happened this 
week.  So next upload should have video again.

On November 4, 2017 8:44:29 AM CDT, Marcel Dischinger  wrote:
>Package: digikam
>Version: 4:5.7.0-1
>Followup-For: Bug #834131
>
>Since version 5.6.0 video thumbnails and playback are broken again
>(worked for me for the versions before with the libqtmultimedia
>packages).
>
>Digikam release notes state that starting with 5.4.0 qtav is used for
>audio and video files, replacing libqtmultimedia. So I guess a rebuild
>is necessary to enable audio and video support again.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#879298: Correcting statement about fabo

[Steve Robbins]

Hi Tobias,

Thanks for the correction!

On Tuesday, October 24, 2017 12:08:02 AM CDT you wrote:
> Hallo,
> 
> When I filed the bugs in respect of the maintainer status of Fathi I used
> the wrong switch in the script. I'd like to correct that.
> 
> Fathi has NOT retired, so the sentcne Fathi having retired is wrong.
> 
> it should have read
> 
> Fathi Boudra  has not been working on the $PKG package for
> quite some time.
> 
> I'm sorry for the inconvenience.

No problem.  Is it still the case that you recommend Fathi be removed from the 
uploaders list?

Thanks,
-Steve


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

Bug#857491: Computation of top_dir is fooled by README

[Steve Robbins]

On Thursday, October 5, 2017 6:37:51 PM CDT Anton Gladky wrote:
> Hi Steve,
> 
> thanks for the bug report. The simple solution to remove ".." from that
> list cause FTBFS of the package. One need to find more reliable
> solution.

Ah.  I had only done the editing on the installed file and it worked for my 
purposes.   In the worst case, perhaps it could be removed post-build,
after installing to debian/tmp.

-Steve


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

Bug#737016: Uploaded -- waiting NEW queue processing

[Steve Robbins]

Tracking URL is: https://ftp-master.debian.org/new/qtav_1.12.0%2Bds-1.html



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

Bug#876154: digikam: FTBFS: error: missing binary operator before token "defined"

[Steve Robbins]

On Tuesday, September 19, 2017 12:27:56 PM CDT Nobuhiro Iwamatsu wrote:

>  #if not defined(__APPLE__) && defined(__GNUC__)
>  ^~~
> /build/digikam-5.3.0/core/libs/database/imagehistory/imagehistorygraph_boost
> .h:1557:9: error: missing binary operator before token "defined"


> Could you check this problem?

Thanks, confirmed.  It seems that someone has turned on -fno-operator-names.  
This was not present before [1].  RedHat has the same issue reported [2].


[1] https://buildd.debian.org/status/fetch.php?
pkg=digikam=amd64=4%3A5.3.0-1=1479074086=0
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1423329


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

Bug#853734: [pkg-boost-devel] Bug#853734: Bug#853734: ping

[Steve Robbins]

On Friday, September 22, 2017 3:17:58 PM CDT pdzie...@igf.fuw.edu.pl wrote:
> Hi,
> 
> what is the status of this bug?
> 
> I think it has become more urgent to fix it since starting with Boost
> 1.65.0 the
> boost::python::numeric API has become obsolete and now only the
> boost::python::numpy API is available.

Thank you for the ping.  We will surely create packages using NumPy for the 
new boost.  I simply haven't had time to get to the new packages yet.

-Steve


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

Bug#718908: digikam: Renaming of image files very slow

[Steve Robbins]

On Monday, August 5, 2013 2:24:45 AM CDT Matthias Julius wrote:
> Package: digikam
> Version: 4:2.6.0-1+b2
> Severity: normal
> 
> Dear Maintainer,
> 
> renaming of image files takes more than a second per file. When renaming
> hundreds of files this adds up to a long time. The files are located on
> a NFS share. However, mapivi is doing the same job in a fraction of the
> time.

Does this remain a problem with the newer Digikam 5.x ?

Thanks,
-Steve


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

Bug#869148: digikam cannot import photos from iphone

[Steve Robbins]

On Thursday, July 20, 2017 3:39:43 PM CDT Herminio Hernandez Jr wrote:

> I am trying to import my photos from my iphone to my desktop. I plug the
> iphone into the USB port and I see KDE recognizing and asking if I want
> digikam in import. I click on the digikam icon and it the app launches.
> After launch I recieve an error say the device is not recognized. I will
> be attaching a screenshot of the error.

What kind of iPhone is it?  

I see a similar report against OpenSUSE for iPhone 6S that shows the same 
error message; 
seehttp://opensuse.14.x6.nabble.com/Digikam-etc-cannot-upload-from-iPhone-6S-td5078569.html

Of interest is this bit:

[quote]
See also 
https://forums.gentoo.org/viewtopic-t-1057040-start-0-postdays-0-postorder-asc-highlight-.html?sid=4e7f17ebc8ac5da89456e92ee46749c5

Apparently it broke with iOS 10 and you need to make sure that the iPhone 
"trusts" your computer so it exposes its filesystem. 
[/quote]

And, as Simon said: let us know if you try it with a newer version.  [which 
reminds me: we need a newer version for Debian ...]

-Steve


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

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

[Steve Robbins]

That's fair enough for unstable.   But can we at least remove from testing 
immediately? 

On June 21, 2017 2:25:13 AM CDT, Mattia Rizzolo  wrote:
>Control: tag -1 moreinfo
>
>On Tue, Jun 20, 2017 at 06:25:16PM -0500, Steve M. Robbins wrote:
>> 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.
>
>That's not easily possible as you're going to break a number of reverse
>dependencies.
>Possibly they can be broken by forcing the removal, but at least make
>the effort of checking them, there are packages that fails on release
>architectures.
>Please take care of completing your transitions:
>
>
>Checking reverse dependencies...
># Broken Depends:
>berkeley-express: berkeley-express [kfreebsd-amd64 kfreebsd-i386]
>bitcoin: bitcoin-qt [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
> bitcoin-tx [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
> bitcoind [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
>comedilib: libcomedi0 [kfreebsd-amd64]
>dc-qt: dc-qt [kfreebsd-amd64]
>dogecoin: dogecoin [kfreebsd-amd64 kfreebsd-i386]
>dolfin: libdolfin2016.1 [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
>python-dolfin [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
>encfs: encfs [kfreebsd-amd64 kfreebsd-i386]
>freemat: freemat [hurd-i386]
>kcollectd: kcollectd [kfreebsd-amd64]
>kig: kig [kfreebsd-amd64 kfreebsd-i386]
>libbitcoin: libbitcoin-dev [amd64 hurd-i386 i386 kfreebsd-i386
>mips64el]
>lightspark: lightspark-common [amd64 arm64 armel armhf hurd-i386 i386
>kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel ppc64el s390x]
>maffilter: maffilter [kfreebsd-amd64]
>mia: libmia-2.4-0 [kfreebsd-amd64]
> mia-tools [kfreebsd-amd64]
>molds: molds [powerpc]
>pokerth: pokerth [kfreebsd-amd64 kfreebsd-i386]
> pokerth-server [kfreebsd-amd64 kfreebsd-i386]
>pytango: python-pytango [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
> python-tango [powerpc]
> python3-pytango [hurd-i386 kfreebsd-amd64 kfreebsd-i386]
> python3-tango [powerpc]
>python-mapnik: python-mapnik [kfreebsd-amd64]
>   python3-mapnik [kfreebsd-amd64]
>swift-im: libswiften-dev [amd64 arm64 armel armhf kfreebsd-amd64 mips
>mips64el mipsel powerpc ppc64el s390x]
>libswiften3 [amd64 arm64 armel armhf kfreebsd-amd64 mips mips64el
>mipsel powerpc ppc64el s390x]
>swift-im [amd64 arm64 armel armhf kfreebsd-amd64 mips mips64el mipsel
>powerpc ppc64el s390x]
>synfig: synfig [kfreebsd-amd64 kfreebsd-i386]
>ycmd: ycmd [kfreebsd-amd64 kfreebsd-i386 powerpc]
>
>
>-- 
>regards,
>Mattia Rizzolo
>
>GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
>more about me:  https://mapreri.org : :'  :
>Launchpad user: https://launchpad.net/~mapreri  `. `'`
>Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#861718: src:cppunit: please update cppunit to 0.14.0

[Steve Robbins]

Hi.  I think your plan is fine.  I  no  longer use cppunit myself so I'm happy 
to see you take an active role in the maintenance.   Please consider yourself 
the lead maintainer and feel free to go ahead with upload or whatever.

Best
Steve 

On May 14, 2017 6:49:49 AM CDT, Rene Engelhard  wrote:
>Hi,
>
>On Wed, May 03, 2017 at 09:19:53AM +0200, Rene Engelhard wrote:
>> I prepared the update, if you want I can commit to collab-maint
>and/or add myself as co-maintainer
>> and/or even upload it.
>
>Thought I saw it on collab-maint but I must have dreamed, see none.
>
>So I imported it into pkg-openoffice's git:
>https://anonscm.debian.org/cgit/pkg-openoffice/cppunit.git
>
>I also changed the maintainer to Debian LibreOffice Maintainers, see
>ab57c8c93276a09b52e376608a36c593a0895aac, kept you as Uploaders: (and
>added 
>me)
>
>cppunit is maintained upstream at TDF so I guess it's better related.
>If you wish I can revert that, though, and move the .git somewhere
>else...
>
>Regards,
> 
>Rene

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#705948: nyquist: diff for NMU version 3.05-2.1

[Steve Robbins]

Thanks for the bug fix!

But there's something wrong with the attached diff.  Can you submit again, 
please?  Or submit it to collab-maint?

Thanks,
-Steve


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

Bug#857421: Many plugins are lost since Jessie

[Steve Robbins]

On Friday, March 10, 2017 12:22:25 PM CDT David Prévot wrote:
> Package: kipi-plugins
> Version: 4:5.3.0-1
> Severity: important
> 
> Hi,
> 
> Thank you for taking care of these plugins!
> 
> More than half the plugins advertised in the package description
> (including BatchProcess) seem to have been lost after an upgrade from
> Jessie to Stretch. Indeed, only 15 of them seem available while over 30
> are still present in the package description.

Thanks.  I will have to review this.   I knew a lot of these had gotten left 
behind in the move to KDE Frameworks 5.  I had hoped they would reappear 
eventually, but never did and I forgot to clean up the package description.  
So thanks for the reminder.

> Is there any way to have them back (even individually) in a Stretch
> system (is it a packaging or an upstream issue? 

It's a good question.  I'll have to look into that.

-Steve


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

Bug#853734: [pkg-boost-devel] Bug#853734: ping

[Steve Robbins]

Hello Sylwester,

Below, I speak only for myself, not my co-maintainers.

On Monday, March 6, 2017 9:54:17 AM CST sla...@staszic.waw.pl wrote:
> Sorry for being impatient, but let me take the freedom to ping :)

No problem.  I'm afraid this answer will disappoint you, however.  

Since Debian is in freeze mode for the next release: I do not plan on 
uploading anything to "unstable" until the release is out.   It is 
theoretically possible to make an upload to "experimental", but I don't have 
time for that. 

My general plan is to wait until the release is out, then upload whatever 
Boost version is newest at that time.  I would only make these kind of 
improvements in that version.

-Steve


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

Bug#853734: [pkg-boost-devel] Bug#853734: NumPy support in Boost.Python (via a new package?)

[Steve Robbins]

Hello,

On Tuesday, January 31, 2017 1:58:03 PM CST sla...@staszic.waw.pl wrote:

> Following the comment (at the same url) from the maintainer, it would be
> likely optimal to create a new package for the numpy support in order
> not to introduce dependency on NumPy in the Boost.Python package itself.

Thank you for the note and link to previous discussion with upstream.  As you 
suspected, I wasn't really following the NumPy situation.  Will look into 
creating NumPy-aware package.

-Steve




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

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

[Steve Robbins]

On Friday, January 13, 2017 10:04:44 AM CST you wrote:

> Sorry for the delay!

That's no problem.  With Debian in freeze, I'm not in any hurry.


> If you are still interested please join the Qt/KDE team
> on alioth.

Done.

> Is qtav as repo name OK for you?

Sure.  

-S


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

Bug#850795: [pkg-boost-devel] Bug#850795: libboost1.62-doc: Missing HTML documentation

[Steve Robbins]

On Tuesday, January 10, 2017 9:55:52 AM CST Michal Sojka wrote:

> this package does not have any HTML files in
> /usr/share/doc/libboost1.62-doc/HTML directory. I consider this a bug,

Agree that it's a bug.   Recommend you use the web pages: 
http://www.boost.org/doc/libs/
1_62_0/[1] 

It is a bug that is going to have to wait for someone to step forward and deal 
with 
upstream's unfortunate packaging and Debian's unfortunate javascript policy.  
Otherwise, 
my solution will be to remove the -doc package.

-Steve



[1] http://www.boost.org/doc/libs/1_62_0/


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

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

[Steve Robbins]

On Monday, January 2, 2017 4:17:14 PM CST you wrote:
> On miércoles, 28 de diciembre de 2016 14:14:51 ART Steve M. Robbins wrote:

> > 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?
> 
> Sure thing. Dmitry and I have also been thinking in Qt-extras, but
> kde-extras is just fine.

I've never heard of Qt-extras.  If that's a better fit: fine with me.  Where is 
the repo?

> Feel free to ask here for reviews if you want.

Thanks!  

-Steve



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

Bug#849830: [Pkg-kde-extras] Bug#849830: [src:digikam] Some sources are not included in your package

[Steve Robbins]

On Sunday, January 1, 2017 2:29:37 AM CST you wrote:
> On Sunday, January 01, 2017 12:59:08 AM Steve Robbins wrote:
> > On Saturday, December 31, 2016 10:06:37 PM CST you wrote:

> > No part of the resulting binary package comes from files that are not in
> > their intended form of modification.  I acknowledge there are extra
> > non-source files in the source tarball *that are not used* to create the
> > binary.
> 
> Speaking as a member of the FTP team, the source needs to be DFSG free to be
> in Main.  Regardless of if it's used in the binary.

To take that position, you need to redefine "source" as essentially any file in 
the upstream tarball, regardless of whether it is used to produce the binary 
packages.   I think most people -- myself included -- would equate "source" 
with "files that are used to produce the binary distribution" (and, for 
avoidance of doubt, this includes config files, doc files used to produce -doc 
packages, etc).

Taking your stronger view requires creating a debian-specific "source" tarball 
that pragmatically gains no extra freedom for the users. 

Moreover I don't find that definition in the DFSG, which says only that: "The 
program must include source code, and must allow distribution in source code 
as well as compiled form."

> > > In some cases this could also constitute a license violation for some
> > > copyleft licenses such as the GNU GPL. (While sometimes the licence
> > > allows not to ship the source, the DFSG always mandates source code.)
> > 
> > It requires all sources required to create the binary.  Digikam meets this
> > test.
> 
> No.  It doesn't.  This is a valid bug and one that's not hard to fix.

The GPL defines  “source code” as "the preferred form of the work for making 
modifications to it."   The requirement is that if you provide a covered work, 
you must also provide the source.  There is no restriction in the GPL that 
forbids extraneous non-source files from being provided in the same tarball.  
So, yes: Debian's Digikam meets the GPL requirements.

-Steve


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

Bug#849830: [src:digikam] Some sources are not included in your package

[Steve Robbins]

On Saturday, December 31, 2016 10:06:37 PM CST you wrote:

> your package includes some files that seem to lack sources
> in preferred forms of modification (even if removed during clean target).

No part of the resulting binary package comes from files that are not in their 
intended form of modification.  I acknowledge there are extra non-source files 
in the source tarball *that are not used* to create the binary.

> According to Debian Free Software Guidelines [1] (DFSG) #2:
>  "The program must include source code, and must allow distribution
>   in source code as well as compiled form."

Digikam meets this test.

> In some cases this could also constitute a license violation for some
> copyleft licenses such as the GNU GPL. (While sometimes the licence
> allows not to ship the source, the DFSG always mandates source code.)

It requires all sources required to create the binary.  Digikam meets this 
test.

-Steve


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

Bug#686402: kfreebsd-kernel-headers: several headers assume _BSD_SOURCE

[Steve Robbins]

Yes well the bug is in the kfreebsd headers.  I should have been more precise: 
the bug is no longer relevant to ITK.  Perhaps I should have just reassigned to 
some other package. 

On August 12, 2016 8:57:14 AM CDT, u...@debian.org wrote:
>"Steve M. Robbins"  writes:
>
>> Bug #686402 is no longer relevant since ITK is not targeting
>kfreebsd.
>
>Support for -std=c99 would still be good to have as a matter of
>principle, and seems like it should be straightforward to implement.
>I won't press the matter further, though.
>
>-- 
>Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
>http://www.mit.edu/~amu/ |
>http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#820635: igstk: depends on vtk 5

[Steve Robbins]

I pass also.


On April 11, 2016 4:41:20 AM CDT, Gert Wollny  wrote:
>Hello,
>
>Am Montag, den 11.04.2016, 08:28 +0200 schrieb Andreas Tille:
>
>
>> I had the impression that VTK6 might be supported by the latest
>> version 5.2 but I'm not sure.  I personally have no free time slices
>> to verify this.  
>Well, I had a stab a this a few days ago, the complications are: 
>
> - no vtk6 
> - The Qt GUI requires that vtk is compiled with Qt support, 
>   but it uses QT4 and vtk6 is build against QT5
>
>At this point I gave up, and looked at the project activity: The
>developers list has below one mail a month, in the last three years and
>it's mostly unanswered questions, and the user list is likewise very
>low traffic and there are two mail that spell out the missing VTK6
>support. 
>
>> If nobody raises his hand to volunteer maintaining this package in a
>> short time frame I'd be fine with removing it.
>I pass on this one. The project is hosted by Kitware, and somehow I
>suspect that they would continue maintaining it if there was serious
>interest. 
>
>Best, 
>Gert 

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#809228: It would be nice to have 1.60 in sid

[Steve Robbins]

Last night I got rid of these source lintian errors.  So forget my earlier msg.

I'm well on my way to an upload now.  Hopefully in the next day or two.


On February 29, 2016 9:46:55 AM CST, Mario Lang  wrote:
>"Steve M. Robbins"  writes:
>
>> On Fri, 26 Feb 2016 22:03:37 +0100 Mario Lang 
>wrote:
>>> Hi.
>>> 
>>>  Is there anything in particular I could help you with to get it
>>> done?
>>
>> Yes.  I have the new package in the svn and it is building.  But
>there are a 
>> zillion lintian complaints about missing sources:
>>
>> E: boost1.60 source: source-is-missing 
>> libs/sort/doc/doxygen/html/search/all_0.js line length is 258
>characters 
>> (>256)
>>
>> If you have some time to send patches for this, would be appreciated.
> I 
>
>Unfortunately, I am about to leave on a trip to Italy.
>Saturday at the earliest.
>
>> myself have no patience for this and will end up removing the doc
>package 
>> entirely to fix it.
>
>While I try to understand the motivation behind these efforts, I
>also totally understand your frustration.  These are tasks that totally
>waste our time, likely for absolutely no benefit at all.
>
>-- 
>CYa,
>  ⡍⠁⠗⠊⠕

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#737724: gmp-doc: please provide HTML doc besides PDF and INFO

[Steve Robbins]

 I am not actively working on this issue. 

On February 1, 2016 3:57:51 AM CST, Jerome BENOIT  wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>Hello Steve:
>
>I think it is pretty easy provided some change.
>
>Are you you working on it ?
>
>Best,
>Jerome
>-BEGIN PGP SIGNATURE-
>Version: GnuPG v2
>
>iQEcBAEBCAAGBQJWrywfAAoJEIC/w4IMSybjLEgIAMqNC9k/DxO64KfPsui5QLle
>e3xJmKN+m+Lsz1SWUGjwdZbfvdx+DtjijDWZXYZiy1eMaH1g5TNtKlIAi5+dVk8O
>Ry2RFTV8kXOZJH8U1Ps7JJ8t8S+eq1QIP+1/NXJfwZXxnsJ1s9RbwYlf4H0OT6CW
>YvpNMAdz3VDqRBJBxl75Xxu7tLbZ+f5sJc5qASPOvX1DvNsyFmo/UeA9WSwQY7gH
>1BpdoPuH29QAN68vZMWDEt/M10wgSQ+/7cHTUluU2x83fzb8Mj+1Cvno54UhsELC
>cKc9zE+bVk19lOKs9/AB6OZ4jWxp+38hjAyYKsxXGjnHJBAapwa7xF4nldcO+Q8=
>=hXSg
>-END PGP SIGNATURE-

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#806243: libminc: FTBFS on mipsel

[Steve Robbins]

Thanks Jurica.  Is there any difference in fpu?  Soft vs. Hard?  Extra 
precision bits?

On December 7, 2015 9:53:05 AM CST, Jurica Stanojkovic 
 wrote:
>> Jurica: is everything else the same between your good/bad
>environments, 
>> specifically: libc, compiler, and libnetcdf?  I mean: I assume they
>are both 
>> running 'sid', but are the specific versions of each package the
>same?
>
>Yes, i am using sbuild (sid) and environment should be the same.
>libc, compiler and libnetcdf are the same (same versions). 
>I have checked all build logs.
>
>Kernels are not the same:
>3.6.11+ on loongson
>3.7.10 on netlogic-xlp
>4.1.0 on cavium
>but i do not suggest that kernel is issue here.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Steve Robbins]

I acknowledge that a header only library is uncommon.   But I can't agree that 
it us a bug.  Thus I don't believe a warning is required.   And I certainly 
won't remove the package for this reason.   

Given that, can you restate what problem you encountered using the package? 

Thanks, Steve 




On October 21, 2015 5:50:43 PM GMT+05:30, Joachim Wuttke 
 wrote:
>Package: libgtest-dev
>Version: 1.7.0-4
>
>There exists no corresponding library binary package libgtest1.
>
>This is in accordance with a recommendation of the upstream authors,
>https://code.google.com/p/googletest/wiki/FAQ#Why_is_it_not_recommended_to_install_a_pre-compiled_copy_of_Goog,
>but it is in conflict with the well-established standard way
>of how libraries are distributed in Debian.
>
>I wonder if there is any recommendable use of a header package
>that comes without the corresponding library package. Unless
>there is a convincing use case, I propose to remove libgtest-dev
>for good.
>
>Otherwise, at the very least, I suggest that the description of
>libgtest-dev be amended to clearly state that, quite exceptionally
>for a header package, its dependence on the binary library is
>not enforced in Debian, and that upon special recommendation of
>upstream the binary library is not and will not be packaged for
>Debian.
>
>---
>
>Dr. Joachim Wuttke
>Group Leader Scientific Computing
>Jülich Centre for Neutron Science (JCNS)
>Forschungszentrum Jülich GmbH
>Outstation at Heinz Maier-Leibnitz Zentrum (MLZ)
>+49 89 289 10715
>http://apps.jcns.fz-juelich.de

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

[Steve Robbins]

Thanks.  That is helpful.  I'm not in a position to act on this right now.  But 
you've given me several ideas for improvement. 

On October 21, 2015 7:26:29 PM GMT+05:30, Joachim Wuttke 
 wrote:
>> Given that, can you restate what problem you encountered using the
>package?
>
>Somehow I discovered that there is a libgtest-dev in Debian, and a
>FindGTest in cmake. So I installed libgtest-dev on my system, removed
>ThirdParty/gtest from my project, changed CMakeList.txt files, tried
>to rebuild the project, saw that FindGTest did not find the library,
>investigated the problem, and finally discovered that libgtest-dev
>is deceptive in that it does not pull in the binary without which
>it is useless.
>
>Therefore I consider the current state of affairs as untenable,
>which is also attested by the high number of views of the
>discussion thread at 
>http://askubuntu.com/questions/145887/why-no-library-files-installed-for-google-test.
>
>A clear word about the missing dependency on the nonexistent
>library package in the description of libgtest-dev would have had
>the potential of saving me considerable time. I do not insist that
>it be labelled »warning«.
>
>- Joachim

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#802509: [pkg-boost-devel] Bug#802509: libboost-coroutine-dev: The boost-coroutine library is only compiled as a static library

[Steve Robbins]

Severity wishlist
Thanks


On October 20, 2015 10:56:17 PM GMT+05:30, Tiago de Paula Peixoto 
 wrote:
>Package: libboost-coroutine-dev
>Version: 1.58.0.1
>Severity: grave
>Justification: renders package unusable
>
>Dear Maintainer,
>
>The boost-coroutine library is currently only compiled as a static
>library, while all other boost libraries are compiled also as shared
>objects.
>
>Static librares cannot be linked against shared objects, and hence
>this renders this library useless by other libraries and plugins.
>
>AFAIK, there is no reason to compile it as a shared object, since that
>is what most other distros do.
>
>Best,
>Tiago
>
>-- System Information:
>Debian Release: stretch/sid
>  APT prefers unstable
>  APT policy: (990, 'unstable'), (500, 'testing'), (1, 'experimental')
>Architecture: i386 (x86_64)
>
>Kernel: Linux 4.1.6-rh1-xenU (SMP w/4 CPU cores)
>Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
>(ignored: LC_ALL set to en_US.UTF-8)
>Shell: /bin/sh linked to /bin/bash
>Init: systemd (via /run/systemd/system)
>
>Versions of packages libboost-coroutine-dev depends on:
>ii  g++ 4:5.2.1-4
>ii  g++-5   5.2.1-22
>ii  libboost-coroutine1.58-dev  1.58.0+dfsg-3.1
>ii  libstdc++-5-dev 5.2.1-22
>
>libboost-coroutine-dev recommends no packages.
>
>libboost-coroutine-dev suggests no packages.
>
>-- no debconf information
>
>___
>pkg-boost-devel mailing list
>pkg-boost-de...@lists.alioth.debian.org
>http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-boost-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#793885: minc: FTBFS with netcdf in experimental due to test failure

[Steve Robbins]

Correct.  It  needs to be fixed properly.  Your upload is not a fix.  

Thanks, 
Steve

On August 20, 2015 2:47:26 AM CDT, Sebastiaan Couwenberg sebas...@xs4all.nl 
wrote:
On 20-08-15 05:26, Steve M. Robbins wrote:
 On Wed, Aug 19, 2015 at 10:32:04PM +0200, Sebastiaan Couwenberg
 wrote:
 
 To fix this issue I've done an NMU of minc to DELAYED/2, see the 
 attached debdiff for changes.
 
 
 +override_dh_auto_test: +   dh_auto_test || echo Ignoring test
 failures +
 
 I'm afraid that I can't agree that ignoring test failures qualifies
 as fixing this issue.  I'd be happier if you would cancel this
 upload and leave the bug open until it gets properly dealt with.

You mean, when minc gets removed from testing because this RC bug is
not fixed properly?

If you don't mind testing removal of minc, I'm happy to cancel my NMU.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#777912: patch

[Steve Robbins]

Hey.   I was just planning to let v3 just die.  But if the fix is just using 
the same patch it could be useful to apply it.  Still has several dependancies.

On July 4, 2015 4:00:28 AM CDT, Gianfranco Costamagna 
costamagnagianfra...@yahoo.it wrote:
Hi Steve, I saw you fixed insighttoolkit4, do you plan to fix also this
one? the patch is really the same...

However I'm wondering if we should let it disappear from testing, and
try to focus on enabling itk4 on all
architectures...

cheers,

G.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Bug#755539: Elastix needs binnmu after ITK

[Steve Robbins]

On September 3, 2014 5:44:22 AM CDT, Emilio Pozuelo Monfort po...@debian.org 
wrote:
On 02/09/14 07:23, Steve M. Robbins wrote:
 The recent build failure of elastix (#759945) is caused by the
 libhdf5.so path having changed, presumably due to #755539.  The path
 is encoded into insighttoolkit4-dev's file
 /usr/lib/cmake/ITK-4.6/ITKTargets-none.cmake so Elastix will need a
 binnmu as soon as insighttoolkit is rebuilt.

It should build fine now, right? So why is the binNMU needed? There was
a
temporary problem on insighttoolkit4 that is now fixed, but no binNMUs
on
elastix or plastimatch should be needed AFAICS.

Could be.  I was just presenting the results of my investigation into the build 
failure.  

Since the .so file location changed, it is possible that the shared library 
itself changed location or soname. 
So in addition to verifying that it still builds, you need to verify that the 
EXISTING elastix binary continues to function.



Emilio

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#385623: Processed: reopening 385623

[Steve Robbins]

Hi Anthony,

I guess you're reopening of this bug is related to the UNACCEPT  
messages that I got.


I am still in the dark about that.

Could you please let me know what is wrong and what I might need to do  
to fix it?


Thanks,
-Steve






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

Bug#398643: two-line fix for sconsign bug

[Steve Robbins]

tags 398643 + patch
thanks

Hi,

Just after submitting this bug, I worked out the patch, below.  I've already
sent it upstream.

-Steve

--- /usr/bin/sconsign   2006-11-06 08:32:52.0 -0600
+++ /tmp/sconsign   2006-11-14 16:04:51.0 -0600
@@ -166,6 +166,8 @@
 import SCons.SConsign

 def my_whichdb(filename):
+if filename.endswith(.dblite):
+return SCons.dblite
 try:
 f = open(filename + .dblite, rb)
 f.close()



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

Bug#395474: geomview: upgrade to Geomview 1.8.2

[Steve Robbins]

Hello Jerome,

Quoting Jerome BENOIT [EMAIL PROTECTED]:

is there any plan to bring the recent upgraded version of Geomview   
to Debian ?


My plan is to wait until 1.8.2 is officially released.

What I see on geomview.org right is a release candidate
and the accompanying Notes file indicates rapid, unstable development,
which doesn't lend itself to inclusion in Debian.

Thank you for alerting me to geomview's recent release.  Please send a note
to this bug again once 1.8.2 is officially out.

-Steve



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

Bug#394071: Trouble using minc headers with gcc = 4.0

[Steve Robbins]

Hello Michael,

I'm very excited that you're packaging freesurfer.


Quoting Michael Hanke [EMAIL PROTECTED]:


I contacted upstream about this issue and learned that they use a
patched version of minc to address this problem. They kindly provided me
with the patch (courtesy of Nick Schmansky).

I'm not completely sure whether one could handle this situation without
modifying minc, though.


I think you can.  I believe that if you define VIO_PREFIX_NAMES while  
building freesurfer, the typedefs are avoided.  Arranging to pass  
'-DVIO_PREFIX_NAMES' on the compiler command line suffices.


Please let me know how that works out.  If it does work, please close  
this bug and alert freesurfer upstream to have them define it  
unconditionally.


Thanks,
-Steve



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

Bug#314988: geomview: Another undefined option

[Steve Robbins]

Quoting Gilles Sadowski [EMAIL PROTECTED]:


Hi.



Could be: so far AMD64 is the only platform where users have reported
this problem.  But I have no real idea what the cause is.



There is a new version (test release 1.8.2) available from their web site.
Did you try it to see whether it shows the sam behaviour?


I did not.  But I don't have an AMD64 machine with which to test in any case.
Since you do, perhaps you could do the experiment?

-Steve



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

Bug#314988: geomview: Another undefined option

[Steve Robbins]

Quoting Gilles Sadowski [EMAIL PROTECTED]:


And it does nothing else.
Could it be related to the AMD64 platform?


Could be: so far AMD64 is the only platform where users have reported  
this problem.  But I have no real idea what the cause is.


-Steve




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