date:20170101

Raphael Hertzog  writes:
> On Sat, 31 Dec 2016, Russ Allbery wrote:

>> These all look good to me.  Seconded (and quoted below for the
>> convenience of others who may want to review and second).

> Seconded.

And now applied for the next release.

-- 
Russ Allbery (r...@debian.org)

Bug#848826: More info. on vainfo

2017-01-01 Thread shirish शिरीष

at bottom :-

On 02/01/2017, Sebastian Ramacher  wrote:
> Hi
>
> On 2016-12-25 04:41:43, shirish शिरीष wrote:
>> in-line  :-
>>
>> On 24/12/2016, Sebastian Ramacher  wrote:
>> > Hi
>>
>> Hi,
>>
>> > On 2016-12-23 15:43:10, shirish शिरीष wrote:
>>
>> 
>>
>> >> (+) Video --vid=1 (*) (h264)
>> >>  (+) Audio --aid=1 --alang=und (*) (aac)
>> >> [vo/opengl] GLX not found.
>> >> [vo/opengl] GLX not found.
>> >
>> > I suppose your issues start here already. Please provide a X.org log
>> > and
>> > dmesg.
>> >
>> > Cheers
>>
>> Warning - Longish mail (a bit)
>>
>> Have provided Xorg.0.log from /var/log/X.org.0.log
>>
>> While I'm able to figure out and troubleshoot some parts and able to
>> play the videos without the warnings. What had happened was -
>>
>> a. For some reason nvidia-* packages had occupied center-stage along
>> with Intel. It took me sometime to realize that maybe because some
>> laptops which are available today are 'hybrid' laptops which have both
>> intel and nvidia graphics hence nvidia which usually had a
>> breaks/replaces against intel was not there.
>>
>> How it came to be, I'm clueless still.
>>
>> b. I removed all instances of any nvidia package except for
>> nvidia-installer-cleanup which depends on glx-diversions.
>>
>> c. Then rebooted the system and found it was flashing the monitor.
>>
>> d. Then rebooted into single user mode, found out mesa-vdpau-drivers
>> was not installed, As I was in single-user-mode/recovery-mode had to
>> take a usb disk, download mesa-vdpau-drivers, copied it to this
>> machine and installed it via dpkg.
>>
>> e. Rebooted again and this time got the login page, saw couple of
>> videos, the complain was no longer in the videos.
>
> And vainfo no also reports that the intel driver is used?



yup on the thinkpad machines, it now does -

> vainfo
>[99%]
libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: Intel i965 driver for Intel(R) Haswell Mobile - 1.7.3
vainfo: Supported profile and entrypoints
  VAProfileMPEG2Simple: VAEntrypointVLD
  VAProfileMPEG2Simple: VAEntrypointEncSlice
  VAProfileMPEG2Main  : VAEntrypointVLD
  VAProfileMPEG2Main  : VAEntrypointEncSlice
  VAProfileH264ConstrainedBaseline: VAEntrypointVLD
  VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice
  VAProfileH264Main   : VAEntrypointVLD
  VAProfileH264Main   : VAEntrypointEncSlice
  VAProfileH264High   : VAEntrypointVLD
  VAProfileH264High   : VAEntrypointEncSlice
  VAProfileH264MultiviewHigh  : VAEntrypointVLD
  VAProfileH264MultiviewHigh  : VAEntrypointEncSlice
  VAProfileH264StereoHigh : VAEntrypointVLD
  VAProfileH264StereoHigh : VAEntrypointEncSlice
  VAProfileVC1Simple  : VAEntrypointVLD
  VAProfileVC1Main: VAEntrypointVLD
  VAProfileVC1Advanced: VAEntrypointVLD
  VAProfileNone   : VAEntrypointVideoProc
  VAProfileJPEGBaseline   : VAEntrypointVLD


Couple of older desktop machines having Wolfdale (Core2Duo)  and Intel
G33 chipsets still show the following -

─[$] vainfo

libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/i915_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

Double-checked for any nvidia bits but didn't find any. Maybe I should
file a separate bug report for the desktop machines ? Please let me
know what I should do ?

>
> --
> Sebastian Ramacher
>

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#819660: explicitly allow building automatic debug symbols packages not listed in control

Raphael Hertzog  writes:
> On Sat, 31 Dec 2016, Russ Allbery wrote:

>> >>The first paragraph of the control file contains information about the
>> >>source package in general. The subsequent sets each describe a binary
>> >>package that the source tree builds. All the binary packages have a
>> >>corresponding paragraph, except for the possible automatic debug
>> >>packages that do not require one.
>> 
>> > There may be better ways to phrase this, but I think there is still a
>> > need for some clarification about this.
>> 
>> Seems reasonable to me.  Seconded.

> Seconded.

I massaged the wording a bit.  Here's what I committed for the next
release:

--- a/policy.sgml
+++ b/policy.sgml
@@ -2680,9 +2680,12 @@ Package: libc6

 

- The first paragraph of the control file contains information about
- the source package in general. The subsequent sets each describe a
- binary package that the source tree builds.
+ The first paragraph of the control file contains information
+ about the source package in general.  The subsequent paragraphs
+ each describe a binary package that the source tree builds.
+ Each binary package built from this source package has a
+ corresponding paragraph, except for any automatically-generated
+ debug packages that do not require one.

 


-- 
Russ Allbery (r...@debian.org)

Bug#849912: preseed: xgettext fails on PO template (non-ASCII entry without explicit encoding set)

2017-01-01 Thread Niels Thykier

Package: preseed
Version: 1.76
Severity: normal

Hi,

Noticed this issue in the lintian archive wide processing (runs stable
w. -backports):

"""
N: Processing source package preseed (version 1.76, arch source) ...
[...]
ERROR: xgettext failed to generate PO template file because there is non-ASCII
   string marked for translation. Please make sure that all strings marked
   for translation are in uniform encoding (say UTF-8), then 
ESC[1m*prepend*ESC[0m the
   following line to POTFILES.in and rerun intltool-update:

   [encoding: UTF-8]

command failed with error code 1 at 
/srv/lintian.debian.org/lintian/checks/po-debconf.pm line 192.
internal error: cannot run po-debconf check on package source:preseed/1.76
warning: skipping check of source:preseed/1.76
"""

Note due to this error, the lintian report for preseed is currently
incomplete.

Thanks,
~Niels

Bug#823348: Limit the strongest dependencies on supplemental -doc packages

Raphael Hertzog  writes:
> On Sat, 31 Dec 2016, Russ Allbery wrote:
>> Looks reasonable to me.  Seconded.

> Seconded.

Thanks!  IIRC, Josh isn't (yet) a DD, so this needs one more second.

> diff --git a/policy.sgml b/policy.sgml
> index 404dc73..421e0d1 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -10699,6 +10699,18 @@ END-INFO-DIR-ENTRY
>   
>  
>   
> +   If package is a build tool, development tool,
> +   command-line tool, or library development package,
> +   package (or package-dev in the case of a
> +   library development package) already provides documentation in
> +   man, info, or plain text format, and package-doc
> +   provides HTML or other formats, package should declare
> +   at most a Suggests on package-doc. Otherwise,
> +   package should declare at most a Recommends on
> +   package-doc.
> + 
> +
> + 
> Additional documentation included in the package should be
> installed under /usr/share/doc/package.
> If the documentation is packaged separately,

-- 
Russ Allbery (r...@debian.org)

Bug#849804: /etc/init.d/asterisk debug unusable for continous output

2017-01-01 Thread Joerg Dorchain

On Sun, Jan 01, 2017 at 09:41:57PM +0100, Bernhard Schmidt wrote:
> 
> I think this could fix it.
> 
> https://issues.asterisk.org/jira/browse/ASTERISK-26630
> https://gerrit.asterisk.org/#/c/4516/
> 
> It is already in the upstream Asterisk 13 branch, but not in any 13.x
> release. But I'm sure this will be sooner than later.

You probably know better, I found the patch in the pipe for 14.x
release. Anyway, it will come, and in a way that I can use it
even before switching from chan_sip to chan_pjproject :-)

> 
> If you change pjproject.conf to read
> 
> [log_mappings]
> asterisk_debug = "3,4,5,6"
> 
> does that help?

No. I would not expect so, as /etc/init.d/asterisk debug starts
asterisk with debug level output.

Bye,

Joerg

signature.asc
Description: PGP signature

Bug#829367: Please add virtual-mysql-* packages to the official list of virtual packages

Raphael Hertzog  writes:
> On Sat, 31 Dec 2016, Russ Allbery wrote:

>>> The list and descriptions:
>> 
>>> virtual-mysql-client - A MySQL database compatible client package
>>> virtual-mysql-client-core- A MySQL database compatible client core 
>>> package
>>> virtual-mysql-server - A MySQL database compatible server package
>>> virtual-mysql-server-core- A MySQL database compatible server core 
>>> package
>>> virtual-mysql-testsuite  - A MySQL database compatible test suite 
>>> package

>> I second adding these virtual packages (so we need another second to apply
>> them to Policy).

> Seconded.

Thanks, this has been applied for the next release.

-- 
Russ Allbery (r...@debian.org)

Bug#264589: Link from packages.debian.org to manpages.debian.net - updated information (bug 264589)

2017-01-01 Thread Paul Wise

On Tue, 2014-03-04 at 12:08 +0800, Paul Wise wrote:

> Attached an update to support the new per-language redirects on
> manpages.d.o and the filesystem paths for translated manpages.

