Bug#964423: FTBFS: QDesktopWidget::screenGeometry is deprecated

[Danny Edel]

On 7/7/20 2:21 AM, John Scott wrote:
> Rebuilding dspdfviewer to see how it would fare with Poppler in
> experimental, I found it FTBFS in unstable unconditionally.
> 
> /<>/pdfviewerwindow.cpp: In member function
> ‘void PDFViewerWindow::reposition()’:
> /<>/pdfviewerwindow.cpp:119:89: error: ‘const QRect
> QDesktopWidget::screenGeometry(int) const’ is deprecated: Use
> QGuiApplication::screens() [-Werror=deprecated-declarations]
>

Hello John,

thank you for bringing this to my attention.  I will make a patch and
report back on this bug.

Regards,

Danny

Bug#845106: x11vnc: configure does not find libssl, builds without OpenSSL support

[Danny Edel]

On Sun, 20 Nov 2016 13:37:46 +0100 Hilko Bengen  wrote:
> after searching for "AC_CHECK_LIB(ssl, SSL_library_init" using
> codesearch.debian.net and rebuilding with OpenSSL 1.1, I found that the
> OpenSSL is no longer detected and thus no longer used when building the
> package.

Hello,

is anyone already working on this?  If not, I would try resolving this
myself, since I use x11vnc a lot and would very much like to see it in
stretch.  The autoremoval because of this bug is currently scheduled for
January 3.

Cheers,
Danny

Bug#830984: fixed in ball 1.4.3~beta1-2 -- only on amd64

[Danny Edel]

On 11/13/2016 05:55 PM, Andreas Tille wrote:
> Hi Danny,
> 
> I fully agree that we should ignore test results on other than amd64
> architecture.  Please let me know if you intend to implement the needed
> change or whether you suggest that I should do so.
> 
> Kind regards
> 
>   Andreas.
> 

Hello Andreas,

I have created and git-pushed a patch to debian/rules.  I did not update
the changelog, since it didn't look like the one uploaded to unstable
earlier today and I wanted to avoid a merge conflict on your side.

If you could review / edit changelog / upload, that would be nice.

A quick test on an i386 chroot with the build command replaced by
/bin/true suggests it does exactly what it's supposed to.  It ran the
test suite, ignored the inevitable error and issued a diagnostic.  It
even printed my warning multiple times : )  The computer will ignore it
of course, but it might prompt a human reader to get involved.

If the new revision actually builds, I would suggest we keep this bug
open (I wrote the bug number into d/rules) and downgrade its severity to
important.

I don't have the time right now to dig into the i386 issues in detail.
If that changes, I might un-dust my old Celeron-based laptop and let it
compile for a few days.  If it can actually run stretch/sid.  I remember
reading something on d-devel about raising the minimum processor
requirements for the i386 port…

Cheers,

Danny



signature.asc
Description: OpenPGP digital signature

Bug#830984: fixed in ball 1.4.3~beta1-2 -- only on amd64

[Danny Edel]

Control: reopen -1

On Sun, 13 Nov 2016 09:18:53 + Danny Edel <deb...@danny-edel.de> wrote:
> We believe that the bug you reported is fixed in the latest version of
> ball, which is due to be installed in the Debian FTP archive.

Hello Andreas, hello Steffen,

it seems like the fixes were indeed only effective on amd64, so I am
reopening the FTBFS/test-suite bug.  Also, I removed the other bugs from
CC, so you don't get each mail 4 times : )

From what I can tell, the testsuite failures fall into two categories:

1.  Most likely completely harmless, -- 0.01 difference in a
floating-point calculation.  The PoseClustering_test seems to be
involved in this on a few arches, where it compares a string rendering
(letter-by-letter) instead of using a fuzzy-compare of the values.

  * arm64
  * ppc64el

2.  Something is really broken and needs debugging on the appropriate
hardware.  Segfaults, integer mismatches (8 != 0), really weird output,
etc...

  * i386
  * s390x
  * kfreebsd-amd64
  * kfreebsd-i386
  * powerpc
  * x32

[at the time of writing, not all arches had finished/failed]

In the case of kfreebsd, the source will likely need patches for the
different kernel, since Sysinfo_test fails with statements like:

TEST_EQUAL(getTotalMemory() > 0, true): got 0, expected 1)

I fear that the tests are likely to keep failing on non-amd64
architectures until someone with access to a corresponding box puts in
the effort to investigate, and adjust the tests for the subtle differences.

Until then, I propose to run, but ignore the return code, of the
testsuite on "anything other than linux-amd64" for now, to have a chance
of re-entry into stretch.

Rationale behind running anyway:  We can load the logfile and grep for
'*Failed' to keep track of the problematic tests.  This string also
works great with the web interface and the ctrl+f feature of most browsers.

Rationale behind ignoring right now:  I assume that the vast majority of
users run amd64 (popcon backs me on this), and those would benefit from
seeing the package in stretch.  Even on the now-FTBFS arches, the
(comprehensive) testsuite suggests that 99% of the library is working as
intended, which should qualify the problem as important, but not
release-critical in my opinion.

If (!) there is a userbase of BALL on Debian-but-non-amd64/non-linux,
there is also the hope one of them will step up and provide assistance
in tracking this down or confirming the actual impact, which is a lot
easier if the package is available as a binary.

What is your opinion?

Danny

-- 

PS:  I submitted a basic travis-ci configuration to upstream for review.
 If it gets accepted, I can work from there to approach the
'will-it-build-on-jessie/stretch/sid/xenial' question.



signature.asc
Description: OpenPGP digital signature

Bug#784451: Bug#833004: Do you have resources to look after ball? [progress info]

[Danny Edel]

Hello Andreas,

On 11/12/2016 05:25 PM, Andreas Tille wrote:
> I'd prefer to skip this test anyway (or let the test suite pass even
> if it fails.

I looked into the source, and I guess excluding the test from the set is
the easiest and most straightforward way to achive the effect.

> Sure.  If you confirm you would volunteer to exclude the test I'll
> delay the upload.  I'd also fix some lintian issues before uploading.

I have written up a quick oneline patch that removes "AmberFF_test" from
the set of test programs to be built+run.  It is already pushed to the
git repository and I updated d/changelog.

I put the upstream issue on watch with my github account, so I should™
get an email if something happens there.

> Thanks again for your very welcome help
> 
>   Andreas.
> 

I don't mind helping out.  I also forked ball upstream on github, maybe
I can add some automatic build/testsuite checks via Travis-CI.  They
base their images on Ubuntu, but it should be a good start, and there's
always sid chroots.

I do expect that with the next release of ball, we have to rework (or
maybe, can outright drop) a lot of the debian/patches.

Hope this helps,

Danny

Bug#784451: Bug#833004: Do you have resources to look after ball? [progress info]

[Danny Edel]

On 11/11/2016 02:29 PM, Andreas Tille wrote:
> Start 197: AmberFF_test
> 197/334 Test #197: AmberFF_test .***Failed
> 0.19 sec
> (...)
> (line 511 TEST_REAL_EQUAL(r4_r1 - r4_i, r1_r4 - r1_i): got -145.471, 
> expected -103.957)  - 
> (line 513 TEST_REAL_EQUAL(r1_r4 - r1_i + r1_tpl + r4_tpl + tpl_i, 
> total_energy): got 1680.36, expected 1638.84)  - 
> FAILED
> FAILED

> Considering Steffen's answer it might be worth trying the said
> snapshot if this might be fixed there.

Hello Andreas, hello Steffen,

this looks like upstream bug [584][], and appears to be intermittent,
but from what I can tell, no code has been added to address this in
upstream master.  So upgrading to a snapshot would not necessarily help.

However, I can *not* reproduce the AmberFF_test failure.  Neither in my
Debian testing environment, nor in an unstable chroot freshly created
with git-pbuilder.

I literally ran the AmberFF_test one thousand times and it did not fail
once.  Of course, that doesn't mean it won't fail on the 1001st time,
but I have no idea how to effectively approach this without deep
knowledge of the program and its algorithms.

Since we're talking floating-point arithmetic, and the results are not
completely off (same sign, and at least within the same order of
magnitude), this may be a hardware-specific corner-case resulting in
greatly reduced precision.  For reference, I'm running on an Intel Core2
6600.

Trying the same code again and expecting a different result might not be
very professional (or even sane), but we could upload to a buildd
(experimental?) and see if the failure is reproducible there.

Of course, it is always an option to exclude this test to restore
buildability.  The quality would certainly not be worse than before,
when the testsuite was skipped entirely.

[584]: https://github.com/BALL-Project/ball/issues/584

Bottom line:  As much as I'd like to help out; without access to a box
where the problem is reproducible, I am not able to.

Best regards,

Danny



signature.asc
Description: OpenPGP digital signature

Bug#784451: Do you have resources to look after ball? [progress info]

[Danny Edel]

Control: block 784451 by 832420

On 11/10/2016 09:13 PM, Andreas Tille wrote:
> I take the freedom to turn this discussion into a public one
> and CC the relevant bugs to leave a record there that something is
> happening.

Hello Andreas,

that is fine with me.  I'll keep the bugs in CC too.

> Hmmm, may be we should base the packaging on a later upstream commit?
> 
>> Among
>> other things, upstream also migrated from Qt4 to Qt5, and incorporated a
>> few fixes for recent boost.
> 
> We somehow should target to Qt5 anyway (see #784451) better sooner than
> later.
>  

For now, I have backported the fixes to the released, but Qt4-based
1.4.3~beta1 version, to resolve the current FTBFS with a targeted fix.
The changes are uploaded to the debian-med/ball repository on alioth,
pending your review and upload.

In that process, I tried building various stages of upstream master, and
bae96ab4 'Merge branch issue_596' might be a candidate for a snapshot
(entire testsuite passes).  However, there is the problem that
QtWebEngine is not yet included in Debian, so I could only build recent
master if I explicitly disabled support with -DUSE_QTWEBENGINE=OFF.  I
am not sure if this would be a good thing for users.

I added a blocking relationship to the ITP of QtWebEngine, I hope I
didn't mix up the numbers.  The changelog contains a Closes: clause on
both FTBFS issues, even though I could only test amd64.  Feel free to
remove those before uploading if that's an issue.

Cheers,
Danny

Bug#780036: vagrant: Vagrant does not Windows guests via 'winrm' [workaround]

[Danny Edel]

On Sun, 08 Mar 2015 10:42:34 -0500 Peter Gallagher
 wrote:
> Attempting to install the winrm GEM manually does not change the behaviour. 
> The
> DEB package provided at https://www.vagrantup.com/download-archive/v1.6.5.html
> does not display this behaviour and works as expected.

Hello,

I came across the same problem today, but as a workaround you can call
(as the same user you normally use vagrant)

$ vagrant plugin install winrm winrm-fs

to install the winrm (and winrm-fs, which is needed next) gems into
vagrant's own gem store (located in ~/.vagrant.d/gems/).  This allows to
manage windows guests in the meantime, until ruby-winrm is packaged for
Debian.

Cheers,

Danny

Bug#797038: add patch

[Danny Edel]

On Sat, 9 Jul 2016 23:51:52 +0200 Matthias Klose  wrote:
> patch at
> http://launchpadlibrarian.net/271939349/llvm-toolchain-3.8_1%3A3.8.1-2ubuntu1_1%3A3.8.1-2ubuntu2.diff.gz

Hello Matthias,

thank you very much!  This patch solves the issue for me, clang++ now
compiles *and* links against abi-tagged c++11 libraries, and I have not
encountered any problems yet.

Cheers,
Danny

Bug#827898: libnetfilter-queue: Please include doxygen-generated documentation

[Danny Edel]

Source: libnetfilter-queue
Severity: wishlist

Dear maintainer,

this library can provide documentation in doxygen format, but it is not
currently built or included in a -doc package.

If you execute "doxygen doxygen.cfg" after running the normal Debian
build (which does generate this file) the documentation is built in the
doxygen/html subdirectory.

Please consider shipping this in the -dev or as its own
libnetfilter-queue-doc package.

Thank you,
Danny

Bug#797917: Porting the patch to debian?

[Danny Edel]

Hi,

I would like to try one of the patches from upstream, but I can't figure
out how to apply them to the sourcecode I grab with "apt-get source
clang-".

In particular, neither the patch from
https://llvm.org/bugs/attachment.cgi?id=14874 nor the newer one from
http://reviews.llvm.org/D18035?download=true applies (quilt import ->
quilt push dies with "can't find file to patch").

Could someone help me by porting that patch against the Debian version
of clang, or even by uploading a patched version to experimental?  I
would gladly test and provide feedback, right now clang is near-unusable
since pretty much every c++ library in Debian uses those abi tags.

Thank you in advance,
Danny

Bug#777791: [PATCH] ball: ftbfs with GCC-5

[Danny Edel]

On 05/18/2016 08:45 AM, Andreas Tille wrote:
> Could you please add your changes to debian/changelog?  If you use
> 
> dch
> 
> it injects a separate section for your ID.

Hi Andreas,

I updated the changelog with dch and it tagged the changes with my name.
The commit is in master.

I hope its all right.

- Danny

Bug#777791: [PATCH] ball: ftbfs with GCC-5

[Danny Edel]

On 05/10/2016 07:13 PM, Andreas Tille wrote:
> Thanks a lot.  Your work is really appreciated.  Please also be bold and
> commit to master.  I have no time to look the next 2-3 days - but I'd
> like to see the changes in master since I see no point in deriving for
> this package what we are doing anywhere else.

Hi Andreas,

I have backported a fix for the Python issue and ball now builds in a
fresh sid cowbuilder.  I also un-deleted the 0001-missingSigned.patch,
since I realized it is needed on ARM, where "char" is "unsigned char" by
default, causing FTBFS when assigning -1 to a "const char".  This may be
a candidate for a pullrequest to the newly moved upstream github repository.

All patches are uploaded to "master", the work-in-progress branch is
deleted.  To me the resulting package (now without any weird hacks and
old packages from snapshot.d.o) seems usable:  I started BALLView and
loaded random projects from /usr/share/BALL-1.4/data/projects, and I get
molecule renderings on my screen -- but I have no idea if these are the
right ones : )

Cheers,

- Danny



signature.asc
Description: OpenPGP digital signature

Bug#777791: [PATCH] ball: ftbfs with GCC-5

[Danny Edel]

On 05/04/2016 02:19 PM, Andreas Tille wrote:
> Any success with you alioth commits?  Did you possibly pinged alioth
> admins via IRC?  I'd love to get you properly working as any normal
> Debian Med member.  If not I'd try to investigate.

Hello Andreas,

sorry for the late reply, but I have been able to commit now.  Thank you
for fixing this.

I mirrored my changes as "fix-debian-bug-91" branch to
debian-med/ball.git, and deleted the temporary mirror.  The work I
pushed is equal to the patch from the last email, so it can be ignored now.

I then rebuilt the package on a fresh sid cowbuilder, but now there's a
new problem (see attachment for the exact error message) near the end of
the build, involving a static_cast.  I will look into that of course,
but I did not want to overwrite the "master" branch before contacting
you, especially not with a not-anymore-working solution.

Will report back here,

- Danny
[ 79%] Building CXX object 
source/PYTHON/EXTENSIONS/CMakeFiles/VIEWmodule.dir/VIEWmodule/sipVIEWpart2.o
/build/ball-1.4.3~beta1/build/source/PYTHON/EXTENSIONS/VIEWmodule/sipVIEWpart2.cpp:
 In function 'void* cast_Box(void*, const sipTypeDef*)':
/build/ball-1.4.3~beta1/build/source/PYTHON/EXTENSIONS/VIEWmodule/sipVIEWpart2.cpp:3184:45:
 error: invalid static_cast from type 'BALL::VIEW::Box*' to type 
'BALL::VIEW::Vertex2*'
 return static_cast(sipCpp);
 ^
source/PYTHON/EXTENSIONS/CMakeFiles/VIEWmodule.dir/build.make:383: recipe for 
target 
'source/PYTHON/EXTENSIONS/CMakeFiles/VIEWmodule.dir/VIEWmodule/sipVIEWpart2.o' 
failed

Bug#822114: puppet-module-puppetlabs-apache: generates invalid SSL configuration file when on Debian (ssl_mutex) [patch]

[Danny Edel]

Package: puppet-module-puppetlabs-apache
Version: 1.1.1-1
Severity: important
Tags: patch

Dear Maintainer,

using the puppet/apache module to configure an SSL-enabled site currently fails 
on jessie.

The check in the file 
/usr/share/puppet/modules.available/puppetlabs-apache/manifests/mod/ssl.pp
only outputs the correct configuration file "ssl_mutex default" when on Ubuntu.

Upstream fixed this in version 1.2.0, the exact commit is
https://github.com/puppetlabs/puppetlabs-apache/commit/2093c1e763ffa0760bbe92cb7ba912979062daae

Since this bug makes it impossible to use the module with SSL on jessie, please 
consider
including this patch in the jessie release.

I verified this in a fresh VM, installing puppet-module-puppetlabs-apache and 
trying
to execute 'puppet apply apache.pp'.  After changing the line, this worked.

Thank you,

- Danny


-- System Information:
Debian Release: 8.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.4.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages puppet-module-puppetlabs-apache depends on:
ii  puppet-common3.7.2-4
ii  puppet-module-puppetlabs-concat  1.1.1-1
ii  puppet-module-puppetlabs-stdlib  4.3.2-1

puppet-module-puppetlabs-apache recommends no packages.

puppet-module-puppetlabs-apache suggests no packages.

-- no debconf information
--- ssl.pp.orig	2016-04-21 10:55:32.153611165 +
+++ ssl.pp	2016-04-21 10:55:51.630464107 +
@@ -12,7 +12,7 @@
 
   case $::osfamily {
 'debian': {
-  if $apache_version >= 2.4 and $::operatingsystem == 'Ubuntu' {
+  if $apache_version >= 2.4 {
 $ssl_mutex = 'default'
   } elsif $::operatingsystem == 'Ubuntu' and $::operatingsystemrelease == '10.04' {
 $ssl_mutex = 'file:/var/run/apache2/ssl_mutex'
class { 'apache':
	apache_version => "2.4",
}

apache::vhost { 'test ssl':
	servername => 'localhost.localdomain',
	ssl => true,
	docroot => '/var/www/html',
}

Bug#777791: [PATCH] ball: ftbfs with GCC-5

[Danny Edel]

On Mon, 11 Apr 2016 17:54:03 +0200 Andreas Tille  wrote:
> Did you created a new repository on collab-maint for this purpose?
> It seems you did not used a clone of the packaging Git
> 
> git://anonscm.debian.org/debian-med/ball.git
> 

Hi Andreas,

sorry for the miswording -- I did use the git repository at the
specified location, not collab-maint.  If the patch didn't apply cleanly
I can't say why.

> since I tried to
> 
> git am 0001-Rework-patches-for-sid.patch
> 
> which resulted in several conflicts.  I wonder whether you could 
> rather commit to the official packaging repository.  To enable you 
> doing this I've added you to the Debian Med team.

Thanks!  I will submit there as soon as the group membership is through.
 I can already see that I'm added in the alioth webinterface, but
"groups" on git.debian.org doesn't yet include scm_debian-med.

Trying to push anyway gives:

danny@debwork ~/git/debian-med/ball $ git push -v
Pushing to git.debian.org:/git/debian-med/ball.git
Counting objects: 13, done.
Delta compression using up to 2 threads.
Compressing objects: 100% (13/13), done.
Writing objects: 100% (13/13), 6.09 KiB | 0 bytes/s, done.
Total 13 (delta 4), reused 0 (delta 0)

remote: error: insufficient permission for adding an object to
repository database ./objects

remote: fatal: failed to write object

error: unpack failed: unpack-objects abnormal exit

To git.debian.org:/git/debian-med/ball.git
 = [up to date]  pristine-tar -> pristine-tar
 = [up to date]  upstream -> upstream
 ! [remote rejected] master -> master (unpacker error)
updating local tracking ref 'refs/remotes/origin/pristine-tar'
updating local tracking ref 'refs/remotes/origin/upstream'
error: failed to push some refs to 'git.debian.org:/git/debian-med/ball.git'

I will try to push again later tonight or tomorrow.  I'm sure this is
just an issue about the group membership update script not run yet.

Cheers,

- Danny



signature.asc
Description: OpenPGP digital signature

Bug#777791: [PATCH] ball: ftbfs with GCC-5

[Danny Edel]

Control: tags -1 patch

Hello Andreas,

I have taken on the ball FTBFS again, and have backported more fixes
from the github upstream.  It can now compile on a fresh sid.

The patches 0001-missingSigned.patch and gcc5.diff are not necessary any
more, so I removed them, but I left nopsboxit.patch,
link_against_x11.patch and findsip.patch untouched.


I had to disable the building of the binary
source/APPLICATIONS/UTILITIES/assign_positions_from_template, but since
this binary was not previously installed into any package, I don't think
this is a problem.


All patches are taken from github upstream unless explicitly noted, and
I expect they will be included in the next release, but this may help
the Debian package back onto its feet right now.

The attached patch is based directly on master in collab-maint.

Cheers,

- Danny
From 93eb17ca031d7a5d225d8c33feacafe49b2675fb Mon Sep 17 00:00:00 2001
From: Danny Edel <m...@danny-edel.de>
Date: Sun, 10 Apr 2016 11:57:18 +0200
Subject: [PATCH] Rework patches for sid

This fixes FTBFS.  Also, enable tests in d/rules.
---
 debian/patches/0001-missingSigned.patch|  32 --
 .../adjust-PoseClustering_Test-boost-1.58.patch|  13 +++
 .../disable-assign-positions-from-template.patch   |  10 ++
 .../fix-FingerprintSimilarityClustering.patch  |  54 +++
 debian/patches/fix-PoseClustering_Test.patch   |  17 
 ...pilation-of-BinaryFingerprintMethods_test.patch |  81 
 .../fix-poseClustering-with-boost-1.60.patch   | 108 +
 debian/patches/fix-string-gcc5.patch   |  73 ++
 debian/patches/gcc5.diff   |  18 
 debian/patches/series  |   9 +-
 debian/rules   |  12 ++-
 11 files changed, 373 insertions(+), 54 deletions(-)
 delete mode 100644 debian/patches/0001-missingSigned.patch
 create mode 100644 debian/patches/adjust-PoseClustering_Test-boost-1.58.patch
 create mode 100644 debian/patches/disable-assign-positions-from-template.patch
 create mode 100644 debian/patches/fix-FingerprintSimilarityClustering.patch
 create mode 100644 debian/patches/fix-PoseClustering_Test.patch
 create mode 100644 debian/patches/fix-compilation-of-BinaryFingerprintMethods_test.patch
 create mode 100644 debian/patches/fix-poseClustering-with-boost-1.60.patch
 create mode 100644 debian/patches/fix-string-gcc5.patch
 delete mode 100644 debian/patches/gcc5.diff

diff --git a/debian/patches/0001-missingSigned.patch b/debian/patches/0001-missingSigned.patch
deleted file mode 100644
index 6801495..000
--- a/debian/patches/0001-missingSigned.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From: Andreas Hildebrandt <ahild...@uni-mainz.de>
-Date: Tue, 14 Aug 2012 17:14:31 +0200
-Subject: missingSigned
-
-===

- include/BALL/DATATYPE/hashGrid.h |2 +-
- source/DATATYPE/hashGrid.C   |2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
-
 a/include/BALL/DATATYPE/hashGrid.h
-+++ b/include/BALL/DATATYPE/hashGrid.h
-@@ -37,7 +37,7 @@ namespace BALL
- {
- 	namespace __private
- 	{
--		extern const char BALL_EXPORT neighbour_table_[27][3];
-+		extern const signed char BALL_EXPORT neighbour_table_[27][3];
- 	}
- 
- 	template  class HashGrid3;
 a/source/DATATYPE/hashGrid.C
-+++ b/source/DATATYPE/hashGrid.C
-@@ -9,7 +9,7 @@ namespace BALL
- {
- 	namespace __private
- 	{
--		const char neighbour_table_[27][3] =
-+		const signed char neighbour_table_[27][3] =
- 		{
- 			{ 0,  0,  0 }, { 0,  0, -1 }, { 0,  0,  1 },
- 			{ 0, -1, -1 }, { 0, -1,  0 }, { 0, -1,  1 },
diff --git a/debian/patches/adjust-PoseClustering_Test-boost-1.58.patch b/debian/patches/adjust-PoseClustering_Test-boost-1.58.patch
new file mode 100644
index 000..d4cd089
--- /dev/null
+++ b/debian/patches/adjust-PoseClustering_Test-boost-1.58.patch
@@ -0,0 +1,13 @@
+Subject: Adjust boost::archive for boost-1.58 version
+Author: Danny Edel <deb...@danny-edel.de>
+
+The archive format of boost-1.58 (currently in sid) and the
+version 1.60, which the upstream patch is for, only differs
+in the "version" field.
+
+Delete this patch once 1.60 is in sid.
+--- a/source/TEST/data/PoseClustering_wardtree.dat
 b/source/TEST/data/PoseClustering_wardtree.dat
+@@ -1 +1 @@
+-22 serialization::archive 13 0 0 15 14 0 0 1 0 0 1 0.0e+00 1 0 1 1 0.0e+00 1 0 2 1 0.0e+00 1 0 3 1 0.0e+00 1 0 4 1 0.0e+00 1 0 5 1 0.0e+00 1 0 6 1 0.0e+00 1 0 7 1 0.0e+00 0 0 2 2.930124538e-05 0 0 3 1.017511487e+00 0 0 4 2.349177122e+00 0 0 2 9.453108311e-01 0 0 2 1.095688367e-05 0 0 4 5.062472916e+01 0 0 8 5.839497375e+01 8 1 0 0 8 0 9 3 9 8 10 2 10 9 11 7 11 6 12 4 12 5 13 12 13 11 14 13 14 10 14
++22 serialization::archive 12 0 0 15 14 0 0 1 0 0 1 0.0e+00 1 0 1 1 0.0e+00 1 0 2 1 0.0e+00 1 0 3 1 0.0

Bug#820301: ITP: pytest-benchmark -- py.test fixture for benchmarking code

[Danny Edel]

Package: wnpp
Severity: wishlist
Owner: Danny Edel <deb...@danny-edel.de>

* Package name: pytest-benchmark
  Version : 3.0.0
  Upstream Author : Ionel Cristian Mărieș <cont...@ionelmc.ro>
* URL : https://github.com/ionelmc/pytest-benchmark
* License : BSD-2-Clause
  Programming Lang: Python
  Description : py.test fixture for benchmarking code

This plugin provides a benchmark fixture. This fixture is a callable
object that will benchmark any function passed to it.
.
It allows to save and compare timing data to detect speed regressions,
and can output results as svg graphs.

-

I will coordinate with the python-modules-team (in CC) about how
to maintain and upload the packaging.

Bug#816081: dspdfviewer: FTBFS on big-endian architectures (testsuite): 4287168392 != 4294936831

[Danny Edel]

Control: fixed -1 dspdfviewer/1.15-1

With dspdfviewer/1.15-1 uploaded to unstable and the testsuite disabled
on big-endian, it no longer fails to build from source[1], hence the
downgrade of severity and "fixed".

Howver, I'd like to keep the ticket open until the underlying problem is
identified, or alternatively, it is confirmed that this is a false
positive and the program works correctly on big-endian hardware.

[1]: https://buildd.debian.org/status/package.php?p=dspdfviewer



signature.asc
Description: OpenPGP digital signature

Bug#816081: dspdfviewer: FTBFS on big-endian architectures (testsuite): 4287168392 != 4294936831

[Danny Edel]

On Sat, 27 Feb 2016 12:27:44 +0100 Danny Edel <deb...@danny-edel.de> wrote:
> I will investigate further and report back here.

I cannot determine the exact cause why it fails on big-endian emulation.
 Also, trying to load any GUI through the emulator just results in a
blank window, so I cannot even check if the resulting binary is all
right (false-positive).  My best guess is that Qt uses OpenGL to
accelerate drawing, which cannot be emulated correctly, meaning this
could be a test failure without anything being wrong.

As a temporary workaround, I have disabled unittests on big-endian
hardware in v1.15-1 (to be uploaded today), until someone with access to
a hardware machine with X11 can help in checking the exact situation.

[help needed]
If you have a big-endian machine with X11 running, please try executing
the software and check if the resulting UI looks okay or the colors are
messed up -- seeing as how blue was always 0xFF, all output should look
blue-tainted if the test suite diagnosed a problem correctly.

If you want to donate some time to this, you can re-activate the
unittests by appending -DRunUnitTestsOnBigEndian=ON to the
dh_auto_configure call in d/rules.

- Danny



signature.asc
Description: OpenPGP digital signature

Bug#818877: borgbackup: BorgBackup fails to extract files properly

[Danny Edel]

On 03/22/2016 11:26 AM, Nicholas Cheng wrote:
> # Creating a new test backup The backup went well, there was no
> output indicating an I/O error with the --verbose flag on.
> 
> # Mounted the newly created test backup I simply created a folder in
> my home directory named 'test' and mounted the backup. All the files
> in the backup were readable and didn't seem to indicate any
> problems.

Hi Nicholas,

this is good news.  Your backup isn't broken, it's just a matter of the
extraction process.

> # Attempted to extract the test backup I encountered the same errors
> as before, please refer to the attached text file named 'extracting'
> to look at the output and commands I used.

The traceback suggests that the problem occurs during setxattr().  This
would suggest that the files by themselves are complete, please check
that to be sure.

> After submitting the bug report, I did some additional testing by 
> installing Attic, I encountered the same issue with extracting
> backups.

This might indicate a problem with your file system creation and/or
mount options.


You should check if getfattr/setfattr support works when calling
interactively:

getfattr -d ~/test/somefile

setfattr -n user.somecoolname -v somevalue ~/test/somefile

You should normally be able to set anything in the "user.*" namespace.
If the files in your ~/Downloads folder additionally have values outside
of the namespace, that would explain why attic/borg cannot restore them.
 AFAIK writing anything outside the user namespace needs root
permission.  (In this case, please check why they have the attributes in
the first place, and check if restoring with sudo gives the desired result.)


On my ext4 /home file system, I can set user.* attributes and restore
them with borg correctly.  What file system are you using for /home?

Cheers,

- Danny



signature.asc
Description: OpenPGP digital signature

Bug#818877: borgbackup: BorgBackup fails to extract files properly

[Danny Edel]

On 03/21/2016 11:36 AM, Nicholas Cheng wrote:
> Dear Maintainer,
> 
> I installed borgbackup, made a backup of my ~/Documents folder and
> attempted to restore it in another folder I created in my home
> directory. BorgBackup restored a few files before finally stopping.

Hello Nicholas,

I cannot reproduce your problem right now.  Please provide the more
information, like the exact commands you used to backup and restore.

> I looked around the internet and there was little to no mention of a
> similar bug. I've tried removing ~/.cache/borg completely and
> retrying the same procedure.

I remember that it was recently [discovered][1] that under certain
circumstances, disk I/O errors can get silently ignored.  You might want
to check if you're affected by this.  [This comment][2] shows commands
used to create an archive and shows the file lengths being wrong, which
is a symptom of the ignored i/o error on read.

The fix will be included in the next upload.

To check whether your problem is a corrupt backup or during restore,
please try mounting your backup (man borgbackup, section BORG MOUNT) as
a directory and see if the files inside are all right.  If your backup
can be mounted and the files inside are correct, then you are not
affected by the above bug.

> BorgBackup still fails to extract files properly and completely. It
> outputs a few lines of errors (Errno 1 5) before outputting some
> Traceback errors before exiting.

Please post the exact error messages and the full traceback here.  It
would be best if you call borgbackup with --verbose to get a bit more
details of what exactly it was doing when it failed.  If you can, send
the terminal session as a text attachment to avoid any email formatting
or line breaking.  The "script" program from bsdutils package can help
you to create such a transcript file.


Cheers,

- Danny


[1]: https://github.com/borgbackup/borg/issues/748
[2]: https://github.com/borgbackup/borg/issues/748#issuecomment-196586665



signature.asc
Description: OpenPGP digital signature

Bug#818190: /usr/bin/borg VS /usr/bin/borgbackup

[Danny Edel]

On 14/03/16 19:43, Technicien Informatique wrote:
> Hi,
> 
> Is there a reason the borgbackup package installs borg in two 
> different places (/usr/bin/borg & /usr/bin/borgbackup) ?
> 
> I have to say this is a little bit confusing. The documentation says
>  you should call "borg", but your package is named "borgbackup", but
>  then you can you either name.
> 
> I think choosing a side (borg OR borgbackup) and being consistent 
> everywhere would be better.
> 

Hi Technicien,

the package was created as "borgbackup" (not simply as "borg"), and
most™ packages install a binary with the same name as the package.
(Hence the symlink initially)

Personally I find it nice if command names are short and memorable, but
in this case - "borg" already hits 56M Google results - it is possible
that something totally unrelated might produce a name clash in the
future, so even if we drop the symlink now, we might have to re-add and
create conflict or alternative in the future, possibly adding a
"canonical" filename (/usr/bin/borg.borgbackup?).

Also, upstream writes in their README.rst, first sentence:
> BorgBackup (short: Borg) is a deduplicating backup program. 
which makes it feel natural to allow both the shorthand and the full
program name to be called.

Unless there are actual problems having the symlink, I would prefer
not to drop it -- some users will already have used the long name in
their scripts and I prefer not to make backwards-incompatible changes
unless there is a reason to do so.

Cheers,

- Danny



signature.asc
Description: OpenPGP digital signature

Bug#816788: borgbackup-doc: api.html build embeds datetime and i/o charset, thus making package unreproducible

[Danny Edel]

Package: borgbackup-doc
Version: 1.0.0~rc2-3
Severity: wishlist

Currently, the package borgbackup-doc does not build 100% reproducible.

The only problem is api.html, which embeds the current date/time and I/O
charset from the buildd.  The problem occurs when parsing function
default arguments.

The API doc build system tries to evaluate the default argument,
and print the serialized value, rather then copying the initializer
verbatim.

Note that this technically makes the docs wrong (in addition to making
them harder to read), since the program will actually re-evaluate the
initializer at runtime.


Example:

archive.py
> start=datetime.utcnow()

Source:
https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/borg/archive.py?id=73e19357745377abc44c00e38cccf52aaef09273#n135

Possible output:
> start=datetime.datetime(2017, 4, 7, 1, 
> 48, 28, 382881)


to do: Check if there is a sphinx switch to make it copy the
parameter(s) verbatim (the string '=datetime.utcnow()' in this case),
rather than trying to evaluate and serialize them.

Bug#816782: borgbackup: FTBFS on hppa: test-suite fails at ArchiverTestCase.test_basic_functionality

[Danny Edel]

Package: borgbackup
Version: 1.0.0~rc2-3
Severity: serious
Justification: fails to build from source (but built successfully in the past)

On hppa, the borgbackup test suite failed on 1.0.0~rc2-3 [1] but built
successfully on 1.0.0~rc2-1 [2].  This may be a regression in
dependencies, since the during-build testsuite did not change, the only
difference of those versions is in the autopkgtest and fuse in
build-depends, which doesn't have anything to do with the failed test.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=borgbackup=hppa=1.0.0~rc2-3=1457125572
[2]: 
https://buildd.debian.org/status/fetch.php?pkg=borgbackup=hppa=1.0.0~rc2-1=1456923438

Bug#816097: cowbuilder-dist: pbuilder-satisfydepends segfaults when used with qemu-user-static

[Danny Edel]

Package: ubuntu-dev-tools
Version: 0.155
Severity: important

Hi,

I use cowbuilder-dist as a frontend to qemu-user-static, to track down a
build failure on mips.

the commands I used are:

export UBUNTUTOOLS_DEBIAN_MIRROR=http://10.x.x.x:3142/debian

(Note: this is my local apt-cacher-ng.  If I specify it by name,
debootstrap fails to resolve the DNS name, but if I give the IP it
works.  Not sure if this is misconfiguration on my side.)

cowbuilder-dist sid mips create --main-only


But if I try to build dspdfviewer using the "build" command it fails
when trying to set up the dependencies.

dget 
http://http.debian.net/debian/pool/main/d/dspdfviewer/dspdfviewer_1.14-2.dsc
cowbuilder-dist sid mips build dspdfviewer_1.14-2.dsc

(normal output snipped, the last few lines are)

Need to get 35.0 MB/120 MB of archives. After unpacking 550 MB will be used.
Writing extended state information...
/usr/lib/pbuilder/pbuilder-satisfydepends: line 28: 13953 Segmentation fault
  (core dumped) $CHROOTEXEC env XDG_CACHE_HOME=/root aptitude -y 
--without-recommends -o APT::Install-Recommends=false "${APTITUDEOPT[@]}" -o 
Aptitude::ProblemResolver::StepScore=100 -o 
"Aptitude::ProblemResolver::Hints::KeepDummy=reject 
pbuilder-satisfydepends-dummy :UNINST" -o 
Aptitude::ProblemResolver::Keep-All-Level=55000 -o 
Aptitude::ProblemResolver::Remove-Essential-Level=maximum install 
pbuilder-satisfydepends-dummy
E: pbuilder-satisfydepends failed.
I: Copying back the cached apt archive contents
I: unmounting /pbuilder-ccache filesystem
I: unmounting dev/pts filesystem
I: unmounting run/shm filesystem
I: unmounting proc filesystem
 -> Cleaning COW directory
  forking: rm -rf /var/cache/pbuilder/build/cow.12716 


Since "build" is a core functionality of cowbuilder-dist, I
think this qualifies as "important".

Note that the problem is not specific to dspdfviewer as a
package-to-be-built, I get the same segfault when trying to build vim,
or even the hello package, which should have a really small dependency list.



Known workaround:

cowbuilder-dist sid mips login --bindmounts /dir/to/source
apt install devscripts equivs
cd /dir/to/source
mk-build-deps -ir
debuild -b -uc -us



In case I filed this against the wrong package, please redirect
accordingly.  I'm not sure which component actually triggers the
segfault.


Thank you,

- Danny


PS: In case the problem is not reproducible on your machine, please tell
me how to save the core dump from the segmentation fault.  I can't find
it in my ~/pbuilder folder, and I assume it got auto-deleted.


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

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

Versions of packages ubuntu-dev-tools depends on:
ii  binutils   2.26-5
ii  dctrl-tools2.24-2
ii  devscripts 2.16.1
ii  diffstat   1.61-1
ii  distro-info0.14
ii  dpkg-dev   1.18.4
ii  lsb-release9.20160110
ii  perl   5.22.1-7
ii  python 2.7.11-1
ii  python-apt 1.1.0~beta1
ii  python-debian  0.1.27
ii  python-distro-info 0.14
ii  python-httplib20.9.1+dfsg-1
ii  python-launchpadlib1.10.3-3
ii  python-lazr.restfulclient  0.13.4-5
ii  python-ubuntutools 0.155
pn  python:any 
ii  sudo   1.8.15-1.1

Versions of packages ubuntu-dev-tools recommends:
ii  bzr 2.7.0-2
ii  bzr-builddeb2.8.9
ii  ca-certificates 20160104
ii  cowdancer   0.78
ii  debian-archive-keyring  2014.3
ii  debian-keyring  2016.01.20
ii  debootstrap 1.0.79
ii  dput0.9.6.4
ii  genisoimage 9:1.1.11-3
ii  libwww-perl 6.15-1
ii  lintian 2.5.41
ii  patch   2.7.5-1
ii  pbuilder0.223
ii  python-dns  2.3.6-3
ii  python-soappy   0.12.22-1
ii  quilt   0.63-3
ii  reportbug   6.6.6

Versions of packages ubuntu-dev-tools suggests:
ii  python 2.7.11-1
ii  python-simplejson  3.8.1-1
ii  qemu-user-static   1:2.5+dfsg-5

-- no debconf information

Bug#816081: dspdfviewer: FTBFS on big-endian architectures (testsuite): 4287168392 != 4294936831

[Danny Edel]

On Sat, 27 Feb 2016 11:02:00 +0100 Danny Edel <deb...@danny-edel.de> wrote:
> On big-endian architectures, dspdfviewer currently fails to build from
> source.


I can reproduce this with cowbuilder-dist from the ubuntu-dev-tools
package and the qemu-user-static emulator, with a mips chroot.

However, the problem does *not occur on a jessie chroot*.


Since the identical source produces different results on jessie vs. sid,
this may be a regression in one of the third-party libraries linked.

I will investigate further and report back here.

Bug#816081: dspdfviewer: FTBFS on big-endian architectures (testsuite): 4287168392 != 4294936831

[Danny Edel]

Package: dspdfviewer
Version: 1.14-2
Severity: serious
Tags: upstream help
Justification: fails to build from source (but built successfully in the past)

On big-endian architectures, dspdfviewer currently fails to build from
source.

The error messages contain the decimal numbers, but "decoding" them to hex
shows there is most likely an endianness issue somwehere inside:

dec: 4287168392 != 4294936831

hex: FF 88 FF 88 != FF FF 88 FF


dec: 4285537985 != 4280185087

hex: FF 70 1E C1 != FF 1E 70 FF


Explanation:  These colors are normally in ARGB (alpha, red, green,
blue) format.

For monitor pixels, Alpha is always FF (255).

Swapping FF701EC1 gives C11E70FF, setting alpha to FF gives FF1E70FF
which is exactly the created number.


Tag "help":  I do not have access to a real big-endian machine *with* an
X-Server running to discern if this is actually a bug (it would look like
really messed up colors) or a false positive in the test suite.

I will try to reproduce and fix this with emulators like qemu, but this
is of couse a really slow process and not 100% reliable (the emulator
could be adding new endianness problems and/or hide an existing one).

If you have a big-endian machine with X and are willing to help, please
speak up : )


- Danny

Bug#815564: borgbackup: activate unittests during build

[Danny Edel]

On 02/23/2016 07:31 PM, Daniel Reichelt wrote:
> Interesting. On a current jessie (plain + git/master-testsuite-enabled's
> build-deps from bpo) I get an error about python3.4's unittest not
> recognizing arguments from PYBUILD_TEST_ARGS - see attached build.log.
> 
> Which version of libpython3.4-stdlib ends up being used within your
> chroot? (mine is 3.4.2-1)

In my jessie-backports chroot, both jessie and jessie-backports are
available in sources.list.  But the main issue is this:

Quoting build log:

> usage: python3.4 -m unittest discover (...)

This should say python3.4 -m **pytest**, not unittest.  That's what the
'export PYBUILD_TEST_PYTEST=1' in d/rules is supposed to trigger.

The corresponding line in the pybuild source code: (git-blame says it's
there since 2013, so should™ be in jessie, without needing backports)

http://anonscm.debian.org/cgit/dh-python/dh-python.git/tree/pybuild#n396


Can you reproduce the build failure in a freshly created pbuilder?



I created mine with:

DIST=jessie-backports git-pbuilder create

and I checked my build with:

git add -u && \
gbp buildpackage --git-pbuilder --git-dist=jessie-backports \
  --git-export=INDEX --git-ignore-new



Its quite possible there is something™ different with the way you set up
your chroot, but debomatic and git-pbuilder seem to agree with me so far.

Checking the debomatic log, the only dependency it actually pulled from
backports is the msgpack, and it used the rest from jessie(-updates), so
it doesn't seem to be using other backported versions.



I'd love to fix this, but I can't reproduce it here.


Cheers,

- Danny


ps: debomatic log link from Gianfranco

http://debomatic-i386.debian.net/distribution#jessie-backports/borgbackup/1.0.0~rc1-3~bpo8+1/buildlog

Bug#815564: borgbackup: activate unittests during build

[Danny Edel]

On 02/22/2016 06:46 PM, Gianfranco Costamagna wrote:
> (I'm just wondering: is fakeroot installed by default everywhere?)
> at lest with a pbuilder-dist sid login I don't have it, maybe having in 
> build-dependencies
> is better?
> 
> we can add it later if needed, ppa and debomatic seems to have it :)

Hi Gianfranco,

Good call, I missed that one - my pbuilders (created via git-pbuilder)
all had it when I was building borgbackup.

It's only "Recommended" by dpkg-dev, which itself is part of the
build-essential set.  So to be sure it's there, we should build-depend
on fakeroot explicitly before we upload.  Better safe than sorry.

This may be a bug in git-pbuilder, that it *does* install Recommended
packages - AFAIK the pbuilder's should only ever install hard depends,
and ignore Recommended and Suggests.


"aptitude why fakeroot" answers me:

i   borgbackup-build-deps Dependsdebhelper (>= 9)
i A debhelper Dependsdpkg-dev (>= 1.18.2~)
i A dpkg-dev  Recommends fakeroot


-


Uploading to delayed/2 should™ be fine, but just to ensure that the
current version actually migrates to stretch, maybe make it delayed/3.


Cheers,

- Danny

Bug#815564: borgbackup: activate unittests during build

[Danny Edel]

Package: borgbackup
Version: 1.0.0~rc1-2
Severity: wishlist
Tags: patch

Hi Gianfranco, hi Daniel,

I want to re-activate the testsuite of borgbackup, but without the
problems that occured the last time, so I CC'd both of you, I hope
that's all right.

I have prepared a patch, and verified it against a jessie-backports
cowbuilder, but I'm not merging it into master without checking in
with you this time : )

You will find the branch at the collab-maint repository as
"master-testsuite-enabled".  Direct link to graphical diff:

https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/diff/?h=master-testsuite-enabled=master=master-testsuite-enabled

Gianfranco, could you check that merging this doesn't make any problems
with the Ubuntu port, and Daniel, could you verify there are no problems
with jessie?

If both come in as OK, I'd merge this as 1.0.0~rc1-3, but only after -2
has finished testing migration, which should happen on 2016-02-23 or -24.


My motivation for activating the testsuite is to ensure that the
libraries in Debian are compatible with the ones upstream expects --
this will get more relevant for stable-backports, once sid is 1-2 years
different from stable.
In general, I'd rather get errors at build time than from users after
they upgrade their machine, and running the upstream test suite seems
like a good start into this direction.


Cheers,

- Danny

Bug#814853: borgbackup: borg create --stats doesn't output stats

[Danny Edel]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/borgbackup/borg/issues/669


On Tue, 16 Feb 2016 13:11:19 +0100 Danny Edel <deb...@danny-edel.de> wrote:
> I have forwarded this to the upstream bugtracker.

Since the program works as documented in the manpage, the behaviour will
not be changed, but upstream will refresh the screencast, and also split
it, so that users of distribution packages can directly access the
"usage" part.

Upstream assigned a fresh issue number 669 to the screencast update.

Bug#814058: borgbackup: FTBFS on jessie: wrong build-deps and failing unittests

[Danny Edel]

Hi Daniel,

1.0.0~rc1 is in Debian unstable now, with the testsuite deactivated for
now.  If there are no issues, it'll reach stretch in five days.  If any
changes are required to accomodate for the jessie backport, a heads-up
would be appreciated, so we don't have to wait for the testing migration
twice.  Otherwise, if those changes fix your problem, feel free to mark
the bug as closed.

Regarding coordination, I'm happy enough with the debian bugtracking
service and the github tracker for upstream-relevant stuff, so unless
there's a specific reason to implement (and maintain) another system,
I'd prefer to stick with those.

Cheers,

- Danny

Bug#814581: dspdfviewer: FTBFS: Errors while running CTest

[Danny Edel]

Control: block -1 by 814607

Hi,

since it seems to be not just dspdfviewer's test suite, but any qt5
program (even the qt5 examples) that brings the "Floating point
exception" when run via xvfb-run, I have reported a bug against the xvfb
package.

Until this is fixed or a workaround known, we cannot use xvfb-run to
execute the test suite.

[upstream hat on] I'm thinking about reworking the Xvfb based
environment to something more feature-complete, that can emulate two
screens so I can test things like window alignment and screen-switching
under the supported window managers.

[Debian hat on] If I can't find a way to fix this, I'll probably have to
disable the testsuite for Debian builds temporarily.

Cheers,

- Danny

Bug#814853: borgbackup: borg create --stats doesn't output stats

[Danny Edel]

Control: forwarded -1 https://github.com/borgbackup/borg/issues/665

On 02/16/2016 01:37 AM, Mike Hommey wrote:
> Dear Maintainer,
> 
> See the screencast from 
> https://asciinema.org/a/28691?autoplay=1=2
> 
> See what output adding --stats should be presenting. It doesn't 
> happen, neither in the version in unstable, nor in the version in 
> experimental.

Hello Mike,

thank you for reporting this.

I can confirm the behaviour is inconsistent with the screencast, but the
manpage provides a clue here:

Quoting "man borg":

> WARNING:
> 
> While some options (like --stats or --list) will emit more 
> informational messages, you have to use INFO (or lower) log level to 
> make them show up in log output. Use -v or a logging configuration.


I have forwarded this to the upstream bugtracker.

Cheers,

- Danny

Bug#814607: xvfb-run crashes with "Floating point exception" when trying to run qt5 example programs

[Danny Edel]

Package: xvfb
Version: 2:1.18.1-1
Severity: important
Control: fixed -1 2:1.18.0-3

Dear maintainer,

after running the testsuite from my package failed with the xvfb version
currently in sid, I found that the same problem also happens with the qt5
examples, so it may be a bug in the new xvfb version.

I am assuming this affects any application with a Qt5 gui component, so I
believe this qualifies as "important".

I hope I set the pseudo-headers above correctly to "The version in
stretch is not affected, but sid is", please correct it if I did it
wrong.

--- How to reproduce ---

1. install xvfb xauth qtbase5-examples, all from sid
2. run xvfb-run -a 
/usr/lib/x86_64-linux-gnu/qt5/examples/gui/analogclock/analogclock

Result: Immediately outputs "Floating point exception" and dies

--- Known Workaround ---

3. Add stretch to sources.list
4. apt install xvfb/stretch
5. repeat above xvfb-run command

Result:  Lots of warnings about the painter not being active, but no
"floating point exception" like with the sid version.  Program seems to
run, and has to be CTRL-C'd to quit.
(Also, with the xvfb version in stretch, my test suite passes, so it
seems to be operating normally.)


Thank you for maintaining xvfb,

- Danny

Bug#814581: dspdfviewer: FTBFS: Errors while running CTest

[Danny Edel]

Control: merge 814579 814581

On 13/02/16 09:41, Chris Lamb wrote:
> Dear Maintainer,
> 
> dspdfviewer fails to build from source in unstable/amd64:

Hello Chris,

thank you for reporting this.  I have deduced that the most likely
reason is the switch xorg 1.17->1.18.  I am investigating how to fix
this.  The test output "Floating point exception" seems to suggest this
is quite a low-level error.  (The same source builds fine against sid
snapshots from before the xorg 1.18 merge)

I will report back on this issue here, just ignore the other one I opened.

- Danny



signature.asc
Description: OpenPGP digital signature

Bug#814579: dspdfviewer: FTBFS with xorg-1.18: Testsuite fails with floating point exception

[Danny Edel]

Source: dspdfviewer
Version: 1.14-2
Severity: serious
Justification: fails to build from source (but built successfully in the past)

After xorg got bumped to 1.18 in unstable, the testsuite started failing
with "floating point exception" on the parts where xvfb-run is used to
emulate a GUI.

The Qt5 build worked in unstable before the xorg 1.18 bump, so the
package testsuite will need to be adapted to the new version.

-- System Information:
Debian Release: 8.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

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

Bug#812885: general: Bluetooth doesn't work

[Danny Edel]

On 01/27/2016 04:49 PM, justysia wrote:
> [12.695075] bluetooth hci0: firmware: failed to load 
> brcm/BCM43142A0-4ca-2009.hcd (-2)
> Please help me fix it.
> Best regards,
> Justysia

Hello Justysia,

I had the same problem on an Acer Notebook that came with this card
pre-installed.

If you cannot find the firmware in the hcd format (it's probably not
legal to distribute on the internet, so I wouldn't be surprised if it's
hard to find), but still have the windows driver CD that came with the
laptop, you can convert the .hex file on there to the .hcd format.

On the laptop I installed (BCM43142, 04ca:2009) the firmware was called
BCM43142A0_001.001.011.0197.0211.hex on the windows CD.

I used Jesse Sung's hex2hcd utility from
https://github.com/jessesung/hex2hcd to convert, and moved it to the
filename mentioned in the error message /lib/firmware/brcm/xxx.hcd -
maybe that works for you too.



d-devel readers:  Would it be possible for Debian to distribute the
resulting file as part of a broadcom firmware package?  Firmware for
their wireless lan chipsets is already distributed in a similar manner.


Cheers,

- Danny

Bug#777791: [PATCH] ball: ftbfs with GCC-5

[Danny Edel]

Hello Andreas,

I have had some spare time and spent it on the ball package.  I hope
that helps you in getting the package back into Debian.

Some notes regarding the patch:

* I dropped the gcc5.patch, since it created an ambiguous overload of
getline -- Upstream added one themselves in the meantime.

* The patches in debian/patches/backports/ are all cherry-picked from
the upstream git repository at github.com/BALL-project/ball -- their
first line will tell you the commit ID.  Take a look at the branch
qt5_latest if they are not yet in master.
They were created with git format-patch -1 , I hope that's all
right.

* The most problematic part was DOCKING/COMMON/poseClustering.h.  It
seems to break with boost-1.56, because it assumes a certain class is
copyable that has been adapted to c++11's "move" idea.
The commit that breaks it is
https://github.com/boostorg/graph/commit/cb26ccf

I have used a very crude workaround (I have defined a BOOST_* symbol
suggesting that the compiler would not support moves), this needs to be
properly ported to current boost by BALL upstream.  Please try to get in
contact with upstream, and have them properly port the code.

* The upstream code is also not yet ready for libeigen3 version 3.3
(currently in beta) that drops some compatibility code.  I added a
Build-Conflicts to make the buildd's aware of that.  This also needs to
be ported by upstream.

In order to build the package anyway, I had to add to my sources.list a
snapshot.debian.org containing the older version (its header-only, so
it's compiled into the binary and does not generate a run-time
dependency).  sources.list line containing a suitable old version:

deb http://snapshot.debian.org/archive/debian/20150924T154447Z sid main



* I activated the test suite in d/rules -- mainly because I was not sure
if my crude workaround broke anything.
On my test builds, the Socket_test sometimes™ failed.  Maybe there is a
race condition, I don't know.  Could also be my old hardware bitrotting
away...

* Since I used the older libeigen, I set it as a "system" library in
cmake, which prevents the compile log from generating warnings when
eigen uses deprecated features  (just distracted me while working on
ball, feel free to drop that patch).


The patch is based against b915af8eff, which was today (jan 26) the
current master in the debian-med repository.


After all this hacking, the package builds and the resulting .deb's seem
usable to me, but I dont understand enough biochemics to make anything
out of it : )


I can't tell myself if the patch is of acceptable quality, please have a
look over it before adopting.  Feedback would be much appreciated, this
is my first non-trivial contribution.


I hope this helps,


- Danny
diff --git a/debian/control b/debian/control
index ceb15db..2b09efd 100644
--- a/debian/control
+++ b/debian/control
@@ -39,6 +39,7 @@ Build-Depends-Indep: doxygen,
  texlive-latex-recommended,
  texlive-fonts-recommended,
  texlive-latex-extra
+Build-Conflicts: libeigen3-dev( >= 3.3~ )
 Standards-Version: 3.9.6
 Vcs-Browser: https://anonscm.debian.org/cgit/debian-med/ball.git
 Vcs-Git: git://anonscm.debian.org/debian-med/ball.git
diff --git a/debian/patches/adapt-poseClustering-test-archive-boost1.58 b/debian/patches/adapt-poseClustering-test-archive-boost1.58
new file mode 100644
index 000..c5349c0
--- /dev/null
+++ b/debian/patches/adapt-poseClustering-test-archive-boost1.58
@@ -0,0 +1,10 @@
+Subject: Adapt archive version number to 12 (boost1.58)
+
+The upstream boost::archive file was most likely compiled against a more
+recent (version no. 13) serialization library, but boost1.58 (currently
+highest in Debian) only has version no. 12
+--- a/source/TEST/data/PoseClustering_wardtree.dat
 b/source/TEST/data/PoseClustering_wardtree.dat
+@@ -1 +1 @@
+-22 serialization::archive 13 0 0 15 14 0 0 1 0 0 1 0.0e+00 1 0 1 1 0.0e+00 1 0 2 1 0.0e+00 1 0 3 1 0.0e+00 1 0 4 1 0.0e+00 1 0 5 1 0.0e+00 1 0 6 1 0.0e+00 1 0 7 1 0.0e+00 0 0 2 2.930124538e-05 0 0 3 1.017511487e+00 0 0 4 2.349177122e+00 0 0 2 9.453108311e-01 0 0 2 1.095688367e-05 0 0 4 5.062472916e+01 0 0 8 5.839497375e+01 8 1 0 0 8 0 9 3 9 8 10 2 10 9 11 7 11 6 12 4 12 5 13 12 13 11 14 13 14 10 14
++22 serialization::archive 12 0 0 15 14 0 0 1 0 0 1 0.0e+00 1 0 1 1 0.0e+00 1 0 2 1 0.0e+00 1 0 3 1 0.0e+00 1 0 4 1 0.0e+00 1 0 5 1 0.0e+00 1 0 6 1 0.0e+00 1 0 7 1 0.0e+00 0 0 2 2.930124538e-05 0 0 3 1.017511487e+00 0 0 4 2.349177122e+00 0 0 2 9.453108311e-01 0 0 2 1.095688367e-05 0 0 4 5.062472916e+01 0 0 8 5.839497375e+01 8 1 0 0 8 0 9 3 9 8 10 2 10 9 11 7 11 6 12 4 12 5 13 12 13 11 14 13 14 10 14
diff --git a/debian/patches/backports/FingerPrintSim-Fix-build.patch b/debian/patches/backports/FingerPrintSim-Fix-build.patch
new file mode 100644
index 000..4f1eeec
--- 

Bug#812451: borgbackup: Mixing archives created by an unpriviledged user and root inside a single repository

[Danny Edel]

On 01/23/2016 09:42 PM, Vincent Blut wrote:
> mix archives created by an unpriviledged user and
> root inside a single backup repository… and it seems borg doesn’t
> like that experiment. :-)
> 
> PermissionError: [Errno 13] Permission denied:
> '/mnt/backup/lamella/data/0/6148'
> 
> Platform: Linux lamella 4.3.0-1-amd64 #1 SMP Debian 4.3.3-5
> (2016-01-04) x86_64 Linux: debian stretch/sid   LibC: glibc 2.9 
> Python: CPython 3.5.1+
> 
> I did not investigate this issue closely, but I guess it happens when
>  borg tries to deduplicate data but can’t access the chunk in
> question
> 
> Your opinion?
> 
> Cheers, Vincent


Hi Vincent,

as Gianfranco already posted I don't think this is an issue with borg.

On my system, root's umask is 0022, meaning files get created rw-r--r--
by default, forbidding users to open them for writing.  (I had it on
0077 once, was "fun"…)

Try to reproduce the following:


root# touch /testfile
user$ echo foo >> /testfile
(should give permission denied error)
root# rm /testfile

root# umask 
root# touch /testfile
user$ echo foo >> /testfile
(should work)


If that is the case (and root+user are the only ones accessing the
backup directory) maybe you can try to incorporate umask  into your
root's call of borg, and see if it works as planned.  (Note that root
will always be able to write to user-owned files, so changing user's
umask won't be necessary)

If you have more than one user, you will need to setup file ACLs so that
each of them has write access to files and directories, no matter who
created them.  IIRC file ACLs will override the simple unix
user/group/world permission bits, so the umasks should not matter
anymore.  But dont ask me about how exactly that ACL magic works ^^  Try
searching for "facl" on the webs, maybe someone has a good starting
point out there.


Cheers,

- Danny

Bug#811350: apt-cacher-ng: Cronjob fails when a proxy is set for downloads

[Danny Edel]

Package: apt-cacher-ng
Version: 0.8.8-1~bpo8+1

Dear Maintainer,

I am getting this message from my apt-cacher-ng cron job:

/etc/cron.daily/apt-cacher-ng:
Error: cannot fetch
http://localhost:3142/acng-report.html?doExpire=Start+Expiration=aOe,
HTTP/1.0 404 Not Found

If I log in on the machine, and try to fetch the URL with curl, it works
just fine, but if I execute /etc/cron.daily/apt-cacher-ng I get the same
error message as above.

I checked with strace -f -e connect /etc/cron.daily/apt-cacher-ng and it
sends the request to the upstream proxy server that apt-cacher-ng uses
to access the Debian mirror.


If I comment out the Proxy: line in /etc/apt-cacher-ng/zz_debconf.conf
the expiration task starts normally.


I am not sure if it's intended behaviour that the expiration task uses a
proxy to connect back to the machine running apt-cacher-ng, so I'm
filing this bug report.


I am using the version in jessie-backports repository, in case that is
relevant.


Thank you,

- Danny

Bug#810534: borgbackup backport to jessie

[Danny Edel]

Hi Antoine,

Now that borgbackup is clear to enter and stay in testing again, it may
be time to revisit the backport to stable : )

On 01/09/2016 04:57 PM, Antoine Beaupré wrote:
> from what i understand, there are two dependencies that need to be
> backported:
> 
>  * setuptools-scm: backported by Gianfranco already, but out of date
>(1.8 backported vs 1.10 in stretch)

I don't think that this is a showstopper.

According to setup.py[1] borgbackup only requires 1.7 (this is mirrored
to d/control Build-Depends), which is satisfied already in jessie-backports.


[1]:
https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/setup.py?id=dc168cf8cc7f50870dd1aca8c2329660a7017f4f#n260

>  * python3-msgpack: backport missing. zigo contacted, said he would
>backport himself. i'll open a bug report about this on msgpack to
>track that

Is there any news on this?  I tested a no-change-rebuild in a
jessie-backports pbuilder (seemed to go fine, but I don't know how to
correctly verify that), and was able to compile borgbackup with the
resulting package.

Right now borgbackup-doc built this way has privacy breach (loads
javascripts from external url when browsing local doc), which does not
happen when building it on sid.

Any thoughts?


Cheers,

- Danny

Bug#809136: borgbackup: Mention API incompatibilities in README

[Danny Edel]

Hi Antoine,

On 01/13/2016 07:50 PM, anar...@debian.org wrote:
> The readme is not quite accurate: *some* borg versions are actually
> compatible across the network. It's only on the 0.29 boundary that there
> is a problem.

Is this[1] wording acceptable?  Then I would prepare it for upload as
0.29.0-3, closing the bug.

> It also refers to a non-existent backport, but i guess we can trust this
> will come to fruitition soon. :)

I was hoping that too, so this may be a bit optimistic.  But I hope in
case there is none, a user would report this as a bug (i.e. communicate
with us) rather than installing in a non-managed directory.

Cheers!

- Danny


[1]:
https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/commit/?id=9f41b18ac0e53153cba88f8d5ae3b8ef21ae23fb

Bug#777791: ball: ftbfs with GCC-5

[Danny Edel]

Hello Andreas, hello list(s),

I tried to reproduce this build failure on a current sid and investigate
a bit.  On my machine it outputs the same basic error messages (although
the line numbers in the basic_string template file are a bit different).

I try to quote the error message partially so it becomes a bit clearer
what is really going on:

On 01/07/2016 01:12 PM, Andreas Tille wrote:
> /build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC: In member function 
> 'BALL::String& BALL::String::insert(BALL::String::const_iterator, 
> std::initializer_list)':
> /build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC:1379:19: error: no 
> matching function for call to 
> 'std::__cxx11::basic_string::insert(BALL::String::const_iterator&, 
> std::initializer_list&)'
>   str_.insert(p, li);
>^

(...)

Info:
BALL::String::const_iterator is a typedef for std::string::const_iterator


> /usr/include/c++/5/bits/basic_string.h:1308:7: note: candidate: void 
> std::__cxx11::basic_string<_CharT, _Traits, 
> _Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, 
> _Alloc>::iterator, std::   initializer_list<_Tp>) [with _CharT = 
> char; _Traits = std::char_traits; _Alloc = std::allocator; 
> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator = 
> __gnu_cxx::__normal_iterator; 
> typename __gnu_cxx::__alloc_traits __gnu_cxx::__alloc_traits<_Alloc>::rebind<_CharT>::other>::pointer = char*]
>insert(iterator __p, initializer_list<_CharT> __l)
>^
> /usr/include/c++/5/bits/basic_string.h:1308:7: note:   no known conversion 
> for argument 1 from 'BALL::String::const_iterator {aka 
> __gnu_cxx::__normal_iterator 
> >}' to 'std::__cxx11::basic_string::iterator {aka 
> __gnu_cxx::__normal_iterator}'


In essence this says:

(1) No matching function for
string::insert(string::const_iterator, initializer_list),

because (when trying the correct overload),
(2) Cannot convert from string::const_iterator to string::iterator


Which raises the question: Why does the compiler try to convert to a
non-const-iterator in the first place?

According to both cplusplus.com[1] and cppreference.com[2] the insert
function with an initializer_list as second parameter should take a
*const_*iterator directly.

I have condensed this into a simple test case (see attached string.cc)
and for me, this testcase fails in the same way as ball when called with
GCC.

Try it like this:

g++ -std=c++11 string.cc -o string && ./string
(long error message)

Now, with clang++ this fails too:

clang++ -std=c++11 string.cc -o string && ./string
(a bit shorter error message, but essentially the same)

However, if I try the example using clang's STL implementation (from
debian package libc++-dev) it builds *and runs* as expected:

clang++ -std=c++11 -stdlib=libc++ string.cc -o string && ./string
(outputs "Some new string")


I am not sure how to continue from here - this might be a bug in clang's
or gcc's std::string implementation, unportable usage from upstream, or
any number of other things.  If you have access to other compilers, it
may help to test the snippet on them too and report the results.

For reference:

$ g++ -dumpversion
5.3.1

-> Does not compile, cannot convert const_iterator->iterator
-> libstdc++-5-dev 5.3.1-5

$ clang++ -dumpversion
4.2.1

-> Does not compile with default/gcc STL implementation
-> Compiles and runs with libc++-dev 3.7.0-1


I hope this helps in resolving this, or at least in figuring out *where*
the issue actually is located.

- Danny


[1]: http://www.cplusplus.com/reference/string/string/insert/
[2]: http://en.cppreference.com/w/cpp/string/basic_string/insert
#include 
#include 

using namespace std;

int main(){
	string s = "Somestring";
	string::const_iterator ci = s.cbegin()+4;
	initializer_list il = { ' ', 'n', 'e', 'w' , ' ' };
	s.insert(ci, il);
	cout << s << endl;
	return 0;
}

Bug#809136: borgbackup: Mention API incompatibilities in README

[Danny Edel]

Hello everyone,

after our discussions and the clarifications from anarcat, it seems that
the only sensible way to solve this is by trying to inform the end-user
as much as possible to help her/him make an informed decision whether
they should use the 0.x software or wait for the 1.0 version.

On future compat-breaking updates, I will take care to copy any relevant
parts from upstream changelog to a NEWS.Debian file, to make sure they
pop up during installation / get e-mailed to the admin, although that
does of course not cover new installations.

I have already split the Debian-READMEs into source[1] and end-user[2]
and I tried to find a sensible wording for both.

If you have better ideas, send patches!  (feel free to spawn new
branches on the collab-maint repository)


Under the assumption that the enduser can be expected to at least read
README.Debian, (upstream) README.rst, and NEWS.Debian upon updates, I
believe that it should be appropriate to post stuff there.


Please state whether you think this (write README and hope user actually
reads it) is an appropriate solution to the compatibility problem,
meaning we could close the bug this way.


Cheers

- Danny


[1]:
https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/debian/README.source
[2]:
https://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/debian/README.Debian

Bug#809136: Block borgbackup migration to stable for now

[Danny Edel]

Hello Antoine,

thank you for your detailed answer.  I will try to address inline.

On 01/08/2016 10:45 PM, Antoine Beaupré wrote:
> Borg has actually shown great API stability since it forked from
> Attic. The change that occured was necessary, and was well documented
> in the release notes and the manual. (It should have been documented
> in the NEWS.Debian file in the Debian package as well.) It is also the
> *only* one that happened in over 15 releases since the fork from
> Attic. We can even still convert older, prehistoric attic repositories
> to borg without data loss.

My statement that borgbackup does not make any compatibility guarantees
was a quote taken from the top-level README.rst (near the bottom of the
file), not by inspecting the actual source code history.  If it is no
longer accurate, you might want to update that paragraph in the upstream
README, since this statement reads very different.

I apologize if I made the wrong conclusions, and I think we can find a
good solution to this.

> Furthermore, this only concerns the backup remote RPC protocol. The
> storage format is *still* compatible, all the way back to attic. If
> you have a copy of your repository, you can still backup to and from
> it. If your server is upgraded, it is true that you do need to upgrade
> your client, however (and vice-versa).

Thank you for the clarification, I will include this in README.Debian
and (in future releases, if there is another incompatiblity) in a
NEWS.Debian.

> But tons of backup software in Debian have that behavior: unison was
> already mentionned, but rdiff-backup also has the same problems. That
> is why we have backports: when the server side upgrades, we upgrade
> the clients to the backports version. It's annoying, but it works, and
> rdiff-backup has been in Debian for a long time. Those other backup
> softwares are way more popular, sometimes by orders of magnitude, than
> borg:

I understand this solves the issue about writing to a new
(testing/unstable) server with an old (stable) client.  I know this is
irrelevant if borg-1.0 gets released before stretch (which I hope it
does), but can you clarify how borg does/will handle "old server, new
client"?

> Keeping borg from entering stable (or, more precisely, testing in this
> case) is exactly what we *don't* want here. If we keep borg from
> entering testing, we keep it from being backported. If we keep it from
> being backported, we make it *harder* for people to run the same
> version of borg across different versions of Debian. So we basically
> make the Debian package useless, which means people won't use it and
> will instead use the pip version.
> 
> Is that what we want?

Very good point.  No I don't want to end up there.  On a Debian system,
the installed software should be managed by apt/dpkg.

> I was looking at backporting borg from stretch to jessie, but if the
> maintainers are going to remove it from stretch, i'm certainly not
> going to bother, and that would be a shame...

A backport would be really nice to have, so please don't give up on this
yet.  In essence, all I want is a solution on how to ensure that users
don't get surprised.

> Finally, keep in mind that this is a problem only in Debian, and only
> if we have multiple, incompatible versions of borg in
> Debian. (Non-debian installs can use virtualenvs to install as many
> borg versions as they want.) Right now, we only have one version
> (0.29.0-2), and it's compatible between unstable and testing. If
> testing gets released right now, stable, testing and unstable are all
> compatible, and we have absolutely no problem.

Agreed.  Currently there would not be a problem, but it will be one when
upstream releases another API-breaking release.  The main point of this
ticket is to figure out how to be prepared for that next time it happens.

> Furthermore, it's very likely that borg 1.0 gets released before
> stretch, so all those arguments will be completely irrelevant because
> borg *will* be API stable.

Yes that would be perfect.

> 
> This, in short, is a non-isse right now. If 0.28 was in stable and
> 0.29 in testing, this would be a bug, but then the fix would be a
> backport, not a removal from stable (which you can do, if you are
> really stuck, anyways).
> 
> Now, can i open this bug about backporting? :)
> 
> a.

Let's resolve this situation first and close this bug (so the
testing-autoremoval is disabled), then create the backport.

Let me try to summarize to check if I understood you correctly:

1. The incompatibility warning from README only affects the network
communication between different versions, not the on-disk format
2. Borgbackup already makes the "read back your old backups with a new
software version" promise, all the way back to attic repositories.
3. By using your backport, #1 will be solvable by the enduser directly
without having to resort to non-apt-managed software installation.

#1 would in my opinion downgrade this ticket from 

Bug#809136: Don't migrate borgbackup to Debian stable

[Danny Edel]

Control: retitle -1 Block borgbackup migration to stable for now

Hello everyone,

I have thought a lot about this situation and I still think that
blocking migration to stable *for now* is the sensible solution.  I do
not want to remove borgbackup from Debian, or keep this blocker alive
indefinitely, just to clarify that.


The "opener" of this ticket was the situation that you cannot connect to
a borgbackup-0.28.0 server with a borgbackup-0.29.0 client or the other
way around.  This alone - as David pointed out - should not normally
qualify for a blocker.

Solving this issue in the way upstream suggests (having a borg-0.28 and
a borg-0.29 command) would require changing installation paths so that
both versions could coexist, and adding versioned binary names.  While
some work, that is not impossible, however it would still need
"backports" of the old client versions to the current Debian sid, which
may get a bit complicated and difficult to maintain.


Now please keep in mind that borgbackup is *a backup software*.  Users
generally trust backup software with their most important data (we keep
saying "make backups" for a reason) and even though the QA department
says they should, most users don't test continually whether they can
actually restore the backup with each new version of the backup software.

I do not know if this is general consensus, but personally I would
expect from any backup software included in Debian stable, that I can
restore my data using the newer version in the next Debian stable.  If a
backup software does not qualify for that criteria, I would expect to be
actively warned (versus requiring me to read the changelog) before I
install/use it.

Borgbackup currently does not meet that standard.  In fact, they state
"Expect that we will break compatibility repeatedly (...) like when
going from 0.x.y to 1.0.0" on their front page in all-caps.  You can
read some discussion about backwards-compatibility in upstream issue #1
on github.

I think it's safe to assume that once borgbackup reaches milestone
1.0.0, they will care a lot about (at least read-only) on-disk backwards
compatibility, and maybe even RPC compatibility between 1.x and 1.y
client/server.  So this would be the time when I personally think it's
ready for Debian stable.


While it could be argued that with the same reasoning it should not be
in Debian at all, I think having the package in unstable is actually
beneficial both to Debian users and upstream development.

I assume that a Debian *unstable* user is aware of the fact that this is
relatively new software, and that a large portion of "unstable" userbase
are developers and early adopters, that are willing to try new things
out and submit helpful bugreports and feature requests.  This kind of
feedback can be very beneficial to upstream, and since those users will
regularly update to the newest version, the backward-compatibility issue
is not as present here.


In essence, my main issue here is keeping up the high quality that users
expect from a Debian stable.  So unless we find some way to ensure users
have read (and acknowledged) a statement about (non-)compatiblity before
they install it, I don't think it should migrate into Debian stable
until upstream starts to make that promise.



This has been a rather long message, but I hope it clarifies the
reasoning why I belive this is a blocker for stable migration.  As
always, discussion is appreciated and maybe someone has an idea or a
solution I have not yet thought of.


Thank you in advance,

- Danny

PS: Please don't CC me in replies, being co-maintainer I am subscribed
to the bug.

Bug#809136: probably not suitable to be packaged in debian

[Danny Edel]

On 12/27/2015 02:42 PM, Marc Haber wrote:
> The workaround suggested by upstream seriously is to have all
> incompatible versions of the server installed and having the client
> choose which server to use.
> 
> So debian would need to have a borgbackup-0.28 package and a
> borgbackup-0.29 package and all incompatible API versions
> simultaneously since it is extremely unlikely that Debian unstable,
> testing and stable will have compatible versions of borgbackup and
> that one surely will want to back up unstable systems to a stable
> server or vice versa.


Hello Marc,

I doubt that it would work just that easy, since these packages would
(without deviating from upstream) not be co-installable because of path
conflicts, so in the plausible use case that you want to share a stable
server with an unstable and a stable client, you'd have to keep deleting
and re-installing borgbackup between the version in stable and the
backport of the newer version.  That does not sound like a viable
solution to me.  (Manually installing the other versions into a
non-dpkg-managed directory does not count either)

I do agree that this is a serious problem, and if Gianfranco (cc'd) does
not have any objections, we should define this bug to a severity level
that prevents a migration to Debian stable until upstream decides on a
stable API and file format version, which probably won't come before the
1.0 release.  I personally don't see a problem with having it in debian
"unstable" until then (since its users will upgrade regularly), but we
should maybe stop further migrations or even ask for a removal from
testing until this is resolved.

Gianfranco, what do you think about the situation?


Cheers,

- Danny

Bug#807564: digikam: FTBFS, cannot find Marble

[Danny Edel]

Hello List,

I'm looking into this aswell, since I want to use digikam again and got
some free time to fix it.  I hope I can provide a source-patch in the
next few days that allows the currently packaged version of digikam to
build again.

In case I get it to work, where do I send the patch?  It would affect
both #807564 and #802966 since they both say FTBFS (although for
different reasons).

Cheers,

- Danny

Bug#807564: Fix "Can't find marble" FTBFS [patch]

[Danny Edel]

Control: tags -1 patch

Hi List,

I've tried to reproduce the build failure and it turns out that the
FindMarble.cmake file is in a path that is not in the default cmake
module search path.

If the search path is passed to cmake with EXTRA_CMAKE_ARGS, digikam
compiles successfully again.

Also the libsoprano-dev dependency is no longer a problem, because
digikam build-depends on kdelibs5-dev, which (now?) depends on
libsoprano-dev.

I hope that helps in at least building digikam again, making it easier
to look into the other remaining tickets.

PS: If you test the patch locally, don't forget to increment digikam's
version number! libstdc++6 in sid has a "Breaks: digikam-private-libs"
on versions <= 4:4.4.0-1.1+b2 defined.


I must add that although it compiles, it does *not* start out-of-the-box
on my system, it now crashes with the following error message:

*** Error in `digikam': realloc(): invalid old size: 0x00c21f80 ***
Aborted


Maybe someone with more C debugging skills can look into that?  (or
maybe it is an issue with my system)


Cheers,

- Danny
diff -ru orig/digikam-4.4.0/debian/rules digikam-4.4.0/debian/rules
--- orig/digikam-4.4.0/debian/rules	2014-01-18 00:19:58.0 +0100
+++ digikam-4.4.0/debian/rules	2015-12-13 14:39:07.711699472 +0100
@@ -12,6 +12,9 @@
   EXTRA_CMAKE_ARGS += -DDIGIKAMSC_USE_PRIVATE_KDEGRAPHICS=OFF
 endif
 
+# Location of FindMarble.cmake
+EXTRA_CMAKE_ARGS += -DCMAKE_MODULE_PATH=/usr/share/marble/cmake
+
 %:
 	dh $@ --with kde --parallel 
 

Bug#806803: does not build twice in a row

[Danny Edel]

On 12/01/2015 05:50 PM, Marc Haber wrote:
> Package: borgbackup
> Version: 0.28.2-1
> Severity: important
> 
> Hi,
> 
> when invoking debuild in the same source tree twice, the second try
> fails with "unrepresentable changes to source". debian/rules clean
> should return the package in the complete pre-build state so that the
> build can begin again. This makes debugging packages tremendously
> easier than having to unpack over and over again.
> 
> Severity: important since this is the usual severity for "fails to
> build twice in a row" bug reports.
> 
> Greetings
> Marc
> 

Hello Marc,

thank you for reporting this.  I'll look into it and patch the d/rules
clean-target.

In the meantime, you can use git-buildpackage's [export] feature as a
workaround, making it a bit more user friendly to use scratchpad
directories.

Something along the lines of
git add -u && gbp buildpackage --git-export=INDEX --git-ignore-new
should work (called from the collab-maint/borgbackup.git clone)

Cheers,
Danny

[export]:
http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.building.html#GBP.BUILDING.EXPORT

Bug#806561: borgbackup: The borg man page should mention it was written by Debian

[Danny Edel]

On 11/29/2015 12:10 AM, Gianfranco Costamagna wrote:
> sure, I like this too, but only when some brain is added, not when the stuff 
> is a result
> of some magic command :D
> 

Hi everyone,

for reference: The new "magic command" basically calls the upstream
"make man" in the docs/ subdirectory: (see line 23)

http://anonscm.debian.org/cgit/collab-maint/borgbackup.git/tree/debian/rules?h=debian/0.28.2-1=fe5c01cc1baa3f26819b392f51e1e54a122b159e#n23

There is no longer any Debian-specific hand-written manpage, so there's
no issue with it going out-of-date with upstream.  While not perfect,
that's certainly better than a hand-written manpage that gives incorrect
information every now and then.  Upstream is aware of the manpage issue,
you can read the discussion at github:

https://github.com/borgbackup/borg/issues/208

I hope that clears it up a bit.

Cheers,

- Danny

Bug#792096: borg packaging

[Danny Edel]

Hello everyone,

I was surprised to see the reaction my comments generated and like
Gianfranco, I also want to ask Marc to consider rethinking his decision.
 I do not think you are spoiling the fun or that insisting on
oldfashioned keeping is a bad thing.  I apologize that my choice of
words made you feel that way - I am not a native english speaker either,
so it may have sounded different than I intended.

I chose github as a mirror because I have upload rights there, that's
the only reason.  I would also prefer to work on *.debian.org and I will
do so once I have permission.  I just thought hosting git repo online
somewhere makes looking at it easier than sending stuff by mail, and
using github seemed like the easier choice than hosting and maintaining
a git browser myself.  Since git clones contain the entire history,
switching mirrors shouldn't be complicated once upload permission is
granted.

I chose the "ignore upstream tarball/use git tag" method also just
because it was simpler.  Had I imported the release tarball, I would
have had to maintain the list of files that are auto-generated (a simple
*.c won't do, for example _chunker.c is handwritten), and add rules to
remove them from the build dir or change their timestamp so that they
get refreshed at build-time.  Not having them in the first place made
that unnecessary.  That's the reason why upstream git tag seemed easier
to create a working example implementation of the "regenerate files" idea.

The git tag is gpg-signed with the same key as the tar.gz release, so I
don't really see the difference in authenticity, please elaborate why
.tar.gz would be superior for validation of borgbackup.  From what I
understand, an end-user will trust whatever checksum the Maintainer puts
into .changes and signs with maintainer key, so this is just an issue of
what the maintainer trusts.  Or am I getting this wrong?

- Danny

Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)

[Danny Edel]

On Tue, 08 Sep 2015 09:23:51 -0400 Antoine Beaupré wrote:
> 
> How does it differ from the package that Gianfranco and Marc have been
> working on? (In cc.)
> 
> A.

It doesn't necessarily "differ" in the sense that it would be a
different from-scratch packaging.  It is 95% their package, plus a few
lines in d/rules and one patch in d/patches to accomodate for the
differences between upstream git and upstream tarball.  My Idea was that
instead of just saying "regenerate those files" I wanted to add a stance
saying "and it could work somewhat like this", in order to have a
discussion on whether my Idea makes sense, and not on the basis of
whether it even works.


The only differences are:


(1) Repository layout "branch off the main repo"

I didn't use upstream tarball, but rather depended only on the git tag
(which doesn't contain the generated files I spoke of earlier, but it
contains the code to re-generate them)

Basically I followed this:

http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.UPSTREAM.GIT.NOTARBALL


(2) Rebuilding .c and .rst.inc files

By using the upstream git directly, we can use the upstream build system
(which already calls cython and sphinx) to generate the .c sources and
the .rst.inc for the html manual.  Some environment-variable-setting in
d/rules was necessary to call the upstream docs/Makefile, to make sure
it can call "borg help COMMAND --usage-only" during the generation of
the .rst.inc files.


(3) Patch to remove travis and codecov badges

README.rst in git contains images that say "code coverage xyz%" and
"travis build [passing/failing]". I didn't think they are of relevance
to a Debian user (since they reflect current git status, not the version
installed) plus it may be a privacy concern to load external resources
when browsing the local copy of the manual.


I also think that by using upstream git directly, we get the advantage
of directly being able to use git-bisect/git-cherry-pick for identifying
and backporting fixes to the stable version, which may come in handy
later on.


Danny

Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)

[Danny Edel]

On Mon, 31 Aug 2015 14:14:35 +0200 Danny Edel wrote:
> I am currently working on a proof-of-concept version of d/rules doing
> all of that, I will report back here once I've got a working draft.

I have pushed a working packaging to github. It's not of
release-quality, but it should serve as a proof-of-concept for building
from git tags.

git clone git://github.com/dannyedel/pkg-borgbackup.git
gbp buildpackage -uc -us [-S/-b]

Browse: https://github.com/dannyedel/pkg-borgbackup

Things left to do/discuss:

* Lintian notices that the binaries are not properly hardened. I've
tried including /usr/share/dpkg/buildflags.mk, but enabling pie in the
hardening options breaks the build on the cython files. I am not sure
what's the right course of action here.

* If we symlink borg to borgbackup (like the package name), lintian
complains that /usr/bin/borgbackup has no manpage. Do we also symlink
the manpage or is there a special syntax to say "load 'man borg' when
someone types 'man borgbackup'"?


Just to make clear, I don't think this packaging is ready for production
use as-is.  It's meant as a proof-of-concept of building from the
minimal set of source files (i.e. the ones versioned in git), using
debian packaged versions of cython and sphinx to re-generate the rest.
If you also think that's a good idea, please use as much or as little as
seems appropriate.


Danny

Bug#797917: Actually this bug makes clang not so useful

[Danny Edel]

On 04/09/15 11:23, Gianfranco Costamagna wrote:
> 
> I guess clang is not useful for cxx11 projects until llvm folks finds
> a way to make it use the new ABI.
> 

Hi everyone,

I just want to make clear that this is *not* specific to c++11 projects.
Even if you don't use any c++11 features, clang can't link against the
library.

Try compiling my example code (which is valid c++98) with

$ g++ -std=c++98 -o options options.cpp -lboost_program_options
$ clang++ -std=c++98 -o options options.cpp -lboost_program_options

The results are the same - works on gcc, fails to link on clang on sid,
while both commands used to work on stable.

If I understand the consequences of this failure right, this will
severely impact the usefulness of clang++, since it will start failing
to link against *any* c++ library compiled by recent g++, breaking
unchanged and valid user code - be it c++11, c++03 or c++98.

I don't think this is that much of an issue on sid - after all, it's
called "unstable" for a reason - but it might be a showstopper for
stable, if clang++ is to be an alternative for g++.

- Danny

Bug#797917: libboost-program-options-dev: clang++: undefined reference to boost::program_options::arg

[Danny Edel]

Package: libboost-program-options-dev
Version: 1.58.0.1

Dear maintainer,

I cannot link against recent boost_program_options with clang++, while
it works fine with g++. I have attached a small test program that
demonstrates the bug.

$ g++ -o options options.cpp -lboost_program_options
$ ./options --filename asdf
Filename is asdf
(No problem, works as intended)

$ clang++ -o options options.cpp -lboost_program_options

/tmp/options-18b2b2.o: In function
`boost::program_options::typed_value, char>::name() const':

options.cpp:(.text._ZNK5boost15program_options11typed_valueINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcE4nameEv[_ZNK5boost15program_options11typed_valueINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEcE4nameEv]+0x4c):
undefined reference to `boost::program_options::arg'

clang: error: linker command failed with exit code 1 (use -v to see
invocation)


I believe this is because the symbol is only exported using the new
[abi:cxx11] which apparently g++ understands but clang++ doesn't.

$ nm -D /usr/lib/x86_64-linux-gnu/libboost_program_options.so | c++filt
| grep boost::program_options::arg
0027d920 B boost::program_options::arg[abi:cxx11]


I am running debian sid, so these should be quite recent versions:

$ g++ --version
g++ (Debian 5.2.1-15) 5.2.1 20150808

$ clang++ --version
Debian clang version 3.5.2-2 (tags/RELEASE_352/final) (based on LLVM 3.5.2)

I also tested with clang-3.8 package, same results (undefined reference
to boost::program_options::arg)

$ clang++-3.8 --version
Debian clang version 3.8.0-svn245286-1 (trunk) (based on LLVM 3.8.0)


Is it possible to compile boost_program_options (and possibly other
not-pure-header-parts of boost) in a dual-abi way, so that Clang can
link to it aswell? Or did I miss a flag on calling clang as a user?


On a jessie VM, the above commands work as expected, so from a user
perspective, this is a regression. I'm not sure whether this is a boost
or a clang issue, please redirect if I reported against the wrong package.


Thank you,

- Danny
#include 
#include 
#include 

using namespace std;
using namespace boost::program_options;

int main(int argc, char** argv) {
	string fname;
	options_description opts("Options");
	opts.add_options()
		("filename,f", value()->required(),
		 "Specify file name");

	variables_map vm;
	store( command_line_parser(argc,argv).options(opts).run(), vm);
	notify(vm);

	cout << "Filename is " << fname << endl;
	return 0;
}

Bug#797917: Actually this bug makes clang not so useful

[Danny Edel]

On Thu, 3 Sep 2015 17:45:27 + (UTC) Gianfranco Costamagna
 wrote:
> according to [1] there might be no fix.
> 

This may not be a permanent fix, but Debian could take up the "dual-abi"
idea that gcc upstream does with their libstdc++.so.6.

Example:

$ nm -D /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | c++filt | grep
std::locale::name
0009e300 T std::locale::name[abi:cxx11]() const
000b8900 T std::locale::name() const

For reference, the un-beautified symbol names are

0009e300 T _ZNKSt6locale4nameB5cxx11Ev
000b8900 T _ZNKSt6locale4nameEv


The symbol is exported twice, once with the new ABI and once with the
old. If someone™ figured out how to make the gcc compiler do that, boost
(and other libraries') maintainers could adapt those flags when
compiling with gcc, so we don't generate a vendor lock-in.

If we could make those "Dual-ABI compile flags" the default on
gcc-compiled libraries, clang upstream should have enough time
implementing [abi:cxx11] and remain usable in Debian.

- Danny

Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)

[Danny Edel]

Hi,

I have been investigating the differences of "upstream release tarball"
versus "upstream git tag/github tarball" and I noticed that "upstream
release" differs a bit:

(1) Release tarball ships .c files compiled from python sources with
cython (examples: borg/crypto.c, borg/chunker.c)

(2) Release tarball includes generated generates .rst.inc files for
documentation by calling
  borg help  (see script docs/update_usage.sh)

(3) Release tarball includes a static borg/_version.py, while git tag
includes one embedding the git revision.


I personally think we should regenerate (1) with debian's packaged
cython3 during the build instead of using the upstream ones.

Rationale for this is mainly security: If any serious bug is discovered
in cython3, and we call it during build, all we need is a
no-change-rebuild in order to benefit from the fix. [This will mainly
get relevant when borgbackup reaches "stable" and upstream has moved on]

While (2) and (3) are nowhere near as important as (1), if we recreate
those ourselves during the build process, we could simply depend on
upstream git tag releases (those are gpg-signed with the same key as the
release tarball btw).

I am generally assuming that the (git-)versioned files are the only
actual human-written sources, and everything else is generated by
automation. I would suggest Debian imports only the human-written source
code, and we run all automation following it at build-time.

I am currently working on a proof-of-concept version of d/rules doing
all of that, I will report back here once I've got a working draft.


Of course, in the end, this is just my personal opinion and not
necessarily required policy, however 4.13 ("Convenience copies of code",
although this discusses included *library* code) suggests a similar
direction. I could not find anything on "including generated files vs.
regenerating them" in general.

https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles


- Danny

Bug#792096: RFP: borgbackup -- deduplicating and compressing backup program)

[Danny Edel]

On Sat, 11 Jul 2015 12:57:54 +0200 Marc Haber
mh+debian-packa...@zugschlus.de wrote:
 I have stitched together a quick package and pushed it to collab-maint,
 ssh://git.debian.org/git/collab-maint/borgbackup.git
 
 I do not intend to upload until a team of at least two active people
 maintaining the package has formed.

Hello Marc,

if I can, I'd like to help on the packaging/maintaining front. The
package sounds like a really nice addition to Debian, especially the
borg serve infrastructure could be exactly what I need myself : )

Disclaimer: Unlike Gianfranco and anarcat, I'm not a DD, so I don't have
upload rights myself.

However, if there's other parts of the maintaining , I hope that I can
jump in, just let me know where I could lend a hand.

- Danny

Bug#777833: digikam: ftbfs with GCC-5 (patch)

[Danny Edel]

tags 777833 patch
thanks

Hello all,

I tried to rebuild digikam on sid today. The current version still
misses libsoprano-dev dependency and fails with:

 make[3]: *** No rule to make target '/usr/lib/libsoprano.so', needed
by 'lib/libkvkontakte.so.1.0.0'.  Stop.

Once a build-time dependency on libsoprano-dev was declared, I was able
to compile digikam on a sid sbuild, it linked against the new
opencv-*2.4v5 libraries.

- Danny
diff -Nru digikam-4.4.0/debian/control digikam-4.4.0/debian/control
--- digikam-4.4.0/debian/control2014-11-15 17:37:35.0 +0100
+++ digikam-4.4.0/debian/control2015-08-10 14:51:04.0 +0200
@@ -6,6 +6,7 @@
 Build-Depends: debhelper (= 9), pkg-kde-tools (= 0.9), pkg-config, cmake (= 2.6.2),
  doxygen,
  kdelibs5-dev, kdepimlibs5-dev,
+ libsoprano-dev,
  libmarble-dev,
  libkipi-dev (= 4:4.12), libkexiv2-dev (= 4:4.12), libkdcraw-dev (= 4:4.12), libksane-dev,
  baloo-dev, libkfilemetadata-dev,

Bug#777833: digikam: ftbfs with GCC-5

[Danny Edel]

On Sat, 08 Aug 2015 00:56:48 +0200 Christoph Anton Mitterer
cales...@scientia.net wrote:
 Hey.
 
 Anything new here? That blocks upgrading to to current libstdc++6
 (without removing a large number of packages) and thus also prevents
 other packages (that already depend on newer libstdc++6) with important
 security updates to be installed.
 
 Cheers,
 Chris

Hello Chris,

I've tried to reproduce the build failure, and I got a little different
results than above, so I'm sharing them in the hope they benefit in
tracking down the bug.

 Unmodified package 

I tried apt-get source digikam, followed by
sbuild --dist unstable digikam_4.4.0-1.1.dsc

It ran for a while, and then failed with the following message:

make[3]: *** No rule to make target '/usr/lib/libsoprano.so', needed by
'lib/libkvkontakte.so.1.0.0'.  Stop.


Full log (400kb) can be downloaded from
http://danny-edel.de/logs/digikam_4.4.0-1.1_amd64-20150810-1415.build

 With libsoprano-dev in Build-Depends: 

For testing purposes, I added libsoprano-dev (which contains this
file) to build-depends and created a new source package (Please ignore
the incremented version number), and got a different failure:

CMakeFiles/kface.dir/detection/opencvfacedetector.cpp.o: In function
`KFaceIface::Cascade::Cascade(QStringList const, QString const)':
/«PKGBUILDDIR»/extra/libkface/libkface/detection/opencvfacedetector.cpp:130:
undefined reference to `cv::CascadeClassifier::load(std::__cxx11
::basic_stringchar, std::char_traitschar, std::allocatorchar  const)

Full log (500kb) can be downloaded from
http://danny-edel.de/logs/digikam_4.4.0-1.2_amd64-20150810-1455.build



I hope this helps in getting Digikam to run again. To me, the second
failure looks like cv needs a rebuild to expose the new __cxx11 symbols,
before digikam can compile cleanly with GCC5.

However, I don't know how to request that, or check whether it has
already been requested.

- Danny


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

Bug#794665: RFS: dspdfviewer/1.13-1 [ITP] -- Dual-screen PDF viewer for latex-beamer presentations

[Danny Edel]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package dspdfviewer

* Package name: dspdfviewer
  Version : 1.13-1
  Upstream Author : Danny Edel m...@danny-edel.de
* URL : http://dspdfviewer.danny-edel.de
* License : GPL version 2 or, at your option, any later version
  Section : text

It builds those binary packages:

dspdfviewer - Dual-Screen PDF Viewer for LaTeX-beamer

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

  http://mentors.debian.net/package/dspdfviewer


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

dget -x
http://mentors.debian.net/debian/pool/main/d/dspdfviewer/dspdfviewer_1.13-1.dsc

More information about dspdfviewer can be obtained from
  * https://github.com/dannyedel/dspdfviewer
* Sourcecode and issues tracker
  * http://dspdfviewer.danny-edel.de
* Website

Changes since the last upload:

dspdfviewer is not yet in debian, so there are not really changes yet.

However, I initially posted directly to the mailing list and didn't know
to file the bug report. This thread can be found on

https://lists.debian.org/debian-mentors/2015/08/msg5.html

Thanks to the feedback I got in response, the package is much cleaner
now and hopefully can be included in Debian.

-- 

Regards,

Danny Edel

m...@danny-edel.de
deb...@danny-edel.de


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

Bug#794319: ITP: dspdfviewer -- Dual-Screen PDF Viewer for LaTeX-beamer presentations

[Danny Edel]

Package: wnpp
Severity: wishlist
Owner: Danny Edel deb...@danny-edel.de

* Package name: dspdfviewer
  Version : 1.13
  Upstream Author : Danny Edel m...@danny-edel.de
* URL : http://dspdfviewer.danny-edel.de/
* License : GPL
  Programming Lang: C++
  Description : Dual-Screen PDF Viewer for LaTeX-beamer

 This is a specialized PDF Viewing application custom-made for
 the LaTeX class beamer, specifically the
 show notes on second screen=right option.
 .
 To make use of this program, you will need a document created
 by latex-beamer, and you will need two monitors connected to
 your computer.
 They do not need to have the same resolution, not even the same
 aspect ratio.
 .
 This program will split your PDF page in half, and display the
 left half (intended for the audience) on one monitor (think:
 a notebook's VGA output connected to your university's projector)
 and it will display the right half (intended for you) on the
 second screen.
 Also, on the second screen, you get page thumbnails and status
 information, like the time since you started the presentation
 and a wall clock.


Answering the questions from the template:

 why is this package useful/relevant?

While I could create dual-width presentations with latex' beamer class,
there was no viewer to render them to independent screens (workarounds
included setting the screens to identical sizes and dragging a viewer
window to both screens)

 is it a dependency for another package?

No, but you could think of it as an enhancement for latex-beamer.

 do you use it?

Yes, I do, and judging from the resonance on email, github and
stackoverflow, so do other people, both using debian systems and other
distributions. Since I want to make life easier for current and future
users of my software running debian, I'm asking for an inclusion in the
official software list.

 if there are other packages providing similar functionality,
 how does it compare?

I don't know of any packages providing similar functionality, that was
the reason I programmed it in the first place.

 how do you plan to maintain it? inside a packaging team
 (check list at https://wiki.debian.org/Teams)? are you
 looking for co-maintainers? do you need a sponsor?

I have been maintaining the software itself on github since winter
2012/2013, and have built deb packages to my third-party repository
since then.
I plan to maintain the debian package myself, trying to keep it as close
to upstream as possible, but compliant to debian guidelines.

I will need a sponsor since I'm new to official debian packaging.


-- 
Danny Edel
m...@danny-edel.de
deb...@danny-edel.de


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