Bug#891414: enable qt5 front-end

[Philip Rinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: severity -1 wishlist
Control: tags -1 moreinfo

I'm not a fan of doing this so you have to convince me ;-).

Could you please elaborate why I should do this? I don't see problems using the
gtk3 front-end in a qt environment. What's the actual benefit?

Best,

Philip
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEK9jU45eVX3dG2zuJrWkWlnOTmCsFAlqSyA0ACgkQrWkWlnOT
mCtU9xAAkBOZU6IfmOoEbYevhPgqi7qe0bHsciVcRI24HkJQ0fY86SIo1bMuH8qD
e2NuREpDD6wyLfGk39WggXNvk72Db4LAEC/DutjgNhqsiCJEmwNdHWIG+zPmaZGU
YprWPlqqx1M87SKd+M7Ciaktt6t0+QD3FuZ4d307zIC5ZjUEMTBedpyKEbanNlHY
Em4AaBEoF7L4Q6RaPh+Q0cH5mmFxZlKIF7rQv9t5my4Ct0yPUtUCTGsLzOnS+wWm
cHmZ7/D71W0lS3AiGEmEzLzoKAl2QqyvzPsS1vbUNFyX6LEf8KCu3o+f9xvGcOQD
6NgGNJnH6UvzzMDeX1dLJj8oELdwyTzXLxa00SmAOIu4ZkeLRMIW4fpremlBBxc5
JlVLzCVmWvJa1pQgkgo7Lx5Z8JdQU6n+3dlTthWRNywviJEplFPD14wC0QXNTxZJ
r5bsbqQdyUqUqkOrFp2h32gKE7CSJRLK2Y4pxV3+cwjze+8ObBVZ2nyj1i01xJiL
wVrGkBBQAdqCkuMHVUjR+5N581/3k6Auip5o61B04BjFewLqGdjoGab3cIKPPhPu
vv3l4KnrbzmY1riTAirFk00SNnrfNWLx7Ixavdrl7gEsYJa+gmRbbGf4FgG3UsHZ
J3DvwwKsBPKwZ6pFlMVdSrcBDIKFoYSGHfAbaEzMcGpEAgehCsc=
=NBuQ
-END PGP SIGNATURE-

Bug#881339: marked as done (allow node-babel-preset-env to build depend on itself)

[Philip Hands]

On Thu, 22 Feb 2018, Wookey <woo...@wookware.org> wrote:
...
> Anyway, Pirate - I suggest you ask about this on debian-devel where we
> can have a pulic discussion about policy and whether there is anything
> special about this case which makes it not suitable software for the
> archive.

This would probably have been a much better approach than the course
that was taken.

The private discussion with Thorsten that was forwarded to the bug
seemed not to have been followed through to any sort of conclusion
before escalation to the TC.

Also, the questions that Don was trying to explore about why there was a
need for the dependencies in the first place went unanswered. Presumably
because the whole thing is moot now that the package has been accepted.

If that was the reason for not responding to Don, it would have been
polite to close the bug at that point.

If on the other hand one is still expecting clarification on some
outstanding point (despite the fact that the original purpose of the bug
is now gone) then it would probably be wise to say so explicitly.

In the absence of any of that, my only regret is that we didn't reject
the bug at the outset for not really having bothered with steps 1-3 here:

  https://www.debian.org/devel/tech-ctte

I'm confident that we can all learn from this experience, and hope we
will do a better job next time.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#891034: ITP: pass-extension-otp -- pass extension for managing one-time-password tokens

[Philip Rinn]

Package: wnpp
Severity: wishlist
Owner: Philip Rinn <ri...@inventati.org>

* Package name: pass-extension-otp
  Version : 1.0.0
  Upstream Author : Tad Fisher <tadfis...@gmail.com>
* URL : https://github.com/tadfisher/pass-otp
* License : GPL-3+
  Programming Lang: bash
  Description : pass extension for managing one-time-password tokens

An extension for the password manager pass that allows adding one-time-password
(OTP) secrets, generating OTP codes, and displaying secret key URIs using the
standard otpauth:// scheme.

Bug#890867: debootstrap: [Patch] add docker support

[Philip Hands]

On Tue, 20 Feb 2018, Geert Stappers <stapp...@stappers.nl> wrote:
> On Tue, Feb 20, 2018 at 11:27:10AM +0900, Hideki Yamane wrote:
>> --- a/scripts/sid
>> +++ b/scripts/sid
>> @@ -94,7 +95,9 @@ Status: install ok installed" >> 
>> "$TARGET/var/lib/dpkg/status"
>> }
>>  
>> if doing_variant fakechroot; then
>> -   setup_proc_fakechroot
>> +   setup_proc_symlink
>> +   elif work_on docker; then
>> +   setup_proc_symlink
>> else
>> setup_proc
>> in_target /sbin/ldconfig
>
> It is
> | if doing_variant fakechroot; then
> | -   setup_proc_fakechroot
> | +   setup_proc_symlink
> that looks strange.
>
> Please elaborate that change.
> Mostly because other modifications were _adding_ code.

As I understand it the way that both fakechroot and docker are being
handled is by invoking what used to be called 'setup_proc_fakechroot'.
Since that function is no longer _just_ for fakechroot it deserves a new
name, so it's been renamed to 'setup_proc_symlink' (as one can see
earlier in the patch) and then of course it needs to also be replaced
here.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#884268: Fixed?

[Philip Chung]

Control: fixed -1 17.12.2-1

On Sun, 18 Feb 2018 19:28:27 -0800 "Kingsley G. Morse Jr."
<kings...@loaner.com> wrote:
> kdenlive's upstream maintainer, Jean-Baptiste
> Mardelle wrote that he pushed a fix into branch
> 'Applications/17.12'[1].
> 
> That's the good news.
> 
> The bad news?
> 
> I tested debian's version 17.12.1-1 and it was
> still broken.
> 

I tested the new version 17.12.2-1, and it appears to be fixed there.

Philip Chung

Bug#889633: gimagereader: missing translations in desktop file

[Philip Rinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Control: forwarded -1 https://github.com/manisandro/gImageReader/pull/316

Hi,

I implemented this in a pull request upstream. Let's see when/if it's merged.

Best,

Philip
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEK9jU45eVX3dG2zuJrWkWlnOTmCsFAlqFx30ACgkQrWkWlnOT
mCummw//SkfpJDFkB2fRaGfJHH8LpfFhuC5CEHlRTN8JksPk6dAIP4RjPK7am829
q+q+cUh9b+0uz+sTF88+WsDNFlwdOQK6ciCkvLc1UKItdEAbQUmFoGgivjTEd66q
Zx64hMAvVQokFfyksZjLRVpV9qCTDKa4VCsz+Fj2nlD95eX9Rw+K/A1PYMo2Kqkg
pKZV58Bvhbxi+/1SGQSkMkkU2YFyHSv9zIF7wi/PNpcztrS3gzsMJZenfZZUid3Y
qIapGuSn75cFjPdA3kIS/PE26iq0gSi2/f1C6MxJowSHi9trgwRaLsOQQgExq/Rc
a/iX+teJLF2HzmP6AKBDH6KyVPTfN1bRdlACXWSf0yCwqHWmk4ixa2C0Zr9A9Z8U
Yfi9zJnhB/sNGxp1C6EnSrWS+p6tjhmLgtK6Lg9Efgsm4AXawmtG3qC/FMUzHGgt
zAOoC933Ex5PX3aBQbASsrzpMZizwvpKgnSmPvoIqTIff7Sq5DqdsUG0gPI0S3Xp
v7vxlDH7LLDt4FAqeusxUNMTdWq5u+jnRGCmeXyH66FRxgCfzzGWoiXA6iQ1AJ7/
mZMQmjM/AvTUTsJn8KuJ8pJREo8mQowunJQ1E2SY/Bc9lZwaxjANQrZr2z/UmBTS
NmoNdg+P6ndMmcUOaI0LaqBJlM+tqESTbrVTj2UmZZ3EXFGQwKM=
=ZSS7
-END PGP SIGNATURE-

Bug#839046: debootstrap: enable --merged-usr by default

[Philip Hands]

Hi Ian,

You're not citing any concrete examples of things that will supposedly
break.

AFAICS the closest you got was:

On Sat, 10 Feb 2018, Ian Jackson <ijack...@chiark.greenend.org.uk> wrote:
> Another bad consequence is that some existing configurations that do
> not, for whatever reason, mount /usr early, will be harder to set up.

Which might be a fair point, except that late mounting of /usr became
explicitly unsupported with the release of Stretch:

  
https://www.debian.org/releases/stretch/armel/release-notes/ch-information.en.html#late-mounting-usr

The adoption of usrmerge was blocked before on the basis that it was too
late in the release cycle.  We are now fairly early in the release cycle.

That being the case, I think we should let the people volunteering to do
the work to get on with it without delay. That way there will be plenty
of time to address any real downsides that might be revealed.

Cheers, Phil.

P.S. I've not even installed usrmerge on any systems as yet, so please
don't assume that I'm a rabid supporter of this effort -- it just seems
entirely sane to me, whereas the pushback you pointed at ... not so much.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#883573: Call for vote on waiving libpam-systemd dependencies' ordering

[Philip Hands]

On Fri, 09 Feb 2018, Didier 'OdyX' Raboud <o...@debian.org> wrote:
> I call for votes on the following resolution with regards to #883573.
> The voting period lasts for one week or until the outcome is no longer
> in doubt (§6.3.1).
>
> === Resolution ===
>
> In 2014, it was resolved in #746578 that the libpam-systemd binary package 
> alternative dependency on systemd-shim and systemd-sysv shall be set in that 
> order, in order to avoid unwanted init system changes accross upgrades. 
> Debian 
> Stretch has since been released.
>
> The Committee therefore resolves that:
>
> 1. The Technical Commitee decision from 2014-11-15 in bug #746578 is repealed.
>
> This means Debian's normal policies and practices take over and the
> libpam-systemd package's dependencies are set free from specific ordering 
> constraints.  The migration should be managed according to Debian's usual 
> backwards-compatibility arrangements.
>
> === End Resolution ===
>
> R: Approve resolution and repeal the TC decision from 2014-11-15 in #746578.
> F: Further Discussion

I vote:

  R > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#863520: cyrus-imapd version 2.5.10-3 Fatal error with SSL

[Philip Iezzi]

Dear maintainer,

I would greatly appreciate if you could push this fix into current Debian 
Stretch. The problem still persists in Cyrus-imapd 2.5.10-3 and above patch 
from upstream fixes it. After having upgraded a mailserver to Debian Stretch we 
had a massive amount of negative customer feedback complaining about dropped 
connections.

The patched and recompiled packages are now running for more than 2 weeks on 
two rather busy mail servers (datenpark.ch / onlime.ch) and all trouble has 
gone away, cyrus-imapd works stable again.

Thanks Vladislav for your great support!

Here's a short howto for people who never built a Deb package before:

$ apt-get source cyrus-imapd
$ wget 
https://github.com/cyrusimap/cyrus-imapd/commit/a1c917df8de04e108228f38f0010498bec3d81e8.patch
 -O cyrus-imapd-issue1872.patch 
$ cd cyrus-imapd-2.5.10/
$ patch -p1 < ../cyrus-imapd-issue1872.patch
$ apt-get build-dep cyrus-imapd
$ dpkg-buildpackage -b
$ cd ../

# install at least the following and put those packages on hold:
$ dpkg -i cyrus-common_2.5.10-3_amd64.deb cyrus-imapd_2.5.10-3_amd64.deb 
cyrus-pop3d_2.5.10-3_amd64.deb libcyrus-imap-perl_2.5.10-3_amd64.deb
$ echo cyrus-common hold | dpkg --set-selections
$ echo cyrus-imapd hold | dpkg --set-selections
$ echo cyrus-pop3d hold | dpkg --set-selections
$ echo libcyrus-imap-perl hold | dpkg --set-selections

# check package state
$ dpkg --get-selections | grep cyrus | grep -v deinstall

This fixes the issue and the "lib/cyrusdb_twoskip.c" fatal errors no longer pop 
up in mail.log

Best regards,
Philip

Bug#889493: tech-ctte: Please review if systemd is reliable enough to be the default

[Philip Hands]

On Sun, 04 Feb 2018, "Kingsley G. Morse Jr." <kings...@loaner.com> wrote:
> Hi Phil,
>
> I find I often benefit from other people's point
> of view.
>
> If you happen to have the time, and are so
> inclined, and it would be comfortable, feel free
> to elaborate on your comment in bug report #889493.
>
> I'm particularly curious why you wrote it had no
> merit.

If you look closely, you'll notice that I didn't actually write that,
but never mind.

For anything worthwhile to conceivably come out of such a bug, at least
one TC member would need to be at least a little interested in
discussing it, in which case they would certainly reopen the bug, and
we'd then continue as if I'd done nothing.

I look at that as simply changing the default state of the incoming bug
to closed[1].

Of course one would normally go to the effort of pointing out the
specific flaws in the submission, but I'm not going to do that in this
case because I wouldn't want to give the false impression that if only
you'd done a few things differently it would have been considered.

Submitting this bug demonstrates to me that you have fundamentally
misunderstood the purpose and power of the Technical Committee.  Once
that misunderstanding is rectified, you will no longer be tempted to
submit the bug in any form.  The fact that the original bug also fails
to conform with most of the bug submission guidelines is irrelevant.

To draw an analogy, you might as well spend your time writing to the
Oxford English Dictionary complaining about the inclusion of words you
don't like (although please don't, as they also have more useful things
to be doing than discarding post).

Cheers, Phil.

[1] I could imagine us doing that with all bugs in fact -- if the first
person to get to the bug doesn't see it as worth discussing they
simply close it and leave other members of the TC to reopen it if
they disagree. This is much more efficient than leaving it open
until after the next meeting, and doesn't give a false impression
about what is happening to the submitter.  I can think of a couple
of recent bugs that would have benefited from this approach ;-)
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#887323: dewalls i386 test failure

[Philip Schuchardt]

Nice! I wonder if i386 don’t support exceptions properly or something...
On Tue, Jan 30, 2018 at 8:07 AM Wookey <woo...@wookware.org> wrote:

> On 2018-01-30 06:48 +0000, Philip Schuchardt wrote:
> > I know I’ve been dragging my feet on this. Let’s see if I can figure
> this out,
> > this week.
>
> I fished out an old netbook which is actually i386. And installed an
> unstable chroot on it (very slowly!) last night. Hopefully this will
> enable some bottom-getting-to.
>
> I should probbaly just have used a debian porter-box, but that machine
> needed updating anyway.
>
> Wookey
> --
> Principal hats:  Linaro, Debian, Wookware, ARM
> http://wookware.org/
>
-- 
Phi|ip

Bug#861263: debian-installer: zfs support

[Philip Hands]

On Sat, 06 May 2017, Sam Kuper <sam.ku...@uclmail.net> wrote:
...
> Given that a machine intended to run ZFS is likely to be provisioned
> with >2GB of RAM ...

debian-installer is effectively an embedded OS for the purpose of
installing Debian -- trying to squeeze the ability to build ZFS into
that is a mistake IMO.

Given that you are assuming systems with a decent chunk of RAM, I'd
suggest that you instead boot from live media, thus getting a full
Debian system immediately, running in RAM, without the need to be
restrained by the limitations of debian-installer.

Then you ought to be able to simply install the zfs tools and modules
into the in-RAM system (assuming one can load them without reboot),
format disks as you require, and then install using e.g. debootstrap,
without needing to worry about what debian-installer can or cannot do.

I would guess that debian-live should be up to the task, but if doesn't
work for some reason, you could also look at grml.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#887656: debian-installer: no way to set IP address manually if DHCP address assigned

[Philip Hands]

