Bug#833326: pulseaudio: Lenovo Ideapad 300 - volume of the internal microphone is very low

[Florent Mazzone]

Package: pulseaudio
Version: 9.0-1.1
Severity: normal

Dear Maintainer,

When using Skype, I've noticed that the volume of the internal microphone is
very low.

Configuring different volume levels for the two channels of the microphone
resolves the problem temporarily (for ex: left 0% right 100%). But as soon as a
software such as Skype tries to adapt the volume of the microphone, the volume
decreases again and the microphone becomes unusable.

Information about the configuration : http://www.alsa-
project.org/db/?f=42dbb27b8cefa74c1a6b837f7d80cd51523c5167

Sincerely,

Florent Mazzone



-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

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

Versions of packages pulseaudio depends on:
ii  adduser  3.115
ii  libasound2   1.1.1-2
ii  libasound2-plugins   1.1.1-1
ii  libc62.23-4
ii  libcap2  1:2.25-1
ii  libdbus-1-3  1.10.8-1
ii  libfftw3-single3 3.3.4-2+b1
ii  libgcc1  1:6.1.1-10
ii  libice6  2:1.0.9-1+b1
ii  libltdl7 2.4.6-0.1
ii  liborc-0.4-0 1:0.4.25-1
ii  libpulse09.0-1.1
ii  libsm6   2:1.2.2-1+b1
ii  libsndfile1  1.0.25-10
ii  libsoxr0 0.1.2-1
ii  libspeexdsp1 1.2~rc1.2-1
ii  libstdc++6   6.1.1-10
ii  libsystemd0  230-7
ii  libtdb1  1.3.9-1
ii  libudev1 230-7
ii  libwebrtc-audio-processing1  0.3-1
ii  libx11-6 2:1.6.3-1
ii  libx11-xcb1  2:1.6.3-1
ii  libxcb1  1.11.1-1
ii  libxtst6 2:1.2.2-1+b1
ii  lsb-base 9.20160629
ii  pulseaudio-utils 9.0-1.1

Versions of packages pulseaudio recommends:
ii  pulseaudio-module-udev  9.0-1.1
ii  pulseaudio-module-x11   9.0-1.1
ii  rtkit   0.11-4

Versions of packages pulseaudio suggests:
pn  paman
pn  paprefs  
ii  pavucontrol  3.0-3+b2
pn  pavumeter

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio is free software; you can redistribute it and/or modify
# it under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# PulseAudio is distributed in the hope that it will be useful, but
# WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; allow-module-loading = yes
; allow-exit = yes
; use-pid-file = yes
; system-instance = no
; local-server-type = user
; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB
; lock-memory = no
; cpu-limit = no

; high-priority = yes
; nice-level = -11

; realtime-scheduling = yes
; realtime-priority = 5

; exit-idle-time = 20
; scache-idle-time = 20

; dl-search-path = (depends on architectur

Bug#833327: xmldiff: maintainer address bounces

[Ansgar Burchardt]

Source: xmldiff
Version: 0.6.10-2
Severity: serious

[ Uploaders X-Debbugs-Cc'ed ]

The maintainer address for xmldiff bounces, see below.

Ansgar

Mail Delivery System  writes:
> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es) failed:
>
>   afayo...@debian.org
> Unrouteable address
>
> -- This is a copy of the message, including all the headers. --
>
[...]
> To: Alexandre Fayolle , John Paul Adrian Glaubitz 
> 
> X-DAK: dak process-upload
> X-Debian: DAK
> X-Debian-Package: xmldiff
> Precedence: bulk
> Auto-Submitted: auto-generated
> MIME-Version: 1.0
> Content-Type: text/plain; charset="utf-8"
> Content-Transfer-Encoding: 8bit
> Subject: xmldiff_0.6.10-2.2_amd64.changes ACCEPTED into unstable
> Message-Id: [...]
> Date: Wed, 03 Aug 2016 04:34:49 +
>
> Mapping sid to unstable.
>
> Accepted:
>
> Format: 1.8
> Date: Wed, 03 Aug 2016 05:59:29 +0200
> Source: xmldiff
> Binary: xmldiff xmldiff-xmlrev
> Architecture: source amd64 all
> Version: 0.6.10-2.2
> Distribution: sid
> Urgency: medium
> Maintainer: Alexandre Fayolle 
> Changed-By: John Paul Adrian Glaubitz 
> Description:
>  xmldiff- tree to tree correction between xml documents
>  xmldiff-xmlrev - xmldiff output formatter
> Closes: 822039
> Changes:
>  xmldiff (0.6.10-2.2) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* Add build-arch and build-indep targets to debian/rules to fix
>  FTBFS with newer versions of dpkg (Closes: #822039)
> Checksums-Sha1:
>  2f0f87aa9d1ad8190ea6073dc564e5ec718242b7 1981 xmldiff_0.6.10-2.2.dsc
>  c939c67aa97b2fd1d087308e6183674ac5fb5071 4404 xmldiff_0.6.10-2.2.diff.gz
>  562b85a2a148ea226f1a0b99a425cf76f274c8e1 11038 
> xmldiff-dbgsym_0.6.10-2.2_amd64.deb
>  d069ddb7d738dd9c14e14b882eb7b52ab2787b95 8646 
> xmldiff-xmlrev_0.6.10-2.2_all.deb
>  39246abfce47bec773312a488692ea6ce0e96968 43726 xmldiff_0.6.10-2.2_amd64.deb
> Checksums-Sha256:
>  04f1dba94436a7cd282acca063e697680d2c103633fea4f348183e2a481409dd 1981 
> xmldiff_0.6.10-2.2.dsc
>  5e404657e73eae4e67cfcfff23433a4d73f77034cf4c1461e0276e3193ab4b1f 4404 
> xmldiff_0.6.10-2.2.diff.gz
>  4675477b1a512f31e84880534c384bb5a794d7a0a10323d4b775d0b28bb351cf 11038 
> xmldiff-dbgsym_0.6.10-2.2_amd64.deb
>  6302573638935240ed56a8bf6d398331cfa57529a014432fa116d31ec4a00fe5 8646 
> xmldiff-xmlrev_0.6.10-2.2_all.deb
>  1e27b93b3ce05763dbe8e48eb3181436031d15cc22dab739164688d8a9b0a876 43726 
> xmldiff_0.6.10-2.2_amd64.deb
> Files:
>  5b2d7bb27c8910d25fafa327e9bbd9e2 1981 misc optional xmldiff_0.6.10-2.2.dsc
>  5356d53d2116dc3b7341c08510787368 4404 misc optional 
> xmldiff_0.6.10-2.2.diff.gz
>  6394766b9020e8039387fd8c3d140d2a 11038 debug extra 
> xmldiff-dbgsym_0.6.10-2.2_amd64.deb
>  851e76ecc29b2e570f3609b0de9e1234 8646 misc optional 
> xmldiff-xmlrev_0.6.10-2.2_all.deb
>  1b74a41206b3165d40cfab6df1b79a4d 43726 misc optional 
> xmldiff_0.6.10-2.2_amd64.deb
>
>
>
> Thank you for your contribution to Debian.

Bug#833296: exim4-config: dpkg-reconfigure exim4-config: misleading message

[Mauro Salvini]

> Hi,
> 
> thanks for your bug report. Superb research, well done.

Hi,

thank you, it's my first bug report, glad to hear that is well done :-)

> @ expands to primary_hostname. Are you manualy setting this in your
> configuration?

No, i never set this variable in my configuration.
/var/lib/exim4/config.autogenerated contains

.ifdef MAIN_HARDCODE_PRIMARY_HOSTNAME
primary_hostname = MAIN_HARDCODE_PRIMARY_HOSTNAME
.endif

and MAIN_HARDCODE_PRIMARY_HOSTNAME is never set.

About this, if during dpkg-reconfigure exim4-config I set "Keep number
of DNS queries minimal (Dial-on-Demand)" to yes,
MAIN_HARDCODE_PRIMARY_HOSTNAME becomes defined as myhost.mydomain.local,
and exim4 delivers mail in the right way.


> If uname() returns a single-component name, Exim calls gethostbyname()
> (or getipnodebyname() where available) in an attempt to acquire a
> fully qualified host name.
> 
> Can you check what your gethostbyname/getipnodebyname returns?

I wrote this code snippet (getipnodebyname() is not available in my
system):

#include 
#include 
#include 

int main()
{
struct utsname buf;
uname(&buf);
printf("hostname by uname(): %s\n", buf.nodename);

struct hostent *hent = gethostbyname(buf.nodename);
printf("hostname by gethostbyname(): %s\n", hent->h_name);

return 0;
}

It returns:

hostname by uname(): myhostname
hostname by gethostbyname(): myhostname.mydomain.local

> I guess that there is something not right with your /etc/hosts which
> misguides gethostbyname. I have never fully understood what to do with
> /etc/hosts if one does not have a static IP address, and since all my
> hosts do have static IP addresses, I have neve had a problem like that.
> 
> For starters, I'd try to add an entry with your full host name for
> the IP address your network interface actually has.

I tried with a /etc/hosts like this:

127.0.0.1 localhost
192.168.0.10 myhostname.mydomain.local myhostname

but behavior is the same.

(by the way: static IP address means manually-assigned IP address only
or also DHCP-assigned IP address that is always the same because is
based on a static map on DHCP server?)


I also tried "exim -bt -d+all username" on various scenarios:

- /etc/mailname set with FQDN, "Other destinations for which mail is
accepted" during dpkg-reconfigure set with FQDN, hostname set as
myhostname, it states:
08:53:19  3350 local_part=username domain=myhostname.mydomain.local
08:53:19  3350 checking domains
08:53:19  3350 myhostname.mydomain.local in
"@:localhost:myhostname.mydomain.local"? yes (matched
"myhostname.mydomain.local")

so it does not match "@"

- /etc/mailname set with FQDN, "Other destinations for which mail is
accepted" during dpkg-reconfigure leaved blank, hostname set as
myhostname.mydomain.local, it states:
08:56:56  3363 local_part=username domain=myhostname.mydomain.local
08:56:56  3363 checking domains
08:56:56  3363 myhostname.mydomain.local in "@:localhost"? yes (matched
"@")

so it right matches "@".

Thank you again, greetings

Mauro

Bug#833296: exim4-config: dpkg-reconfigure exim4-config: misleading message

[Marc Haber]

Hi Mauro,

On Wed, Aug 03, 2016 at 09:11:58AM +0200, Mauro Salvini wrote:
> > thanks for your bug report. Superb research, well done.
> 
> thank you, it's my first bug report, glad to hear that is well done :-)

Keep up the good work!

> > @ expands to primary_hostname. Are you manualy setting this in your
> > configuration?
> 
> No, i never set this variable in my configuration.
> /var/lib/exim4/config.autogenerated contains
> 
> .ifdef MAIN_HARDCODE_PRIMARY_HOSTNAME
> primary_hostname = MAIN_HARDCODE_PRIMARY_HOSTNAME
> .endif
> 
> and MAIN_HARDCODE_PRIMARY_HOSTNAME is never set.

Ok, that's the default behavior.

> About this, if during dpkg-reconfigure exim4-config I set "Keep number
> of DNS queries minimal (Dial-on-Demand)" to yes,
> MAIN_HARDCODE_PRIMARY_HOSTNAME becomes defined as myhost.mydomain.local,
> and exim4 delivers mail in the right way.

Yes, that's also how it's intended to work. Maybe this setting is best
for your setup.

> > If uname() returns a single-component name, Exim calls gethostbyname()
> > (or getipnodebyname() where available) in an attempt to acquire a
> > fully qualified host name.
> > 
> > Can you check what your gethostbyname/getipnodebyname returns?

> hostname by uname(): myhostname
> hostname by gethostbyname(): myhostname.mydomain.local

Hm.

What does hostname --fqdn say?

What does exim -bP | grep ^primary_hostname say?

> > I guess that there is something not right with your /etc/hosts which
> > misguides gethostbyname. I have never fully understood what to do with
> > /etc/hosts if one does not have a static IP address, and since all my
> > hosts do have static IP addresses, I have neve had a problem like that.
> > 
> > For starters, I'd try to add an entry with your full host name for
> > the IP address your network interface actually has.
> 
> I tried with a /etc/hosts like this:
> 
> 127.0.0.1 localhost
> 192.168.0.10 myhostname.mydomain.local myhostname
> 
> but behavior is the same.

and 192.168.0.10 is your local IP address on the network?

I do have the trivial 127.0.1.1 myhostname.zugschlus.de myhostname
line in my /etc/hosts and my exim does the right thing, like echo test
| mail root getting correctly qualified to m...@myhostname.zugschlus.de
and r...@myhostname.zugschlus.de.

Is your "myhostname.mydomain.local" the literal host name? If so, are
you actually using the .local TLD or is that just obfuscated? Please
consider using a different TLD as .local may cause interference with
avahi (the .local TLD is reserved for use with mDNS).

> (by the way: static IP address means manually-assigned IP address only
> or also DHCP-assigned IP address that is always the same because is
> based on a static map on DHCP server?)

I used the wrong word. I just meant having the actual IP address in
/etc/hosts instead of the 127.0.1.1 placeholder, but that's not the
problem since things work fine on my local system.

> - /etc/mailname set with FQDN, "Other destinations for which mail is
> accepted" during dpkg-reconfigure leaved blank, hostname set as
> myhostname.mydomain.local, it states:
> 08:56:56  3363 local_part=username domain=myhostname.mydomain.local
> 08:56:56  3363 checking domains
> 08:56:56  3363 myhostname.mydomain.local in "@:localhost"? yes (matched
> "@")
> 
> so it right matches "@"

I do have the FQDN set in /etc/mailname. See
https://wiki.debian.org/EtcMailName?highlight=%28mailname%29 for the
current (sad) state of /etc/mailname and its documentation in Debian.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#828976: closed by Benjamin Kaduk (Re: krb5kdc: segfault)

[BASTET Laurent (Administrateur de systèmes et réseaux au sein du groupe Infrastructure et Réseau) - SG/SPSSI/CPII/DOIP/IR/Infrastructure Bordeaux]

Hello,

Thanks very much for your reply !!! It works fine with:
kadmin.local: setstr laurent "[{""type"":""foo""}]"
kadmin.local: getstr laurent
otp: [{"type":"foo"}]

but not with:
kadmin.local: setstr laurent '[{"type":"foo"}]'
kadmin.local: getstr laurent
otp: '[{type:foo}]')

For information, the MIT documentation 
(https://web.mit.edu/kerberos/krb5-1.13/doc/admin/admin_commands/kadmin_local.html#set-string) 
uses:


set_string u...@foo.com otp [{"type":"hotp","username":"custom"}]


Thanks again !

Best regards

Laurent BASTET
Administrateur de systèmes et réseaux
CPII/DOIP/IR/Infrastructure Bordeaux
rue Pierre Ramond
CS 60013
33166 Saint Médard en Jalles
05.56.70.65.90


Le 03/08/2016 06:58, > Benjamin Kaduk (par Internet) a écrit :

On Tue, 2 Aug 2016, Benjamin Kaduk wrote:


I am not actually sure how to escape the quotes to get them through the SS
parser.  Probably the easiest way to get well-formed JSON as the string

Apparently doubled double quotes within a double-quote context will do the
escaping.

So:

setstr laurent otp "[{""type"":""foo""}]"

ought to do the trick as well, even on the older version.

-Ben

Bug#833328: openssl does not start on x86_64: version `OPENSSL_1.0.1s' not found

[Mihail Artamonov]

Package: openssl
Version: 1.0.1t-1+deb8u2
Severity: important

In Debian 8.5 , my openssl is unusable.


# dpkg -l | grep -i openssl
ii  libgnutls-openssl27:amd64  3.3.8-6+deb8u3  amd64
 GNU TLS library - OpenSSL wrapper
ii  openssl1.0.1t-1+deb8u2 amd64
 Secure Sockets Layer toolkit - cryptographic utility
# dpkg -l | grep -i libssl
ii  libssl1.0.0:amd64  1.0.2h-1~bpo8+1 amd64
 Secure Sockets Layer toolkit - shared libraries
# openssl -v
openssl: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0: version
`OPENSSL_1.0.1s' not found (required by openssl)
# ls -la /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
-rw-r--r-- 1 root root 2482112 Jul  3 13:47
/usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0


Linux ltrus1hapr1 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3
(2016-07-02) x86_64 GNU/Linux

Bug#833328: Please close or delete this issue.

[Mihail Artamonov]

Hello, this problem was solved. Thank you!

Bug#793837: This "accidentially" is a regression to former versions of the ntp package

[Christian Ehrhardt]

Hi,
I was checking a similar report to Ubuntu and found that by accident this
is a regression and not a feature request.

The former 4.2.6 as in Jessie totally ignored the -with-sntp=no which is in
d/rules.
Thereby sntp (the older bad one) was in Jessie (even if not intended).

Since 4.2.8 due to commit
commit dd3be096e78eb8d13da36caad215c9f5c009b11a
Author: 
Date: Sun Feb 20 20:23:00 2011 +

Attempt typical subpackage approach for libevent
sntp test cleanup

This changed, and now sntp is "really" not built.
Funny enough the manpage which was added as a debian patch is still
installed even with --with-sntp=no.

Also it was reported and I could confirm that ntpsweep which is provided by
the package is actually broken due to sntp being missing.

Jessie:
root@debian-jessie:~# dpkg -l ntp
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
ArchitectureDescription
+++--===-===-==
ii  ntp  1:4.2.6.p5+dfsg-7+deb8u amd64
  Network Time Protocol daemon and utility programs
root@debian-jessie:~# dpkg -L ntp | grep sntp
/usr/bin/sntp
/usr/share/man/man1/sntp.1.gz
root@debian-jessie:~# ntpsweep --host 0.debian.pool.ntp.org
Host st offset(s) version system
processor
+--+-+---++-
0.debian.pool.ntp.org ?



Sid:
dpkg -l ntp
Desired=Unknown/Install/Remove/Purge/Hold
|
Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version
ArchitectureDescription
+++--===-===-==
ii  ntp  1:4.2.8p8+dfsg-1amd64
  Network Time Protocol daemon and utility programs
root@debian-sid:~# dpkg -L ntp | grep sntp
/usr/share/man/man1/sntp.1.gz
root@debian-sid:~# ntpsweep --host 0.debian.pool.ntp.org
Host st offset(s) version system
processor
+--+-+---++-
Can't exec "sntp": No such file or directory at
/usr/share/ntp/lib/NTP/Util.pm line 133.
Could not start sntp: No such file or directory at /usr/bin/ntpsweep line
112.


-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#831211: ucommon: FTBFS with GCC 6: dh_makeshlibs: failing due to earlier errors

[Emilio Pozuelo Monfort]

On 03/08/16 02:02, Peter Colberg wrote:
> Dear Debian Release Team,
> 
> twinkle has been marked for autoremoval from testing on 2016-08-27 due
> to this FTBFS. Building ucommon with GCC 6 instead of GCC 5 yields
> slight differences in the list of visible symbols.
> 
> How should this bug be dealt with? Is it not simply a matter of
> waiting for GCC 6 to become default, uploading ucommon with an
> updated symbols file and an ABI bump (if needed), and submitting
> binNMUs for dependent packages?

Yes.

> If so, can this bug be downgraded to severity important until then?

No. Just ping the bug to restart the timer if that becomes necessary (e.g. that
date gets closer and GCC 6 is not the default yet).

Cheers,
Emilio

Bug#833329: Updating the python-scipy Uploaders list

[Mattia Rizzolo]

Source: python-scipy
Version: 0.17.0-1 0.17.1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Alexandre Fayolle  has retired, so can't work on
the python-scipy package anymore (at least with this address).

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#833332: mutagen: please update Homepage field

[Jakub Wilk]

Source: mutagen
Version: 1.33.2-1
Severity: minor

mutagen's Homepage field is , which 
says:


Moved to GitHub: https://github.com/quodlibet/mutagen

--
Jakub Wilk

Bug#833331: Updating the xmldiff Uploaders list

[Mattia Rizzolo]

Source: xmldiff
Version: 0.6.10-2.1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Alexandre Fayolle  has retired, so can't work on
the xmldiff package anymore (at least with this address).

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#833330: Updating the spyder Uploaders list

[Mattia Rizzolo]

Source: spyder
Version: 2.3.8+dfsg1-1
Severity: minor
User: m...@qa.debian.org
Usertags: mia-teammaint

Alexandre Fayolle  has retired, so can't work on
the spyder package anymore (at least with this address).

(If the person is listed as Maintainer, what we are asking is to please
step in as a new maintainer.)

Thanks.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#833333: [amarok] Crashes when playing any file

[Giovanni Mascellani]

Package: amarok
Version: 2.8.0-5
Severity: important

Hi.

Amarok starts correctly, but crashes as soon as I request playing any
track. Attached you can find the log obtained by launching from a
console "amarok --debug > amarok.log 2>&1". Unfortunately running amarok
under gdb doesn't give any good result (probably there are wrappers that
hide the fault). If you can give my hints on how to properly use gdb
with amarok, I can try to have a backtrace.

Thanks, Giovanni.


--- System information. ---
Architecture: amd64
Kernel:   Linux 4.0.0-1-amd64

Debian Release: stretch/sid
  500 unstablerepos.fds-team.de   500 unstable
ftp.ch.debian.org 1 experimentalftp.ch.debian.org
--- Package information. ---
Depends  (Version) | Installed
==-+-==
amarok-common  (= 2.8.0-5) | 2.8.0-5
amarok-utils   (= 2.8.0-5) | 2.8.0-5
kde-runtime(>> 4:4.10) | 4:16.04.2-2
libaio1(>= 0.3.93) | libavcodec57
   (>= 7:3.0)  |  OR libavcodec-extra57  (>= 7:3.0)
| libavformat57   (>= 7:3.0) | libavutil55
  (>= 7:3.0) | libc6(>=
2.17) | libcurl3-gnutls(>= 7.16.2) | libgcc1
(>= 1:3.0) | libgcrypt20 (>=
1.7.0) | libgdk-pixbuf2.0-0 (>= 2.22.0) |
libgl1-mesa-glx|  OR libgl1
   | libglib2.0-0   (>= 2.37.3)
| libgpod4-nogtk(>= 0.7.92)  |  OR libgpod4
 (>= 0.7.92) | libkcmutils4  (>=
4:4.8.4) | libkdecore5   (>= 4:4.8.4) | libkdeui5
(>= 4:4.9.98) | libkdewebkit5
(>= 4:4.8.4) | libkdnssd4(>= 4:4.8.4) |
libkfile4 (>= 4:4.8.4) | libkio5
  (>= 4:4.8.4) | libknewstuff3-4   (>= 4:4.8.4)
| liblastfm1  (>= 1.0.0) | libloudmouth1-0
  (>= 1.1.4) | libmtp9 (>=
1.1.0) | libmysqlclient18   | libofa0
 (>= 0.9.3) | libphonon4  (>=
4:4.7.0.0) | libplasma3(>= 4:4.8.4) | libqjson0
 (>= 0.7.1) | libqt4-dbus
(>= 4:4.6.1) | libqt4-network(>= 4:4.5.3) |
libqt4-opengl (>= 4:4.8.0) | libqt4-script
  (>= 4:4.5.3) | libqt4-sql(>= 4:4.5.3)
| libqt4-svg(>= 4:4.5.3) | libqt4-xml
(>= 4:4.5.3) | libqtcore4(>=
4:4.8.0) | libqtgui4 (>= 4:4.8.0) | libqtwebkit4
(>= 2.1.0~2011week13) | libsolid4
(>= 4:4.8.4) | libstdc++6(>= 5.2) |
libthreadweaver4  (>= 4:4.8.4) | libx11-6
   | libxml2 (>= 2.7.4)
| phonon | zlib1g
(>= 1:1.2.0) | libqtscript4-core
 | libqtscript4-gui   | libqtscript4-network
  | libqtscript4-xml
  | libqtscript4-sql   |
libqtscript4-uitools   | amarok-common
   (= 2.8.0-5) | 2.8.0-5
amarok-utils   (= 2.8.0-5) | 2.8.0-5
kde-runtime(>> 4:4.10) | 4:16.04.2-2
libaio1(>= 0.3.93) | libavcodec57
   (>= 7:3.0)  |  OR libavcodec-extra57  (>= 7:3.0)
| libavformat57   (>= 7:3.0) | libavutil55
  (>= 7:3.0) | libc6(>=
2.17) | libcurl3-gnutls(>= 7.16.2) | libgcc1
(>= 1:3.0) | libgcrypt20 (>=
1.7.0) | libgdk-pixbuf2.0-0 (>= 2.22.0) |
libgl1-mesa-glx|  OR libgl1
   | libglib2.0-0   (>= 2.37.3)
| libgpod4-nogtk(>= 0.7.92)  |  OR libgpod4
 (>= 0.7.92) | libkcmutils4  (>=
4:4.8.4) | libkdecore5   (>= 4:4.8.4) | libkdeui5
(>= 4:4.9.98) | libkdewebkit5
(>= 4:4.8.4) | libkdnssd4(>= 4:4.8.4) |
libkfile4 (>= 4:4.8.4) | libkio5
  (>= 4:4.8.4) | libknewstuff3-4   (>= 4:4.8.4)
| liblastfm1  (>= 1.0.0) | libloudmouth1-0
  (>= 1.1.4) | libmtp9 (>=
1.1.0) | libmysqlclient18   | libofa0
 (>= 0.9.3) | libphonon4  (>=
4:4.7.0.0) | libplasma3(>= 4:4.8.4) | libqjson0
 (>= 0.7.1

Bug#833334: prime-phylo: FTBFS with Boost >= 1.60

[Graham Inggs]

Source: prime-phylo
Version: 1.0.11-2
Severity: wishlist
Tags: experimental


Dear Maintainer

Prime-phylo FTBFS with boost 1.60 currently available in Experimental
with the following message:

/usr/include/boost/serialization/access.hpp:116:9: error: ‘struct
std::pair’ has no member named ‘serialize’
 t.serialize(ar, file_version);

Regards
Graham

Bug#833296: exim4-config: dpkg-reconfigure exim4-config: misleading message

[Mauro Salvini]

Hi Marc,

> > > If uname() returns a single-component name, Exim calls gethostbyname()
> > > (or getipnodebyname() where available) in an attempt to acquire a
> > > fully qualified host name.
> > > 
> > > Can you check what your gethostbyname/getipnodebyname returns?
> 
> > hostname by uname(): myhostname
> > hostname by gethostbyname(): myhostname.mydomain.local
> 
> Hm.
> 
> What does hostname --fqdn say?

It says myhostname.mydomain.local

> What does exim -bP | grep ^primary_hostname say?

It says myhostname

Checked /var/lib/exim4/config.autogenerated for primary_hostname:

.ifdef MAIN_HARDCODE_PRIMARY_HOSTNAME
primary_hostname = MAIN_HARDCODE_PRIMARY_HOSTNAME
.endif

MAIN_HARDCODE_PRIMARY_HOSTNAME never defined

> > > I guess that there is something not right with your /etc/hosts which
> > > misguides gethostbyname. I have never fully understood what to do with
> > > /etc/hosts if one does not have a static IP address, and since all my
> > > hosts do have static IP addresses, I have neve had a problem like that.
> > > 
> > > For starters, I'd try to add an entry with your full host name for
> > > the IP address your network interface actually has.
> > 
> > I tried with a /etc/hosts like this:
> > 
> > 127.0.0.1 localhost
> > 192.168.0.10 myhostname.mydomain.local myhostname
> > 
> > but behavior is the same.
> 
> and 192.168.0.10 is your local IP address on the network?

No , I obfuscate it, sorry. It actually is 10.0.xx.xx

> Is your "myhostname.mydomain.local" the literal host name? If so, are
> you actually using the .local TLD or is that just obfuscated? Please
> consider using a different TLD as .local may cause interference with
> avahi (the .local TLD is reserved for use with mDNS).

Yes, domain ends with .local (this name comes from IT&C office
configuration).

Just for a try, I changed /etc/hosts and /etc/mailname to have a .net
TLD:
- exim -bP | grep ^primary_hostname says
  myhostname
- exim -bt -d+all username says
  10:13:17  5455 local_part=username domain=myhostname.mydomain.net
  10:13:17  5455 checking domains
  10:13:17  5455 myhostname.mydomain.net in "@:localhost"? no (end of
list)

Thanks again

Greetings
Mauro

Bug#833181: libreoffice-draw: I/O general error when saving leads to defunct

[Rene Engelhard]

tag 833181 + moreinfo
thanks

Hi,

On Mon, Aug 01, 2016 at 04:46:40PM -0300, Ricardo Fabian Peliquero wrote:
> While trying to save an odg from lodraw, an error dialog pops-up. Error when 
> saving the document. General error. General input/output error. After that, 
> most of loffice menus and icons are grayed out, including the Exit menu item.

This can be almost everything, not enough info to tell. Have a gdb backtrace
and/or strace or so?

Does it happen always or just in specific circumstances?

> ps -a shows:
>  6824 pts/200:00:00 oosplash
>  6841 pts/200:00:01 soffice.bin
>  6842 pts/200:00:00 soffice.bin 

A dead soffice.bin. Nothing really telling...

> Please, consider revising. I could managed to downgrade to testing for the 
> last two weeks, but that is not of any help now.

?? You mean it's not new in 5.1.5 rc2 but appeared before 5.1.5 rc1 so
the migration of 5.1.5 made it moot? Why are you reporting against 5.1.5 rc2
then and not against the version you saw it in? :)

> I tried to upgrade to experimental, but aptitude won't allow this.

That should work, but nevermind, 5.2.0 will be in sid real soon now(tm)

Regards,

Rene

Bug#833334: prime-phylo: FTBFS with Boost >= 1.60

[Graham Inggs]

Control: tags -1 patch


The attached patch, applied in Ubuntu, fixes the FTBFS.
Description: Fix FTBFS with Boost 1.60
 Add serialization/utility include to prevent error:
 src/cxx/libraries/prime/MpiMCMC.cc:112:33:   required from here
 /usr/include/boost/serialization/access.hpp:116:9:
 error: ‘struct std::pair’ has no member named ‘serialize’
 t.serialize(ar, file_version);
Bug-Debian: https://bugs.debian.org/84
Author: Graham Inggs 
Last-Update: 2016-08-03
--- a/src/cxx/libraries/prime/MpiMCMC.hh
+++ b/src/cxx/libraries/prime/MpiMCMC.hh
@@ -10,6 +10,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 

Bug#831211: ucommon: FTBFS with GCC 6: dh_makeshlibs: failing due to earlier errors

[Julien Cristau]

On Wed, Aug  3, 2016 at 09:58:27 +0200, Emilio Pozuelo Monfort wrote:

> On 03/08/16 02:02, Peter Colberg wrote:
> > Dear Debian Release Team,
> > 
> > twinkle has been marked for autoremoval from testing on 2016-08-27 due
> > to this FTBFS. Building ucommon with GCC 6 instead of GCC 5 yields
> > slight differences in the list of visible symbols.
> > 
> > How should this bug be dealt with? Is it not simply a matter of
> > waiting for GCC 6 to become default, uploading ucommon with an
> > updated symbols file and an ABI bump (if needed), and submitting
> > binNMUs for dependent packages?
> 
> Yes.
> 
If binNMUs of dependent packages are necessary then something's gone
very wrong...

Cheers,
Julien

Bug#833335: namazu2-index-tools and namazu2: error when trying to install together

[Ralf Treinen]

Package: namazu2,namazu2-index-tools
Version: namazu2/2.0.21-15
Version: namazu2-index-tools/2.0.21-15
Severity: serious
User: trei...@debian.org
Usertags: edos-file-overwrite

Date: 2016-08-03
Architecture: amd64
Distribution: sid

Hi,

automatic installation tests of packages that share a file and at the
same time do not conflict by their package dependency relationships has
detected the following problem:


Preconfiguring packages ...
Selecting previously unselected package libfile-mmagic-perl.
(Reading database ... 10961 files and directories currently installed.)
Preparing to unpack .../libfile-mmagic-perl_1.30-1_all.deb ...
Unpacking libfile-mmagic-perl (1.30-1) ...
Selecting previously unselected package libnmz7.
Preparing to unpack .../libnmz7_2.0.21-15_amd64.deb ...
Unpacking libnmz7 (2.0.21-15) ...
Selecting previously unselected package namazu2-common.
Preparing to unpack .../namazu2-common_2.0.21-15_all.deb ...
Unpacking namazu2-common (2.0.21-15) ...
Selecting previously unselected package namazu2.
Preparing to unpack .../namazu2_2.0.21-15_amd64.deb ...
Unpacking namazu2 (2.0.21-15) ...
Selecting previously unselected package namazu2-index-tools.
Preparing to unpack .../namazu2-index-tools_2.0.21-15_all.deb ...
Unpacking namazu2-index-tools (2.0.21-15) ...
dpkg: error processing archive 
/var/cache/apt/archives/namazu2-index-tools_2.0.21-15_all.deb (--unpack):
 trying to overwrite '/usr/share/man/man1/mknmz.1.gz', which is also in package 
namazu2 2.0.21-15
Processing triggers for man-db (2.7.5-1) ...
Processing triggers for libc-bin (2.23-4) ...
Errors were encountered while processing:
 /var/cache/apt/archives/namazu2-index-tools_2.0.21-15_all.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)


This is a serious bug as it makes installation fail, and violates
sections 7.6.1 and 10.1 of the policy. An optimal solution would
consist in only one of the packages installing that file, and renaming
or removing the file in the other package. Depending on the
circumstances you might also consider Replace relations or file
diversions. If the conflicting situation cannot be resolved then, as a
last resort, the two packages have to declare a mutual
Conflict. Please take into account that Replaces, Conflicts and
diversions should only be used when packages provide different
implementations for the same functionality.

Here is a list of files that are known to be shared by both packages
(according to the Contents file for sid/amd64, which may be
slightly out of sync):

  /usr/share/man/man1/mknmz.1.gz

This bug has been filed against both packages. If you, the maintainers of
the two packages in question, have agreed on which of the packages will
resolve the problem please reassign the bug to that package. You may then
also register in the BTS that the other package is affected by the bug.

-Ralf.

PS: for more information about the detection of file overwrite errors
of this kind see http://qa.debian.org/dose/file-overwrites.html.

Bug#833336: needs update for new agreement URL (fixed upstream)

[Daniel Baumann]

Package: letsencrypt.sh
Version: 0.2.0-1
Severity: serious

Hi,

the LE agreement URL changed, letsencrypt.sh needs to be updated
accordingly, please cherry-pick:


https://github.com/lukas2511/letsencrypt.sh/commit/afabfff06e2dece1772ed788ac41ca0d297ab49b

otherwise new LE installations don't work and error out with:

+ Generating account key...
+ Registering account key with letsencrypt...
  + ERROR: An error occurred while sending post-request to
https://acme-v01.api.letsencrypt.org/acme/new-reg (Status 400)

Details:
{
  "type": "urn:acme:error:malformed",
  "detail": "Provided agreement URL
[https://letsencrypt.org/documents/LE-SA-v1.0.1-July-27-2015.pdf] does
not match current agreement URL
[https://letsencrypt.org/documents/LE-SA-v1.1.1-August-1-2016.pdf]";,
  "status": 400
}

Regards,
Daniel

Bug#833296: exim4-config: dpkg-reconfigure exim4-config: misleading message

[Marc Haber]

On Wed, Aug 03, 2016 at 10:26:57AM +0200, Mauro Salvini wrote:
> > > > If uname() returns a single-component name, Exim calls gethostbyname()
> > > > (or getipnodebyname() where available) in an attempt to acquire a
> > > > fully qualified host name.
> > > > 
> > > > Can you check what your gethostbyname/getipnodebyname returns?
> > 
> > > hostname by uname(): myhostname
> > > hostname by gethostbyname(): myhostname.mydomain.local
> > 
> > Hm.
> > 
> > What does hostname --fqdn say?
> 
> It says myhostname.mydomain.local

Good.

> > What does exim -bP | grep ^primary_hostname say?
> 
> It says myhostname

not good.

> Checked /var/lib/exim4/config.autogenerated for primary_hostname:
> 
> .ifdef MAIN_HARDCODE_PRIMARY_HOSTNAME
> primary_hostname = MAIN_HARDCODE_PRIMARY_HOSTNAME
> .endif
> 
> MAIN_HARDCODE_PRIMARY_HOSTNAME never defined

So primary_hostname is set according to the docs
(/usr/share/doc/exim4-base/spec.txt.gz):

$primary_hostname

This variable contains the value set by primary_hostname in the
configuration file, or read by the uname() function. If uname() returns a
single-component name, Exim calls gethostbyname() (or getipnodebyname()
where available) in an attempt to acquire a fully qualified host name. See
also $smtp_active_hostname.

The last sentence doesn't apply here. And we see that your
gethostbyname returns the host name just fine.

What does getent hosts $IP for all your IP addresses say?

> > and 192.168.0.10 is your local IP address on the network?
> 
> No , I obfuscate it, sorry. It actually is 10.0.xx.xx

Same thing, a RFC 1918 address that is unlikely to have correct
reverse DNS.

> > Is your "myhostname.mydomain.local" the literal host name? If so, are
> > you actually using the .local TLD or is that just obfuscated? Please
> > consider using a different TLD as .local may cause interference with
> > avahi (the .local TLD is reserved for use with mDNS).
> 
> Yes, domain ends with .local (this name comes from IT&C office
> configuration).
> 
> Just for a try, I changed /etc/hosts and /etc/mailname to have a .net
> TLD:
> - exim -bP | grep ^primary_hostname says
>   myhostname

Bad.

> - exim -bt -d+all username says
>   10:13:17  5455 local_part=username domain=myhostname.mydomain.net
>   10:13:17  5455 checking domains
>   10:13:17  5455 myhostname.mydomain.net in "@:localhost"? no (end of
> list)

Looks better, but why? Strangely, the process of qualifying the
address is not in the debug output, first thing I see of the username
is its already qualified form.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#830344: How should the TC help with a project roadmap?

[Philip Hands]

Hi,

I managed to make time to watch the video of the roadmap BoF, so
hopefully I'm now able to respond to more than the name "roadmap*.

Some notes regarding the BoF:

Consensus:

  It strikes me that where there is consensus, the process of getting it
  on the roadmap is not really needed, so then it's just a question of
  raising awareness across the project.  I think the TC has very little
  to contribute in such cases.

Conflicting goals:

  Unless it's clear that both goals will be done unless one of them is
  stopped, and they are going to be in conflict from the start, I think
  it's normally best to let them compete.  As long as each effort is
  aware of the other, then they can decide amongst themselves which is
  going to fail in the end.  It's completely possible that of the two
  efforts, one is clearly technically superior, but the other has more
  enthusiastic people involved -- how does one choose which to stop?

GR for the roadmap:

  If we need a centrally agreed list, then this seems like the best way
  to do it, since it makes sure that a) all developers will be made
  aware of the goals, and b) the ones that succeed have enough support
  that even those that might be tempted to resist a goal should be
  persuaded that many people want it to happen.

Late conflict:

  This is a very important point.  If we can come up with a way of
  avoiding this happening it would clearly be a benefit.

The "Let me help you do what you want team":

  That encapsulates what I think might be worthwhile out of this idea.
  It emphasises letting people do things if they happen to feel the urge.

So, the problem I see with getting the TC involved with this is process
is that it emphasises the aspect of somehow seeking permission before
proceeding.

We don't really have a shortage of ideas in Debian, but we do have a
shortage of effort to implement them.  If we can make it easier for
people to go ahead and explore their idea for improving Debian, that's
great.  If we can also help them avoid pitfalls, and help them promote
their effort to get more people to help them, even better.

Of course, that doesn't really advance the idea of a centralised and
coherent roadmap.  I'm not too upset about that, since I think that
lurking in the foundations of the idea of a coherent roadmap is the
assumption that we can somehow predict which ideas are likely to
succeed, and that we can somehow tell people to work on them.  I don't
think either assumption is true, and that some good ideas will be lost
if we set up any sort of filter.

For example, If a Roadmap Team (that acted as gatekeepers to a
centralised roadmap) had been around in 2000, when the idea of
reproducible builds was mentioned on the lists, I'd guess that idea
would not have made it onto the roadmap (judging from the list
response).

If by the time 2013 came round, we had had a decade of failed attempts
to get Reproducible Builds onto the Roadmap, perhaps Lunar would have
assumed that the idea was a non-starter.  Perhaps the Roadmap Team would
remember past rejections, and respond on the basis of precedent.
Perhaps if a roadmep had been in existence for a decade or more, people
would now consider getting on the roadmap as a necessary first step for
any ambitious idea.  This all strikes me as counter-productive.

So, let's not build a discriminating filter, but rather a full-band
amplifier.  We can expect unworkable ideas to fall by the wayside, but
even then they might prompt someone to come up with a workable
replacement idea, so are not automatically a waste of time.

In fact, if someone wants to do something obviously stupid, perhaps the
only way for them to be persuaded to give up is to let them try.  Having
the TC (or anyone else) decide that the idea has no merit might well
lead to endless bickering about how there's a conspiracy to suppress
their genius.

The TC seems like it is far too likely to act as a brake on development
if people are encouraged to seek its approval.  I don't think we should be
involved (except of course as individuals on the other team, as we wish).

Cheers, Phil.

P.S. Sure, if two ideas are going to cause a conflict, then they can be
referred to the TC in the normal manner, and then we'd get involved, but
I would expect that to be a very rare event.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Bug#827411: piuparts: FTBFS on jessie: 'wheezy' != 'squeeze'

[Holger Levsen]

control: tags -1 + pending

Hi Stefano,

On Sat, Jul 30, 2016 at 06:39:28PM -0400, Stefano Rivera wrote:
> Suggested solution attached.

thanks, applied to the develop branch now, will upload to sid shortly
and then proceed with fixing this via jessie-pu…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#833116: fgetty: Incorrect keystroke interpretation

[Dmitry Bogatov]

> When trying to login with fgetty, I could read my password on the screen 
> while typing. Did not continue.
> ngetty + login behaves good
> ngetty + login1 will get in well, but no key press will echo on the console.

Sorry, I assumed you read C. This is intended behaviour. Please,
continue and tell, whether rest is OK. I expect terminal to be not in
good shape, but after `reset` I expect fancy letter to work.

(Sure, it is not secure and you are encouraged to reinstall version
from sid afterward).  Probably I have one idea for your case.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#833337: cacti: Import_template.php does not work

[Tino Mo]

Package: cacti
Version: 0.8.8b+dfsg-8+deb8u4
Severity: normal
Tags: newcomer

Dear Maintainer,

script /usr/share/cacti/cli/import_template.php does not work. 
Output:"PHP Fatal error:  Call to undefined function import_xml_data() in 
/usr/share/cacti/cli/import_template.php on line 100"
Problem is in line 34. Existing Patch "07_cli-include-path.patch" in the packet 
does not intervene. 


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core)
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)

Bug#833013: collectd-core: Network plugin fails to load

[Sebastian Harl]

Hi,

On Wed, Aug 03, 2016 at 10:53:39AM +0200, Sebastian Harl wrote:
> On Sat, Jul 30, 2016 at 11:16:29PM +0200, Antoine Sirinelli wrote:
> > Since the latest security update, collected cannot load anymore the
> > network plugin. Since this plugin is used to transfer the measurements
> > to other hosts, it makes collectd completely useless for me.
> > 
> > Here is the error messages:
> > 
> > network plugin: gcry_control (GCRYCTL_SET_THREAD_CBS) failed: Not supported
> > Initialization of plugin `network' failed with status -1. Plugin will be 
> > unloaded.
> 
> Thanks for reporting this. That failure is a regression in
> 5.1.0-3+deb7u1 but it seems to have surfaced an actual (potentially
> severe) underlying issue that already existed before. It's specific to
> Wheezy.
> 
> Just before the collectd error messages, you should see the following in
> syslog:
> Libgcrypt warning: missing initialization - please fix the application
> 
> What happens is that gcrypt (apparently) is initialized before the call
> to gcry_control(GCRYCTL_SET_THREAD_CBS). Since that call is then trying
> to change the settings in an unsupported way (cannot change threading
> behavior after initialization), we're seeing this error.
> 
> Now, the actual problem is that this means gcrypt is not initialized
> correctly. Given the multi-threaded nature of collectd, I believe that
> this may potentially mean undefined behavior or crashes in the gcrypt
> code in the network plugin.
> 
> I'll need to dig further into why this is happening in the first place
> (why is gcrypt already initialized at this point?).

I believe the initialization happens during collectd's configuration
phase. The following upstream commit (which is part of the releases in
Jessie and onwards) fixes the issue:
https://github.com/collectd/collectd/commit/0ec776abf45ef3989f38d966e74b588f9ef15ebe

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#833013: collectd-core: Network plugin fails to load

[Sebastian Harl]

Hi,

On Tue, Aug 02, 2016 at 10:45:50PM +0200, Dejan SANADER wrote:
> Looks like a libgcrypt >= 1.6 is mandatory now...
> 
> https://github.com/collectd/collectd/blob/master/src/network.c#L504

Thanks for the additional info. It's actually the other way around.
gcry_control(GCRYCTL_SET_THREAD_CBS) is only used for libgcrypt < 1.6.

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#833013: collectd-core: Network plugin fails to load

[Sebastian Harl]

tags 833013 + wheezy
thanks

Hi,

On Sat, Jul 30, 2016 at 11:16:29PM +0200, Antoine Sirinelli wrote:
> Since the latest security update, collected cannot load anymore the
> network plugin. Since this plugin is used to transfer the measurements
> to other hosts, it makes collectd completely useless for me.
> 
> Here is the error messages:
> 
> network plugin: gcry_control (GCRYCTL_SET_THREAD_CBS) failed: Not supported
> Initialization of plugin `network' failed with status -1. Plugin will be 
> unloaded.

Thanks for reporting this. That failure is a regression in
5.1.0-3+deb7u1 but it seems to have surfaced an actual (potentially
severe) underlying issue that already existed before. It's specific to
Wheezy.

Just before the collectd error messages, you should see the following in
syslog:
Libgcrypt warning: missing initialization - please fix the application

What happens is that gcrypt (apparently) is initialized before the call
to gcry_control(GCRYCTL_SET_THREAD_CBS). Since that call is then trying
to change the settings in an unsupported way (cannot change threading
behavior after initialization), we're seeing this error.

Now, the actual problem is that this means gcrypt is not initialized
correctly. Given the multi-threaded nature of collectd, I believe that
this may potentially mean undefined behavior or crashes in the gcrypt
code in the network plugin.

I'll need to dig further into why this is happening in the first place
(why is gcrypt already initialized at this point?).

Cheers,
Sebastian

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x2F1FFCC7 +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin



signature.asc
Description: Digital signature

Bug#833338: mini-buildd: Please update Vcs field in debian/control

[Boyuan Yang]

Source: mini-buildd
Version: 1.0.16
Severity: minor

As said in https://qa.debian.org/cgi-bin/vcswatch?package=mini-buildd:

Error: The Vcs URL git://git.debian.org/git/collab-maint/mini-buildd.git is
deprecated/defunct, git://anonscm.debian.org/collab-maint/mini-buildd.git was
tried instead. Please update the Vcs field in debian/control.

git.debian.org is no longer working and should be replaced.

Thanks.



-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#833320: RFS: nbconvert/4.2.0-1 (ITP -- to experimental!)

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo


Hi,


>   I am looking for a sponsor for my package "nbconvert"


I admit you already have a Python packaging knowledge higher than mine :)


It has been a long time since my last nitpick, and this time I found one!
hurray!
:)

1) why aren't you building the doc? is some sort of "chicken and egg" issue?
can I presume you will add the package later?

2) missing copyright!
./nbconvert/resources/style.min.css: * Copyright 2011-2015 Twitter, Inc.


3) FTBFS!
http://debomatic-amd64.debian.net/distribution#experimental/nbconvert/4.2.0-1/buildlog

hurray! I found something to nitpick :)

if you can fix the above I'll be happy to upload!

G.

Bug#833339: hobbit-plugins missing permissions for /bin/btrfs

[gurkan]

Package: hobbit-plugins
Version: 20160122
Severity: normal

the included sudoers.d/xymon file is missing the line:
xymon ALL=(root) NOPASSWD: /bin/btrfs

causing errors in the logging system.

Bug#833341: Change default fallback locale to C.UTF-8

[Christoph Berg]

Package: postgresql-common
Version: 175
Severity: normal

Too many people end up with SQL_ASCII clusters when they didn't have
any specific OS locale configured. We should change the default locale
to C.UTF-8.

Christoph

Bug#833340: mini-buildd: please make the build reproducible

[Boyuan Yang]

Source: mini-buildd
Version: 1.0.16
Severity: wishlist
Tags: patch

Hi,

The current unreproducible status is due to different env HOME value generated
by help2man.

An example patch is provided to fix make the package reproducible.

Thanks.
--- a/mini-buildd
+++ b/mini-buildd
@@ -77,9 +77,9 @@
 help="SMTP credentials in format '[USER]:[PASSWORD]@smtp|ssmtp://HOST:PORT'.")
 group_conf.add_argument("-U", "--dedicated-user", action="store", default="mini-buildd",
 help="Force a custom dedicated user name (to run as a different user than 'mini-buildd').")
-group_conf.add_argument("-H", "--home", action="store", default=os.getenv("HOME"),
+group_conf.add_argument("-H", "--home", action="store", default="$HOME",
 help="Run with this home dir. The only use case to change this for debugging, really.")
-group_conf.add_argument("-F", "--pidfile", action="store", default=os.path.join(os.getenv("HOME"), ".mini-buildd.pid"),
+group_conf.add_argument("-F", "--pidfile", action="store", default=os.path.join("$HOME", ".mini-buildd.pid"),
 help="Set pidfile path.")
 group_conf.add_argument("-f", "--foreground", action="store_true",
 help="Don't daemonize, log to console.")

Bug#833264: [pkg-wpa-devel] Bug#833264: wpasupplicant: DHCPOffer not recognized after upgrade on 1 August 2016

[Andrew Shadura]

On 2 August 2016 at 11:58, Paul Cobbaut  wrote:
> Version: 2.3-2.4

Is that right?

> Since yesterdays update of wpasupplicant it is impossible to accept a valid
> DHCPOffer on this computer. Other computers in the network have no issue.
> Downgrading to the version of wpasupplicant in 'testing' solves the issue. I
> put wpasupplicant on 'hold' with apt-mark, all other packages are Debian
> Sid.

More details, logs, debug info?..

-- 
Cheers,
  Andrew

Bug#833342: chromium: crashes upon the first keypress in wayland

[Rostislav Pehlivanov]

Package: chromium
Version: 52.0.2743.82-4
Severity: important

Dear Maintainer,

Since the switch to GTK3 in unstable Chromium has started to crash
upon the first keypress in Wayland with the following log:

[25511:25511:0803/101959:ERROR:browser_main_loop.cc(283)] GLib-GObject: invalid 
cast from 'GdkWaylandDisplay' to 'GdkX11Display'
[25511:25511:0803/101959:ERROR:browser_main_loop.cc(283)] GLib-GObject: invalid 
cast from 'GdkWaylandDisplay' to 'GdkX11Display'
[25511:25511:0803/101959:ERROR:browser_main_loop.cc(283)] GLib-GObject: invalid 
cast from 'GdkWaylandDisplay' to 'GdkX11Display'
[25511:25511:0803/101959:ERROR:browser_main_loop.cc(283)] GLib-GObject: invalid 
cast from 'GdkWaylandDisplay' to 'GdkX11Display'

It appears that since GTK3 supports Wayland it's automatically picked as
the backend and since Chromium either hasn't fully stabilized its support for it
or there's a bug the crash happens. Previously with gtk2 Xwayland was always 
used.
The browser is perfectly usable and stable as long as no actual keys have been 
pressed, e.g.
navigating with a mouse.

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

Kernel: Linux 4.7.0-custom (SMP w/8 CPU cores; PREEMPT)
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 chromium depends on:
ii  libasound2   1.1.1-2
ii  libatk1.0-0  2.20.0-1
ii  libavcodec57 7:3.1.1-3
ii  libavformat577:3.1.1-3
ii  libavutil55  7:3.1.1-3
ii  libc62.23.90+20160725.b898b64-1
ii  libcairo21.14.6-1+b1
ii  libcups2 2.1.4-4
ii  libdbus-1-3  1.11.2-1
ii  libexpat12.2.0-1
ii  libfontconfig1   2.11.0-6.4
ii  libfreetype6 2.6.3-3+b1
ii  libgcc1  1:6.1.1-10
ii  libgdk-pixbuf2.0-0   2.34.0-1
ii  libglib2.0-0 2.49.4-1
ii  libgnome-keyring03.12.0-1+b1
ii  libgtk-3-0   3.21.4-1
ii  libharfbuzz0b1.2.7-1
ii  libjpeg62-turbo  1:1.5.0-1
ii  libnettle6   3.2-1
ii  libnspr4 2:4.12-2
ii  libnss3  2:3.23-2
ii  libpango-1.0-0   1.40.1-1
ii  libpangocairo-1.0-0  1.40.1-1
ii  libpci3  1:3.3.1-1.1
ii  libpulse09.0-1.1
ii  libspeechd2  0.8.4-2
ii  libstdc++6   6.1.1-10
ii  libx11-6 2:1.6.3-1
ii  libxcomposite1   1:0.4.4-1
ii  libxcursor1  1:1.1.14-1+b1
ii  libxdamage1  1:1.1.4-2+b1
ii  libxext6 2:1.3.3-1
ii  libxfixes3   1:5.0.2-1
ii  libxi6   2:1.7.6-1
ii  libxml2  2.9.4+dfsg1-1
ii  libxrandr2   2:1.5.0-1
ii  libxrender1  1:0.9.9-2
ii  libxslt1.1   1.1.28-4
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.2-1+b1
ii  x11-utils7.7+3
ii  xdg-utils1.1.1-1

Versions of packages chromium recommends:
ii  fonts-liberation  2.00.1-1

Versions of packages chromium suggests:
pn  chromium-l10n  

-- debconf-show failed

Bug#763822: [Reproducible-builds] Moving towards buildinfo on the archive network

[Johannes Schauer]

Hi Jonathan,

Quoting Jonathan McDowell (2016-07-25 22:29:39)
> Having been impressed by the current status of reproducible builds and
> the fact it looks like we're close to having the important pieces in
> Debian proper, I have started to have a look at how I could help out
> with this bug. I've done some poking around in the dak code, and think I
> have a vague idea of how to achieve what I think is wanted.

Having tried hacking dak myself, I want to especially thank you for looking
into that!

> (Additionally it is not clear to me where the dpkg status for buildinfo
> creation is; I have heard that it's close to happening, but I can't find
> anything on recent list archives about it - pointers appreciated!)

You are probably aware of #138409?

It scrolled out of my IRC history already but I think guillem said in
#debian-dpkg that releasing a dpkg version with buildinfo support was blocked
by coordination with dak because he wants to make sure that dpkg support aligns
with what dak ends up supporting.

Thanks!

cheers, josch


signature.asc
Description: signature

Bug#826177: ice: No sound after system restart

[Elimar Riesebieter]

control: retitle -1 ice: No sound after restart
control: severity -1 normal

* Tarso  [2016-06-02 21:09 -0300]:

Sorry, I recognized this bug lately, but recognized ;-)

> Package: alsa
> Severity: important
> File: ice
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What led up to the situation?
> fresh install
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
> the sound card is auto installed by the system, aparently with the
> correct driver
>* What was the outcome of this action?
> no sounds comes out of the speakers
>* What outcome did you expect instead?
> sounds
> 
> To " fix" my no sound problem, I can open alsamixer and open a
> music file with any player, or even a youtube video (something
> that will use the sound card).  with something playing, I change
> the multitrack on alsamixer from 48000 (default), to ICE (pressing
> the up arrow). the file stops playing and I close the player. Than
> on alsamixer, I press the down arrow to change the multitrack back
> to 48000, and it is unresponsive for a couple of seconds. I keep
> insisting pressing the down arrow several times untill it goes to
> 48000 and I hear a popping sound. after that I can close alsamixer
> and my sound card works perfectly. I can log in and out and the
> sound keeps working, but if I restart the system I need to
> re-apply this " fix" .
> *** End of the template - remove these template lines ***

Could you please point me to the "multitrack" in alsamixer. Never
heard of that.

What do you mean with ice?

Please post the output of:

# aplay -l
# dpkg -l | egrep "libasou|alsa"
# ps aux | grep pulse

Elimar
-- 
  Obviously the human brain works like a computer.
  Since there are no stupid computers humans can't be stupid.
  There are just a few running with Windows or even CE ;-)

Bug#830971: The bug is still present in Debian 4.6.4-1 kernel

[Tarik Graba]

Hi everybody,

A patch has been upstreamed and applied to the 4.7 branch:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.7.y&id=1488a1e3828d60d74c9b802a05e24c0487babe4e

I don't know what version of the kernel is planned for the next Debian 
stable release, but if the 4.6 version is chosen maybe consider 
backporting this patch.


Regards,
T.G.

Bug#833300: closed by Michael Biebl (Re: Bug#833300: libgtksourceview2.0-dev: Please depend on libpng-dev)

[Ximin Luo]

Michael Biebl:
> Am 03.08.2016 um 02:24 schrieb Ximin Luo:
>> Debian Bug Tracking System:
>>> This is an automatic notification regarding your Bug report
>>> which was filed against the libgtksourceview2.0-dev package:
>>>
>>> #833300: libgtksourceview2.0-dev: Please depend on libpng-dev
>>>
>>> It has been closed by Michael Biebl .
>>>
>>> Their explanation is attached below along with your original report.
>>> If this explanation is unsatisfactory and you have not received a
>>> better one in a separate message then please contact Michael Biebl 
>>>  by
>>> replying to this email.
>>>
>>
>> Hi Michael,
>>
>> Your explanation is insufficient - it does not communicate to readers why 
>> this is not a bug.
> 
> It's not a bug in gtksourceview-2.0.pc because that file does not
> declare a dependency on libpng. I've even copied the contents of that
> file to make that clear.
> 

It's really unclear to me why this means "there is no bug". The logical jump 
here is too far, can you explain better please?

You should understand that most readers have less in-depth context about this 
program than you, so it is harder for other people to make "logical jumps" that 
might seem obvious to you.

>> Why do you think pkg-config exits with error code 1, when libpng-dev is not 
>> installed?
> 
> You need to check that locally on your system. Run pkg-config with the
> --debug flag and you should see where it exits.
> 

I did run it with the debug flag, and it exited exactly after trying to find 
libpng-dev. Although I pasted the original command line wrong in my first 
email, I've attached the full log as a separate file.

X

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git
$ pkg-config --debug gtksourceview-2.0 2> ~/pkg-config.log 
no output option set, defaulting to --exists
Error printing disabled by default due to use of output options --exists, --atleast/exact/max-version, --list-all or no output option at all. Value of --print-errors: 0
Error printing disabled
Adding virtual 'pkg-config' package to list of known packages
Cannot open directory #1 '/usr/local/lib/x86_64-linux-gnu/pkgconfig' in package search path: No such file or directory
Cannot open directory #2 '/usr/local/lib/pkgconfig' in package search path: No such file or directory
Cannot open directory #3 '/usr/local/share/pkgconfig' in package search path: No such file or directory
Scanning directory #4 '/usr/lib/x86_64-linux-gnu/pkgconfig'
Ignoring file '.' in search directory; not a .pc file
Ignoring file '..' in search directory; not a .pc file
File 'libdrm_intel.pc' appears to be a .pc file
Will find package 'libdrm_intel' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/libdrm_intel.pc'
File 'xft.pc' appears to be a .pc file
Will find package 'xft' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/xft.pc'
File 'sqlite3.pc' appears to be a .pc file
Will find package 'sqlite3' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/sqlite3.pc'
File 'xkbcomp.pc' appears to be a .pc file
Will find package 'xkbcomp' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/xkbcomp.pc'
File 'xfixes.pc' appears to be a .pc file
Will find package 'xfixes' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/xfixes.pc'
File 'pixman-1.pc' appears to be a .pc file
Will find package 'pixman-1' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/pixman-1.pc'
File 'icu-uc.pc' appears to be a .pc file
Will find package 'icu-uc' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/icu-uc.pc'
File 'xau.pc' appears to be a .pc file
Will find package 'xau' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/xau.pc'
File 'gnutls.pc' appears to be a .pc file
Will find package 'gnutls' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/gnutls.pc'
File 'libidn.pc' appears to be a .pc file
Will find package 'libidn' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/libidn.pc'
File 'QtHelp.pc' appears to be a .pc file
Will find package 'QtHelp' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/QtHelp.pc'
File 'zlib.pc' appears to be a .pc file
Will find package 'zlib' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/zlib.pc'
File 'cairo-tee.pc' appears to be a .pc file
Will find package 'cairo-tee' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/cairo-tee.pc'
File 'glu.pc' appears to be a .pc file
Will find package 'glu' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/glu.pc'
File 'form.pc' appears to be a .pc file
Will find package 'form' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/form.pc'
File 'pangoxft.pc' appears to be a .pc file
Will find package 'pangoxft' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/pangoxft.pc'
File 'gthread-2.0.pc' appears to be a .pc file
Will find package 'gthread-2.0' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/gthread-2.0.pc'
File 'gdk-x11-3.0.pc' appears to be a .pc file
Will find package 'gdk-x11-3.0' in file '/usr/lib/x86_64-linux-gnu/pkgconfig/gdk-x11-3.0.pc'
File 'xinerama.pc' appears to be a .pc file
Will find package 'xinerama' in file '/usr/lib/x86_64-linux-gnu/pkgconf

Bug#833343: gnuplot needs transitional packages for gnuplot5

[Adrian Bunk]

Package: gnuplot
Version: 5.0.3+dfsg3-7
Severity: important

gnuplot needs transitionals packages for all gnuplot5* packages
in jessie.

Otherwise a user who has only gnuplot5 (and not gnuplot) installed
on jessie will stay at the jessie gnuplot5 package after upgrading
to stretch.

Please use Method 2 from https://wiki.debian.org/Renaming_a_Package

Bug#833300: closed by Michael Biebl (Re: Bug#833300: libgtksourceview2.0-dev: Please depend on libpng-dev)

[Emilio Pozuelo Monfort]

On 03/08/16 11:44, Ximin Luo wrote:
> Michael Biebl:
>> Am 03.08.2016 um 02:24 schrieb Ximin Luo:
>>> Debian Bug Tracking System:
 This is an automatic notification regarding your Bug report
 which was filed against the libgtksourceview2.0-dev package:

 #833300: libgtksourceview2.0-dev: Please depend on libpng-dev

 It has been closed by Michael Biebl .

 Their explanation is attached below along with your original report.
 If this explanation is unsatisfactory and you have not received a
 better one in a separate message then please contact Michael Biebl 
  by
 replying to this email.

>>>
>>> Hi Michael,
>>>
>>> Your explanation is insufficient - it does not communicate to readers why 
>>> this is not a bug.
>>
>> It's not a bug in gtksourceview-2.0.pc because that file does not
>> declare a dependency on libpng. I've even copied the contents of that
>> file to make that clear.
>>
> 
> It's really unclear to me why this means "there is no bug". The logical jump 
> here is too far, can you explain better please?
> 
> You should understand that most readers have less in-depth context about this 
> program than you, so it is harder for other people to make "logical jumps" 
> that might seem obvious to you.

libgtksourceview2.0-dev needs to depend on the packages that provide the .pc
files that its .pc file requires.

i.e., it should depend on what provides gtk+-2.0.pc and what provides 
libxml-2.0.pc.

The failure indicates that something is missing a dependency on libpng-dev, but
pkg-config is recursive. So when you do `pkg-config --cflags gtksourceview-2.0'
it will look for the cflags of required packages, recursively. And the package
that requires libpng is the one that should depend on it.

>>> Why do you think pkg-config exits with error code 1, when libpng-dev is not 
>>> installed?
>>
>> You need to check that locally on your system. Run pkg-config with the
>> --debug flag and you should see where it exits.
>>
> 
> I did run it with the debug flag, and it exited exactly after trying to find 
> libpng-dev. Although I pasted the original command line wrong in my first 
> email, I've attached the full log as a separate file.

I see:

Searching for 'cairo' private requirement 'libpng'
Looking for package 'libpng'
Looking for package 'libpng-uninstalled'

So /usr/lib/x86_64-linux-gnu/pkgconfig/cairo.pc has:

Requires.private:gobject-2.0 glib-2.0 >= 2.14   pixman-1 >= 0.30.0
fontconfig >= 2.2.95 freetype2 >= 9.7.3   libpng xcb-shm xcb >= 1.6 xcb-render
>= 1.6 xrender >= 0.6 x11 xext

However, it also depends on libpng-dev:

Depends: libcairo2 (= 1.14.6-1+b1), libcairo-gobject2 (= 1.14.6-1+b1),
libcairo-script-interpreter2 (= 1.14.6-1+b1), libfontconfig1-dev (>= 2.2.95),
libfreetype6-dev (>= 2.1.10), libx11-dev, libxrender-dev (>= 0.6), libxext-dev,
libpng-dev, libsm-dev, libpixman-1-dev (>= 0.22.0), libxcb1-dev (>= 1.6),
libxcb-render0-dev (>= 1.6), libxcb-shm0-dev, libglib2.0-dev

So the question here is: what version of libcairo2-dev do you have installed,
and why don't you have libpng-dev installed?

Emilio

Bug#833344: docky: Sesstion Manager docklet crashes docky

[Bartosz Skrzypczak]

Package: docky
Version: 2.2.1.1-1
Severity: important

As the title says, docky crashes after adding Session Manager docklet. Now it 
also crashes every time I start it. Here is log from console: 
http://pastebin.com/ZVCHcJKv

This bug is also known on ubuntu: https://bugs.launchpad.net/docky/+bug/1468835

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

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

Versions of packages docky depends on:
ii  gconf2  3.2.6-3
ii  libc6   2.23-2
ii  libdbus-glib2.0-cil 0.6.0-1
ii  libdbus2.0-cil  0.8.1-2
ii  libgconf2.0-cil 2.24.2-4
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libgkeyfile1.0-cil  0.1-5
ii  libglib2.0-02.48.1-2
ii  libglib2.0-cil  2.12.10-6
ii  libgnome-keyring1.0-cil 1.0.0-5
ii  libgtk2.0-0 2.24.30-2
ii  libgtk2.0-cil   2.12.10-6
ii  libmono-addins0.2-cil   1.0+git20130406.adcd75b-4
ii  libmono-cairo4.0-cil4.2.1.102+dfsg2-8
ii  libmono-corlib4.5-cil   4.2.1.102+dfsg2-8
ii  libmono-posix4.0-cil4.2.1.102+dfsg2-8
ii  libmono-sharpzip4.84-cil4.2.1.102+dfsg2-8
ii  libmono-system-core4.0-cil  4.2.1.102+dfsg2-8
ii  libmono-system-web4.0-cil   4.2.1.102+dfsg2-8
ii  libmono-system-xml-linq4.0-cil  4.2.1.102+dfsg2-8
ii  libmono-system-xml4.0-cil   4.2.1.102+dfsg2-8
ii  libmono-system4.0-cil   4.2.1.102+dfsg2-8
ii  libnotify0.4-cil0.4.0~r3032-7
ii  libwnck22   2.30.7-5
ii  libx11-62:1.6.3-1
ii  mono-runtime4.2.1.102+dfsg2-8

Versions of packages docky recommends:
pn  dockmanager  

docky suggests no packages.

-- no debconf information

Bug#833345: jessie-pu: package piuparts/0.62+deb8u1

[Holger Levsen]

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

Hi,

piuparts ftbfs in jessie, which I would like to fix with the following
upload:

$ git diff 0.62..jessie
diff --git a/debian/changelog b/debian/changelog
index 45e9372..76cbd8f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+piuparts (0.62+deb8u1) UNRELEASED; urgency=medium
+
+  [ Stefano Rivera ]
+  * Don't test the current Debian release status, tracking that is
+distro-info-data's problem. (Closes: #827411)
+
+ -- Holger Levsen   Wed, 03 Aug 2016 12:01:32 +0200
+
 piuparts (0.62) unstable; urgency=medium
 
   * Default to http://http.debian.net/debian instead of the deprecated
diff --git a/tests/test_config.py b/tests/test_config.py
index e68d8ea..a5ca9a3 100644
--- a/tests/test_config.py
+++ b/tests/test_config.py
@@ -17,9 +17,6 @@ class ConfStdDistroTests(unittest.TestCase):
 
 
 def testConfStdDistroNames(self):
-self.assertEqual(self.oldstable, 'squeeze')
-self.assertEqual(self.stable, 'wheezy')
-self.assertEqual(self.testing, 'jessie')
 self.assertEqual(self.unstable, 'sid')
 self.assertEqual(self.experimental, 'experimental')
 

Obviously I will change the UNRELEASED to jessie before uploading.

BTW, is there any ETA for 8.6 yet? (Debian Edu needs some more fixes
too…)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#811993: terminatorx: FTBFS with GCC 6: call overloaded is ambiguous

[James Cowgill]

Hi Alex,

On 27/07/16 22:52, Alexander Koenig wrote:
> upstream has a new release that - among other things - has these issues
> fixed. Current release is 4.0.1; also note that I have updated the debian
> package for my own builds (clone from 
> https://terminatorX.org/src/debian.git) maybe some of the modifications
> can be reused.

I've updated the Debian packaging to 4.0.1 in the git repo here:
https://anonscm.debian.org/cgit/pkg-multimedia/terminatorx.git

Is it possible for you to look at some of the patches? I think they're
all subtitle to be applied upstream, but only patches 28 and 29 were
wrote by me.

https://anonscm.debian.org/cgit/pkg-multimedia/terminatorx.git/tree/debian/patches

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#833346: wodim: "wodim --devices" does not work

[Richard Betham]

Package: wodim
Version: 9:1.1.11-3
Severity: normal

Dear Maintainer,


I entered the command line:
wodim --devices

and got the result:
"
wodim: No such file or directory. 
Cannot open SCSI driver!
For possible targets try 'wodim --devices' or 'wodim -scanbus'.
For possible transport specifiers try 'wodim dev=help'.
For IDE/ATAPI devices configuration, see the file README.ATAPI.setup from
the wodim documentation.
"
This was output on Standard Error

I tried the same command as root, and on another machine, all with the same 
result.
I tried "wodim -scanbus"
with the same result.

I would prefer that Wodim --devices would tell me what CD and DVD drives are 
connected.

Eventually I used gui k3b, which used growisofs, successfully.

Thank you very much for supplying and maintaining wodim and cdrkit.

With best regards from
Richard Betham




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

Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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 wodim depends on:
ii  libc62.19-18+deb8u4
ii  libcap2  1:2.24-8

Versions of packages wodim recommends:
ii  genisoimage  9:1.1.11-3

Versions of packages wodim suggests:
ii  cdrkit-doc  9:1.1.11-3

-- no debconf information

Bug#830102: sitesummary: autopkgtest failure

[Holger Levsen]

On Fri, Jul 22, 2016 at 08:54:05AM +0200, Petter Reinholdtsen wrote:
> See
> also https://bugs.debian.org/483997 >.
 
Guillem suggests to use a trigger: "But coming back to the solutions to
your problem, I think you either need a trigger in apache2, which would
make sitesummary perform the the actual configuration. Or one from
sitesummary, that would tell apache2 to perform any required configuration
activation like Jonathan suggested."


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#833328: [Pkg-openssl-devel] Bug#833328: Please close or delete this issue.

[Sebastian Andrzej Siewior]

On 2016-08-03 11:00:18 [+0300], Mihail Artamonov wrote:
> Hello, this problem was solved. Thank you!

What changed in the last 9 minutes that solved the problem?

Sebastian

Bug#830344: How should the TC help with a project roadmap?

[Ian Jackson]

Philip Hands writes ("Bug#830344: How should the TC help with a project 
roadmap?"):
> I managed to make time to watch the video of the roadmap BoF, so
> hopefully I'm now able to respond to more than the name "roadmap*.

Thanks, Philip, for this penetrating analysis.

I complete agree with your conclusions.


> The "Let me help you do what you want team":
> 
>   That encapsulates what I think might be worthwhile out of this idea.
>   It emphasises letting people do things if they happen to feel the urge.

I think this would be an awesome idea.  Let me try to run with it.

What would such a team need ?

 * To be accessible and approachable, and not judgemental.

 * To have the communication and technical skills to help someone with
   an idea produce clear and cogent explanations.

 * To have high status and high visibility, so that when they
   introduce someone driving a project to stakeholders, they get
   airtime.

 * Ideally to contain people with few enemies.

 * To be dynamic and novelty-oriented.

Looking at that wishlist in the round, it doesn't look like the TC.

Perhaps we could have the larger core teams send a representative each
to this new liason team.  But we do have difficulties with some of the
important stakeholders in the project having a shortage of people.


There is also a question about archive-wide changes.  We have a
recurrent conflict about a questions of the following form:

Should the maintainers of a package P be required to carry a patch to
provide for P a feature F, that P's maintainers don't care about, but
the feature F team do ?  (By a feature I mean not the abstract
requirement, but the concrete approach - maybe a specification,
technical policy or particular implementation.)

These discussions are sometimes in the context of a feature F which
the F team is trying to introduce; and sometimes in the context of one
which a subset of maintainers in Debian are trying to remove.

One of the biggest impediments to archive-wide features is that the
feature team may expect resistance from maintainers.  This is
particularly true for features which compete with (or seem to compete
with) ones that maintainers care about (or are politically aligned
with).

I have a very firm view that it is a primary responsibility of the
maintainers to enable other people's work.  The amount of effort to
carry a patch is normally low.

But the TC in particular has in the past had a low regard for features
of this kind which in the TC's view `duplicate' other functionality.
In these circumstances the medium- to long-term coexistence of
competing approaches is not possible, because maintainers can block
the one they don't like.

As a result the healthy competition between ideas, which you describe,
cannot always occur in Debian.


Ian.


-- 
Ian JacksonThese 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#833348: mirror submission for ftp.man.szczecin.pl

[Academic Center of Computer Science]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: ftp.man.szczecin.pl
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
Archive-ftp: /pub/Linux/debian/
CDImage-ftp: /pub/Linux/debian-cd/
IPv6: yes
Archive-upstream: ftp2.de.debian.org
CDImage-upstream: ftp2.de.debian.org
Updates: twice
Maintainer: Academic Center of Computer Science 
Country: PL Poland

Bug#833347: mirror submission for ftp.man.szczecin.pl

[Academic Center of Computer Science]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: ftp.man.szczecin.pl
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
Archive-ftp: /pub/Linux/debian/
CDImage-ftp: /pub/Linux/debian-cd/
IPv6: no
Archive-upstream: ftp2.de.debian.org
CDImage-upstream: ftp2.de.debian.org
Updates: twice
Maintainer: Academic Center of Computer Science 
Country: PL Poland

Bug#792519: systemd-logind fails to start on system using LDAP

[Lorenz Hübschle-Schneider]

Dear all,

I get similar symptoms (but no boot failures, just unnecessarily slow
boot times) with current unstable (systemd 231-1, dbus 1.10.8-1,
libnss-ldap 265-3+b1) using systemd-networkd instead of NetworkManager.

Loads of
> dbus-daemon[2395]: nss_ldap: could not connect to any LDAP server as (null) - 
> Can't contact LDAP server
in the logs until at some point networkd connects.

I suspect that the network may only be brought up at that point because
of an NFS automount that is triggered:
> systemd[1]: home.automount: Got automount request for /home, triggered by 
> 2458 (mount)
> systemd[1]: Starting Wait for Network to be Configured...

 After that request there are some more failures (this time from nscd
 instead of dbus) until the network is actually connected.

I have nss_initgroups_ignoreusers set up for all system users and
'bind_policy soft' in /etc/ldap.conf

Anything I can do to help fix this?

Best,
Lorenz

On Sun, 19 Jul 2015 15:03:53 -0300 Felipe Sateler 
wrote:
> On 17 July 2015 at 18:44, Daniel Schepler  wrote:
> > On Wed, Jul 15, 2015 at 12:30 PM, Felipe Sateler 
> > wrote:
> >>
> >> On 15 July 2015 at 16:09, Daniel Schepler  wrote:
> >> > On Wed, Jul 15, 2015 at 11:48 AM, Felipe Sateler 
> >> > wrote:
> >> >>
> >> >> Hmm. Could you please attach the upgrade logs since some time before
> >> >> the problems occurred?  Might network manager have been updated in the
> >> >> meantime?
> >> >
> >> >
> >> > Attaching /var/log/dpkg.log.  I think the first failed boot was
> >> > 2015-07-08
> >> > or 2015-07-09.  From the previous history, the last upgrade of dbus was:
> >> >
> >> > 2015-05-20 09:46:36 upgrade dbus:amd64 1.8.16-1 1.8.18-1
> >> >
> >> >>
> >> >> Also, how do you manage your connections?
> >> >>
> >> >> I also found this old redhat bug[1]. Could you try adding a conf
> >> >> snippet to order the ldap components before dbus? Use systemctl edit
> >> >>  and add Before=dbus.service.
> >> >>
> >> >>
> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=502072
> >> >
> >> >
> >> > OK, it will be a while before I can test it because I'm doing work using
> >> > the
> >> > machine right now.
> >> >
> >> > It would appear to me from the logs that NetworkManager can't
> >> > successfully
> >> > start before dbus is available - and I would probably want to make nslcd
> >> > dependent on networking being up.  Would that mean that I'd have to set
> >> > things up so it manually connects eth0 over DHCP, then starts nslcd,
> >> > then
> >> > starts dbus?  And then NetworkManager would be left only managing wlan0?
> >> > And if so, where would I look for documentation on setting up the unit
> >> > to
> >> > connect eth0?  (Sorry for the last very basic question.)
> >>
> >> I think (but I'm not sure) that nm will still connect without dbus
> >> available yet, but it will of course not answer any dbus requests. So
> >> it should only be necessary to order ldap before dbus.
> >>
> >> However, this solution may prove brittle. Reading the linked redhat
> >> bug there are two promsing suggestions:
> >>
> >> 1. Add 'bind_policy soft' to /etc/ldap.conf.
> >> 2. Set nss_initgroups_ignoreusers to at least
> >> 'root,dirsrv,gdm,rtkit,pulse,haldaemon,polkituser,avahi,dbus'
> >>
> >> It seems the problem is that nss_ldap is trying to query ldap for
> >> system users. That seems wrong to me, as the system should be able to
> >> work without network.
> >

Bug#833349: mirror listing update for ftp.man.szczecin.pl

[Academic Center of Computer Science]

Package: mirrors
Severity: minor
User: mirr...@packages.debian.org
Usertags: mirror-list

Submission-Type: update
Site: ftp.man.szczecin.pl
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x 
Archive-ftp: /pub/Linux/debian/
CDImage-ftp: /pub/Linux/debian-cd/
IPv6: yes
Archive-upstream: ftp2.de.debian.org
CDImage-upstream: ftp2.de.debian.org
Updates: twice
Maintainer: Academic Center of Computer Science 
Country: PL Poland

Bug#833350: [logwatch] oom-killer lines not matched (again)

[Marcin Szewczyk]

Package: logwatch
Version: 7.4.1-2
Severity: normal
Tags: patch

Logwatch does not match current oom-killer lines.

Kernel: 3.16.7-ckt25-2+deb8u3

Currently lines look somewhat like this:
#v+
Aug  2 16:05:04 veos01 kernel: [1784876.846422] bash invoked oom-killer: 
gfp_mask=0x2000d0, order=2, oom_score_adj=0
Aug  2 16:05:04 veos01 kernel: [1784876.846425] bash cpuset=/ mems_allowed=0
Aug  2 16:05:04 veos01 kernel: [1784876.846429] CPU: 0 PID: 16245 Comm: bash 
Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt25-2+deb8u3
[...]
Aug  2 16:05:04 veos01 kernel: [1784876.846724] Out of memory: Kill process 
1390 (sshd) score 13 or sacrifice child
Aug  2 16:05:04 veos01 kernel: [1784876.973189] Killed process 1392 
(rsync_wrapper) total-vm:11692kB, anon-rss:284kB, file-rss:8kB
#v-

Patch attached.

See also:
- logwatch: Wrong regular expression for Out of memmory killer
  (2012-01-21),
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656806

- #53 kernel: Applications invoking oom-killer and those killed by it
  are not the same (2016-08-03),
  https://sourceforge.net/p/logwatch/bugs/53/

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.5
  500 stable  security.debian.org 
  500 stable  ftp.pl.debian.org 
  500 oldstable   ftp.pl.debian.org 
   50 testing security.debian.org 
   50 testing ftp.pl.debian.org 
  100 jessie-backports ftp.pl.debian.org 

--- Package information. ---
Package's Depends field is empty.

Package's Recommends field is empty.

Package's Suggests field is empty.




-- 
Marcin Szewczyk
http://wodny.org
--- /usr/share/logwatch/scripts/services/kernel	2014-11-03 20:03:19.0 +0100
+++ /etc/logwatch/scripts/services/kernel	2016-08-03 12:04:43.424018354 +0200
@@ -99,7 +99,7 @@
   $UnalignedErrors{$1}++;
} elsif ($ThisLine =~ /([^(]*)\(\d+\): floating-point assist fault at ip/) {
   $FPAssists{$1}++;
-   } elsif ($ThisLine =~ /Out of memory: (?:Killed|kill) process \d+ \((.*)\)/) {
+   } elsif ($ThisLine =~ /Out of memory: (?:[Kk]illed|[Kk]ill) process \d+ \((.*)\)/) {
   $OOM{$1}++;
} elsif ($ThisLine =~ /(EDAC (MC|PCI)\d:.*)/) {
   # Standard boot messages
@@ -229,7 +229,7 @@
 }
 
 if (keys %OOM) {
-   print "\nWARNING:  Out of memory killer killed these executables\n";
+   print "\nWARNING:  Out of memory killer killed these executables or their children\n";
foreach my $Thisone ( sort {$a cmp $b} keys %OOM ) {
   print "   $Thisone :  $OOM{$Thisone} Time(s)\n";
}

Bug#833351: python-tornado: accesses the internet during build

[Chris Lamb]

Source: python-tornado
Version: 4.4.1-1
Severity: serious
Justification: Policy 4.9
User: la...@debian.org
Usertags: network-access

Dear Maintainer,

Whilst python-tornado builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access during
a build.

00:00:21.707841 IP d29dd38a7d1e.9 > router.asus.com.domain: 40327+ A? 
docs.python.org. (33)
00:00:21.707887 IP d29dd38a7d1e.9 > router.asus.com.domain: 61201+ ? 
docs.python.org. (33)

  [..]

The full build log (including tcpdump output) is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


python-tornado.4.4.1-1.unstable.amd64.log.txt.gz
Description: Binary data

Bug#655300: CVE-2012-0035: Project.el code loading vulnerability in CEDET

[Jonathan Wiltshire]

Package: cedet

Dear maintainer,

Recently you fixed one or more security problems and as a result you closed
this bug. These problems were not serious enough for a Debian Security
Advisory, so they are now on my radar for fixing in the following suites
through point releases:

squeeze (6.0.8) - use target "oldstable"

Please prepare a minimal-changes upload targetting each of these suites,
and submit a debdiff to the Release Team [0] for consideration. They will
offer additional guidance or instruct you to upload your package.

I will happily assist you at any stage if the patch is straightforward and
you need help. Please keep me in CC at all times so I can
track [1] the progress of this request.

For details of this process and the rationale, please see the original
announcement [2] and my blog post [3].

0: debian-rele...@lists.debian.org
1: http://prsc.debian.net/tracker/655300/
2: <201101232332.11736.th...@debian.org>
3: http://deb.li/prsc

Thanks,

with his security hat on:
--
Jonathan Wiltshire  j...@debian.org
Debian Developer http://people.debian.org/~jmw

4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC  74C3 5394 479D D352 4C51

Bug#833296: exim4-config: dpkg-reconfigure exim4-config: misleading message

[Mauro Salvini]

On Wed, 2016-08-03 at 10:44 +0200, Marc Haber wrote:
> On Wed, Aug 03, 2016 at 10:26:57AM +0200, Mauro Salvini wrote:
> > > > > If uname() returns a single-component name, Exim calls gethostbyname()
> > > > > (or getipnodebyname() where available) in an attempt to acquire a
> > > > > fully qualified host name.
> > > > > 
> > > > > Can you check what your gethostbyname/getipnodebyname returns?
> > > 
> > > > hostname by uname(): myhostname
> > > > hostname by gethostbyname(): myhostname.mydomain.local
> > > 
> > > Hm.
> > > 
> > > What does hostname --fqdn say?
> > 
> > It says myhostname.mydomain.local
> 
> Good.
> 
> > > What does exim -bP | grep ^primary_hostname say?
> > 
> > It says myhostname
> 
> not good.
> 
> > Checked /var/lib/exim4/config.autogenerated for primary_hostname:
> > 
> > .ifdef MAIN_HARDCODE_PRIMARY_HOSTNAME
> > primary_hostname = MAIN_HARDCODE_PRIMARY_HOSTNAME
> > .endif
> > 
> > MAIN_HARDCODE_PRIMARY_HOSTNAME never defined
> 
> So primary_hostname is set according to the docs
> (/usr/share/doc/exim4-base/spec.txt.gz):
> 
> $primary_hostname
> 
> This variable contains the value set by primary_hostname in the
> configuration file, or read by the uname() function. If uname() returns a
> single-component name, Exim calls gethostbyname() (or getipnodebyname()
> where available) in an attempt to acquire a fully qualified host name. See
> also $smtp_active_hostname.
> 
> The last sentence doesn't apply here. And we see that your
> gethostbyname returns the host name just fine.
> 
> What does getent hosts $IP for all your IP addresses say?

getent hosts 127.0.0.1
127.0.0.1   localhost

getent hosts 127.0.1.1
127.0.1.1   myhostname.mydomain.local myhostname

getent hosts 10.0.xx.xx # LAN address
10.0.xx.xx myhostname

getent hosts 10.0.yy.yy # WIFI address, now off
10.0.yy.yy  myhostname.mydomain.local

Strange difference between last two IPs. If I enable WIFI and disconnect
LAN, result is:

getent hosts 10.0.xx.xx # LAN address, now off
10.0.xx.xx myhostname.mydomain.local

getent hosts 10.0.yy.yy # WIFI address
10.0.yy.yy  myhostname

Seems to depend of /etc/nsswitch.conf hosts row items order, that is the
default one:

hosts:  files myhostname mdns4_minimal [NOTFOUND=return] dns

Moving dns in second position before myhostname, both addresses resolve
to myhostname.mydomain.local, but exim -bP | grep ^primary_hostname
stills report myhostname.

> > > and 192.168.0.10 is your local IP address on the network?
> > 
> > No , I obfuscate it, sorry. It actually is 10.0.xx.xx
> 
> Same thing, a RFC 1918 address that is unlikely to have correct
> reverse DNS.
> 
> > > Is your "myhostname.mydomain.local" the literal host name? If so, are
> > > you actually using the .local TLD or is that just obfuscated? Please
> > > consider using a different TLD as .local may cause interference with
> > > avahi (the .local TLD is reserved for use with mDNS).
> > 
> > Yes, domain ends with .local (this name comes from IT&C office
> > configuration).
> > 
> > Just for a try, I changed /etc/hosts and /etc/mailname to have a .net
> > TLD:
> > - exim -bP | grep ^primary_hostname says
> >   myhostname
> 
> Bad.
> 
> > - exim -bt -d+all username says
> >   10:13:17  5455 local_part=username domain=myhostname.mydomain.net
> >   10:13:17  5455 checking domains
> >   10:13:17  5455 myhostname.mydomain.net in "@:localhost"? no (end of
> > list)
> 
> Looks better, but why? Strangely, the process of qualifying the
> address is not in the debug output, first thing I see of the username
> is its already qualified form.

Sorry, I didn't paste all the log but only the part regarding domains.
Full log below.

Thanks again to spend your time with me :-)

Greetings
Mauro


11:30:16  6760 Exim version 4.87 uid=0 gid=0 pid=6760 D=fffd
Berkeley DB: Berkeley DB 5.3.28: (September  9, 2013)
Support for: crypteq iconv() IPv6 GnuTLS move_frozen_messages DKIM
DNSSEC Event OCSP PRDR SOCKS
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm
dbmjz dbmnz dnsdb dsearch nis nis0 passwd
Authenticators: cram_md5 plaintext
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore autoreply lmtp pipe smtp
Fixed never_users: 0
Size of off_t: 8
Compiler: GCC [4.9.2]
Library version: GnuTLS: Compile: 3.3.8
 Runtime: 3.3.8
Library version: PCRE: Compile: 8.35
   Runtime: 8.35 2014-04-04
11:30:16  6760 Total 13 lookups
WHITELIST_D_MACROS: "OUTGOING"
TRUSTED_CONFIG_LIST: "/etc/exim4/trusted_configs"
11:30:16  6760 changed uid/gid: forcing real = effective
11:30:16  6760   uid=0 gid=0 pid=6760
11:30:16  6760   auxiliary group list: 
11:30:16  6760 seeking password data for user "uucp": cache not
available
11:30:16  6760 getpwnam() succeeded uid=10 gid=10
11:30:16  6760 configuration file is /var/lib/exim4/config.autogenerated
11:30:16  6760 log selectors = cff

Bug#832415: Further information: upstream software works fine

[Rafael Laboissière]

* Eric S Fraga  [2016-07-25 17:50]:

Just a quick update: building the latest upstream version of octave 
along with the parallel package results in a system that works as it 
should.  No errors at all.


You mean, building Octave from source?

Which version?

Thanks,

Rafael Laboissière

Bug#832415: octave-parallel: Any attempt to use parcellfun leads to unhandled error in subprocesses

[Rafael Laboissière]

* Eric S Fraga  [2016-07-25 10:36]:


Package: octave-parallel
Version: 3.1.0-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

Any attempt to use parcellfun leads to errors such as these:

warning: parcellfun: unhandled error in subprocess 1 
warning: called from 
   parcellfun at line 291 column 9 
   [...] traceback on my own code elided 
error: '__exit__' undefined near line 311 column 7


Could you please provide a script that replicates the bug?

Thanks,

Rafael Laboissière

Bug#833296: exim4-config: dpkg-reconfigure exim4-config: misleading message

[Marc Haber]

On Wed, Aug 03, 2016 at 01:45:33PM +0200, Mauro Salvini wrote:
> On Wed, 2016-08-03 at 10:44 +0200, Marc Haber wrote:
> > What does getent hosts $IP for all your IP addresses say?
> 
> getent hosts 127.0.0.1
> 127.0.0.1   localhost
> 
> getent hosts 127.0.1.1
> 127.0.1.1   myhostname.mydomain.local myhostname
> 
> getent hosts 10.0.xx.xx   # LAN address
> 10.0.xx.xx myhostname

I would investgate this

> getent hosts 10.0.yy.yy   # WIFI address
> 10.0.yy.yy  myhostname

and this. This should give a fully qualified output as well, I think.

> Sorry, I didn't paste all the log but only the part regarding domains.

No problem, I meant my local exim -bt -d+all output I obtained. Yours
looks the same, the qualification process is not in the log. I'll post
a question on the upstream mailing list later today.

Greetings
Marc

-- 
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

Bug#833352: python-pykka: accesses the internet during build

[Chris Lamb]

Source: python-pykka
Version: 1.2.1-2
Severity: serious
Justification: Policy 4.9
User: la...@debian.org
Usertags: network-access

Dear Maintainer,

Whilst python-pykka builds successfully on unstable/amd64, according to
Debian Policy 4.9 packages may not attempt network access during
a build.

  00:00:00.00 IP c83daa2f7617.37572 > router.asus.com.domain: 64509+ A? 
docs.python.org. (33)
  00:00:00.47 IP c83daa2f7617.37572 > router.asus.com.domain: 33549+ ? 
docs.python.org. (33)

  [..]

This appears to be caused by (at least) Sphinx's intersphinx mapping extension.
Please see #830186 for more information, including suggestions on how to fix it.

The full build log (including tcpdump output) is attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-


python-pykka.1.2.1-2.unstable.amd64.log.txt.gz
Description: Binary data

Bug#823061: Dakuwaqa's Garden - Underwater footage from Fiji & Tonga - YouTube

[Jeffrey Robertson]

 

 

  UNBELIEVEABLY BEAUTIFUL

 

  very nice,almost like in the 
Philippines!http://www.youtube.com/embed/mcbHKAWIk3I

   

  

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

[Petter Reinholdtsen]

[NIIBE Yutaka]
> OK, I located the issue for ccid-driver.  It is fixed in our
> repository.
>
> master:
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=971064f8b7ad676326b2a468f688037a303717df
>
> 2.0.x:
> http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=c68d39f7114623075c0b407b05927b61b190a377
>
> I don't know if this is all for the problem, but it will improve the
> situation.

Thank you.  I just tested on a Raspberry Pi using the gnupg2/scdaemon
version 2.1.14-2 in Debian experimental, and this now segfaults when I
try 'gpg2 --card-status'.  But for some reason I can't get info from
valgrind, so here is the backtrace from gdb:

Program received signal SIGSEGV, Segmentation fault.
0xb6cbc020 in strlen () from /lib/arm-linux-gnueabihf/libc.so.6
(gdb) bt
#0  0xb6cbc020 in strlen () from /lib/arm-linux-gnueabihf/libc.so.6
#1  0x7f5b2174 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) 

But I do not quite understand why the old code should work on amd64 but
not on arm.

> Umm... IIUC, it is pcsc service which let "power on" the card.
> I don't know why it fails.
>
> Running pcscd foreground with debug option shows more information
> (I mean, pcscd --foreground --debug).
>
> Please see:
> http://ludovicrousseau.blogspot.jp/2011/07/pcscd-debug-output.html

Thanks.

-- 
Happy hacking
Petter Reinholdtsen

Bug#833339: hobbit-plugins missing permissions for /bin/btrfs

[Axel Beckert]

Control: notfound -1 20160122
Control: close -1

Hi,

Gürkan Sengün wrote:
> the included sudoers.d/xymon file is missing the line:
> xymon ALL=(root) NOPASSWD: /bin/btrfs
> 
> causing errors in the logging system.

Had a look at the issue and talked with Gürkan.

These messages has been caused by a local test and not by a
packaged test. Hence closing the bug report.

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#833340: mini-buildd: please make the build reproducible

[Chris Lamb]

user reproducible-bui...@lists.alioth.debian.org
usertags 833340 timestamps
thanks

Hi,

> mini-buildd: please make the build reproducible

- default=os.getenv("HOME"),
+ default="$HOME",

Unless I'm missing something, this won't work as $VARS are not expanded
in Python..

(What you probably want to do is set the default to ~/.mini-buildd and
patch the callsites to use os.path.expanduser at "real" runtime.)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-

Bug#833353: ITP: ocaml-result -- compatibility Result module

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu" 

* Package name: ocaml-result
  Version : 1.2
  Upstream Author : Jane Street Group, LLC
* URL : https://github.com/janestreet/result
* License : BSD
  Programming Lang: OCaml
  Description : compatibility Result module

 Projects that want to use the new result type defined in OCaml >=
 4.03 while staying compatible with older version of OCaml should use
 the Result module defined in this library.

This is a new dependency of janest-core.

Bug#833354: weird IRC quit/leave behaviour with plugin IRC More

[Jonas Meurer]

Package: pidgin-plugin-pack
Version: 2.7.0-2
Severity: normal

Hello,

it seems like the pidgin plugin 'IRC More' causes channel quit/leave to
behave weird.

First, leaving a channel is delayed with the plugin enabled. When I close
the channel tab in pidgin, it takes up to two minutes until the channel
receives a 'mejo has left' message. This is clearly not the case without the
IRC More plugin.

Second, this can lead to weird quit messages, when I rejoin the channel
within the delay. See the following leave message that was caused by leaving
and rejoining channel #quit_test on irc.oftc.net as nick 'mejo' with pidgin:

13:03 -!- mejo [~mejo@] has left #quit_test [JOIN #quit_test ]

Cheers,
 jonas

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

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

Versions of packages pidgin-plugin-pack depends on:
ii  libatk1.0-0 2.20.0-1
ii  libc6   2.23-4
ii  libcairo2   1.14.6-1+b1
ii  libenchant1c2a  1.6.0-11+b1
ii  libfontconfig1  2.11.0-6.4
ii  libfreetype62.6.3-3+b1
ii  libgdk-pixbuf2.0-0  2.34.0-1
ii  libglib2.0-02.48.1-2
ii  libgtk2.0-0 2.24.30-4
ii  libgtkspell02.0.16-1.1
ii  libpango1.0-0   1.40.1-1
ii  libpurple0  2.11.0-1

pidgin-plugin-pack recommends no packages.

pidgin-plugin-pack suggests no packages.

-- no debconf information

Bug#833355: Please package new upstream version with ucode files for Intel Wireless 8260

[Jonas Meurer]

Package: firmware-iwlwifi
Version: 20160110-1
Severity: important

Hello,

for the Intel Wireless 8260 controller, several ucode files are missing,
that are published upstream:

# lspci -v -s 04:00.0
04:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)
Subsystem: Intel Corporation Wireless 8260
Flags: bus master, fast devsel, latency 0, IRQ 126
Memory at f100 (64-bit, non-prefetchable) [size=8K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [100] Advanced Error Reporting
Capabilities: [140] Device Serial Number 44-85-00-ff-ff-12-53-bd
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [154] L1 PM Substates
Kernel driver in use: iwlwifi
Kernel modules: iwlwifi

# dmesg |grep iwlwifi
[   21.639144] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-21.ucode (-2)
[   21.639149] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-21.ucode failed with error -2
[   21.639159] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-20.ucode (-2)
[   21.639162] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-20.ucode failed with error -2
[   21.639169] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-19.ucode (-2)
[   21.639176] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-19.ucode failed with error -2
[   21.639184] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-18.ucode (-2)
[   21.639190] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-18.ucode failed with error -2
[   21.639197] iwlwifi :04:00.0: firmware: failed to load 
iwlwifi-8000C-17.ucode (-2)
[   21.639203] iwlwifi :04:00.0: Direct firmware load for 
iwlwifi-8000C-17.ucode failed with error -2
[   21.639458] iwlwifi :04:00.0: Unsupported splx structure
[   21.645714] iwlwifi :04:00.0: firmware: direct-loading firmware 
iwlwifi-8000C-16.ucode
[   21.646255] iwlwifi :04:00.0: loaded firmware version 16.242414.0 
op_mode iwlmvm

# cat /proc/version
Linux version 4.6.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 5.4.0 
20160609 (Debian 5.4.0-6) ) #1 SMP Debian 4.6.4-1 (2016-07-18)

The missing ucode files are distributed upstream at
https://git.kernel.org/cgit/linux/kernel/git/iwlwifi/linux-firmware.git/tree/

Greetings,
 jonas

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

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

firmware-iwlwifi depends on no packages.

firmware-iwlwifi recommends no packages.

Versions of packages firmware-iwlwifi suggests:
ii  initramfs-tools  0.125

-- no debconf information

Bug#833053: Syntax error in the script that setupcon outputs

[Anton Zinoviev]

On Tue, Aug 02, 2016 at 10:43:45PM +0200, Philip Hands wrote:
> It looks like there are a couple of other instances of the potentially
> empty braces problem in this script, so we could address them at the
> same time just in case.

I agree.  Even if the current script didn't have more empty braces 
problems, it would be safer to protect against bugs caused by future 
changes.
 
> How about just adding : to each brace, as in the following patch.

I like this solution.

Anton Zinoviev

Bug#833356: ITP: mysql-cluster -- Official fork of mysql. Support master-master replication

[Viktor Krivak]

Package: wnpp
Severity: wishlist
Owner: Viktor Krivak 

* Package name: mysql-cluster
  Version : 7.4.11
* URL : http://www.mysql.com/products/cluster/
* License : GPLv2
  Programming Lang: C++
  Description : Official fork of mysql. Support master-master replication.

Mysql cluster is highly scalable, multi-master database with 99.999% 
availability. It is an official fork of mysql maintained by Oracle.
Main difference from "pure" mysql is an additional storage engine called 
ndbcluster. This engine allows distribution across multiple servers to provide 
data high availability and scalability. Supports in-memory and disk based data, 
automatic load-balancing and rolling restart with zero downtime.
In comparison to "pure" mysql server cluster contains 2 new services management 
(ndb_mgm) and storage (ndbd). It requires at least 4 servers for a meaningful 
installation (it is possible to use just one server, but only for testing).

Some scripts in package can be copied from mysql-server package. I would like 
to place this package under:
MySQL maintainers  team since there 
are many similarities with other mysql-like databases.

Bug#833340: mini-buildd: please make the build reproducible

[Boyuan Yang]

Control: user reproducible-bui...@lists.alioth.debian.org
Control: usertags -1 environment
X-Debbugs-Cc: reproducible-bui...@lists.alioth.debian.org

2016-08-03 20:14 GMT+08:00 Chris Lamb :
> - default=os.getenv("HOME"),
> + default="$HOME",
>
> Unless I'm missing something, this won't work as $VARS are not expanded
> in Python..
>
> (What you probably want to do is set the default to ~/.mini-buildd and
> patch the callsites to use os.path.expanduser at "real" runtime.)

I intended to use "$HOME" string literally since I did not come up
with a better solution. :-(

The original author used os.getenv() in python argparse, so the output
of `mini-buildd --help' really depend on $HOME env var. Unfortunately
the man page is generated using help2man (or similar tool) [1] during
building process and reproducible build website will alter $HOME env
var to test reproducibility. So in my opinion there is no better
option except fixed text string. Mini-buildd script won't and
shouldn't detect if itself is running for help2man or for end-user.

[1] 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/armhf/diffoscope-results/mini-buildd.html

Thanks,
Boyuan

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

[NIIBE Yutaka]

On 08/03/2016 09:03 PM, Petter Reinholdtsen wrote:
> Thank you.  I just tested on a Raspberry Pi using the gnupg2/scdaemon
> version 2.1.14-2 in Debian experimental, and this now segfaults when I
> try 'gpg2 --card-status'.  But for some reason I can't get info from
> valgrind, so here is the backtrace from gdb:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0xb6cbc020 in strlen () from /lib/arm-linux-gnueabihf/libc.so.6
> (gdb) bt
> #0  0xb6cbc020 in strlen () from /lib/arm-linux-gnueabihf/libc.so.6
> #1  0x7f5b2174 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
> (gdb) 

arm-linux-gnueabihf ?  Your original report says "armel" in the
subject.

According to https://wiki.debian.org/RaspberryPi, it seems armel.

> But I do not quite understand why the old code should work on amd64 but
> not on arm.

I don't think architecture matters.  IIUC, the problem is Raspberry Pi
specific, reader specific, or the combination of board and reader.

Please note that it works both on armel and armhf on my environment
with Gnuk Token and some other readers.
-- 

Bug#833357: corosync: Update to 2.3.6 fails with specific configuration / upstream fixed

[Patrick Matthäi]

Package: corosync
Version: 2.3.6-2
Severity: serious
Tags: patch upstream

Hi,

updating corosync from 2.3.5 to 2.3.6 fails with some configurations (as I
already reported to the bpo list) with:
"can't autogenerate multicast address"

Upstream report and patch: https://github.com/corosync/corosync/issues/137

Please apply the patch and I would also welcome updated backports packages :)

Here is one of my /etc/corosync/corosync.conf configurations, with that it is
reproduceable:

totem {
version: 2
token: 3000
token_retransmits_before_loss_const: 10
clear_node_high_bit: yes
crypto_cipher: none
crypto_hash: none
transport: udpu
interface {
ringnumber: 0
bindnetaddr: 192.168.99.0
}
}

logging {
to_logfile: yes
logfile: /var/log/corosync/corosync.log
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}

quorum {
provider: corosync_votequorum
two_node: 1
wait_for_all: 1
}

nodelist {
node {
ring0_addr: nd1-1-cs
}
node {
ring0_addr: nd1-2-cs
}
}



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

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

Bug#833340: mini-buildd: please make the build reproducible

[Chris Lamb]

> The original author used os.getenv() in python argparse, so the output
> of `mini-buildd --help' really depend on $HOME env var

I agree that upstream are using an environment variable called HOME and
note that it ends up in the manpage.

However, this does not imply that the string "$HOME" will be interpolated,
so your patch breaks mini-buildd.

> Unfortunately in my opinion there is no better option except fixed text
> string.

A fixed text string is indeed required, but "$HOME" is not that string :)
What's wrong with my expanduser suggestion?

Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
--- a/mini-buildd   2016-08-03 08:56:33.531642844 -0400
--- b/mini-buildd   2016-08-03 09:08:26.614952941 -0400
@@ -77,9 +77,9 @@
 help="SMTP credentials in format 
'[USER]:[PASSWORD]@smtp|ssmtp://HOST:PORT'.")
 group_conf.add_argument("-U", "--dedicated-user", action="store", 
default="mini-buildd",
 help="Force a custom dedicated user name (to 
run as a different user than 'mini-buildd').")
-group_conf.add_argument("-H", "--home", action="store", 
default=os.getenv("HOME"),
+group_conf.add_argument("-H", "--home", action="store", default="~",
 help="Run with this home dir. The only use 
case to change this for debugging, really.")
-group_conf.add_argument("-F", "--pidfile", action="store", 
default=os.path.join(os.getenv("HOME"), ".mini-buildd.pid"),
+group_conf.add_argument("-F", "--pidfile", action="store", 
default="~/.mini-buildd.pid",
 help="Set pidfile path.")
 group_conf.add_argument("-f", "--foreground", action="store_true",
 help="Don't daemonize, log to console.")
@@ -118,6 +118,9 @@
 if args.set_admin_password or args.loaddata or args.dumpdata:
 args.foreground = True
 
+args.home = os.path.expanduser(args.home)
+args.pidfile = os.path.expanduser(args.pidfile)
+
 return args
 
 def _setup(self):

Bug#830613: python-ws4py: accesses the internet during build

[Stein Magnus Jodal]

Thanks! I'll make sure to fix this in the next upload.

Stein Magnus

Bug#833358: lua-bitop-dev: bad "Requires:" in pkg-config file

[Marc Becker]

Package: lua-bitop-dev
Version: 1.0.2-3
Severity: normal

Bad "Requires:" entry in /usr/lib/x86_64-linux-gnu/pkgconfig/lua5.2-bitop.pc

$ pkg-config --libs lua5.2-bitop
-llua5.2-bitop -llua5.1

Same problem in lua-posix-dev (and possibly others).

Short time fix:
Depend on `lua5.2` in Lua 5.2 module pkg-config files.

Long term (suggestion) Debian 9+:
Remove runtime library requirement.
It does not protect against Lua runtime version missmatch
and makes pkg-config not usable for building libraries which
only need to link in other Lua modules.


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

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

Versions of packages lua-bitop-dev depends on:
ii  lua-bitop  1.0.2-3
ii  multiarch-support  2.19-18+deb8u4

lua-bitop-dev recommends no packages.

lua-bitop-dev suggests no packages.

-- no debconf information

Bug#814584: gnupg2: gpg2 --card-status fail on armel / Raspberry Pi - "Card error"

[Petter Reinholdtsen]

[NIIBE Yutaka]
> arm-linux-gnueabihf ?  Your original report says "armel" in the
> subject.
>
> According to https://wiki.debian.org/RaspberryPi, it seems armel.

My original test was done using a Freedombox image, which was armel.

Todays test was done using some random RPi and SD card I found on my
desk and I did not notice it was using a different architecture.  I can
try again on armel, if you believe it mattes.

> I don't think architecture matters.  IIUC, the problem is Raspberry Pi
> specific, reader specific, or the combination of board and reader.
>
> Please note that it works both on armel and armhf on my environment
> with Gnuk Token and some other readers.

Right.  Good to know.

-- 
Happy hacking
Petter Reinholdtsen

Bug#832931: mariadb-10.0: FTBFS on powerpc

[Otto Kekäläinen]

Hello!

I don't understand this fully. The build overview at
https://buildd.debian.org/status/logs.php?pkg=mariadb-10.0&arch=powerpc
shows 10.0.26 building mostly fine for powerpc. Can you trigger a
rebuild to see if it was sporadic?

Anyway, I have forwarded this to upstream developers.

Bug#833352: python-pykka: accesses the internet during build

[Stein Magnus Jodal]

On Wed, Aug 03, 2016 at 01:55:43PM +0200, Chris Lamb wrote:
> Whilst python-pykka builds successfully on unstable/amd64, according to
> Debian Policy 4.9 packages may not attempt network access during
> a build.
> 
>   00:00:00.00 IP c83daa2f7617.37572 > router.asus.com.domain: 64509+ A? 
> docs.python.org. (33)
>   00:00:00.47 IP c83daa2f7617.37572 > router.asus.com.domain: 33549+ 
> ? docs.python.org. (33)
> 
>   [..]
> 
> This appears to be caused by (at least) Sphinx's intersphinx mapping 
> extension.
> Please see #830186 for more information, including suggestions on how to fix 
> it.

Thanks! I'll make sure to fix this in the next upload.

Stein Magnus

Bug#832489: tzdata-java: The Debian 8 package tzdata-java without support openjdk8

[Matthias Klose]

Control: reassign -1 src:tzdata

openjdk-8 now ships it's own timezone data base, which cannot be derived from
tzdata unfortunately. The tzdata-java packages need to be removed.

Bug#832965: Debug information

[Florian Gruel]

Here is the ~/.cache/shotwell/shotwell.log file, if this helps to locate the 
debug in the startup sequence 

L 13661 2016-08-03 14:48:19 [MSG] main.vala:385: Shotwell Gestionnaire de 
photos 0.22.1
L 13661 2016-08-03 14:48:19 [MSG] main.vala:43: Verifying database ...
L 13661 2016-08-03 14:48:19 [MSG] VideoSupport.vala:380: interpreter state has 
changed; video thumbnails may be out of date
L 13661 2016-08-03 14:48:22 [MSG] VideoSupport.vala:432: offline video 
thumbnail regeneration completed
L 13661 2016-08-03 14:48:23 [WRN] DirectoryMonitor.vala:916: Skipping hidden 
file/directory /home/flo/Images/wallpapers/.last


On Sat, 30 Jul 2016 15:45:10 +0200 Thomas Clavier 
mailto:t...@tcweb.org>> wrote:
> When i follow that : https://wiki.gnome.org/Apps/Shotwell/ReportingABug
>
> I have more information ... not more clear for me :-(
>
> Thread 18 "typefind:sink" received signal SIGABRT, Aborted.
> [Switching to Thread 0x7fffb57fb700 (LWP 5847)]
> 0x7fffef0871c8 in __GI_raise (sig=sig@entry=6) at
> ../sysdeps/unix/sysv/linux/raise.c:54
> 54 ../sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier de ce
> type.
> (gdb) backtrace full
> #0  0x7fffef0871c8 in __GI_raise (sig=sig@entry=6) 
> at
> ../sysdeps/unix/sysv/linux/raise.c:54
> resultvar = 0
> pid = 5823
> selftid = 5847
> #1  0x7fffef08864a in __GI_abort () at abort.c:89
> save_stage = 2
> act =
>   {__sigaction_handler = {sa_handler = 0x20, sa_sigaction =
> 0x20}, sa_mask = {__val = {140735784987356, 140735786239565, 142,
> 140735785006582, 140735878215680, 8, 140735772823153, 140735878212096,
> 13609419723004720896, 140735790291200, 140735878215680,
> 140735878216832, 13609419723004720896, 1136, 140735790101616,
> 140735878215680}}, sa_flags = -1610143232, sa_restorer = 0x7fffa00726f0}
> sigs = {__val = {32, 0 }}
> #2  0x7fff9a35360b in  () at
> /usr/lib/x86_64-linux-gnu/libavcodec.so.57
> #3  0x7fff9a3536d6 in avcodec_alloc_context3 () at
> /usr/lib/x86_64-linux-gnu/libavcodec.so.57
> #4  0x7fffb45e0540 in  () at
> /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
> #5  0x7fffb45d6e53 in  () at
> /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
> #6  0x70b1f22d in g_type_class_ref (pclass=0x7fffa00726f0,
> node=0x7fffa0072410)
> at /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2241
> slist = 
> init_slist = 
> i = 
> class = 0x7fffa0072a00
> entries = 
> entry = 
> bnode = 
> ptype = 
> holds_ref = 
> pclass = 
> #7  0x70b1f22d in g_type_class_ref (type=) at
> /build/glib2.0-vjfO_h/glib2.0-2.48.1/./gobject/gtype.c:2956
> ptype = 
> holds_ref = 
> pclass = 
> #8  0x76bfada4 in gst_element_register () at
> /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0
> #9  0x7fffb45d75b3 in  () at
> /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
> #10 0x7fffb45c9e20 in  () at
> /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so
> #11 0x76c1c537 in  () at
> /usr/lib/x86_64-linux-gnu/libgstreamer-1.0.so.0

Bug#833359: ITP: lefse -- determine features of organisms, clades, taxonomic units, genes

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: lefse
  Version : 1.0+20160802
  Upstream Author : Nicola Segata 
* URL : https://bitbucket.org/biobakery/biobakery/wiki/lefse
* License : expat
  Programming Lang: Python
  Description : determine features of organisms, clades, taxonomic units, 
genes
 LEfSe (Linear discriminant analysis Effect Size) determines the features
 (organisms, clades, operational taxonomic units, genes, or functions)
 most likely to explain differences between classes by coupling standard
 tests for statistical significance with additional tests encoding
 biological consistency and effect relevance.


Remark: This package is a precondition for metaBIT and will be maintained
by the Debian Med team at
https://anonscm.debian.org/git/debian-med/lefse.git

Bug#833340: mini-buildd: please make the build reproducible

[Boyuan Yang]

2016-08-03 21:11 GMT+08:00 Chris Lamb :
>> The original author used os.getenv() in python argparse, so the output
>> of `mini-buildd --help' really depend on $HOME env var
>
> I agree that upstream are using an environment variable called HOME and
> note that it ends up in the manpage.
>
> However, this does not imply that the string "$HOME" will be interpolated,
> so your patch breaks mini-buildd.

Sorry, it is indeed my mistake.

> What's wrong with my expanduser suggestion?
>
> Patch attached.

If we need to expand earlier or later, what is the difference between
current situation and patched version? Home directory will eventually
expand to difference strings due to different $HOME env var, and the
package will be unreproducible. Also, this patch should not be alone,
since we need to add os.path.expanduser() somewhere else.

> ... patch the callsites to use os.path.expanduser at "real" runtime

How do we know if the script is running at "real" runtime?

Thanks,
Boyuan

Bug#832965: Debug information

[Florian Gruel]

here is the content of shotwell.gdb :

GNU gdb (Debian 7.11.1-2) 7.11.1
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show
copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from shotwell...Reading symbols from
/usr/lib/debug/.build-
id/23/77967f2f067ca208d142c9828125638d72bc15.debug...done.
done.
(gdb) run
Starting program: /usr/bin/shotwell 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-
gnu/libthread_db.so.1".
[New Thread 0x7fffe0d8c700 (LWP 17131)]
[New Thread 0x7fffe058b700 (LWP 17132)]
[New Thread 0x7fffdd47e700 (LWP 17133)]
[New Thread 0x7fffdcc7d700 (LWP 17134)]
[New Thread 0x7fffc700 (LWP 17135)]
[New Thread 0x7fffcf7fe700 (LWP 17136)]
[New Thread 0x7fffceffd700 (LWP 17137)]

(shotwell:17126): Gtk-WARNING **: Theme parsing error: :2:38: The
style property GtkPaned:handle-size is deprecated and shouldn't be used
anymore. It will be removed in a future version
[New Thread 0x7fffce6fb700 (LWP 17138)]
[New Thread 0x7fffcd490700 (LWP 17139)]
[Thread 0x7fffcd490700 (LWP 17139) exited]
[New Thread 0x7fffcd490700 (LWP 17140)]
[Thread 0x7fffcd490700 (LWP 17140) exited]
[New Thread 0x7fffcd490700 (LWP 17141)]
[Thread 0x7fffcd490700 (LWP 17141) exited]
[New Thread 0x7fffcd490700 (LWP 17142)]
[Thread 0x7fffcd490700 (LWP 17142) exited]
[New Thread 0x7fffcd490700 (LWP 17143)]
[New Thread 0x7fffccc8f700 (LWP 17148)]
[New Thread 0x7fffa700 (LWP 17149)]
[New Thread 0x7fffaf7fe700 (LWP 17150)]
[New Thread 0x7fffaeffd700 (LWP 17151)]
[New Thread 0x7fffae7fc700 (LWP 17152)]
[New Thread 0x7fffadffb700 (LWP 17153)]
[New Thread 0x7fffad7fa700 (LWP 17154)]
[New Thread 0x7fffacb8c700 (LWP 17155)]
[New Thread 0x7fff8700 (LWP 17156)]
[New Thread 0x7fff8f7fe700 (LWP 17157)]
[Thread 0x7fffadffb700 (LWP 17153) exited]
[Thread 0x7fffa700 (LWP 17149) exited]
[Thread 0x7fffccc8f700 (LWP 17148) exited]
[Thread 0x7fffaeffd700 (LWP 17151) exited]
[New Thread 0x7fffaeffd700 (LWP 17174)]
[New Thread 0x7fffccc8f700 (LWP 17175)]
[New Thread 0x7fffa700 (LWP 17176)]
[New Thread 0x7fffadffb700 (LWP 17177)]
[New Thread 0x7fff78ae0700 (LWP 17178)]
L 17126 2016-08-03 15:24:02 [CRT] PhotoMonitor.vala:1069: Unable to
reimport [13987] /home/flo/Images/2015/05/09/dsc06392.jpg due to master
file changing: Fin précoce de flux inattendue
L 17126 2016-08-03 15:24:02 [CRT] PhotoMonitor.vala:1069: Unable to
reimport [13984] /home/flo/Images/2015/05/09/dsc06389.jpg due to master
file changing: Fin précoce de flux inattendue
L 17126 2016-08-03 15:24:02 [CRT] PhotoMonitor.vala:1069: Unable to
reimport [13988] /home/flo/Images/2015/05/09/dsc06393.jpg due to master
file changing: Fin précoce de flux inattendue
L 17126 2016-08-03 15:24:02 [CRT] PhotoMonitor.vala:1069: Unable to
reimport [13985] /home/flo/Images/2015/05/09/dsc06391.jpg due to master
file changing: Fin précoce de flux inattendue
L 17126 2016-08-03 15:24:02 [CRT] PhotoMonitor.vala:1069: Unable to
reimport [13986] /home/flo/Images/2015/05/09/dsc06390.jpg due to master
file changing: Fin précoce de flux inattendue
L 17126 2016-08-03 15:24:02 [CRT] PhotoMonitor.vala:1069: Unable to
reimport [13983] /home/flo/Images/2015/05/09/dsc06388.jpg due to master
file changing: Fin précoce de flux inattendue
[Thread 0x7fff78ae0700 (LWP 17178) exited]
[Thread 0x7fffa700 (LWP 17176) exited]
[Thread 0x7fffccc8f700 (LWP 17175) exited]
[Thread 0x7fffaeffd700 (LWP 17174) exited]
[Thread 0x7fffae7fc700 (LWP 17152) exited]
[Thread 0x7fffaf7fe700 (LWP 17150) exited]
[Thread 0x7fffcd490700 (LWP 17143) exited]

Thread 23 "multiqueue0:src" received signal SIGABRT, Aborted.
[Switching to Thread 0x7fff8700 (LWP 17156)]
0x7fffef0871c8 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
54  ../sysdeps/unix/sysv/linux/raise.c: Aucun fichier ou dossier
de ce type.
(gdb) 
(gdb) backtrace full
Python Exception  Attempt to dereference a generic
pointer.: 
#0  0x7fffef0871c8 in __GI_raise (sig=sig@entry=6) at
../sysdeps/unix/sysv/linux/raise.c:54
resultvar = 0
pid = 17126
selftid = 17156
#1  0x7fffef08864a in __GI_abort () at abort.c:89
save_stage = 2
act = 
  {__sigaction_handler = {sa_handler = 0x20, sa_sigaction =
0x20}, sa_mask = {__val = {140735562013404, 140735563265613, 142,
140735562032630, 140735476058528, 8, 140735549849201, 140735476057040,
4720083191924324608, 140

Bug#833360: Kmidimon - French translation

[trebmuh]

Package: kmidimon
Version: 0.7.5-2

Dear debian maintainers,

just to let you know that I've been doing a french translation of 
kmidimon which has been incorporated upstream in rev 201 as you can find 
here : https://sourceforge.net/p/kmidimon/code/201/ .


I'm copying Pedro Lopez Cabanillas (who is upstream) to this email in 
case he might want to be in the loop.


Hope that helps,
Olivier

Bug#809022: [debian-mysql] Bug#809022: autopkgtest patch for MariaDB

[Otto Kekäläinen]

Unfortunately it seems that this ci test fails in Debian production CI
systems: https://ci.debian.net/packages/m/mariadb-10.0/unstable/amd64/

Can you help here? Should the test have libmariadbclient18 installed
before it runs?

Bug#831510: [pkg-gnupg-maint] Bug#831510: gnupg2: Deletes pub keyring

[Werner Koch]

On Sun, 31 Jul 2016 19:24, k...@roeckx.be said:

> time does the wrong thing.  For instance it could move the file to
> the .bak file and then create a new (or tmp) file, and you would
> end up with having no file for some time.

Right.  We write a new file, rename the old to .bak, and then rename the
new file to the original name.  Signals at the wrong time would leave
you only with the .bak and the next time gpg starts it does not find a
keyring and creates a new one which now defaults to .kbx.

I just pushed a fix for this which blocks all signals during the
renames.  Not really tested, though.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf   */

Bug#833361: runit: Init files (/etc/runit/*) should be provided by runit-init not runit

[Mat]

Package: runit
Version: 2.1.2-5
Severity: normal
Tags: patch

 The files in /etc/runit/ are only required when runit is running as
 PID 1, so they are logically part of the runit-init package.

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

Kernel: Linux 4.6.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to en_IE.utf-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages runit depends on:
ii  libc6  2.23-4

runit recommends no packages.

Versions of packages runit suggests:
ii  socklog-run  2.1.0-8

-- no debconf information

*** /tmp/runit-init.patch
diff --git a/runit-init.install b/runit-init.install
index 049efb1..2827a1f 100755
--- a/runit-init.install
+++ b/runit-init.install
@@ -1,3 +1,6 @@
 #!/usr/bin/dh-exec
 runit-2.1.2/src/runit-init => /sbin/init
 runit-2.1.2/src/runit  /sbin
+runit-*/etc/debian/1   /etc/runit
+runit-*/etc/2  /etc/runit
+runit-*/etc/debian/3   /etc/runit
diff --git a/runit.install b/runit.install
index d4c8fec..87a81f5 100644
--- a/runit.install
+++ b/runit.install
@@ -8,7 +8,3 @@ runit-*/src/svlogd /usr/bin
 runit-*/src/chpst  /usr/bin
 runit-*/src/runsvchdir /usr/sbin
 runit-*/src/utmpset/usr/sbin
-
-runit-*/etc/debian/1   /etc/runit
-runit-*/etc/2  /etc/runit
-runit-*/etc/debian/3   /etc/runit
\ No newline at end of file

Bug#831500: [pkg-gnupg-maint] Bug#831500: gnupg: Please declare that GnuPG 2.x breaks debsig-verify

[Werner Koch]

On Sat, 16 Jul 2016 18:11, guil...@debian.org said:

> The debsig-verify program parses gpg --list-packets output, but its
> parser was not very lenient of different but valid input. With GnuPG

--list-packets is more of a debugging aid than a fixed API.  You should
not use it in other ways.

Why do you need it at all?  Maybe we can find a better solution.


Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.
 /* Join us at OpenPGP.conf   */

Bug#833328: [Pkg-openssl-devel] Bug#833328: Please close or delete this issue.

[Mihail Artamonov]

I have using additional mirror for ha-proxy packages:
# deb http://httpredir.debian.org/debian jessie-backports main

And I have updated openssl via "apt-get install openssl -t jessie-backports"

Now I have:
ii  openssl1.0.2h-1~bpo8+1 amd64
ii  libssl1.0.0:amd64  1.0.2h-1~bpo8+1 amd64

And all are working fine.

On Wed, Aug 3, 2016 at 2:08 PM, Sebastian Andrzej Siewior
 wrote:
> On 2016-08-03 11:00:18 [+0300], Mihail Artamonov wrote:
>> Hello, this problem was solved. Thank you!
>
> What changed in the last 9 minutes that solved the problem?
>
> Sebastian

Bug#833360: Kmidimon - French translation

[James Cowgill]

Control: tags -1 fixed-upstream

Hi,

On 03/08/16 14:38, treb...@tuxfamily.org wrote:
> Package: kmidimon
> Version: 0.7.5-2
> 
> Dear debian maintainers,
> 
> just to let you know that I've been doing a french translation of
> kmidimon which has been incorporated upstream in rev 201 as you can find
> here : https://sourceforge.net/p/kmidimon/code/201/ .
> 
> I'm copying Pedro Lopez Cabanillas (who is upstream) to this email in
> case he might want to be in the loop.

While this could be patched into the Debian version, it would be
preferable to have a new upstream release.

Pedro, if you do make a new release, could you include this patch as well?

https://sources.debian.net/src/kmidimon/0.7.5-2/debian/patches/01-remove-uninstall-target.patch/

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#833362: ITP: ppx-driver -- feature-full driver for OCaml AST transformers

[Stéphane Glondu]

Package: wnpp
Severity: wishlist
Owner: "Stéphane Glondu" 

* Package name: ppx-driver
  Version : 113.33.03
  Upstream Author : Jane Street Group LLC
* URL : https://github.com/janestreet/ppx_driver
* License : Apache-2.0
  Programming Lang: OCaml
  Description : feature-full driver for OCaml AST transformers

 A driver is an executable created from a set of OCaml AST
 transformers linked together with a command line frontend.
 .
 The aim is to provide a tool that can be used to:
 .
  * easily view the pre-processed version of a file, no need to
construct a complex command line: `ppx file.ml` will do
  * use a single executable to run several transformations: no need to
fork many times just for pre-processing
  * improved errors for misspelled/misplaced attributes and extension
points

This package is a new dependency of ocaml-ipaddr.

Bug#830344: How should the TC help with a project roadmap?

[Sam Hartman]

I'm not really advocating that the TC would be a very good help promote
your ideas team.
However, I'm struck by the following even if I don't entirely know what
to make of it.

> "Ian" == Ian Jackson  writes:


Ian>  * To be accessible and approachable, and not judgemental.

Ian>  * To have the communication and technical skills to help
Ian> someone with an idea produce clear and cogent explanations.

Ian>  * To have high status and high visibility, so that when they
Ian> introduce someone driving a project to stakeholders, they get
Ian> airtime.

Ian>  * Ideally to contain people with few enemies.

Ian>  * To be dynamic and novelty-oriented.

I'll note that with the exception of the last bullet point, that's
fairly close to what I'd hope to see out of a TC.
The last bullet point may well be important in this context.

Yes, sometimes the TC will need to make judgments, but I think that to
do its job and actually collect information, it needs to be perceived as
non-judgmental in the sense you mean above.

Bug#832623: flashplugin-nonfree: New upstream flash version 22.0.0.209

[Dario Andres Susman]

Package: flashplugin-nonfree
Followup-For: Bug #832623

Dear Maintainer,

Browser Firefox ESR 45.2.0 reports current flash plugin is vulnerable/outdated.

I've attempted to update, but seems that it hasn't been uploaded yet.


root@fgx-laptop:~# update-flashplugin-nonfree --install --verbose
options :  --install --verbose --
temporary directory: /tmp/flashplugin-nonfree.E0Cs8u6iVy
importing public key ...
selected action = --install
installed version = 11.2.202.626
upstream version = 22.0.0.209
wgetoptions= -nd -P .   -v --progress=dot:default 
downloading 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.22.0.0.209.sha512.amd64.pgp.asc
 ...
--2016-08-03 10:42:28--  
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.22.0.0.209.sha512.amd64.pgp.asc
Resolving people.debian.org (people.debian.org)... 5.153.231.30, 
2001:41c8:1000:21::21:30
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:80... 
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: 
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.22.0.0.209.sha512.amd64.pgp.asc
 [following]
--2016-08-03 10:42:29--  
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.22.0.0.209.sha512.amd64.pgp.asc
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443... 
connected.
HTTP request sent, awaiting response... 404 Not Found
2016-08-03 10:42:30 ERROR 404: Not Found.

wget failed to download 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp.22.0.0.209.sha512.amd64.pgp.asc
downloading 
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc
 ...
--2016-08-03 10:42:30--  
http://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc
Resolving people.debian.org (people.debian.org)... 5.153.231.30, 
2001:41c8:1000:21::21:30
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:80... 
connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: 
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc
 [following]
--2016-08-03 10:42:31--  
https://people.debian.org/~bartm/flashplugin-nonfree/D5C0FC14/fp10.sha512.amd64.pgp.asc
Connecting to people.debian.org (people.debian.org)|5.153.231.30|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: 1250 (1.2K) [text/plain]
Saving to: ‘./fp10.sha512.amd64.pgp.asc’

 0K . 100% 64.3M=0s

2016-08-03 10:42:32 (64.3 MB/s) - ‘./fp10.sha512.amd64.pgp.asc’ saved 
[1250/1250]

verifying PGP fp10.sha512.amd64.pgp.asc ...
copying 
/var/cache/flashplugin-nonfree/install_flash_player_11_linux.x86_64.tar.gz ...
verifying checksum install_flash_player_11_linux.x86_64.tar.gz ...
wgetoptions= -nd -P .   -v --progress=dot:default  -O 
/tmp/flashplugin-nonfree.E0Cs8u6iVy/install_flash_player_11_linux.x86_64.tar.gz
downloading 
https://fpdownload.adobe.com/get/flashplayer/pdc/11.2.202.626/install_flash_player_11_linux.x86_64.tar.gz
 ...
verifying checksum install_flash_player_11_linux.x86_64.tar.gz ...
unpacking install_flash_player_11_linux.x86_64.tar.gz ...
verifying checksum contents of install_flash_player_11_linux.x86_64.tar.gz ...
moving libflashplayer.so to /usr/lib/flashplugin-nonfree ...
setting permissions and ownership of 
/usr/lib/flashplugin-nonfree/libflashplayer.so ...
Flash Player version: 11.2.202.626
moving install_flash_player_11_linux.x86_64.tar.gz to 
/var/cache/flashplugin-nonfree ...
flash-mozilla.so - auto mode
  link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'.
calling update-alternatives ...
flash-mozilla.so - auto mode
  link currently points to /usr/lib/flashplugin-nonfree/libflashplayer.so
/usr/lib/flashplugin-nonfree/libflashplayer.so - priority 50
Current 'best' version is '/usr/lib/flashplugin-nonfree/libflashplayer.so'.
removing /usr/bin/flash-player-properties
removing /usr/share/applications/flash-player-properties.desktop
removing /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png
removing /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png
removing /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png
removing /usr/share/icons/hicolor/32x32/apps/flash-player-properties.png
removing /usr/share/icons/hicolor/48x48/apps/flash-player-properties.png
removing /usr/share/pixmaps/flash-player-properties.png
installing /usr/bin/flash-player-properties
installing /usr/share/applications/flash-player-properties.desktop
installing /usr/share/icons/hicolor/16x16/apps/flash-player-properties.png
installing /usr/share/icons/hicolor/22x22/apps/flash-player-properties.png
installing /usr/share/icons/hicolor/24x24/apps/flash-player-properties.png
installing /usr/share/icons/hicolor/32x32/apps/flash-player-proper

Bug#833363: python-debian: please improve message when passing incorrect type to iter_paragraphs

[Chris Lamb]

Source: python-debian
Version: 0.1.28
Tags: patch
Severity: wishlist

Hi,

The attached patch replaces:

 TypeError: bytes or unicode/string required

with:

 TypeError: bytes or unicode/string required, not 

.. which is a little more useful for developers - they are almost
certainly going to do the same thing manually when debugging. :)


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index c1dcb17..403fd95 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -1269,7 +1269,7 @@ class _gpg_multivalued(_multivalued):
 return s
 if isinstance(s, six.string_types):
 return s.encode(encoding)
-raise TypeError('bytes or unicode/string required')
+raise TypeError('bytes or unicode/string required, not %s' % type(s))
 
 
 class Dsc(_gpg_multivalued):

Bug#833361: runit: Init files (/etc/runit/*) should be provided by runit-init not runit

[Dmitry Bogatov]

> Package: runit
> Version: 2.1.2-5
> Severity: normal
> Tags: patch
>
>  The files in /etc/runit/ are only required when runit is running as
>  PID 1, so they are logically part of the runit-init package.

Almost. Both runit-systemd and runit-sysv requires /etc/runit/2.
/etc/runit/{1,3} are really only needed by runit-init.
But I find it ugly to separate them. WTDYT?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#833364: O: gtkglext -- OpenGL Extension to GTK+

[Bart Martens]

Package: wnpp
Severity: normal

I hereby orphan this package due to lack of time to maintain it properly.

Bug#810978: mobile-broadband-provider-info: Please package new version 20151214

[W. Martin Borgert]

Dear Bhavani, dear all,

would it be OK for you, if I package a new version?
If I'm not mistaken, it has 323 new APNs, which would probably help a  
lot of our users.

I would put it into a collab-maint git repo, if there are no objections.

Thanks in advance!

Bug#833365: libapache2-mpm-itk: installation fails when apache2 is not running

[Florent Bervas]

Package: libapache2-mpm-itk
Version: 2.4.7-02-1.1+deb8u1
Severity: normal
Tags: patch

Hi,

I have been faced to an installation issue of the package. During
installation process, postinst script failed 2 times:

== Error messages ==

/var/lib/dpkg/info/libapache2-mpm-itk.postinst: 9: [: !=: unexpected
operator
/var/lib/dpkg/info/libapache2-mpm-itk.postinst: 291: [: !=: unexpected
operator

== Explanation ==

In both case, a command's result is not handled correctly as a string. When
the command "a2query -M" is executed while the apache2 server is not
running, the command returns an empty string and bash fails the comparison.

== Patch ==

Suggested patch that have fixed my issue:

/var/lib/dpkg/info/libapache2-mpm-itk.postinst:9
-if [ $(a2query -M) != 'prefork' ] ; then
+if [ "$(a2query -M)" != "prefork" ] ; then

/usr/share/apache2/apache2-maintscript-helper:291
-if [ $CUR_MPM != "$MPM" ] ; then
+if [ "$CUR_MPM" != "$MPM" ] ; then


Thank you for taking care of this bug.

Best,

Florent


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

Kernel: Linux 4.3.0-1-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 libapache2-mpm-itk depends on:
ii  apache2-bin [apache2-api-20120211]  2.4.10-10+deb8u5
ii  libc6   2.19-18
ii  libcap2 1:2.24-8

libapache2-mpm-itk recommends no packages.

libapache2-mpm-itk suggests no packages.

Bug#833366: please make it possible to update/upgrade more than once daily

[Marc Haber]

Package: apt
Version: 1.3~pre2
Severity: wishlist
File: /usr/lib/apt/apt.systemd.daily

Hi,

currently, the apt.systemd.daily job can only be configured to
update/upgrade once daily or less than that. It cannot be configured
to update more often than that.

To get aquainted with the mechanics of the mechanism, it would be nice
to be able to run the job, for example, once an hour, so that one
could see the process working whenever unstable updates.

I do understand that once daily is a reasonable default to keep mirror
load down, but it would be really nice to be able to go beyond
that. There are valid reasons for that.

Thanks for considering.

Greetings
Marc