Attached an update to git master and https URLs.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
From 50f9f03737859545d7fdfba5cfe16edc8c2a10f8 Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Thu, 27 Dec 2012 15:48:15 +0800
Subject: [PATCH] Link to manual pages (Closes: #264589)

---
 lib/Packages/DoShow.pm   | 26 ++
 templates/html/filelist.tmpl | 12 +++-
 templates/html/show.tmpl | 24 
 3 files changed, 61 insertions(+), 1 deletion(-)

diff --git a/lib/Packages/DoShow.pm b/lib/Packages/DoShow.pm
index e0f05ff..12a40da 100644
--- a/lib/Packages/DoShow.pm
+++ b/lib/Packages/DoShow.pm
@@ -241,6 +241,12 @@ sub do_show {
 			$contents{downloads} = \@downloads;
 
 			#
+			# File contents on amd64
+			#
+			$contents{contents} = [];
+			pkg_files('amd64', $suite, $pkg, $contents{contents});
+
+			#
 			# more information
 			#
 			moreinfo( name => $pkg, data => $page, vars => \%contents,
@@ -526,6 +532,26 @@ sub pkg_list {
 }
 }
 
+sub pkg_files {
+my ( $arch, $suite, $pkg, $list ) = @_;
+if (tie my %contents_data, 'DB_File', "$DBDIR/contents/filelists_${suite}_${arch}.db",
+O_RDONLY, 0666, $DB_BTREE) {
+
+unless (exists $contents_data{$pkg}) {
+		return ;
+} else {
+my @files = unpack "L/(CC/a)", $contents_data{$pkg};
+my $file = '';
+
+for (my $i=0; $i' IF loop.first -%]
+[%- IF manurl -%]
+[% file %]
+[% ELSE -%]
 [% file %]
+[% END -%]
 [% '' IF loop.last -%]
 [% END %]
 
diff --git a/templates/html/show.tmpl b/templates/html/show.tmpl
index 31cfce8..37616dc 100644
--- a/templates/html/show.tmpl
+++ b/templates/html/show.tmpl
@@ -235,6 +235,30 @@
  
 [% END %]
 
+[%- manfirst = 1 -%]
+[% FOREACH content IN contents;
+  manurl = '';
+  mansection = '';
+  manname = '';
+  IF (matches = content.match('^/usr/share/man/man(\d+)/([^\.]+)'));
+manurl = 'https://manpages.debian.org/man/' _ uri_escape(suite) _ '/' _ uri_escape(matches.0) _ '/' _ uri_escape(matches.1);
+mansection = matches.0;
+manname = matches.1;
+  ELSIF (matches = file.match('^/usr/share/man/([^\.]+)/man(\d+)/([^\.]+)'));
+manurl = 'https://manpages.debian.org/man/' _ uri_escape(suite) _ '/' _ uri_escape(matches.0) _ '/' _ uri_escape(matches.1) _ '/' _ uri_escape(matches.2);
+mansection = matches.1;
+manname = matches.2;
+  END -%]
+	[%- IF manurl -%]
+	[%- IF manfirst -%]
+	[%- manfirst = 0 -%]
+	[% g('Documentation:') %]
+	[%- END -%]
+	[% g('%s', manurl, manname, manname _ '(' _ mansection _ ')' ) %]
+	[%- END -%]
+[%- END -%]
+
+
 [% FOREACH b IN binaries %]
   [% IF loop.first %][% g('The following binary packages are built from this source package:') %][% END %]
 [% IF b.available %][% b.name %][% ELSE; b.name; END %]
-- 
2.11.0



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

Bug#849910: RM: gmt-tutorial -- ROM; RC buggy, obsoleted by gmt-doc

2017-01-01 Thread Bas Couwenberg

Package: ftp.debian.org
Severity: normal

Please remove the gmt-tutorial package from the archive.

It is unmaintained, RC buggy, and obsoleted by gmt-doc.

Kind Regards,

Bas

Bug#849911: RM: mongodb-clients [armhf] -- ANAIS; FTBFS and unsupported upstream

2017-01-01 Thread Apollon Oikonomopoulos

Package: ftp.debian.org
Severity: normal

Dear FTP Masters,

On the same account as in #848276, could you please remove 
mongodb-clients on armhf from unstable?

Regards and best wishes for a Happy New Year,
Apollon

Bug#601455: Standardize how to disable an init script

Andreas Henriksson  writes:

> The underlying issue for this bug report is similar to what's recently
> been discussed in #522163 - the /etc/default/ ENABLED anti-pattern.

> In #522163 it seemed the conclusion included that documenting that
> something is an anti-pattern in policy itself was not desirable. I thus
> think that much of any potential solution to #601455 is also likely not
> desirable to have in policy.

> Possibly these to bug reports should just be merged (and wontfix tagged
> together).

We should be coming up with a documented way of disabling a service and
put that in Policy, and provide a recommendation for people to use that
instead of all the other mechanisms that currently exist but don't play
well with various things.  That would include recommending *against* the
ENABLED anti-pattern.  That's why I've been keeping this bugs open and
around, not wontfix.

This is mostly just documenting update-rc.d disable in Policy, except that
we need to document how to keep a service from ever being enabled and
started by installation of a package by doing something to the system
*before* the package is installed.  This is very important for, say, build
environments and other bootstrapping environments.  (And we have a
mechanism now for this, namely policy.d; it's just not documented in
Policy.)

-- 
Russ Allbery (r...@debian.org)

Bug#849909: openvpn: Openvpn 2.4 sees all client certificates as expired if i use crl-verify

2017-01-01 Thread Kertesz Laszlo

Package: openvpn
Version: 2.4.0-3
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***
Since version 2.4 appeared in Testing clients cannot connect to my openvpn 
servers 
(i have 2 running on my desktop). 
They are working fine if i downgrade to 2.3.11, but 2.4 versions seem to treat 
all certificates as expired if crl-verify is enabled. 
I checked all certificates and are valid until 2021-2026.

Commenting out the crl-verify line from the server config will make it work, but
i have revoked certificates and without this option those certificates will be 
allowed to connect. 

Excerpt from server log (removed IP addresses and other personal info):

Mon Jan  2 07:37:10 2017 us=426660 1.2.3.4:36241 TLS: Initial packet from 
[AF_INET]1.2.3.4:36241, sid=66129e86 1e790a7e
Mon Jan  2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR: depth=0, 
error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn, 
emailAddress=my@email
Mon Jan  2 07:37:10 2017 us=466182 1.2.3.4:36241 OpenSSL: error:14089086:SSL 
routines:ssl3_get_client_certificate:certificate verify failed
Mon Jan  2 07:37:10 2017 us=466201 1.2.3.4:36241 TLS_ERROR: BIO read 
tls_read_plaintext error
Mon Jan  2 07:37:10 2017 us=466215 1.2.3.4:36241 TLS Error: TLS object -> 
incoming plaintext read error
Mon Jan  2 07:37:10 2017 us=466228 1.2.3.4:36241 TLS Error: TLS handshake failed
Mon Jan  2 07:37:10 2017 us=466290 1.2.3.4:36241 SIGUSR1[soft,tls-error] 
received, client-instance restarting


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

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

Versions of packages openvpn depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  init-system-helpers1.46
ii  iproute2   4.9.0-1
ii  libc6  2.24-8
ii  liblz4-1   0.0~r131-2
ii  liblzo2-2  2.08-1.2
ii  libpam0g   1.1.8-3.4
ii  libpkcs11-helper1  1.11-6
ii  libssl1.0.21.0.2j-4
ii  libsystemd0232-8
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.0c-2
pn  resolvconf  

-- debconf information:
  openvpn/create_tun: false

Bug#849908: Portuguese translation not packaged

2017-01-01 Thread Carlos Maddela

Package: debdelta
Version: 0.56
Severity: wishlist

Dear Andrea,

I think the Portuguese MO file has never been packaged even in version
0.54 when it was supposed to have been fixed. I tried reopening Bug
#760731, but I got an error from BTS, so I've filed this new bug instead.

Thanks,

Carlos

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

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

Versions of packages debdelta depends on:
ii  binutils2.27.90.20161231-1
ii  bzip2   1.0.6-8
ii  libbz2-1.0  1.0.6-8
ii  libc6   2.24-8
ii  python  2.7.13-1
ii  zlib1g  1:1.2.8.dfsg-4

Versions of packages debdelta recommends:
ii  bsdiff   4.3-19
ii  gnupg-agent  2.1.17-2
ii  gnupg2   2.1.17-2
ii  lzma 9.22-2
ii  python-apt   1.1.0~beta5
ii  python-debian0.1.29
ii  xdelta   1.1.3-9.1
ii  xdelta3  3.0.11-dfsg-1
ii  xz-utils [lzma]  5.2.2-1.3

Versions of packages debdelta suggests:
ii  debdelta-doc  0.56

-- no debconf information

Bug#849907: raw nroff .TP sitting on the man page

Package: tree
Version: 1.7.0-4
Severity: minor
File: /usr/share/man/man1/tree.1.gz

   -I pattern
  Do not list those files that match the wild-card pattern.

.TP --ignore-case If a match pattern is specified  by  the  -P  or  -I
   option,  this  will  cause  the pattern to match without regards to the
   case of each letter.

   --matchdirs

Bug#846950: It is not only RPCSVCGSSDOPTS but also RPCGSSDOPTS that is not correctly propagated

2017-01-01 Thread Joachim Falk

Dear all,

both RPCSVCGSSDOPTS and RPCGSSDOPTS from /etc/default/nfs-common are not 
correctly propagated
into /run/sysconfig/nfs-utils by /usr/lib/systemd/scripts/nfs-utils_env.sh.

I have attached a patch for nfs-utils_env.sh. Note that
RPCSVCGSSDOPTS must be propagated to SVCGSSDARGS and
not to RPCSVCGSSDARGS. Simply look into /lib/systemd/system/rpc-svcgssd.service
where SVCGSSDARGS is used as argument for rpc.svcgssd.

Moreover, this still dos not allow one to override the keytab setting as 
/etc/krb5.keytab
is hardcoded in multiple ConditionPathExists conditions in the systemd service 
files.
Hence, a symlink for /etc/krb5.keytab must be used.

With kind regards,
Joachim Falk
--- nfs-utils_env.sh.orig	2016-12-23 22:43:59.816660950 +0100
+++ nfs-utils_env.sh	2016-12-23 23:27:20.266394604 +0100
@@ -12,12 +12,12 @@
 echo RPCNFSDARGS=\"$RPCNFSDOPTS ${RPCNFSDCOUNT:-8}\"
 echo RPCMOUNTDARGS=\"$RPCMOUNTDOPTS\"
 echo STATDARGS=\"$STATDOPTS\"
-echo RPCSVCGSSDARGS=\"$RPCSVCGSSDOPTS\"
+echo SVCGSSDARGS=\"$RPCSVCGSSDOPTS\"
+echo SMNOTIFYARGS=\"$SMNOTIFYARGS\"
+echo RPCIDMAPDARGS=\"$RPCIDMAPDARGS\"
+echo GSSDARGS=\"$RPCGSSDOPTS\"
 } > /run/sysconfig/nfs-utils
 
 # the following are supported by the systemd units, but not exposed in default files
-# echo SMNOTIFYARGS=\"$SMNOTIFYARGS\"
-# echo RPCIDMAPDARGS=\"$RPCIDMAPDARGS\"
-# echo RPCGSSDARGS=\"$RPCGSSDARGS\"
 # echo BLKMAPDARGS=\"$BLKMAPDARGS\"
 # echo GSS_USE_PROXY=\"$GSS_USE_PROXY\"
# To apply settings to systemd service units execute the following commands:
# systemctl restart nfs-config (this will update /run/sysconfig/nfs-utils)
# systemctl restart nfs-utils (this will apply /run/sysconfig/nfs-utils)

# The following two settings are only respected by the systemd nfs services 
units.
# See the !!!PATCHED!!! /usr/lib/systemd/scripts/nfs-utils_env.sh and the 
associated services
# /lib/systemd/system/nfs-config.service
# /lib/systemd/system/nfs-idmapd.service
# /lib/systemd/system/nfs-utils.service
# /lib/systemd/system/rpc-gssd.service
# /lib/systemd/system/rpc-svcgssd.service
# /lib/systemd/system/rpc-statd.service
# /lib/systemd/system/rpc-statd-notify.service
# /lib/systemd/system/auth-rpcgss-module.service
SMNOTIFYARGS=""
RPCIDMAPDARGS=""

# If you do not set values for the NEED_ options, they will be attempted
# autodetected; this should be sufficient for most people. Valid alternatives
# for the NEED_ options are "yes" and "no".

# Do you want to start the statd daemon? It is not needed for NFSv4.
NEED_STATD=

# Options for rpc.statd.
#   Should rpc.statd listen on a specific port? This is especially useful
#   when you have a port-based firewall. To use a fixed port, set this
#   this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
#   For more information, see rpc.statd(8) or http://wiki.debian.org/SecuringNFS
STATDOPTS=

# Do you want to start the idmapd daemon? It is only needed for NFSv4.
NEED_IDMAPD=yes

# Do you want to start the gssd daemon? It is required for Kerberos mounts.
NEED_GSSD=yes

RPCGSSDOPTS="-k /etc/krb5/krb5.keytab"
#RPCGSSDOPTS="-vvv -rrr -k /etc/krb5/krb5.keytab" # comment in for debugging


signature.asc
Description: OpenPGP digital signature

Bug#790949: conditional-restart from postinst and related scripts of plugin packages

Hello,

On Fri, Jul 03, 2015 at 11:22:41AM +0200, Daniel Pocock wrote:
> Package: debian-policy
> Severity: important
> 
> Some of this has been discussed in other bugs such as
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=60979
> requesting an init script action for restart-only-if-running

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181123

> 
> Consider the following:
> 
> - package foo provides a daemon
> - package foo-plugin-bar provides the 'bar' plugin for 'foo'
> 
> How should the foo-plugin-bar postrm work?

My suggestion is that any package which provides a plugin interface
also provide a dpkg triggers interface that other packages
who ships plugins can interact via.

That way the main package decides what the relevant action is
for a given activated trigger.

(See eg. src:rygel for a packaging example using triggers for plugins.)

> 
> Should it restart foo?

Likely no, never.

(That would mean a new service could get started just because a
plugin happened to be installed.)

> 
> Should it do a conditional restart?

Likely yes, normally.

(Some services might have other better ways to pick up new plugins.)

> 
> During dist-upgrade, can anything be done to ensure the service is not
> started by mistake by one of the postinst scripts until the other
> package has also been upgraded?

Well, bugs may always happen I guess. but also the previously
suggested trigger solution should help here by centralizing the
implementation in one place rather than spreading/duplicating it
over many packages.

> 
> In the policy manual, s9.3.3.2 "Running initscripts", it is suggested to
> use:
> 
>   if which invoke-rc.d >/dev/null 2>&1; then
>   invoke-rc.d package 
>   else
>   /etc/init.d/package 
>   fi

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833177

> 
> 
> Could it be better to give a second example, how to restart only if
> already running:
> 
>   if which invoke-rc.d >/dev/null 2>&1; then
>   invoke-rc.d status package >/dev/null 2>&1 && \

^ wrong order.

>   invoke-rc.d package restart
>   else
>   /etc/init.d/package restart

(Direct init script invokations is BAD! Again, see #833177)

>   fi
> # whatever happened, return success:
> true

Again see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=181123

The LSB standard and systemctl variant of this is the 'try-restart'
action. Nothing in current debian policy should disallow you from
using it in your init scripts. Reinventing this interface isn't
really useful. Also, you might be tempted to say that try-reload is only
optional in LSB, not mentioned in debian policy and might not be
available (sure, but if you need it you should add it!) but
then again your suggestion also relies on an action that's not
guaranteed to be available -> status.

> 
> 
> Plugin packages, such as foo-plugin-bar, may want to use this second
> example or some variation of it instead.
> 

The content of this bug report is either:

 a/ already covered by #181123 or #833177
 b/ implementation specific to the daemon providing the plugin interface

Given plugin interfaces are very much custom made I doubt anyone
would suggest mandating a single unified implementation in
Debian policy (which would likely make all existing debian packages
of things providing plugin interfaces RC-buggy at once).

I'm thus not very sure what is being asked to be added to policy?

Which already established pattern in the debian archive is it
that should be recorded in policy?

If it where up to me I'd say this bug report should simply be closed:
 - for the a/ case it's mostly a duplicate of #181123 (and conflict
   against the other).
 - for the b/ case it seems more like a wonfix bug.

This all seems more like something that could be better described on
a wiki.debian.org page discussing plugin strategies and matching debian
packaging strategies plus links to example packages to look at.

Regards,
Andreas Henriksson

Bug#845803: fixed in gpgme1.0 1.8.0-3

2017-01-01 Thread Ryan Tandy


On Fri, Dec 30, 2016 at 06:04:03PM +1100, Stuart Prescott wrote:

Given that these priorities are changed in the package but not the archive, I
assume that you'd like the archive updated too. Would you be able to ask the
ftp-masters to adjust the overrides? (Or would you like me to do that for
you?)

I believe the correct bug title is¹:

override: libgpgme-dev:libdevel/extra, llibgpgmepp-dev:libdevel/extra,
libgpgmepp-doc:doc/optional, libgpgmepp6:libs/optional,
libqgpgme7:libs/optional, python-gpg:python/optional, python3-
gpg:python/optional

(without whatever line-breaks creep into it, obviously...)


I didn't see this follow-up, but I've just finished filing exactly that 
on my own initiative: #849903.


Apologies for missing out on the coordination. I see I've missed several 
messages on other lists.


(for avoidance of doubt: not a gpgme1.0 maintainer)

Bug#849906: python-django-ratelimit: please add dependency “Suggests: python-django-ratelimit-doc”

Source: django-ratelimit
Version: 0.4.0+8+gd58c489-3
Severity: minor

Dear Maintainer,

Working with the ‘django-ratelimit’ packages requires understanding
how it works and what it does.

Please set a “Suggests: python-django-ratelimit-doc” dependency to the
binary package ‘python3-django-ratelimit’, or other binary packages for
which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \“Laurie got offended that I used the word ‘puke’. But to me, |
  `\ that's what her dinner tasted like.” —Jack Handey |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849904: python-dipy: please add dependency “Suggests: python-dipy-doc”

Source: dipy
Version: 0.11.0-1
Severity: minor

Dear Maintainer,

Working with the ‘dipy’ packages requires understanding how it works
and what it does.

Please set a “Suggests: python-dipy-doc” dependency to the binary
package ‘python3-dipy’, or other binary packages for which it is
appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \  “It is clear that thought is not free if the profession of |
  `\   certain opinions makes it impossible to earn a living.” |
_o__)  —Bertrand Russell, _Free Thought and Official Propaganda_, 1928 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849905: python-django-feincms: please add dependency “Suggests: python-django-feincms-doc”

Source: python-django-feincms
Version: 1.11.4-1
Severity: minor

Dear Maintainer,

Working with the ‘python-django-feincms’ packages requires
understanding how it works and what it does.

Please set a “Suggests: python-django-feincms-doc” dependency to the
binary package ‘python3-django-feincms’, or other binary packages for
which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \  “When I get real bored, I like to drive downtown and get a |
  `\ great parking spot, then sit in my car and count how many |
_o__)people ask me if I'm leaving.” —Steven Wright |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849903: override: libgpgme-dev:libdevel/extra, libgpgmepp-dev:libdevel/extra, libgpgmepp-doc:doc/extra, libgpgmepp6:libs/optional, libqgpgme7:libs/optional, python-gpg:python/optional, python3-gpg

2017-01-01 Thread Ryan Tandy

Package: ftp.debian.org
Severity: normal

Please demote the binaries of src:gpgme1.0 to priority optional/extra. 
The maintainer ACKed this change and has already applied it to the 
source in unstable; see #845803.

Quoting that bug:

> Looking at the revision control history, this was bumped from "optional"
> to "standard" back in 2013 in response to a request from the mutt
> maintainer: https://bugs.debian.org/623353
> 
> however, mutt is today priority: optional itself, so i'm going to bump
> all of gpgme back down to "optional" (and its -dev packages down to
> "extra") in the next release.

AFAICT, none of the packages has any reverse dependencies of priority 
standard or higher (other than packages included in this request).

thanks,
Ryan

Bug#849902: python-btrees: please add dependency “Suggests: python-btrees-doc”

Source: python-btrees
Version: 4.3.1-1
Severity: minor

Dear Maintainer,

Working with the ‘python-btrees’ packages requires understanding how
it works and what it does.

Please set a “Suggests: python-btrees-doc” dependency to the binary
package ‘python-btrees’, or other binary packages for which it is
appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “We spend the first twelve months of our children's lives |
  `\  teaching them to walk and talk and the next twelve years |
_o__)   telling them to sit down and shut up.” —Phyllis Diller |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849901: netgen: please add dependency “Suggests: netgen-doc”

Source: netgen
Version: 4.9.13.dfsg-8+b4
Severity: minor

Dear Maintainer,

Working with the ‘netgen’ packages requires understanding how it works
and what it does.

Please set a “Suggests: netgen-doc” dependency to the binary package
‘netgen’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \ “The reward of energy, enterprise and thrift is taxes.” |
  `\  —William Feather |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849899: libzypp: please add dependency “Suggests: libzypp-doc”

Source: libzypp
Version: 15.3.0-1+b2
Severity: minor

Dear Maintainer,

Working with the ‘libzypp’ packages requires understanding how it
works and what it does.

Please set a “Suggests: libzypp-doc” dependency to the binary package
‘libzypp-dev’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \ “What is needed is not the will to believe but the will to find |
  `\   out, which is the exact opposite.” —Bertrand Russell, _Free |
_o__)   Thought and Official Propaganda_, 1928 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849900: nbibtex: please add dependency “Suggests: nbibtex-doc”

Source: nbibtex
Version: 0.9.18-11
Severity: minor

Dear Maintainer,

Working with the ‘nbibtex’ packages requires understanding how it
works and what it does.

Please set a “Suggests: nbibtex-doc” dependency to the binary package
‘nbibtex’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “The best is the enemy of the good.” —Voltaire, _Dictionnaire |
  `\Philosophique_ |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849146: [Pkg-samba-maint] Bug#849146: samba: empty client domain is not mapped to standalone server domain when user name contains @

2017-01-01 Thread André Janna


Mathieu Parent :


Can you forward this to upstream bugzilla (linked to
https://bugzilla.samba.org/show_bug.cgi?id=12375) and report back bug#
here?

Thanks

--
Mathieu



I opened upstream bug https://bugzilla.samba.org/show_bug.cgi?id=12492

André

Bug#601455: Standardize how to disable an init script

Hello!

The underlying issue for this bug report is similar to what's recently
been discussed in #522163 - the /etc/default/ ENABLED anti-pattern.

In #522163 it seemed the conclusion included that documenting that
something is an anti-pattern in policy itself was not desirable. I thus
think that much of any potential solution to #601455 is also likely not
desirable to have in policy.

Possibly these to bug reports should just be merged (and wontfix tagged
together).

Regards,
Andreas Henriksson

Bug#849898: libswe: please add dependency “Suggests: libswe-doc”

Source: libswe
Version: 1.80.00.0002-1
Severity: minor

Dear Maintainer,

Working with the ‘libswe’ packages requires understanding how it works
and what it does.

Please set a “Suggests: libswe-doc” dependency to the binary package
‘libswe-dev’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “Even if the voices in my head are not real, they have pretty |
  `\   good ideas.” —anonymous |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#848851: linux: FTBFS on ppc64el

Control: tag -1 upstream fixed-upstream pending

On Mon, 2017-01-02 at 02:38 +, Ben Hutchings wrote:
> On Mon, 2017-01-02 at 02:34 +, Ben Hutchings wrote:
> [...]
> > Let's try without that -pie:
> > 
> > $ ld -m elf64lppc -T arch/powerpc/boot/zImage.lds -o 
> > arch/powerpc/boot/zImage.pseries arch/powerpc/boot/pseries-head.o 
> > arch/powerpc/boot/of.o arch/powerpc/boot/epapr.o ./zImage.15656.o 
> > arch/powerpc/boot/wrapper.a
> > $
> > 
> > Surprise, it works!  So we need to filter out -pie here as well.
> 
> [...]
> 
> But that doesn't make sense.  gcc-6's implicit -pie has been a problem
> in some places, but this is kbuild explicitly passing -pie where we are
> still using gcc-5.

Anyway, now that I know to look at the wrapper script, I found the fix:

commit ff45000fcb56b5b0f1a14a865d3541746d838a0a
Author: Nicholas Piggin 
Date:   Mon Nov 28 12:42:26 2016 +1100

powerpc/boot: Request no dynamic linker for boot wrapper

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or
apathy?
A.  I don't know and I couldn't care less.



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

Bug#849897: libplank: please add dependency “Suggests: libplank-doc”

Source: plank
Version: 0.11.3-1
Severity: minor

Dear Maintainer,

Working with the ‘plank’ packages requires understanding how it works
and what it does.

Please set a “Suggests: libplank-doc” dependency to the binary package
‘libplank-dev’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “I am as agnostic about God as I am about fairies and the |
  `\   Flying Spaghetti Monster.” —Richard Dawkins, 2006-10-13 |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849896: libjs-yui3: please add dependency “Suggests: libjs-yui3-doc”

Source: yui3
Version: 3.5.1-1
Severity: minor

Dear Maintainer,

Working with the ‘yui3’ packages requires understanding how it works
and what it does.

Please set a “Suggests: libjs-yui3-doc” dependency to the binary
package ‘libjs-yui3-common’, or other binary packages for which it is
appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “Give a man a fish, and you'll feed him for a day; give him a |
  `\religion, and he'll starve to death while praying for a fish.” |
_o__)   —Anonymous |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849894: libjodreports-java: please add dependency “Suggests: libjodreports-java-doc”

Source: jodreports
Version: 2.10.11~dfsg-2.1
Severity: minor

Dear Maintainer,

Working with the ‘jodreports’ packages requires understanding how it
works and what it does.

Please set a “Suggests: libjodreports-java-doc” dependency to the
binary package ‘libjodreports-java’, or other binary packages for
which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \“We cannot solve our problems with the same thinking we used |
  `\   when we created them.” —Albert Einstein |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849892: libaria-dev: please add dependency “Suggests: libaria-dev-doc”

Source: libaria
Version: 2.8.0+repack-1
Severity: minor

Dear Maintainer,

Working with the ‘libaria’ packages requires understanding how it
works and what it does.

Please set a “Suggests: libaria-dev-doc” dependency to the binary
package ‘libaria-dev’, or other binary packages for which it is
appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \ “Pinky, are you pondering what I'm pondering?” “I think so, |
  `\   Brain, but culottes have a tendency to ride up so.” —_Pinky and |
_o__)   The Brain_ |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849893: libdigidoc: please add dependency “Suggests: libdigidoc-doc”

Source: libdigidoc
Version: 3.10.1.1208+ds1-2
Severity: minor

Dear Maintainer,

Working with the ‘libdigidoc’ packages requires understanding how it
works and what it does.

Please set a “Suggests: libdigidoc-doc” dependency to the binary
package ‘libdigidoc*’, or other binary packages for which it is
appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “Give a man a fish, and you'll feed him for a day; give him a |
  `\religion, and he'll starve to death while praying for a fish.” |
_o__)   —Anonymous |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849895: libgnuplot-iostream: please add dependency “Suggests: libgnuplot-iostream-doc”

Source: gnuplot-iostream
Version: 0~20140302.gitc8919a0+dfsg-2
Severity: minor

Dear Maintainer,

Working with the ‘gnuplot-iostream’ packages requires understanding
how it works and what it does.

Please set a “Suggests: libgnuplot-iostream-doc” dependency to the
binary package ‘libgnuplot-iostream-dev’, or other binary packages for
which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \“Intellectual property is to the 21st century what the slave |
  `\  trade was to the 16th.” —David Mertz |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849891: gmt-doc: please add dependency “Recommends: gmt-tutorial”

Source: gmt
Version: 5.3.1+dfsg-2
Severity: minor

Dear Maintainer,

The GMT tutorial in the ‘gmt-doc’ package requires the data files in
the ‘gmt-tutorial’ package.

Please set a “Recommends: gmt-tutorial” dependency to the binary
package ‘gmt-doc’, or other binary packages for which it is
appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \  “It is … incumbent upon us to recognize that it is |
  `\inappropriate for religion to play any role in issues of state |
_o__)[of] a modern democracy.” —Lawrence M. Krauss, 2012-05-28 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#833177: 9.3.3.2: Remove /etc/init.d/

On Mon, Aug 01, 2016 at 08:22:19PM +0200, Ondřej Nový wrote:
[...]
> Please remove usage of "/etc/init.d/package " as alternative for
> invoke-rc.d
[...]

The patch attached to the original bug reports looks fine and still
applies, so I'm just here to say:

Seconded

fwiw, this is a case of following old legacy cruft in policy being
harmful so would appreciate this being fixed asap. IIRC I talked Ondřej
out of following policy on this which also resulted in this bug report
when we faced a deeper issue during stretch development timeframe (that
ofcourse we should fix at the root of the problem rather than just hide
by following outdated practises in every package on top).
I'm thus happy this bug report has gotten its severity raised recently.

Regards,
Andreas Henriksson

Bug#849890: korganizer: korgac crashes every time I login into a KDE session

2017-01-01 Thread Kamaraju Kusumanchi

Package: korganizer
Version: 4:16.04.3-2
Severity: normal

Dear Maintainer,

Every time I login into a KDE session, korgac crashes with a segmentation
fault. Please find the backtrace from the crash handler below.

Application: korgac (korgac), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
[Current thread is 1 (Thread 0x7fe013d69940 (LWP 2274))]

Thread 3 (Thread 0x7fe010887700 (LWP 2315)):
[KCrash Handler]
#6  0x7fe02e0043ef in QObject::disconnect (sender=0xcb7b3ab0,
signal=signal@entry=0x0, receiver=receiver@entry=0x7fe0040030f0,
method=method@entry=0x0) at kernel/qobject.cpp:2956
#7  0x7fe033000d50 in QObject::disconnect (member=0x0,
receiver=0x7fe0040030f0, this=) at
../../include/QtCore/../../src/corelib/kernel/qobject.h:336
#8  QDBusConnectionPrivate::closeConnection (this=this@entry=0x7fe0040030f0) at
qdbusintegrator.cpp:1145
#9  0x7fe032fed7e2 in QDBusConnectionManager::run (this=0x7fe033062d60
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
qdbusconnection.cpp:188
#10 0x7fe02de04da8 in QThreadPrivate::start (arg=0x7fe033062d60 <(anonymous
namespace)::Q_QGS__q_manager::innerFunction()::holder>) at
thread/qthread_unix.cpp:368
#11 0x7fe026772464 in start_thread (arg=0x7fe010887700) at
pthread_create.c:333
#12 0x7fe02d5089df in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 2 (Thread 0x7fe011da7700 (LWP 2305)):
#0  0x7fe02d4ff56d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7fe02748a150 in poll (__timeout=-1, __nfds=1, __fds=0x7fe011da6b80)
at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0xcb75da80, cond=cond@entry=0xcb75dac0,
vector=vector@entry=0x0, count=count@entry=0x0) at ../../src/xcb_conn.c:479
#3  0x7fe02748bee9 in xcb_wait_for_event (c=0xcb75da80) at
../../src/xcb_in.c:693
#4  0x7fe013accb69 in QXcbEventReader::run (this=0xcb76e550) at
qxcbconnection.cpp:1343
#5  0x7fe02de04da8 in QThreadPrivate::start (arg=0xcb76e550) at
thread/qthread_unix.cpp:368
#6  0x7fe026772464 in start_thread (arg=0x7fe011da7700) at
pthread_create.c:333
#7  0x7fe02d5089df in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:105

Thread 1 (Thread 0x7fe013d69940 (LWP 2274)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fe02de05c6b in QWaitConditionPrivate::wait
(time=18446744073709551615, this=0xcb79d6b0) at
thread/qwaitcondition_unix.cpp:143
#2  QWaitCondition::wait (this=this@entry=0xcb793510,
mutex=mutex@entry=0xcb7934f0, time=time@entry=18446744073709551615) at
thread/qwaitcondition_unix.cpp:215
#3  0x7fe02de0494e in QThread::wait (this=this@entry=0x7fe033062d60
<(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>,
time=time@entry=18446744073709551615) at thread/qthread_unix.cpp:698
#4  0x7fe032fed546 in QDBusConnectionManager::~QDBusConnectionManager
(this=0x7fe033062d60 <(anonymous
namespace)::Q_QGS__q_manager::innerFunction()::holder>, __in_chrg=) at qdbusconnection.cpp:157
#5  0x7fe032fed5d9 in (anonymous
namespace)::Q_QGS__q_manager::Holder::~Holder (this=,
__in_chrg=) at qdbusconnection.cpp:76
#6  0x7fe02d455920 in __run_exit_handlers (status=0, listp=0x7fe02d7b85d8
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:83
#7  0x7fe02d45597a in __GI_exit (status=) at exit.c:105
#8  0x7fe02fcdf4a5 in
KDBusService::KDBusService(QFlags, QObject*) ()
from /usr/lib/x86_64-linux-gnu/libKF5DBusAddons.so.5
#9  0xcab2c535 in ?? ()
#10 0x7fe02d4402b1 in __libc_start_main (main=0xcab2c070, argc=1,
argv=0x7fff9e9ea898, init=, fini=,
rtld_fini=, stack_end=0x7fff9e9ea888) at ../csu/libc-start.c:291
#11 0xcab2c76a in _start ()


FWIW, I am running Debian Stretch (currently testing)

thanks
raju



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

Kernel: Linux 4.8.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE= (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages korganizer depends on:
ii  kdepim-runtime   4:16.04.2-2
ii  kf5-kdepimlibs-kio-plugins   4:16.04.2-2
ii  libc62.24-8
ii  libgcc1  1:6.2.1-5
ii  libkf5akonadicalendar5   16.04.2-2
ii  libkf5akonadicontact54:16.04.2-2
ii  libkf5akonadicore-bin4:16.04.3-3+b1
ii  libkf5akonadicore5   4:16.04.3-3+b1
ii  libkf5akonadimime5   4:16.04.2-2
ii  libkf5akonadinotes5  4:16.04.2-2
ii  libkf5akonadisearchpim5  16.04.3-1
ii  libkf5akonadiwidgets54:16.04.3-3+b1
ii

Bug#849888: babel: please add dependency “Suggests: babel-doc”

Source: babel
Version: 1.4.0.dfsg-8.2
Severity: minor

Dear Maintainer,

Working with the ‘babel’ packages requires understanding how it works
and what it does.

Please set a “Suggests: babel-doc” dependency to the binary package
‘babel-*’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \   “It is a part of probability that many improbable things will |
  `\   happen.” —Aristotle, _Poetics XXV_, 335 BCE |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature

Bug#849889: freevo: please add dependency “Suggests: freevo-doc”

Source: freevo
Version: 1.9.2b2-4.3
Severity: minor

Dear Maintainer,

Working with the ‘freevo’ packages requires understanding how it works
and what it does.

Please set a “Suggests: freevo-doc” dependency to the binary package
‘freevo’, or other binary packages for which it is appropriate.

This will present the suggestion to administrators choosing which
packages to install.

-- 
 \  “Shepherds … look after their sheep so they can, first, fleece |
  `\   them and second, turn them into meat. That's much more like the |
_o__)  priesthood as I know it.” —Christopher Hitchens, 2008-10-29 |
Ben Finney 


signature.asc
Description: PGP signature

Bug#181123: [PATCH 2/2] Document status init script action

In LSB the status action is among the 'shall be supported' actions.
In Debian there are still many init scripts which does not support
the status action still to this day (see lintian catches for
init.d-script-does-not-implement-optional-option status).

Given we avoid creating a big number of RC bugs (under anyones
interpretation), we don't want to implement status as non-optional.
At the same time as it's not optional in LSB, we don't want to
add it to optional either.

Solve this by creating a new middle ground for 'recommended' actions
and put status there. Hopefully one day status can move up to the
rest of the 'non-optional' actions.

LSB also documents the specific return codes for the status action
which might be useful to have in policy as well, but at the same
time do we really want to duplicate all of LSB?
For now lets leave that as a potential future enhancement.
(See also discussion about this in merged/duplicate bug report.)

Fwiw, systemctl also supports status and trivial testing seems to
indicate it also uses the LSB specified return codes.

https://lintian.debian.org/tags/init.d-script-does-not-implement-optional-option.html
---
 policy.sgml | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/policy.sgml b/policy.sgml
index 2fa250f..ef5d902 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7551,12 +7551,16 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
  cause the configuration to be reloaded if the
  service supports this, otherwise restart the
  service.
+
+ status
+ report the current status of the service

 
The start, stop, restart, and
force-reload options should be supported by all
-   scripts in /etc/init.d, the reload
-   and try-restart options are optional.
+   scripts in /etc/init.d, supporting
+   status is recommended, the reload and
+   try-restart options are optional.
  
 
  
-- 
2.11.0

Bug#181123: [PATCH 0/2] Mention try-reload and status actions

These patches is an attempt to finally put #181123 to rest.

It tries to strike a well balanced middle ground between existing
debian state of the archive and the LSB. The main focus has been
to atleast mention the actions where previously left out of policy
while being documented in LSB.

This entire chapter still needs a major overhaul given the world no
longer only revolves around (sysv)init scripts. That's no reason not to
start with this small first step though

Andreas Henriksson (2):
  Document optional try-restart init script action
  Document status init script action

 policy.sgml | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

-- 
2.11.0

Bug#181123: [PATCH 1/2] Document optional try-restart init script action

Add the try-restart action similar to how LSB describes it.
Many init scripts in Debian still does not support this action
but fortunately even LSB just documents it as optional.

Fwiw, systemctl also supports try-restart action in the same fashion.
---
 policy.sgml | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/policy.sgml b/policy.sgml
index cb51a43..2fa250f 100644
--- a/policy.sgml
+++ b/policy.sgml
@@ -7538,6 +7538,10 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
  stop and restart the service if it's already running,
  otherwise start the service
 
+ try-restart
+ restart the service if it's already running,
+otherwise just report success.
+
  reload
  cause the configuration of the service to be
  reloaded without actually stopping and restarting
@@ -7552,7 +7556,7 @@ rmdir /usr/local/share/emacs 2>/dev/null || true
The start, stop, restart, and
force-reload options should be supported by all
scripts in /etc/init.d, the reload
-   option is optional.
+   and try-restart options are optional.
  
 
  
-- 
2.11.0

Bug#814719: nyancat-server: doesn't actually provide a server

2017-01-01 Thread Axel Beckert

Control: retitle -1 nyancat-server: server does not start automatically with 
non-systemd init systems
Control: severity -1 important

Hi Adam,

Adam Borowski wrote:
> [~]# netstat -anp|grep :23
> [~]# 
> 
> As that's the only stated purpose of this package, I'm setting severity to
> grave.
[…]
> Init: sysvinit (via /sbin/init)

This very likely only affects non-systemd users as it doesn't ship an
init script (or inetd configuration) but does ship
/lib/systemd/system/nyancat-server.socket for systemd-only socket
activation (didn't check if that works, though, no systemd here
either).

Hence downgrading to important as the package is not unusable for
_all_ users.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#848851: linux: FTBFS on ppc64el

On Mon, 2017-01-02 at 02:34 +, Ben Hutchings wrote:
[...]
> Let's try without that -pie:
> 
> $ ld -m elf64lppc -T arch/powerpc/boot/zImage.lds -o 
> arch/powerpc/boot/zImage.pseries arch/powerpc/boot/pseries-head.o 
> arch/powerpc/boot/of.o arch/powerpc/boot/epapr.o ./zImage.15656.o 
> arch/powerpc/boot/wrapper.a
> $
> 
> Surprise, it works!  So we need to filter out -pie here as well.
[...]

But that doesn't make sense.  gcc-6's implicit -pie has been a problem
in some places, but this is kbuild explicitly passing -pie where we are
still using gcc-5.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or
apathy?
A.  I don't know and I couldn't care less.



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

Bug#848851: linux: FTBFS on ppc64el

On Tue, 2016-12-20 at 10:12 +0200, Adrian Bunk wrote:
> On Tue, Dec 20, 2016 at 08:57:55AM +0100, Salvatore Bonaccorso wrote:
> > Source: linux
> > Version: 4.8.15-1
> > Severity: serious
> > Justification: FTBFS
> > 
> > Hi
> > 
> > src:linux 4.8.15-1 FTBFS on ppc64el.
> > 
> > Log: 
> > https://buildd.debian.org/status/fetch.php?pkg=linux=ppc64el=4.8.15-1=1482184049
> > 
> > [...]
> >   CC  crypto/af_alg.mod.o
> >   CC  crypto/algif_aead.mod.o
> > ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, 
> > try linking with -N
> > ld: final link failed: Bad value
> > /«PKGBUILDDIR»/arch/powerpc/boot/Makefile:323: recipe for target 
> > 'arch/powerpc/boot/zImage.pseries' failed
> > make[6]: *** [arch/powerpc/boot/zImage.pseries] Error 1
> > make[6]: *** Waiting for unfinished jobs
> >   CC  crypto/algif_hash.mod.o
> > arch/powerpc/Makefile:285: recipe for target 'zImage' failed
> > make[5]: *** [zImage] Error 2
> > make[5]: *** Waiting for unfinished jobs
> >   CC  crypto/algif_skcipher.mod.o
> > [...]
> 
> I'd assume this is also a duplicate of #848798, but I am less sure about 
> that than for #848850 (which I already merged with the binutils bug).

With KBUILD_VERBOSE=1 I see:

...
  /bin/bash /home/benh/linux-4.8.15/arch/powerpc/boot/wrapper -c -o 
arch/powerpc/boot/zImage.pseries -p pseries   vmlinux
ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, 
try linking with -N
ld: final link failed: Bad value

and then with tracing enabled for that shell script:

...
+ ld -m elf64lppc -T arch/powerpc/boot/zImage.lds -pie -o 
arch/powerpc/boot/zImage.pseries arch/powerpc/boot/pseries-head.o 
arch/powerpc/boot/of.o arch/powerpc/boot/epapr.o ./zImage.15656.o 
arch/powerpc/boot/wrapper.a
ld: arch/powerpc/boot/zImage.pseries: Not enough room for program headers, 
try linking with -N
ld: final link failed: Bad value

Let's try without that -pie:

$ ld -m elf64lppc -T arch/powerpc/boot/zImage.lds -o 
arch/powerpc/boot/zImage.pseries arch/powerpc/boot/pseries-head.o 
arch/powerpc/boot/of.o arch/powerpc/boot/epapr.o ./zImage.15656.o 
arch/powerpc/boot/wrapper.a
$

Surprise, it works!  So we need to filter out -pie here as well.  (Or
disable building these wrappers, since we don't actually package them. 
But that doesn't seem to be a kconfig option)

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today, ignorance or
apathy?
A.  I don't know and I couldn't care less.



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

Bug#849887: captagent: init.d-script-does-not-implement-required-option force-reload

Package: captagent
Version: 6.1.0.20-2
Severity: normal
Tags: patch

Dear Maintainer,

Please see attached patch to fix lintian error and implement the
debian policy (non-optional) force-reload init script action.

Note that this trivial patch has not been tested. Review carefully.

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

Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
>From a1a960da04d89e6aa49079831a0bba04b1897d57 Mon Sep 17 00:00:00 2001
From: Andreas Henriksson 
Date: Mon, 2 Jan 2017 03:23:06 +0100
Subject: [PATCH] Add missing required force-reload init script action

The 'force-reload' action is required by LSB and is among the
(non-optional) 'shall' options in Debian policy.
Simply have it fall back on the restart action.

As a bonus, the condrestart action gets an alternative
name 'try-restart' which is the LSB documented name for
this action.
---
 debian/captagent.init | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/captagent.init b/debian/captagent.init
index 5cb8929..bed038c 100644
--- a/debian/captagent.init
+++ b/debian/captagent.init
@@ -77,11 +77,11 @@ case "$1" in
 	status)
 		status
 		;;
-	restart)
+	restart|force-reload)
 		stop
 		start
 		;;
-	condrestart)
+	try-restart|condrestart)
 		if [ -f $pidfile ] ; then
 			stop
 			start
-- 
2.11.0

Bug#849884: Additional testing

2017-01-01 Thread Kyle Gordon

Hi,

This also causes guest Debian Stretch machines to terminate unexpectedly,
and can also be triggered by an alternative home automation package called
home-assistant.

I think this is certainly pointing at the KVM/QEMU host being faulty in
some way.

Kyle

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem,new logwatch sends mails with charset UTF-8

2017-01-01 Thread Jason Pyeron

> -Original Message-
> From: 'Klaus Ethgen' [mailto:kl...@ethgen.de] 
> Sent: Sunday, January 01, 2017 14:42
> To: Jason Pyeron
> Cc: 'Willi Mann'; 849...@bugs.debian.org; 
> logwatch-de...@lists.sourceforge.net
> Subject: Re: Bug#849531: [Logwatch-devel] Bug#849531: 
> Possible security problem,new logwatch sends mails with charset UTF-8
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> Am So den  1. Jan 2017 um 20:24 schrieb Jason Pyeron:
> > Yes, 8-bit ASCII, here is a translation table.
> 
> ASCII is 7 bit.
> 
> All 8 bit are different encodings.

Sorry, "extended" ascii (code page 437), been using it since 1984 and old 
naming habits die hard.

> 
> > > Below 128 it is not a problem as UTF-8 is transparent in this 
> > > range. But
> > > above 128 it _is_ a problem.
> > 
> > No, only when not ENCODED properly.
> 
> Well, exactly what I said.
> 
> > UTF-8 is very, very, likely going to stay.
> 
> I would wish that it would die as it is bad designed and have some bad
> behaviour, technical wise.
> 
> However, I am realistic enough to know that it will not be possible to
> replace UTF-8 with better design's. It is like IPv6, there is 
> no Plan B.
> 
> Just I will only use UTF-8 where it is cleary specified (like XML) or
> where it is the only possible way to go. With everything else I stay
> with latin1. But this is just my personal view.
> 
> Regards
>Klaus
> - -- 
> Klaus Ethgen   
> http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
> 
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> -BEGIN PGP SIGNATURE-
> Comment: Charset: ISO-8859-1
> 
> iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhpW38ACgkQpnwKsYAZ
> 9qzrIgwAlGkTGVpJEp1XKYNcpUF2hR7Ie6vlA3xFBfCacCDAjJx5gIrGLkX5d8Ay
> rus3hblp/Gv+r+IpzUrRyk5gifBAfaDWVnuj1j8Qi9dLFyhnQaD0LX8/MBgV6wOn
> A2/C+XedX1geoZxk7c/m6b59XaWAuN36JK8PJjpoWX/8MNqDoNYAr31gMrZkHwmw
> IYZygbLom22qcSq4ZeowWY5ZUX9nqku0/9NNzBYtegB/YIWxbzxWNaOIPhgPouZ5
> Ejjd14NBap4ZT263Bc55L+tvCBX2BU1iFipmKa5pRslexF3UdscR1e20b0wWVTaP
> HTkcNJggsNQVUpPYyxp6xUWkmaItZCMSSHC77sv4ur6jnRY8IolUlh+x68ZEayIn
> yU5O/rjg3tMbNaZHTOZcNZNtOisNOMm19SOkwNCezKdods8BhAI0z9I7rnDaOumT
> HefdprK0CTuylGKdAvBxJv6io3AKkNdTaZ32bFnfE2HtaX77ZNDTgXkmutE1og6t
> UeF6fw/T
> =Mr6M
> -END PGP SIGNATURE-
>

Bug#838800: [NMU] Re: Bug#838800: rss-glx build-depends on conflicting packages.

2017-01-01 Thread Axel Beckert

Control: tag -1 + patch pending

Hi,

Paul Wise wrote:
> On Sun, 2016-09-25 at 02:29 +0100, peter green wrote:
> > rss-glx build-depends on both libglew-dev and libglewmx-dev.
> > 
> > These are now provided from seperate source packages and conflict with 
> > each other. So it is not possible to satisfy the build-dependencies.
> 
> Dropping the libglewmx-dev fixes the FTBFS, didn't test the result though.

The resulting package works for me. Will make a non-maintainer upload
with the following patch soon after this mail.

diff -Nru rss-glx-0.9.1/debian/changelog rss-glx-0.9.1/debian/changelog
--- rss-glx-0.9.1/debian/changelog  2013-08-18 04:09:28.0 +0200
+++ rss-glx-0.9.1/debian/changelog  2017-01-02 00:50:24.0 +0100
@@ -1,3 +1,11 @@
+rss-glx (0.9.1-6.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Remove build-dependency libglewmx1.5-dev to avoid conflicting
+build-dependencies. (Closes: #838800)
+
+ -- Axel Beckert   Mon, 02 Jan 2017 00:50:24 +0100
+
 rss-glx (0.9.1-6) unstable; urgency=low
 
   * Build-depend on libgl1-mesa-dev instead of -swx11-dev (Closes: #713110)
diff -Nru rss-glx-0.9.1/debian/control rss-glx-0.9.1/debian/control
--- rss-glx-0.9.1/debian/control2013-08-18 04:08:35.0 +0200
+++ rss-glx-0.9.1/debian/control2017-01-02 00:50:24.0 +0100
@@ -6,7 +6,7 @@
  libgl1-mesa-dev | libgl-dev, libglu1-mesa-dev | libglu-dev,
  libglew1.5-dev | libglew-dev, libopenal-dev, libalut-dev,
  libmagickwand-dev (>= 7:6.4.0), libtool, pkg-config,
- libglc-dev, libglewmx1.5-dev, dh-autoreconf
+ libglc-dev, dh-autoreconf
 Standards-Version: 3.9.1
 Homepage: http://rss-glx.sourceforge.net
 
Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


signature.asc
Description: Digital signature

Bug#849886: create /var/log/monit.log with correct SELinux context

2017-01-01 Thread cgzones

Package: monit
Version: 1:5.20.0-4

On package installation, the log file /var/log/monit.log is created by
the post install script monit.postinst.
The SELinux context will not bet correctly set up.
Can you please either add something like

if [ -x /sbin/restorecon ]; then
   /sbin/restorecon /var/log/monit.log
fi

to restore the context or install the file via

intsall -o root -g adm -m 0640 /dev/null /var/log/monit.log

?

Kindly Regards,
 Christian Göttsche

Bug#849885: sweethome3d: SweetHome3D does not show up in "Open with application" list

2017-01-01 Thread Nagy Attila István

Package: sweethome3d
Version: 4.5+dfsg-3
Severity: important
Tags: patch

SweetHome3D is not listed in the application list reachable via right clicking 
a file and selecting 
 "Open with"->"Other application..."->"View all applications".
The cause of this is that the SweetHome3D desktop file 
(/usr/share/applications/sweethome3d.desktop) lacks a %U from the Exec line, 
 this way Gnome3 doesn't recognise the program as being able to handle 
parameters, so it is excluded from 
 the list of appications.

The solution is to change the line in the file 
/usr/share/applications/sweethome3d.desktop:

Exec=sweethome3d

to:

Exec=sweethome3d %U



-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'proposed-updates'), (500, 
'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages sweethome3d depends on:
ii  default-jre [java6-runtime] 2:1.7-52
ii  icedtea-netx-common 1.5.3-1
ii  java-wrappers   0.1.28
ii  libbatik-java   1.7+dfsg-5
ii  libfreehep-graphicsio-svg-java  2.1.1-3
ii  libitext-java   2.1.7-9
ii  libjava3d-java  1.5.2+dfsg-11
ii  libsunflow-java 0.07.2.svn396+dfsg-13
ii  openjdk-6-jre [java6-runtime]   6b31-1.13.3-1
ii  openjdk-7-jre [java6-runtime]   7u111-2.6.7-1~deb8u1

Versions of packages sweethome3d recommends:
ii  sweethome3d-furniture  1.4.2-1

sweethome3d suggests no packages.

-- no debconf information

Bug#849284: insserv: fopen(/etc/insserv.conf): No such file or directory

MB> No, removing the above packages is totally safe in stretch (when using
MB> systemd)

(the only names I can remember are experimental, sid, testing, and stable.)

MB> Actually, you can run
MB> apt purge sysv-rc initscripts insserv startpar
MB> and I would recommend that to anyone upgrading to stretch.

OK I did it. Thanks. (Hope I can reboot.)

OK if that is so safe then why not add Conflicts stuff to them?

Bug#849284: insserv: fopen(/etc/insserv.conf): No such file or directory

2017-01-01 Thread Michael Biebl

Am 02.01.2017 um 00:52 schrieb 積丹尼 Dan Jacobson:
> Also when I want to remove insserv, aptitude asks
>  Remove the following packages:
> 1) initscripts [2.88dsf-59.8 (now, unstable)]
> 2) sysv-rc [2.88dsf-59.8 (now, unstable)]
> 3) sysv-rc-conf [0.99-7 (now, unstable)]
> 
> Which seems dangerous...
> 

It is no longer

> http://unix.stackexchange.com/questions/214155/completely-remove-remains-of-sysvinit
> 
> "Be aware that initscripts is not sysv specific, removing it will almost 
> certainly destroy your system."

This information is outdated.

> OK thank God me and anybody reading this bug did not remove insserv.
> 

No, removing the above packages is totally safe in stretch (when using
systemd)

Actually, you can run
apt purge sysv-rc initscripts insserv startpar
and I would recommend that to anyone upgrading to stretch.

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#849569: spice: Please package 0.13 branch to experimental

2017-01-01 Thread Erik Adler

I more or less a have already done it. I am a bit new to the whole
Debian packaging thing but if somebody wants to mentor me I can give it
a spin. I can understand that the maintainers for the stable spice
branch might feel a bit iffy about it though. Fair enough. For those
that need the binaries now :

https://github.com/adlererik/spice-virgl/releases
source :
https://github.com/adlererik/spice-virgl

Anybody can do what they want with the above code.

All the best

Erik Adler
GPG/PGP key ID: 0x2B4B58FE
gpg --keyserver pgp.mit.edu --recv-keys 0x2B4B58FE

Bug#849284: insserv: fopen(/etc/insserv.conf): No such file or directory

Also when I want to remove insserv, aptitude asks
 Remove the following packages:
1) initscripts [2.88dsf-59.8 (now, unstable)]
2) sysv-rc [2.88dsf-59.8 (now, unstable)]
3) sysv-rc-conf [0.99-7 (now, unstable)]

Which seems dangerous...

http://unix.stackexchange.com/questions/214155/completely-remove-remains-of-sysvinit

"Be aware that initscripts is not sysv specific, removing it will almost 
certainly destroy your system."

OK thank God me and anybody reading this bug did not remove insserv.

Bug#849884: qemu-kvm: USB host device pass through causes instant VM poweroff

2017-01-01 Thread Kyle Gordon

Package: qemu-kvm
Version: 1:2.1+dfsg-12+deb8u6
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Over the course of the past few weeks, a guest KVM instance that relies on USB 
pass through has been found in the powered off state. Restarting it shows that 
it has been hard powered off.

This is now reproducible with the connected RFXCom hardware. 

Guest OS = Debian Jessie
Host OS = Debian Jessie

Start guest machine, and configure USB pass through. In this case, it's for an 
RFXCom USB radio transceiver. Device is correctly detected in the guest, and 
shows up as expected in lsusb.
Start software that accesses the device. In this case, Domoticz home automation 
software.
Within a few minutes, the machine will be hard powered off. The following logs 
are present on the host.

2017-01-01 23:40:27.179+: starting up
LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin 
QEMU_AUDIO_DRV=spice /usr/bin/kvm -name homeauto -S -machine 
pc-i440fx-2.1,accel=kvm,usb=off -m 6144 -realtime mlock=off -smp 
2,sockets=2,cores=1,threads=1 -uuid a79858f4-274e-425f-aece-98c14dc8fbc6 
-no-user-config -nodefaults -chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/homeauto.monitor,server,nowait 
-mon chardev=charmonitor,id=monitor,mode=control -rtc base=utc,driftfix=slew 
-global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown -global 
PIIX4_PM.disable_s3=1 -global PIIX4_PM.disable_s4=1 -boot strict=on -device 
piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device 
virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x6 -drive 
file=/media/store/KVM_VMs/homeauto-new.qcow2,if=none,id=drive-virtio-disk0,format=qcow2
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x7,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1
 -drive file=/media/store/KVM_VMs/homeauto-new-1.qcow2,if=none,id=drive-virti
 o-disk1,format=qcow2 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0x9,drive=drive-virtio-disk1,id=virtio-disk1
 -drive 
file=/media/store/KVM_VMs/homeauto-new-3.qcow2,if=none,id=drive-virtio-disk2,format=qcow2
 -device 
virtio-blk-pci,scsi=off,bus=pci.0,addr=0xa,drive=drive-virtio-disk2,id=virtio-disk2
 -netdev tap,fd=28,id=hostnet0,vhost=on,vhostfd=29 -device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:38:01:2d,bus=pci.0,addr=0x3 
-chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 
-chardev spicevmc,id=charchannel0,name=vdagent -device 
virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0
 -device usb-tablet,id=input0 -spice 
port=5904,addr=127.0.0.1,disable-ticketing,seamless-migration=on -device 
qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,bus=pci.0,addr=0x2 
-device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device 
hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -chardev 
spicevmc,id=charredir0,name=usbr
 edir -device usb-redir,chardev=charredir0,id=redir0 -chardev 
spicevmc,id=charredir1,name=usbredir -device 
usb-redir,chardev=charredir1,id=redir1 -chardev 
spicevmc,id=charredir2,name=usbredir -device 
usb-redir,chardev=charredir2,id=redir2 -chardev 
spicevmc,id=charredir3,name=usbredir -device 
usb-redir,chardev=charredir3,id=redir3 -device 
usb-host,hostbus=6,hostaddr=4,id=hostdev0 -device 
virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x8 -msg timestamp=on
char device redirected to /dev/pts/1 (label charserial0)
main_channel_link: add main channel client
main_channel_handle_parsed: net test: latency 2.497000 ms, bitrate 41698055 bps 
(39.766364 Mbps)
red_dispatcher_set_cursor_peer: 
inputs_connect: inputs channel client create

=== Normal behaviour until Domoticz is started...  ===

qemu-system-x86_64: /build/qemu-XXUWBP/qemu-2.1+dfsg/hw/usb/core.c:600: 
usb_packet_copy: Assertion `p->actual_length + bytes <= iov->size' failed.
2017-01-01 23:42:30.995+: shutting down

I have tried 2.7+dfsg-3~bpo8+2 from jessie-backports, but the behaviour is the 
same.

Unsure where to try next. 

Regards

Kyle

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

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

Versions of packages qemu-kvm depends on:
ii  qemu-system-x86  1:2.1+dfsg-12+deb8u6

qemu-kvm recommends no packages.

qemu-kvm suggests no packages.

-- no debconf information

Bug#849284: insserv: fopen(/etc/insserv.conf): No such file or directory

> "MB" == Michael Biebl  writes:

MB> Why would anyone want to install insserv manually under systemd in
MB> stretch? It's no longer needed and should not be pulled in by other
MB> packages.

Then please add a Breaks or Conflicts or something, as there are a
thousand ways it could get installed by unknowing people / programs from
some list of packages, especially as we read in the Description
"Using insserv incorrectly can result in an unbootable system."

The Description should also say Do Not Install Along With ...

Bug#849840: libavformat57: enable libopenmpt support

2017-01-01 Thread James Cowgill

Hi,

On 01/01/17 19:42, Andreas Cadhalpun wrote:
> Hi James,
> 
> On 01.01.2017 02:12, James Cowgill wrote:
>> I think that libopenmpt should be enabled in the Debian ffmpeg package.
>> libopenmpt-dev is in the archive right now.
>>
>> libopenmpt is designed to be a replacement for libmodplug as it handles
>> the same types of files. There is an FAQ documenting the differences
>> here: https://lib.openmpt.org/libopenmpt/#sec_faq. The major advantage
>> is that it has a fairly active upstream compared to libmodplug and
>> certain modules play better with it.
>>
>> I don't know if libmodplug has to be disabled, but presumably ffmpeg
>> will choose one over the other for the vast majority of cases so I'm not
>> sure it's worth it having both enabled.
> 
> Thanks for filing such a detailed bug report.
> 
> I'm all for replacing libmodplug with a better maintained alternative,
> however, the ffmpeg libopenmpt demuxer currently has bug causing
> head-buffer-overflows in libopenmpt. I expect that the fix [1] will
> make it into the next ffmpeg bugfix release, so I intend to switch
> to libopenmpt when importing that.

Thanks! That sounds fine.

James



signature.asc
Description: OpenPGP digital signature

Bug#792594: libqt5qml5 requires SSE2 on i386

2017-01-01 Thread Guillem Jover

Hi!

On Sun, 2017-01-01 at 11:41:45 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> On domingo, 1 de enero de 2017 04:13:41 ART Guillem Jover wrote:
> [snip]
> > > In any case, because I need a patched Qt on my systems to be
> > > able to run many Qt applications at all, I'll have to rebase the patches
> > > and build local packages anyway. I'll try to send the rebased patches
> > > here for whoever else needs them, if I remember.
> > 
> > As I had to upgrade all the systems involved, I needed to update
> > the patches, which I did against 5.7.x and 5.8.x (git HEAD).
> > 
> > > If someone else wants access to the Qt Declaratives packages I'm
> > > building please say so, and I'll publish them on some repository.
> > 
> > This still stands.
> 
> And you are really willing to take care of this delta, so let's make it 
> official.

Ah, perfect thanks! And well, as long as I've got such hardware I'll
have to do that anyway, yes.

> The only thing I would like you to change in order to accept the patch is to 
> change the generic hasRequiredCpuSupport() for something more precise, maybe 
> something along cpuHasSse2Support() or alike. Yes, I know it's just details, 
> but helps while looking at the code.

I think we might have covered this in the past reviews, but in any
case I think that would be very confusing, because on non-i386 such
cpuHasSse2Support() function would need to return true, which is very
much not correct. :) I've left it as is, but reworked the text message
handling so that it's also generic now. Hope that qualms your concerns.

Actually, I didn't like that either, and reworked it even further (v2),
but I've not build tested that one yet.

Attached both updated patches, for which I've only built tested the first
one for now, but I'd not expect any run-time problems. But I'll try to do
that for the second one tomorrow.

Thanks,
Guillem
From 8020224f94ff24b6bafd59613427ed91bf8c341e Mon Sep 17 00:00:00 2001
From: Guillem Jover 
Date: Mon, 12 Oct 2015 01:45:37 +0200
Subject: [PATCH] Do not make lack of SSE2 support on x86-32 fatal

When an x86-32 CPU does not have SSE2 support (which is the case for
all AMD CPUs, and older Intel CPUs), fallback to use the interpreter,
otherwise use the JIT engine.

Even then, make the lack of SSE2 support on x86-32 fatal when trying
to instantiate a JIT engine, which does require it.

Refactor the required CPU support check and text into a new pair of
privately exported functions to avoid duplicating the logic, and do
so in functions instead of class members to avoid changing the class
signatures.

Version: 5.7.x
Bug-Debian: https://bugs.debian.org/792594
---
 src/qml/jit/qv4isel_masm.cpp|  3 +++
 src/qml/jit/qv4isel_masm_p.h| 19 +++
 src/qml/jsruntime/qv4engine.cpp |  1 +
 src/qml/qml/v8/qv8engine.cpp|  7 ---
 tools/qmljs/qmljs.cpp   |  7 +++
 5 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/src/qml/jit/qv4isel_masm.cpp b/src/qml/jit/qv4isel_masm.cpp
index d047623ac..5be02998e 100644
--- a/src/qml/jit/qv4isel_masm.cpp
+++ b/src/qml/jit/qv4isel_masm.cpp
@@ -265,6 +265,9 @@ InstructionSelection::InstructionSelection(QQmlEnginePrivate *qmlEngine, QV4::Ex
 , compilationUnit(new CompilationUnit)
 , qmlEngine(qmlEngine)
 {
+if (!hasRequiredCpuSupport())
+qFatal("This program requires %s", getRequiredCpuSupportText());
+
 compilationUnit->codeRefs.resize(module->functions.size());
 }
 
diff --git a/src/qml/jit/qv4isel_masm_p.h b/src/qml/jit/qv4isel_masm_p.h
index 1e6ac1f51..0f48f9c01 100644
--- a/src/qml/jit/qv4isel_masm_p.h
+++ b/src/qml/jit/qv4isel_masm_p.h
@@ -59,6 +59,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -71,6 +72,24 @@ QT_BEGIN_NAMESPACE
 namespace QV4 {
 namespace JIT {
 
+Q_QML_PRIVATE_EXPORT inline bool hasRequiredCpuSupport()
+{
+#ifdef Q_PROCESSOR_X86_32
+return qCpuHasFeature(SSE2);
+#else
+return true;
+#endif
+}
+
+Q_QML_PRIVATE_EXPORT inline const char *getRequiredCpuSupportText()
+{
+#ifdef Q_PROCESSOR_X86_32
+return "an X86 processor that supports SSE2 extension, at least a Pentium 4 or newer";
+#else
+return "no specific processor features, something strange happened";
+#endif
+}
+
 class Q_QML_EXPORT InstructionSelection:
 protected IR::IRDecoder,
 public EvalInstructionSelection
diff --git a/src/qml/jsruntime/qv4engine.cpp b/src/qml/jsruntime/qv4engine.cpp
index 26f473a7a..5e4100ac0 100644
--- a/src/qml/jsruntime/qv4engine.cpp
+++ b/src/qml/jsruntime/qv4engine.cpp
@@ -162,6 +162,7 @@ ExecutionEngine::ExecutionEngine(EvalISelFactory *factory)
 
 #ifdef V4_ENABLE_JIT
 static const bool forceMoth = !qEnvironmentVariableIsEmpty("QV4_FORCE_INTERPRETER") ||
+  !JIT::hasRequiredCpuSupport() ||
   !OSAllocator::canAllocateExecutableMemory();
 if (forceMoth) {
 factory = new

Bug#459427: changelog vs. NEWS handling

Hello,

This is one issue I think would be nice to have resolved so will
add my personal opinion below

On Sun, Jan 06, 2008 at 02:55:00PM +0100, Peter Eisentraut wrote:
> Package: debian-policy
> Version: 3.7.3.0
> Severity: normal
> 
> There is some lack of clarity in the policy or perhaps some confusion among
> packagers and thence inconsistencies among packages regarding the handling of
> upstream changelog files. 

This ever growing inconsistency and confusion among packagers causes an
even bigger confusion among users. What can I as a user expect from
/usr/share/doc/package/changelog.gz ? Is it just random mumblings
because policy said the file had to be provided?

If that file is just going to be untrustworthy and potentially misleading
I better avoid opening it at all.

This is why I think /any/ resolution to this issue is important.

Ofcourse I have a personal favourite resolution, but as said /any/
resolution is better than prolonging the ongoing confusion.

> Policy says that upstream changelogs should be installed as
> /usr/share/doc/package/changelog.gz.  Many packages, however, come
> with two kinds of changelogs: a source-level list of changes directed at
> developers, often called ChangeLog in a GNU-type package, and a user-level 
> list
> of changes, sometimes called release notes, often in a file called NEWS in a
> GNU-type package.
> 
> Debian packages appear to handle this in different ways: Some take the policy
> literally and install the ChangeLog as /usr/share/doc/package/changelog.gz and
> then install NEWS as additional documentation in 
> /usr/share/doc/package/NEWS.gz
> or whatever the file is called in the particular case.  Sometimes the source
> package doesn't come with a useful changelog, so they install NEWS or the
> release notes as /usr/share/doc/package/changelog.gz; others would then not
> install a "changelog" and install /usr/share/doc/package/NEWS.gz or some other
> name instead.
> 
> This has two major problems: I think that installing a source-level change 
> list
> is hardly ever useful for a binary package.  Most users would probably rather
> read the release notes, but these are currently not be found at a uniform
> location.  The intent behind all this was probably to give the package user a
> list of user-level changes.  So in that sense most packages do a less than
> ideal job at the moment.

My personal opinion is that a changelog is something where every change
is guaranteed to be logged. (And that guarantee is basically just saying
that if it's ever noticed that a change was not logged, that's indeed a
bug.)
A NEWS file is something different to me in that it's a subset of the
changelog. Sometimes that subset might be equal to the entire changelog
set, but there's no guarantee that NEWS logs every change - rather the
opposite.

If someone hands me something and tells me it's a changelog then I want
to be able to trust the guarantee that nothing is hidden. The reason I
would be reading a changelog is often to try to figure out where a bug
might have sneaked in and that's often in the "uninteresting" changes.
If someone lied to me and gave me a censored changelog they're actively
wasting my time on misleading me.

I thus think a ChangeLog (or "source level changelog") should be
installed as changelog when available (and not when noone is available
or easily generatable).
When a NEWS (or "user level changelog") or similar is available that
should be installed as NEWS.

Additionally possibly clarify that when something is not available from
upstream people should *not* go out of their way to find something to
stuff in there. Many times I've heard that "policy says I have to"
when asking people why they're insisting on showing a bad lie down my
throut when they could have just left it out (because all
policy really said was just "...should ... if ...").

In other words, I support suggestion number 1 (with the extension of
standardizing the NEWS name along side changelog).

> 
> I can think of three possibilities to address this:
> 
> 1. Clarify the policy that a source-level changelog should be installed as
> /usr/share/doc/package/changelog.gz and user-level change lists/release notes
> should be installed as /usr/share/doc/package/NEWS.gz, whichever of these is
> available and deemed useful.  This has the advantage that it is
> backward-compatible with respect to the changelog handling, and it would allow
> users to find the release notes under the familiar name "NEWS".  It would also
> be somewhat consistent with the GNU names for these files and the handling of
> changelog.Debian vs. NEWS.Debian.
> 

My personal preference does thus not go to option number 2 (or 3), but I
would still rather see either of them being used explicitly than leaving
things at the current status quo. If option 2 or 3 is implemented
then atleast I can know that I should personally never care for
/usr/share/doc/package/changelog.gz again.

I also guess that the

Bug#849883: inconsistency while processing conflicts

2017-01-01 Thread Richard B. Kreckel

Package: synaptic
Version: 0.83+nmu1
Severity: normal

There is a reproducible inconsistency while processing conflicts in
synaptic. It appears to involve three packages, each of which conflicts
with and replaces the other two.

Using packages emacs25, emacs25-nox, and emacs25-lucid, here are steps
to reproduce:
0) Assuming package emacs25 and its dependencies are installed, start
synaptic.
1) Right-click emacs25-lucid -> mark for installation. Confirm removal
of emacs25 by clicking the 'Mark' button.
[Status: Package emacs25 is marked for removal, emacs25-lucid is marked
for installation.]
2) Right-click emacs25-nox -> mark for installation.
[Status: Package emacs25 is marked for removal, emacs25-lucid is marked
for installation.[
3) Right-click emacs25-lucid -> mark for installation. The box informs
about "additional required changes" to be installed: emacs25-nox. This
is, of course, where the nonsense begins. Confirm by clicking the 'Mark'
button.
[Status: Package emacs25 is marked for removal, emacs25-lucid and
emacs25-nox are both marked for *complete* removal.]

  -richy.
-- 
Richard B. Kreckel

Bug#791828: dput-ng: Please make coinstallable with dput

On 08-Jul-2015, Tobias Frost wrote:

> I'd love to use both dput and dput-ng without the need of installing
> the version I'd use next..

As discussed briefly in the thread from 2016-12, my counter-proposal
is that the two packages should ideally:

* Be alternative implementations of the same set of features, so that
  any features that people actually use should be implemented in each.

* Eventually converge so closely that they merge, and there is just
  one ‘dput’ that is the single obvious package to install.

> Thanks for consdering!

I look forward to working (gradually and carefully) with the ‘dput-ng’
maintainers to make this request redundant :-)

-- 
 \“You don't change the world by placidly finding your bliss — |
  `\you do it by focusing your discontent in productive ways.” |
_o__)   —Paul Z. Myers, 2011-08-31 |
Ben Finney 

signature.asc
Description: PGP signature

Bug#849265: [Adduser-devel] Bug#849265: adduser: Should not add users to the audio group

2017-01-01 Thread Afif Elghraoui

Hi,

على الأربعاء 28 كانون الأول 2016 ‫14:36، كتب Dan Keast:
> Hi Afif,
> 
> That sounds like a great idea to me.
> 
> It's a pretty trivial change, but I've attached a patch file if it's of
> any use to you.
> 

Thanks for the patch. Anyway, I've just gotten around to contacting the
udev maintainers:

http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2017-January/013683.html

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#849882: python-vobject: Should TimezoneComponent.prettyPrint() have default arguments?

2017-01-01 Thread Petter Reinholdtsen


Package: python-vobject
Version: 0.8.1c-4

Should the TimezoneComponent.prettyPrint() function use the same default
values as the equivalent function in other classes?  I discovered that
The method in TimezoneComponent have this prototype:

def prettyPrint(self, level, tabwidth):

While the base class Component have this prototype:

def prettyPrint(self, level = 0, tabwidth=3):

This made my code fail with this message:

  >
  Traceback (most recent call last):
File "/home/pere/bin/ical-split", line 119, in 
  print c.prettyPrint()
  TypeError: prettyPrint() takes exactly 3 arguments (1 given)

This code demonstrates the problem:

  import vobject
  icalstream = open(file)
  components = vobject.readComponents(icalstream, validate=True)
  cal = components.next()
  for c in cal.getChildren():
print c.prettyPrint()

-- 
Happy hacking
Petter Reinholdtsen

Bug#841171: linux-image-3.16.0-4-amd64: random hangs during systemd-udev-settle

On Sun, 2017-01-01 at 22:25 +0100, Lucas Nussbaum wrote:
> Control: tag -1 - moreinfo
> 
> Hi,
> 
> On 29/12/16 at 17:14 +, Ben Hutchings wrote:
> > It seems simple enough... can you try the attached patch?
> 
> I can confirm that the patch fixes the problem. Thanks!

I've queued this up, but it just missed the next point release.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names
taken.



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

Bug#849498: cme: Please allow "fixing" without restyling

2017-01-01 Thread Afif Elghraoui

Control: tag -1 + help

Hello,

على الأربعاء 28 كانون الأول 2016 ‫02:03، كتب Dominique Dumont:
> On Tuesday, 27 December 2016 13:51:28 CET you wrote:
>> For the case of team uploads (and maybe NMU's) where people like to use cme
>> to fix certain issues in debian/control, it would be helpful if calling cme
>> fix would *only* fix issues and not restyle it. 
> 
> I've tried such a way by bridging Config::Model with Augeas [1] [2]. But 
> supporting
> such a solution is too much work for the benefit. 
> 
> I may reconsider this if I get help hacking on Config::Model.
> 

I've added the 'help' tag to reflect this.

>> If the primary maintainer
>> is not using cme, the uploader would have to either not use cme in this
>> case or take care to commit only the necessary changes, which adds extra
>> work and disrupts the uploader's workflow. 
> 
> You forgot one option: ask the primary maintainer to accept once a
> re-ordering imposing by cme. This would minimize the impact of further
> changes done by cme. 
> 
> Mentioning that cme's style matches the ordering of parameters in Debian 
> policy may help convincing the primary maintainer.
> 

I am one such maintainer. While I can get used to a field ordering
different from that used by dh-make, my main problem is the way cme
organizes lists-- it removes trailing commas and doesn't use a constant
indentation level globally. Trying to maintain this isn't a one-time
fight with cme.

Thanks and regards
Afif

> 
> [1] http://augeas.net/docs/references/1.4.0/lenses/files/debctrl-aug.html
> [2] 
> http://search.cpan.org/dist/Config-Model-Backend-Augeas/lib/Config/Model/Backend/Augeas.pm
> 

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Bug#848840: Fixed by touch init.py

2017-01-01 Thread James Cameron

Caused by missing empty __init__.py file in
/usr/share/sugar/activities/Browse.activity/collabwrapper/

Python needs the empty file to mark the directory as a module.

(I did try to figure out how to propose this as a patch to VCS, but
after using gbp pq import/export the patches seemed a bit noisy;
perhaps there's a better way.)

-- 
James Cameron
http://quozl.netrek.org/

Bug#849881: Calibre will not start after installing Nvidia Radeon drivers.

2017-01-01 Thread Jonathan Hutchins


Package: calibre
Version: 2.55.0+dfsg-1~bpo8+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Since installing NVIDIA-Linux-x86-375.20, Calibre reports the following
error on
start:

$ calibre
Traceback (most recent call last):
  File "/usr/bin/calibre", line 20, in 
sys.exit(calibre())
  File "/usr/lib/calibre/calibre/gui_launch.py", line 62, in calibre
from calibre.gui2.main import main
  File "/usr/lib/calibre/calibre/gui2/__init__.py", line 8, in 
from PyQt5.QtWidgets import QStyle  # Gives a nicer error message than
import
from Qt
ImportError: /usr/lib/i386-linux-gnu/libGLX.so.0: undefined symbol:
__glDispatchForceUnpatch

Note that I had a similar (identical?) error with the stable package,
which I then upgraded to the backport.


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

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

Versions of packages calibre depends on:
pn  calibre-bin
ii  fonts-liberation   1.07.4-1
ii  imagemagick8:6.8.9.9-5+deb8u6
ii  libjs-mathjax  2.4-2
ii  poppler-utils  0.26.5-2+deb8u1
ii  python-apsw3.8.6-r1-1
ii  python-beautifulsoup   3.2.1-1
ii  python-chardet 2.3.0-1
ii  python-cherrypy3   3.5.0-1
ii  python-cssselect   0.9.1+git90c72b0-1
ii  python-cssutils0.9.10-1
ii  python-dateutil2.2-2
ii  python-dbus1.2.0-2+b3
ii  python-feedparser  5.1.3-3
ii  python-imaging 2.6.1-2+deb8u3
ii  python-lxml3.4.0-1
ii  python-markdown2.5.1-2
ii  python-mechanize   1:0.2.5-3
ii  python-netifaces   0.10.4-0.1
ii  python-pil 2.6.1-2+deb8u3
ii  python-pkg-resources   5.5.1-1
ii  python-pyparsing   2.0.3+dfsg1-1
ii  python-pyqt5   5.3.2+dfsg-3
ii  python-pyqt5.qtsvg 5.3.2+dfsg-3
ii  python-pyqt5.qtwebkit  5.3.2+dfsg-3
ii  python-routes  2.0-1
ii  python2.7  2.7.9-2+deb8u1
ii  xdg-utils  1.1.0~rc1+git20111210-7.4

Versions of packages calibre recommends:
ii  python-dnspython  1.12.0-1

calibre suggests no packages.

-- Configuration Files:
/etc/bash_completion.d/calibre ad99a9010e6d5c196b46ca11d965c012 [Errno 2]
No such
file or directory: u'/etc/bash_completion.d/calibre
ad99a9010e6d5c196b46ca11d965c012'

-- no debconf information

Bug#849880: lintian erroneously complains about spigot:test.sh

2017-01-01 Thread Ian Jackson

Package: lintian
Version: 2.5.49

The source package spigot_0.2016-12-18.g8372d450-1.dsc (currently in
testing/stretch) has what I think is a wrong lintian warning:

Spigot$ lintian spigot_0.2016-12-18.g8372d450-1.dsc
W: spigot source: missing-runtime-test-file ./test.sh paragraph
starting at line 1
Spigot$

But:

Spigot$ cd spigot
spigot$ cat debian/tests/control
Tests: test.sh
Tests-Directory: .
spigot$ ls -l test.sh
-rwxrwxr-x 1 ian ian 80094 Dec 18 19:57 test.sh*
spigot$

The package seems in order to me.  My invocation of autopkgtest liked
it, and as you can see here, it runs and passes in the Debian CI:
  https://ci.debian.net/packages/s/spigot/unstable/amd64/

Thanks,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#792607: spigot != spigot

2017-01-01 Thread Ian Jackson

Control: retitle -1 RFP: spigot.py -- Post to the Pump.io social network 
automatically from (RSS) feeds

spigot (the exact real calculator, named after the `spigot algorithm',
which it implements) is now in testing.

spigot (the Python pump.io client) is still waiting in hope for a
contributor.

As the Debian maintainer of spigot (the exact real calculator), I felt
that it was appropriate to claim the command name `spigot' for the
exact real calculator, because: the calculator is a command line
utility for interactive use; and, the pump.io client seems to expect
to be invoked by upstream as `spigot.py'.  After that the decision to
claim the package name `spigot' seemed to follow.

I did search for other spigot programs and commands and none seemed
likely to be troubled by /usr/bin/spigot being the exact real
calculator.

I'm not sure what the best package name for the Python pump.io client
is, but for now I am retitling this bug to request `spigot.py'.

For reference, I think pump.io is cool and I certainly don't want to
get in the way of better support for pump.io in Debian.  If I knew
more about pump.io and/or Python packaging I might even consider
packaging it.

As it is, the best I can do is offer to sponsor somehow who
understands these things more than I do.

Regards,
Ian.

-- 
Ian Jackson    These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#849827: live-build fails to build amd64 target

2017-01-01 Thread Michael .

And here goes the live-build community once more into a meltdown.

Peter, I haven't seen your name in many, if any, discussions before this so
take this from someone who has been a part of the user community for many
many years.
Your attitude and method of communication alienates yourself from people
wanting to take their time to help you. Live-build has, while I have been a
user, always been a volunteer community.
As users we file bug reports and make comments without fear or favour. Yes
there has been a few times where the response has seemed quite short but
this is the internet and reading tone into replies is a dangerous thing. It
is the words used that matter and injecting tone is something the reader
does not the writer. The words you have used are pre-empting a stern reply
by suggesting you will get a brush off rather than any help, what a great
way to make friends and influence people.

In other words please don't come here telling this community we are doing
it all wrong if you are not in any way shape or form willing to offer
assistance.
Just my $0.02 in reply to yours.

On 2 January 2017 at 09:09, Ben Armstrong 
wrote:

> On January 1, 2017 4:47:39 PM "Peter.Stein" 
> wrote:
>
> > I actually had a bunch of comments, but suspected they would not be well
> > received
>
> Try us.
>
> >
>
> and thus tried to be diplomatic
>
> I must have missed that. ;)
>
> >
>
> and productive by suggesting a
> > step-by-step HOWTO. It's needed, everyone knows what one is, and
> > shouldn't be difficult to put together by the live-build experts. You
> > wanted an improvement suggestion and I gave you a very "actionable" one.
>
> I know how many hundreds of hours of my personal time went into the
> original document before I called it quits and doubt your assessment of the
> ease of replacing the current doc. Since it's "incomprehensible", it seems
> it all needs to be replaced from scratch ... or was that hyperbole, perhaps?
>
>
> > I'm always reluctant to get into these "improvement" discussions because
> > the fact of the matter is you open source folks don't take constructive
> > criticism very well and invariably end up copping an attitude - like you
> > are now. I've developed software professionally for 35 years and can
> > state unequivocally that this documentation does not meet the
> > "production grade" standard.
>
> I am not "you open source folks". I'm a person with feelings, not a bundle
> of stereotypes. I'm particularly not impressed by you "pulling rank" by
> trotting out your "senior developer" status when I haven't seen a single
> line of code or sentence of doc contributed by you to this project. Show me
> the code (or doc).
>
> >
>
> I hear what you're saying about limited
> > resources and community efforts, but as the old saying goes "the road to
> > hell is paved with good intentions". At some point somewhat needs to
> > step back, take a deep breath, and do an honest assessment to determine
> > what if any improvements are needed.
>
> I was that someone. I did that assessment, and this is what, within a
> reasonable amount of time, I managed to accomplish to cut through the
> information-dense manual and try to guide any new user through getting
> oriented. I hope you've read it and tried at least this "crash course"
> outline. If you did, please tell me what you thought of it:
>
> https://debian-live.alioth.debian.org/live-manual/stable/
> manual/html/live-manual.en.html#8
>
> I know it's just a small thing, but it's what time and energy allowed in
> lieu of a more ambitious total rewrite, which I was painfully aware was
> needed, but lacked the resources to carry out.
>
> But that day has come and gone. What's left of the  team is just keeping
> this doc, and live-build itself on life support. The main thrust of
> development is now in live-wrapper. So my honest assessment is: live-manual
> is imperfect, but it's the doc we have. If it falls short of your
> expectations, it falls on you, the users who still care about it, to make
> it better, because it's not likely anyone else will. That's not "copping an
> attitude". That's just giving you my experienced opinion on the state of
> things.
>
> >
>
> Griping from the user community
> > should not be the impetus for change. That's my $.02. ;-)
>
> So if you truly believe that, switch from griping to contributing!
>
> Ben
>

Bug#849627: RFS: xtrkcad/1:4.2.4a-1 ITA

2017-01-01 Thread Jörg Frings-Fürst

tags 84927 - moreinfo
thanks


Hello Sean,


Am Sonntag, den 01.01.2017, 20:43 + schrieb Sean Whitton:
> [Jörg's address bounced from my MTA so re-sending to -submitter; sorry
> for noise]
I look tomorrow morning why your mail was bounced.

> 
> Hello Jörg,
> 
> On Sun, Jan 01, 2017 at 04:06:33PM +0100, Jörg Frings-Fürst wrote:
> > Am Freitag, den 30.12.2016, 19:36 + schrieb Gianfranco Costamagna:
> > > did you also merge the debian improvements from Mike?
> > 
> > some yes, some on a other way and some not yet.
> > 
> > I use dh instead of cdbs and I'm working without get-orig-source.
> > Compat level is 10 instead of 9.
> 
> Fine.
> 
> > Debian/copyright is completely rewritten, but I can't check against
> > Mikes version.
> 
> It's fine so long as it is accurate (though unfortunate that work was
> duplicated).
> 
> > On the todo list is the split into two packages. With Sean is agreed
> > that to make after the freeze.
> 
> I was wrong about this.  We can upload to binNEW until the end of
> January.  So how about doing the package split now?  Your choice,
> depending on time available.

Sorry that I misinterpret this:

[quote]
In the future, after the stretch freeze, consider a package split:

I: xtrkcad: arch-dep-package-has-big-usr-share 16352kB 92%
[/quote]

Next week I have a lot of work. So I do the split this evening.

XtrkCad is split into xtrkcad and xtrkcad-common.

Build with

 * sbuild --no-arch-all
 * sbuild --no-arch-any

are ok.


> 

CU
Jörg

-- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema: SYR8SJXB

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.


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

Bug#849879: jupyter-nbextension-jupyter-js-widgets: fails to remove (python error)

2017-01-01 Thread alberto

Package: jupyter-nbextension-jupyter-js-widgets
Version: 5.2.2-2
Severity: minor

Dear Maintainer,

I recently installed notebook and some related packages but had problems.
Then I decided to purge all the packages but
jupyter-nbextension-jupyter-js-widgets
fails with the fillowing error message:

(Reading database ... 605526 files and directories currently installed.)
Removing jupyter-nbextension-jupyter-js-widgets (5.2.2-2) ...
/usr/lib/python3.5/runpy.py:125: RuntimeWarning: 'notebook.nbextensions' found 
in sys.modules after import of package 'notebook', but prior to execution of 
'notebook.nbextensions'; this may result in unpredictable behaviour
  warn(RuntimeWarning(msg))
Disabling notebook extension jupyter-js-widgets/extension...
Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 1176, in 

main()
  File "/usr/lib/python3/dist-packages/jupyter_core/application.py", line 267, 
in launch_instance
return super(JupyterApp, cls).launch_instance(argv=argv, **kwargs)
  File "/usr/lib/python3/dist-packages/traitlets/config/application.py", line 
658, in launch_instance
app.start()
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 961, in 
start
super(NBExtensionApp, self).start()
  File "/usr/lib/python3/dist-packages/jupyter_core/application.py", line 256, 
in start
self.subapp.start()
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 871, in 
start
self.toggle_nbextension(self.extra_args[0])
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 861, in 
toggle_nbextension
logger=self.log)
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 434, in 
disable_nbextension
logger=logger)
  File "/usr/lib/python3/dist-packages/notebook/nbextensions.py", line 345, in 
_set_nbextension_state
cm.update(section, {"load_extensions": {require: state}})
  File "/usr/lib/python3/dist-packages/traitlets/config/manager.py", line 85, 
in update
data = self.get(section_name)
  File "/usr/lib/python3/dist-packages/traitlets/config/manager.py", line 63, 
in get
return json.load(f)
  File "/usr/lib/python3.5/json/__init__.py", line 268, in load
parse_constant=parse_constant, object_pairs_hook=object_pairs_hook, **kw)
  File "/usr/lib/python3.5/json/__init__.py", line 319, in loads
return _default_decoder.decode(s)
  File "/usr/lib/python3.5/json/decoder.py", line 339, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
  File "/usr/lib/python3.5/json/decoder.py", line 357, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
dpkg: error processing package jupyter-nbextension-jupyter-js-widgets 
(--remove):
 subprocess installed pre-removal script returned error exit status 1
Errors were encountered while processing:
 jupyter-nbextension-jupyter-js-widgets


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

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

Versions of packages jupyter-nbextension-jupyter-js-widgets depends on:
ii  python2.7.13-1
ii  python-notebook   4.2.3-3
ii  python3   3.5.1-4
ii  python3-notebook  4.2.3-3

jupyter-nbextension-jupyter-js-widgets recommends no packages.

Versions of packages jupyter-nbextension-jupyter-js-widgets suggests:
ii  python-ipywidgets   5.2.2-2
ii  python3-ipywidgets  5.2.2-2

-- no debconf information

Bug#849531: [Logwatch-devel] Bug#849531: Possible security problem, new logwatch sends mails with charset UTF-8

2017-01-01 Thread Mike Tremaine


> 
> The fail-safe default before was ISO-8859-1. So I suggest to use it
> again.
> 


If stream converted output it s require please consider making it a 
configurable module in the code base that can be turned on and off and modified 
(the module) as needed. Leave the default as is, that way DESTRO’s and users 
can configure to their liking. But it will work as intended all the way back to 
the stone-age tools that we started this project with. (I’m looking at you 
Solaris 7/8)


-Mike

Bug#849827: live-build fails to build amd64 target

2017-01-01 Thread Ben Armstrong

On January 1, 2017 4:47:39 PM "Peter.Stein" wrote:

I actually had a bunch of comments, but suspected they would not be well
received

Try us.

and thus tried to be diplomatic

I must have missed that. ;)

and productive by suggesting a
step-by-step HOWTO. It's needed, everyone knows what one is, and
shouldn't be difficult to put together by the live-build experts. You
wanted an improvement suggestion and I gave you a very "actionable" one.

I know how many hundreds of hours of my personal time went into the
original document before I called it quits and doubt your assessment of the
ease of replacing the current doc. Since it's "incomprehensible", it seems
it all needs to be replaced from scratch ... or was that hyperbole, perhaps?

I'm always reluctant to get into these "improvement" discussions because
the fact of the matter is you open source folks don't take constructive
criticism very well and invariably end up copping an attitude - like you
are now. I've developed software professionally for 35 years and can
state unequivocally that this documentation does not meet the
"production grade" standard.

I am not "you open source folks". I'm a person with feelings, not a bundle
of stereotypes. I'm particularly not impressed by you "pulling rank" by
trotting out your "senior developer" status when I haven't seen a single
line of code or sentence of doc contributed by you to this project. Show me
the code (or doc).

I hear what you're saying about limited
resources and community efforts, but as the old saying goes "the road to
hell is paved with good intentions". At some point somewhat needs to
step back, take a deep breath, and do an honest assessment to determine
what if any improvements are needed.

I was that someone. I did that assessment, and this is what, within a
reasonable amount of time, I managed to accomplish to cut through the
information-dense manual and try to guide any new user through getting
oriented. I hope you've read it and tried at least this "crash course"
outline. If you did, please tell me what you thought of it:

https://debian-live.alioth.debian.org/live-manual/stable/manual/html/live-manual.en.html#8

I know it's just a small thing, but it's what time and energy allowed in
lieu of a more ambitious total rewrite, which I was painfully aware was
needed, but lacked the resources to carry out.

But that day has come and gone. What's left of the team is just keeping
this doc, and live-build itself on life support. The main thrust of
development is now in live-wrapper. So my honest assessment is: live-manual
is imperfect, but it's the doc we have. If it falls short of your
expectations, it falls on you, the users who still care about it, to make
it better, because it's not likely anyone else will. That's not "copping an
attitude". That's just giving you my experienced opinion on the state of
things.

Griping from the user community
should not be the impetus for change. That's my $.02. ;-)

So if you truly believe that, switch from griping to contributing!

Ben

Bug#849691: RFS: gnome-shell-extension-radio/1.4-1 [ITP] -- GNOME shell extension for listening to Internet radio streams

2017-01-01 Thread leo


Hi,

Le 2017-01-01 21:31, Andreas Henriksson a écrit :

Hello Leo,

On Thu, Dec 29, 2016 at 09:22:23PM +0100, l...@ndrs.fr wrote:

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package 
"gnome-shell-extension-radio",

[...]

Thanks for your interest in debian packaging.

[...]

Everything is ready except a few contributors informations missing in
`debian/copyright` but I hope it'll to be fixed soon, see [4].


Please note that not all contributors may be copyright holders.



I'm not really versed in copyright/license things, so I just added each 
contributor as a copyright holder... I'm going to read about it and find 
how to do this properly.



If actual copyright holders are missing from debian/copyright that's
likely a blocking issue though, as your package likely won't pass
through the initial NEW review done by ftp-masters.



Indeed, I knew about this. I just found the email of the two missing 
copyright holders (I'm not sure they're actually, they're contributor) 
and asked them, waiting for an answer.



(You seem to have put work into your debian/copyright and thanks for
doing so. Having copyright and licensing information in order
is great help for getting the package accepted and shipped in
the Debian archive.)



This is my first Debian package, sorry if I'm doing something wrong...


Your package seems mostly fine.



Glad to here it. :)


I'm not sure why you're overriding the build target in your
debian/rules though rather than using override_dh_auto_build:.



It was due to some environment variables set somewhere, when running 
`debuild` the package didn't build. Strange things is that running 
`dpkg-buildpackage` worked. I asked on #debian-mentors but didn't get a 
clear explanation. But, overriding the build target fixed the problem 
with `debuild`. I guess I'm missing something here, will try to see 
what's wrong.



My main issue though is how to build from the VCS you refer us to?


In fact, I used [1] as a template (found it here: [2]) ; I'm not sure 
about what I should provide, how and where...



Please document the procedure for working with your source in
debian/README.source when you use anything non-standard by choice.


Will do.


(Anything that's not building via a pure dpkg-buildpackage or
gbp buildpackage invocation would count in my book as being
non-standard.  Please note that with gbp you can just ship
debian/gbp.conf to make it 'just work'. Having all people who
potentially want to build from source jump through hoops is not a good
recipe for scalability.)



I see. I tried using gbp with no success. Will give it another try.


I have thus not actually tried to build your package.
Given I've not built it I also can not upload it (and this can't
even be considered a complete review of it).



I received a few comments from folks on #debian-mentors, one of them 
tried to build it and spotted a few problems. Thanks for your remarks. 
Should I ping you once I've fixed all those things ?




[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849522
[2] http://213.246.39.125/~leo/packaging/gnome-shell-extension-radio/
[3] 
https://gitlab.com/zapashcanon/gnome-shell-extension-radio-packaging/tree/master/debian

[4] https://github.com/hslbck/gnome-shell-extension-radio/issues/43


Regards,
Andreas Henriksson


[1] 
https://gitlab.com/highvoltage/gnome-shell-extension-dashtodock-packaging/tree/master
[2] 
https://packages.qa.debian.org/g/gnome-shell-extension-dashtodock.html


Cheers,

--

Léo Andrès

Bug#849878: RFP: zsh-completions -- Additional completion definitions for zsh

2017-01-01 Thread shirish शिरीष

Package: wnpp
Severity: wishlist

* Package name: zsh-completions
  Version : 0.22
  Upstream Author : Multiple authors
* URL : https://github.com/zsh-users/zsh-completions/
* License : Multiple but mostly Apache v2,MIT / X, MIT / BSD
variant 3-clause BSD
  Programming Lang: Zsh
  Description : Additional completion definitions for zsh

This projects aims at gathering/developing new completion scripts that
are not available in Zsh yet.

It would be useful as zsh users would everything under one roof.

-- 
  Regards,
  Shirish Agarwal  शिरीष अग्रवाल
  My quotes in this email licensed under CC 3.0
http://creativecommons.org/licenses/by-nc/3.0/
http://flossexperiences.wordpress.com
EB80 462B 08E1 A0DE A73A  2C2F 9F3D C7A4 E1C4 D2D8

Bug#837167: RFS: aiscm/0.6.2-2

2017-01-01 Thread Jan Wedekind


On Sun, 1 Jan 2017, Andrey Rahmatullin wrote:


You have

override_dh_makeshlibs:
   # NOOP to prevent debuild from invoking ldconfig

Debuild doesn't invoke ldconfig. If it's done to avoid adding an ldconfig
trigger you should explain that and explain why it is added because it's
not clear why do you need manual actions here.

--
WBR, wRAR



Ok, I have changed the documentation as follows:

override_dh_makeshlibs:
# NOOP to prevent debuild from adding an ldconfig trigger.
# aiscm does not install shared libraries in the library path,
# it merely installs native extensions to be loaded by the Guile 
interpreter.

The extension builds shared libraries but does not install them in the 
library path.

Bug#849422: fvwm: the module list in the fvwm(1) is obsolete

2017-01-01 Thread Jaimos Skriletz

On Tue, 27 Dec 2016 00:46:42 +0100 Vincent Lefevre  wrote:
> Package: fvwm
> Version: 1:2.6.7-2
> Severity: minor
>
> The fvwm(1) man page still mentions FvwmWinList, which no longer
> exists.
>
> Other removed modules may be in the same case. I haven't checked.

I fixed this by removing mention of obsolete modules from the
manpage(s) and the patch was accepted upstream.

This will be fixed in my next upload.

Thanks

jaimos

Bug#849423: fvwm: the FvwmDebug module is missing

2017-01-01 Thread Jaimos Skriletz

On Tue, 27 Dec 2016 00:49:49 +0100 Vincent Lefevre  wrote:
> Package: fvwm
> Version: 1:2.6.7-2
> Severity: normal
>
> The FvwmDebug module is missing, while it was present in 2.6.5,
> and it isn't announced as removed like other modules.
> /usr/share/doc/fvwm/changelog.gz just contains about them:
>

Thank you for pointing this out.

I am unsure if it is proper for me to be patching the upstream
changlog and upstream responded it is not going to change their
changelog (NEWS file).

I have added this module to the list of modules in
/usr/share/doc/fvwm/changelog.Debian.gz. It will be fixed with the
next package upload.

Unsure if I will edit the upstream changelog, but will close the bug
with the next upload and include this module listed in the
changelog.Debian which also lists all removed modules, so it will at
least be documented in the Debian package.

Thanks again for pointing this out.

jaimos

Bug#849794: qtwebengine-opensource-src: FTBFS on buildd machines

2017-01-01 Thread Sandro Knauß

Hey,

> (temporarily not raising this bug to RC-level to allow initial testing
> migration)

thanks for that :)

> This package could not be built on (any) official buildd machine other than
> amd64 (which was a binary upload). This problem needs to be solved sooner or
> later.
>
> I tried to build it on my own x86_64 VPS (1GB mem + 4GB swap) and it is
> still experiencing FTBFS (OOM?).

well that is too less :) I think you need at least 8G RAM + 8G disk space. Yes 
it is that huge :)

> The root of FTBFS seems different on different architectures:

I already started to write mails to failing archs to get ideas, to get input 
on how to fix those issues.

https://lists.alioth.debian.org/pipermail/pkg-kde-talk/2016-December/
002455.html

At this thread some ideas pop up, that may help. If you have any additional 
ideas how to fix the problems, feel free to post those. I have very less 
experience in other platforms that amd64/i386 so open for input :)

Best Regards,

sandro

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

Bug#849827: live-build fails to build amd64 target

2017-01-01 Thread Ozi Traveller

Hi Peter

I use live-build to create my isos and I have a small explanation of what I
do here:
https://sourceforge.net/projects/linnix/files/

I'm not suggesting that you use what I have created, but it might help fill
in some of the blanks in the documentation.

I found the documentation very difficult to understand. I always hoped that
they might create some worked examples, as I found the small examples in
the docs too small to connect all the dots to get what I wanted.

Cheers



On Mon, Jan 2, 2017 at 7:47 AM, Peter.Stein  wrote:

> I actually had a bunch of comments, but suspected they would not be well
> received and thus tried to be diplomatic and productive by suggesting a
> step-by-step HOWTO. It's needed, everyone knows what one is, and shouldn't
> be difficult to put together by the live-build experts. You wanted an
> improvement suggestion and I gave you a very "actionable" one. I'm always
> reluctant to get into these "improvement" discussions because the fact of
> the matter is you open source folks don't take constructive criticism very
> well and invariably end up copping an attitude - like you are now. I've
> developed software professionally for 35 years and can state unequivocally
> that this documentation does not meet the "production grade" standard. I
> hear what you're saying about limited resources and community efforts, but
> as the old saying goes "the road to hell is paved with good intentions". At
> some point somewhat needs to step back, take a deep breath, and do an
> honest assessment to determine what if any improvements are needed. Griping
> from the user community should not be the impetus for change. That's my
> $.02. ;-)
> Cheers.
>
> On 01/01/17 13:09, Ben Armstrong wrote:
>
> On January 1, 2017 2:26:58 PM "Peter.Stein" 
>  wrote:
>
> > I eventually figured out by trial and error how to get the iso to build.
> > Not because of the documentation, but in spite of it. The resulting iso
> > won't boot via GRUB2, but that's a GRUB issue not a live-build issue.
> > HOWTOs are commonplace in the linux world. That's an obvious way to
> > improve the body of documentation for live-build.
>
>
>
> Each chapter of live-manual covers "how to" customize different aspects of
> live-build. The section on local package lists, which is the closest
> equivalent to the old command-line option, is here:
>
> https://debian-live.alioth.debian.org/live-manual/stable/
> manual/html/live-manual.en.html#409
>
> I'll be the first to admit that this documentation is not perfect: a
> documentation writer's job is never done and there's always room for
> improvement, but so far you have not made any actionable suggestions for
> making it better. Unfortunately, we're at an impasse. We cannot make the
> doc any better if you won't tell us, specifically, what about it didn't
> work for you.
>
> Ben
> p.s. Although I contributed to the authorship of this doc considerably
> before my retirement, it was a group effort, all done by volunteers like
> me, so credit for its good bits goes to the whole group. I'm sure you
> understand that group authorship can sometimes lack the coherence of
> single-authored documents, but we had a lot of material to cover, and
> worked with what meagre resources we had. I doubt if any of the remaining
> team is interested in this point at a complete rewrite (though really,
> that's entirely up to them,) so it will have to be incremental
> improvements. Your cavalier dismissal of the whole work of the doc as
> "incomprehensible" coupled with your refusal to give us anything concrete
> to work with to improve it disinclines me to help anymore. Good luck.
>
>
>

Bug#848287: python-testing.mysqld: (build-)depends on mysql-{client,server}

2017-01-01 Thread Emilio Pozuelo Monfort

On 01/01/17 17:30, Dominik George wrote:
> Hi,
> 
> I was able to identify the issue, but need help fixing it.
> 
> The problem is that the testing module uses the default root user of the
> newly created database, and it uses the UNIX socket, and that has
> peercred authentication by default in MariaDB.
> 
> I tried the following to disable peercred for the socket:
> 
> $ cat >init.sql
> USE mysql;
> UPDATE user SET plugin='' WHERE User='root';
> FLUSH PRIVILEGES;
> 
> $ mysqld … --initialize-insecure --init-file=init.sql
> 
> But it still does not allow connecting a non-root user as root through
> the UNIX socket.
> 
> Any help appreciated.

Cc'ing pkg-mysql-maint, maybe someone there can help.

Emilio

Bug#841171: linux-image-3.16.0-4-amd64: random hangs during systemd-udev-settle

2017-01-01 Thread Lucas Nussbaum

Control: tag -1 - moreinfo

Hi,

On 29/12/16 at 17:14 +, Ben Hutchings wrote:
> It seems simple enough... can you try the attached patch?

I can confirm that the patch fixes the problem. Thanks!

Lucas

Bug#849754: RFS: guerillabackup/0.0.0-1