On Thu, 18 Jan 2018, Stuart <stu...@durge.org> wrote:
> Package: debian-installer
> Severity: normal
> Tags: d-i
>
> Dear Maintainer,
>
> Installing 9.3.0 via Net Install CD.
> At the network detection stage, it found two network interfaces.
> I selected one interface, and it allocated an address via DHCP.
> My machine is intended to have a static IP, but I couldn't see an
> option to enter an IP once DHCP had succeeded.
>
> It would be useful to be able to choose not to use DHCP, or to
> override the DHCP settings.

We do handle your use case, but it's probably not very obvious that we
do.

The way you do it is (IIRC) that you select the  button after DHCP
has succeeded, at which point you should be given the option to
configure the network, and when you select that you should be presented
with more options.

Alternatively, if you're quick you can select  while the DHCP
attempt is occurring.

Another option that generally works is to simply do the install, using
the DHCP allocated IP address, and then reconfigure the system to your
requirements after it is up and running.

The reason we don't offer the prompt you were hoping for by default is
that most people on networks with working DHCP want to use it, and
quite often are not familiar enough with the technical terms to be able
to answer the question we'd have to ask.

You can also get the prompt you want by selecting an "Expert" install,
but then you'll also get prompted with all the other questions on other
subjects that we have decided are not important enough to bother normal
users with.

HTH

If that addresses your concerns, please close the bug.

If there is some place where you think placing the documentation about
the Back/Cancel bits would have been seen by you, and hence would have
allowed you to work out how to do it yourself, please make a suggestion.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#887012: ITP: node-rmrf -- no-BS synchronous rm -rf for node.js

[Philip Hands]

On Sun, 14 Jan 2018, Philip Hands <p...@hands.com> wrote:
...
> I hadn't noticed the new repo URL when I merged the two ITP bugs, sorry
> about that.

Oh, I see -- Defaulting to rm -rf / -- most amusing.

I suspect that we don't need that version of the package either, in fact.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#887006: ITP: node-rmrf -- no-BS synchronous rm -rf for node.js

[Philip Hands]

Control: forcemerge -1 887012

Hi,

I note that the description for this ITP is simply lifted from the git
repo, and that it isn't appropriate for a Debian package's description,
which combination seems to be a bit of a red flag on these ITPs.

The "longer" description is simply untrue -- the code does not in fact
run rm -rf. Instead it is a rather poor attempt at a re-implementation,
judging by this:

  https://github.com/mrDarcyMurphy/node-rmrf/issues/4

which strikes me as an RC bug.

The fix for that bug has been untouched for over two years:

  https://github.com/mrDarcyMurphy/node-rmrf/pull/5

which also have addressed the fact that the existing code cannot deal
with deleting special files, instead attempting to recurse into them on
the assumption that anything that's not a file must be a directory. :-/

The last commit here was in 2013 -- which suggests that this is dead
upstream (unless there's an active repository elsewhere).

Is this really the best implementation of a recursive delete in the node
ecosystem?

If there is something better, would it not be wise to drop this as a
dependency and use the better thing instead, hopefully pushing that
change upstream and so reducing reliance on this faulty implementation?

This doesn't give me the impression of something that's worth packaging,
unless you're planning on becoming the upstream, and fixing it first.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#887006: ITP: node-rmrf -- no-BS synchronous rm -rf for node.js

[Philip Hands]

On Sun, 14 Jan 2018, Philip Hands <p...@hands.com> wrote:
> unless you're planning on becoming the upstream, and fixing it first.

Ah, I see -- you are planing on being the new upstream -- well done :-)

I hadn't noticed the new repo URL when I merged the two ITP bugs, sorry
about that.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#887089: ITP: node-shiny-server-client -- browser library for connecting to Shiny Server

[Philip Rinn]

Package: wnpp
Severity: wishlist
Owner: Philip Rinn <ri...@inventati.org>
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-shiny-server-client
  Version : 1.0.0+gitf214eae
  Upstream Author : RStudio <n...@rstudio.com>
* URL : https://github.com/rstudio/shiny-server-client
* License : AGPL-3.0
  Programming Lang: JavaScript
  Description : browser library for connecting to Shiny Server

 This Node.js package provides unified client code for Shiny Server, Shiny 
Server
 Pro, and RStudio Connect. Previously, each server product had its own version 
of
 this code with slight differences. This package provides the superset of
 functionality needed by the different products, and runtime options determine
 what features to enable.
 .
 Node.js is an event-based server-side JavaScript engine.

This package is a dependency of shiny-server (which will be maintained by
Debian-science). I intend to maintain the package under the Debian Science
umbrella. I'll need a sponsor to upload the package.

Bug#887080: ITP: node-pinkyswear -- very small implementation of the Promises/A+ specification

[Philip Rinn]

Package: wnpp
Severity: wishlist
Owner: Philip Rinn <ri...@inventati.org>
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-pinkyswear
  Version : 2.2.3
  Upstream Author : Tim Jansen <t...@tjansen.de>
* URL : https://github.com/timjansen/PinkySwear.js
* License : public-domain
  Programming Lang: JavaScript
  Description : very small implementation of the Promises/A+ specification

 This Node.js package is a minimalist Promises/A+ implementation for embedding.
 You can use it as a lightweight dependency for your library if you need to
 return a promise. It is not intended as a stand-alone library for more complex
 applications, and therefore does not support assimilation of other promises.
 .
 Node.js is an event-based server-side JavaScript engine.


This package is a dependency of node-shiny-server-client (ITP will follow) which
is a dependency of shiny-server (will be maintained by Debian-science).

I intend to maintain the package under the Debian JavaScript maintainers or the
Debian Science umbrella. I'll need a sponsor to upload the package.

Packaging can be found (until I know which team I'll use) at

https://salsa.debian.org/rinni-guest/node-pinkyswear

Bug#886267: Voting for TC Chair

[Philip Hands]

On Wed, 03 Jan 2018, Didier 'OdyX' Raboud <o...@debian.org> wrote:
> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A: Didier Raboud 
> B: Tollef Fog Heen 
> C: Phil Hands 
> D: Margarita Manterola 
> E: David Bremner 
> F: Niko Tyni 
> G: Gunnar Wolf 
> ===END===

I vote:

   A = D > B = C = E = F > G

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#886889: Fix insecure password generation in stretch

[Philip Rinn]

Control: tags -1 pending

Hi,

On 10.01.2018 18:00:14, Joel Johnson wrote:
> It is noted in the changelog for version 1.2.1-1, but shouldn't the fix be
> applied to the stretch package as well?

Yes, I'm waiting for the Stable Reslease Managers:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886593

Best,
Philip


signature.asc
Description: PGP signature

Bug#886238: closed by Bastian Blank <wa...@debian.org> (Re: Bug#886238: Please introduce official nosystemd build profile)

[Philip Hands]

On Mon, 08 Jan 2018, Hleb Valoshka <375...@gmail.com> wrote:
> On 1/8/18, Don Armstrong <d...@debian.org> wrote:
>
>> Devuan does not support reading the new upstream configuration file,
>> which is what new patches are needed to support. This is pretty classic
>> bitrot of an underused/under-tested execution path.
>
> It does: 
> https://git.devuan.org/devuan-packages/dnscrypt-proxy/blob/suites/ascii-proposed/debian/dnscrypt-proxy.init

Well done.

I note that your init script is not the same as the one in the bug's
patch, and is also not the same as the one that reverting the commit you
were on about would have resurrected.

I would hope that between the three versions there is one (or a
combination) that would function both on a system where the systemd
support files are present (as in the Debian package) and where they are
absent (as is the case in yours). If not, presumably that would not take
a vast effort to achieve.

That being the case, I'd suggest that you mail the bug with your script
attached, pointing out the interesting differences between it and the
existing patch, and perhaps offering to help testing the result.

I sincerely hope that doing that would result a rather happier outcome
than your efforts to date seem to have achieved.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#881343: pk4: Please avoid the use of "avail" in package descriptions

[Philip Hands]

On Mon, 08 Jan 2018, Michael Stapelberg <stapelb...@debian.org> wrote:
> In the context of “pk4 - avail the Debian source package producing the
> specified package”, I interpret “avail” as a shorter alternative to “make
> available”.

Ah, yes, I see.

While the existence of the word "available" suggests such a meaning for
the word "avail", sadly English is not quite as predictable as that, and
avail does not actually mean that at all.

BTW avail apparently comes from the obsolete "vail" of Middle English,
meaning "to have value".

In my experience avail is only seen in very limited circumstances these
days (which suggests that it's on its way to obsolescence too):

  1) followed by his/her/oneself, meaning something like make use of:

 The thirsty man availed himself of the drinking fountain.

  2) as part of "of/to no avail", meaning without success:

 He attempted to fly by flapping his arms, to no avail.

I presume that available started out as meaning specifically "something
that one might avail oneself of", and has drifted a little to it's
current meaning since -- hence the confusion.

That being the case, you could perhaps use "obtain" or "provide" or just
"make the source available".  I suppose "provision" might work too,
although it's a bit of an odd usage.  "prepare" also might work.

HTH

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#881343: pk4: Please avoid the use of "avail" in package descriptions

[Philip Hands]

Hi,

> Thanks for the report. I thought about it for a while, and I’d prefer to
> keep the description as-is. Sorry.

Judging by the usage throughout the manpage, as well as in the short
description, you obviously think that "avail" precisely fits the meaning
that you are attempting to convey, but sadly I suspect that it doesn't
actually mean what you think it means.

I'm certainly not an English scholar, but I am a reasonably well
educated native (British) English speaker, and I do include avail" in my
active vocabulary, albeit on the periphery of that vocabulary.

Your usage of "avail" provides me with no real certainty as to what you
mean by it.

You appear to be using it as a synonym for "get", which is not a meaning
that I immediately recognise, nor one that is strongly suggested by
dictionary definitions I can find -- occasionally it is defined as
meaning "provide" but I would even then dispute that it means provide in
the way that you are using it.

Perhaps you could expand on what you think it means.

That might allow people to suggest an alternative choice of words that
would be comprehensible to a wider audience.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#886238: closed by Bastian Blank <wa...@debian.org> (Re: Bug#886238: Please introduce official nosystemd build profile)

[Philip Hands]

On Sun, 07 Jan 2018, Hleb Valoshka <375...@gmail.com> wrote:
> On 1/5/18, Debian Bug Tracking System <ow...@bugs.debian.org> wrote:
>> From: Bastian Blank <wa...@debian.org>
> ...
>> As you have been already told by several people, Debian supports
>> systemd-less systems.  If you find bugs running in this mode, please
>> file bug reports.
>
> I've already posted a bug number which perfectly shows how bugs for
> systemd-less systems are treated.
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850069
>
>> Control: severity -1 wishlist
>
> W_I_S_H_L_I_S_T_!
>
> System is broken,

Wrong.

Which bit of this reply is not clear to you?

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857322#10

Did you perhaps miss the fact that the two bugs had been merged?

Without the merged bug, there is no patch, so in that case you would
have nothing to complain about (maintainers are _NOT_ required to fix
such bugs, but should not reject patches without good reason).

With the merged bug, we have a patch that is described as "prelimiary"
and suggests a way of testing it. :

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857322#25

Therefore it needs testing before one could legitimately complain about
the maintainer blocking it.

Have you contributed to that testing?

If so, why is that not visible in the bug?

If not, how about putting your efforts into something useful (testing),
rather than wasting your and our time with this intemperate drivel?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#886593: stretch-pu: package qtpass/1.1.6-1

[Philip Rinn]

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

Hi,

the current version in stable has a insecure built-in password generator. As
the built-in password generator not used in qtpass' default config, the
security team asked me to fix it via stretch-pu.
Here is the corresponding link:
https://security-tracker.debian.org/tracker/source-package/qtpass

