Bug#851827: scim-qt-immodule seems to be not working with Qt5 apps

[Rolf Leggewie]

Package: scim
Version: 1.4.18-1
Followup-For: Bug #851827

Artem,

thank you for your report.  Unfortunately, scim does not yet support Qt5.

You can follow upstream discussion at https://github.com/scim-im/scim/issues/21

I'm sorry, I don't have better news at this point in time.

Regards

Rolf

Bug#886026: thank you for the translations

[Rolf Leggewie]

Thank you for the translations.  Pastebinit uses launchpad for many
things, translations included.

https://translations.launchpad.net/pastebinit/trunk

I've made an attempt to upload it there.

Bug#830207: new VCS

[Rolf Leggewie]

the packaging is now being developed at
https://github.com/leggewie-DM/audio-recorder

Bug#876386: Thank you for this report

[Rolf Leggewie]

Dear Shi,

thank you for your report.  I will shortly upload an interim "fix" to
depend on net-tools until this can be properly fixed.  Xie xie.

Regards

Rolf

Bug#866037: your report lacks information

[Rolf Leggewie]

Hello,

there is basically no information whatsoever in your bug report what
problem you experience with n2n.  What am I supposed to make of this? 
Please provide steps to reproduce and what problems you experience.  You
even quoted the section requesting that information, yet ignored it.

Regards

Rolf

Bug#875738: disable version check

[Rolf Leggewie]

I believe that just like bug 871452, Debian ought to disable this check.

Bug#885284: gbirthday: Depends on unmaintained pygtk

[Rolf Leggewie]

On 11.01.2018 21:49, Jérôme wrote:
> QBirthday now has a setup.py which makes it easier to install. I hope
> it also makes it easier to create a .deb from the sources.
>
> Rolf (or anyone), would you like to package QBirthday?

Jerome, thank you.  That sounds pretty good.  I shall look into it.

Bug#865460: No login and crash at reconnect

[Rolf Leggewie]

severity 865460 important
thanks


On 08.09.2017 00:40, Jörg Frings-Fürst wrote:
> roger is unusablel with this bug. So I set the severity to grave.

Hello Jörg,

thank you for the report.  FWIW, roger runs fine for me, albeit on an
Ubuntu system.  In your original report you write "since some days
roger-router don't login at start and crashes at reconnect.", so I will
assume it was initially working fine.  To me that hints at a problem
elsewhere, not in the roger package.  Alsa maybe?  Can you recollect any
changes you made around the time the breakage occurred?  I wonder if
there is some kind of library incompatibility.  Does rebuilding the
package help at all?

Furthermore, I suppose the CLI of roger would still be working even for
you, or am I mistaken?  As such, "a bug which has a major effect on the
usability of a package, without rendering it completely unusable to
everyone." seems to apply here and thus I would think that severity
important is correct.

Regards

Rolf

Bug#873774: Many gui apps become slow responsive after upgrading my sid

[Rolf Leggewie]

On 31.08.2017 09:36, liuxu wrote:
> Package: scim
> Version: 1.4-18
>
> many gui apps in my mate desktop env becomes slow responsive
> [...]
> After purge all scim packages, those problematic apps become normal
> immediately.
> After reinstall scim and scim-pinyin, those apps become probelmatic
> again immediately.

Hello Liuxu,

thank you for your report.  I'm sorry to hear about the troubles you are
facing.

Were you previously using version 1.4.17-1?  Does downgrading to the
version in testing help?

Regards

Rolf

Bug#871452: cherrytree: Please omit the menu option to check for newer version

[Rolf Leggewie]

Package: cherrytree
Severity: minor

Dear Maintainer,

I believe that for a distro package it does not make sense to have a binary
have a menu option to check upstream for a newer version.  The latest
available version in Debian is the one available from the mirrors.  This
should be easy enough to patch out.

Regards

Rolf

Bug#853406: gcc7 and package freelan

[Rolf Leggewie]

Hello Matthias,

thank you for making us aware of the FTBFS of freelan with gcc7. 
Upstream provided a patch and I already uploaded the package. 
Unfortunately, I hadn't realized that I hadn't extended the validity of
my key as DM in the official keyring.  I've done that now, but seeing
that the last update to it was 12 hours ago it might be another four
weeks or so before the package comes through.

I've bumped the release once more and uploaded it to
https://mentors.debian.net/debian/pool/main/f/freelan/freelan_2.0-4.dsc 
I attach the debdiff against the latest version in testing/unstable here
as well for your inspection.  It would be great if you could help out
and prevent removal of the package in about two weeks time, well before
I expect my updated key to be included in the official keyring.

Regards

Rolf
diff --git a/debian/changelog b/debian/changelog
index 257d999..a08bb26 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+freelan (2.0-4) unstable; urgency=medium
+
+  [ Sebastien Vincent ]
+  * patches: backport 5014a8023b from upstream. Closes: #853406
+fix FTBFS with gcc7
+
+  [ Rolf Leggewie ]
+  * control: update to standards version 4.0.0
+- fix typo in manpage
+- make the whatis entry for the freelan manpage more meaningful
+  * copyright: update my copyright to 2017
+
+ -- Rolf Leggewie <f...@rolf.leggewie.biz>  Sun, 06 Aug 2017 17:57:54 +0800
+
 freelan (2.0-2) unstable; urgency=medium
 
   [ Julien Kauffmann ]
diff --git a/debian/control b/debian/control
index 95b2986..2a1f58c 100644
--- a/debian/control
+++ b/debian/control
@@ -7,7 +7,7 @@ Build-Depends: debhelper (>= 9),
  libssl-dev, libcurl4-openssl-dev, libboost-system-dev, libboost-thread-dev,
  libboost-program-options-dev, libboost-filesystem-dev,
  libboost-iostreams-dev, scons
-Standards-Version: 3.9.8
+Standards-Version: 4.0.0
 Homepage: http://www.freelan.org
 Vcs-Git: https://github.com/freelan-developers/freelan.git -b debian/unstable
 Vcs-Browser: 
https://github.com/freelan-developers/freelan-all/tree/debian/unstable
diff --git a/debian/copyright b/debian/copyright
index b4c00dc..1d164f9 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -8,7 +8,7 @@ License: GPL-3+
 Comment: Upstream grants a special exception to link with OpenSSL
 
 Files: debian/*
-Copyright: 2015-2016 Rolf Leggewie <f...@rolf.leggewe.biz>
+Copyright: 2015-2017 Rolf Leggewie <f...@rolf.leggewe.biz>
2012  Julien Kauffmann <julien.kauffm...@freelan.org>
 License: GPL-3+
 
diff --git a/debian/freelan.1 b/debian/freelan.1
index c561e76..bbaf7a2 100644
--- a/debian/freelan.1
+++ b/debian/freelan.1
@@ -1,7 +1,7 @@
 .\" DO NOT MODIFY THIS FILE!  It was generated by help2man 1.44.1.
 .TH FREELAN "1" "June 2015" "freelan 2.0.0 (2.0-8-g0545b2d) Sun 21 Jun 2015" 
"User Commands"
 .SH NAME
-freelan \- manual page for freelan 2.0.0 (2.0-8-g0545b2d) Sun 21 Jun 2015
+freelan \- peer-to-peer VPN
 .SH DESCRIPTION
 .SS "Generic options:"
 .TP
@@ -245,7 +245,7 @@ The DNS script.
 Do not run as a daemon.
 .TP
 \fB\-s\fR [ \fB\-\-syslog\fR ]
-Alwats log to syslog (useful when running with
+Always log to syslog (useful when running with
 \fB\-\-foreground\fR on OSX with launchd).
 .HP
 \fB\-p\fR [ \fB\-\-pid_file\fR ] arg A pid file to use.
diff --git a/debian/patches/5014a8023b.patch b/debian/patches/5014a8023b.patch
new file mode 100644
index 000..3ac53ec
--- /dev/null
+++ b/debian/patches/5014a8023b.patch
@@ -0,0 +1,64 @@
+From 5014a8023b42762052d6417ebbc0cd2adb1fda90 Mon Sep 17 00:00:00 2001
+From: Sebastien Vincent <sebastien.vinc...@cppextrem.com>
+Date: Sat, 5 Aug 2017 20:10:55 +0200
+Subject: [PATCH] Fixes compilation with g++-7.
+
+---
+ libs/asiotap/src/posix/posix_tap_adapter.cpp  | 2 ++
+ libs/netlinkplus/include/netlinkplus/endpoint.hpp | 8 +---
+ 2 files changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/libs/asiotap/src/posix/posix_tap_adapter.cpp 
b/libs/asiotap/src/posix/posix_tap_adapter.cpp
+index 71377cee..cdd7abf3 100644
+--- a/libs/asiotap/src/posix/posix_tap_adapter.cpp
 b/libs/asiotap/src/posix/posix_tap_adapter.cpp
+@@ -206,6 +206,7 @@ namespace asiotap
+   {
+   result[name] = name;
+   }
++  break;
+   }
+   case tap_adapter_layer::ip:
+   {
+@@ -213,6 +214,7 @@ namespace asiotap
+   {
+   result[name] = name;
+   }
++  break;
+   }
+   }
+

Bug#780280: dak: generate rejection mail for mails with expired signature

[Rolf Leggewie]

Hello!

Currently, the uploader of a package using an expired key is left
guessing as to why the package was accepted but doesn't show up in the
archive.  Please remove this guesswork to improve productivity.  Thank you.

Regards

Rolf

Bug#860568: iptraf-ng: cron spam due to duplicated logrotate rules

[Rolf Leggewie]

Package: iptraf-ng
Version: 1.1.4-1
Followup-For: Bug #860568

FWIW, this problem also occurs in a Ubuntu Trusty installation.
I'm mentioning this since my first assumption was this might be
due to iptraf migrating to iptraf-ng but that hasn't happened
in Ubuntu trusty.

Bug#861909: postgrey: Please add whitelist entry for mail.alibaba.com

[Rolf Leggewie]

Package: postgrey
Version: 1.35-1
Severity: normal

Dear Maintainer,

aliexpress.com and alibaba.com outgoing mail are handled by a large
pool of outgoing MTA of the form mail123-456.mail.alibaba.com.  I
kindly request an appropriate entry be made for them in the default
whitelist.

Regards

Rolf

Bug#830207: Next try

[Rolf Leggewie]

Hello and good morning!   

On 19.02.2017 19:45, David Rabel wrote:
> dpkg-source emits a warning concerning the fiels that dh-clean deletes,
> e.g.:
>
> dpkg-source: warning: ignoring deletion of file missing, use
> --include-removal to override
>
> Is this a problem?

No, that's just informational.

On 19.02.2017 19:29, David Rabel wrote:
> Good morning,
>
> On 19.02.2017 00:48, Rolf Leggewie wrote:
>>> What you actually say is: IF we leave it as it is, the worst case is
>>> that the software could be public domain.
>> No.  The software has whatever license it has.[...]
> I meant leave it as it is "upstream".
> In my opinion the software is DFSG-compliant in any way. If the
> copyright holder is Osmo or Team audio-recorder or the software is
> public domain.

Part of the work as maintainer and especially when doing an ITP is to
verify the code is indeed DFSG-free.  Personally, I'd have trouble with
ambiguity in the form of "Well, I can't really be certain if the
software is licensed as GPL, LGPL or public domain but since all those
are DFSG-free it should be OK".  One should clarify what the license is
and release the ITP only afterwards.

> There are source files without copyright notice. Do we have to add
> that? For example the header files under src/ . 

Publishing something without claiming copyright automatically makes it
public domain.  So, unless Person A publishes file X with a copyright
notice and person B republishes it, stripping the copyright notice,
those files do not usually have copyright.  It's OK to assume that files
for which we cannot find a copyright claim to be copyright-free (until
we are made aware of the contrary, that is).

> I think you are wrong here. intltoolize is not run by autoreconf.

That's what I read during my research about dh-autoreconf (not
autoreconf). It's entirely possible that I am mistaken.  As I said, my
changes were untested.  Does the package still compile?

By the way, why do you remove the autogenerated files in the first place
when upstream apparently is keen to ship them and it creates a "problem"
for you in having to recreate them?  This is usually only necessary if
those autogenerated files are old and do not support newer platforms. 
That's when you need to autoreconf.  Otherwise, it's unnecessary but it
does have the benefit of future-proofing the package somewhat.

>> The Depends and Build-Depends lines look surprisingly long.[...]
> I copied both Build-Depends and Depends from the upstream control file.
> I'm not too familiar with ${misc:Depends} and ${shlibs:Depends} . Maybe
> you would like to fix this?

Not sure if this is even wrong.  It just struck me as odd.

I have not compiled your package yet.  You could strip the additional
packages from Depends, build the package and inspect the resulting deb
file with "dpkg --info $path-to-deb-file" and if the dropped
dependencies are still listed then listing them explicitly in
debian/control wasn't necessary.  If they are no longer there, I'd
install the package, run the binary and unless I run into problems I'd
assume the dependencies weren't actually really necessary.

You can read more about ${misc:Depends} and ${shlibs:Depends} in "man 7
debhelper" under the heading "Automatic generation of miscellaneous
dependencies."

Regards

Rolf

Bug#830207: Next try

[Rolf Leggewie]

On 19.02.2017 04:12, David Rabel wrote:
> I was just thinking: Do we have to add a paragraph in debian/copyright
> for files we delete with debian/clean?

Yes, absolutely.  The only other option is to create a separate
dfsg-free upstream tarball and strip the relevant files from that tarball.

In your case, of course, you might also use your upstream powers and
consider to drop the file upstream depending on whether or not it should
be shipped in upstream releases.

Bug#830207: Next try

[Rolf Leggewie]

Good morning David,

On 19.02.2017 03:59, David Rabel wrote:
> Hi Rolf,
>
> a general question: Are you OK with the way I commit every step in git
> or would you prefer that I clean up the history a little bit before pushing?

Whatever you think makes most sense.  Your style looks absolutely fine
to me.

>> I am sure Osmo did not intend to release as public domain.
> What you actually say is: IF we leave it as it is, the worst case is
> that the software could be public domain.

No.  The software has whatever license it has.  We are just documenting
what that is.  While doing this due diligence we might actually find out
that the license as stated is not what the author intended (a license
bug if that's how you want to look at it).  Debian is doing this to
guarantee to its users that all software complies with DFSG and thus the
users do not have to do this work.  Again, there really is no way around
this.

I am not sure that debian/copyright is currently complete, yet. 
"licensecheck -r" lists quite a few files under LGPL license for example
and "rgrep -i copyright ." gives a lot more names than currently
documented.  There's still work to be done here.

> We could drop the file, we just would have to run intltoolize before
> the build process. I was not quite sure how to do it.

It is already being done in line 18 of the current debian/rules file via
"--with autoreconf".  So, at least for Debian it seems that file (and
possibly others) is not necessary and will be replaced during the build
anyhow.

dh-autoreconf is a superset of autotools-dev and thus I pushed an
untested fix to the rl-wip branch on github.  Feel free to cherry-pick
after verification.

The Depends and Build-Depends lines look surprisingly long.  Why do you
have so many explicit runtime dependencies in Depends?  Isn't this
picked up automatically by ${misc:Depends} and ${shlibs:Depends}?  If
necessary this can be fixed later, but it struck me as odd when I
stumbled upon it now.

Thanks again for your work.

Regards

Rolf

Bug#830207: Next try

[Rolf Leggewie]

On 18.02.2017 20:37, David Rabel wrote:
> Hi there,
>
> I uploaded a new audio-recorder package to mentors:
> https://mentors.debian.net/package/audio-recorder

Awesome!  Thanks.

I see you pushed changes to github so I will focus my review on what's
up there, assuming it is identical to what's on mentors.debian.net  I've
not looked at mentors.

60fd5fd4c
It's a trivial fix, but if upstream has that spelling error I think it
would be better to keep it.  Where do you draw the line?  Who knows,
there might be some kind of intended meaning that you and I missed?  In
that part of our work, we are just documenting, not correcting IMO.

08dc66295a
I'm not sure if changing "The entire Linux community" to "Team audio
recorder" is sufficient.  I'm not sure such an entity exists and it's
basically equally opaque.  If it's not specific enough to understand who
to contact in case you'd like to ask for a relicensing of the code then
it's not specific enough for Debian.  Let's say you'd like to develop a
closed-source variety of audio-recorder, who would you need to ask for
permission?  Besides, as I already mentioned previously, my feeling is
that nobody but Osmo Antero has copyright.  There are two conditions
that need to be met for this NOT to be true; 1) significant
contributions from third parties and 2) those parties requested for
copyright when making those contributions.  2) is not documented in the
files and it should be IF there was a third-party copyright.

I understand that Osmo enjoys drinking his vine and keep things simple. 
But he is making things unnecessarily complicated here by adding an
opaque group of people to the copyright holders.  I believe that what he
wants to do is acknowledge outside contributions.  That's what the
AUTHORS file is for which is actually present but does not list anybody
besides him.  It's fine for him to make a broad statement there such as
"a multitude of patches were gladly received by a number of people from
the Linux community.  If you'd like to see your name here specifically
contact me at XYZ".  Copyright is about who owns the ultimate rights to
the source.  GPL extends quite a few of those rights to the users (such
as the right to modify, redistribute, etc.)  What Osmo is doing (and I'm
absolutely certain that is unintentional) is to give basically everyone
who can somehow claim to be part of the Linux community to fully OWN the
code and that includes the right to relicense it, for example.  This
would effectively make the source public domain and strip it of the
protections the GPL provides (such as disallowing redistribution as a
closed-source binary program).  I am sure Osmo did not intend to release
as public domain.

This absolutely needs clarification, no way around that.  My suggestion
is to simply drop the erroneous and very dangerous line giving the Linux
community or Team Audiorecorder the copyright.  All users already have
very broad rights protected under the GPL.  Adding that line actually
puts those rights in jeopardy.

dfe98839e3 adds Ian Holmes as copyright holder for src/gst-recorder.c. 
If there are any other other copyright holders then that's the way we
should handle copyright attribution for them as well, unless they have
copyright in a broad number of files.

329aa8ce287
"Other" is not a good name for License.  I suggest to follow
https://tracker.debian.org/media/packages/g/granule/copyright-1.4.0-7-4
or https://github.com/giuliopaci/SPro/blob/master/debian/copyright which
I found doing a quick Google search. 
https://lists.debian.org/debian-legal/2015/01/msg00054.html says there
is a later version of the file with a better worded license term.  If
that's the case it would be advisable for upstream to exchange the
current for the later version.  If upstream doesn't do this, we can also
do it in Debian only.  If the file is not necessary to build the binary,
we might want to simply drop it via debian/clean.  This question needs
more consideration.

> Mainly it is an update of the debian/copyright file. But while I edited
> it, I found a lot of auto-generated files in the source tarball. So I
> deleted them via dquilt patch. I hope this is the right way to handle
> such files.

Are they giving any problems during the build?  If no, then I'd say not
to bother with them at all.  If yes and they aren't removed by "dh
clean" already then the file debian/clean is the proper place.  Have a
look at "man dh_clean".  Simply put, you can list file names one per
line in debian/clean to be removed as one of the first steps during the
build. Wildcards are allowed, RegExp might be.  This is better than
using patches because deleting a 1MB file it takes a patch that's
slightly bigger than 1MB.  It's easier to read during code inspection as
well.

Regards

Rolf

Bug#855308: qemu: runtime dependencies for qemu are too strict

[Rolf Leggewie]

Package: qemu
Severity: normal
Tags: patch

Dear qemu packaging maintainers,

the qemu binary package currently transitively depends on all
available system emulation binary packages (via its dependency
on qemu-system).  These package are non-trivial in size and most
users won't need all emulators.  I have prepared a patch against
current git HEAD that will change nothing by default but allow
the user to have only the emulators installed that they really
want and use.

Regards

Rolf
Author: Rolf Leggewie
Subject: relax qemu runtime dependencies

--- control-in.orig	2017-02-16 22:53:29.567416355 +0800
+++ control-in	2017-02-16 23:01:45.809877093 +0800
@@ -123,7 +123,7 @@
 Package: qemu
 Architecture: amd64 arm arm64 armel armhf hppa i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc powerpcspe ppc64 ppc64el s390x sparc sparc64 x32
 Multi-Arch: foreign
-Depends: ${misc:Depends}, qemu-system (>= ${source:Version}), qemu-user (>= ${source:Version}) [linux-any], qemu-utils (>= ${source:Version})
+Depends: ${misc:Depends}, qemu-system (>= ${source:Version})|qemu-system-binary (>= ${source:Version}), qemu-user (>= ${source:Version}) [linux-any], qemu-utils (>= ${source:Version})
 Suggests: qemu-user-static [linux-any]
 Description: fast processor emulator
  QEMU is a fast processor emulator: currently the package supports
@@ -222,7 +222,7 @@
 # alpha m68k sh4 uses bootroms
  seabios, ipxe-qemu (>= 1.0.0+git-2013.c3d1e78-1~)
 Suggests: samba, vde2, qemu-block-extra (= ${binary:Version}),
-Provides: ${sysprovides:misc}
+Provides: ${sysprovides:misc}, qemu-system-binary
 Breaks: qemu-system (<< 1.3.0+dfsg-5)
 Replaces: qemu-system (<< 1.3.0+dfsg-5)
 Description: QEMU full system emulation binaries (miscellaneous)
@@ -250,7 +250,7 @@
  ipxe-qemu (>= 1.0.0+git-2013.c3d1e78-1~),
  qemu-efi
 Suggests: samba, vde2, qemu-block-extra (= ${binary:Version}),
-Provides: ${sysprovides:arm}
+Provides: ${sysprovides:arm}, qemu-system-binary
 Breaks: qemu-system (<< 1.3.0+dfsg-5),
 :ubuntu: qemu-common (<< 1.3.0+dfsg-5),
 :ubuntu: qemu-kvm (<< 1.2.0.dfsg-1),
@@ -282,7 +282,7 @@
 # all mips targets uses vgabios and bootroms
  seabios, ipxe-qemu (>= 1.0.0+git-2013.c3d1e78-1~)
 Suggests: samba, vde2, qemu-block-extra (= ${binary:Version}),
-Provides: ${sysprovides:mips}
+Provides: ${sysprovides:mips}, qemu-system-binary
 Breaks: qemu-system (<< 1.3.0+dfsg-5)
 Replaces: qemu-system (<< 1.3.0+dfsg-5)
 Description: QEMU full system emulation binaries (mips)
@@ -310,7 +310,7 @@
 Recommends: qemu-utils,
 # ppc targets use vgabios-stdvga and bootroms
  seabios, ipxe-qemu (>= 1.0.0+git-2013.c3d1e78-1~)
-Provides: ${sysprovides:ppc}
+Provides: ${sysprovides:ppc}, qemu-system-binary
 Breaks: qemu-system (<< 1.3.0+dfsg-5),
 :ubuntu: qemu-common (<< 1.3.0+dfsg-5),
 :ubuntu: qemu-kvm (<< 1.2.0.dfsg-1),
@@ -342,7 +342,7 @@
 # sparc64 uses vgabios-stdvga and bootroms
  seabios, ipxe-qemu (>= 1.0.0+git-2013.c3d1e78-1~)
 Suggests: samba, vde2, qemu-block-extra (= ${binary:Version}), 
-Provides: ${sysprovides:sparc}
+Provides: ${sysprovides:sparc}, qemu-system-binary
 Breaks:
  qemu-system (<< 1.3.0+dfsg-5),
 :ubuntu: qemu-common (<< 1.3.0+dfsg-5),
@@ -375,7 +375,7 @@
 :ubuntu: cpu-checker
 Suggests: samba, vde2, qemu-block-extra (= ${binary:Version}),
  kmod [linux-any], sgabios, ovmf
-Provides: ${sysprovides:x86}
+Provides: ${sysprovides:x86}, qemu-system-binary
 :ubuntu:Conflicts: kvm (<< 1.3.0+dfsg-5)
 Breaks:
  qemu-system (<< 1.3.0+dfsg-5),

Bug#830207: good to see audiorecorder in Debian

[Rolf Leggewie]

David,

thank you for your mail.

On 14.02.2017 16:57, David Rabel wrote:
> Thanks for your offer and of course I would appreciate your help.

Awesome.  Just add me to the uploaded fields as "Rolf Leggewie
<f...@rolf.leggewie.biz>" please.

> A few words regarding the workflow: Because Osmo publishes
> audio-recorder as an Ubuntu package, it already contains a debian/
> directory. So I download the latest tarball, untar it, delete the
> debian/ directory and tar it again.

That's actually much more complicated than it needs to be.  While it
does make sense to ask upstream to stop shipping a debian directory,
DebSrc3.0 which I believe is by now the default will overwrite any
directory if you want that.  The debian directory is always overridden
(c.f.
https://wiki.debian.org/Projects/DebSrc3.0#Advantages_of_new_formats). 
You only need to repack things if upstream tarball contains
undistributable content according to DFSG (not licensed for
redistribution, etc.).

> I work with git and gbp, so the all the packaging work is done in a
> git repository.

That's what I use for my other packages, too, so I'm very familiar with it.

> That is https://github.com/NoreSoft/audio-recorder at the moment. I am
> not a big fan of github, but chose it for simplicity. If you prefer
> something more free, let me know. If not, I could just give you write
> access to the repo.

You could host at alioth but personally I like github.  My account on
github is leggewie.

Upstream uses launchpad.net which recently got git support.  We might
look into moving the debian packaging there.  Do you know if upstream is
proficient in git?

>> "(C) linux community" really isn't saying anything at all so I am
>> going to have
>> to REJECT. Also missing other references (eg. Rosetta, but I stopped
>> looking there)
> So I am not quite sure yet how to handle this. My first idea is to ask
> Osmo if he may have this in more detail.

Anything passing through NEW will get the fine comb when it comes to
copyright.  You need to look at every single file before uploading. 
That's normal and you should prepare the upload accordingly.

Regards

Rolf

Bug#830207: Audio Recorder

[Rolf Leggewie]

On 14.02.2017 17:43, David Rabel wrote:
> The audio-recorder package was rejected by Debien FTP masters, because
> of the "(C) linux community". Can you say, who in particular
> contributed to audio-recorder?

Beware that unlike German Urheberrecht Copyright is not automatically
assigned.  So, unless contributions were made with a specific copyright
request they are public domain.  You can command copyright for your own
work.  I assume what you meant to do is acknowledge the contributions. 
But again, that does not mean the contributors have copyright and things
become much simpler.  Only you as upstream author have copyright and you
are of course free to mention contributors (who again do not have
copyright unless they requested this).

IANAL, but that that's my understanding.

> Viele Grüße, David 

Oh, Du bist Deutsch?

Bug#830207: good to see audiorecorder in Debian

[Rolf Leggewie]

Hello,

great to see audiorecorder close to being included in Debian.  I had
offered help for packaging the software at
https://bugs.launchpad.net/bugs/1391951 but I never got around to doing
an ITP.  Let me know if you are interested in a co-maintainer.  I am DM
and would be able to upload packages without requiring a DD sponsor.

Regards

Rolf

Bug#743420: sane-utils: scanimage fails when avahi is enabled

[Rolf Leggewie]

Package: sane-backends
Followup-For: Bug #743420

Hello,

I believe this is https://bugs.launchpad.net/bugs/1208091 which
Laurent Vivier traced down to a race condition in net.c  He also
provided a patch in above-mentioned URL.  In any case, I reported
#854705 to see if Debian wants to ship the patch.  FWIW, Laurent
says he no longer experiences the issue.

Regards

Rolf

Bug#854705: race condition in net backend

[Rolf Leggewie]

Package: libsane
Severity: normal
Tags: patch

Dear Maintainer,

one of the Ubuntu users has analyzed a segfault reported in
https://bugs.launchpad.net/bugs/1208091 which is linked to #734103.
Laurent concluded that there is a race condition in the net backend
for which he provided a patch in http://tinyurl.com/j5qjcqc. Please
have a look and include the patch if you feel it is appropriate.

Regards

Rolf

Bug#824450: scanbd does not find scanner

[Rolf Leggewie]

On 02.06.2016 05:52, Chris Laif wrote:
> After that I compiled scanbd_1.4.4-1rl1 and ... voila, it works 

Well, that's good news.  I'm still wondering what's wrong with the
Debian package itself.

Are you available to test a package on Jessie?

Bug#853295: git-buildpackage should recommend or suggest libdistro-info-perl

[Rolf Leggewie]

On 01.02.2017 00:09, Guido Günther wrote:
>> thank you for maintaining git-buildpackage.
>> > 
>> > I noticed that git-dch uses functionality from libdistro-info-perl.  
>> > Wouldn't
>> > it be a good idea to either recommend or suggest the package?
> gbp doesn't use it by itself. Invokes dch from devscripts's which
> already recommends it so I don't think we should also do so.

Yeah, that's indeed good enough.  I somehow missed this transitional
dependency when looking at why the package hadn't been installed on one
of my machines.  Sorry for the noise.

Bug#853754: gjots2: Autosave is unsafe

[Rolf Leggewie]

Package: gjots2
Version: 2.4.1-2
Severity: important
Tags: upstream

I just found out that the autosave function of gjots2, while neat, has
some serious shortcomings in implementation.

Steps to reproduce
1) open a gjots file
2) change something, but don't save
3) close the file or quit the program

I will not be asked if I want to save my changes.  So, for example if I
changed my mind on the changes in #2 and would like to discard them,
ordinarily I would simply close the program and I'd assume to be back to
my original state.  Not with gjots2 anymore. The old state is preserved
but the user will need to know where and most importantly be aware they
need to recover back to the state in #1 manually.  This is not in line
with how other programs use autosave (for recovery) so this can
potentially lead to data loss the next time the file is opened and
autosaved.

Bug#853295: git-buildpackage should recommend or suggest libdistro-info-perl

[Rolf Leggewie]

Package: git-buildpackage
Version: 0.6.22
Severity: normal

Dear Guido,

thank you for maintaining git-buildpackage.

I noticed that git-dch uses functionality from libdistro-info-perl.  Wouldn't
it be a good idea to either recommend or suggest the package?

Regards

Rolf

-- System Information:
Debian Release: 8.7
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)


Versions of packages git-buildpackage depends on:
ii  devscripts2.15.3+deb8u1
ii  git   1:2.1.4-2.1+deb8u2
ii  man-db2.7.0.2-5
ii  python2.7.9-1
ii  python-dateutil   2.2-2
ii  python-pkg-resources  20.10.1-1.1~bpo8+1

Versions of packages git-buildpackage recommends:
pn  cowbuilder
ii  pristine-tar  1.33

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  unzip  6.0-16+deb8u2

-- no debconf information

Bug#790584: gjots2: depends on python-gnome2 which is deprecated

[Rolf Leggewie]

Package: gjots2
Version: 2.4.1-2
Followup-For: Bug #790584

Emilio, thank you for making me aware of this problem.  I relayed the 
information upstream and am happy to report that upstream has superseded
all python-gnome2-related code in the latest release.

Bug#827522: [gjots2] Version 3.0.1 available

[Rolf Leggewie]

Package: gjots2
Version: 2.4.1-2
Followup-For: Bug #827522

Marek,

I thought I had already replied to this ticket but it looks like
I did not.

Thank you for your report.  There are ways in Debian to inform the
maintainer automatically about new upstream releases (debian/watch).
Specifically opening bug tickets about new upstream versions being
available doesn't really help much.

I had had a look at the new upstream quite a while ago and found
several bugs so I reported them upstream and held off releasing 
to Debian.

https://sourceforge.net/p/gjots2/bugs/

Regards

Rolf Leggewie

Bug#849290: dovecot-core: incorrect information in /etc/dovecot/README

[Rolf Leggewie]

Package: dovecot-core
Severity: minor

Dear Maintainer,

I would say that the file /etc/dovecot/README is pretty unnecessary.
I run the version from Jessie and there is nothing particularly
interesting in that file and the referenced directory does not even
exist.  Time to drop the file?

Regards

Rolf

Bug#849289: git-annex: [RFE] youtube-dl support

[Rolf Leggewie]

Package: git-annex
Severity: wishlist
Tags: upstream

Dear Maintainer,

it would be nice if git-annex supported the youtube-dl package as an
alternative to quvi, especially considering that quvi is currently in
RFA status (bug #831732).

Regards

Rolf

Bug#836186: libreoffice: README.Debian-source is outdated

[Rolf Leggewie]

Package: src:libreoffice
Version: 1:5.2.0-2
Severity: normal

Dear Maintainer,

it seems that the information in README.Debian-source is obsolete.
Lines 131ff read:

"The .orig.tar.gz consists of the 6 seperate tarballs from
http://ftp.gwdg.de/pub/openoffice/stable/3.2.0/ of which some non-free
stuff has been removed:"

That directory contains only openoffice sources whereas Debian has
switched to Libreoffice quite a while ago.  It would be nice if you
found the time to go through this document and bring it up to date.

Thank you for the work of maintaining LO in Debian.

Regards

Rolf Leggewie

Bug#836185: libreoffice-mysql-connector: bug script is faulty

[Rolf Leggewie]

Package: libreoffice-mysql-connector
Version: 1:4.3.3-2+deb8u5
Severity: normal
Tags: patch

Dear Maintainer,

the libreoffice-mysql-connector bug script is faulty.  This leads to an
error when reporting a bug with reportbug.

"The package bug script /usr/share/bug/libreoffice-mysql-connector/script
exited with an error status (return code = 256). Do you still want to 
file a report?"

Please consider applying the attached patch to have it do the right
thing.  Proper credit in the changelog would be appreciated.

Regards

Rolf Leggewie
Author: Rolf Leggewie <f...@rolf.leggewie.biz>
Subject: fix bug script in libreoffice-mysql-connector

--- new/libreoffice-mysql-connector.bug-script.in	2016-08-31 17:53:49.446917134 +0800
+++ orig/libreoffice-mysql-connector.bug-script.in	2016-08-31 17:53:14.422743461 +0800
@@ -1,2 +1,2 @@
 #!/bin/sh
-/usr/lib/libreoffice/program/unopkg list --bundled mysql-connector-ooo >&3
+/usr/lib/libreoffice/program/unopkg list --bundled com.sun.star.mysql-connector-ooo-@PLATFORMID@ >&3

Bug#836184: libreoffice-mysql-connector: Please package the latest version of the mysql connector

[Rolf Leggewie]

Package: libreoffice-mysql-connector
Version: 1:4.3.3-2+deb8u5
Severity: normal

Dear Maintainer,

upstream has a newer version 1.0.4_3 for the mysql connector.  Please
consider to package it and upgrade from the current 1.0.2 version.

http://extensions.libreoffice.org/extension-center/mysql-native-connector

Regards

Rolf Leggewie

Bug#770884: scim: Scim segfaults when gtk3-engines-unico is installed

[Rolf Leggewie]

On Mon, 24 Nov 2014 17:06:34 -0500 Wyatt Ward  wrote:
> Package: scim
> Version: 1.4.14-5+b1
> Severity: normal
> Tags: l10n
>
> Dear Maintainer,
>
> I have had scim installed for a long time, and it always worked well.
Then when I installed the unico engine, scim-panel-gtk began segfaulting
and repeatedly restarting before crashing again.
>
> The problem resolves itself immediately upon the removal of the
package gtk3-engines-unico.

I've had gtk3-engines-unico installed forever and did not experience the
crashes you mention.  Is this still a problem for you?

Bug#826383: xpra hogs CPU

[Rolf Leggewie]

This is getting comical.

On 06.06.2016 00:26, Dmitry Smirnov wrote:
> If you reasonably suspect that Raspberry is not powerful enough for
> Xpra then why did you submit your bug in first place?

You crack me up.  Now, where did I say that?  You seem to be
hallucinating.  I'm merely observing that the CPU is saturated.  And
it's well-known that the CPU on the Raspberry isn't the beefiest.  That
doesn't mean I'd expect extended CPU hogging.  Quite the contrary,
especially since I can run graphical apps over ssh X forwarding without
any problem and with maybe 3-10% CPU consumption.

But then again, what do I know what xpra is doing in the background? And
indeed maybe there is a good explanation and it's likely not to change. 
Then this would be something that should be documented in README.Debian
if there is no way to improve performance.  Again, we know really
nothing at this point.  We merely have an observation of an odd
behaviour.  You stopped the bug triage in its tracks. OK...

> Too bad if you expected (much) more than this as I can't satisfy your
> expectations...

I'm only asking you to care enough for a package you claim you want to
maintain to actually maintain it.  And that means for example bug
triage, not ticket closing.

> There some reasons why your bug was closed:
> * No actionable tasks for maintainer.

Nonsense.  Apparently neither you nor I have any idea at this point if
the CPU or some other part of the RPi is indeed underpowered for xpra. 
Or if this is somehow a mismatch of versions/platforms/$whatnot.  Or
PEBKAC.  Or if it used to be a problem and no longer is in
backports/testing/unstable.  Just to name a few possibilities.  All I
know is that you don't seem to care to find out.  And that it's your job
as maintainer to _want_ to find out, during bug triage.  And that's why
you are not a good maintainer, even if you do not like to hear this
valid criticism.

> * Unsupported client from unsupported operating system.

Nonsense.

By the same token a critical security vulnerability in the Debian Apache
package isn't even a bug if it is triggered from a remote windows
client?  Or a segfault in a package because of malformed input that the
program didn't validate/discard?  How did you ever manage to become DD?

Seems like you missed the point again that the problem occurred in a
fully up-to-date Jessie system (not the Ubuntu system)?!

You've made it amply clear that you consider the version in Jessie
ancient and unsupported.  It hasn't really sunk in to your conscience
apparently that this disregard for stable still disqualifies you as
maintainer.  And obviously, you don't like to hear it, but I'll still
repeat it as that's simply the truth.  You signed up to be maintainer,
then be it, not only for unstable.

> * Not really a bug report but support request.

Buahahaha.

I think we've exchanged our points of view and it seems I won't be able
to convince you to take your job seriously.  Oh, well...

Have a great day.

Bug#826383: xpra hogs CPU

[Rolf Leggewie]

Hello Dmitry,

On 05.06.2016 21:10, Dmitry Smirnov wrote:
>> JFTR, the problem of high CPU load occured on a Jessie box.  Last I
>> looked, Jessie was still supported.
> Then please try Xpra from jessie-backports.

Not available for Raspbian.  But that's not an issue.  I can compile and
backport packages myself if necessary.  That can be part of meaningful
bug triage but shouldn't be the first, immediate and only response to
any problem in a stable release.  At least for a maintainer that cares
about quality software and user experience.

For example, you as maintainer would know if the Raspberry is simply
underpowered and 100% CPU on the simplest of tasks is to be expected
with xpra on such a host. Or you'd equally know if there had been issues
about a mix of versions of xpra causing problems for each other in the
past.  Or if you didn't know, as a good maintainer you'd be interested
to learn and find this out.  Bug triage.  Closing a ticket isn't the
most pressing concern for a good maintainer.

>> Now, I wish you a nice day.  Have fun closing tickets rather than fixing
>> problems and delivering kick-ass software as the latter does not seem to
>> be of much concern to you.
> Before jumping to conclusion you could consider submitting meaningful bug 
> report properly with enough information to troubleshoot the issue.

If you feel there wasn't enough information, you can always ask, you
know.  The most important information was there.  "Up-to-date Jessie box
talking to Trusty box causes high CPU load on the former".  Out there
for anyone who can be bothered to read.  Can you be bothered?

> Also you can consider seeking help upstream (since the problem is unlikely to 
> be Debian-specific) but you are likely to be told that 0.12.3 is an 
> unsupported version -- a something you should have known by now.

Funny, first you tell me to go downstream.  Now you tell me to go
upstream.  Well, actually you aren't really changing your message which
is "go away and don't bother me".  Fair enough.  But again, people with
that kind of attitude to users and bug triage don't make a good maintainer.

If the problem in all likelihood now isn't Debian-specific but actually
extends beyond it then why was the ticket closed?  That's not the usual
workflow.

I stand by my analysis of the quality of the work you delivered in your
first reaction to this ticket.

Bug#826383: xpra hogs CPU

[Rolf Leggewie]

Dmitry, as a fellow DM, I am sad to see your shitty attitude to
delivering quality software.  It's a sad regression to see you join xpra
maintenance for which you obviously lack the necessary desire for
delivering the best quality software experience.

JFTR, the problem of high CPU load occured on a Jessie box.  Last I
looked, Jessie was still supported.

Now, I wish you a nice day.  Have fun closing tickets rather than fixing
problems and delivering kick-ass software as the latter does not seem to
be of much concern to you.


On 05.06.2016 19:23, Dmitry Smirnov wrote:
> On Sunday, 5 June 2016 4:03:32 PM AEST Rolf Leggewie wrote:
>> Version: 0.12.3+dfsg-1
> You are using ancient (unsupported) release. Please upgrade and try again.
>
>
>> I have revisited using xpra today, connecting from a Ubuntu trusty
> Why do you seek Ubuntu support in Debian? Please upgrade to Debian.
> We do not support Ubuntu.
>
>
>> laptop to a Raspberry headless machine running Jessie.  The CPU on
>> the RPi is fully saturated from the xpra process when doing simple
>> things like hitting enter in the X terminal. Is xpra that
>> inefficient or is something amiss here?  Anything I can switch off
>> to lower the load?
> You can try to experiment with different encodings and other settings.
>
> I'm closing this bug since there is nothing actionable for maintainer here.
>
> Thank you for reporting the bug, which will now be closed.  If you
> have further comments please address them to 826...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>

Bug#826383: xpra hogs CPU

[Rolf Leggewie]

Package: xpra
Version: 0.12.3+dfsg-1
Severity: important

Dear Maintainer,

I have revisited using xpra today, connecting from a Ubuntu trusty
laptop to a Raspberry headless machine running Jessie.  The CPU on
the RPi is fully saturated from the xpra process when doing simple
things like hitting enter in the X terminal. Is xpra that
inefficient or is something amiss here?  Anything I can switch off
to lower the load?

Regards

Rolf

Bug#826382: xz-utils: git packaging repo not updated

[Rolf Leggewie]

Package: xz-utils
Version: v4.999.9beta+20100527-1
Severity: normal

Dear Maintainer,

the git packaging repo hasn't been updated for quite a while. It
would be nice if you did so.

Regards

Rolf


PS: Even more important is to upload upstream 5.2.2 -> #731634

Bug#520619: Debian BTS: pigz as gzip replacement

[Rolf Leggewie]

On Mon, 27 Apr 2015 16:18:44 +0200 Kernc  wrote:
> Are patches welcome?

Disclosure: I'm not the maintainer, but patches should always be
welcome, I suppose.  And the way I know Eduard, he is quick to act on
them, too.

Bug#824450: scanbd does not find scanner

[Rolf Leggewie]

Chris,

sorry for the delay in responding.

On 17.05.2016 13:50, Chris Laif wrote:
>> Is there a chance you can try Debian unstable for testing purposes on
>> your hardware?
> I can try some unstable packages as long it does not mess up the whole
> system, unfortunately it is not possible to dual-boot.
>
>> Do you know how to compile software on your own?
>>
> Yes, standard procedures shouldn't be a problem. You can even contact
> me via private mail if that helps.

Please try http://oss.leggewie.org/scanbd/scanbd_1.4.4-1rl1.dsc 

There are binary packages in that directory as well, but they are for
i386.  I added a bunch of tests for common configuration mistakes into
the latest init script.  Unfortunately, those didn't make it in time for
jessie.  Before changing the binary packages, try to replace
/etc/init.d/scanbd with the latest version from git
http://anonscm.debian.org/cgit/collab-maint/scanbd.git/plain/debian/scanbd.init 
It might be enough to inform you where your configuration is wrong.  Do
"/etc/init.d/scanbd status" and "/etc/init.d/scanbd restart" as root to
see you where you stand.  I am almost certain your problem is not a true
bug but a configuration mistake.

Regards

Rolf

Bug#779815: grub2: Re: grub-pc: hitting keys does NOT display menu with GRUB_HIDDEN_TIMEOUT

[Rolf Leggewie]

Package: grub2-common
Followup-For: Bug #779815

Dear Ian,

GRUB_HIDDEN_TIMEOUT has been deprecated for quite a while.  Please use
the alternatives.

`GRUB_HIDDEN_TIMEOUT'
 Wait this many seconds before displaying the menu. If  is
 pressed during that time, display the menu and wait for input
 according to `GRUB_TIMEOUT'. If a hotkey associated with a menu
 entry is pressed, boot the associated menu entry immediately. If
 the timeout expires before either of these happens, display the
 menu for the number of seconds specified in `GRUB_TIMEOUT' before
 booting the default entry.

 If you set `GRUB_HIDDEN_TIMEOUT', you should also set
 `GRUB_TIMEOUT=0' so that the menu is not displayed at all unless
  is pressed.

 This option is unset by default, and is deprecated in favour of
 the less confusing `GRUB_TIMEOUT_STYLE=countdown' or
 `GRUB_TIMEOUT_STYLE=hidden'.

Bug#806105: scim: FTBFS when built with dpkg-buildpackage -A (No such file or directory)

[Rolf Leggewie]

On 22.05.2016 18:27, Santiago Vila wrote:
> Hi.
>
> I've prepared two patches to fix this bug.

Thanks, Santiago.  I'm currently preparing an upload.

Bug#824450: scanbd does not find scanner

[Rolf Leggewie]

Hello Chris,

thank you for your report.

On 16.05.2016 17:07, Chris Laif wrote:
> Package: scanbd
> Version: 1.4.0-2
> Severity: important
>
> I've got a Canon scanner, which perfectly worked with Squeeze's
> scanbuttond. After upgrading to Jessie (fresh install, all packages up
> to date) the scanner is not recognized by scanbd.

Are you an an i386 or amd64 or some other system?
Is your device connected over USB3?
Is there a chance you can try Debian unstable for testing purposes on
your hardware?
Do you know how to compile software on your own?

Regards

Rolf

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Rolf Leggewie]

On 13.05.2016 12:26, Rolf Leggewie wrote:
> there's been some talk in http://bugs.debian.org/620391 about Roger
> Router and PEAS Python2 plugins.

Make that http://bugs.debian.org/817936

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Rolf Leggewie]

Jan-Michael,

there's been some talk in http://bugs.debian.org/620391 about Roger
Router and PEAS Python2 plugins.

As upstream, are you actually aware of any Plugins for Roger that are
Python 2?  I'd rather see them ported to Python 3 or become deprecated
than add a complicated web of additional dependencies to the Debian
package. Would it be acceptable to do "sed s/python/python3/
./libroutermanager/plugins.c" and require all python plugins to be
ported to python3 from now on?

FWIW, I'm not aware of any external, third-party plugins for Roger
Router, irrespective of their programming language.  Do they exist?

Regards

Rolf

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Rolf Leggewie]

On 13.05.2016 08:51, Rolf Leggewie wrote:
> Hello Barry,
>
> so, libpeas-1.0-0-python2loader has officially made it into Debian.  I'm
> now thinking how to deal with that for roger.
>
> On 03.04.2016 05:35, Barry Warsaw wrote:
>> On Apr 02, 2016, at 10:33 PM, Rolf Leggewie wrote:
>>
>> Hi Rolf,
>>
>>> I'm still at a loss what it is you are asking of me.  The title of this
>>> bug requests me to add a run-time dependency that doesn't even exist in
>>> Debian yet.  In Ubuntu the change you advocate has been made, but
>>> apparently there were no changes necessary for roger-router alongside. 
>>> In fact, roger-router in Ubuntu still depends on libpeas-1.0.0 and not
>>> libpeas-1.0-0-python2loader even though the package does exist there.
>> We should certainly fix roger-router in Ubuntu; I'm not sure how I missed 
>> that
>> one over there.  I'll file a bug and fix that early next week.
> Ubuntu is still unchanged both in Xenial and Yakkety.
>
> The title of this ticket suggests I should add an explicit dependency on
> libpeas-1.0-0-python2loader to Depends.  I'm a bit reluctant to do that
> since it would mean I need to maintain a fork since my main computer is
> trusty.  In any case, roger does not ship any python code at all.  My
> understanding is that it uses peas to allow third party plugins and
> those could be written in python or other programming languages.  I'm
> actually not aware of any plugins and they could be written in either
> python 2 or python 3.  Adding a strong dependency to the python 2 loader
> seems wrong to me.  I feel like adding a Suggests for
> "libpeas-1.0-0-python2loader|libpeas-1.0-0-python3loader" would be more
> appropriate.  Or should I be mistaken?  If it really needs to be a
> Depends wouldn't it be better to have debhelper and dh_shlibs take care
> of doing the right thing?

After further inspection of the peas packages in testing and unstable I
have now learned that the new libpeas-1.0-0 includes what I thought was
going to be carved out into libpeas-1.0-0-python3loader.

Barry, I think that adding "libpeas-1.0-python2loader | libpeas-1.0-0
(<< 1.16.0-1ubuntu1)" to Depends for libroutermanager0 (all other roger
binary packages depend on this one directly or indirectly) would fix
this ticket as well as allow me to build from the same code base for
trusty.  Seeing that libpeas-1.0-0-python3loader was indeed added to
Xenial (and Yakkety, so far, for that matter), I think that depending on
"libpeas-1.0-python2loader | libpeas-1.0-0 (<< 1.16.0-1ubuntu1),
libpeas-1.0-0 (>= 1.18.0-2) | libpeas-1.0-python3loader" would be needed
to support all of trusty, xenial and unstable from the same roger code
base.  This assumes that Ubuntu will later during the Yakkety cycle go
back to syncing libpeas from unstable and thus drop
libpeas-1.0-python3loader.

It would be appreciated if you confirmed this change for roger.

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Rolf Leggewie]

On 13.05.2016 11:22, Rolf Leggewie wrote:
> I think that depending on
> "libpeas-1.0-python2loader | libpeas-1.0-0 (<< 1.16.0-1ubuntu1),
> libpeas-1.0-0 (>= 1.18.0-2) | libpeas-1.0-python3loader" would be needed
> to support all of trusty, xenial and unstable from the same roger code
> base.

Actually, that would need to be

"libpeas-1.0-python2loader | libpeas-1.0-0 (<< 1.16.0-1ubuntu1),
libpeas-1.0-0 (>= 1.18.0-2) | libpeas-1.0-0 (<< 1.16.0-1ubuntu1) |
libpeas-1.0-python3loader"

Puh, quite involved, but I think the above should cover all cases.

It would be nice if Ubuntu merged libpeas-1.0-python3loader into
libpeas-1.0-0 for Xenial LTS.  Do you think such a thing has a chance to
be SRU'd?

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Rolf Leggewie]

Hello Barry,

so, libpeas-1.0-0-python2loader has officially made it into Debian.  I'm
now thinking how to deal with that for roger.

On 03.04.2016 05:35, Barry Warsaw wrote:
> On Apr 02, 2016, at 10:33 PM, Rolf Leggewie wrote:
>
> Hi Rolf,
>
>> I'm still at a loss what it is you are asking of me.  The title of this
>> bug requests me to add a run-time dependency that doesn't even exist in
>> Debian yet.  In Ubuntu the change you advocate has been made, but
>> apparently there were no changes necessary for roger-router alongside. 
>> In fact, roger-router in Ubuntu still depends on libpeas-1.0.0 and not
>> libpeas-1.0-0-python2loader even though the package does exist there.
> We should certainly fix roger-router in Ubuntu; I'm not sure how I missed that
> one over there.  I'll file a bug and fix that early next week.

Ubuntu is still unchanged both in Xenial and Yakkety.

The title of this ticket suggests I should add an explicit dependency on
libpeas-1.0-0-python2loader to Depends.  I'm a bit reluctant to do that
since it would mean I need to maintain a fork since my main computer is
trusty.  In any case, roger does not ship any python code at all.  My
understanding is that it uses peas to allow third party plugins and
those could be written in python or other programming languages.  I'm
actually not aware of any plugins and they could be written in either
python 2 or python 3.  Adding a strong dependency to the python 2 loader
seems wrong to me.  I feel like adding a Suggests for
"libpeas-1.0-0-python2loader|libpeas-1.0-0-python3loader" would be more
appropriate.  Or should I be mistaken?  If it really needs to be a
Depends wouldn't it be better to have debhelper and dh_shlibs take care
of doing the right thing?

Regards

Rolf

Bug#620391: marked as done (scim keeps crashing)

[Rolf Leggewie]

On 12.05.2016 15:54, Debian Bug Tracking System wrote:
> Your message dated Thu, 12 May 2016 16:51:38 +0900
> with message-id <87twi367ed@gentoo.org>
> and subject line Cannot reproduce on AMD64
> has caused the Debian Bug report #620391,
> regarding scim keeps crashing
> to be marked as done.

Benda,

thank you for your bug triage work.

We usually do not close tickets without either being able to point to a
specific code change that we are absolutely certain fixes the exact
issue reported or giving the original reporter a chance to report back
if the problem persists.  Crashes are usually much more troublesome to
triage from afar, so please exercise extra caution.

Michal, please speak up if you are still affected by this problem
especially if it is reproducible and I will look into how to reopen this
ticket.

Regards

Rolf

Bug#620391: marked as done (scim keeps crashing)

[Rolf Leggewie]

On 12.05.2016 16:01, Rolf Leggewie wrote:
> We usually do not close tickets without either being able to point to
> a specific code change that we are absolutely certain fixes the exact
> issue reported or giving the original reporter a chance to report back
> if the problem persists.

After visiting the BTS on the web I see that more information had been
requested as early as 2012 and the ticket had been tagged moreinfo since
2014.  So, it was indeed OK to close as WFM.

Benda, it would have been helpful if the closing mail had included a
mentioning of the missing information that had been requested from
Michal and without which there isn't anything we can do.

This ticket was indeed overdue for closure.  Thanks for the clean-up and
testing on your AMD64 system.

Bug#816337: prerm called with unknown argument `upgrade'

[Rolf Leggewie]

Package: scim
Followup-For: Bug #816337

Hello Dan,

thank you for this report.  This is odd. 1.4.15-5.1 is the version
where this should problem should be fixed.  Did the upgrade error
out or was this just informational?

I see this in your report:

> dpkg: trying script from the new package instead ...
> dpkg: ... it looks like that went OK

so I assume everything went OK afterwards?

Regards

Rolf

Bug#819977: jessie-pu: package roger-router/1.8.9-2jessie1

[Rolf Leggewie]

On 04.04.2016 16:58, Adam D. Barratt wrote:
>> I'd like to request to upload a bug-fix for the roger-router package
>> to Jessie.  This would fix bugs #798471 and #774116.
>>
>> Roger Router is a tool to interact with Fritzbox hardware from AVM.
>> One of the things it can do is to send a fax.  This was broken until
>> version 1.8.9-3 because compilation happened as --with-cups-yes
>> assuming this would include cups-support when in fact this disabled
>> a known-good code base for cups-support and replaced it with a
>> known-broken, experimental one.  The patches are cherry-picked from
>> 1.8.9-3 and 1.8.9-4.
>
> Please provide a source debdiff of the proposed package as built and
> tested on Jessie, rather than indvidual patches; that's what we'll be
> acking (or otherwise). 

Sure.

I thought the individual patches would be easier to inspect and
approve/reject as necessary.  Attached is a single debdiff.
diff --git a/debian/README.Debian b/debian/README.Debian
index 13996bd..7a06d73 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -1,3 +1,5 @@
+= Configuration =
+
 configuration help is available from
 
 http://wiki.ubuntuusers.de/FritzBox/Roger_Router
@@ -6,10 +8,17 @@ http://forum.ubuntuusers.de/topic/roger-router-roger/
 http://en.tabos.org/installation-prequel
 
 If you want to use the incoming call notification you will have to enable
-it on your fritzbox with: #96*5*
-
-If you want to use the capifax plugin you will have to enable capi-over-tcp
-on your fritzbox with: #96*3*
+it on your fritzbox with: #96*5*  If you want to use the capifax plugin
+you will have to enable capi-over-tcp on your fritzbox with: #96*3*  Both
+of these settings will be reset to their default value of "off" whenever
+you update the router firmware.  Please reenable them as necessary.
 
 Please note, quick reconnect & display external ip in tooltip for Fritz!Box
 needs active UPnP support!
+
+= Fax support =
+
+Roger installs a Cups printer.  To be able to fax, you either need to use
+roger_cli where you specify all necessary information including the number
+to send to on the command line or you should have Roger GUI running and it
+will prompt you for the receiving Fax number.
diff --git a/debian/changelog b/debian/changelog
index f02d242..fa2aca8 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+roger-router (1.8.9-2jessie1) stable; urgency=medium
+
+  backport fixes to fax support from 1.8.9-3 and 1.8.9-4
+
+  * do not build the experimental (!) cups backend.
+Closes: #774116, closes: #798471.
+
+Upstream uses a very funny (NOT!) semantics to their make-switches.
+Who would expect that "--with-cups=yes" actually DISABLES a working
+cups support?
+
+  * README.Debian:
+- add some information on how to send a fax
+- add information what needs to be done after firmware updates
+  certain functions, such as fax support, will be reset to being
+  disabled every time a new firmware is installed
+
+ -- Rolf Leggewie <f...@rolf.leggewie.biz>  Mon, 04 Apr 2016 15:14:08 +0200
+
 roger-router (1.8.9-2) unstable; urgency=low
 
   * copyright: add copyright information for win32/printer/ghostpdf.ppd
diff --git a/debian/control b/debian/control
index a1df6d4..b660a8f 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,7 @@ Uploaders: Jan-Michael Brummer <jan.brum...@tabos.org>
 Build-Depends: debhelper (>= 9), dh-autoreconf,
  libappindicator3-dev,
  libcapi20-dev (>= 1:3.24),
- libcups2-dev,
  libebook1.2-dev,
- libgconf2-dev,
  libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev,
  libgtk-3-dev,
  libnotify-dev,
diff --git a/debian/libroutermanager0.symbols b/debian/libroutermanager0.symbols
index 1d29ec1..7e302d9 100644
--- a/debian/libroutermanager0.symbols
+++ b/debian/libroutermanager0.symbols
@@ -81,7 +81,7 @@ libroutermanager.so.0 libroutermanager0 #MINVER#
  fax_send@Base 1.8.4
  fax_set_log_level@Base 1.8.4
  fax_spandsp_workaround@Base 1.8.4
- fax_spooler_new_dir_cb@Base 1.8.4
+#MISSING: 1.8.9-2# fax_spooler_new_dir_cb@Base 1.8.4
  fax_transfer@Base 1.8.4
  faxophone_close@Base 1.8.4
  faxophone_connect@Base 1.8.4
diff --git a/debian/roger-router-cli.install b/debian/roger-router-cli.install
index d8d4c6b..1379a1c 100644
--- a/debian/roger-router-cli.install
+++ b/debian/roger-router-cli.install
@@ -1,8 +1,7 @@
 usr/bin/roger_cli
 usr/lib/*/routermanager/
-usr/lib/cups/backend/roger-cups
 usr/share/man/*/roger_cli*
-usr/share/roger/roger-cups
+usr/share/roger/roger-cups usr/lib/cups/backend/
 usr/share/roger/roger-fax.ppd
 usr/share/roger/install-fax.sh
 
diff --git a/debian/rules b/debian/rules
index 95b94a1..c7c5f2f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,7 +13,6 @@ override_dh_auto_configure:
dh_auto_configure -- \
--with-spandsp=6 \
--with-libn

Bug#798471: roger-router: "Cannot set file owner for /var/spool/roger/" when using fax printer

[Rolf Leggewie]

On 06.04.2016 18:35, tcrass wrote:
> one funny thing: There are two identical RogerRouter icons in my KDE
> system tray, both of which feature the same menu, albeit slightly
> different in styling. Seems not to affect functionality, though.

Ist this a new problem, not present in 1.8.9-2?  In any case, please
file a separate ticket about this.

Bug#798471: roger-router: "Cannot set file owner for /var/spool/roger/" when using fax printer

[Rolf Leggewie]

On 06.04.2016 13:56, tcrass wrote:
> dpkg: dependency problems prevent configuration of libroutermanager0:
>  libroutermanager0 depends on libcapi20-3; however:
>   Package libcapi20-3:i386 is not installed.

> So still no luck installing you packages...

Ah, right.  Actually not surprising.  You have an amd64-system. My
packages are for i386.  I've prepared amd64-packages now at
http://oss.leggewie.org/bdo798471/

Bug#798471: roger-router: "Cannot set file owner for /var/spool/roger/" when using fax printer

[Rolf Leggewie]

On 06.04.2016 10:47, tcrass wrote:
> I have the impression that I cannot install your packages without
> severely deviating my system from its current "stable" state.

Your current situation is anything but stable.  Apparently, there's a
bunch of other packages waiting to be installed or waiting for their
dependencies to be installed.  I was also of the impression that you
have roger from the jessie repository installed which is not the case.

Here's what I suggest you do.

1) remove the three packages for roger
2) make sure "aptitude install -f" runs through fine
3) "aptitude install roger" (from the jessie repo)
4) try once more what I suggested in yesterday's mail

Bug#798471: roger-router: "Cannot set file owner for /var/spool/roger/" when using fax printer

[Rolf Leggewie]

On 05.04.2016 21:01, tcrass wrote:
> Rolf,
>
> > It would actually be very helpful if you installed the packages from
>> http://oss.leggewie.org/bdo798471/ and report back if they work for you.
>
> I downloaded the roger-router_1.8.9-2jessie1_i386.deb package from the
> mentioned URL, but when running
>
> sudo dpkg -i roger-router_1.8.9-2jessie1_i386.deb
>
> I just get a bunch of unpleasent messages:

roger-router needs roger-router-cli and libroutermanager0

Try

"cd tmp;for file in wget libroutermanager0_1.8.9-2jessie1_i386.deb
roger-router-cli_1.8.9-2jessie1_i386.deb
roger-router_1.8.9-2jessie1_i386.deb ; do wget
http://oss.leggewie.org/bdo798471/$file;sudo dpkg -i $file;done"

Then fix the other dependencies by installing them from the repositories.

Bug#798471: roger-router: "Cannot set file owner for /var/spool/roger/" when using fax printer

[Rolf Leggewie]

On 04.04.2016 16:53, tcrass wrote:
> thank you so much! 

It would actually be very helpful if you installed the packages from
http://oss.leggewie.org/bdo798471/ and report back if they work for you.

Bug#798471: roger-router: "Cannot set file owner for /var/spool/roger/" when using fax printer

[Rolf Leggewie]

Package: roger-router
Followup-For: Bug #798471

Feel free to test the Jessie packages available at
http://oss.leggewie.org/bdo798471/

Bug#798471: roger-router: "Cannot set file owner for /var/spool/roger/" when using fax printer

[Rolf Leggewie]

Package: roger-router
Followup-For: Bug #798471

fixed 798471 1.8.9-3
tags 798471 jessie patch pending
thanks

Thorsten, tank you for the report.

I've prepared the necessary patches for jessie and requested upload
permission in bug 819977.

Bug#819977: jessie-pu: package roger-router/1.8.9-2jessie1

[Rolf Leggewie]

Package: release.debian.org
Severity: normal
Tags: jessie
User: release.debian@packages.debian.org
Usertags: pu

Hello,

first of all, reportbug lists only squeeze and wheezy when making a
pu-related bug report.

I'd like to request to upload a bug-fix for the roger-router package
to Jessie.  This would fix bugs #798471 and #774116.

Roger Router is a tool to interact with Fritzbox hardware from AVM.
One of the things it can do is to send a fax.  This was broken until
version 1.8.9-3 because compilation happened as --with-cups-yes
assuming this would include cups-support when in fact this disabled
a known-good code base for cups-support and replaced it with a
known-broken, experimental one.  The patches are cherry-picked from
1.8.9-3 and 1.8.9-4.

I'd like to ship alongside some improvements in the README.Debian file
to guide the user in case they run into problems.

These changes should have little risk of regression and improve the
user experience for stable customers considerably.

Looking forward to your comments.

Regards

Rolf Leggewie
>From 67bc92d83524ebce8c3c0253d19e509c2556e2ce Mon Sep 17 00:00:00 2001
From: Rolf Leggewie <f...@rolf.leggewie.biz>
Date: Sat, 8 Nov 2014 22:59:00 +0800
Subject: [PATCH 1/4] do not build the experimental (!) cups backend. Closes:
 #798471, Closes: #774116

OMG.  the compilation switch "--with-cups" doesn't mean what
you'd expect.  It means "build the experimental, known-broken,
WIP (!) version of cups-support", and disable the standard,
working cups backend. Who in their right mind would expect
that kind of semantic?

Of course, upstream didn't document this anywhere. Grr!
---
 debian/control   | 2 --
 debian/libroutermanager0.symbols | 2 +-
 debian/roger-router-cli.install  | 3 +--
 debian/rules | 3 +--
 4 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/debian/control b/debian/control
index a1df6d4..b660a8f 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,7 @@ Uploaders: Jan-Michael Brummer <jan.brum...@tabos.org>
 Build-Depends: debhelper (>= 9), dh-autoreconf,
  libappindicator3-dev,
  libcapi20-dev (>= 1:3.24),
- libcups2-dev,
  libebook1.2-dev,
- libgconf2-dev,
  libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev,
  libgtk-3-dev,
  libnotify-dev,
diff --git a/debian/libroutermanager0.symbols b/debian/libroutermanager0.symbols
index 1d29ec1..7e302d9 100644
--- a/debian/libroutermanager0.symbols
+++ b/debian/libroutermanager0.symbols
@@ -81,7 +81,7 @@ libroutermanager.so.0 libroutermanager0 #MINVER#
  fax_send@Base 1.8.4
  fax_set_log_level@Base 1.8.4
  fax_spandsp_workaround@Base 1.8.4
- fax_spooler_new_dir_cb@Base 1.8.4
+#MISSING: 1.8.9-2# fax_spooler_new_dir_cb@Base 1.8.4
  fax_transfer@Base 1.8.4
  faxophone_close@Base 1.8.4
  faxophone_connect@Base 1.8.4
diff --git a/debian/roger-router-cli.install b/debian/roger-router-cli.install
index d8d4c6b..1379a1c 100644
--- a/debian/roger-router-cli.install
+++ b/debian/roger-router-cli.install
@@ -1,8 +1,7 @@
 usr/bin/roger_cli
 usr/lib/*/routermanager/
-usr/lib/cups/backend/roger-cups
 usr/share/man/*/roger_cli*
-usr/share/roger/roger-cups
+usr/share/roger/roger-cups usr/lib/cups/backend/
 usr/share/roger/roger-fax.ppd
 usr/share/roger/install-fax.sh
 
diff --git a/debian/rules b/debian/rules
index 95b94a1..c7c5f2f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,7 +13,6 @@ override_dh_auto_configure:
 	dh_auto_configure -- \
 		--with-spandsp=6 \
 		--with-libnotify=yes \
-		--with-cups=yes \
 		--with-secret=yes \
 		--with-ebook=yes \
 		--with-gstreamer1=yes \
@@ -32,7 +31,7 @@ override_dh_install:
 
 override_dh_fixperms:
 	dh_fixperms
-	chmod 755 debian/roger-router-cli/usr/share/roger/roger-cups
 	chmod 755 debian/roger-router-cli/usr/share/roger/install-fax.sh
+	chmod 755 debian/roger-router-cli/usr/lib/cups/backend/roger-cups
 	chown lp.fax debian/roger-router-cli/var/spool/roger
 	chmod 2770 debian/roger-router-cli/var/spool/roger
-- 
1.9.1

>From ad80ff407b739f4975325fce7524dbe4ed740c86 Mon Sep 17 00:00:00 2001
From: Rolf Leggewie <f...@rolf.leggewie.biz>
Date: Sat, 7 Mar 2015 15:39:51 +0800
Subject: [PATCH 2/4] README.Debian: add some information on how to send a fax

---
 debian/README.Debian | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/debian/README.Debian b/debian/README.Debian
index 13996bd..8bb1f9f 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -1,3 +1,5 @@
+= Configuration =
+
 configuration help is available from
 
 http://wiki.ubuntuusers.de/FritzBox/Roger_Router
@@ -8,8 +10,15 @@ http://en.tabos.org/installation-prequel
 If you want to use the incoming call notification you will have to enable
 it on your fritzbox with: #96*5*
 
+Please note, quick reconnect & display external ip in tooltip for Fritz!Box
+needs active UPnP support!
+
+= Fax support =
+
 If you want to use the capifax plugin you will have to enable capi-

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Rolf Leggewie]

On 02.04.2016 23:35, Barry Warsaw wrote:
> I look at this as a tracking bug - something that needs to happen if another
> bug gets resolved, but nothing to do right now.

Thank you for the clarification.

I'll keep this ticket open in the spirit your explained above.

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Rolf Leggewie]

On 02.04.2016 21:34, Barry Warsaw wrote:
> to reduce the overall dependence on Python 2 in Debian. We've already
> made this split in Ubuntu and haven't seen any reports of problems

Barry,

thank you for the quick response.

I'm still at a loss what it is you are asking of me.  The title of this
bug requests me to add a run-time dependency that doesn't even exist in
Debian yet.  In Ubuntu the change you advocate has been made, but
apparently there were no changes necessary for roger-router alongside. 
In fact, roger-router in Ubuntu still depends on libpeas-1.0.0 and not
libpeas-1.0-0-python2loader even though the package does exist there.

Should I be mistaken to think that this ticket is invalid?

Regards

Rolf

Bug#817936: roger-router: Please add libpeas-1.0-0-python2loader to Depends

[Rolf Leggewie]

Barry,

On 11.03.2016 19:45, Barry Warsaw wrote:
> In bug #806824 I propose to split the Python loaders for libpeas into
> separate binary packages.

That split hasn't happened yet and it isn't even clear if
libpeas-1.0-0-python2loader will ever hit the archive.  To file this bug
looks a bit premature.  Currently, there's nothing to be done and it's
not clear if there ever will be.

Regards

Rolf

Bug#799580: pastebinit: fails with http_s_://paste.debian.net

[Rolf Leggewie]

On Sat, 24 Oct 2015 01:06:46 +0200 Alberto Fuentes  wrote:
> pastebinit doesnt really support https. I attach some patches that enables
> https in the configuration

Stuart and Alberto,

thank you for the report and the patches.  Pastebinit 1.5 has just been
released and as you can see all patches submitted to this ticket have
landed.

https://code.launchpad.net/~pastebinit-developers/pastebinit/trunk

Regards

Rolf

Bug#670485: pastebinit: support hidden pastes

[Rolf Leggewie]

Paul and Alberto,

thank you for the report and the patches.  Pastebinit 1.5 has just been
released and as you can see your patch for this ticket landed upstream.

https://code.launchpad.net/~pastebinit-developers/pastebinit/trunk

Regards

Rolf

Bug#803237: test.sh does not pass

[Rolf Leggewie]

Alberto,

thank you for the report and the patches.  Pastebinit 1.5 has just been
released and as you can see quite a few of your patches made it.

https://code.launchpad.net/~pastebinit-developers/pastebinit/trunk

Here are the reasons for those that did not make it.

0001: Unacceptable upstream, requires an external python module (requests)
0003: No longer necessary, had apparently already been fixed in VCS
0005: No longer necessary, pastebin.com has been fixed
0006: No longer necessary, both pastebins were removed
 one is just dead and the other requires some kind of token now
0007: No longer necessary

Regards

Rolf

Bug#814396: twinkle: Unable to add myself to Uploaders

[Rolf Leggewie]

Package: twinkle
Severity: normal
Tags: patch

Dear Peter,

I tried to add myself to Uploaders for twinkle as previously discussed
but the git repo would not let me make any changes.  What do I need to
do?

Regards

Rolf
k
diff --git a/debian/control b/debian/control
index 9cdf669..5af6b99 100644
--- a/debian/control
+++ b/debian/control
@@ -2,7 +2,7 @@ Source: twinkle
 Section: comm
 Priority: optional
 Maintainer: Debian VoIP Team <pkg-voip-maintain...@lists.alioth.debian.org>
-Uploaders: Peter Colberg <pe...@colberg.org>
+Uploaders: Peter Colberg <pe...@colberg.org>, Rolf Leggewie <f...@rolf.leggewie.org>
 Build-Depends: bison,
cmake,
debhelper (>= 9),

Bug#810457: scanbd: please switch to libusb 1.0

[Rolf Leggewie]

On 13.01.2016 20:26, Aurelien Jarno wrote:
> Please change the build-depends

OK.

I was thinking of doing it as "Build-Depends:
libusb-1.0-0-dev|libusb-dev".  Any reason not to do that?  It is
technically correct that the package can build against either of the two
versions.  Thank you for your guidance.

Bug#810457: scanbd: please switch to libusb 1.0

[Rolf Leggewie]

On 09.01.2016 02:38, Aurelien Jarno wrote:
> Package: scanbd
> Version: 1.4.1-7
> Severity: wishlist
>
> Dear Maintainer,
>
> scanbd has a build-depends on libusb-dev. A few years ago upstream
> has released a new major version libusb 1.0 with a different API which
> aims to fix design deficiencies with USB 2.0 and 3.0 in mind.
>
> The old libusb 0.1 package is not supported upstream anymore and should
> be considered deprecated.
>
> If scanbd supports the new libusb 1.0 library, please consider
> switching the build-depends from libusb-dev to libusb-1.0-0-dev.

Aurelien, thank you for the heads-up.

I specifically set the build dependency to libusb-dev to avoid
dependency on a specific version.  I believe you are the maintainer of
the libusb-dev package.  Do you plan to point that libusb version 1.0
eventually?  That's the way I was hoping to do the migration.

I tested today and the package scanbd compiles fine.  The binary package
seems to run fine as well.  It turns out the bug you reported would be a
non-issue on upgrade to the new API of libusb-dev.  What do you suggest
to do considering my preference to stay version-agnostic in the build
dependencies.

Regards

Rolf

Bug#746554: Bug#770603: fte - package sponsorship

[Rolf Leggewie]

On 05.01.2016 03:40, Iain R. Learmonth wrote:
> Do you still require a sponsor for these packages?

Ian, thank you for your message.  Yes, I'm still looking for a sponsor
for these packages.  They expired on mentors.debian.net so I uploaded
them again.

https://mentors.debian.net/package/libfte
https://mentors.debian.net/package/fteproxy

http://mentors.debian.net/debian/pool/main/libf/libfte/libfte_0.1.0-1.dsc
http://mentors.debian.net/debian/pool/main/f/fteproxy/fteproxy_0.2.19-1.dsc

As I believe you are aware some previous potential sponsors objected to
the tight coupling of FTE with obfsproxy.

Bug#786165: This bug is not RC

[Rolf Leggewie]

Mattia, thanks again for your work.

Bug#786165: This bug is not RC

[Rolf Leggewie]

On 29.12.2015 03:53, Mattia Rizzolo wrote:
> control: severity -1 serious
>
> On Mon, Dec 28, 2015 at 12:13:52AM +0800, Rolf Leggewie wrote:
>> severity 786165 important
> this bug IS RC: python-support was just removed from the archive


Mattia,

merry Christmas!  Your work is appreciated, talking to a smart-ass
usually isn't as you can imagine.

This bug was not RC at the first time you marked it as such.  It was not
RC at the time I downgraded it back to non-RC.  You were even
specifically told *not* to mark bugs prematurely as RC in 746741 with
regards to the removal of python-support.  You still went ahead and did
it nonetheless only about 24 hours later :-(.  You are right that this
bug is RC now.

I do not plan to introduce 0.6.9 into Debian yet, so I do not want to
accept your NMU to unstable.  Feel free to redirect it to experimental. 
Please be sure not to push your changes to the master branch in git, use
a separate branch instead.  Thank you for your work.

Regards & Happy New Year

Rolf

Bug#746554: changing back to ITP

[Rolf Leggewie]

retitle 746554 ITP: fteproxy -- programmable proxy for censorship circumvention
owner 746554 !
retitle 770603 ITP: libfte -- encryption library to thwart deep packet 
inspection censorship
owner 770603 !
thanks

packages have been waiting for sponsorship

Bug#786165: gbirthday and python-support

[Rolf Leggewie]

Hello guys,

thank you for working on this bug. I'm happy some work has been done in
experimental already.

What I do not understand is why this bug is marked as RC.  As far I am
aware removal of python-support is not an RC-goal.  I think this ticket
should be downgraded.

Mattia, do you have your changes in git somewhere?  It would be nice if
you pushed them to a separate branch in alioth.  I'd like to cherry-pick
the stuff I like.

I haven't been able to upload for several months and I believe the issue
with my key is as of now still unresolved.  I'll have to look into it again.

Regards

Rolf

Bug#661110: RFA: isdnutils -- ISDN utilities

[Rolf Leggewie]

On 11.12.2015 04:05, Joachim Wiedorn wrote:
> Hello Rolf,
>
> I have seen there is a problem with the pppdcapiplugin package 
> because of changes of the ppp package.
>
> I think about overtaking isdnutils.

> What do you think about break out capiutils as standalone source
> package (similar to libcapi20-3) and let isdnutils package "die"?

Joachim,

thank you for picking this up.  The package is up for adoption so
essentially you are free to do as you please.  Thanks for asking.  You
might want to consider to do as I did which was to upload a separate new
package that built and for the sake of higher version took over one of
the binary packages of the old isdnutils source package.  The left-over
still remains.  This approach requires to pass through NEW but that is
the cleanest solution.  isdnutils can then either continue to exist or
eventually die off.  I don't feel like killing it explicitly.

Regards

Rolf

Bug#762871: tora: offers only MySQL connections

[Rolf Leggewie]

On Thu, 25 Sep 2014 22:23:27 +0200 Axel Stammler
 wrote:
> I would like to connect to a Postgres server but the ‘connection 
> provider’ list only
> contains ‘MySQL’.

Unfortunately, the (inactive) Debian maintainer of the package made a
conscious choice about this.  Not very user-friendly, but that's what it
is.  See bug 560687 for further information.

You need to install the appropriate libqt4-sql-* packages.

Bug#551680: Please package debug symbols as polipo-dbg

[Rolf Leggewie]

On Mon, 19 Oct 2009 14:09:09 -0700 Josh Triplett j...@joshtriplett.org
wrote:
 Please consider creating a package of debug symbols.

I'd gladly upload a fix for this package but since it introduces a new
package it has to go through NEW and such uploads can only be done by a
sponsoring DD not a DM.

Looking for sponsors to
http://mentors.debian.net/debian/pool/main/p/polipo/polipo_1.1.1-7.dsc

Bug#791275: scim: library transition may be needed when GCC 5 is the default

[Rolf Leggewie]

On Tue, 21 Jul 2015 18:57:49 +0200 Matthias Klose d...@debian.org wrote:
 Control: tags -1 + confirmed
 
 needs a transition, or else plasma at least fails to build from source.


Thanks, Matthias, for your work on the transition.  I tried to upload
the corresponding change last week but since this introduces a new
package a DM like me cannot do it. Are you willing to sponsor?

http://mentors.debian.net/debian/pool/main/s/scim/scim_1.4.15-5.dsc


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

Bug#655852: polipo: Polipo should log queries/fetches.

[Rolf Leggewie]

On Sat, 14 Jan 2012 22:01:44 +1100 Donovan Baarda
a...@minkirri.apana.org.au wrote:
 Package: polipo
 Version: 1.0.4.1-1.1
 Severity: wishlist
 
 Dear Maintainer,
 
 I'm used to using squid and using its logs to generate stats useful
 for analysing traffic and proxy performance. This has been very useful
 for tuning cache perfomance and identifying popular and/or problematic
 servers.

https://github.com/jech/polipo/pull/35


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

Bug#426402: apt: Need better way to specify mirrors for Debian repositiories

[Rolf Leggewie]

On Mon, 28 May 2007 17:07:11 +0300 David Baron d_ba...@012.net.il wrote:
 Package: apt
 Version: 0.6.46.4-0.1
 Severity: wishlist
 
 I am sure this is not original. Applies to Debian package repositories since
 they have a uniform structure:
 
 Sometimes (like now!), not all packages have made it to all mirrors, or
 one's favorite, closest mirror is down. I would like a better way of
 specifitying Debian mirrors. Foreign repos would remain is now and the
 current syntax would remain valid for Debian as well.
 
 Something like:
 Debian Mirrors:
 Preferred Mirror: ftp://...
 Mirror 2: http://...
 Mirror 3 ...
 End Debian Mirrors

sounds a lot like the mirror method available in apt nowadays. Time to
close this ticket as fixed?


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

Bug#780608: ITP: freelan -- P2P VPN daemon

[Rolf Leggewie]

Package: wnpp
Severity: wishlist
Owner: Rolf Leggewie debian-b...@rolf.leggewie.biz

* Package name: freelan
  Upstream Author : Julien Kaufmann
* URL : http://www.freelan.org/
* License : (GPL)
  Programming Lang: (C, C++, Python)
  Description : P2P VPN daemon

 Freelan is an application to create secure ethernet tunnels over a
 single UDP port. It can be used to create virtual LANs (Local
 Area Network), hence the name: freelan.
 .
 Freelan may create peer-to-peer tunnel connections or rely on a
 more classic client/server layout. The virtual network can be
 shaped to fit exactly the bandwidth or topology constraints,
 providing an optimal virtual private network.
 .
 Freelan is particularly useful for remote sites interconnection and
 gaming.


I already maintain n2n and was intruiged by the nice feature set
and active development offered by freelan.  I plan to maintain
the package together with upstream.  I might need a sponsor.


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

Bug#780328: roger-router: Debian package does not prevent storing the router password in plain text

[Rolf Leggewie]

Package: roger-router
Version: 1.8.9-3
Severity: normal
Tags: upstream

The package saves encrypted passwords if the necessary key manager is
installed and running (this can be either gnome-keyring or the kwallet
package).  But it is possible that the password will be saved in
plaintext if those conditions are not met.  The user can easily verify
the existence of any plaintext passwords via

dconf dump /org/tabos/routermanager/|grep pass

If desired, the whole configuration can be dropped, including the
password via dconf reset -f /org/tabos/.

The Debian package should do better in protecting the password at
all times.  One of the difficulties is that the password managers
rely on X, whereas the goal of the CLI package is to provide support
even in headless environments.

Even after fixing this issue going forward, one thing to keep in mind
as well is how to deal with passwords already stored in plaintext.
Should the user be warned and if so, how? Should they be erased?

After the above difficulties have been sorted out and tested,
appropriate runtime dependencies on gnome-keyring|kwallet ought
to be added.

http://de.tabos.org/forum/viewtopic.php?f=6t=3749


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

Bug#780285: unblock: roger-router/1.8.9-2jessie1

[Rolf Leggewie]

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

Please unblock package roger-router

Dear Release Team,

as maintainer of the roger-router package I would like to upload a fix
for #774116.  I've already uploaded a fix to experimental and I would
like to upload it to unstable as 1.8.9-2jessie1 and have it migrate
eventually.  I'd like to request a freeze exception before actually
doing that.

Faxing via the FritzBox device is one of the important functions of
Roger Router.  It is currently known-broken in testing.  The background
is that upstream has a makefile switch --with-cups which when set to
yes builds an experimental, known-broken cups-support.  Building as
--with-cups=no actually builds the working CUPS support. Go figure!
That tripped me and I would like to correct this mistake before jessie
gets released.

Regards

Rolf Leggewie

unblock roger-router/1.8.9-2jessie1
From a59161f6e088cf254438946433f7ef373fded9ba Mon Sep 17 00:00:00 2001
From: Rolf Leggewie f...@rolf.leggewie.biz
Date: Sat, 8 Nov 2014 22:59:00 +0800
Subject: [PATCH 1/2] do not build the experimental (!) cups backend. Closes: #774116
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

OMG.  the compilation switch --with-cups doesn't mean what
you'd expect.  It means build the experimental, known-broken,
WIP (!) version of cups-support, and disable the standard,
working cups backend. Who in their right mind would expect
that kind of semantic?

Of course, upstream didn't document this anywhere. Grr!

I was unable to verify this personally, but Dieter Schäfer and
Markus Grunwald kindly confirmed that the test packages I put out
for the purpose work fine for him. Thanks!
---
 debian/control   | 2 --
 debian/libroutermanager0.symbols | 2 +-
 debian/roger-router-cli.install  | 3 +--
 debian/rules | 3 +--
 4 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/debian/control b/debian/control
index a1df6d4..b660a8f 100644
--- a/debian/control
+++ b/debian/control
@@ -6,9 +6,7 @@ Uploaders: Jan-Michael Brummer jan.brum...@tabos.org
 Build-Depends: debhelper (= 9), dh-autoreconf,
  libappindicator3-dev,
  libcapi20-dev (= 1:3.24),
- libcups2-dev,
  libebook1.2-dev,
- libgconf2-dev,
  libgstreamer1.0-dev, libgstreamer-plugins-base1.0-dev,
  libgtk-3-dev,
  libnotify-dev,
diff --git a/debian/libroutermanager0.symbols b/debian/libroutermanager0.symbols
index 1d29ec1..7e302d9 100644
--- a/debian/libroutermanager0.symbols
+++ b/debian/libroutermanager0.symbols
@@ -81,7 +81,7 @@ libroutermanager.so.0 libroutermanager0 #MINVER#
  fax_send@Base 1.8.4
  fax_set_log_level@Base 1.8.4
  fax_spandsp_workaround@Base 1.8.4
- fax_spooler_new_dir_cb@Base 1.8.4
+#MISSING: 1.8.9-2# fax_spooler_new_dir_cb@Base 1.8.4
  fax_transfer@Base 1.8.4
  faxophone_close@Base 1.8.4
  faxophone_connect@Base 1.8.4
diff --git a/debian/roger-router-cli.install b/debian/roger-router-cli.install
index d8d4c6b..1379a1c 100644
--- a/debian/roger-router-cli.install
+++ b/debian/roger-router-cli.install
@@ -1,8 +1,7 @@
 usr/bin/roger_cli
 usr/lib/*/routermanager/
-usr/lib/cups/backend/roger-cups
 usr/share/man/*/roger_cli*
-usr/share/roger/roger-cups
+usr/share/roger/roger-cups usr/lib/cups/backend/
 usr/share/roger/roger-fax.ppd
 usr/share/roger/install-fax.sh
 
diff --git a/debian/rules b/debian/rules
index 95b94a1..c7c5f2f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -13,7 +13,6 @@ override_dh_auto_configure:
 	dh_auto_configure -- \
 		--with-spandsp=6 \
 		--with-libnotify=yes \
-		--with-cups=yes \
 		--with-secret=yes \
 		--with-ebook=yes \
 		--with-gstreamer1=yes \
@@ -32,7 +31,7 @@ override_dh_install:
 
 override_dh_fixperms:
 	dh_fixperms
-	chmod 755 debian/roger-router-cli/usr/share/roger/roger-cups
 	chmod 755 debian/roger-router-cli/usr/share/roger/install-fax.sh
+	chmod 755 debian/roger-router-cli/usr/lib/cups/backend/roger-cups
 	chown lp.fax debian/roger-router-cli/var/spool/roger
 	chmod 2770 debian/roger-router-cli/var/spool/roger
-- 
1.9.1

From d89739a8fceda7f2b0897476f8b4daf42ab53428 Mon Sep 17 00:00:00 2001
From: Rolf Leggewie f...@rolf.leggewie.biz
Date: Sat, 7 Mar 2015 15:39:51 +0800
Subject: [PATCH 2/2] README.Debian: add some information on how to send a fax

---
 debian/README.Debian | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/debian/README.Debian b/debian/README.Debian
index 13996bd..8bb1f9f 100644
--- a/debian/README.Debian
+++ b/debian/README.Debian
@@ -1,3 +1,5 @@
+= Configuration =
+
 configuration help is available from
 
 http://wiki.ubuntuusers.de/FritzBox/Roger_Router
@@ -8,8 +10,15 @@ http://en.tabos.org/installation-prequel
 If you want to use the incoming call notification you will have to enable
 it on your fritzbox with: #96*5*
 
+Please note, quick reconnect  display external ip in tooltip for Fritz!Box
+needs active UPnP support!
+
+= Fax support

Bug#774116: Bug is still there

[Rolf Leggewie]

Peter,

thank you for your message.  It seems you forgot to include the Debian
BTS, please don't message me privately, let's keep it in the bug
tracker.  I will fullquote your message for reference.

On 12.03.2015 00:16, Peter Schütt wrote:
 Hallo,
 
 I never use aptitude so did the following:
 
 apt-get --purge remove roger-router-cli
 
 apt-get -t experimental install roger-router
 
 dpkg -l roger*
 Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
 | Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
  Halb installiert/Trigger erWartet/Trigger anhängig
 |/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler:
 GROSS=schlecht)
 ||/ Name  Version   Architektur  
 Beschreibung
 +++-=-=-=-===
 rc  roger 1.8.9-1~no~secret amd64
 Routermanager (roger)
 un  roger-plugins-evolution   keine   keine   (keine
 Beschreibung vorhanden)
 rc  roger-plugins-fritzfon1.8.9-1~no~secret amd64
 Routermanager (roger) - Plugin FritzFon
 un  roger-plugins-google  keine   keine   (keine
 Beschreibung vorhanden)
 un  roger-plugins-gtknotify   keine   keine   (keine
 Beschreibung vorhanden)
 un  roger-plugins-indicator   keine   keine   (keine
 Beschreibung vorhanden)
 un  roger-plugins-kwallet keine   keine   (keine
 Beschreibung vorhanden)
 rc  roger-plugins-notificatio 1.8.9-1~no~secret amd64
 Routermanager (roger) - Plugin Notification
 rc  roger-plugins-statusicon  1.8.9-1~no~secret amd64
 Routermanager (roger) - Plugin Status Icon GTK
 rc  roger-plugins-thunderbird 1.8.9-1~no~secret amd64
 Routermanager (roger) - Plugin Thunderbird
 rc  roger-plugins-vcard   1.8.9-1~no~secret amd64
 Routermanager (roger) - Plugin VCard
 ii  roger-router  1.8.9-3   amd64 Home
 router management tool - GUI
 ii  roger-router-cli  1.8.9-3   amd64 Home
 router management tool - command-line interface

Peter, as I suspected, the problem comes from you having installed
upstream's binary packages in the past.  There are still remnants of
them left on your system.  Your best bet is to try and identify ALL of
them, then purge them.  aptitude search \!~i~c will list all unpurged
packages on your system.

Upstream's packaging is known to violate Debian's policy in many ways
and it is no surprise to me it is giving you problems now.  Be prepared
to continue to experience problems even in totally unrelated packages
and even after removing upstream's packages (actually, especially in
unrelated packages and especially after removal).

Lesson learned: Installing third-party packages that do not go through
the rigorous checks and adhere to Debian's policy does come at a cost.
I'm afraid you are mostly on your own with this one.

 ls -l /var/spool/roger
 insgesamt 0
 
 ls -l /var/spool
 insgesamt 44
 drwxrws--- 2 lp  fax 4096 Mär  8 16:59 roger
 
 I am a member of the group fax.
 
 When I use the printer now the windows opens to input the fax number .
 
 But the sending of the fax does not work.
 
 When I use the Fax-WebGUI of the Fritz.Box it works!
 
 I uses this fax number (of a web.de - account for playing: +4932121083XXX)
 
 
 Another error:
 
 When I update the fritz.box firmware when roger router is running then
 the roger router aborts:
 
 [1]+  Speicherzugriffsfehler  roger

Please report this as a separate issue via reportbug so that others can
confirm and add required information to do the triage.  Please only do
this if you experience the segfault after trying as much as possible to
remove any traces of upstream's packages from your system as they might
be causing this problem as well.

Please be sure to reenable the fax functionality in your FritzBox as
laid out in README.Debian after any firmware update.

 Ciao
   Peter Schütt

Regards

Rolf


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

Bug#774116: Bug is still there

[Rolf Leggewie]

On 11.03.2015 20:55, Peter Schütt wrote:
 Hallo,
 I tried the version 1.8.9-3 from experimental branch and I get the same
 error while faxing:
 
 E [11/Mar/2015:13:50:28 +0100] [Job 141] Cannot set file owner for
 /var/spool/roger/peter: Operation not permitted


Hello Peter,

sorry to hear about your troubles.  Can you please verify and report
back the following:

1) as root
   lpadmin -x Roger-Router-Fax
   aptitude purge roger-router-cli
   aptitude install roger-router
2) output of dpkg -l roger*
3) ls -l /var/spool/roger

Then please try to fax again.  Make sure Roger GUI is running at the time.

Regards

Rolf


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

Bug#780285: unblock: roger-router/1.8.9-2jessie1

[Rolf Leggewie]

On 12.03.2015 02:02, Niels Thykier wrote:
 Hi Rolf,
 
 If the change truly drops a symbol in a public shared library, then I am
 afraid it is far far too late to accept this change.  It implies doing
 an ABI transition, which we stopped accepting back in October 2014.


Niels,

thank you for the quick reply.  I'm afraid the change is indeed pretty
intrusive, it completely swaps out the used code base.  Can I get in a
change to README.Debian to inform the users of the non-working CUPS
printer? Here is my suggestion.

CUPS support for Roger Router in Jessie is currently known to be
non-working. The maintainer will try to release a backport after the
jessie release.  Until then, you can either recompile version 1.8.9-3 or
higher for yourself to get the fix or get the known-good, precompiled
and signed binaries straight from the maintainer at
http://oss.leggewie.org/bdo774116/;

Would that be acceptable?

Regards

Rolf


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

Bug#780027: roger-router: Roger should probe the box for activated fax support

[Rolf Leggewie]

Package: roger-router
Version: 1.8.9-2
Severity: normal
Tags: upstream

Roger can fail for various reasons. If it does, the error it
reports isn't always good (and oftentimes completely absent).
This should be improved.

One example is when the user hasn't yet activated fax support
via #96*3*.  I had done this in the past and thought everything
was OK, but apparently this needs to be done again when a new
firmware is uploaded to the FritzBox.

When fax support is not active and the user initiates sending
of a fax the program simply hangs with no error message at
all.

I suggest for Roger to probe the box for fax support and emit
an error as necessary.


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

Bug#774116: roger-router: Cups error message when trying to send a fax

[Rolf Leggewie]

On 07.03.2015 15:29, Rolf Leggewie wrote:
 If Fax works for you with version 1.8.9-2rl3

Test case from the command line

roger_cli -d -s -f /usr/share/cups/data/default-testpage.pdf -n $number

with the $number you want to fax to.  In my case, nowadays, it simply
hangs eventually.


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

Bug#779975: roger-router: fails to send read-only PDF files

[Rolf Leggewie]

Package: roger-router
Version: 1.8.9-2rl1
Severity: normal

Roger Router CLI fails to send PDF files that are in a read-only location.
The program obviously tries to save a temporary TIFF file alongside. My /usr
is mounted read-only.  See the attached log file for a test session.
$ roger_cli -d -s -f /usr/share/cups/data/default-testpage.pdf -n $numberhidden
17:57:58 Debug: Roger Router 1.8.9
17:57:58 Debug: Setting file monitor to '/var/spool/roger'
17:57:58 Debug: Registering router plugin: 'Speedport'
17:57:58 Debug: Register libsecret password manager plugin
17:57:58 Debug: Registering router plugin: 'FRITZ!Box'
17:57:58 Debug: Network state changed from offline to online
17:57:58 Debug: fritzbox_present: Freeing previous data
17:57:58 Debug: fritzbox_present: Query http://fritz.box/jason_boxinfo.xml
17:57:59 Debug: fritzbox_present: Data available
17:57:59 Debug: Configured router found: FRITZ!Box Fon Speedport W701V
17:57:59 Debug: Current router firmware: 29.4.88
17:57:59 Debug: fritzbox_present: Freeing previous data
17:57:59 Debug: fritzbox_present: Query http://fritz.box/jason_boxinfo.xml
17:58:01 Debug: fritzbox_present: Data available
17:58:01 Debug: ReverseLookup: 
'/usr/lib/i386-linux-gnu/routermanager/plugins/reverselookup/lookup.xml'
17:58:01 Debug: Country Code: 31
17:58:01 Debug: Service: 'gebeld.nl', prefix: 0
17:58:01 Debug: Service: 'gevonden.cc', prefix: 0
17:58:01 Debug: Service: 'nummerzoeker.com', prefix: 0
17:58:01 Debug: Country Code: 49
17:58:01 Debug: Service: '11880.com', prefix: 0
17:58:01 Debug: Service: 'Das Oertliche', prefix: 1
17:58:01 Debug: AreaCodes: 
'/usr/lib/i386-linux-gnu/routermanager/plugins/areacodes_global/globalareacodes.csv'
17:58:03 Debug: Listen to controller #1 ...
17:58:03 Debug: CAPI connection established!
17:58:03 Debug: [fritzbox_login_04_74]: start
17:58:03 Debug: [fritzbox_login_04_74]: url: http://fritz.box/cgi-bin/webcm
17:58:06 Debug: [fritzbox_login_04_74]: save data
17:58:06 Debug: Currently not logged in
17:58:09 Debug: Login successful
17:58:26 Debug: Received status code: 7
17:58:26 Debug: Trying to connect to 'fritz.box' on port 1012
17:58:26 Debug: Connected to 'fritz.box' on port 1012
GPL Ghostscript 9.10:  Could not open the file 
/usr/share/cups/data/default-testpage.pdf.tif .
Error: /invalidfileaccess in --showpage--
Operand stack:
   1   true
Execution stack:
   %interp_exit   .runexec2   --nostringval--   --nostringval--   
--nostringval--   2   %stopped_push   --nostringval--   --nostringval--   
--nostringval--   false   1   %stopped_push   1916   1   3   %oparray_pop   
1915   1   3   %oparray_pop   1899   1   3   %oparray_pop   --nostringval--   
--nostringval--   2   1   1   --nostringval--   %for_pos_int_continue   
--nostringval--   --nostringval--   1793   0   9   %oparray_pop   
--nostringval--   --nostringval--
Dictionary stack:
   --dict:1175/1684(ro)(G)--   --dict:1/20(G)--   --dict:82/200(L)--   
--dict:82/200(L)--   --dict:113/127(ro)(G)--   --dict:292/300(ro)(G)--   
--dict:28/32(L)--   --dict:6/8(L)--   --dict:28/40(L)--
Current allocation mode is local
Last OS error: Permission denied
GPL Ghostscript 9.10: Unrecoverable error, exit code 1
17:58:29 Warning: Error converting print file to TIFF!

Bug#779867: scanbd: fails to purge: scanbd.postrm: update-inetd: not found

[Rolf Leggewie]

On 06.03.2015 02:43, Andreas Beckmann wrote:
 during a test with piuparts I noticed your package failed to purge due
 to a command not found. According to policy 7.2 you cannot rely on the
 depends being available during purge, only the essential packages are
 available for sure.
[...]
   Purging configuration files for scanbd (1.4.1-4) ...
   /var/lib/dpkg/info/scanbd.postrm: 10: /var/lib/dpkg/info/scanbd.postrm: 
 update-inetd: not found

Andreas,

thank you for the report.  I'm a bit puzzled now as to what is the
appropriate way to handle this.  I asked in #debian-mentors and even
pabs didn't know a definite answer.  I poked around other packages for
guidance and inspiration and I'm still unclear.

1) handle removal in prerm only
   that seems premature
2) handle removal in prerm and postrm
   cups does this, while testing for the existence of the binary
   same problem as #1
3) handle removal only in postrm, but test for existence of the binary
   atftpd does this
   purge will succeed, but possibly leaving cruft behind

None of these seems to be any good, really.  So maybe there is a #4?
Using sed or something like that?

Can I ask for your kind guidance on how this ought to be dealt with
properly?

Regards

Rolf


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

Bug#774116: roger-router: Cups error message when trying to send a fax

[Rolf Leggewie]

Hello,

for all of you like me looking for a working Fax solution with Roger
Router, can you please test the packages I have uploaded to
http://oss.leggewie.org/bdo774116/ ? Personally, I no longer get the
error mentioned in this ticket, but Fax still isn't working.  I do get a
popup requesting to input a number (Roger GUI has to be running at that
time), but sending the fax fails for some reason.  I hear it works for
others and it might be I am special case because I connect to the
FritzBox via a VPN.

If Fax works for you with version 1.8.9-2rl3 then I will upload that
version to experimental and close this ticket.  Your feedback is
appreciated.

Regards

Rolf


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

Bug#779694: openbsd-inetd: broaden the runtime-dependency on update-inetd to update-inetd|reconf-inetd

[Rolf Leggewie]

Package: openbsd-inetd
Version: 2:1.9.2.39.3a460-3
Severity: normal
Tags: patch

Dear Maintainer,

please consider to relax the run-time dependency on update-inetd to
(update-inetd|reconf-inetd). I have prepared a patch.

Regards

Rolf
--- debian/control.orig	2015-03-04 14:31:50.953955974 +0800
+++ debian/control	2015-03-04 14:32:12.102060846 +0800
@@ -11,7 +11,7 @@
 Package: openbsd-inetd
 Architecture: any
 Multi-Arch: foreign
-Depends: ${shlibs:Depends}, ${misc:Depends}, lsb-base (= 3.2-13), update-inetd, tcpd
+Depends: ${shlibs:Depends}, ${misc:Depends}, lsb-base (= 3.2-13), update-inetd | reconf-inetd, tcpd
 Provides: inet-superserver
 Description: OpenBSD Internet Superserver
  The inetd server is a network daemon program that specializes in managing

Bug#779693: inetutils-inetd: broaden dependency on update-inetd

[Rolf Leggewie]

Package: inetutils-inetd
Version: 2:1.9-2
Severity: normal
Tags: patch

Dear Maintainer,

I think the dependency of inetutils-inetd on update-inetd should be broadened
to update-inetd or alternatively reconf-inetd.  Please look at the attached
patch.

Regards

Rolf
--- debian/control.orig	2015-03-04 13:44:28.403860537 +0800
+++ debian/control	2015-03-04 13:51:12.365863684 +0800
@@ -33,7 +33,7 @@
 Architecture: any
 Provides: inet-superserver, netkit-inetd
 Conflicts: inet-superserver, netkit-inetd
-Depends: ${shlibs:Depends}, ${misc:Depends}, update-inetd, tcpd, lsb-base,
+Depends: ${shlibs:Depends}, ${misc:Depends}, update-inetd | reconf-inetd, tcpd, lsb-base,
  inetutils-syslogd | system-log-daemon
 Description: internet super server
  Inetd is the daemon that listens on various TCP and UDP ports and spawns

Bug#775856: polipo hangs on HTTP basic authentication

[Rolf Leggewie]

On 21.01.2015 02:19, Nils Dagsson Moskopp wrote:
 Package: polipo
 Version: 1.1.1-5
 Severity: normal
 
 Dear Maintainer,
 
 when trying to use Polipo with a HTTP basic authentication, it just hangs.

Hello Nils,

thank you for your report and providing detailed steps on how to
reproduce.  I followed them (on a Ubuntu trusty machine, nonetheless)
and was unable to reproduce the problem.


$ curl http://logs.2pktfkt.de/nodrama.de/ -v --proxy 127.1:8123
* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to 127.1 (127.0.0.1) port 8123 (#0)
 GET http://logs.2pktfkt.de/nodrama.de/ HTTP/1.1
 User-Agent: curl/7.35.0
 Host: logs.2pktfkt.de
 Accept: */*
 Proxy-Connection: Keep-Alive

 HTTP/1.1 401 Unauthorized
 Content-Length: 194
 Date: Fri, 27 Feb 2015 02:40:50 GMT
* Server nginx/1.6.2 is not blacklisted
 Server: nginx/1.6.2
 Content-Type: text/html
 WWW-Authenticate: Basic realm=#nodrama.de
 Connection: keep-alive

html
headtitle401 Authorization Required/title/head
body bgcolor=white
centerh1401 Authorization Required/h1/center
hrcenternginx/1.6.2/center
/body
/html
* Connection #0 to host 127.1 left intact

This needs further inspection.  My system uses polipo 1.1.1-5 just like
yours.

Regards

Rolf


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

Bug#762723: pastebinit: [INTL:de] updated German po file translation

[Rolf Leggewie]

On 18.02.2015 02:44, Helge Kreutzmann wrote:
 I do not intend to introduce a delta
 for this in Debian.
 In this case it would be great if you could pull the (latest)
 de.po from upstream / launchpad

Helge, in principle I agree, but as you can see above I already said I
will not introduce a delta to upstream only for this.


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

Bug#778591: unblock: pastebinit/1.4-4

[Rolf Leggewie]

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

Please unblock package pastebinit to allow the fix for
RC-bug 778336 to propagate to testing. Thank you

unblock pastebinit/1.4-3
diff --git a/debian/changelog b/debian/changelog
index 7de6407..b3370f0 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+pastebinit (1.4-4) unstable; urgency=medium
+
+  [ Andrew Starr-Bochicchio ]
+  * detect_distro_with_python3.patch: Use platform instead of
+lsb_release to detect the distro as lsb_release is not
+available under Python 3 (Closes: #760341). pastebinit
+will now default again to using paste.debian.net on Debian
+(Closes: #778336).
+
+ -- Rolf Leggewie f...@rolf.leggewie.biz  Tue, 17 Feb 2015 11:35:07 +0800
+
 pastebinit (1.4-3) unstable; urgency=low
 
   * bump debhelper to version 9
diff --git a/debian/patches/detect_distro_with_python3.patch b/debian/patches/detect_distro_with_python3.patch
new file mode 100644
index 000..e0737c3
--- /dev/null
+++ b/debian/patches/detect_distro_with_python3.patch
@@ -0,0 +1,15 @@
+Index: pastebinit/pastebinit
+===
+--- pastebinit.orig/pastebinit	2015-02-16 12:37:04.434846203 -0500
 pastebinit/pastebinit	2015-02-16 12:39:22.709104460 -0500
+@@ -37,8 +37,8 @@
+ 
+ # Now try to override it with a distributor pastebin
+ try:
+-import lsb_release
+-release = lsb_release.get_distro_information()['ID'].lower()
++import platform
++release = platform.linux_distribution()[0].lower()
+ if release == 'debian':
+ defaultPB = http://paste.debian.net;
+ elif release == 'fedora':
diff --git a/debian/patches/series b/debian/patches/series
index 986704d..b17e68f 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 upstream-r205_r201.patch
 increase_timeout.patch
+detect_distro_with_python3.patch

Bug#760341: Bug#778336: pastebinit: fails in the default configuration

[Rolf Leggewie]

On 17.02.2015 01:49, Andrew Starr-Bochicchio wrote:
 This could be fixed by fixing #760341 so that pastebinit defaults to
 paste.debian.net The root cause of that is lsb-release doesn't support
 Python 3, breaking the distro detection.
 
 The attached patch works around that by using platform to detect the
 distribution instead.

Thanks, everyone, especially Andrew.  I'm preparing an upload as we speak.


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