I attached the debdiff (the fix is adopted from upstream, see
https://github.com/IJHack/QtPass/issues/338 for reference).

May a go ahead?

Best,

Philip
diff -Nru qtpass-1.1.6/debian/changelog qtpass-1.1.6/debian/changelog
--- qtpass-1.1.6/debian/changelog   2016-12-02 16:23:16.0 +0100
+++ qtpass-1.1.6/debian/changelog   2018-01-07 13:45:10.0 +0100
@@ -1,3 +1,9 @@
+qtpass (1.1.6-1+deb9u1) stretch; urgency=medium
+
+  * Fix insecure built-in password generator (Fixes: CVE-2017-18021)
+
+ -- Philip Rinn <ri...@inventati.org>  Sun, 07 Jan 2018 13:45:10 +0100
+
 qtpass (1.1.6-1) unstable; urgency=medium
 
   * New upstream release
diff -Nru qtpass-1.1.6/debian/NEWS qtpass-1.1.6/debian/NEWS
--- qtpass-1.1.6/debian/NEWS1970-01-01 01:00:00.0 +0100
+++ qtpass-1.1.6/debian/NEWS2018-01-07 13:45:10.0 +0100
@@ -0,0 +1,15 @@
+qtpass (1.1.6-1+deb9u1) stretch; urgency=medium
+
+  All passwords generated with QtPass' built-in password generator prior to
+  1.1.6-1+deb9u1 are possibly predictable and enumerable by hackers.
+  The generator used libc's random(), seeded with srand(msecs), where msecs is
+  not the msecs since 1970 (not that that'd be secure anyway), but rather the
+  msecs since the last second. This means there are only 1000 different
+  sequences of generated passwords.
+  .
+  NB: QtPass uses `pwgen` to generate passwords by default. This means, if you
+  didn't change the configuration to use the built-in password generator your
+  passwords are safe. If you used the built-in password generator, change all
+  passwords you generated with QtPass.
+
+ -- Philip Rinn <ri...@inventati.org>  Sun, 07 Jan 2018 13:45:10 +0100
diff -Nru qtpass-1.1.6/debian/patches/01-fix-password-generator.patch 
qtpass-1.1.6/debian/patches/01-fix-password-generator.patch
--- qtpass-1.1.6/debian/patches/01-fix-password-generator.patch 1970-01-01 
01:00:00.0 +0100
+++ qtpass-1.1.6/debian/patches/01-fix-password-generator.patch 2018-01-04 
22:38:41.0 +0100
@@ -0,0 +1,67 @@
+--- a/mainwindow.cpp
 b/mainwindow.cpp
+@@ -67,7 +67,6 @@
+   connect(actionAddPassword, SIGNAL(triggered()), this,
+   SLOT(on_addButton_clicked()));
+   connect(actionAddFolder, SIGNAL(triggered()), this, SLOT(addFolder()));
+-  qsrand(static_cast(QTime::currentTime().msec()));
+ 
+ #if QT_VERSION >= QT_VERSION_CHECK(5, 2, 0)
+   ui->lineEdit->setClearButtonEnabled(true);
+@@ -1900,10 +1899,10 @@
+ else
+   qDebug() << "pwgen fail";
+   } else {
+-int charsetLength = pwdConfig.Characters[selection].length();
++quint32 charsetLength = pwdConfig.Characters[selection].length();
+ if (charsetLength > 0) {
+   for (int i = 0; i < length; ++i) {
+-int index = qrand() % charsetLength;
++quint32 index = Util::boundedRandom(charsetLength);
+ QChar nextChar = pwdConfig.Characters[selection].at(index);
+ passwd.append(nextChar);
+   }
+--- a/util.cpp
 b/util.cpp
+@@ -9,6 +9,9 @@
+ #else
+ #include 
+ #endif
++#include 
++#include 
++#include 
+ QProcessEnvironment Util::_env;
+ bool Util::_envInitialised;
+ 
+@@ -137,3 +140,21 @@
+   nanosleep(, NULL);
+ #endif
+ }
++
++quint32 Util::boundedRandom(quint32 bound) {
++  static int fd = -1;
++  if (bound < 2)
++  return 0;
++
++  if (fd == -1)
++  assert((fd = open("/dev/urandom", O_RDONLY)) >= 0);
++
++  quint32 randval;
++  const quint32 max_mod_bound = (1 + ~bound) % bound;
++
++  do
++  assert(read(fd, , sizeof(randval)) == sizeof(randval));
++  while (randval < max_mod_bound);
++
++  return randval % bound;
++}
+--- a/util.h
 b/util.h
+@@ -16,6 +16,7 @@
+   static bool checkConfig(QString passStore, QString passExecutable,
+   QString gpgExecutable);
+   static void qSleep(int ms);
++  static quint32 boundedRandom(quint32 bound);
+ 
+ private:
+   static void initialiseEnvironment();
diff -Nru qtpass-1.1.6/debian/patches/series qtpass-1.1.6/debian/patches/series
--- qtpass-1.1.6/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ qtpass-1.1.6/debian/patches/series  2018-01-04 22:11:50.0 +0100
@@ -0,0 +1 @@
+01-fix-password-generator.patch

Bug#884835: [Pkg-mailman-hackers] Bug#884835: mailman3-suite: postinst fails if nginx is installed and apache2 is missing

[Philip Frei]

Hi,

On Wed, 20 Dec 2017 17:50:42 +0100 Pierre-Elliott
=?iso-8859-1?Q?B=E9cue?= <be...@crans.org> wrote:

> Please provide a little more output to explain how the postinst will
> fail? Did you chose "none" for the webserver to configure?

I installed mailman3-suite in a fresh KVM guest and discovered the same
error in the postinstall script.

It's possbile to complete the installation after uncommenting line 199
in /var/lib/dpkg/info/mailman3-suite.postinst.

BTW: There's no debconf question about choosing the webserver during
the installation. Only when I run dpkg-reconfigure mailman3-suite.

regards,
Philip

Bug#884526: jigdo-file: Does not report package rejections because checksum mismatch

[Philip Hands]

On Thu, 28 Dec 2017, "Thomas Schmitt" <scdbac...@gmx.net> wrote:
> Hi,
>
> first a correction of my proposal:
>
> The else-case with
>   echo "WARNING: File not found after download:" >&2
> is not good.
> It floods the log if one uses a mirror with few matching files.
> Not finding a file after the download is a normal situation.
>
> ---
>
> I wrote:
>> >sed -e 's/^[hH][tT][tT][pP]:\/\///' \
>> >-e 's/^[hH][tT][tT][pP][sS]:\/\///' \
>> >-e 's/^[fF][tT][pP]:\/\///' \
>> >-e 's/^[fF][iI][lL][eE]:\/\///'`
>
> Philip Hands wrote:
>>   sed -e 's,^\(https\?\|ftp\|file\)://,,i'
>> ...
>>   "$imageTmp/${url#[[:alpha:]]*://}"
>
> Are these widely portable enough ?

the , rather than / feature is already in use in the script (except that
its using s%%%).

\( \) is already in use, and AFAIK \| has been there for as long

\? _might_ be a bit later as a feature, in which case one could add
\|https, but then again isURI() doesn't match https: anyway

The i flag is a GNU extension, so is probably not that portable, so one
could go for \(http\|HTTP\|...

For the shell, I suspect that [[:alpha:]] is an innovation from the
90's, so one could play it safe (well, except that it might break with
odd codings) with [a-zA-Z]. posh doesn't seem to know about [:alpha:]
for instance.

posh does know about the ${ # } thing, but that wasn't in Solaris SVR4
shell AFAIK.

> Mine can be justified by S.R.Bourne's "The Unix System", i guess,
> and it is coordinated with function isURI.
>
> Well, my scruples are mainly about what wget guarantees to use as
> local disk path. I understand that jigdo-file would be quite tolerant
> as long as the file is somewhere in the "$imageTmp" tree.
> Maybe i should invest a "find" run in case of missing file. The tree is small.
>
>
> I wrote:
>> > fileMD5=`$jigdoFile md5 "$localPath" 2>/dev/null | awk '{print $1}'`
>
>> The way it's done elsewhere in the script (which I happen to think is
>> pretty horrible, but that's what is already there) is using set, thus:
>>   set -- `$jigdoFile md5sum --report=quiet "$localPath"`
>
> Option "--report=quiet" instead of "2>/dev/null" is a good point.
>
> One would have to wrap the "set --" into a sub-shell, because fetchAndMerge
> already tampers with its own arguments.
> Like:
>   answer=`$jigdoFile md5sum --report=quiet "$localPath"`
>   fileMD5=`(set -- $answer ; echo "$1")`
> Now that's really ugly.

This seems preferable, and avoids new dependencies:

  `$jigdoFile md5sum --report=quiet "$localPath" | sed 's/ .*$//'`

> If direct objections emerge against "awk", i'd consider some helper
> function which echos "$1".
>
>
>> I also happen to think that using `` rather than $() is pretty horrible
>> in this day and age, but that's what's currently there throughout the
>
> Yep. Not to speak of the headless camelBack variable names.
>
> I strive to be minimally intrusive for the purpose and to be as
> conservative as in an autotools script.

Fair enough.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#884526: jigdo-file: Does not report package rejections because checksum mismatch

[Philip Hands]

On Thu, 28 Dec 2017, "Thomas Schmitt" <scdbac...@gmx.net> wrote:
...
> Especially in need of attention:
>
> - I could not find a clear description how "wget" determines the local
>   file paths from URLs and option --directory-prefix="$imageTmp".
>   My current conversion from URL to path is purely heuristic therefore:
>
> localPath="$imageTmp"/`echo "$url" | \
>sed -e 's/^[hH][tT][tT][pP]:\/\///' \
>-e 's/^[hH][tT][tT][pP][sS]:\/\///' \
>-e 's/^[fF][tT][pP]:\/\///' \
>-e 's/^[fF][iI][lL][eE]:\/\///'`

A rather less laboured way of getting the same effect with sed would be:

  sed -e 's,^\(https\?\|ftp\|file\)://,,i'

[ Things to note about that:
 s,,, in place of s/// means that no escaping of / is needed
 the 'i' flag at the end makes the match case insensitive
 s\? means match zero or one 's'
]

However, I doubt that it's important to worry about the potential for
unexpectedly removing a prefix of e.g. cdrom:// or ://, in which case
you could dispense with sed and instead do this:

  localpath="$imageTmp/${url#[[:alpha:]]*://}"

> - I introduced a dependency on "awk", which was not used in jigdo-lite
>   before. The task is to obtain the first word of jigdo-file's output:
>
> fileMD5=`$jigdoFile md5 "$localPath" 2>/dev/null | awk '{print $1}'`

The way it's done elsewhere in the script (which I happen to think is
pretty horrible, but that's what is already there) is using set, thus:

  set -- `$jigdoFile md5sum --report=quiet "$localPath"`

which leaves the value that you are after in $1.

I also happen to think that using `` rather than $() is pretty horrible
in this day and age, but that's what's currently there throughout the
script, so I guess one should stick with that, or fix it everywhere.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#880014: #880014: Call for Votes for new TC member

[Philip Hands]

On Tue, 26 Dec 2017, Didier 'OdyX' Raboud <o...@debian.org> wrote:
> I call for votes on the following ballot to fill a vacant seat in the TC. The 
> voting period starts immediately and lasts for up to one week, or until the 
> outcome is no longer in doubt (§6.3.1).
>
> ===BEGIN
> The Technical Committee recommends that Gunnar Wolf <gw...@debian.org> be
> appointed by the Debian Project Leader to the Technical Committee.
>
> G: Recommend to Appoint Gunnar Wolf <gw...@debian.org>
> F: Further Discussion
> ===END

I vote:

  G > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#884835: [Pkg-mailman-hackers] Bug#884835: mailman3-suite: postinst fails if nginx is installed and apache2 is missing

[Philip Frei]

Hi,

Am Wed, 20 Dec 2017 17:50:42 +0100
schrieb Pierre-Elliott Bécue :

> Please provide a little more output to explain how the postinst will
> fail? Did you chose "none" for the webserver to configure?

Atfer the installation failed I removed and purged all related
packages. With a fresh install there's no question about choosing the
webserver.

This is the relevant output of the script:

+ [ -e /usr/share/apache2/apache2-maintscript-helper ]
+ settings_local_new=
+ hyperkitty_cfg_new=
+ django_admin_args=--verbosity 0 --no-color
--pythonpath /usr/share/mailman3-suite --settings settings
+ db_get mailman3-suite/reconfigure-webserver
+ _db_cmd GET mailman3-suite/reconfigure-webserver
+ _db_internal_IFS= 

+ IFS= 
+ printf %s\n GET mailman3-suite/reconfigure-webserver
+ IFS=  

+ IFS=
 read -r _db_internal_line
+ RET=apache2
+ return 0
+ webservers=apache2
+ restart=
+ webserver=apache2
+ apache_install
+ return 1
dpkg: error processing package mailman3-suite (--configure):
 subprocess installed post-installation script returned error exit
  status 1 Errors were encountered while processing:
 mailman3-suite


regards,
Phil

Bug#884835: mailman3-suite: postinst fails if nginx is installed and apache2 is missing

[Philip Frei]

Package: mailman3-suite
Version: 0+20170523-6
Severity: normal

Hi,

it's possible to use mailman3 with nginx. But without Apache2 installed
the postinst will fail because there's no instruction how to proceed
with nginx.

regard,
Phil

Bug#884316: mailman3-suite: Unable to use nginx because of a typo in control file

[Philip Frei]

Package: mailman3-suite
Version: 0+20170523-2
Severity: minor
Tags: patch

Hi,

it's great to see mailman3 in Debian. Thanks a lot for your efforts.

There is a small typo in the control file that prevents to use nginx
with this package. Patch is attached.

regard,
Phil
--- control.orig2017-12-13 19:49:17.022251933 +0100
+++ control 2017-12-13 19:49:26.078320831 +0100
@@ -26,7 +26,7 @@
  uwsgi,
  uwsgi-plugin-python,
  ${misc:Depends}
-Recommends: libapache2-mod-proxy-uwsgi | nxginx, postgresql
+Recommends: libapache2-mod-proxy-uwsgi | nginx, postgresql
 Description: Django project integrating Mailman3 Postorius and HyperKitty
  This django web application provides the Mailman3 Postorius web interface
  and the HyperKitty mailinglist archiver integrated into one project.

Bug#883256: apparmor-profiles-extra: Totem can't access files outside $HOME

[Philip Rinn]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi,

sorry for replying so late. Thanks for all of you for your input!

On 07.12.2017 at 08:51, intrigeri wrote:
> The Totem profile allows common locations for media files outside of $HOME,
> such as /{media,mnt,opt,srv}/**. Where are the files you're trying to play
> located? If they are in one of the supposedly allowed directories, please
> provide the AppArmor denial logs.

The files I tried to access are in /bigdata/Filme/**. I added this line in
/etc/apparmor.d/local/usr.bin.totem

owner /bigdata/Filme/** rw,

and everything works.

I didn't look into  before filing the bug (due to not being
familiar with how apparmor profiles work). If I had, I wouldn't have filed the
bug. I think the behavior of the profile is totally fine, feel free to close the
bug.

Best,

Philip
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEK9jU45eVX3dG2zuJrWkWlnOTmCsFAlopXG8ACgkQrWkWlnOT
mCsvDw//SzQmQrq55bd0i0eKuIYpwLKOFDzPYG7TX1S79sfwpWo6I6HvHuu6fUzS
ws5ksGpd5wRvJJgSzPgYqQmQW2pe3gsS9ZJynZxvv4zfxLVpEjN8OEgys7PVRs9r
36XC6CsjjjFymprnAqOR/EnGvjXTDJ7xVHjvhene7ZvGGTlLQIQjeWmVLfsRiqo4
ozbifiYxg/7r2WRD8uCeBOASpUP3iOQpUWHHnQLEc3a9xYIe7dWFHKviFE1QWyFZ
zh/MxEaiD48++OCGP4MoyRaDPQ1tKIBmvDVe9b4zMyjGpi4q/bjRRIglnKqXfNF6
BRIjRBY8K2xe3X8ucFlX5qpWtj2SEgp3jnR4VnsfACvoq+ueKkkvCHiu59sQXcyd
3uKhZd5+HjHu315xb+tNseZ9SdiOPKCIzxh4Bw7W8e7Z1VIXIpDJgS3VTuDgCA9r
mjWwHPIZQpPP3KxwucmIwsl2DI5fahrLobUW2E6l5ZExbZTxqJlosnlgBtOXEdNF
KoQPfZk+a+1PJq4w2H2MuB1KcfxPbB80wJVQiPoEi9i2Y3rX8bNM5L/ep22FHouH
PWe1OhZ7yrhKokcA2X4weOcAWamMjpaSfRjoUC1wtlP3CEFEXWldxml3vIXLGUaX
yxmQ3CPk3x4ZuHnu8fN9Rg/V6HEX2T+BAPKus6WlxSs9VI8whFU=
=cyha
-END PGP SIGNATURE-

Bug#883614: [pkg-wpa-devel] Bug#883614: wpasupplicant fails to connect in v2.6

[Philip J Freeman]

hmm.. turns out, I can't repro anymore after installing new package..
perhaps just a local network issue?

Sorry for the cruft. :-/


On Tue, Dec 05, 2017 at 08:10:24PM +0100, Andrew Shadura wrote:
> Hi Philip,
> 
> From the logs you attached it appears that the connection attempt succeeded. 
> Could you please inspect the exact state wpa-supplicant and the interfaces 
> are left in at that point?
> 
> Thanks!
> -- 
> Cheers,
>   Andrew

-- 
⛵

Bug#883614: Downgrading to wpasupplicant 2:2.4-1.1 fixes issue

[Philip J. Freeman]

FYI: Downgrading to wpasupplicant 2:2.4-1.1 fixes issue

elektron@x61s-4280:~/wpasup$ dpkg -l | grep wpasupp
ii  wpasupplicant  2:2.4-1.1
amd64client support for WPA and WPA2 (IEEE 802.11i)

Log:

wpa_supplicant v2.4
random: Trying to read entropy from /dev/random
Successfully initialized wpa_supplicant
Initializing interface 'wlan0' conf 
'/home/elektron/.dotfiles/sec/wifi/byc.conf' driver 'default' ctrl_interface 
'N/A' bridge 'N/A'
Configuration file '/home/elektron/.dotfiles/sec/wifi/byc.conf' -> 
'/home/elektron/.dotfiles/sec/wifi/byc.conf'
Reading configuration file '/home/elektron/.dotfiles/sec/wifi/byc.conf'
ctrl_interface='/var/run/wpa_supplicant'
Line: 5 - start of a new network block
ssid - hexdump_ascii(len=7):
 62 79 63 77 69 66 69  bycwifi 
key_mgmt: 0x2
proto: 0x2
pairwise: 0x10
group: 0x10
PSK (ASCII passphrase) - hexdump_ascii(len=12): [REMOVED]
PSK (from passphrase) - hexdump(len=32): [REMOVED]
Priority group 0
   id=0 ssid='bycwifi'
rfkill: initial event: idx=0 type=2 op=0 soft=0 hard=0
rfkill: initial event: idx=1 type=1 op=0 soft=0 hard=0
rfkill: initial event: idx=2 type=2 op=0 soft=0 hard=0
nl80211: Supported cipher 00-0f-ac:1
nl80211: Supported cipher 00-0f-ac:5
nl80211: Supported cipher 00-0f-ac:2
nl80211: Supported cipher 00-0f-ac:4
nl80211: Supported cipher 00-0f-ac:10
nl80211: Supported cipher 00-0f-ac:8
nl80211: Supported cipher 00-0f-ac:9
nl80211: Using driver-based off-channel TX
nl80211: interface wlan0 in phy phy0
nl80211: Set mode ifindex 3 iftype 2 (STATION)
nl80211: Subscribe to mgmt frames with non-AP handle 0x558a4f505140
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=040a
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=040b
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=040c
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=040d
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=090a
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=090b
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=090c
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=090d
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=0409506f9a09
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=7f506f9a09
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=0801
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=06
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=0a07
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=0a11
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=1101
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=1102
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x558a4f505140 match=0505
netlink: Operstate: ifindex=3 linkmode=1 (userspace-control), operstate=5 
(IF_OPER_DORMANT)
nl80211: driver param='(null)'
Add interface wlan0 to a new radio phy0
nl80211: Regulatory information - country=00
nl80211: 2402-2472 @ 40 MHz 20 mBm
nl80211: 2457-2482 @ 20 MHz 20 mBm (no IR)
nl80211: 2474-2494 @ 20 MHz 20 mBm (no OFDM) (no IR)
nl80211: 5170-5250 @ 80 MHz 20 mBm (no IR)
nl80211: 5250-5330 @ 80 MHz 20 mBm (DFS) (no IR)
nl80211: 5490-5730 @ 160 MHz 20 mBm (DFS) (no IR)
nl80211: 5735-5835 @ 80 MHz 20 mBm (no IR)
nl80211: 57240-63720 @ 2160 MHz 0 mBm
nl80211: Added 802.11b mode based on 802.11g information
wlan0: Own MAC address: 00:1f:3b:38:77:e3
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=0 
set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=1 
set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=2 
set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=3 
set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=4 
set_tx=0 seq_len=0 key_len=0
wpa_driver_nl80211_set_key: ifindex=3 (wlan0) alg=0 addr=(nil) key_idx=5 
set_tx=0 seq_len=0 key_len=0
wlan0: RSN: flushing PMKID list in the driver
nl80211: Flush PMKIDs
wlan0: Setting scan request: 0.10 sec
TDLS: TDLS operation not supported by driver
TDLS: Driver uses internal link setup
TDLS: Driver does not support TDLS channel switching
wlan0: WPS: UUID based on MAC address: 525a8782-38cb-534f-8dd8-c7f73d7da9d4
ENGINE: Loading dynamic engine
ENGINE: Loading dynamic engine
EAPOL: SUPP_PAE entering state 

Bug#883614: wpasupplicant fails to connect in v2.6

[Philip J Freeman]

Package: wpasupplicant
Version: 2:2.6-12
Severity: normal

Dear Maintainer,

   * Newer version of wpasupplicant appears to fail connecting to network.
   * Seems to have started after: 2017-11-30 15:20:52 upgrade 
wpasupplicant:amd64 2:2.4-1.1 2:2.6-11

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

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

Versions of packages wpasupplicant depends on:
ii  adduser   3.116
ii  libc6 2.25-3
ii  libdbus-1-3   1.12.2-1
ii  libnl-3-200   3.2.27-2
ii  libnl-genl-3-200  3.2.27-2
ii  libpcsclite1  1.8.22-1
ii  libreadline7  7.0-3
ii  libssl1.1 1.1.0g-2
ii  lsb-base  9.20170808

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  
pn  wpagui

-- no debconf information

-- Device:

03:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN 
[Kedron] Network Connection (rev 61)

-- Config:
ctrl_interface=/var/run/wpa_supplicant
network={
ssid="bycwifi"
key_mgmt=WPA-PSK
proto=WPA2
pairwise=CCMP
group=CCMP
psk="correctpasswd"
}

-- Log:

wpa_supplicant v2.6
random: Trying to read entropy from /dev/random
Successfully initialized wpa_supplicant
Initializing interface 'wlan0' conf 
'/home/elektron/.dotfiles/sec/wifi/byc.conf' driver 'default' ctrl_interface 
'N/A' bridge 'N/A'
Configuration file '/home/elektron/.dotfiles/sec/wifi/byc.conf' -> 
'/home/elektron/.dotfiles/sec/wifi/byc.conf'
Reading configuration file '/home/elektron/.dotfiles/sec/wifi/byc.conf'
ctrl_interface='/var/run/wpa_supplicant'
Line: 5 - start of a new network block
ssid - hexdump_ascii(len=7):
 62 79 63 77 69 66 69  bycwifi 
key_mgmt: 0x2
proto: 0x2
pairwise: 0x10
group: 0x10
PSK (ASCII passphrase) - hexdump_ascii(len=12): [REMOVED]
PSK (from passphrase) - hexdump(len=32): [REMOVED]
Priority group 0
   id=0 ssid='bycwifi'
nl80211: Supported cipher 00-0f-ac:1
nl80211: Supported cipher 00-0f-ac:5
nl80211: Supported cipher 00-0f-ac:2
nl80211: Supported cipher 00-0f-ac:4
nl80211: Supported cipher 00-0f-ac:10
nl80211: Supported cipher 00-0f-ac:8
nl80211: Supported cipher 00-0f-ac:9
nl80211: Using driver-based off-channel TX
nl80211: Driver-advertised extended capabilities (default) - hexdump(len=8): 00 
00 00 00 00 00 00 40
nl80211: Driver-advertised extended capabilities mask (default) - 
hexdump(len=8): 00 00 00 00 00 00 00 40
nl80211: interface wlan0 in phy phy0
nl80211: Set mode ifindex 3 iftype 2 (STATION)
nl80211: Subscribe to mgmt frames with non-AP handle 0x5629734afb20
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=040a
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=040b
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=040c
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=040d
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=090a
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=090b
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=090c
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=090d
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=0409506f9a09
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=7f506f9a09
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=0801
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=06
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=0a07
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=0a11
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=1101
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=1102
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=0505
nl80211: Register frame type=0xd0 (WLAN_FC_STYPE_ACTION) 
nl_handle=0x5629734afb20 match=0500
rfkill: initial event: idx=1 type=1 op=0 soft=0 hard=0
netlink: Operstate: ifindex=3 linkmode=1 (userspace-control), operstate=5 
(IF_OPER_DORMANT)
Add interface wlan0 to a new radio phy0
nl80211: Regulatory information - country=00
nl80211: 2402-2472 @ 40 MHz 20 mBm
nl80211: 2457-2482 @ 20 MHz 20 mBm (no IR)
nl80211: 2474-2494 @ 20 MHz 20 mBm 

Bug#883256: apparmor-profiles-extra: Totem can't access files outside $HOME

[Philip Rinn]

Package: apparmor-profiles-extra
Version: 1.16
Severity: important
User: pkg-apparmor-t...@lists.alioth.debian.org
Usertags: buggy-profile

Hi,

with the AppArmor profile enabled, I can't access any file outside my $HOME
directory. While I understand the idea behind it, it's rather annoying with my
setup (which is not too uncommon I think). I have a HDD for my media files
while everything else is on a SSD thus my media files live outside my $HOME 
directory.

I know how to fix the problem for myself but I think the profile is too strict
here.

Best,

Philip


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

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

Versions of packages apparmor-profiles-extra depends on:
ii  apparmor  2.11.1-3

apparmor-profiles-extra recommends no packages.

apparmor-profiles-extra suggests no packages.

-- no debconf information



signature.asc
Description: OpenPGP digital signature

Bug#838503: debian-installer: mdadm should not start syncing RAID1 arrays at full speed during installation

[Philip Hands]

On Mon, 27 Nov 2017, Mikhail Zakharenko <mikhail.zakhare...@gmail.com> wrote:
> Hi Cyril!
>
> Could You provide preseed variable for "dev.raid.speed_limit_max" sysctl 
> setting?
> I want to adjust it to near acceptable value around 50Mbytes per second, 
> because RAID 1 installation is really slow now

This seems like a bit of a kludge to me.

Do dpkg pre and post hooks work in the context of d-i?

If so, could we not just have a hook for dpkg install that tunes the max
setting down low to avoid the conflict, and turn it back up again
afterwards?

I suspect that that would not result in a significant slow-down of the
sync, while getting rid of the performance issue.

To address the concern about leaving people with still-sync-ing systems
post-reboot (which is not actually prevented by the status quo, I note)
we could add an extra progress screen near the end of the install.

It could track the progress of any remaining md sync (if any), while
pointing out that cancelling out of the screen will do no harm, and will
only mean that the sync that one is waiting for is going to be completed
post reboot.

A preseed variable to allow always skipping past that progress screen
would seem like a reasonable thing to have, if we did all the above.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#880875: please rename source package to r-cran-scatterplot3d

[Philip Rinn]

Hi Sébastien,

On 22.11.2017 at 11:13, Sébastien Villemot wrote:
> Hi Philip,
> 
> On Mon, Nov 06, 2017 at 03:10:33PM +0100, Philip Rinn wrote:
> 
>> On 06.11.2017 at 11:16, Philip Rinn wrote:
>>> I'll rename the package on the next upload and ping you for sponsorship 
>>> (I'm only
>>> DM and the package has to go through NEW).
> 
>> Could you please review and sponsor my upload?
> 
> Upload accepted by ftpmasters.

I saw it, yeah :-)

> 
>> Could you also give me upload rights for r-cran-scatterplot3d? With the 
>> rename
>> I'll loose my upload rights as they are bound to the source package name.
>>
>> Fingerprint: 2BD8D4E397955F7746DB3B89AD6916967393982B
>> Uid: Philip Rinn <ri...@inventati.org>
> 
> I gave you upload rights on the new package.
> 
> I also requested the removal of the old source package (#882401).

Thanks!

Best,

Philip



signature.asc
Description: OpenPGP digital signature

Bug#882219: stretch-pu: package corebird/1.4.1-1+deb9u1

[Philip Rinn]

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

Dear release team,

Twitter changed the character limit of tweets to 280 chars (see [1]). The
version of corebird in stretch does only allow to compose tweets with 140
chars. The fix is really trivial[2].

Would you allow an update of corebird?

Best,

Philip


[1]
https://blog.twitter.com/official/en_us/topics/product/2017/tweetingmadeeasier.html

[2]
https://github.com/baedert/corebird/commit/d3cc0b068b4f3b1d0d97e4bd7c9e723d002636c1
diff -Nru corebird-1.4.1/debian/changelog corebird-1.4.1/debian/changelog
--- corebird-1.4.1/debian/changelog 2017-01-09 15:16:58.0 +0100
+++ corebird-1.4.1/debian/changelog 2017-11-20 11:43:37.0 +0100
@@ -1,3 +1,9 @@
+corebird (1.4.1-1+deb9u1) stretch; urgency=medium
+
+  * Allow 280 characters per tweet
+
+ -- Philip Rinn <ri...@inventati.org>  Mon, 20 Nov 2017 11:43:37 +0100
+
 corebird (1.4.1-1) unstable; urgency=medium
 
   * New upstream release:
diff -Nru corebird-1.4.1/debian/patches/01-allow-280-characters.patch 
corebird-1.4.1/debian/patches/01-allow-280-characters.patch
--- corebird-1.4.1/debian/patches/01-allow-280-characters.patch 1970-01-01 
01:00:00.0 +0100
+++ corebird-1.4.1/debian/patches/01-allow-280-characters.patch 2017-11-16 
12:09:28.0 +0100
@@ -0,0 +1,13 @@
+Description: Twitter changed the limit to 280 characters
+Author: Timm Bäder <m...@baedert.org>
+--- a/src/CbTweet.h
 b/src/CbTweet.h
+@@ -23,7 +23,7 @@
+ #include "CbTypes.h"
+ #include "CbMedia.h"
+ 
+-#define CB_TWEET_MAX_LENGTH 140
++#define CB_TWEET_MAX_LENGTH 280
+ 
+ typedef enum
+ {
diff -Nru corebird-1.4.1/debian/patches/series 
corebird-1.4.1/debian/patches/series
--- corebird-1.4.1/debian/patches/series1970-01-01 01:00:00.0 
+0100
+++ corebird-1.4.1/debian/patches/series2017-11-16 12:09:28.0 
+0100
@@ -0,0 +1 @@
+01-allow-280-characters.patch

Bug#881901: openvpn: 'management tunnel' now ignores the port setting

[Philip Hands]

Package: openvpn
Version: 2.4.0-6+deb9u2
Severity: normal

Dear Maintainer,

In version 2.3.4-5+deb8u2, if one had a setting of, e.g.:

  management tunnel 5656

the behaviour was as documented -- it would wait for the tunnel to come up,
and then listen on port 5656 for the management interface.

Having upgraded to 2.4.0-6+deb9u2, the port number seems to be ignored,
as you can see here:

  # grep management /etc/openvpn/vpn1.conf
  management tunnel 5656

  # netstat -tlnp | grep openvpn
  tcp0  0 172.12.34.14:43125  0.0.0.0:*   LISTEN
  495/openvpn

Downgrading to 2.3.4-5+deb8u2 restores the previous behaviour.

It seems that if you specify an IP address, rather than "tunnel" then
it uses a different code path, which does the listen before the tunnel
comes up, and it does then use the specified port.  This cannot be used
as a workaround though if you want it to listen on the tunnel address,
since the interface is not up at this point.

Cheers, Phil.

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  init-system-helpers1.48
ii  iproute2   4.9.0-1
ii  libc6  2.24-11+deb9u1
ii  liblz4-1   0.0~r131-2+b1
ii  liblzo2-2  2.08-1.2+b2
ii  libpam0g   1.1.8-3.6
ii  libpkcs11-helper1  1.21-1
ii  libssl1.0.21.0.2l-2+deb9u1
ii  libsystemd0232-25+deb9u1
ii  lsb-base   9.20161125

Versions of packages openvpn recommends:
ii  easy-rsa  2.2.2-2

Versions of packages openvpn suggests:
ii  openssl 1.1.0f-3+deb9u1
ii  resolvconf  1.79

-- debconf information:
  openvpn/create_tun: false

Bug#881113: mailman3-core: Package should suggest lynx

[Philip Frei]

Package: mailman3-core
Version: 3.1.0-1
Severity: minor

Dear Maintainer,

Mailman uses lynx to convert html to plain text messages. Maybe it's a
good idea to add lynx to the package suggestions.



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

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

Bug#880875: please rename source package to r-cran-scatterplot3d

[Philip Rinn]

Hi Sébastien,

On 06.11.2017 at 11:16, Philip Rinn wrote:
> I'll rename the package on the next upload and ping you for sponsorship (I'm 
> only
> DM and the package has to go through NEW).

lets do it now, I prepared an upload and uploaded it to mentors.d.o:

https://mentors.debian.net/package/r-cran-scatterplot3d

I also updated the git repository:

https://anonscm.debian.org/cgit/debian-science/packages/scatterplot3d.git


Could you please review and sponsor my upload?

Could you also give me upload rights for r-cran-scatterplot3d? With the rename
I'll loose my upload rights as they are bound to the source package name.

Fingerprint: 2BD8D4E397955F7746DB3B89AD6916967393982B
Uid: Philip Rinn <ri...@inventati.org>


Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#880875: please rename source package to r-cran-scatterplot3d

[Philip Rinn]

Hi,

On 05.11.2017 at 13:06, Sébastien Villemot wrote:
> No need to carry a transitional package. Just rename the source (and the git
> repository), and upload it. I think it will have to go through NEW, though, 
> but
> I'm not sure. Then you'll have to request the removal of the old source
> package once the new one is accepted. This has already been done for quite a
> few other CRAN packages.

True, no transitional package is needed, it's only a change in the source 
package
name.

I'll rename the package on the next upload and ping you for sponsorship (I'm 
only
DM and the package has to go through NEW).
[I already renamed the git repository and created a symlink to the old location
(which has to stay until buster becomes oldoldstable :-().]


Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#880875: please rename source package to r-cran-scatterplot3d

[Philip Rinn]

Hi,

On 05.11.2017 at 10:54, Sébastien Villemot wrote:
> scatterplot3d is the only CRAN package maintained in Debian Science Team whose
> source package name does not begin with "r-cran".
>
> Please rename the source package to r-cran-scatterplot3d, to facilitate the
> identification of the package when making searches on source package names, 
> and
> also for consistency.

is it really worth the hassle? Carrying a transitional package around, going
through new again, etc.? There are packages around outside Debian Science which
doesn't use r-*- as source package name. To identify R packages you
have to look for (Build-)Dependencies anyway as some not-only-R-packages build
binary R packages ... and there is still the section "gnu-r" to identify them -
well, sadly not really [1].

I'd rather ask why don't the other R packages in Debian Sciences follow the
recommendation in the "Debian R Policy"[2] section 2.1?

"The Debian source package can in most cases retain the  name. E.g., 
for
the examples above one could use car, affy, rgtk and lindsey. This makes it
consistent with the upstream archive: CRAN mirrors will have a current tar.gz 
file
with sources for car, and so will Debian mirrors."


Well, if you have strong feelings about renaming the package I'll do it with the
next upstream version but I don't really see the point.

Best,
Philip


[1] https://lists.debian.org/debian-med/2015/04/msg00048.html
[2] https://lists.debian.org/debian-devel/2003/12/msg02332.html



signature.asc
Description: OpenPGP digital signature

Bug#878590: systemd: jessie to stretch upgrade resulted in eth0 being given a new style predictable name (enp1s9)

[Philip Hands]

Package: systemd
Version: 232-25+deb9u1
Severity: important

Hi,

After upgrading to Stretch, the system came up with its NIC named as
enp1s9, and thus had no working network (since eth0 was configured
in /etc/network/interfaces), requiring me to get console access to
fix things.

I suspect that this is the result of me having two empty udev rules
files on the system, prior to the upgrade:

 udev/rules.d/70-persistent-net.rules
 udev/rules.d/75-persistent-net-generator.rules

Those empty files being there in order to ensure that the one NIC in
the machine will never end up being called anything other than eth0,
not even if the NIC gets replaced.

It is my suspicion that something is checking for the existence of
the persistent-net rules file, and if it is there, is assuming that it
contains a rule to keep the NIC named as whatever it was named before.

If that is the case, I broke that assumption.

I can imagine that dealing with this case automatically might be rather
tiresome.

I would have been happy if the upgrade had failed with a warning that
having an empty 70-persistent-net.rules is not supported, and that I
should take steps to either define the new names in network/interfaces,
or add net.ifnames=0 to the kernel command line, or perhaps recommending
a new udev rule that would have the effect of naming the one NIC in the
machine as 'en0' say, if there is a nice way of doing that which survives
the NIC being replaced.

If something else is going on, I realise that this report is very light
on detail, and will be happy to do any tests, or provide any further
details to work out what's really going on here -- please just ask.

I believe that what I did was the recommended way of getting the behaviour
I wanted, and that the intention was that NIC naming should be preserved
on upgrade, hence the severity of important, since this breaks networking,
which might cause significant inconvenience for people.

I'm sorry if this should be reported against e.g. udev instead, but the
persistent naming seems to be under the aegis of systemd, so this seemed
like a reasonable starting point -- please reassign as appropriate.

BTW I note that the recommendation from here:
  
https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/
to restore the old behaviour by doing:

  ln -s /dev/null /etc/systemd/network/99-default.link

does not work on this system, so at present I'm adding net.ifnames=0 to
the kernel command line to restore the 'eth0' name.

Cheers, Phil.


-- Package-specific info:

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

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

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1
ii  libc6   2.24-11+deb9u1
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u2
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1
ii  libselinux1 2.6-3+b3
ii  libsystemd0 232-25+deb9u1
ii  mount   2.29.2-1
ii  procps  2:3.3.12-3
ii  util-linux  2.29.2-1

Versions of packages systemd recommends:
ii  dbus1.10.22-0+deb9u1
ii  libpam-systemd  232-25+deb9u1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 232-25+deb9u1

-- no debconf information

Bug#878332: linux-armmp-lpae: Raspberry pi 2 hangs at boot

[Philip Rinn]

Control: retitle -1 linux > 4.11: Raspberry pi 2 hangs at boot with lpae kernel
Control: severity -1 normal

Hi,

I'm fine with using a non-lpae kernel. (Unlocking the crypt rootfs works now.)
I couldn't get any additional output on the console with adding earlyprintk[1] 
to
the kernel cmdline. So I'm giving up.

I'm sill open to test new things to find the cause.

Best,
Philip


[1] I tried:
 - earlyprintk
 - earlyprintk=serial,ttyAMA0,115200
 - earlyprintk=serial,ttyS0,115200



signature.asc
Description: OpenPGP digital signature

Bug#878332: linux-armmp-lpae: Raspberry pi 2 hangs at boot

[Philip Rinn]

Hi,

On 13.10.2017 at 15:05, Sebastian Reichel wrote:
> 4.12 introduced a new mmc driver, that was not enabled in the
> Debian kernel resulting in rootfs not being found. It has been
> enabled in 4.13.4-1, which is available in sid:
> 
> [armhf,arm64] mmc: Enable MMC_BCM2835 (Closes: #845422)

I know, but I was able to boot 4.12.0-0.bpo.2-armmp without problems. While I
couldn't boot 4.13.0-1-armmp-lpae. For me lpae makes the difference not the new
mmc driver (the old one is still there afaik).

> Also your kernel cmdline is probably incorrect for early
> printing, which works with the Debian kernel on RPi2 (and
> properly displayed the rootfs could not be found problem
> for 4.12 kernels):
> 
> earlyprintk console=ttyAMA0,115200 root=/dev/mmcblk0p2 rootwait

Oh, good to know, thanks.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#878332: linux-armmp-lpae: Raspberry pi 2 hangs at boot

[Philip Rinn]

Hi,

booting a non-lpae kernel (4.12.0-0.bpo.2-armmp) works - I still have a problem
unlocking my encrypted rootfs but that's another problem.

Is this a known regression?

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#878332: linux-armmp-lpae: Raspberry pi 2 hangs at boot

[Philip Rinn]

Control: reassign -1 src:linux
Control: retitle -1 linux-armmp-lpae (> 4.11.6): Raspberry pi 2 hangs at boot

Hi,

just to make it clear: Version 4.11.6 is the last working kernel for me.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#878332: linux-armmp-lpae: Raspberry pi 2 hangs at boot

[Philip Rinn]

Package: linux-armmp-lpae
Version: 4.12+85~bpo9+1
Severity: important

Hi,

starting with kernel 4.12 (but I also tested 4.13 from sid). My Raspberry pi 2
hangs at boot with this. All I get at boot is this:

U-Boot 2017.09+dfsg1-3 (Oct 09 2017 - 22:14:03 +)

DRAM:  998 MiB
RPI 2 Model B (0xa01041)
MMC:   sdhci@7e30: 0
reading uboot.env

** Unable to read "uboot.env" from mmc0:1 **
Using default environment

In:serial
Out:   vidconsole
Err:   vidconsole
Net:   No ethernet found.
starting USB...
USB0:   Core Release: 2.80a
scanning bus 0 for devices... 3 USB Device(s) found
   scanning usb for storage devices... 0 Storage Device(s) found
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot.scr
reading /boot.scr
2630 bytes read in 11 ms (233.4 KiB/s)
## Executing script at 0200
3985984 bytes read in 321 ms (11.8 MiB/s)
12042 bytes read in 69 ms (169.9 KiB/s)
17711567 bytes read in 1252 ms (13.5 MiB/s)
Booting Debian 4.12.0-0.bpo.2-armmp-lpae from mmc 0:3...
Kernel image @ 0x100 [ 0x00 - 0x3cd240 ]
## Flattened Device Tree blob at 0100
   Booting using the fdt blob at 0x000100
   reserving fdt memory region: addr=0 size=1000
   Using Device Tree in place at 0100, end 6009

Starting kernel ...


Appending "debug" to the kernel command line didn't show any other messages. I
can't enable EARLY_PRINTK as it depends on DEBUG_LL which is incompatible with
multiplatform :-(. How should I proceed now?

I would do some git-bisecting but I'm lost at which commit to start - I
obviously can't just start at commit 1 after 4.11.6 as it would take ages to
compile and test all the resulting kernels :-(


BTW: Updating u-boot didn't help either (this was my first hope)


Best,
Philip



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

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

Bug#877024: modemmanager should ask before messing with serial ports

[Philip Hands]

Aleksander Morgado <aleksan...@aleksander.es> writes:

> Hey Ian,
>
> On Thu, Oct 12, 2017 at 2:39 PM, Ian Jackson
> <ijack...@chiark.greenend.org.uk> wrote:
>> Aleksander Morgado writes ("Bug#877024: modemmanager should ask before 
>> messing with serial ports"):
>>> This is part of the discussion we had in the MM mailing list for such
>>> a solution:
>>> https://lists.freedesktop.org/archives/modemmanager-devel/2017-September/005917.html
>>
>> Thanks, this looks constructive.
>>
>> Of the heuristics in that mail, most seem to me to be very sound
>> justifications for thinking that the device is safe to probe.
>>
>> The one big exception is this:
>>
>>  | * If vid is a known modem vendor (e.g. huawei, zte, sierra, u-blox,
>>  |  telit), it's a modem and we probe the tty.
>>
>> This is a hostage to the future, since of course we don't know what
>> devices might be manufactured by a particular vendor in the many-years
>> life of a Debian release.
>>
>
> Yes, this one is probably the weakest rule of all. Still not sure at
> which point to apply the rule, though. E.g. should it be applied after
> having applied all the previous rules (in that case it would be a very
> safe rule, maybe totally unneeded) or should it be applied as an OR to
> some other rule (e.g. driver is option/sierra/qcserial OR vendor is
> huawei/zte..., in this case it would be a weaker rule). Will need to
> decide this based on testing with real devices.

It's nice to see that a workable solution seems to be emerging here.

My opinion on the final wrinkle is that for Debian, in the case of
uncertainty, modemmanager should not be probing, and that guessing based
on manufacturer seems insufficiently certain.

Optimistic probing hides the fact that one doesn't _really_ know the
device is a modem.  The result being that the bug report mentioning the
features of the device that might allow an improved heuristic to be
developed is never going to be submitted.

That being the case, I agree with Ian that if such behaviour is
implemented, it would be best if it can be disabled at run-time, and that
the Debian package should then default to disabling it.

Having the option to enable it at run-time would still be useful, so
that people that know that they really do have a modem, can:

  read the package's README to discover why it doesn't work

  report a bug saying what sort of modem they have, and that it's not
  being found by the Debian default configuration of MM

  and then flick the switch to make modemmanager optimistic enough to
  find their modem (on the understanding that it might break other
  stuff they could plug in, but at least they'll know why)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Philip Hands]

Sean Whitton <spwhit...@spwhitton.name> writes:

> Hello Jérémy,
>
> On Tue, Oct 03 2017, Jérémy Lal wrote:
>
>> It might be a good idea to make policy more explicit about downloads
>> during build.
>
> I'm not sure how it could be more explicit:
>
> For packages in the main archive, no required targets may attempt
> network access.

The problem seems to be that Praveen reads that prohibition as implying
that it is totally OK to do this when not in main.

This strikes me as equivalent to reading:

  All men are mortal, 
  Socrates is a man,

and concluding that women are immortal.

The correct way to read this bit of policy is that network access during
build is considered such a bad idea that it is not allowed under any
circumstances in Debian proper (main).

That being the case, it is a safe bet to assume that it's a bad idea in
packages in contrib and non-free too.

If one wants to vary from that, the reason should be made very clear
indeed.

I don't believe that Praveen has provided any real justification for
needing network access, beyond his opinion that policy allows it.

I suspect that in the particular case of using rollup, it is even worse
than Simon McVittie eloquently describes in his mail to this thread.

A quick read of rollup's changelog shows that they have had about 30
releases since July, that they've recently had a major refactoring, and
that every release since that refactoring has involved fixing that
refactoring.

They had a release within a day of Praveen's changelog entry for the
package, so it's not completely obvious which version of rollup would
have been used for the package build, but chances are that he used one
version, and that within 24 hours nobody, not even Praveen, would be
certain of being able to reproduce that package because it would then be
using a new version of rollup to do all the work.

They've had another release since -- more fixups for the refactoring.

I'm astonished that Praveen thinks it is sensible to build on these
shifting sands.  My astonishment is then only magnified at every step:

  o  When it is pointed out, still not realising the folly of this.
  o  Running to policy, looking for excuses.
  o  Blaming ftp masters for not noticing these flaws.
  o  Insisting that the TC needs to be involved to fix the mess

Should we really try to make policy forbid all the foolish ways in which
one might try to assemble a package, in order to ensure that there is
nowhere for people to hide in policy?  I think not.

It would seem much more straightforward to remove the upload rights from
people who insist on repeating this sort of behaviour incessantly.

Praveen, please don't do it again.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#877699: linux-source: Please enable new drivers for Broadcom bcm2835 family

[Philip Rinn]

Package: linux-source
Version: 4.12.13-1
Severity: wishlist

Hi,

there are new drivers for the thermal sensor [1] and for the sdhost controller
[2] of the bmc2835 family. Could you please build them as modules?

Adding the two config options should enable them:

CONFIG_BCM2835_THERMAL=m
CONFIG_MMC_BCM2835=m

Thanks,

Philip

[1]
https://github.com/torvalds/linux/commit/bcb7dd9ef206f7d646ed8dac6fe7772083714253
[2]
https://github.com/torvalds/linux/commit/660fc733bd7436f4fa1a351376493e635514ed64



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

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

Versions of packages linux-source depends on:
pn  linux-source-4.12  
pn  linux-source-4.13  

linux-source recommends no packages.

linux-source suggests no packages.

Bug#876069: i386 applications using JNI may crash due to Hotspot workaround for Exec Shield

[Philip Hands]

Hi Ben,

I thought you'd like to know that, having applied your patch to
openjdk-8, and built it in an i386 chroot, the result fixes the
consistent lo-writer crashes I was seeing with the released version.

It was pretty disappointing to discover that on a clean stretch install
that I'd just done for a newbie, there were no viable word processors
because lo-writer just crashed, and abiword currently has a bug where it
madly refreshes the screen.

Thanks very much for finding this, and thus removing the egg from my
face :-)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#875423: openssl: Please re-enable TLS 1.0 and TLS 1.1 (at least in testing)

[Philip Hands]

Raphaël Hertzog <hert...@debian.org> writes:

...
> Or at least I would like a system-wide flag (in a configuration file?) to
> let me re-enable old protocols easily.

Just because I haven't seen anyone else suggest it:

Would it be practical to have the normal packages drop TLS 1.0/1.1
support as currently planned, but have an alternative set of packages
(called openssl-obsolescent, or openssl-tls-flawed, or whatever) with
the TLS 1.0/1.1 support re-enabled, so that one could do the migration
away from TLS 1.0/1.1, but still allow people who notice problems to
deal with them by choosing to install this other set of packages?

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#875330: O: brewtarget -- needs a new maintainer

[Philip Lee]

Package: wnpp
Severity: normal

The debian packaging for this project has been maintained here:
https://github.com/Brewtarget/debian-packaging I would love someone to take
over this repo. The source packages are here, including 2.3.1-1 which
should be uploaded to debian ASAP:
https://github.com/Brewtarget/brewtarget/releases

Bug#853491: libffado: ftbfs with GCC-7

[Philip Chung]

Control: tags -1 patch
Control: affects 871274 src:libffado

On Tue, 31 Jan 2017 09:32:52 + Matthias Klose <d...@debian.org> wrote:
> Package: src:libffado
> Version: 2.3.0-2
> Severity: normal
> Tags: sid buster
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-7
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-7/g++-7, but succeeds to build with gcc-6/g++-6. The
> severity of this report may be raised before the buster release.
> There is no need to fix this issue in time for the stretch release.
> 
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc7-20170126/libffado_2.3.0-2_unstable_gcc7.log
> The last lines of the build log are at the end of this report.
> 
> To build with GCC 7, either set CC=gcc-7 CXX=g++-7 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
> 
>   apt-get -t=experimental install g++ 
> 
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-7/porting_to.html
> 
> [...]
> /usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
>template class auto_ptr;
> ^~~~
> In file included from src/fireworks/fireworks_device.cpp:30:0:
> src/fireworks/audiofire/audiofire_device.h:37:39: warning: 'template 
> class std::auto_ptr' is deprecated [-Wdeprecated-declarations]
>  AudioFire( DeviceManager& d, std::auto_ptr( configRom ));
>^~~~
> In file included from /usr/include/c++/7/memory:80:0,
>  from 
> /usr/include/libxml++-2.6/libxml++/parsers/saxparser.h:14,
>  from /usr/include/libxml++-2.6/libxml++/libxml++.h:53,
>  from src/libutil/serialize_libxml.h:29,
>  from src/libutil/serialize.h:32,
>  from src/libieee1394/configrom.h:32,
>  from src/devicemanager.h:30,
>  from src/fireworks/fireworks_device.cpp:25:
> /usr/include/c++/7/bits/unique_ptr.h:51:28: note: declared here
>template class auto_ptr;
> ^~~~
> src/fireworks/fireworks_device.cpp:52:39: warning: 'template class 
> std::auto_ptr' is deprecated [-Wdeprecated-declarations]
>  Device::Device(DeviceManager& d, std::auto_ptr( configRom ))
>^~~~
> In file included from /usr/include/c++/7/memory:80:0,
>  from 
> /usr/include/libxml++-2.6/libxml++/parsers/saxparser.h:14,
>  from /usr/include/libxml++-2.6/libxml++/libxml++.h:53,
>  from src/libutil/serialize_libxml.h:29,
>  from src/libutil/serialize.h:32,
>  from src/libieee1394/configrom.h:32,

Attached is a patch that will fix the compilation errors.

The errors occur because pointers are being compared against the
character literal '\0' rather than 0. An initial reading of the code
suggests that the intent is to dereference the pointers first. The patch
dereferences the pointers using array syntax.

The code now compiles, the package still fails to build because of
linking problems with libconfig++ [1].

[1] https://bugs.debian.org/871274
Description: Fix pointer comparisons with null terminators
Author: Philip Chung <philipchung1...@yahoo.com>
Bug-Debian: https://bugs.debian.org/853491
Last-Update: 2017-09-04

Index: libffado/src/libieee1394/configrom.cpp
===
--- libffado.orig/src/libieee1394/configrom.cpp
+++ libffado/src/libieee1394/configrom.cpp
@@ -176,7 +176,7 @@ ConfigRom::initialize()
 ( void* )CSR1212_TEXTUAL_DESCRIPTOR_LEAF_DATA( m_vendorNameKv ),
 len );
 
-while ((buf + len - 1) == '\0') {
+while (buf[len - 1] == '\0') {
 len--;
 }
 // \todo XXX seems a bit strage to do this but the nodemgr.c code does
@@ -195,7 +195,7 @@ ConfigRom::initialize()
 memcpy( buf,
 ( void* )CSR1212_TEXTUAL_DESCRIPTOR_LEAF_DATA( m_modelNameKv ),
 len );
-while ((buf + len - 1) == '\0') {
+while (buf[len - 1] == '\0') {
 len--;
 }
 // \todo XXX for edirol fa-66 it seems somehow broken. see above

Bug#872674: puredata-import FTBFS with puredata 0.48.0-1

[Philip Chung]

Control: tags -1 patch

On Sun, 20 Aug 2017 03:30:19 +0300 Adrian Bunk <b...@debian.org> wrote:
> Source: puredata-import
> Version: 1.3-3
> Severity: serious
> Tags: buster sid
> 
> https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/puredata-import.html
> 
> ...
> make -j1
> make[1]: Entering directory '/build/1st/puredata-import-1.3'
> cc -I"/usr/include/pd" -Wall -W -g -DPD -DVERSION='"1.3"' -fPIC -O6 
> -funroll-loops -fomit-frame-pointer -o "import.o" -c "import.c"
> In file included from import.c:2:0:
> s_stuff.h:48:12: error: conflicting types for 'sys_hostfontsize'
>  EXTERN int sys_hostfontsize(int fontsize);
> ^~~~
> In file included from import.c:1:0:
> /usr/include/pd/m_pd.h:436:12: note: previous declaration of 
> 'sys_hostfontsize' was here
>  EXTERN int sys_hostfontsize(int fontsize, int zoom);
> ^~~~
> import.c: In function 'import_new':
> import.c:112:12: warning: unused variable 'currentdir' [-Wunused-variable]
>   t_symbol *currentdir;
> ^~
> import.c:109:35: warning: unused parameter 's' [-Wunused-parameter]
>  static void *import_new(t_symbol *s, int argc, t_atom *argv)
>^
> import.c: In function 'import_free':
> import.c:138:35: warning: unused parameter 'x' [-Wunused-parameter]
>  static void import_free(t_import *x)
>^
> Makefile:191: recipe for target 'import.o' failed
> make[1]: *** [import.o] Error 1
> 
> 

The solution is to simply remove debian/patches/add_required_headers.h

The Debian packages for Pure Data now include the required headers, and
the local headers added in the patch are now out of sync.

Philip Chung

Bug#873807: ssh-askpass FTCBFS: xmkmf is unfixable

[Philip Hands]

Helmut Grohne <hel...@subdivi.de> writes:

> Source: ssh-askpass
> Version: 1:1.2.4.1-9
> Tags: patch upstream
> User: helm...@debian.org
> Usertags: rebootstrap
> Control: block 873764 by -1
>
> ssh-askpass fails to cross build from source, because ... it uses xmkmf.
> I looked at xmkmf hard and there seems to be no way to make this work at
> all. I talked to vorlon, and we agreed that xmkmf should just die
> (#873764). As such I am asking you to migrate away from xmkmf. I am
> attaching a patch moves to autoconf in a minimal way that makes the
> binary package look mostly equal to the original package (according to
> diffoscope). Oh and the patch makes cross building work. Can you apply
> it? Or at least, can you remove xmkmf usage?

Done, and thanks very much for the patch, and the nudge.

I've been neglecting this package for way too long, so that gave me a
reason to fix some old bugs too.  :-)

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#820904: ssh-askpass: cannot control position of ssh-askpass window

[Philip Hands]

Tony Finch <d...@dotat.at> writes:

> Package: ssh-askpass
> Version: 1:1.2.4.1-9
> Severity: wishlist
> Tags: upstream patch
>
> Dear Philip,
>
> I am using i3-wm with two monitors and Xrandr.
>
> In this setup, ssh-askpass plonks itself over the crack between the screens.
> It doesn't have any facility to control where it places itself.

Sorry for the tardy response -- dealing with ssh-askpass bugs has been
bobbing just below the point where I get round to it on my TODO list for
far too long.

Anyway, since I'm now preparing a release, I looked at this, and it
occurs to me that it might be more useful to be able to specify the
position on the screen as e.g. a percentage of the width/height.

Currently it goes for the middle of the X axis, and one third from the
top on the Y.  We could therefore have resources xPercent and yPercent
that default to 50 and 33 respectively to attain the same effect (bar
rounding) and for your 2 screen setup you could set yPercent to 25, say,
to get it in the middle of one screen.

Would that work for you?

That strikes me as better than using an absolute position, but perhaps
there is something I'm not considering.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Philip Hands]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> Jérémy Lal writes ("Bug#862051: nodejs (6.11.2~dfsg-1) experimental; 
> urgency=medium"):
>> Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs
>> until it's no longer needed - be it other debian packages or other user
>> scripts.
>
> Earlier you said only "other Debian packages":
>
>My plan was to simply keep /usr/bin/nodejs around for some time
>until no debian package rely on it.
>
> Now you say "other user scripts".  I don't know how you would ever
> tell whether "other user scripts" were relying on it.  There is no way
> to for us to tell what people are doing on their computers (and nor
> should there be).

I guess that one could do something like moving the symlink into another
-legasy style package, and recomend that from the main package for one
release to keep upgrades happy. Then drop the recomendation, and wait
for popcon to show that people are not installing the package any more.
Then remove the package in testing early in a cycle and see if anyone
reports bugs about it.

That seems like rather a lot of effort though, when the alternative is
simply tolerating the existence of the two line debian/nodejs.links file.

Is there some down-side for users to having those links in place on
their systems?  If so, I don't think anyone's mentioned it yet.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Philip Hands]

Jérémy Lal <kapo...@melix.org> writes:

> 2017-08-30 11:50 GMT+02:00 Philip Hands <p...@hands.com>:
>
>> Jérémy Lal <kapo...@melix.org> writes:
>>
>> > 2017-08-29 21:39 GMT+02:00 Didier 'OdyX' Raboud <o...@debian.org>:
>> >
>> >> Le mardi, 29 août 2017, 17.46:22 h CEST Thorsten Glaser a écrit :
>> >> > Leave /usr/bin/nodejs there for at least one more release.
>> >>
>> >> I'll just note for the purpose of the TC discussion that as of nodejs
>> >> 6.11.2~dfsg-3 (the version currently in unstable) , the /usr/bin/nodejs
>> →
>> >> node
>> >> symlink still exists, so at this point, I don't consider there is
>> material
>> >> for
>> >> a TC decision either way, but it's an important conversation to be had.
>> >>
>> >> Jérémy: could you maybe clarify your plan and your rationale? This would
>> >> help
>> >> putting everyone on common grounds.
>> >>
>> >
>> > I replaced /usr/bin/nodejs by /usr/bin/node, and made a symlink from
>> > /usr/bin/nodejs to /usr/bin/node.
>> > My plan was to simply keep /usr/bin/nodejs around for some time until
>> > no debian package rely on it. The JavaScript debian team wiki is updated
>> > to reflect that.
>>
>> I was against the TC instructing you how to behave in detail in our
>> resolution, because I couldn't imagine that anyone would think that
>> tidiness was more important than not breaking things for our users.
>>
>> Are you really going to prove me wrong?
>>
>> How much is it costing you to keep the symlink there?
>>
>> Do you expect that cost to ever exceed the effort of responding to even
>> the first bug reported about this, when you turn out to have broken
>> someone's locally-written script?
>>
>> Actually, do you expect it to ever exceed the effort already wasted in
>> responding to this thread by you and us?
>>
>> It's pretty clear that if you do decide to go ahead and remove
>> /usr/bin/nodejs quickly, that someone is likely to kick the matter back
>> up to the TC.
>>
>> I for one will have absolutely no sympathy with your side of the case at
>> that point, not only because I think it is senseless, but also because
>> you'll have been responsible for wasting the time of all involved.
>>
>> I will also not be even slightly timid about micro-managing you the
>> second time around, since if that comes to pass you'll have demonstrated
>> the need.
>
>
> Maybe i didn't express myself properly: the idea is to keep /usr/bin/nodejs
> until it's no longer needed - be it other debian packages or other user
> scripts.
> If it was to be really removed, it shouldn't be done without some
> deprecation
> warning and time for users to notice and change their code.

Ah, well -- that's all fine then.  Thanks for clarifying.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#754462: Bug#862051: nodejs (6.11.2~dfsg-1) experimental; urgency=medium

[Philip Hands]

Jérémy Lal <kapo...@melix.org> writes:

> 2017-08-29 21:39 GMT+02:00 Didier 'OdyX' Raboud <o...@debian.org>:
>
>> Le mardi, 29 août 2017, 17.46:22 h CEST Thorsten Glaser a écrit :
>> > Leave /usr/bin/nodejs there for at least one more release.
>>
>> I'll just note for the purpose of the TC discussion that as of nodejs
>> 6.11.2~dfsg-3 (the version currently in unstable) , the /usr/bin/nodejs →
>> node
>> symlink still exists, so at this point, I don't consider there is material
>> for
>> a TC decision either way, but it's an important conversation to be had.
>>
>> Jérémy: could you maybe clarify your plan and your rationale? This would
>> help
>> putting everyone on common grounds.
>>
>
> I replaced /usr/bin/nodejs by /usr/bin/node, and made a symlink from
> /usr/bin/nodejs to /usr/bin/node.
> My plan was to simply keep /usr/bin/nodejs around for some time until
> no debian package rely on it. The JavaScript debian team wiki is updated
> to reflect that.

I was against the TC instructing you how to behave in detail in our
resolution, because I couldn't imagine that anyone would think that
tidiness was more important than not breaking things for our users.

Are you really going to prove me wrong?

How much is it costing you to keep the symlink there?

Do you expect that cost to ever exceed the effort of responding to even
the first bug reported about this, when you turn out to have broken
someone's locally-written script?

Actually, do you expect it to ever exceed the effort already wasted in
responding to this thread by you and us?

It's pretty clear that if you do decide to go ahead and remove
/usr/bin/nodejs quickly, that someone is likely to kick the matter back
up to the TC.

I for one will have absolutely no sympathy with your side of the case at
that point, not only because I think it is senseless, but also because
you'll have been responsible for wasting the time of all involved.

I will also not be even slightly timid about micro-managing you the
second time around, since if that comes to pass you'll have demonstrated
the need.

Be warned.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#852975: dvb_usb_dw2102 uses stack for USB buffers

[Philip Rinn]

Control: fixed -1 linux/4.12.6-1

Hi,

this is fixed at least for linux 4.12. Don't know about other versions.

Thanks,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#872790: ITP: node-shell-quote -- quote and parse shell commands

[Philip Hands]

Bastien ROUCARIES <roucaries.bast...@gmail.com> writes:

> Package: wnpp
> Severity: wishlist
> Owner: ro...@debian.org
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name: node-shell-quote
>   Version : 1.6.1
>   Upstream Author : James Halliday <m...@substack.net> (http://substack.net)
> * URL : https://github.com/substack/node-shell-quote#readme
> * License : Expat
>   Programming Lang: JavaScript
>   Description : quote and parse shell commands
>
>  This package parses shell like argument and quotes it if needed.
>  It supports replacing environment variables by value, and shell operator
>  (redirection) by equivalent javascript syntax.
>  .
>  Node.js is an event-based server-side JavaScript engine.

I note that there are a couple of open issues that seem reasonably
serious for a package that appears to be intended for sanitising user
input before passing it on to the shell:

  https://github.com/substack/node-shell-quote/issues/31
  https://github.com/substack/node-shell-quote/issues/19

Meanwhile, the project is looking a bit dead, with no commits in the
last year.

Those bugs, if still present in the code, should be opened against the
package in our BTS, with #31 being RC IMO.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#872577: debootstrap: Handle existing /dev

[Philip Hands]

Ben Hildred <426...@gmail.com> writes:

> On Sun, Aug 20, 2017 at 3:25 AM, Ansgar Burchardt <ans...@debian.org> wrote:
>
>> Dan Nicholson writes:
>> > On Fri, Aug 18, 2017 at 2:48 PM, Henrique de Moraes Holschuh
>> > <h...@debian.org> wrote:
>> >> Wouldn't it be more straigthforward to "test -e || mknod" ?
>> >
>> > I definitely considered that, but it seemed more noisy to the code to
>> > add a conditional for every call. But I'd be fine reworking to that
>> > approach if that's more acceptable, though.
>>
>> You can always introduce a `mknod_if_not_exists` function or so.  Though
>> I'm not sure this is worth here (the name is so long the `test -e` is
>> almost shorter).
>>
>> Ansgar
>>
>>
> function mknod-e () {
> [ -e "$1" ] || mknod "$@"
> }

$1 for mknod in this case is liable to be '-m'

The attached patch might satisfy the quest for neatness.

One could instead call the function something like
ensure-exists-in-target and leave the /dev/'s on all the filenames, if
that were considered clearer.

Cheers, Phil.


signature.asc
Description: PGP signature
>From 28f460d35d8925442ce5a63c45b51d04a0db37dd Mon Sep 17 00:00:00 2001
From: Philip Hands <p...@hands.com>
Date: Sun, 20 Aug 2017 23:48:34 +0200
Subject: [PATCH] in setup_devices_simple(), only create devices that do not
 yet exist

---
 functions | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/functions b/functions
index 3cfa0d4..6c40ec7 100644
--- a/functions
+++ b/functions
@@ -1162,18 +1162,23 @@ setup_dynamic_devices () {
 }
 
 setup_devices_simple () {
+	function ensure-exists-dev() {
+		local path="$TARGET/dev/$1" ; shift
+		[ -e "$path" ] || mknod -m 666 $path "$@"
+	}
+
 	# The list of devices that can be created in a container comes from
 	# src/core/cgroup.c in the systemd source tree.
-	mknod -m 666 $TARGET/dev/null	c 1 3
-	mknod -m 666 $TARGET/dev/zero	c 1 5
-	mknod -m 666 $TARGET/dev/full	c 1 7
-	mknod -m 666 $TARGET/dev/random	c 1 8
-	mknod -m 666 $TARGET/dev/urandom	c 1 9
-	mknod -m 666 $TARGET/dev/tty	c 5 0
+	ensure-exists-dev null		c 1 3
+	ensure-exists-dev zero		c 1 5
+	ensure-exists-dev full		c 1 7
+	ensure-exists-dev random	c 1 8
+	ensure-exists-dev urandom	c 1 9
+	ensure-exists-dev tty		c 5 0
 	mkdir $TARGET/dev/pts/ $TARGET/dev/shm/
 	# Inside a container, we might not be allowed to create /dev/ptmx.
 	# If not, do the next best thing.
-	if ! mknod -m 666 $TARGET/dev/ptmx c 5 2; then
+	if ! ensure-exists-dev ptmx c 5 2; then
 		warning MKNOD "Could not create /dev/ptmx, falling back to symlink. This chroot will require /dev/pts mounted with ptmxmode=666"
 		ln -s pts/ptmx $TARGET/dev/ptmx
 	fi
-- 
2.11.0

-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY

Bug#872355: ITP: node-is-module -- Node.js code to check if a string is an ES6 module

[Philip Hands]

Julien Puydt <julien.pu...@laposte.net> writes:

> Hi,
>
> Le 16/08/2017 à 19:26, Philip Hands a écrit :
>> Julien Puydt <julien.pu...@laposte.net> writes:
>>> * URL : https://github.com/component/is-module
>> 
>> That URL is not correct.
>> 
>> Did you perhaps mean:  https://github.com/timaschew/is-module
>> 
>
> It's annoying:
>https://www.npmjs.com/package/is-module
> points to:
>https://github.com/component/is-module
> so what I packaged is what people using npm to get their javascript
> chunk actually use. But indeed, that link is a 404.
>
> The link you point to gives the same license with the same copyright,
> but it doesn't look like it's the same author, so I don't know what
> I'm supposed to do.

Sorry, I've no idea -- the link I came up with is just the result of
putting 'is-module' into github's search -- I have no information about
how that might relate to whatever was at the other link, or why it's not
there now.

I do note that timaschew's version includes a comment:

  // no idea what these regular expressions do,
  ...

  ( https://github.com/timaschew/is-module/blob/master/index.js#L2 )

which strikes me as a little worrying, given that the regular
expressions constitute pretty-much everything that this package does, so
if you can find a version of this by someone that knows what they are
doing, that might be a bonus ;-)

I guess that the way to make that better would be to get the person
responsible for the original version of the regexps to factor that bit
out into a separate library, and then rely on that in their code, at
which point you'd have a maintained version of the regexps to use, but I
can understand that that might not be the path of least resistance.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#872355: ITP: node-is-module -- Node.js code to check if a string is an ES6 module

[Philip Hands]

Julien Puydt <julien.pu...@laposte.net> writes:

> Package: wnpp
> Severity: wishlist
> Owner: Julien Puydt <julien.pu...@laposte.net>
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name: node-is-module
>   Version : 1.0.0
>   Upstream Author : Jonathan Ong <m...@jongleberry.com>
> (http://jongleberry.com)
> * URL : https://github.com/component/is-module

That URL is not correct.

Did you perhaps mean:  https://github.com/timaschew/is-module

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#872184: quilt: please make the build reproducible

[Philip Rinn]

Source: quilt
Version: 0.63-8.1
Severity: normal
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

Dear Maintainer,

While working on the "reproducible builds" effort [1], we have noticed
that 'quilt' could not be built reproducibly.

The attached patch uses 'html2text' to produce the plain text version of the
manual. As a result the plain text version does not include absolute paths
anymore. Once applied, quilt can be built reproducibly in our current
experimental framework.

Regards,

Philip

 [1]: https://wiki.debian.org/ReproducibleBuilds
diff -Nru quilt-0.63/debian/control quilt-0.63/debian/control
--- quilt-0.63/debian/control	2016-12-21 02:36:16.0 +0100
+++ quilt-0.63/debian/control	2017-08-15 00:31:38.0 +0200
@@ -4,7 +4,7 @@
 Maintainer: Martin Quinson <mquin...@debian.org>
 Uploaders: Ryan Niebur <ryanrya...@gmail.com>
 Build-Depends: debhelper (>= 9)
-Build-Depends-Indep: gettext, hevea, lynx, diffstat, perl, procmail, ed
+Build-Depends-Indep: gettext, hevea, html2text, diffstat, perl, procmail, ed
 Standards-Version: 3.9.8
 Vcs-git: git://anonscm.debian.org/collab-maint/quilt
 Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/quilt.git
diff -Nru quilt-0.63/debian/rules quilt-0.63/debian/rules
--- quilt-0.63/debian/rules	2017-07-17 20:39:58.0 +0200
+++ quilt-0.63/debian/rules	2017-08-15 00:31:28.0 +0200
@@ -26,8 +26,7 @@
 	cd doc/tmp; LC_ALL=C hevea ../main.tex ; LC_ALL=C hevea ../main.tex; LC_ALL=C hevea ../main.tex
 	perl -pe 'if (/\\sh\{.*}/) {s:\\sh\{(.*)}:$$1:}'	\
 	 < doc/tmp/main.html > doc/quilt.html
-	LC_ALL=C perl -e '$$/ = undef; $$f=<>; $$f =~ s|<A[^>]*?HREF="[^"]*#[^"]*">(.*?)|$$1|msg; print $$f;' < doc/tmp/main.html > doc/tmp/tmp.html
-	LC_ALL=C lynx doc/tmp/tmp.html -dump > doc/quilt.txt
+	LC_ALL=C html2text -style pretty -o doc/quilt.txt doc/quilt.html
 else
 	touch doc/quilt.html doc/quilt.txt
 endif


signature.asc
Description: OpenPGP digital signature

Bug#870748: coquelicot: wrong command line option for cron job

[Philip Frei]

Package: coquelicot
Version: 0.9.6-1
Severity: normal

The cron job in /etc/cron.d fails because of a wrong command line option for 
reading
the settings file. The wrong parameter is "-f" which doesn't exists.
Instead it should be "-c" to read the file.

regards,
Philip

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

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

Versions of packages coquelicot depends on:
ii  adduser   3.115
ii  init-system-helpers   1.48
ii  libjs-jquery  3.1.1-2
ii  lsb-base  9.20161125
pn  rainbows  
ii  ruby  1:2.3.3
pn  ruby-bcrypt   
pn  ruby-fast-gettext 
pn  ruby-haml 
pn  ruby-haml-magic-translations  
pn  ruby-json 
pn  ruby-lockfile 
pn  ruby-maruku   
pn  ruby-moneta   
pn  ruby-multipart-parser 
pn  ruby-net-ldap 
pn  ruby-rack 
pn  ruby-sass 
pn  ruby-sinatra  
pn  ruby-sinatra-contrib  
pn  ruby-upr  
ii  sysvinit-utils2.88dsf-59.9

Versions of packages coquelicot recommends:
pn  apache2 | nginx | pound  

coquelicot suggests no packages.

Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[Philip Hands]

Sean Whitton <spwhit...@spwhitton.name> writes:

> On Thu, Aug 03, 2017 at 05:51:27PM +0200, Philip Hands wrote:
>> P.S. Just in case this is an oversight, rather than an intentional
>> change:
>> 
>>   Shouldn't "desktop entry" and "Debian menu entry" be somehow
>>   emphasised, to make it clear that there is a reference back to the
>>   earlier definition?
>> 
>> If you meant to get rid of that, no problem.
>
> Ah, sorry, I see what you mean now.
>
> I think it makes sense to get rid of it: IME, when emphasis is used in
> defining a term, it is not repeated when the term is later used.
>
> Do I have your approval for the patch, with the plural/singular fixed?

Yes, that's fine with me.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#839172: TC decision regarding #741573 menu policy not reflected yet

[Philip Hands]

Hi Sean,

Sean Whitton <spwhit...@spwhitton.name> writes:

> control: tag -1 +patch
>
> Hello tech-ctte,
>
> On Thu, Aug 03, 2017 at 08:53:09AM +0200, Didier 'OdyX' Raboud wrote:
>> So yes, point 2 corresponds to your:
>> > - delete that paragraph
>> > - add a new paragraph saying "if there is a desktop file, there should
>> >   be no menu file"
>> [...]
>> That said, now that thanks to new forces, the process seems vivid and strong 
>> again, it does indeed make sense to reassign that to Policy. I'm hereby 
>> doing 
>> this, marking the TC as "affected". We'd still be happy to help on the 
>> wording, ideally during DebConf!
>
> Here is my proposed patch to policy.  Since the TC has made a decision,
> it doesn't make sense to seek seconds for this change, in the usual way.
> So instead I'd like to see "seconds" from at least three TC members
> confirming that this patch is sufficient to close this bug:
>
> diff --git a/policy.xml b/policy.xml
> index 3daa532..934a85b 100644
> --- a/policy.xml
> +++ b/policy.xml
> @@ -8990,14 +8990,8 @@ Reloading description 
> configuration...done.
>  receive extra contributions such as translations.
>
>
> -Packages can, to be compatible with Debian additions to some
> -window managers that do not support the FreeDesktop standard, also
> -provide a Debian menu file, following the
> -Debian menu policy, which can be found in the
> -menu-policy files in the
> -debian-policy package.  It is also available
> -from the Debian web mirrors at  -
> url="https://www.debian.org/doc/packaging-manuals/menu-policy/;>https://www.debian.org/doc/packaging-manuals/menu-policy/.
> +If a package installs a FreeDesktop desktop entries, it must
> +not also install a Debian menu entry.

You appear to have a singular/plural mismatch with:

  installs a FreeDesktop desktop entries

I guess that should instead be:

  installs FreeDesktop desktop entries

(or perhaps it should be singular throughout, I'm not sure)

Cheers, Phil.

P.S. Just in case this is an oversight, rather than an intentional
change:

  Shouldn't "desktop entry" and "Debian menu entry" be somehow
  emphasised, to make it clear that there is a reference back to the
  earlier definition?

If you meant to get rid of that, no problem.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#862051: Call for vote on allowing nodejs to provide /usr/bin/node

[Philip Hands]

Tollef Fog Heen <tfh...@debian.org> writes:

> I call for votes on the following resolution with regards to #862051.
> The voting period lasts for one week or until the outcome is no longer
> in doubt (§6.3.1).
>
> === Resolution ===
>
> The Technical Committee recognises that circumstances change in ways
> that make previous resolutions no longer appropriate.  In 2012, it was
> resolved that the nodejs package should not provide /usr/bin/node due to
> the historical conflict with the ax25-node package.  Node.js is still
> quite popular and the ax25-node package is no longer in stable, testing
> or unstable so the requirement for nodejs to not provide /usr/bin/node
> no longer applies.
>
> The Committee therefore resolves that:
>
> 1. The CTTE decision from 2012-07-12 in bug #614907 is repealed.
>
> This means Debian's normal policies and practices take over and the
> nodejs package is free to provide /usr/bin/node.  The migration should
> be managed according to Debian's usual backwards-compatibility
> arrangements.
>
> === End Resolution ===
>
> R: Approve resolution and repeal the CTTE decision from 2012-07-12.
> F: Further Discussion

I vote:   R > F

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#868869: debian-installer should not recommend to change password periodically (and more)

[Philip Hands]

Philipp Kern <pk...@debian.org> writes:

> On 07/24/2017 12:38 PM, Hideki Yamane wrote:
>>  But it also makes administrator to remember it harder as its trade-off...
>>  (and they maybe choose easy password as a result). It's a not good idea
>>  to suggests to change root password periodically, IMO. It's not a best
>>  practice.
>
> I'd say it's one of two things: If it's easy, make sure to change it
> periodically. If it's hard enough to withstand brute-force, you don't
> need to.
>
> As I said: I'm totally with you that in a standard setup it'd great for
> that not to be necessary. Unfortunately the standard setup does not ship
> with the mitigating controls.

I was under the impression that there was quite a lot of evidence to
demonstrate that regular-change policies are a security disaster.

Continuing to recommend such an approach strikes me as pure inertia.

If we want to recommend that people change their passwords later if they
are incapable of choosing a good one immediately, that seems like good
advice, but advising regular changes is just encouraging people to
consume their often quite limited ability to remember decent passwords,
with the almost inevitable result being that they'll either start
choosing poor passwords, or recording them somewhere insecure, neither
of which are better than keeping a decent password that they can
remember.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#865929: Advice on dealing with GRUB upgrade failure caused by init-select

[Philip Hands]

Hi Colin,

Just in case it's not already clear from the replies you have received
so far, there is a consensus amongst the members of the TC that you
should do as you suggest -- this was reflected in our recent meeting:

  
http://meetbot.debian.net/debian-ctte/2017/debian-ctte.2017-07-19-18.59.log.html#l-36

That being the case, I think you should just get on with fixing it,
rather than awaiting a resolution from us.  (of course if other TC
members have some objection to this suggestion, please say so).

I see no reason for you to waiting for the outcome of a discussion
about whether we need to change policy, or give you an exception to
policy, or simply say that there's nothing going on in violation of
policy.

Also, if you were to come across any additional wrinkles in the course
of fixing this, you can mention them so that we can make sure that
whatever we resolve ensures that you are able to do whatever is needed
(or perhaps suggest alternative approaches).

BTW I'd like to thank you for the clarity with which you laid out the
problem for us -- I'm sure the rest of the TC appreciate that too.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#868791: subtitleeditor: Still getting gtkmm errors in subtitleeditor

[Philip Rinn]

On 19.07.2017 at 14:24, shirish शिरीष wrote:
> at bottom :-
> 
> On 19/07/2017, Philip Rinn <ri...@inventati.org> wrote:
>> Control: retitle -1 Missing call to gtk_widget_get_preferred_width/height()
>>
>> Please don't send private mail, answer to the bug report!
>> I quoted your mail for reference...
> 
> Sorry, that probably was a mistake, thank you.
> 
>>
>> On 19.07.2017 at 03:27, shirish शिरीष wrote:
>>> Thank you Philip,
>>>
>>> The reason I raised the bug (and forgot to mention) is the fact it
>>> makes the package unusable. There were a bunch of subtitles which I
>>
>> How? I work with subtitleeditor on a regular basis and see those warnings in
>> the
>> console as well but they don't draw subtitleeditor unusable.
>>
> 
> The simplest example is
> 
> a. take a subtitle file
> b. use CTRL+A to select all subtitles.
> c. Move subtitles a minute forward or backward so the all the
> subtitles start either earlier or later.
> d. Try to save the file.
> 
> Saving the file doesn't work. Either doing CTRL + S or doing File >
> Save doesn't make any change. Even on the console, the time-stamp of
> the file doesn't change. I did get some gstreamer upgrades which
> migrated from sid to testing/buster although that shouldn't affect the
> outcome.

Works for me.

If you still see this problem please open a new bug report as this is *not*
related to the gtk warnings you reported earlier.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#868791: subtitleeditor: Still getting gtkmm errors in subtitleeditor

[Philip Rinn]

Control: retitle -1 Missing call to gtk_widget_get_preferred_width/height()

Please don't send private mail, answer to the bug report!
I quoted your mail for reference...

On 19.07.2017 at 03:27, shirish शिरीष wrote:
> Thank you Philip,
>
> The reason I raised the bug (and forgot to mention) is the fact it
> makes the package unusable. There were a bunch of subtitles which I

How? I work with subtitleeditor on a regular basis and see those warnings in the
console as well but they don't draw subtitleeditor unusable.

> was trying to change timings, frame rate etc. but was unable to do so
> because of the above errors/warnings. I had to later resort to using
> subtitlecomposer to do the same changes  ,
>

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#868791: subtitleeditor: Still getting gtkmm errors in subtitleeditor

[Philip Rinn]

Control: reassign -1 gtkmm3.0

On 18.07.2017 at 19:02, shirish शिरीष wrote:

> Still getting the following gtkmm errors with the new subtitleeditor,

those are no *errors* but *warnings* - that's a huge difference!

Those gtk warnings occur since GTK+ >= 3.20 and seem to be harmless, anyway I
forwarded the bug accordingly. (Not sure if gtkmm3.0 or gtk+3.0 is correct.)

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#862051: Refer #862051 to ctte

[Philip Hands]

Ian Jackson <ijack...@chiark.greenend.org.uk> writes:

> Anthony DeRobertis writes ("Re: Bug#862051: Refer #862051 to ctte"):
>> On 07/14/2017 12:57 PM, Tollef Fog Heen wrote:
>> > Fair point.
>> >
>> >3. Once a new nodejs package providing /usr/bin/node is in the
>> >   archive, other packages in the archive are free to depend on the
>> >   nodejs package and use /usr/bin/node .
>> 
>> That should probably be a versioned Depends, at least until a stable 
>> release includes /usr/bin/node in nodejs. Otherwise upgrades may break.
>> 
>> OTOH, is this paragraph (or 2, for that matter) really needed? They're 
>> just restating (somewhat imperfectly) Policy and/or normal practice in 
>> Debian, which presumably come back into effect anyway once the 
>> 2012-07-12 decision is repealed.
>
> It would be better to simply say "following Debian's existing backward
> compatibility practices" or something, than trying to restate it all.

Quite -- I think we just need to have clause 1 in the resolution itself.

We could have some suggestions as additional notes to describe the
consequences of the revocation.

Like mentioning that where a versioned depends on nodejs is deemed
necessary, the Depends: should probably also allow nodejs-legacy as an
alternative option, since that also provides /usr/bin/node.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#861377: gimagereader: unhandled exception

[Philip Rinn]

Hi Janusz,

could you please follow upstreams instruction to get a meaningful backtrace?

> Looks like something went wrong in gtkspell territory. Ask your reporter to 
> run the application inside gdb as follows
> 
> G_DEBUG=fatal-criticals gdb gimagereader-gtk
> [... wait for program to abort ...]
> bt
> 
> Ideally he should have gimagereader and gtkspell3 debug symbols installed.

I you have trouble, please check this page: 
https://wiki.debian.org/HowToGetABacktrace

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#867552: corebird: Corebird trap after succesful authorization

[Philip Rinn]

Hi Daniel,

could you also check this (copied from upstram bug tracker):

Another issue could be that the org.baedert.corebird.gschemas.xml file exists 
both
in /usr/share/glib-2.0/schemas and /usr/local/share/glib-2.0/schemas, but the 
one
in /usr/local/ is old and does not contain that settings key.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#861377: gimagereader: unhandled exception

[Philip Rinn]

Control: forwarded -1 https://github.com/manisandro/gImageReader/issues/182
Control: tags -1 upstream


Hi Janusz,

I couldn't reproduce your bug. Does gimagereader work for you at all or is it 
just
crashing? I forwarded the bug upstream, hope they can help.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#868439: ITP: node-url-parse-lax -- Lax url.parse() with support for protocol-less URLs & IPs

[Philip Hands]

icyf...@disroot.org writes:

> Package: wnpp
> Severity: wishlist
> Owner: Rajeev R Menon <icyf...@disroot.org>
> X-Debbugs-CC: debian-de...@lists.debian.org
>
> * Package name : node-url-parse-lax
>   Version : 1.0.0
>   Upstream Author : Sindre Sorhus <sindresor...@gmail.com> (sindresorhus.com)
> * URL : https://github.com/sindresorhus/url-parse-lax#readme
> * License : Expat
>   Programming Lang: JavaScript
>   Description : Lax url.parse() with support for protocol-less URLs & IPs
>
>  url.parse() with support for protocol-less URLs & IPs
>  Lax url.parse() with support for protocol-less URLs & IPs

You appear to have taken the (duplicated) github project descriptions,
and pasted them here, without noticing that this results in three copies
of the same sentence ending up here.

Also, it's not really appropriate to have the usage for the function in
a package description.  I realise that it's often quite hard to come up
with meaningful descriptions for these very short functions, but please
do try.

If you imagine writing a description for someone that has not actually
used node.js that might help, and makes sure that the description
conforms to the last line of 3.4.2 from policy:

  https://www.debian.org/doc/debian-policy/ch-binary.html#s-descriptions

> It is a dependency of npm.
>
> Pirate Praveen has agreed to sponsor this package. I am 
> interested to join the Debian Javascript Maintainers team.

Well done for including this bit, as it helps outsiders keep track of
what's going on.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#868136: corebird: segfault

[Philip Rinn]

Control: forwarded -1 https://github.com/baedert/corebird/issues/750
Control: tags -1 upstream fixed-upstream

Hi Edward,

this bug should be fixed in version 1.5.1 - I hope I'll upload it today (waiting
for a reply in another bug report).

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#867552: corebird: Corebird trap after succesful authorization

[Philip Rinn]

Control: forwarded -1 https://github.com/baedert/corebird/issues/749
Control: tags -1 upstream

Hi Daniel,

I forwarded the bug upstream and got the hint so try to recompile the schemas 
with

glib-compile-schemas

Could you try if it helps? I can't do it myself as I can't reproduce the bug.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#866745: doxygen: Relocation error in doxygen while building gstreamermm-1.0 on armel

[Philip Rinn]

Source: doxygen
Severity: important

Hi,

while building gstreamermm-1.0 on armel doxygen crashes with:

> /usr/bin/doxygen: relocation error: /usr/lib/arm-linux-
gnueabi/libLLVM-3.9.so.1: symbol _ZTINSt13__future_base12_Result_baseE, version
GLIBCXX_3.4.15 not defined in file libstdc++.so.6 with link time reference

see
https://buildd.debian.org/status/fetch.php?pkg=gstreamermm-1.0=armel=1.8.0%2Bdfsg-2=1498907351=0

This makes the whole build fail. It build fine on oher archs.

Best,
Philip



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

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

Bug#866541: pidgin-lastfm: writes " - SongName" to status instead of "Artist - SongName"

[Philip Blagoveschensky]

Package: pidgin-lastfm
Version: 0.4a-2
Severity: important
Tags: patch upstream

Dear Maintainer,

the plugin in question malfunctions because lastfm slightly changed
formatting of their xml responses. It can't figured out the song's artist
anymore.

How to reproduce: enable plugin, set some lastfm username in settings,
e.g. cocacooler,
write %s in your status. See that it will replace it with something like
" - SongName".

patch is attached

In my case the plugin makes the following request:
https://ws.audioscrobbler.com/2.0/?method=user.getRecentTracks=cocacooler_key=4b9aa27d34af5238708afa6807e6a18a

lastfm responds with this (lines after the first 3 are omitted):


Kotobuki
Minako
Dear My Keys ~Kenban no Mahou~ (Instrumental)

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

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

Versions of packages pidgin-lastfm depends on:
ii  perl5.24.1-3
ii  pidgin  2.12.0-1

pidgin-lastfm recommends no packages.

pidgin-lastfm suggests no packages.

-- no debconf information
--- usr/lib/pidgin/lastfm.pl2009-03-23 22:42:11.0 +0300
+++ /usr/lib/pidgin/lastfm.pl   2017-06-30 02:53:00.724214434 +0300
@@ -314,17 +314,17 @@
foreach (@lines) {
 my $line = $_;
  
-if ($line =~ /^\s*(.*?)<\/artist>$/) {
+if ($line =~ /(.*?)<\/artist>/) {
  $artist = $1;
-} elsif ($line =~ /^\s*(.*?)<\/name>$/) {
+} elsif ($line =~ /(.*?)<\/name>/) {
  $title = $1;
-} elsif ($line =~ /^\s*$/) {
+if ($line =~ /<\/track>/) {
  last;
 }
}

Bug#854534: subtitleeditor: running subtitleeditor gives this "** (subtitleeditor:28740): CRITICAL **: bool Config::get_value_bool(const Glib::ustring&, const Glib::ustring&): assertion 'state' failed

[Philip Rinn]

Control: tags -1 fixed-upstream

Hi,

after digging in upstream changelog a bit it turned out it's already fixed 
upstream.

Best,
Philip





signature.asc
Description: OpenPGP digital signature

Bug#865647: php-horde-ingo: XSS vulnerability in rule search

[Philip Frei]

Package: php-horde-ingo
Version: 3.2.13-1
Severity: normal
Tags: security

Dear maintainer,

thanks for your efforts to update all Horde packages for stretch.

There's one open security problem left. Fix can be found at
https://github.com/horde/horde/commit/6854284a647f360f358b4739e4df65a9cd814664

kind regards,
Philip

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

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

Versions of packages php-horde-ingo depends on:
ii  php-common 1:49
pn  php-horde  
pn  php-horde-auth 
pn  php-horde-autoloader   
pn  php-horde-core 
pn  php-horde-exception
pn  php-horde-form 
pn  php-horde-group
pn  php-horde-imap-client  
pn  php-horde-mime 
pn  php-horde-perms
pn  php-horde-share
pn  php-horde-util 
pn  php-horde-view 
ii  php7.0-cli [php-cli]   7.0.19-1

Versions of packages php-horde-ingo recommends:
pn  php-horde-vfs   
pn  php-net-sieve   
pn  php-net-socket  

php-horde-ingo suggests no packages.

Bug#830175: rawtherapee: System freezes during saving/processing

[Philip Rinn]

Hi Matthias,

On 23.06.2017 at 07:34, Matthias Kaehlcke wrote:
> Unfortunately I still encounter the issue occasionally with a 5.0ish
> version: 5.0.r1~git.20170511.502.abd11da0-1

This is not a version from the Debian repository, where did you get it from?
Please only use versions from the Debian repository or report your bugs 
upstream.

> I often have 2-3 instances of RT open, is most of the memory released
> again after doing the processing or does RT keep it around until it is
> closed, which might contribute to the issue?

For me it still looks like a problem of running out of memory and not a problem 
of
rawthereapee. You wrote before that the high CPU load you saw was not caused by
any app, from what I understand this is a sign of swapping activity:

On 11.12.2016 at 03:54, Matthias Kaehlcke wrote:
> I just reproduced it with v4.2.1395 :( After insisting for a long time I
> could switch to a VT and saw that the CPU load was at 50. At this
> point the load was already going down again and top didn't show any
> app to be particularly busy.

I think we have to move it to the upstream bug tracker. Are you willing to help
upstream to debug this problem? You'd need a github account though.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#854534: subtitleeditor: running subtitleeditor gives this "** (subtitleeditor:28740): CRITICAL **: bool Config::get_value_bool(const Glib::ustring&, const Glib::ustring&): assertion 'state' failed

[Philip Rinn]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/kitone/subtitleeditor/issues/2

Hi,

thanks for reporting.

I filed this bug upstream now (it took some time as upstream had to move its
repository to a new host).

Hope this will be fixed soon.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#865485: Voting for TC Chair

[Philip Hands]

Didier 'OdyX' Raboud <o...@debian.org> writes:

> Package: tech-ctte
> Severity: normal
>
> Dear TC members,
>
> With the appointment of Niko to the TC and according to our current 
> procedures¹, I am hereby announcing my immediate vacation of the chair 
> position, triggering a new election. For clarity of the process, I am 
> interested to continue serving as chair.
>
> The ballot is the following:
>
> ===BEGIN===
>
> The chair of the Debian Technical Committee will be:
>
> A: Keith Packard 
> B: Didier Raboud 
> C: Tollef Fog Heen 
> D: Sam Hartman 
> E: Phil Hands 
> F: Margarita Manterola 
> G: David Bremner 
> H: Niko Tyni 
> ===END===

I vote:

  B > F > A = C = D = E = G > H

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#830175: rawtherapee: System freezes during saving/processing

[Philip Rinn]

Hi Matthias,

did you find time testing with rawtherape 5.0 or 5.1?
Would be good to know if it still occurs as much changed with 5.0 concerning
memory management.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#853670: subtitleeditor: ftbfs with GCC-7

[Philip Rinn]

reassign 853670 gstreamermm-1.0
merge 853670 853435
thanks

Reading the build log it's gstreamermm thatcauses the ftbfs.

Best,
Philip



signature.asc
Description: OpenPGP digital signature

Bug#853435: gstreamermm-1.0: ftbfs with GCC-7

[Philip Rinn]

Control: tags -1 upstream fixed-uptream

Hi,

there is already a patch from upstream:
https://bugzilla.gnome.org/show_bug.cgi?id=783678

I'll test it and upload a fixed version soon.

Best,
Philip






signature.asc
Description: OpenPGP digital signature

Bug#853435: gstreamermm-1.0: ftbfs with GCC-7

[Philip Rinn]

Hi Matthias,

sorry for the noise, it's in gstreamermm, didn't read the log carefully...

Best,
Philip




signature.asc
Description: OpenPGP digital signature

Bug#853435: gstreamermm-1.0: ftbfs with GCC-7

[Philip Rinn]

Hi Matthias,

I think this bug is actually in glibmm, see

https://bugzilla.redhat.com/show_bug.cgi?id=1438766

Upstream is working on it:

https://mail.gnome.org/archives/gtkmm-list/2017-April/msg6.html

Can you confirm this?

Best,

Philip



signature.asc
Description: OpenPGP digital signature

Bug#836127: Call for Votes for new TC member

[Philip Hands]

Didier 'OdyX' Raboud <o...@debian.org> writes:

> I call for votes on the following ballot to fill a vacant seat in the TC. The 
> voting period starts immediately and lasts for up to one week, or until the 
> outcome is no longer in doubt (§6.3.1).
>
> ===BEGIN
> The Technical Committee recommends that Niko Tyni <nt...@debian.org> be
> appointed by the Debian Project Leader to the Technical Committee.
>
> N: Recommend to Appoint Niko Tyni <nt...@debian.org>
> F: Further Discussion
> ===END

I vote:

  N > F

-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#864181: Fwd: Bug#864181: os-prober: dmraid detection not functional.

[Philip Hands]

Mike Mestnik <che...@mikemestnik.net> writes:

> In that case the proposed patch is wrong, dmraid is run every time the
> file exists.  Not only is the conditional in test wrong, but the file
> is created when it should be being removed.

You appear to be reading the || after the -f test as &&

To render those lines into english, one would have:

  Either the file exists OR
 we create it now

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature