Bug#849800: debhelper: dh_systemd_start --no-start has no effect

[Peter Colberg]

Package: debhelper
Version: 10.2.2
Severity: normal

Dear Maintainer,

I would like to add a systemd service and timer to acmetool that is
to be explicitly enabled by the user. debian/rules looks as follows:

~~~
override_dh_systemd_enable:
dh_systemd_enable --no-enable acmetool.timer

override_dh_systemd_start:
dh_systemd_start --no-start acmetool.timer

override_dh_installinit:
~~~

However, first-time installation of the package yields this warning:

~~~
# dpkg -i acmetool_0.0.58-5_amd64.deb
Selecting previously unselected package acmetool.
(Reading database ... 52232 files and directories currently installed.)
Preparing to unpack .../acmetool_0.0.58-5_amd64.deb ...
Unpacking acmetool (0.0.58-5) ...
Setting up acmetool (0.0.58-5) ...
acmetool.timer is a disabled or a static unit, not starting it.
~~~

Inspecting the generated postinst it appears --no-start is ignored:

~~~
# Automatically added by dh_systemd_start
if [ -d /run/systemd/system ]; then
systemctl --system daemon-reload >/dev/null || true
if [ -n "$2" ]; then
_dh_action=try-restart
else
_dh_action=start
fi
deb-systemd-invoke $_dh_action acmetool.timer >/dev/null || true
fi
# End automatically added section
~~~

Should the above snippet not be omitted with --no-start?

Regards,
Peter

Bug#849799: libpng1.6: CVE-2016-10087: NULL pointer dereference in png_set_text_2()

[Salvatore Bonaccorso]

Source: libpng1.6
Version: 1.6.26-6
Severity: important
Tags: security upstream patch

Hi,

the following vulnerability was published for libpng1.6.

CVE-2016-10087[0]:
NULL pointer dereference

Upstream commits referenced in security-tracker.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10087
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10087

Regards,
Salvatore

Bug#849631: dnscrypt-proxy 1.8.1-4 fails to start

[Eric Dorland]

Control: tags + moreinfo unreproducible

I'm not seeing this on my system. If you upgrade what does your
dnscrypt-proxy.socket, dnscrypt-proxy.service and
/etc/dnscrypt-proxy/dnscrypt-proxy.conf files look like?

* Perl (zer0.div...@yahoo.fr) wrote:
> Package: dnscrypt-proxy
> Version: 1.7.0+dfsg-1
> Severity: serious
> Tags: upstream
> Justification: serious
> 
> Dear Maintainer,
> 
>* What led up to the situation?
>After upgrade dnscrypt-proxy, it wan't start anymore.
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>  Working as before.
>* What was the outcome of this action?
>dnscrypt-proxy.service and dnscrypt-proxy.socket stop working.
>I get these output in journalctl:
>Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.service: Service
>hold-off time over, scheduling restart.
>Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.service: Start
>request repeated too quickly.
>Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.socket: Unit
>entered failed state.
>Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.service: Unit
>entered failed state.
>Dec 28 22:13:03 debian systemd[1]: dnscrypt-proxy.service: Failed
>with result 'start-limit-hit'.
>
>And if I feed dnscrypt-proxy command with the configuration file, I
>get in terminal:
>Dec 28 22:13:01 debian dnscrypt-proxy[1694]: Wed Dec 28 22:13:01 2016
>[INFO] + DNS Security Extensions are supported
>Dec 28 22:13:01 debian dnscrypt-proxy[1694]: Wed Dec 28 22:13:01 2016
>[INFO] + Provider supposedly doesn't keep logs
>Dec 28 22:13:01 debian systemd[1]: dnscrypt-proxy.service: Service
>hold-off time over, scheduling restart.
> 
>* What outcome did you expect instead?
>Running dnscrypt-proxy.service and dnscrypt-proxy.socket.
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (150, 'testing'), (100, 'stable'), (5, 
> 'experimental')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.8.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages dnscrypt-proxy depends on:
> ii  adduser  3.115
> ii  init-system-helpers  1.46
> ii  libc62.24-8
> ii  libltdl7 2.4.6-2
> ii  libsodium18  1.0.11-1
> ii  libsystemd0  232-8
> 
> dnscrypt-proxy recommends no packages.
> 
> Versions of packages dnscrypt-proxy suggests:
> ii  resolvconf  1.79
> 
> -- Configuration Files:
> /etc/default/dnscrypt-proxy changed:
> DNSCRYPT_PROXY_LOCAL_ADDRESS=127.0.2.1:53
> DNSCRYPT_PROXY_RESOLVER_NAME=dnscrypt.org-fr
> DNSCRYPT_PROXY_OPTIONS=""
> 
> /etc/dnscrypt-proxy/dnscrypt-proxy.conf changed:
> ResolverName=dnscrypt.org-fr

That equals sign looks problematic.

> ResolversList /usr/share/dnscrypt-proxy/dnscrypt-resolvers.csv
> Daemonize yes
> PidFile /var/run/dnscrypt-proxy.pid
> User _dnscrypt-proxy
> LocalAddress 127.0.2.1:53
> EphemeralKeys yes
> MaxActiveRequests 250
> LogFile /var/log/dnscrypt-proxy.log
> LogLevel 7
> BlockIPv6 yes
> 
> 
> -- no debconf information

-- 
Eric Dorland 
43CF 1228 F726 FD5B 474C  E962 C256 FBD5 0022 1E93


signature.asc
Description: PGP signature

Bug#849798: qemu: CVE-2016-10028: display: virtio-gpu-3d: OOB access while reading virgl capabilities

[Salvatore Bonaccorso]

Source: qemu
Version: 1:2.8+dfsg-1
Severity: important
Tags: upstream security

Hi,

the following vulnerability was published for qemu.

CVE-2016-10028[0]:
display: virtio-gpu-3d: OOB access while reading virgl capabilities

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10028
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10028
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1406367

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#849797: mutt: lost key name for

[Adam Borowski]

Package: mutt
Version: 1.7.1-5
Severity: normal

Hi!
In stretch's mutt, the  key no longer works by default.

I see that it fails to recognize its code and assign it the name.
Trying ":exec what-key", the values reported for letter-Enter and
arrows-Enter respectively are:

jessie:
Char = , Octal = 12, Decimal = 10
Char = , Octal = 527, Decimal = 343

stretch:
Char = , Octal = 15, Decimal = 13
Char = , Octal = 527, Decimal = 343


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

Kernel: Linux 4.9.0+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages mutt depends on:
ii  libassuan02.4.3-2
ii  libc6 2.24-8
ii  libcomerr21.43.3-1
ii  libgnutls30   3.5.7-3
ii  libgpg-error0 1.26-1
ii  libgpgme111.8.0-3
ii  libgssapi-krb5-2  1.15-1
ii  libidn11  1.33-1
ii  libk5crypto3  1.15-1
ii  libkrb5-3 1.15-1
ii  libncursesw5  6.0+20161126-1
ii  libnotmuch4   0.23.4-1
ii  libsasl2-22.1.27~101-g0780600+dfsg-1
ii  libtinfo5 6.0+20161126-1
ii  libtokyocabinet9  1.4.48-11

Versions of packages mutt recommends:
ii  libsasl2-modules  2.1.27~101-g0780600+dfsg-1
ii  locales   2.24-8
ii  mime-support  3.60

Versions of packages mutt suggests:
ii  aspell 0.60.7~20110707-3+b1
ii  ca-certificates20161130
ii  exim4-daemon-light [mail-transport-agent]  4.88-2
ii  gnupg  2.1.17-2
pn  mixmaster  
ii  openssl1.1.0c-2
pn  urlview

Versions of packages mutt is related to:
ii  mutt  1.7.1-5

-- no debconf information

Bug#849796: unblock: libphp-phpmailer/(5.2.14+dfsg-2.1

[Salvatore Bonaccorso]

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

Hi

Please unblock package libphp-phpmailer/lower the age it needs to
transition to testing.

libphp-phpmailer as uploaded by Thijs fixes a vulnerability
CVE-2016-10033 (and making sure tha the fix is not incomplete, so not
affected by CVE-2016-10045 itself). The changelog entry is:

> libphp-phpmailer (5.2.14+dfsg-2.1) unstable; urgency=high
> 
>   * Non-maintainer upload by the Security Team.
>   * Fix CVE-2016-10033 (and CVE-2016-10045): apply commits
> 4835657c 9743ff5c 833c35fe from upstream. Closes: #849365.
> 
>  -- Thijs Kinkhorst   Fri, 30 Dec 2016 11:22:28 +

and attached the full debdiff.

unblock libphp-phpmailer/(5.2.14+dfsg-2.1

Regards,
Salvatore

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libphp-phpmailer-5.2.14+dfsg/debian/changelog 
libphp-phpmailer-5.2.14+dfsg/debian/changelog
--- libphp-phpmailer-5.2.14+dfsg/debian/changelog   2016-03-05 
16:06:02.0 +0100
+++ libphp-phpmailer-5.2.14+dfsg/debian/changelog   2016-12-30 
12:22:28.0 +0100
@@ -1,3 +1,11 @@
+libphp-phpmailer (5.2.14+dfsg-2.1) unstable; urgency=high
+
+  * Non-maintainer upload by the Security Team.
+  * Fix CVE-2016-10033 (and CVE-2016-10045): apply commits
+4835657c 9743ff5c 833c35fe from upstream. Closes: #849365.
+
+ -- Thijs Kinkhorst   Fri, 30 Dec 2016 11:22:28 +
+
 libphp-phpmailer (5.2.14+dfsg-2) unstable; urgency=medium
 
   * Team upload
diff -Nru 
libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch
 
libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch
--- 
libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch
1970-01-01 01:00:00.0 +0100
+++ 
libphp-phpmailer-5.2.14+dfsg/debian/patches/0002-Fix-CVE-2016-10033-CVE-2016-10045.patch
2016-12-30 12:22:28.0 +0100
@@ -0,0 +1,117 @@
+diff -Nur libphp-phpmailer-5.2.14+dfsg.orig/class.phpmailer.php 
libphp-phpmailer-5.2.14+dfsg.new/class.phpmailer.php
+--- libphp-phpmailer-5.2.14+dfsg.orig/class.phpmailer.php  2015-11-01 
10:15:28.0 +
 libphp-phpmailer-5.2.14+dfsg.new/class.phpmailer.php   2016-12-30 
11:20:08.368756474 +
+@@ -164,6 +164,7 @@
+ 
+ /**
+  * The path to the sendmail program.
++ * Must contain only a path to an executable, with no parameters or 
switches
+  * @var string
+  */
+ public $Sendmail = '/usr/sbin/sendmail';
+@@ -1329,19 +1330,27 @@
+  */
+ protected function sendmailSend($header, $body)
+ {
+-if ($this->Sender != '') {
++if (!(is_file($this->Sendmail) and is_executable($this->Sendmail))) {
++throw new phpmailerException($this->lang('execute') . 
$this->Sendmail, self::STOP_CRITICAL);
++}
++// CVE-2016-10033, CVE-2016-10045: Don't pass -f if characters will 
be escaped.
++if (!empty($this->Sender) and self::isShellSafe($this->Sender)) {
+ if ($this->Mailer == 'qmail') {
+-$sendmail = sprintf('%s -f%s', 
escapeshellcmd($this->Sendmail), escapeshellarg($this->Sender));
++$sendmailFmt = '%s -f%s';
+ } else {
+-$sendmail = sprintf('%s -oi -f%s -t', 
escapeshellcmd($this->Sendmail), escapeshellarg($this->Sender));
++$sendmailFmt = '%s -oi -f%s -t';
+ }
+ } else {
+ if ($this->Mailer == 'qmail') {
+-$sendmail = sprintf('%s', escapeshellcmd($this->Sendmail));
++$sendmailFmt = '%s';
+ } else {
+-$sendmail = sprintf('%s -oi -t', 
escapeshellcmd($this->Sendmail));
++$sendmailFmt = '%s -oi -t';
+ }
+ }
++
++// TODO: If possible, this should be changed to escapeshellarg.  
Needs thorough testing.
++$sendmail = sprintf($sendmailFmt, escapeshellcmd($this->Sendmail), 
$this->Sender);
++
+ if ($this->SingleTo) {
+ foreach ($this->SingleToArray as $toAddr) {
+ if (!@$mail = popen($sendmail, 'w')) {
+@@ -1388,6 +1397,38 @@
+ }
+ 
+ /**
++ * Fix CVE-2016-10033 and CVE-2016-10045 by disallowing potentially 
unsafe shell characters.
++ *
++ * Note that escapeshellarg and escapeshellcmd are inadequate for our 
purposes, especially on Windows.
++ * @param string $string The string to be validated
++ * @see https://github.com/PHPMailer/PHPMailer/issues/924 CVE-2016-10045 
bug report
++ * @access protected
++ * @return boolean
++ */
++protected static function isShellSafe($str

Bug#849700: [Pkg-mc-devel] Bug#849700: Bug#849700: mcedit does not more work

[Yury V. Zaytsev]

On Fri, 30 Dec 2016, Michelle Konzack wrote:

So, if I have copied some things in mcedit, where in $HOME is this 
informatiuon stored?


~/.local/share/mc

--
Sincerely yours,
Yury V. Zaytsev

Bug#830472: can't reproduce, not serious

[Russell Coker]

severity 830472 normal
thanks

I can't reproduce this.  Version 0.74 fixed all the GCC6 related bugs that 
occur on my system.

Version 0.75 should stay in testing because the amd64 package I uploaded 
compiled without any serious warnings.

I'll fix this bug if I can reproduce it, but it's not a reason to remove 
postal from testing.  If you have any suggestions for reproducing it then 
please let me know.

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#849795: mgba: new upstream version available (0.5.1)

[Ryan Tandy]

Source: mgba
Version: 0.4.1+dfsg1-1
Severity: wishlist

Dear maintainer,

Thank you for packaging mgba.

A new upstream bugfix release is available: 0.5.1. I built an updated 
package locally and it seems to work fine. It would be great if we could 
have this version in stretch.

If you are short on time, I could help prepare the upload.

thanks,
Ryan

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

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

Bug#831391: [Pkg-ime-devel] Bug#831391: U+2601 CLOUD 反而像電信桿而非雲

[Paul Hardy]

I just examined the latest Wen Quan Yi source files.  An incorrect
cloud glyph (U+2601) appears in two Wen Quan Yi BDF files: the 10pt
and 11pt files.  The BDF source font files get converted into PCF
files for Debian installation.  Here is a breakdown of the cloud glyph
in the BDF source files:

wenquanyi_9pt.bdf: GOOD U+2601 glyph (looks like a cloud)

wenquanyi_10pt.bdf: BAD U+2601 glyph

wenquanyi_11pt.bdf: BAD U+2601 glyph (the one that looks like a
telephone pole, so this is probably the point size you saw)

wenquanyi_12pt.bdf: U+2601 is missing

wenquanyi_13pt.bdf: U+2601 is missing

I will notify upstream (where the fix should be made), but of course
it is too late to change before the stretch freeze.


Paul Hardy

Bug#849699: [mtr] Please package v0.87

[Robert Woodcock]

On 12/29/2016 02:21 PM, Samuel Henrique wrote:

Source: mtr
Version: 0.86-1
Severity: wishlist
Tags: patch

Hello, while having a general look for packages who might need updates 
for Stretch, i found out that mtr was outdated and decided to take a 
look at it.


I have made several changes to the packaging while updating it to 
v0.87, you can see the package on mentors[1] and at collab-maint[2].


I would like to co-maintain mtr with you, but if you feel like not to, 
please feel free to use my changes without adding me as an uploader 
(note that the package on mentors and collab does that).


Here's a short summary of the main changes i've made:
* Bump DH level to 10.
* Enable bindnow hardening flag.
* Create a d/clean file to allow multiple builds.
* Bump Standards-Version to 3.9.8.
* Add a watch file.
* Convert copyright to DEP-5.
* Start using git for packaging.

I belive updating to v.087 will also let Ubuntu sync with us again, as 
they've patched mtr to fix an upstream problem not present anymore on 
0.87.


There's also a considerable amount of bugs which i believe should be 
closed, they were marked as fixed but not closed. If you accept my 
help, i can do some bug triage :)


[1]:https://mentors.debian.net/package/mtr
[2]:https://anonscm.debian.org/git/collab-maint/mtr.git

Samuel Henrique 



I've been meaning to get 0.87 uploaded for a while now. I'll look over 
your changes this weekend and include them. I'm OK with you being 
co-maintainer.

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

[Boyuan Yang]

Source: qtwebengine-opensource-src
Severity: important
Version: 5.7.1+dfsg-1

Hi,

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

This package could not be built on (any) official buildd machine other than 
amd64 (which was a binary upload). This problem needs to be solved sooner or 
later.

I tried to build it on my own x86_64 VPS (1GB mem + 4GB swap) and it is still 
experiencing FTBFS (OOM?).

Build logs can be found on buildd [0].

The root of FTBFS seems different on different architectures:

* i386: OOM
* mips: "#error Please add support for your architecture in build/
build_config.h"
* armhf, armel: "fatal error: gnu/stubs-hard.h: No such file or directory"
* kfreebsd: "Unknown platform. Qt WebEngine only supports Linux, Windows, and 
OS X."
* mipsel: "collect2: fatal error: ld terminated with signal 6 [Aborted]
compilation terminated.
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc"

I would suggest making a source-only upload (to experimental, maybe) after 
applying fixes to test if the fixes are working correctly.

[0] https://buildd.debian.org/status/package.php?p=qtwebengine-opensource-src

--
Sincerely,
Boyuan Yang

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

Bug#778412: Henry Spencer regular expressions (regex) library contains a heap overflow vulnerability

[Colin Watson]

On Mon, Feb 16, 2015 at 07:37:19PM +0100, Moritz Mühlenhoff wrote:
> On Sat, Feb 14, 2015 at 03:41:21PM +0100, Luciano Bello wrote:
> > The security team received a report from the CERT Coordination Center that 
> > the 
> > Henry Spencer regular expressions (regex) library contains a heap overflow 
> > vulnerability. It looks like this package includes the affected code at 
> > that's 
> > the reason of this bug report.
> > 
> > The patch is available here:
> > http://gitweb.dragonflybsd.org/dragonfly.git/blobdiff/4d133046c59a851141519d03553a70e903b3eefc..2841837793bd095a82f477e9c370cfe6cfb3862c:/lib/libc/regex/regcomp.c
> 
> Building with "--disable-re" should fix this.

Regrettably not in this case: nvi uses the BSD-specific REG_NOSPEC flag,
so it doesn't build with glibc's regex library.  I'm just applying the
patch instead.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#849793: xpad: "restore to previous state" fails to open notes

[Mike Kupfer]

Package: xpad
Version: 4.8.0-1
Severity: normal

Dear Maintainer,

In the Startup tab for Xpad preferences, if I set "Display pads" to
"Restore to previous state", it doesn't work for open pads.  That is,
if I have pads open and then restart Xpad, the pads are not reopened.

"Open all pads" does work.


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

Kernel: Linux 4.8.0-2-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)

Versions of packages xpad depends on:
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-8
ii  libcairo-gobject2   1.14.8-1
ii  libcairo2   1.14.8-1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.2-2
ii  libgtk-3-0  3.22.5-1
ii  libgtksourceview-3.0-1  3.22.1-1
ii  libice6 2:1.0.9-1+b1
ii  libpango-1.0-0  1.40.3-3
ii  libpangocairo-1.0-0 1.40.3-3
ii  libsm6  2:1.2.2-1+b1

xpad recommends no packages.

xpad suggests no packages.

-- no debconf information

Bug#844707: plasma-workspace: plasmadesktop - excessive cpu usage, slow desktop operation

[Ignacio R. Morelle]

The patch was merged into the LTS branch upstream yesterday:

https://cgit.kde.org/plasma-workspace.git/commit/?h=Plasma/5.8&id=e43b89e2b9f3ff9bf6299488e82a365cbfde2b2a

As I mentioned in the upstream report, it's been working nicely for me
on Sid against Plasma 5.8.4, for the past few days.

Bug#849792: xpad: selection not visible when using custom colors

[Mike Kupfer]

Package: xpad
Version: 4.8.0-1
Severity: normal

Dear Maintainer,

If I configure xpad to use specific text and background colors (rather than
"colors from theme"), there's no visible feedback when I select text in a
note (e.g., doing click and drag).  The text is selected (I can copy and
paste it), but the lack of visible feedback makes it hard to use.

I see this on both Xfce and Mate.  It seems to be independent of the 
background color that I choose and independent of the current GTK theme.



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

Kernel: Linux 4.8.0-2-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)

Versions of packages xpad depends on:
ii  libatk1.0-0 2.22.0-1
ii  libc6   2.24-8
ii  libcairo-gobject2   1.14.8-1
ii  libcairo2   1.14.8-1
ii  libgdk-pixbuf2.0-0  2.36.0-1
ii  libglib2.0-02.50.2-2
ii  libgtk-3-0  3.22.5-1
ii  libgtksourceview-3.0-1  3.22.1-1
ii  libice6 2:1.0.9-1+b1
ii  libpango-1.0-0  1.40.3-3
ii  libpangocairo-1.0-0 1.40.3-3
ii  libsm6  2:1.2.2-1+b1

xpad recommends no packages.

xpad suggests no packages.

-- no debconf information

Bug#802604: fvwm: focus is not given to the window when changing page with invisible mouse pointer

[Dominik Vogt]

On Fri, Dec 30, 2016 at 08:24:07PM -0700, Jaimos Skriletz wrote:
> Hello,
> 
> This was reported by a Debian user. Please retain the CC to
> 802604-forwar...@bugs.debian.org in your response, so that
> the Debian BTS has a record.
> 
> In short if the mouse cursor is over the root window and hidden with
> unclutter, when switching pages (and maybe desks), focus is not given
> to the window under the pointer.

Works fine for me.  I'd need a precise description + config file
to test this.

> I have tested this on 2.6.7 and experience the same thing. Focus is
> given properly if the mouse cursor is not hidden or it is over a
> window, but if hidden over the root window focus is not correctly
> given to windows on the new page.
> 
> jaimos
> 
> On Wed, 21 Oct 2015 17:00:43 +0200 Vincent Lefevre  wrote:
> > On 2015-10-21 16:52:23 +0200, Vincent Lefevre wrote:
> > > I have "Scroll -100 0" bound to some key. When I change the page with
> > > this key and the mouse pointer is over some window of the new desktop
> > > page, then the focus is not given to this window if the mouse pointer
> > > is invisible (this can be the case with "unclutter -idle 1 -root",
> > > using the unclutter package).
> >
> > This problem occurs only when the mouse pointer was over the root window
> > before the change of the desktop page.

Ciao

Dominik ^_^  ^_^

-- 

Dominik Vogt

Bug#849748: dbus is translating SE Linux contexts when it's not appropriate

[Laurent Bigonville]

forwarded 849748 https://bugs.freedesktop.org/show_bug.cgi?id=99234
thanks

Hi,

I've open a bug upstream for this, see 
https://bugs.freedesktop.org/show_bug.cgi?id=99234

Bug#802604: fvwm: focus is not given to the window when changing page with invisible mouse pointer

[Jaimos Skriletz]

Hello,

This was reported by a Debian user. Please retain the CC to
802604-forwar...@bugs.debian.org in your response, so that
the Debian BTS has a record.

In short if the mouse cursor is over the root window and hidden with
unclutter, when switching pages (and maybe desks), focus is not given
to the window under the pointer.

I have tested this on 2.6.7 and experience the same thing. Focus is
given properly if the mouse cursor is not hidden or it is over a
window, but if hidden over the root window focus is not correctly
given to windows on the new page.

jaimos

On Wed, 21 Oct 2015 17:00:43 +0200 Vincent Lefevre  wrote:
> On 2015-10-21 16:52:23 +0200, Vincent Lefevre wrote:
> > I have "Scroll -100 0" bound to some key. When I change the page with
> > this key and the mouse pointer is over some window of the new desktop
> > page, then the focus is not given to this window if the mouse pointer
> > is invisible (this can be the case with "unclutter -idle 1 -root",
> > using the unclutter package).
>
> This problem occurs only when the mouse pointer was over the root window
> before the change of the desktop page.
>

Bug#849791: override: diaspora:net/optional, diaspora-installer:net/optional, diaspora-common:net/optional, diaspora-installer-mysql:net/optional,

[Pirate Praveen]

package: ftp.debian.org
control: block 832219 by -1



signature.asc
Description: OpenPGP digital signature

Bug#843956: override: gitlab:section:web

[Pirate Praveen]

Control: retitle -1 override: gitlab:net/optional

On closer look, I feel "Daemons and clients to connect your system to
the world." is better suited than "Web servers, browsers, proxies,
download tools etc."



signature.asc
Description: OpenPGP digital signature

Bug#849790: Cannot load system exclude list

[Jamie McClelland]

Package: owncloud-client-cmd
Version: 2.2.4+dfsg-1~bpo8+1

Dear Maintainer,

Since upgrading to 2.2.4+dfsg-1~bpo8+1 running the client fails with:

Set proxy configuration to use system configuration 
Cannot load system exclude list or list supplied via --exclude
Aborted

However, if I pass: --exclude /dev/null it works.

Bug#849789: publishing NEW packages properly

[Ian Jackson]

Package: dgit-infrastructure
Version: 2.0

There is some problem with packages which make it out of NEW not
apearing on browse.dgit.d.o.  I suspect the cron jobs are insufficient
somehow.

AFAICT the problem was fixed when I ran
  /srv/dgit.debian.org/dgit-live/infra/dgit-mirror-rsync 
/srv/dgit.debian.org/dispatch-dir/distro=debian all

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#849788: mirror submission for debian.redlibre.cl

[Pablo Umanzor]

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

Submission-Type: new
Site: debian.redlibre.cl
Type: leaf
Archive-architecture: amd64 i386 
Archive-http: /debian/
IPv6: no
Archive-upstream: mirrors.kernel.org
Updates: four
Maintainer: Pablo Umanzor 
Country: CL Chile
Location: Santiago - Las Condes

Bug#849597: libguestfs0: Missing multiple dependencies

[Richard W.M. Jones]

In Fedora we package up the icoutils dependencies in a separate
subpackage to avoid pulling in all of X and Perl when installing the
main library:

http://pkgs.fedoraproject.org/cgit/rpms/libguestfs.git/tree/libguestfs.spec#n427

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

Bug#849787: mcstrans: Running mcstrans triggers 849748 and is the most serious SE Linux problem

[Russell Coker]

Package: mcstrans
Version: 2.6-2
Severity: critical
Tags: upstream
Justification: breaks unrelated software

While mcstrans has no problems for what it does, it triggers bad interactions
between systemd, dbus, and SE Linux.  I don't think it is possible to properly
solve these issues before the sid is frozen.  Therefore I think that mcstrans
should be removed from testing and not offered for installation in the next
stable release.

At this time this is the most serious problem we have with SE Linux in Debian.

As an aside by default Fedora doesn't run mcstrans.  I don't know whether it's
for the same reason, but in any case Fedora users are surviving well enough
without it.

-- 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.8.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mcstrans depends on:
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libcap2  1:2.25-1
ii  libpcre3 2:8.39-2
ii  libselinux1  2.6-3
ii  lsb-base 9.20161125
ii  selinux-utils2.6-3

mcstrans recommends no packages.

mcstrans suggests no packages.

-- no debconf information

Bug#726530: (no subject)

[Thomas Adam]

Hi,

Without a proper stacktrace from a corefile, this won't get any investigation.
Since you're the only one so far to have reported a problem, I'm going to put
this down to your hardware.

But until I get a stacktrace from you via a corefile, you're stuck on an
unsupported version.  Why don't you consider taking a few minutes to think on
that -- and if you can get a stacktrace, I'll look at it.

-- Thomas Adam

Bug#848184: Processed: reassign 848184 to bugs.debian.org

[Don Armstrong]

Control: tag -1 moreinfo
Control: 

Hey; I need to know the text for the pseudopackage description, a the
e-mail address that the bugs should be sent to, and (ideally) a few bugs
which will be immediately assigned to the package.

[The latter isn't strictly necessary, but it's basically a test to make
sure it's worth creating the pseudopackage.]

I also should warn you that you'll never be able to have a
jenkins.debian.org package in Debian (but I doubt that you'd ever want
one.)


-- 
Don Armstrong  https://www.donarmstrong.com

Leukocyte... I am your father.
 -- R. Stevens http://www.dieselsweeties.com/archive.php?s=1546

Bug#848194: Want way to get Release (or InRelease) file from cache

[Ian Jackson]

David Kalnischkies writes ("Re: Bug#848194: Want way to get Release (or 
InRelease) file from cache"):
> On Mon, Dec 19, 2016 at 01:18:13AM +, Ian Jackson wrote:
> > I get a sense of puzzlement from your mail.  I will try to explain why
> > I want these seemingly-daft things.
> 
> My puzzlement comes mostly from you seeming to have a very clear idea
> about what you want (= the Origin and Codename field of Release file),
> but its completely unclear what you have in hand to get there and why
> you actually want those instead of considering other ways.

I may well be confused or simply wrong, of course.

I get a sense from your mail that I may have irritated you.  I would
be happy to try to talk to you some other way, by phone perhaps.
That's often a better approach than writing long emails to try to sort
out someone's misunderstanding.  Or if you think it would help, we
could ask someone else to try to help deconfuse our conversation.

If you'd like to try a phone call or something, please send me some
details (eg, availability, timezone, location) by private email.

Otherwise I can try to explain again why I think I need the suite
codename, and try to explain my thinking about some of the things that
seem wrong to you.

Thanks,
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#849422: (no subject)

[Thomas Adam]

Fixed in Git.

Bug#788253: gfsd: unowned files after purge (policy 6.8, 10.8): /var/lib/systemd/deb-systemd-helper-masked/gfsd.service

[Dmitry Smirnov]

On Tuesday, 20 December 2016 9:32:18 PM AEDT Felipe Sateler wrote:
> Moving
> the removal to after the debhelper block should fix this as well.

Would that be an ugly workaround for bug in the other package?


> Upon package remove but not purge, dh_systemd will mask the unit so
> that upon the next boot you do not get boot failures because the
> program is no longer installed.

I still do not understand how/why is that a problem in gfarm (but not in 
other packages) and why gfarm needs workaround.

It still looks like a bug in debhelper. Could you please elaborate why you've 
reassigned this bug back to gfarm?

Thanks.

-- 
All the best,
 Dmitry Smirnov.

---

Good luck happens when preparedness meets opportunity.


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

Bug#848194: Want way to get Release (or InRelease) file from cache

[David Kalnischkies]

On Mon, Dec 19, 2016 at 01:18:13AM +, Ian Jackson wrote:
> I get a sense of puzzlement from your mail.  I will try to explain why
> I want these seemingly-daft things.

My puzzlement comes mostly from you seeming to have a very clear idea
about what you want (= the Origin and Codename field of Release file),
but its completely unclear what you have in hand to get there and why
you actually want those instead of considering other ways.


> Right now, users have to dig a bit to find the right information.
> Take a you look here at the advice under `Finding the Debian release':
>
> https://manpages.debian.org/cgi-bin/man.cgi?query=dgit-user&apropos=0&sektion=0&manpath=Debian+testing+stretch&format=html&locale=en

(The description of M-A:allowed is wrong – or at least very misleading.
It is neither responsible for the ':i386' nor does it mean that
different builds exists – and libc6 is like the worst possible choice as
an example for an M-A:allowed packages because it neither is one nor can
reasonable be ever be one… It would be /slightly/ more correct with
M-A:same (which libc6 is), but in all honesty that whole sentence hurts
more than it helps – in general that manpage could benefit from review
as it is littered with typos [yuu, teporary, Kf, …] and incorrect or
misleading info [M-A, what you call "alias" is "suite" (or "archive",
but that might confuse people more than it helps), you redefine
"suite", …])

From that I am assuming you have a binary package name as the start.
Good – you can get the installed version (if any) from it, the source
package (and version) it was build from and if you are lucky also the
repository it was downloaded from (if the system is fully up-to-date and
there aren't multiple choices due to multiple versions having the same
number… – a common problem actually with people having a way of easily
building packages with a few additional changes).

You might be unlucky and the user has a version installed which isn't
available (anymore) anywhere as the mirrors carry a new version already
(or she has a previous selfbuilt installed, picks backports by hand, …)
and that is were your trouble begins as things get complicated fast:
binary packages change the source package they belong to (recent
example: gnupg), source packages have a different version than the
binary packages they build (classic example binNMU, but e.g.
libgpg-error used to, too), multiple versions can exist in one
repository, multiple repositories can contain packages with the same
version number (but distinct content), …


btw: Looking at the sources.list is bound to fail. That file might not
even exist on many machines (e.g. on mine) and even if it would many
repositories have a different release schedule then the one they "extend"
(as in you will frequently have them refer to 'oldstable' if you
upgraded to the 'new' stable sooner than the repository owner. A far
more predictable way is e.g. looking at /etc/os-release. dpkg-vendor can
also help you figuring out where you are. Packages itself can also have
an Origin field in the dpkg/status file – that is only used by dpkg
itself ATM through.

The changelog of a package (if available!) can also help you identify
from which pocket it came: "Normal" stable, -security and -backports
have different entry points.

Either seems for me far more simple and reasonable than trying to guess
for each individual package from which repository it eventually came…


Frankly, I have to question the whole interface a bit with its
insistence on ",-security" (and what about -proposed-updates, …) and
a soft suspicion that I can't get Ubuntu sources on Debian or more
delicate: get foodistro/stable and bardistro/stable on Debian/stable as
they all will be "stable" – but I am not a user, I just skimmed the
manpage…

> I would like to make a way to a user to ask dgit for "what I'm
> running" (this request is #848193).
> 
> You mention version numbers.  Obviously the user wants the right
> version.  But the version number is not sufficient.  dgit provides a
> fast-forwarding git branch for each suite.  To get the right history
> structure it is necessary to know not just the sequence of version
> numbers, but also any shared git history (from the dgit git server).
> 
> I think all the information I need is in the Release file (assuming we
> can somehow identify what the right Release file is).  That contains
> both the suite name and the codename, and also the Origin field tells
> us the distro.  (dgit needs configuration for each distro anyway, so
> just the distro name is enough.)

"all information" from the Release files is available via the 'apt-get
indextargets' interface for the relevant files (see next-next section).


> As for pinning, I'm not sure exactly why that is a problem, but I
> think if the user has specifically pinned the very same package, they
> probably have some awareness of what's going on, so bugs where dgit
> gives them the wrong suite (or, situations where dgit

Bug#849077: [pkg-wpa-devel] Bug#849077: wpasupplicant: [Regression] Updating wpasupplicant makes not possible to connect to encrypted WiFi

[Michael Owen]

I had the exact same error with all my ralink, broadcom and realtek
adapters.
Adding the lines to NetworkManager.conf

[device]

   wifi.scan-rand-mac-address=no

fixed them all. I did not have the problem with the internal Atheros on my 
Inspiron.

Fixing this is excellent, I no longer have to use wicd to connect as I prefer 
NetworkManager.


On Mon, 26 Dec 2016 16:39:43 -0300 Lisandro
=?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer 
wrote:
> On lunes, 26 de diciembre de 2016 20:04:08 ART Andrew Shadura wrote:
> > On 26/12/16 19:28, Lisandro Damián Nicanor Pérez Meyer wrote:
> > > Thanks to Eduard Bloch at [bug] I've tried adding
> > >
> > > [device]
> > > wifi.scan-rand-mac-address=no
> > >
> > > to /etc/NetworkManager/NetworkManager.conf
> > >
> > > and updating wpasupplicant... and voilá, WiFi is on again.
> > >
> > > [bug] 
> > >
> > > I don't know if it's a bug in the driver, NM or wpasupplicant, but at
> > > least
> > > things now work.
> >
> > Lisandro, what NM version are you using? A related bug has been fixed by
> > mbiebl recently:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=835822#67
>
> Interesting. I was using 1.4.2-3. After trying this workaround/fix I
updated
> to 1.4.4-1 which is what I'm currently using.
>
> Thanks!
>
> --
> Quizá, para muchos, ahora que lo pienso, Wikipedia tiene
> ciertamente un defecto imperdonable. No adorna.
> Ariel Torres, "Probablemente, la Wikipedia esté bien"
> La Nación Tecnología, Sábado 25 de agosto de 2007
> http://www.lanacion.com.ar/tecnologia/nota.asp?nota_id=937889
>
> Lisandro Damián Nicanor Pérez Meyer
> http://perezmeyer.com.ar/
> http://perezmeyer.blogspot.com/

Bug#803232: fixed in irqbalance 1.1.0-2.1

[Laurent Bigonville]

found 803232 1.1.0-2.1
reopen 803232
thanks

Well, this is not fixed :/

I think the problem comes from the is_irqbalance_enabled() function in 
the config script.


In the case of the upgrade when running systemd, we cannot trust 
systemctl is-enabled to make any decisions as the .service file has 
never been enabled. We need to rely on the state of the LSB scripts 
during the upgrade to know what to do.


I was thinking about this change to test if the script is enabled in any 
runlevel:


diff -Nru irqbalance-1.1.0/debian/irqbalance.config 
irqbalance-1.1.0/debian/irqbalance.config
--- irqbalance-1.1.0/debian/irqbalance.config   2016-12-30 21:54:18.0 
+0100
+++ irqbalance-1.1.0/debian/irqbalance.config   2016-12-31 01:49:20.0 
+0100
@@ -37,7 +37,7 @@
 # will be switched to update-rc.d handling in postinst...
 if [ "$ENABLED" = "0" ]; then
 db_set irqbalance/enable false
-elif [ -e $UPGRADE_FLAG_FILE ] && ! is_irqbalance_enabled; then
+elif [ -e $UPGRADE_FLAG_FILE ] && ! ls /etc/rc*.d/S*irqbalance >/dev/null 
2>&1; then
 db_set irqbalance/enable false
 elif [ ! -e $INSTALL_FLAG_FILE ] && [ ! -e $UPGRADE_FLAG_FILE ]; then
 # dpkg-reconfigure

Bug#849786: ITP: avldrums.lv2 - Drum Sample Player Plugin

[Jaromír Mikeš]

Package: wnpp
Severity: wishlist
Owner: mira.mi...@seznam.cz


* Package name : avldrums.lv2
Version : 0.2.2
Upstream Author : Robin Gareus ro...@gareus.org
* URL : https://github.com/x42/avldrums.lv2
* License : GPL-2+
Programming Lang: C
Description : a Drum Sample Player Plugin
avldrums.lv2 is a simple Drum Sample Player Plugin,
 dedicated to the http://www.bandshed.net/avldrumkits/

Bug#849785: RM: mcmcpack -- RoQA; renamed to r-cran-mcmcpack

[Andreas Beckmann]

Package: ftp.debian.org
Severity: normal

please remove the obsolete source package src:mcmcpack, it has been renamed
to r-cran-mcmcpack:

 r-cran-mcmcpack (1.3-8-1) unstable; urgency=medium

  * Team upload.
  * New upstream version
  * Consistent naming between source and binary package
...


Andreas

Bug#845014: Duplicate

[Linas Vepstas]

Possible duplicate of https://github.com/lxc/lxc/issues/1370

Bug#849782: .apk files not consistently detected

[Christoph Biedl]

Control: tags 849782 moreinfo
Control: merge 849782 849783

Hans-Christoph Steiner wrote...

> Previously, with 1:5.29-2, APK files seemed to be always detected as JAR
> files.

Please clarify. The "tmp" (md5:67b44d779578cbddf6e17db92290e987) gets detected
as Zip in all versions of file supported in Debian (wheezy: 5.11, jessie: 5.22,
stretch/sid: 5.29). The "unsigned" (md5:f323c2eef912954fad38fe9ed0adf5ea) file
changed from Zip to JAR between wheezy and jessie.

Does this match your observation or did I miss your point?

Christoph


signature.asc
Description: Digital signature

Bug#849781: Please add a systemd service file

[Andrey Rahmatullin]

Control: tags -1 + help

On Fri, Dec 30, 2016 at 11:43:50PM +0100, Laurent Bigonville wrote:
> The upstream tarball contains a systemd .service file, but that file is
> not installed in the package.
> 
> Could you please have a look at this?
The main problem with this is the current setup: the package supports two
modes of operation, switched with RUN_MODE in /etc/default/mcelog. As I
didn't implement this, I hesitate to make any changes. I will gladly
accept anything improving the systemd support for this package from
someone who understands these matters better.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#849661: gap-guava: FTBFS with some SHELLs(?): cd: too many arguments

[Jerome BENOIT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hello GUAVA enthusiasts,

@Chris, thanks for report the issue.

On 29/12/16 16:08, Chris West (Faux) wrote:
> Source: gap-guava
> Version: 3.13+ds-1
> Severity: serious
> Justification: fails to build from source
> Tags: sid stretch
> User: reproducible-bui...@lists.alioth.debian.org
> Usertags: ftbfs
> X-Debbugs-CC: reproducible-bui...@lists.alioth.debian.org
> 
> Dear Maintainer,
> 
> The package fails to build:
> 
> gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2
> -fdebug-prefix-map=/build/gap-guava-3.13+ds/2nd=.
> -fstack-protector-strong -Wformat -Werror=format-security
> -Wno-unused-result -Wl,-z,relro -Wl,-z,now -o leonconv leonconv.c
> cd leon make
> /bin/sh: line 0: cd: too many arguments
> Makefile:14: recipe for target 'all' failed
> 

I can reproduce the FTBFS within a schroot Sid environment on my amd64 box with 
bash as sh.
This shell issue is rather disturbing.

> 
> There's definitely an error in the Makefile:
> https://sources.debian.net/src/gap-guava/3.13%2Bds-1/src/Makefile/#L14
> 
> all :   $(FILES)
> cd leon make
> 

This code looks insane. I am on my way to attempt to harden it,


> 
> The variation appears to be that most shells treat this is "cd leon"
> (and ignore the rest of the arguments), whereas some shells reject it as
> an error:
> 
> % mkdir -p foo bar; for s in bash zsh dash posh sh; do $s -c 'cd foo bar'; 
> done
> zsh:cd:1: string not in pwd: foo
> posh: cd: too many arguments
> 
> (the others succeed)
> 
> I have no idea what upstream intended there.
> 
> A full build log can be seen on the reproducible-builds builders, which
> vary the shell (between bash and.. some sh):
> https://tests.reproducible-builds.org/debian/unstable/amd64/gap-guava
> 

Thanks,
Jerome


- -- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calcu...@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B
-BEGIN PGP SIGNATURE-

iQQcBAEBCgAGBQJYZvAWAAoJED+SGaZ/NsaLJBAgALNPE1jQx+vhGMGWTiFUJytV
U9s3YDlwrnWN0BC+XIKOYouz7PXxgqZ7n5j4vbFhD2bUARxizYXjedWs7ClidGig
PR2vFyuNHz63PP2NOyDDr+VPr2deIPSSsA1M3V5lJ1jzP6KJeK/JdrWRfMxgmwJT
MdQZoLJsLADbJm+gY05iiK3juKwLkwS3TBRf1YVj9Qk1w+G226c2NLZu/8HylE0y
cJCGUgAMJxiVViwoS6ycVcQ3GE0stAbtIw/Str7sDtAzcylweD6DEwkxg3/sNowT
YB5yXpnELUPOBbM94nwRMOnIXbBjtCjpNS0Rv3ULBiFb/VgNdAijhIdRF+Xh/QxU
ltkvcCmuV6jx7Kp2tKv0xQyktBvEoCq2RWxOsvOKqW3j/7HHa25OWno+icddslUE
6l9sJsN12NO6hQcmJKwNciof6+f7vkTtq6AT5iDWFjlfx6tCVQY1NBJU9EPX/C+P
BvXbXzXtAvP4izAByyTbNiHaylDc8LaXGXMk8AWu1ZWWStI86L8wrL0L3AqF2V2l
648BvPIMgnOc0ljlEN+8ITOSpyzDEtPnNz/jPdIKcuIJ+o8RnAvgQ0xvaFzRz69k
a1IFSeIkAXkNmW06hUN1oTJH8clTsnMCNRmr7QvjbGM9IyWXkCrZz1yQxLfAkQdg
U4fHZmuOl92TyEIePO7V85C/GDB//+1fA2mf//QFFSvN5tfVhY6tXWgRhkLLsi3C
JceuMQl0CIQZIksznlJCT0uO99F6JOdeYuYq5nfXtZriaJCtiLhoAuZmjoUnrind
Iiy7tC6jErgCQ0fluCbCw3sey9joUKKePR8BwDMhZKpvDo4+KU6+gYD8aasqSeaw
euDZi5b73g4eoM7Xz2g9arCLBFnIn8Fd7h9LFHXNtSmK4jsDcL0Pa4TDcsmC9faX
TIj2EZLi9lG0SSU5ChwZ294wegeETw4y9chFYANNyBf/67ixICJtonJUjKDOHEj7
yQCxD9zivwCxMJZyHC1N3aJM/vpQiBAGpQ4H7NgK2KWfjXHkmZSGsaF7MbQLJfqF
iWOAQFyEoeb54gLcZ5rAgy6IdrJ4FzlqL2FKFl9AyvcLGQIg5w6Hl0M3zYwHuyaP
lh6+IDy32tTAgWCWf6L9UWbhK3M5jwcZCsK8OJUhMfSNNtAS2j2wS6M37bI6JAlj
FyD3rkrCXHsZKIBuxvmtwG/zWJ/tGs737aoGlBepNPmTE4R6/s7NtdYOz5tmG2EZ
o+aH9Bhzn0kF6SOBBWtgKbYHuPUpbeCru50m55w7fFd3PJ9vNFJHc9X8dP0KJJbs
BnfqDtLhMy6L7ywRtqVKU+V23Asg1TeQkRLYaXLq1Ox3XU1VM4omRuusXTMlgRc=
=YI3F
-END PGP SIGNATURE-

Bug#849779: nvidia-driver: Nvidia packages crashed the OS - Not bootable after installing them

[Luca Boccassi]

Control: severity -1 normal
Control: close -1

On Fri, 2016-12-30 at 19:20 -0300, Mariel Opazo Damiani wrote:
> Package: nvidia-driver
> Version: dont know, had to purge it out of the system. Latest one available 
> right before  Dec 30, 2016.
> Severity: critical
> Justification: breaks the whole system
> 
> Dear Maintainer,
> 
> Was trying to install an nvidia video card driver because linux didnt detect 
> it existed at all. 
> First tried with the package nvidia-detect but it said it didnt detect 
> anything.
> Then I manually downloaded the driver from nvidias webpage, installed it and 
> nothing changed, no video card detected. 
> Then moved onto the last thing I had read to work and added a non free 
> repository so I could downlaod nvidia-smi and nvidia-driver. 
> Downloaded both and also the package nvidia-xconfig, used the command 
> "nvidia-driver" and followed it with "nvidia-xconfig", restarted the computer 
> and it wouldnt boot. 
> Had to purge all nvidia related packages out of my system and restore the 
> file "xorg.conf" to its previous state (completely blank) to get my computer 
> to work again.
> 
> The video card in question is NVIDIA GeForce 940-mx (2GB). Checked the 
> supported video cards by NVIDIA and mine is one of them. 

On an optimus system the base driver cannot be installed by itself. See
https://wiki.debian.org/Bumblebee

To use the proprietary driver on an optimus system the bumblebee-nvidia
package is needed.

Furthermore, as Nvidia's website states, the minimum driver version for
the 940mx is the 352 series, so the nvidia-driver in jessie is too old.
Make sure to install all the packages from backports:

sudo apt-get install -t jessie-backports bumblebee-nvidia

So closing this as invalid. If you have issues with bumblebee, please
open a separate bug against that package.

Kind regards,
Luca Boccassi


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

Bug#845193: [Pkg-openssl-devel] Bug#845193: Bug#845193: dpkg: recent -specs PIE changes break openssl

[Sebastian Andrzej Siewior]

On 2016-12-29 00:25:05 [+0100], To Kurt Roeckx wrote:
> > Figure out why it uses link_a instead of link_o, and maybe fix it?

so that link_a instead of link_o is always used - not just on x32.
Replacing _a with _o here gets the build to continue but fails later in
a (normal) link_o rule:

|make[3]: Entering directory '/home/bigeasy/openssl1.0-1.0.2j/engines/ccgost'
|SHLIB_COMPAT=; SHLIB_SOVER=; if [ -n "" ]; then prev=""; for v in `echo " " | 
cut -d';' -f1`; do SHLIB_SOVER_NODOT=$v; SHLIB_SOVER=.$v; if [ -n "$prev" ]; 
then SHLIB_COMPAT="$SHLIB_COMPAT .$prev"; fi; prev=$v; done; fi; 
SHLIB=libgost.so; SHLIB_SUFFIX=; ALLSYMSFLAGS='-Wl,--whole-archive'; 
NOALLSYMSFLAGS='-Wl,--no-whole-archive'; SHAREDFLAGS="-DOPENSSL_PIC 
-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mx32 -DL_ENDIAN -g 
-O2 -fdebug-prefix-map=/home/bigeasy/openssl1.0-1.0.2j=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIE -Wl,-z,relro -Wl,-z,now -Wa,--noexecstack -Wall 
-DMD32_REG_T=int -mx32 -Wl,--version-script=openssl.ld -shared 
-Wl,-soname=$SHLIB$SHLIB_SOVER$SHLIB_SUFFIX"; SHOBJECTS="e_gost_err.o 
gost2001_keyx.o gost2001.o gost89.o gost94_keyx.o gost_ameth.o gost_asn1.o 
gost_crypt.o gost_ctl.o gost_eng.o gosthash.o gost_keywrap.o gost_md.o 
gost_params.o gost_pmeth.o gost_sign.o"; ( :; LIBDEPS="${LIBDEPS:--L../.. 
-lcrypto}"; SHAREDCMD="${SHAREDCMD:-gcc}"; 
SHAREDFLAGS="${SHAREDFLAGS:--DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT 
-DDSO_DLFCN -DHAVE_DLFCN_H -mx32 -DL_ENDIAN -g -O2 
-fdebug-prefix-map=/home/bigeasy/openssl1.0-1.0.2j=. -fstack-protector-strong 
-Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE 
-Wl,-z,relro -Wl,-z,now -Wa,--noexecstack -Wall -DMD32_REG_T=int -mx32 
-Wl,--version-script=openssl.ld}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done 
| sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ 
/:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${SHAREDCMD} ${SHAREDFLAGS} 
-o $SHLIB$SHLIB_SOVER$SHLIB_SUFFIX $ALLSYMSFLAGS $SHOBJECTS $NOALLSYMSFLAGS 
$LIBDEPS ) && if [ -n "$INHIBIT_SYMLINKS" ]; then :; else 
prev=$SHLIB$SHLIB_SOVER$SHLIB_SUFFIX; if [ -n "$SHLIB_COMPAT" ]; then for x in 
$SHLIB_COMPAT; do ( :; rm -f $SHLIB$x$SHLIB_SUFFIX; ln -s $prev 
$SHLIB$x$SHLIB_SUFFIX ); prev=$SHLIB$x$SHLIB_SUFFIX; done; fi; if [ -n 
"$SHLIB_SOVER" ]; then ( :; rm -f $SHLIB$SHLIB_SUFFIX; ln -s $prev 
$SHLIB$SHLIB_SUFFIX ); fi; fi
|/usr/bin/ld: gost_eng.o: relocation R_X86_64_PC32 against symbol 
`stderr@@GLIBC_2.16' can not be used when making a shared object; recompile 
with -fPIC
|/usr/bin/ld: final link failed: Bad value
|collect2: error: ld returned 1 exit status
|../../Makefile.shared:167: recipe for target 'link_o.gnu' failed

and this attempt was with -fPIE without the -fPIC and the spec file
switch. So I *think* that maybe fPIE is not perfectly fine here. I don't
see a failure on sparc64 which is also using the spec file and the same
link rule for the first fips_premain_dso target.

> and according to gdb somewhere in the asm corner. So going from
> x86_64_asm to no_asm makes it build. Is there a reason why we should fix
> asm for x32 in the old openssl while it seems to work in 1.1.0?
> Otherwise I would drop the asm for x32 and be done with it.

dropped.

> btw: During the build I saw
> |gcc: note: pie specs /usr/share/dpkg/pie-compile.specs ignored when pie is 
> not enabled
> |gcc: note: pie specs /usr/share/dpkg/pie-link.specs ignored when pie is not 
> enabled
> 
> after each gcc line. This pops up also with openssl 1.1.0 but I don't
> see it in any for of the build logs (for 1.0.2 or 1.1.0) so it must be
> new.

#849542

> > Kurt
 
Sebastian

Bug#849784: lomoco: udev support broken, missing file /lib/udev/udev.lomoco

[dju]

Package: lomoco
Version: 1.0.0-2
Severity: normal

Dear Maintainer,

I recently upgraded from 1.0.0-1 to 1.0.0-2 and now my mouse (Logitech MX510) 
is now at the default resolution after reboot instead of being automatically 
set to 800 DPI just as before. It seems that the /lib/udev/udev.lomoco file is 
missing in 1.0.0-2, compared to 1.0.0-1. In syslog I can see 
"systemd-udevd[546]: failed to execute '/lib/udev/udev.lomoco' 'udev.lomoco': 
No such file or directory". Copying the file from 1.0.0-1 makes udev 
automatically set the mouse resolution again. Thanks!

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

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

Versions of packages lomoco depends on:
ii  libc6 2.24-8
ii  libusb-0.1-4  2:0.1.12-30

Versions of packages lomoco recommends:
ii  udev  232-8

lomoco suggests no packages.

-- Configuration Files:
/etc/default/lomoco changed [not included]

-- no debconf information

Bug#849779: More information

[Mariel O]

I first tried to fix the system by deleting xorg.conf, since it was the only 
file the commands said they had changed. When turning on  my computer an error 
appeared that it couldn't log in, a white screen with an image and message that 
I don't recall what said.


It wasn't the black screen that represents the system thinking to log in (how 
it would stay infinitely), it was an error screen.  I restored the file to its 
nvidia configuration because I went to sleep and wanted things to be left out 
as they were when the problem arose.


The next day I logged in as root, purged every single package that had "nvidia" 
in its name, since I knew one of them was doing something that was screwing 
with more than just the "xorg.conf" file and rebooted. It didn't reboot to 
regular OS, it reboot to only having the shell, not a graphics interactive 
because it didn't detect the screen. Went in to the folder containing 
"xorg.conf" and changed it back to the original one (blank), for some reason 
the purging didn't touch this file. Then restarted again and it logged in fine.

Bug#849782: .apk files not consistently detected

[Hans-Christoph Steiner]

Package: file
Version: 1:5.29-2
Severity: important

Android APK files are the standard app package for Android.  They are a
slightly custom version of JAR format.  Basically, they are JAR files
with standard files included in them, a custom padding method, and now a
new custom signature format.  The first signature format was just a JAR
signature.

Previously, with 1:5.29-2, APK files seemed to be always detected as JAR
files.  Now sometimes they are detected as ZIP files:

$ file unsigned/aarddict.android_26.apk
unsigned/aarddict.android_26.apk: Java archive data (JAR)
$ file tmp/aarddict.android_26.apk
tmp/aarddict.android_26.apk: Zip archive data, at least v2.0 to extract

You can get those two files here:

unsigned/aarddict.android_26.apk
https://verification.f-droid.org/aarddict.android_26.apk

tmp/aarddict.android_26.apk
https://f-droid.org/repo/aarddict.android_26.apk

Bug#849783: .apk files not consistently detected

[Hans-Christoph Steiner]

Package: file
Version: 1:5.29-2
Severity: important

Android APK files are the standard app package for Android.  They are a
slightly custom version of JAR format.  Basically, they are JAR files
with standard files included in them, a custom padding method, and now a
new custom signature format.  The first signature format was just a JAR
signature.

Previously, with 1:5.29-1, APK files seemed to be always detected as JAR
files.  Now sometimes they are detected as ZIP files:

$ file unsigned/aarddict.android_26.apk
unsigned/aarddict.android_26.apk: Java archive data (JAR)
$ file tmp/aarddict.android_26.apk
tmp/aarddict.android_26.apk: Zip archive data, at least v2.0 to extract

You can get those two files here:

unsigned/aarddict.android_26.apk
https://verification.f-droid.org/aarddict.android_26.apk

tmp/aarddict.android_26.apk
https://f-droid.org/repo/aarddict.android_26.apk

Bug#846792: linux-image-4.8.0-1-amd64: ACPI : EC: EC started delay on boot

[Jakobus Schürz]

Am 2016-12-30 um 23:30 schrieb Jakobus Schürz:
> Hi Salvatore!
> 
> Thanks for your reply!
> 
> 
 I know that is right now not a big help, but confirming if it is not a
 Debian specific change, would help, to make aware upstream.
>>>
>>>
>>> I build a vanilla-kernel from the kernel.org-sources (Don't know, if i
>>> made it correct). But I got a working Kernel 4.9 (without any
>>> patches???).The delay of 6 seconds persists after the EC: EC: in dmesg.
>>>
>>> Do i have to aply any patches?
>>>
>>> I build my Kernel with this recepie
>>> 
>>>
>>> Is this correct?
>>
>> Yes perfect. So we know that the issue is persisting with the vanilla
>> kernel without patches. Now the next step would be that you report
>> that to the bugzilla on kernel.org. Once you have the bugnumber, then
>> you can mark #846792 as forwarded to the upstream bug.
>>
>> Helps?
> 
> So i filed a bug in bugzilla on kernel.org
> 
> https://bugzilla.kernel.org/show_bug.cgi?id=70891
> 
> But i don't know, how to mark a bugreport as forwarded... :(

Now i know, but i took the wrong bugnumber for kernel org.
The correct link is:

https://bugzilla.kernel.org/show_bug.cgi?id=191561

Regards

Jakob

Bug#835542: flex: comparison between signed and unsigned integer expressions

[Christoph Berg]

Control: tag -1 patch pending

Re: Vladimír Čunát 2016-09-27 

> I'm curious: will there be a fix for 2.6.1?

I've just uploaded flex_2.6.1-1.2_source.changes fixing this to
delayed/5, patch attached.

 debian/NEWS.Debian |2 +-
 debian/changelog   |   12 +
 src/flex.skl   |   10 
 src/gen.c  |2 +-
 src/skel.c |   70 ++--
 5 files changed, 54 insertions(+), 42 deletions(-)

The net change is in flex.skl + gen.c; skel.c is generated from these.

Christoph

No differences were encountered between the control files

diff -Nru flex-2.6.1/debian/changelog flex-2.6.1/debian/changelog
--- flex-2.6.1/debian/changelog	2016-12-30 23:28:29.0 +0100
+++ flex-2.6.1/debian/changelog	2016-12-30 23:28:29.0 +0100
@@ -1,3 +1,15 @@
+flex (2.6.1-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Cherry-pick 1da19feba7c957e0f0af0c3eeadc29e8c82b0ca3,
+cf4121fa97abac8aeaa5e08b8fc0b2380228494e and
+8c098febc9a599397921e9b6938b7fb85e38cc7e from upstream to fix comparison
+between signed and unsigned integer expressions in generated lexer
+(Closes: #835542).
+  * Fix distribution in last upload's NEWS.Debian.
+
+ -- Christoph Berg   Fri, 30 Dec 2016 20:29:41 +0100
+
 flex (2.6.1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru flex-2.6.1/debian/NEWS.Debian flex-2.6.1/debian/NEWS.Debian
--- flex-2.6.1/debian/NEWS.Debian	2016-12-30 23:28:29.0 +0100
+++ flex-2.6.1/debian/NEWS.Debian	2016-12-30 23:28:29.0 +0100
@@ -1,4 +1,4 @@
-flex (2.6.1-1.1) UNRELEASED; urgency=medium
+flex (2.6.1-1.1) unstable; urgency=medium
 
In this upload, the flex package drops its dependency on libfl-dev, because
it is impossible to forward the correct architecture constraint. It contains
diff -Nru flex-2.6.1/src/flex.skl flex-2.6.1/src/flex.skl
--- flex-2.6.1/src/flex.skl	2016-12-30 23:28:29.0 +0100
+++ flex-2.6.1/src/flex.skl	2016-12-30 23:28:29.0 +0100
@@ -1661,7 +1661,7 @@
 M4_YY_DECL_GUTS_VAR();
 	char *dest = YY_CURRENT_BUFFER_LVALUE->yy_ch_buf;
 	char *source = YY_G(yytext_ptr);
-	yy_size_t number_to_move, i;
+	int number_to_move, i;
 	int ret_val;
 
 	if ( YY_G(yy_c_buf_p) > &YY_CURRENT_BUFFER_LVALUE->yy_ch_buf[YY_G(yy_n_chars) + 1] )
@@ -1690,7 +1690,7 @@
 	/* Try to read more data. */
 
 	/* First move last chars to start of buffer. */
-	number_to_move = (yy_size_t) (YY_G(yy_c_buf_p) - YY_G(yytext_ptr)) - 1;
+	number_to_move = (int) (YY_G(yy_c_buf_p) - YY_G(yytext_ptr) - 1);
 
 	for ( i = 0; i < number_to_move; ++i )
 		*(dest++) = *(source++);
@@ -1778,7 +1778,7 @@
 	else
 		ret_val = EOB_ACT_CONTINUE_SCAN;
 
-	if ((int) (YY_G(yy_n_chars) + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
+	if ((YY_G(yy_n_chars) + number_to_move) > YY_CURRENT_BUFFER_LVALUE->yy_buf_size) {
 		/* Extend the array by 50%, plus the number we really need. */
 		int new_size = YY_G(yy_n_chars) + number_to_move + (YY_G(yy_n_chars) >> 1);
 		YY_CURRENT_BUFFER_LVALUE->yy_ch_buf = (char *) yyrealloc(
@@ -2451,11 +2451,11 @@
 	YY_BUFFER_STATE b;
 	char *buf;
 	yy_size_t n;
-	yy_size_t i;
+	int i;
 m4_dnl M4_YY_DECL_GUTS_VAR();
 
 	/* Get memory for full buffer, including space for trailing EOB's. */
-	n = (yy_size_t) _yybytes_len + 2;
+	n = (yy_size_t) (_yybytes_len + 2);
 	buf = (char *) yyalloc( n M4_YY_CALL_LAST_ARG );
 	if ( ! buf )
 		YY_FATAL_ERROR( "out of dynamic memory in yy_scan_bytes()" );
diff -Nru flex-2.6.1/src/gen.c flex-2.6.1/src/gen.c
--- flex-2.6.1/src/gen.c	2016-03-01 12:08:30.0 +0100
+++ flex-2.6.1/src/gen.c	2016-12-30 23:28:29.0 +0100
@@ -1973,7 +1973,7 @@
 		("if ( yy_act != YY_END_OF_BUFFER && yy_rule_can_match_eol[yy_act] )");
 	++indent_level;
 	indent_puts ("{");
-	indent_puts ("yy_size_t yyl;");
+	indent_puts ("int yyl;");
 	do_indent ();
 	out_str ("for ( yyl = %s; yyl < yyleng; ++yyl )\n",
 		 yymore_used ? (yytext_is_array ? "YY_G(yy_prev_more_offset)" :
diff -Nru flex-2.6.1/src/skel.c flex-2.6.1/src/skel.c
--- flex-2.6.1/src/skel.c	2016-03-02 01:54:10.0 +0100
+++ flex-2.6.1/src/skel.c	2016-12-30 23:28:29.0 +0100
@@ -18,10 +18,10 @@
   "%#  through m4. Macros beginning with `m4_' will be processed.",
   "%#  The quoting is \"[[\" and \"]]\" so we don't interfere with",
   "%#  user code.",
-  "%# ",
+  "%#",
   "%# All generate macros for the m4 stage contain the text \"m4\" or \"M4\"",
   "%# in them. This is to distinguish them from CPP macros.",
-  "%# The exception to this rule is YY_G, which is an m4 macro, ",
+  "%# The exception to this rule is YY_G, which is an m4 macro,",
   "%# but it needs to be remain short because it is used everywhere.",
   "%#",
   "/* A lexical scanner generated by flex */",
@@ -34,7 +34,7 @@
   "m4_changequote",
   "m4_changequote([[, ]])",
   "",
-  "%# ",
+  "%#",
   "%# Lines in this skeleton starting with a \"%\" character are \"control lines\"",
   "%# a

Bug#849780: apcupsd communication lost with Back-UPS Pro 650 via cable when USB printer is started

[PhLinuX]

Package: apcupsd
Version: 3.14.12-1.1
Severity: important

Dear Maintainer,

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

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

*** End of the template - remove these template lines ***

Each time I use my USB printer, the communication with BackUps Pro650 is lost
while it is cable connected to tty with a UPSCABLE 940-0095A cable.
So I have to stop apcupsd and restart it again.
When I do not use my usb print er all goes well.

Log /var/log/apcupsd.events show:
2016-12-28 08:35:03 +0100  apcupsd 3.14.12 (29 March 2014) debian startup
succeeded
2016-12-28 12:36:59 +0100  Communications with UPS lost.
. snip  Communications with UPS lost.
2016-12-28 22:57:25 +0100  Communications with UPS lost.
2016-12-28 23:03:34 +0100  apcupsd exiting, signal 15
2016-12-28 23:03:34 +0100  apcupsd shutdown succeeded


Server : Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19)
x86_64 GNU/Linux
Os : Debian GNU/Linux 8.6 (jessie)   (uptodate)

# apctest
2016-12-30 11:06:22 apctest 3.14.12 (29 March 2014) debian
Checking configuration ...
sharenet.type = Network & ShareUPS Disabled
cable.type = Custom Cable Smart
mode.type = APC Smart UPS (any)
Setting up the port ...
Doing prep_device() ...

You are using a SMART cable type, so I'm entering SMART test mode
Hello, this is the apcupsd Cable Test program.
This part of apctest is for testing Smart UPSes.
Please select the function you want to perform.

1) Query the UPS for all known values
2) Perform a Battery Runtime Calibration
3) Abort Battery Calibration
4) Monitor Battery Calibration progress
5) Program EEPROM
6) Enter TTY mode communicating with UPS
Q) Quit

Select function number: 1

I am going to run through the series of queries of the UPS
that are used in initializing apcupsd.

Simulating UPSlinkCheck ...
Wrote: Y Got: SM
Attempting to use smart_poll() ...
Sent: Y Got: SM  Good -- smart_poll() works!.

Going to ask for valid commands...
Wrote: a Got: 3.?=.
')-89@ABDEFGKLMNOPQRSUVWXYZabcdefgjklmnopqrsuxyz~
Protocol version is: 3
Alert characters are: ?=
Command characters are: ^A^N^Z')-89@ABDEFGKLMNOPQRSUVWXYZabcdefgjklmnopqrsuxyz~

Now running through apcupsd get_UPS capabilities().
NA  indicates that the feature is Not Available

UPS Status: 08
Line quality: FF
Reason for last transfer to batteries: S
Self-Test Status: NO
Line Voltage: 230.4
Line Voltage Max: 233.2
Line Voltage Min: 230.4
Output Voltage: 230.4
Batt level percent: 100.0
Batt voltage: 13.77
UPS Load: 012.3
Line freq: 50.00
Runtime left: 0067
UPS Internal temp: NA
Dip switch settings: NA
Register 1: 00
Register 2: 00
Register 3: 00
Sensitivity: H
Wakeup delay: 000
Sleep delay: 020
Low transfer voltage: 208
High transfer voltage: 253
Batt charge for return: 00
Alarm status: 0
Low battery shutdown level: 02
UPS Name: UPS_IDEN
UPS Self test interval: 336
UPS manufacture date: 09/30/99
UPS serial number: NB9940151901
Date battery replaced: 09/30/99
Output voltage when on batteries: 230
Nominal battery voltage: 012
Percent humidity: NA
Ambient temperature: NA
Firmware revision: 12.4.I
Number of external batteries installed: NA
Number of bad batteries installed: NA
UPS model as defined by UPS: Back-UPS Pro 650
UPS EPROM capabilities string:
uD43127130133136uA43108110112114uI43253257261265lD43106103100097lA43092090088086lI43208204200196e44200155090oD13115oA13100oI13230s441HMLLq44202050710p443020180300600k4410TLNr44360180300E443336168ON
OFF
The EPROM string is 205 characters long!
Hours since last self test: 010.7

That is all for now.


# apcaccess
APC  : 001,048,1102
DATE : 2016-12-30 11:15:26 +0100
HOSTNAME : phlsys
VERSION  : 3.14.12 (29 March 2014) debian
UPSNAME  : PHLUPS
CABLE: Custom Cable Smart
DRIVER   : APC Smart UPS (any)
UPSMODE  : Stand Alone
STARTTIME: 2016-12-30 11:15:14 +0100
MODEL: Back-UPS Pro 650
STATUS   : ONLINE
LINEV: 233.2 Volts
LOADPCT  : 12.3 Percent
BCHARGE  : 100.0 Percent
TIMELEFT : 69.0 Minutes
MBATTCHG : 5 Percent
MINTIMEL : 3 Minutes
MAXTIME  : 0 Seconds
MAXLINEV : 233.2 Volts
MINLINEV : 233.2 Volts
OUTPUTV  : 233.2 Volts
SENSE: High
DWAKE: 0 Seconds
DSHUTD   : 20 Seconds
DLOWBATT : 2 Minutes
LOTRANS  : 208.0 Volts
HITRANS  : 253.0 Volts
RETPCT   : 0.0 Percent
ALARMDEL : 5 Seconds
BATTV: 13.8 Volts
LINEFREQ : 50.0 Hz
LASTXFER : Automatic or explicit self test
NUMXFERS : 0
TONBATT  : 0 Seconds
CUMONBATT: 0 Seconds
XOFFBATT : N/A
SELFTEST : NO
STESTI   : 336
STATFLAG : 0x0508
REG1 : 0x00
REG2 : 0x00
REG3 : 0x00
MANDATE  : 09/30/99
SERIALNO : NB9940151901
BATTDATE : 09/30/99
NOMOUTV  : 230 Volts
NOMBATTV : 12.0 Volts
FIRMWARE : 12.4.I
END APC  : 2016-12-30 11:15:30 +0100







-- System Information:
Debian Release: 8.6
  APT prefers stable-updates
  APT policy: (500, 'sta

Bug#849781: Please add a systemd service file

[Laurent Bigonville]

Package: mcelog
Version: 144+dfsg-1
Severity: normal
User: pkg-systemd-maintain...@lists.alioth.debian.org
Usertags: systemd-units

Hi,

The upstream tarball contains a systemd .service file, but that file is
not installed in the package.

Could you please have a look at this?

Regards,

Laurent Bigonville

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

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

Versions of packages mcelog depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  libc6  2.24-8
ii  lsb-base   9.20161125
ii  udev   232-8

mcelog recommends no packages.

mcelog suggests no packages.

-- no debconf information

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

['Klaus Ethgen']

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Fr den 30. Dez 2016 um 22:53 schrieb Jason Pyeron:
> You would have the same issue with cat /var/log/x

True. That is the reason I always tell the people not to use cat for
that. (There is only little you should use cat for ever.)

I seen many problems occure because an admin not listening.

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlhm39wACgkQpnwKsYAZ
9qwDZAwAtKQHpIpI+l+rVG+/1TUs5xguzj3Yox7ZCc3irYbDiq5Q6qty95ZRiyv5
HYMJhTQjYjV7Spz7EBYllxfZ7ZvSxxKRmH7Zvbw3RGZFOGVRFUQ0uAJIylzh9x7U
Ugh5LyhYhJsxeK5PRrWuKj6ARYIHivyaNEce/bQ6XzP2rK6mEZJJZhJJ8q1djei4
8cCCvfOBjjug1qQmbdwc8uGDr4fPz32gc1DhdeZY4HUSBXa9Ib7dl3XIP27vU28K
FId+ZtkdE8ObHIuw/c8w8odB8k3D/20Q6axrCUAYZVmdXeqbXhL88Iz6K5Ugx9uo
NxK+4xG2kez9J06s2RDtZzPwwS4Kaa5un8v5hItZg39zikVYFtLiNLJM+IIpSos0
tszgLrFRKmM+IFXkj3eZabE/dYU230AT62vxg6wqzNh3zNTJucPan2i3ad7vCKcs
Sjy+O238p1CSjmZsI6A9iodMPnsbm3pTFUm9p7WM5x9MjgfBMMNPPVeASWBEdry0
ezxxPXPJ
=Jl6P
-END PGP SIGNATURE-

Bug#846792: linux-image-4.8.0-1-amd64: ACPI : EC: EC started delay on boot

[Jakobus Schürz]

Hi Salvatore!

Thanks for your reply!


>>> I know that is right now not a big help, but confirming if it is not a
>>> Debian specific change, would help, to make aware upstream.
>>
>>
>> I build a vanilla-kernel from the kernel.org-sources (Don't know, if i
>> made it correct). But I got a working Kernel 4.9 (without any
>> patches???).The delay of 6 seconds persists after the EC: EC: in dmesg.
>>
>> Do i have to aply any patches?
>>
>> I build my Kernel with this recepie
>> 
>>
>> Is this correct?
> 
> Yes perfect. So we know that the issue is persisting with the vanilla
> kernel without patches. Now the next step would be that you report
> that to the bugzilla on kernel.org. Once you have the bugnumber, then
> you can mark #846792 as forwarded to the upstream bug.
> 
> Helps?

So i filed a bug in bugzilla on kernel.org

https://bugzilla.kernel.org/show_bug.cgi?id=70891

But i don't know, how to mark a bugreport as forwarded... :(

Regards

Jakob

Bug#849779: nvidia-driver: Nvidia packages crashed the OS - Not bootable after installing them

[Mariel Opazo Damiani]

Package: nvidia-driver
Version: dont know, had to purge it out of the system. Latest one available 
right before  Dec 30, 2016.
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

Was trying to install an nvidia video card driver because linux didnt detect it 
existed at all. 
First tried with the package nvidia-detect but it said it didnt detect anything.
Then I manually downloaded the driver from nvidias webpage, installed it and 
nothing changed, no video card detected. 
Then moved onto the last thing I had read to work and added a non free 
repository so I could downlaod nvidia-smi and nvidia-driver. 
Downloaded both and also the package nvidia-xconfig, used the command 
"nvidia-driver" and followed it with "nvidia-xconfig", restarted the computer 
and it wouldnt boot. 
Had to purge all nvidia related packages out of my system and restore the file 
"xorg.conf" to its previous state (completely blank) to get my computer to work 
again.

The video card in question is NVIDIA GeForce 940-mx (2GB). Checked the 
supported video cards by NVIDIA and mine is one of them. 

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

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

Bug#844184: RFS: muse-el/3.20+dfsg-1 [ITA]

[Sean Whitton]

On Fri, Dec 30, 2016 at 04:59:11PM +, Sean Whitton wrote:
> Just to let you know, we've already missed the deadline to add elpa-muse
> to stretch (it was Christmas day, due to 10 day migrations).

Sorry, looks like we were both wrong -- the deadline for binNEW is
February 5th.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#849700: [Pkg-mc-devel] Bug#849700: mcedit does not more work

[Dmitry Smirnov]

On Friday, 30 December 2016 9:54:33 AM AEDT Michelle Konzack wrote:
> There is NO-WAY for me installing Debian 8 because of systemd which does
> not work for me.

Since you are on amd64, systemd would probably work for you but if you have a 
non-technical problem with it (systemd fobia?) then just use SysV instead.
Systemd is not mandatory on Debian even though it is a default init system.
Alternatively you can stay on outdated system forever. Systemd is really not 
_that_ bad to give up on all the work that hundreds of contributors were 
doing all these years...

-- 
Cheers,
 Dmitry Smirnov.

---

However beautiful the strategy, you should occasionally look at the
results.
-- Winston Churchill


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

Bug#846792: linux-image-4.8.0-1-amd64: ACPI : EC: EC started delay on boot

[Jakobus Schürz]

Hi Salvatore!

No problem. I know, christmas is the most busy time in the year... :)
Same here.

> Apologies for the delay in coming back to you. So I'm not having
> really an idea. I suggest the following in case it is feasible for
> you:
> 
> Try to reproduce the problem with "vanilla" kernel. This is to make
> sure the issue is not introduced by a Debian specific change, but
> using otherwise the same configuration.
> 
> The following contains some indication:
> https://kernel-handbook.alioth.debian.org/ch-bugs.html#s9.2 ->
> https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-building
> 
> If this turns out to not be a issue specific to a Debian change, then
> could you please report the bug to the kernel bug database?
> 
> Once you have the bugnumber, mark this bug as forwarded.
> 
> I know that is right now not a big help, but confirming if it is not a
> Debian specific change, would help, to make aware upstream.


I build a vanilla-kernel from the kernel.org-sources (Don't know, if i
made it correct). But I got a working Kernel 4.9 (without any
patches???).The delay of 6 seconds persists after the EC: EC: in dmesg.

Do i have to aply any patches?

I build my Kernel with this recepie


Is this correct?

Regards Jakob

Bug#849775: emacs24: FTBFS randomly (Wrong type argument: number-or-marker-p, nil)

[Rob Browning]

Santiago Vila  writes:

> This is essentially the same bug as #842728, but in emacs24.
> [ If you need a full build log, just say so and I will include it ]
>
> I guess, but I don't really know, that the same fix that worked
> for emacs25 should work here as well. 

OK, thanks -- I'm going to hold off on this for a couple of days.  We're
waiting to hear back from the release team about the possibility of
switching emacs-defaults to emacs25 and then removing emacs24 from
stretch.

  https://lists.debian.org/debian-emacsen/2016/12/msg00016.html

-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4

Bug#849778: postfix: [INTL:sk] Slovak po-debconf translation

[helix84]

Package: postfix
Version: 3.1.3-6
Priority: wishlist
Tags: l10n patch

.po attached


~~helix84


sk.po
Description: Binary data

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

[Jason Pyeron]

> -Original Message-
> From: Willi Mann
> Sent: Friday, December 30, 2016 16:21
> To: Klaus Ethgen; 849...@bugs.debian.org
> Cc: logwatch-de...@lists.sourceforge.net
> Subject: Re: [Logwatch-devel] Bug#849531: Possible security 
> problem, new logwatch sends mails with charset UTF-8
> 
> Hi Klaus,
> 
> Am 2016-12-30 um 18:36 schrieb Klaus Ethgen:
> > Hi Willi,
> > 
> > Am Fr den 30. Dez 2016 um 18:18 schrieb Willi Mann:
> >> can you elaborate how this could be exploited?
> > 
> > Well, log principally contains untrusted data that could be injected
> > from untrusted source. That is no security hole itself.
> > 
> > But when that data gets displayed with the wrong charset, that can
> > trigger problems in window managers (for example). See 
> xterm which can
> > be controlled via ansii sequences. Even more, it could 
> trigger stream
> > conversion problems if the UTF-8 implementation is not really fully
> > tested with broken streams.

You would have the same issue with cat /var/log/x



> 
> So far, I cannot see that the change you mentioned would be 
> problematic.

Adding the binmode(OUTFILE, ":utf8"); fixes your primary report.

> What I do see is that it might be wise to sanitize the output of
> logwatch. A possible way to go might be to remove any byte 
> with value <
> 0x20 - unless it is a newline or tab. But that is independent of the
> ISO-8859-15 to utf-8 change.

Please open a new bug for this enhancement, as it a different issue.

-Jason

Bug#849637: [DSE-Dev] Bug#849637: /sys/devices/system/cpu/online SELinux context

[cgzones]

But isn't genfscon with subcontexts only available on the /proc filesystem?

2016-12-30 22:18 GMT+01:00 Dominick Grift :
> On Fri, 30 Dec 2016 12:39:05 +0100 Laurent Bigonville 
> wrote:
>> reassign 849637 policycoreutils
>> thanks
>>
>> On Thu, 29 Dec 2016 12:36:30 +0100 cgzones  wrote:
>>
>>  > When running a SELinux enabled system /sys/devices/system/cpu/online
>>  > is mislabeled after boot:
>>  >
>>  > root@test1:/root/selinux/policy# restorecon -vv -R -F -n /sys
>>  > Would relabel /sys/devices/system/cpu/online from
>>  > system_u:object_r:sysfs_t:s0 to system_u:object_r:cpu_online_t:s0
>>
>> Not sure why this is assigned to systemd as this is not created by systemd.
>>
>> It's working with sysvinit because the selinux-autorelabel LSB
>> initscript is explicitly relabeling it during boot.
>>
>> Under systemd, that initscript is masked by the selinux-autorelabel.service.
>>
>> I was planning to add a tmpfiles for this, but apparently I forgot about it.
>>
>> Reassigning to policycoreutils
>>
>> Laurent Bigonville
>
> you should be able to add a genfscon() in policy for this, provided that
> the kernel is not too old to support that feature
>
> I would avoid the alternative if possible
>>
>>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
>
>
> ___
> SELinux-devel mailing list
> selinux-de...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/selinux-devel

Bug#849748: dbus is translating SE Linux contexts when it's not appropriate

[Simon McVittie]

On Fri, 30 Dec 2016 at 23:55:58 +1100, Russell Coker wrote:
> Below is part of the SE Linux audit log on one of my test systems.  These
> entries have a MCS context of "s0" which is being translated to "SystemLow"
> in a very similar way to translating a UID to a username.  However the 
> software
> which processes the audit log expects to have a non-translated MCS context so
> this causes problems.

What component emits those log messages? It looks as though it's pid 1,
the system instance of systemd?

> https://www.spinics.net/lists/selinux/msg21149.html
> 
> This URL has the archive of a mailing list discussion about this topic.  It
> seems that changes to systemd or dbus could be used to resolve this.

The D-Bus documentation that says

Returns the security
context used by SELinux, in an unspecified format. If you know what this
means, please contribute documentation via the D-Bus bug tracking system.

is because before I added that sentence, GetConnectionSELinuxSecurityContext()
was not documented at all. However, I didn't (and still don't) know the
specifics of that method, so I documented its existence and left it to
others to fill in the blanks. That was almost four years ago.

If you know enough about SELinux to give a more precise description
or can quote some likely examples of what a user of SELinux would get
by calling that method (similar to the ones given for AppArmor),
please send a patch upstream so we can document it better. The
point of contact for upstream bug reports and code contributions is

and the specification is doc/dbus-specification.xml in the dbus source
tree. https://bugs.freedesktop.org/show_bug.cgi?id=84193 is a relevant
upstream bug that I opened when I added the initial documentation.

In particular, the distinction between translated and non-translated
MCS contexts (and which one gets reported) should be mentioned there -
but until today I didn't know that a translated MCS context was a phrase
that makes sense, so I am really not the right person to be writing that
documentation!

dbus' AppArmor support was added much later than its SELinux support,
so it has been through a lot more review, has more documentation, and we
have a better picture of what is appropriate. If you can bring SELinux
up to the same standard, that would be much appreciated.

Given that GetConnectionSELinuxSecurityContext() seems to have returned
the same thing for about 10 years, I think making the documentation
describe existing behaviour would be a lot more appropriate than changing
its behaviour and only documenting the new version.

> It seems GetConnectionCredentials should be preferred.

Yes. GetConnectionCredentials() returns the uid, the pid, and the raw form
of any applicable LSM label in a single round-trip, making it more efficient
than the older single-credential methods like GetConnectionUnixUserID() and
GetConnectionSELinuxSecurityContext(). If D-Bus is used as intended then
it is not normally a performance bottleneck; but if its performance does
become relevant, then it's usually number of message round-trips per second,
rather than number of bytes per second, that is the limiting factor.

If GetConnectionCredentials() also returns the information you actually
want, where GetConnectionSELinuxSecurityContext() doesn't, then that's
an additional reason to prefer it.

> I don't know a lot about dbus.

We don't know a lot about SELinux. Unfortunately, the SELinux code in
dbus was mostly committed a decade ago, prior to my involvement in dbus
and before we had a systematic "audit trail" of upstream bug reports, so
there's nothing else I can look up to find out why.

If it's systemd that's emitting these messages, and it can make them
better/more appropriate by calling GetConnectionCredentials() rather
than GetConnectionSELinuxSecurityContext(), then I think it's systemd
that should change to call GetConnectionCredentials().

> An other option consists in making D-Bus use getpeercon_raw() in
> GetConnectionSELinuxSecurityContext (and documenting this in the
> D-Bus spec).

I think it would be a bad idea to change the (undocumented!) semantics of
this method - that seems quite likely to break other projects' assumptions,
and it has had its current behaviour for more than 10 years.
I am definitely not going to change the meaning of that method as
a Debian-specific patch, and I don't think it would be appropriate
to change it on the upstream 1.10.x stable-branch either.

However, if you want to pursue this route, the way to do so would
be to talk to the D-Bus upstream maintainers via
.
I don't use or understand SELinux, but some of the other upstream
maintainers might.

S

Bug#849703: ITP: ansible-doc -- Documentation for Ansible

[Evgeni Golov]

Hi Toni,

On Fri, Dec 30, 2016 at 12:58:02AM +0100, Toni Mueller wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Toni Mueller 
> 
> * Package name: ansible-doc
>   Version : 2.2.0.0-1
>   Upstream Author : RedHat 
> * URL : http://www.ansible.com/
> * License : GPL-3
>   Programming Lang: HTML, JavaScript
>   Description : Documentation for Ansible
> 
> Currently, the Ansible package in Debian lacks proper offline
> documentation. This package aims to supply the documentation in HTML
> form offline, so one should not need to go to the aoupstream website to
> read it.

Which source is this built from?
Do you basically want a mirror of https://docs.ansible.com/ansible/ in
a Debian package?

> Yours truly frequently suffers under bad network conditions, which make
> reading the website infeasible or outright impossible, so I think the
> package is useful.

If it is more than ansible-doc , then it certainly is.
I just wonder whether it is sensible to built it from an own source,
and not from the ansible source itself.

> I hope I can collaborate with the maintainer of the ansible package to
> maintain this package.

CC'ed harlan, not sure if he is not drowning in -devel@ :)

Bug#849776: openbsd-inetd: PID file not created any more so update-inetd can't reload the service

[Valentin Vidic]

Package: openbsd-inetd
Version: 0.20160825-1
Severity: normal

Dear Maintainer,

New version of the package does not create the PID file in
/var/run/inetd.pid anymore.  This was previously used by
update-inetd to reload the daemon after updating the
configuration.

AFAICT, PID needs to be created by the systemd service and
the init script.  This was discovered via csync2 package that
calls update-inetd in postinst but the service is not
available anymore after installation - a manual restart of
openbsd-inetd is required now.

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

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

Versions of packages openbsd-inetd depends on:
ii  init-system-helpers  1.46
ii  libbsd0  0.8.3-1
ii  libc62.24-8
ii  libevent-2.0-5   2.0.21-stable-2.1
ii  libwrap0 7.6.q-25
ii  lsb-base 9.20161125
ii  tcpd 7.6.q-25
ii  update-inetd 4.43

openbsd-inetd recommends no packages.

openbsd-inetd suggests no packages.

-- no debconf information

Bug#709384: dh_installinit: Please add an option to no enable the service at installation

[Evgeni Golov]

[ only 3 years later… ]

On Mon, Jan 27, 2014 at 01:32:35AM +0100, Laurent Bigonville wrote:
> Le Sat, 25 Jan 2014 15:40:18 -0400,
> Joey Hess  a écrit :
> 
> > Laurent Bigonville wrote:
> > > Now that the usage of /etc/default/* file to prevent a service to
> > > start is discouraged, it might be interesting to add an option that
> > > allow the maintainer to not automatically enable the service at
> > > installation.
> > 
> > Isn't that what dh_installinit --no-start does?
> > 
> 
> dh_installinit --no-start prevents the service to be started at the
> installation of the package. But the service is still enabled, this
> means that the service will be started at the next reboot of the
> machine.

--no-start will also prevent the service to be restarted during upgrade,
which one still want to do, even if the service is not enabled-by-default.

> What I was proposing here is to prevent the call to update-rc.d.

Actually, you'd need a call to update-rc.d, but not with "defaults" as
parameter, but with "disabled-if-new" (or similar, this is not-existant
today) as you want:
  * not to enable the service if it was disabled
  * update the service if it was enabled

Regards
Evgeni

Bug#849777: shutter: CVE-2016-10081: Insecure use of perl exec()

[Salvatore Bonaccorso]

Source: shutter
Version: 0.88.3-1
Severity: grave
Tags: upstream security
Justification: user security hole
Forwarded: https://bugs.launchpad.net/shutter/+bug/1652600

Hi,

the following vulnerability was published for shutter.

CVE-2016-10081[0]:
| /usr/bin/shutter in Shutter through 0.93.1 allows user-assisted remote
| attackers to execute arbitrary commands via a crafted image name that
| is mishandled during a "Run a plugin" action.

If you fix the vulnerability please also make sure to include the
CVE (Common Vulnerabilities & Exposures) id in your changelog entry.

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2016-10081
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-10081
[1] https://bugs.launchpad.net/shutter/+bug/1652600

Regards,
Salvatore

Bug#849577: stubby also

[Stephane Bortzmeyer]

Note that stubby has the same bug:

% stubby @2001:4b98:dc2:43:216:3eff:fea9:41a -L -z 127.0.0.1:8053 
Could not convert "2001:4b98:dc2:43:216:3eff:fea9:41a" to an IP dict: A helper 
function was supposed to return a certain type for an item, but the wrong type 
was given.
Could not convert "127.0.0.1:8053" to an IP dict: A helper function was 
supposed to return a certain type for an item, but the wrong type was given.

Again, no problem is I use upstream code (from the git repos):

% src/tools/stubby  @2001:4b98:dc2:43:216:3eff:fea9:41a -L -z 127.0.0.1:8053

(and then it works)

Bug#848721: apt: please make the moo reproducible

[David Kalnischkies]

Good day mere mortal,

On Mon, Dec 19, 2016 at 08:57:57PM +0100, Chris Lamb wrote:
> Whilst working on the Reproducible Builds effort [0], we noticed
> that apt could not moo reproducibly.

Your prayer has been received by deity@ …


> Patch attached.

… but your sacrifice is not enough.

Given your intend is on changing the behavior of the cow itself, the cow
usually expects full dedication to the cause with mandatory minimum
service periods and probation. Enlisting your first born child¹ in the
service of the cow might be an acceptable alternative.

Failing that your prayer has to change to be considered worthy and find
support by a current member of the inner circle:


>  static std::string getMooLine() {/*{{{*/
> -   time_t const timenow = time(NULL);
> +   time_t const timenow = GetTimeNow();

On a nitpick level the cow feels kinda tricked by a method named
GetTimeNow to report not always the time now, but what an external has
forced. GetSecondsSinceEpoch() might be better.

> struct tm special;
> localtime_r(&timenow, &special);
> enum { NORMAL, PACKAGEMANAGER, APPRECIATION, AGITATION, AIRBORN } line;
> @@ -163,7 +164,8 @@ bool DoMooApril(CommandLine &)
> /*{{{*/
>   /*}}}*/
>  bool DoMoo(CommandLine &CmdL)
> /*{{{*/
>  {
> -   time_t const timenow = time(NULL);
> +   const time_t timenow = GetTimeNow();

Asking the lord of time two times in the same meditation is considered
bad style especially now that this can generate errors.
The cow suggests passing time forward as parameter.


> +   const char *source_date_epoch = getenv("SOURCE_DATE_EPOCH");
> +
> +   if (!source_date_epoch) {
> +  return time(NULL);
> +   }

The cow dislikes the '!' as it is easy to miss and prefers the far
noisier "== nullptr" here. It also prefers its curly brackets on new
lines even through even its current followers tend to dislike it, but
inertia (as it is so common for cows to be "cowheaded").

The followers advice is dropping the curly brackets for these one-line
ifs to make them all happy.

> +   errno = 0;
> +   char *endptr;
> +   const unsigned long long epoch = strtoull(source_date_epoch, &endptr, 10);

The speaker wonders how reproducible such a call is if it is effected by
LANG – or is that just "bad environment setup"?

And while we are at it a minor nitpick: We prefer the const-modifier to be set
after the type.

> +   if ((errno == ERANGE && (epoch == ULLONG_MAX || epoch == 0))
> + || (errno != 0 && epoch == 0)) {
> +  _error->Error("SOURCE_DATE_EPOCH: strtoull: %s\n", strerror(errno));
> +   }

Using _error->Errno here would be more consistent.


> +   if (endptr == source_date_epoch) {
> +  _error->Error("SOURCE_DATE_EPOCH: No digits were found: %s\n", endptr);
> +   }
> +   if (*endptr != '\0') {
> +   _error->Error("SOURCE_DATE_EPOCH: Trailing garbage: %s\n", endptr);
> +   }

At least some of the if's might be better of as else if's as they can
produce incorrect messages e.g. if the cow itself operates it:

E: SOURCE_DATE_EPOCH: No digits were found: moo
E: SOURCE_DATE_EPOCH: Trailing garbage: moo

Also, far more strange perhaps:

E: SOURCE_DATE_EPOCH: No digits were found: m00
E: SOURCE_DATE_EPOCH: Trailing garbage: m00

The message style is a bit uncommon for apt in general. Unlikely that
a human is going to encounter them a lot, but perhaps something like:

Environment variable SOURCE_DATE_EPOCH has invalid value "%s" (not
starting with digits, trailing garbage, …).


> +   if (epoch > ULONG_MAX) {
> +  _error->Error("SOURCE_DATE_EPOCH: %llu must be <= %lu", epoch, 
> ULONG_MAX);
> +   }

Why is that so that we add pain for our grand-grand-grand-…-children but
support our grand-grand-grand-…-parents parsing a long long future and
past, but accepting only a long future in the end?

The cow fears this is an attempt at making it say something which could
be interpreted as "You don't need to talk about the (far) future, as
there is none for mankind", but much like the god of the christian
faith(s) it likes to put enormous trust into mankind to fix their ways
desperate an endless stream of facts to the contrary.

We hence do expect an explanatory comment at the minimum.


> +   return (time_t) epoch;

we should be using a c++-style cast here: static_cast(epoch)

It makes no practical difference here, but its good style to declare
explicitly what cast is needed to avoid problems down the road if the
"this obviously never changes" code ever gets rewritten.

With all these errors previously I wonder if its a good idea to still be
using epoch value btw.


Also: As this is adding a non-trivial amount of code to a much beloved
and very important feature it would be in your best interest to add
some very basic tests for this [for you] obviously very important
behaviour² so future i

Bug#842239: Not fixed in 1.6.0-2, please reopen

[Jeffrey Ratcliffe]

On 30 December 2016 at 18:46, Roderich Schupp  wrote:
> I expected the date field to default to "now", not "last night 1 am".

Ah. The date field should default to the offset of "now" you last
used. i.e. if you set it to today before saving, then the next time
you start gscan2pdf, it should also default to today.

The reason for using an offset is if you are scanning historical
documents, it is tiresome to reset it by the same several years every
time you start.

So please save a test document, setting first the date to today, quit,
restart, and check that the save dialogue is still showing today.

Perhaps I should add a "now" checkbox, which would then ghost the
document date when activated. Having said that, this would only save
one click.

Regards

Jeff

Bug#849775: emacs24: FTBFS randomly (Wrong type argument: number-or-marker-p, nil)

[Santiago Vila]

Package: src:emacs24
Version: 24.5+1-7.1
Severity: serious

Dear maintainer:

I tried to build this package in stretch with "dpkg-buildpackage -A"
(which is what the "Arch: all" autobuilder would do to build it)
but it failed:


[...]
 debian/rules build-indep
dh build-indep --parallel
   debian/rules override_dh_testdir
make[1]: Entering directory '/<>/emacs24-24.5+1'
dh_testdir debian/emacsVER.postinst
make[1]: Leaving directory '/<>/emacs24-24.5+1'
   dh_update_autotools_config -i -O--parallel
   debian/rules override_dh_auto_configure
make[1]: Entering directory '/<>/emacs24-24.5+1'
dh_testdir debian/emacsVER.postinst
./autogen.sh
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)

[... snipped ...]

make[3]: Entering directory '/<>/emacs24-24.5+1/debian/build-nox/lisp'
cd ../leim && /usr/bin/make -w all EMACS="../src/emacs"
make[4]: Entering directory '/<>/emacs24-24.5+1/debian/build-nox/leim'
EMACSLOADPATH= '../src/emacs' -batch --no-site-file --no-site-lisp -batch -l 
ja-dic-cnv \
  -f batch-skkdic-convert -dir "./../lisp/leim/ja-dic" \
  "./SKK-DIC/SKK-JISYO.L"
Reading file 
"/<>/emacs24-24.5+1/debian/build-nox/leim/SKK-DIC/SKK-JISYO.L" ...
Processing OKURI-ARI entries ...
Processing POSTFIX entries ...
Processing PREFIX entries ...
Collecting OKURI-NASI entries ...
collected 26% ...
collected 30% ...
collected 40% ...
collected 50% ...
collected 60% ...
collected 70% ...
collected 80% ...
collected 90% ...
Processing OKURI-NASI entries ...
processed 10% ...
processed 20% ...
processed 30% ...
processed 40% ...
processed 50% ...
processed 60% ...
processed 70% ...
processed 80% ...
processed 90% ...
processed 100% ...
Saving file 
/<>/emacs24-24.5+1/debian/build-nox/lisp/leim/ja-dic/ja-dic.el...
Wrong type argument: number-or-marker-p, nil
Makefile:138: recipe for target '../lisp/leim/ja-dic/ja-dic.el' failed
make[4]: *** [../lisp/leim/ja-dic/ja-dic.el] Error 255
make[4]: Leaving directory '/<>/emacs24-24.5+1/debian/build-nox/leim'
Makefile:335: recipe for target 'leim' failed
make[3]: *** [leim] Error 2
make[3]: Leaving directory '/<>/emacs24-24.5+1/debian/build-nox/lisp'
Makefile:365: recipe for target 'lisp' failed
make[2]: *** [lisp] Error 2
make[2]: Leaving directory '/<>/emacs24-24.5+1/debian/build-nox'
debian/rules:368: recipe for target 'override_dh_auto_build' failed
make[1]: *** [override_dh_auto_build] Error 2
make[1]: Leaving directory '/<>/emacs24-24.5+1'
debian/rules:235: recipe for target 'build-indep' failed
make: *** [build-indep] Error 2
dpkg-buildpackage: error: debian/rules build-indep gave error exit status 2


This is essentially the same bug as #842728, but in emacs24.
[ If you need a full build log, just say so and I will include it ]

I guess, but I don't really know, that the same fix that worked
for emacs25 should work here as well. 

Thanks.

Bug#849637: /sys/devices/system/cpu/online SELinux context

[Dominick Grift]

On Fri, 30 Dec 2016 17:17:24 +0100 cgzones  wrote:
> Hi,
> thanks for your response.
> I assigned this bug to systemd, cause I did not know any better and
> thought the sysfs filesystem is managed by systemd, like /run.
> 
> Btw, /dev/pts/ptmx is also mislabeled:
> 
> root@debianSE:~# restorecon -vv -R -n /dev
> Warning no default label for /dev/mqueue
> Warning no default label for /dev/pts/0
> Would relabel /dev/pts/ptmx from system_u:object_r:devpts_t:s0 to
> system_u:object_r:ptmx_t:s0
> 

That context spec for /dev/pts/ptmx should probably be dropped and just
leave it devpts_t

> 
> Kindly Regards,
> Christian Göttsche
> 
> 2016-12-30 12:39 GMT+01:00 Laurent Bigonville :
> > reassign 849637 policycoreutils
> > thanks
> >
> > On Thu, 29 Dec 2016 12:36:30 +0100 cgzones  wrote:
> >
> >> When running a SELinux enabled system /sys/devices/system/cpu/online
> >> is mislabeled after boot:
> >>
> >> root@test1:/root/selinux/policy# restorecon -vv -R -F -n /sys
> >> Would relabel /sys/devices/system/cpu/online from
> >> system_u:object_r:sysfs_t:s0 to system_u:object_r:cpu_online_t:s0
> >
> > Not sure why this is assigned to systemd as this is not created by systemd.
> >
> > It's working with sysvinit because the selinux-autorelabel LSB initscript is
> > explicitly relabeling it during boot.
> >
> > Under systemd, that initscript is masked by the selinux-autorelabel.service.
> >
> > I was planning to add a tmpfiles for this, but apparently I forgot about it.
> >
> > Reassigning to policycoreutils
> >
> > Laurent Bigonville
> 
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift



signature.asc
Description: OpenPGP digital signature

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

[Willi Mann]

Hi Klaus,

Am 2016-12-30 um 18:36 schrieb Klaus Ethgen:
> Hi Willi,
> 
> Am Fr den 30. Dez 2016 um 18:18 schrieb Willi Mann:
>> can you elaborate how this could be exploited?
> 
> Well, log principally contains untrusted data that could be injected
> from untrusted source. That is no security hole itself.
> 
> But when that data gets displayed with the wrong charset, that can
> trigger problems in window managers (for example). See xterm which can
> be controlled via ansii sequences. Even more, it could trigger stream
> conversion problems if the UTF-8 implementation is not really fully
> tested with broken streams.

OK, I understand that text from untrusted sources is dangerous and could
be harmful to your terminal - and that it is better to assume logfiles
to be such an untrusted source. However, the change only affects
mailers, right? For mailers, I would expect them to not trust any mails
they get, and therefore to remove any dangerous byte sequences.
Otherwise, the mailer contains the security hole - and an attacker does
not need to go via logfiles and logwatch, he just sends you mail.

When running logwatch such that it writes its output to the terminal,
the change does not have any effect on the security, right?. If there is
a security issue with untrusted data, it was already there before.

So far, I cannot see that the change you mentioned would be problematic.
What I do see is that it might be wise to sanitize the output of
logwatch. A possible way to go might be to remove any byte with value <
0x20 - unless it is a newline or tab. But that is independent of the
ISO-8859-15 to utf-8 change.

Bye
Willi

Bug#849637: /sys/devices/system/cpu/online SELinux context

[Dominick Grift]

On Fri, 30 Dec 2016 12:39:05 +0100 Laurent Bigonville 
wrote:
> reassign 849637 policycoreutils
> thanks
> 
> On Thu, 29 Dec 2016 12:36:30 +0100 cgzones  wrote:
> 
>  > When running a SELinux enabled system /sys/devices/system/cpu/online
>  > is mislabeled after boot:
>  >
>  > root@test1:/root/selinux/policy# restorecon -vv -R -F -n /sys
>  > Would relabel /sys/devices/system/cpu/online from
>  > system_u:object_r:sysfs_t:s0 to system_u:object_r:cpu_online_t:s0
> 
> Not sure why this is assigned to systemd as this is not created by systemd.
> 
> It's working with sysvinit because the selinux-autorelabel LSB 
> initscript is explicitly relabeling it during boot.
> 
> Under systemd, that initscript is masked by the selinux-autorelabel.service.
> 
> I was planning to add a tmpfiles for this, but apparently I forgot about it.
> 
> Reassigning to policycoreutils
> 
> Laurent Bigonville

you should be able to add a genfscon() in policy for this, provided that
the kernel is not too old to support that feature

I would avoid the alternative if possible
> 
> 

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift



signature.asc
Description: OpenPGP digital signature

Bug#767071: rdnssd drops settings from /etc/resolv.conf

[Milan Zamazal]

I wonder why such a serious bug hasn't been fixed yet.  I had to
reinstall a Debian machine unexpectedly and being confronted with this
bug in the rush was no pleasant experience.  I wasted a significant
amount of time finding out what was the hidden thing rendering my newly
installed system into an unusable state.  If it at least put a comment
line to resolv.conf informing about the source of its modification, I
could simply remove the package immediately and be done with the problem
(it would still be a bug, but much less annoying one).

Silently overwriting an important system file without being asked to do
so and without any explanatory notice is not acceptable.  Please either
fix the bug or make sure the package is not installed by default.

Thank you,
Milan

Bug#843589: Change severity

[bugs-debian]

Hi,

I don't really know if this should be an RC bug, but this package has
entered testing. And as such, migration is not possible without fetching
source package.

Adrien

Bug#849774: perl: SSl certificate verify failing for www.spdyn.de

[Tobias Rupf]

Package: perl
Version: 5.24.1~rc4-1
Severity: important

Dear Maintainer,

   * What led up to the situation?
   update from Debian stable to testing

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   using ddclient with update.spdyn.de with ssl=true hich was working in jessie
   using "GET update.spdyn.de" produces same error in Perl

   * What was the outcome of this action?
   SSL connect attempt failed error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed at 
/usr/share/perl5/LWP/Protocol/http.pm line 47

   * What outcome did you expect instead?
   successfol verification of server cert as with firefox or
   "openssl s_client -host update.spdyn.de -port 443"


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.8.0-2-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 perl depends on:
ii  dpkg   1.18.15
ii  libperl5.245.24.1~rc4-1
ii  perl-base  5.24.1~rc4-1
ii  perl-modules-5.24  5.24.1~rc4-1

Versions of packages perl recommends:
ii  netbase  5.3
pn  rename   

Versions of packages perl suggests:
ii  libterm-readline-gnu-perl  1.35-1
ii  make   4.1-9
pn  perl-doc   

-- no debconf information

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

[Gianfranco Costamagna]

Hello,

>I found one more issue...
>
>- /usr/share/xtrkcad/{logo.bmp, html, examples, demo} should be in 
>/usr/share/doc/xtrkcad


did you also merge the debian improvements from Mike?

G.

Bug#849636: apt-daily: do not use pidof

[David Kalnischkies]

Control: severity -1 wishlist

On Thu, Dec 29, 2016 at 12:22:02PM +0100, cgzones wrote:
> The script '/usr/lib/apt/apt.systemd.daily' uses 'pidof dbus-daemon'
> to check whether dbus is running and whether to send a message.
> With SELinux enabled this causes avc denials like:
[…]
> I do not like to grant apt these permissions but I also want apt to
> announce an update to dbus,
> so can you rework the dbus check?

Perhaps. Given you are the first person in 8 years to complain about
this (#438803) perhaps you have also an idea how as I have neither
a SELinux setup nor know what you would deem acceptable.

(truth be told, I don't even use that cron job, so I am not going to be
available for review above very trivial changes and even that…)

I guess we could use (pseudo code) "if systemd; then systemctl is-active
dbus; else pidof dbus; fi" but that would really need someone to verify
that this has the intended result (and is available in your setup).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#439121: Add a .pc file for libapt-pkt

[David Kalnischkies]

Hi,

On Wed, Dec 28, 2016 at 12:24:41AM +0100, Corentin Noël wrote:
> Please note that I haven't been able to test the new test in the debian
> package.

Feel free to ask specifics as this is supposed to be easy™ and more and
more packages use this, so knowing how to run them should be useful for
other packages as well.

The actual invokation depends on your system/preferences, but the
manpage 'autopkgtest' does a reasonable job of explaining them.
Something like that should work:

0) [do once] setup sbuild + a (s)chroot "unstable-amd64-sbuild"
   see https://wiki.debian.org/sbuild
1) autopkgtest /path/to/source/apt -- schroot unstable-amd64-sbuild

That will built the packages first and then run all tests.


>  apt-inst/CMakeLists.txt   |  3 +++
>  apt-inst/apt-inst.pc.in   | 11 +++
>  apt-pkg/CMakeLists.txt|  3 +++
>  apt-pkg/apt-pkg.pc.in | 10 ++
>  debian/libapt-pkg-dev.install |  1 +
>  debian/tests/control  |  5 +++--
>  6 files changed, 31 insertions(+), 2 deletions(-)
>  create mode 100644 apt-inst/apt-inst.pc.in
>  create mode 100644 apt-pkg/apt-pkg.pc.in

Looks like the test you refer to isn't included in the diff. :)


> diff --git a/debian/tests/control b/debian/tests/control
[…]
> -Tests: run-tests
> +Tests: run-tests, autopkgtest

Please don't name the new test like the tool running all these tests as
that would be quite confusing (something can be said about having the
other test named 'run-tests' …).


Best regards

David Kalnischkies


signature.asc
Description: PGP signature

Bug#849773: O: libnss-extrausers

[Bernhard R. Link]

Package: wnpp
Severity: normal

Hi,

I'm hereby orphaning libnss-extrausers, after neglecting it a bit for
too long. There is some open bug report with patches that do not apply,
and the whole thing got a bit out of date as nss is a moving target
(and the nss modules it was forked of are now very different).
So if you take it be ready for a large chunk of upstream work.

Packaging nss modules is also something of an unsolved problem with
multi-arch. (You can multi-arch them, but then people have to make sure
to install all the right architectures or get strange errors if they
forget), so that is no easy thing either.

Might perhaps best to just drop it and use the db backend instead (those
are not in another directory, but at least can keep them outside the
main files).

You can find the package in git at
https://anonscm.debian.org/cgit/collab-maint/libnss-extrausers.git/log/?h=debian
(including the last upload orphaning it).

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

Bug#849700: [Pkg-mc-devel] Bug#849700: mcedit does not more work

[Michelle Konzack]

Now I have tested it with a new user and it does not have this problem.

However, I have even this problem, if I log into the console without X.

I have removed my ~/.bashrc and ~/.bash_login plus 
~/.config/mc and ~/.cache/mc and the error persist.

On the other side, it pase som old copied things into
the open file which came from editing of a CSS file.

So, if I have copied some things in mcedit,
where in $HOME is this informatiuon stored?

-- 
Michelle KonzackITSystems
GNU/Linux Developer 0033-6-61925193

Bug#849403: androguard

[Hans-Christoph Steiner]

androguard can extract and convert the binary AndroidManifest.xml, its
python2 and already in Debian.

Bug#849759: duperemove: programs should be in /usr/bin rather than /usr/sbin

[Peter Zahradnik]

On 12/30/2016 07:56 PM, Adam Borowski wrote:

Package: duperemove
Version: 0.11~beta4-1
Severity: normal

Hi!
For some reason you've put the executables in /usr/sbin.  All of programs
shipped by duperemove are fully functional as non-root, and often useful:
an user may want to dedupe their data files, unprivileged containers, etc.


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

Kernel: Linux 4.9.0+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages duperemove depends on:
ii  libc6 2.24-8
ii  libglib2.0-0  2.50.2-2
ii  libsqlite3-0  3.15.2-2

duperemove recommends no packages.

duperemove suggests no packages.

-- no debconf information

Hi,

I see, will upload new version with /usr/bin path, btw thanks for 
patches and review earlier


Peter

Bug#849390: google-android-installers

[Hans-Christoph Steiner]

It turns out that the approach in google-android-installers is not
maintainable going forward, so we need to split out each source package
from google-android-installers into its own source package.  So we'll
need to remove google-android-ndk-installer from
google-android-installers.  We can leave the rest in
google-android-installers as is for stretch.

Also, only the source package of google-android-installers is
1472023576, the google-android-ndk-installer binary package produced by
it has a binary package version of 12.b+1.

Bug#849772: RM: xfm -- ROM; dependencies lost required functionality

[Bernhard R. Link]

Package: ftp.debian.org
Severity: normal

Please remove xfm from unstable. It wasn't in jessie and isn't
that useful anymore since magic dropped the support it needs to
identify file types.

Bernhard R. Link
-- 
F8AC 04D5 0B9B 064B 3383  C3DA AFFC 96D1 151D FFDC

Bug#849592: bug report - icedove: href links inoperative

[Rick Lutowski]

On 12/30/2016 02:10 AM, Carsten Schoenert wrote:

Regarding the solutions in the web post you referenced:

1. My system /usr/bin already has a link pointing iceweasel to icedove.

You mean /usr/bin/iceweasel -> /usr/bin/firefox-esr ?


Yes.  Sorry for the typo.  Link in /usr/bin is
iceweasel -> ../lib/firefox-esr/firefox-esr


There is no reason to configure this setting explicit to firefox. And
there is no reason to use a mimeTypes.rdf at all if the system defaults
are working. Icedove/Thunderbird is creating a new file if needed. So I
would try first to rename the existing mimeTypes.rdf so Icedove is using


Removing (renaming) icedove mimeTypes.rdf makes no difference.  Same 
error persists.


You mean mozilla-thunderbird, not Icedove/Thunderbird?  (My ~home has a  
.mozilla-thunderbird

config directory, but it is inactive; not accessed since 2013.)


the system defaults. Then you can add a single new rule for html to see
what is happen.

Please read also
http://kb.mozillazine.org/Actions_for_attachment_file_types
This file describes attachments.  Have previously used  (Edit : 
Preferences : Attachments : Incoming) to configure
attachment handlers.  Viewers for all attachments I typically get via 
icedove are working well.



http://kb.mozillazine.org/MimeTypes.rdf


This file describes mimeTypes.rdf for mozilla/firefox.  firefox is 
working fine.


One interesting point is the first paragraph says firefox mimetypes can 
be configured using
"Tools -> Options 
 
-> Content / File Types -> Manage..."
However, my firefox does not have a "Tools -> Options . . ." 

Under Tools there is only "Downloads, Add-ons, Sign In to Sync, Web 
Developer, Pager Info"


Suspect is not relevant to the icedove problem (but am no expert.)


Because others are having this problem, it might be good to modify
the next icedove release to allow html http and https handlers to be
set or changed via menubar (Edit : Preferences : Attachments : Incoming).
Can someone on the icedove development team do this before the next
release?

No as this is user configuration side. There is no default configuration
without massive impact. This setting needs to be done by individual user.


Am at a loss as to what the problem is.  html links in icedove used to 
work in the past, then stopped working after one of
the previous icedove upgrades.  Do not remember which version, but was 2 
or 3 upgrades ago.  Was hoping another upgrade

would fix it, but this has not happened.

Also have Chromium installed, but this browser is no longer operative at 
all.  Will not even display a local (file:///) page.
Do not really care because I always use firefox.  Am sure Chromium used 
to work, so some upgrade must have broken

it too.

Upgrades can have consequences!

Anyway, have become very good at copying and pasting links from icedove 
to firefox for viewing email content.  I can continue to do this 
indefinitely if necessary.  No need to continue to pursue this further, 
but if you ever think of anything  that might be relevant to this 
problem, please let me know.


Thanks very much for your quick responses and suggestions.

--
Rick Lutowski
r...@jreality.com
512-688-1675

Bug#849196: Sometimes, supress_warnings misses one of its attributes

[Ole Streicher]

Hi Sandro,

On 30.12.2016 15:01, Sandro Tosi wrote:
> On Fri, Dec 23, 2016 at 9:47 AM, Ole Streicher  wrote:
>> This is a regression; it did not happen with 1.11. Please fix this
>> regression ASAP so that skimage can migrate safely before the freeze.
> 
> as asked on the github issue, is disabling parallel tests execution in
> skimage a viable temporary solution?

For the moment, I disabled the build time tests in skimage completely
because of #849196, to ensure it migrates before the freeze (I took the
really latest chance to do so). Therefore, I would not touch the package
before Jan 5. Once it is in testing, It would be however very important
to re-enable the tests, since this is more a crude hack than a clean
solution.

Unfortunately, I am not familar with the skimage code (I just did the
firefighter job here); specifically I don't know where to switch off
parallel tests, and what other implications that has. Maybe, you discuss
this with Yaroslav (in Cc), who is the skimage package maintainer? Also
the parallel bug I opened on the "scikit-image" github (referenced on
the numpy issue) may help there. Finally, Yaroslav should decide here.

I personally however would much more prefer to go back to the latest
numpy 1.11 in testing, and update only after 1.12 is released. I very
dislike having workarounds because a beta or a release candidate
uploaded to testing is buggy. And I would also prefer not to have a beta
or RC shipped with Stretch.

Best regards

Ole

Bug#849771: synaptic: feature request: recommend reload in synaptic if packages are not found

[Georg Stillfried]

Package: synaptic
Version: 0.81.2
Severity: wishlist

Dear Maintainer,

I ran into a newbie's mistake. I wanted to install a new package using
synaptic and received an error that the package was not found. 
The problem was that the local repository database was out of date. 
After reloading the repository database, the new package installed fine. 
The problem is that it took me several days to notice my mistake. 

My suggestion is to include a piece of text in the error message that 
appears when a download of a package fails. The piece of text should 
recommend to the user to reload the repository database and try again. 
This could also be made conditional on the amount of time since the last
repository database reload (e.g., one hour). 

Thank you
Georg Stillfried


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

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

Versions of packages synaptic depends on:
ii  hicolor-icon-theme   0.13-1
ii  libapt-inst1.5   1.0.9.8.3
ii  libapt-pkg4.12   1.0.9.8.3
ii  libatk1.0-0  2.14.0-1
ii  libc62.19-18+deb8u6
ii  libcairo-gobject21.14.0-2.1+deb8u1
ii  libcairo21.14.0-2.1+deb8u1
ii  libept1.4.12 1.0.12.1
ii  libgcc1  1:4.9.2-10
ii  libgdk-pixbuf2.0-0   2.31.1-2+deb8u5
ii  libglib2.0-0 2.42.1-1+b1
ii  libgtk-3-0   3.14.5-1+deb8u1
ii  libpango-1.0-0   1.36.8-3
ii  libpangocairo-1.0-0  1.36.8-3
ii  libstdc++6   4.9.2-10
ii  libvte-2.90-91:0.36.3-1
ii  libx11-6 2:1.6.2-3
ii  libxapian22  1.2.19-1
ii  libxext6 2:1.3.3-1
ii  zlib1g   1:1.2.8.dfsg-2+b1

Versions of packages synaptic recommends:
ii  libgtk2-perl   2:1.2492-4
ii  policykit-10.105-8
ii  rarian-compat  0.8.1-6

Versions of packages synaptic suggests:
pn  apt-xapian-index 
pn  deborphan
pn  dwww 
pn  menu 
pn  software-properties-gtk  
ii  tasksel  3.31+deb8u1

-- no debconf information

Bug#849666: gradm2: FTBFS on arm64: /usr/bin/ld: cannot find -lfl

[GCS]

Control: tags -1 -unreproducible

On Fri, Dec 30, 2016 at 12:10 PM, Adrian Bunk  wrote:
> On Fri, Dec 30, 2016 at 08:36:55AM +0100, László Böszörményi wrote:
>> Will try the QEMU + pbuilder build as
>> well, but you might just got some other, transient problem.
>
> This does not look lika a transient problem:
>
> Recently (in 2.6.1-1.1) flex dropped the dependency on libfl-dev.
>
> RC bugs were filed for packages that now need a build-dependency on
> libfl-dev, but it is possible that gradm2 was missed for some reason.
 Indeed, gradm2 was missed. Added the libfl-dev build dependency and
upload will happen very soon.

Regards,
Laszlo/GCS

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

[Jason Pyeron]

A very rudimentary test:

/projects/logwatch
$ perl -e 'for ($i=0; $i<256; ++$i) {print chr($i);}' | hexdump.exe -C
  00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  ||
0010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  ||
0020  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !"#$%&'()*+,-./|
0030  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|
0040  40 41 42 43 44 45 46 47  48 49 4a 4b 4c 4d 4e 4f  |@ABCDEFGHIJKLMNO|
0050  50 51 52 53 54 55 56 57  58 59 5a 5b 5c 5d 5e 5f  |PQRSTUVWXYZ[\]^_|
0060  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
0070  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
0080  80 81 82 83 84 85 86 87  88 89 8a 8b 8c 8d 8e 8f  ||
0090  90 91 92 93 94 95 96 97  98 99 9a 9b 9c 9d 9e 9f  ||
00a0  a0 a1 a2 a3 a4 a5 a6 a7  a8 a9 aa ab ac ad ae af  ||
00b0  b0 b1 b2 b3 b4 b5 b6 b7  b8 b9 ba bb bc bd be bf  ||
00c0  c0 c1 c2 c3 c4 c5 c6 c7  c8 c9 ca cb cc cd ce cf  ||
00d0  d0 d1 d2 d3 d4 d5 d6 d7  d8 d9 da db dc dd de df  ||
00e0  e0 e1 e2 e3 e4 e5 e6 e7  e8 e9 ea eb ec ed ee ef  ||
00f0  f0 f1 f2 f3 f4 f5 f6 f7  f8 f9 fa fb fc fd fe ff  ||
0100

/projects/logwatch
$ perl -e 'binmode(STDOUT, ":utf8"); for ($i=0; $i<256; ++$i) {print STDOUT 
chr($i);}' | hexdump.exe -C
  00 01 02 03 04 05 06 07  08 09 0a 0b 0c 0d 0e 0f  ||
0010  10 11 12 13 14 15 16 17  18 19 1a 1b 1c 1d 1e 1f  ||
0020  20 21 22 23 24 25 26 27  28 29 2a 2b 2c 2d 2e 2f  | !"#$%&'()*+,-./|
0030  30 31 32 33 34 35 36 37  38 39 3a 3b 3c 3d 3e 3f  |0123456789:;<=>?|
0040  40 41 42 43 44 45 46 47  48 49 4a 4b 4c 4d 4e 4f  |@ABCDEFGHIJKLMNO|
0050  50 51 52 53 54 55 56 57  58 59 5a 5b 5c 5d 5e 5f  |PQRSTUVWXYZ[\]^_|
0060  60 61 62 63 64 65 66 67  68 69 6a 6b 6c 6d 6e 6f  |`abcdefghijklmno|
0070  70 71 72 73 74 75 76 77  78 79 7a 7b 7c 7d 7e 7f  |pqrstuvwxyz{|}~.|
0080  c2 80 c2 81 c2 82 c2 83  c2 84 c2 85 c2 86 c2 87  ||
0090  c2 88 c2 89 c2 8a c2 8b  c2 8c c2 8d c2 8e c2 8f  ||
00a0  c2 90 c2 91 c2 92 c2 93  c2 94 c2 95 c2 96 c2 97  ||
00b0  c2 98 c2 99 c2 9a c2 9b  c2 9c c2 9d c2 9e c2 9f  ||
00c0  c2 a0 c2 a1 c2 a2 c2 a3  c2 a4 c2 a5 c2 a6 c2 a7  ||
00d0  c2 a8 c2 a9 c2 aa c2 ab  c2 ac c2 ad c2 ae c2 af  ||
00e0  c2 b0 c2 b1 c2 b2 c2 b3  c2 b4 c2 b5 c2 b6 c2 b7  ||
00f0  c2 b8 c2 b9 c2 ba c2 bb  c2 bc c2 bd c2 be c2 bf  ||
0100  c3 80 c3 81 c3 82 c3 83  c3 84 c3 85 c3 86 c3 87  ||
0110  c3 88 c3 89 c3 8a c3 8b  c3 8c c3 8d c3 8e c3 8f  ||
0120  c3 90 c3 91 c3 92 c3 93  c3 94 c3 95 c3 96 c3 97  ||
0130  c3 98 c3 99 c3 9a c3 9b  c3 9c c3 9d c3 9e c3 9f  ||
0140  c3 a0 c3 a1 c3 a2 c3 a3  c3 a4 c3 a5 c3 a6 c3 a7  ||
0150  c3 a8 c3 a9 c3 aa c3 ab  c3 ac c3 ad c3 ae c3 af  ||
0160  c3 b0 c3 b1 c3 b2 c3 b3  c3 b4 c3 b5 c3 b6 c3 b7  ||
0170  c3 b8 c3 b9 c3 ba c3 bb  c3 bc c3 bd c3 be c3 bf  ||
0180
 
This confirms that binmode utf8 is needed to print out the full ASCII range.

> -Original Message-
> From: Jason Pyeron [mailto:jpye...@pdinc.us] 
> Sent: Friday, December 30, 2016 14:03
> To: Jason Pyeron; 'Willi Mann'; logwatch-de...@lists.sourceforge.net
> Cc: 849...@bugs.debian.org; 849531-forwar...@bugs.debian.org; 
> 'Klaus Ethgen'
> Subject: RE: [Logwatch-devel] Bug#849531: Possible security 
> problem,new logwatch sends mails with charset UTF-8
> 
> I have opened https://sourceforge.net/p/logwatch/bugs/56/ .
> 
> I am working a test case for this right now.
> 
> As I see it, there are 3 paths to test.
> 
> Output as STDOUT, file, and email. In each case does an 8bit 
> value (0x00..0xff unsigned) result in a valid UTF-8 character.
> 
> Is binmode(STDOUT, ":utf8") needed? Does it fix the issue if 
> it was needed?
> 
> > > -Original Message-
> > > From: Willi Mann
> > > Sent: Friday, December 30, 2016 12:18
> > > To: logwatch-devel
> > > Cc: 849...@bugs.debian.org; 
> 849531-forwar...@bugs.debian.org; Klaus Ethgen
> > > What would be your suggested fix?
> 
> 
> $ git show f9db5949c58321175bda66310156f43ae607109f
> commit f9db5949c58321175bda66310156f43ae607109f
> Author: bjorn 
> Date:   Sat Oct 15 17:38:40 2016 -0700
> 
> Changed encoding to UTF-8, as suggested by Goran Uddeborg.
> 
> diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
> index 0f863dc..0167755 100755
> --- a/scripts/logwatch.pl
> +++ b/scripts/logwatch.pl
> @@ -1162,9 +1162,9 @@ sub initprint {
>   }
>   #Config{output} html
>   if

Bug#849768: mousepad: no markdown option

[mrtea]

Package: mousepad
Version: 0.4.0-4ubuntu1
Severity: wishlist

Hi, I recently made to move to Debian. 

For text editing I've mostly used Mousepad. In my  previous distribution 
(Ubuntu)
there was an option to set markdown as filetype. This helped me because I use
markdown. 

I don't find any option for it when I install Mousepad from the Debian
repositories. Therefore I'd like to request this. 


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

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

Versions of packages mousepad depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  libc62.24-8
ii  libglib2.0-0 2.50.2-2
ii  libgtk-3-0   3.22.5-1
ii  libgtksourceview-3.0-1   3.22.1-1
ii  libpango-1.0-0   1.40.3-3

mousepad recommends no packages.

mousepad suggests no packages.

-- no debconf information

Bug#849769: [mipsel]: string.sub sometimes returns incorrect slice

[James McCoy]

Package: luajit
Version: 2.0.4+dfsg-1
Severity: important

Dear Maintainer,

Neovim's test suite was periodically failing on mipsel and after looking
into it, it turns out that luajit sometimes incorrectly handles
str:sub(i, j).

I instrumented the test to log the i, j, and size of the returned
string.  A snippet of the relevant code is below:

local shift = 0
while shift < #fcontents do
  local size = 3
  local s = fcontents:sub(shift + 1, shift + size)
  if shift + size < #fcontents then
io.stdout:write('shift+1: '..(shift)..', shift+size: 
'..(shift+size)..', s: '..#s..'\n')
eq(size, #s)
  end
  local wr = file_write(fp, s)
  eq(wr, #s)
  shift = shift + size
end

fcontents is a string of 4096 bytes, which we take 3 bytes at a time and
write to a file.  Sometimes, this fails because fcontents:sub returns
the rest of the string instead of just the slice requested.  As an
example:

…
shift+1: 2931, shift+size: 2934, s: 3
shift+1: 2934, shift+size: 2937, s: 3
shift+1: 2937, shift+size: 2940, s: 3
shift+1: 2940, shift+size: 2943, s: 1156
not ok 192 - file_write can write the whole file by small chunks

The final call (fcontents:sub(2940, 2943)) returned a slice from 2940 →
4096 (1156 bytes).

-- System Information:
Debian Release: stretch/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: mipsel (mips)

Kernel: Linux 4.7.0-0.bpo.1-octeon (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: unable to detect

Versions of packages luajit depends on:
ii  libc6 2.24-8
ii  libgcc1   1:6.2.1-5
ii  libluajit-5.1-common  2.0.4+dfsg-1

luajit recommends no packages.

luajit suggests no packages.

-- no debconf information

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#849770: exim4: bogus reject response on overlong lines

[Adam Borowski]

Package: exim4
Version: 4.88-2
Severity: normal

Hi!
If an user agent attempts to send a mail containing lines longer than SMTP's
allowed max of 998 bytes (such as reportbug -- #849765), exim's response is
extremely unhelpful.

The user gets:
.[ Mail delivery failed: returning message to sender ]
[-- Attachment #1 --]
[-- Type: text/plain, Encoding: 7bit, Size: 0.3K --]

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:

  kilob...@angband.pl
  sub...@bugs.debian.org

[-- Attachment #2 --]
[-- Type: message/delivery-status, Encoding: 7bit, Size: 0.2K --]

Reporting-MTA: dns; umbar.angband.pl

Action: failed
Final-Recipient: rfc822;sub...@bugs.debian.org
Status: 5.0.0

Action: failed
Final-Recipient: rfc822;kilob...@angband.pl
Status: 5.0.0

[-- Attachment #3 --]
[-- Type: text/rfc822-headers, Encoding: 7bit, Size: 0.6K --]

Return-path: 
Received: from kilobyte by umbar.angband.pl with local (Exim 4.88)
(envelope-from )
id 1cN1mV-0003BB-EP; Fri, 30 Dec 2016 19:19:55 +0100
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Adam Borowski 
To: Debian Bug Tracking System 
Subject: mutt: complains about GPGME
Message-ID: <148312199535.12156.10016894553068573730.report...@umbar.angband.pl>
X-Mailer: reportbug 7.1.1
Date: Fri, 30 Dec 2016 19:19:55 +0100
X-Exim-DSN-Information: Due to administrative limits only headers are returned
`

while the log entry is:
2016-12-30 19:19:55 1cN1mV-0003BB-EP <= kilob...@angband.pl U=kilobyte P=local 
S=7284 id=148312199535.12156.10016894553068573730.report...@umbar.angband.pl
2016-12-30 19:19:55 1cN1mV-0003BB-EP ** sub...@bugs.debian.org R=smarthost 
T=remote_smtp_smarthost: message is too big (transport limit = 1)
2016-12-30 19:19:55 1cN1mV-0003BB-EP ** kilob...@angband.pl R=smarthost 
T=remote_smtp_smarthost: message is too big (transport limit = 1)

All of these machines use exim:
My desktop (umbar.angband.pl) has unstable: 4.88-2
My mail server (tartarus.angband.pl) has stretch: 4.88~RC6-2
b.d.o MX (buxtehude.debian.org) has jessie: 4.84_2 (probably 4.84.2-2+deb8u1)


The rejection message to the user, which needs to include information about
why the mail was rejected, says just "failed".

The log message is outright wrong: "message is too big" clearly means the
whole mail rather than just a single line.


-- Package-specific info:
Exim version 4.88 #2 built 27-Dec-2016 16:36:29
Copyright (c) University of Cambridge, 1995 - 2016
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2016
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 TCP_Fast_Open
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
Configure owner: 0:0
Size of off_t: 8
Configuration file is /var/lib/exim4/config.autogenerated
# /etc/exim4/update-exim4.conf.conf
#
# Edit this file and /etc/mailname by hand and execute update-exim4.conf
# yourself or use 'dpkg-reconfigure exim4-config'
#
# Please note that this is _not_ a dpkg-conffile and that automatic changes
# to this file might happen. The code handling this will honor your local
# changes, so this is usually fine, but will break local schemes that mess
# around with multiple versions of the file.
#
# update-exim4.conf uses this file to determine variable values to generate
# exim configuration macros for the configuration file.
#
# Most settings found in here do have corresponding questions in the
# Debconf configuration, but not all of them.
#
# This is a Debian specific file

dc_eximconfig_configtype='satellite'
dc_other_hostnames='umbar.angband.pl'
dc_local_interfaces='127.0.0.1 ; ::1'
dc_readhost='angband.pl'
dc_relay_domains=''
dc_minimaldns='false'
dc_relay_nets=''
dc_smarthost='mail.angband.pl'
CFILEMODE='644'
dc_use_split_config='false'
dc_hide_mailname='true'
dc_mailname_in_oh='true'
dc_localdelivery='maildir_home'
mailname:umbar.angband.pl

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

Kernel: Linux 4.9.0+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages exim4 depends on:
ii  debconf [debconf-2.0]  1.5.59
ii  exim4-base 4.88-2
ii  exim4-daemon-light 4.88-2

exim4 recommends no packages.

exim4 suggests no packages.

-- debconf in

Bug#849577: Works upstream

[Stephane Bortzmeyer]

The bug does not seem to be upstream, with today upstream git
repository, it works:

% src/test/getdns_query  @2001:4b98:dc2:43:216:3eff:fea9:41a -s 
www.bortzmeyer.org 
SYNC response:
{
  "answer_type": GETDNS_NAMETYPE_DNS,
  "canonical_name": ,
...

Bug#849767: php5-fpm: segfault when using pdo_mysql.so

[Antonio Silva]

Package: php5-fpm
Version: 5.6.29+dfsg-0+deb8u1


php5-fmp is crashing when connecting to mysql using pdo with segfault.
The web server is nginx and i connect using fastcig parameter: 
fastcgi_pass unix:/var/run/php5-fpm-internal.sock; with default parameters.



I get the following gdb:


[New LWP 3316]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `php-fpm: pool 
internal '.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  _pdo_mysql_error (dbh=0x202b1a0, stmt=0x0, file=0x7f5fb5cc7f80 
"/build/php5-5.6.29+dfsg/ext/pdo_mysql/mysql_driver.c", line=586) at 
/build/php5-5.6.29+dfsg/ext/pdo_mysql/mysql_driver.c:67
67/build/php5-5.6.29+dfsg/ext/pdo_mysql/mysql_driver.c: No such file 
or directory.

(gdb) bt
#0  _pdo_mysql_error (dbh=0x202b1a0, stmt=0x0, file=0x7f5fb5cc7f80 
"/build/php5-5.6.29+dfsg/ext/pdo_mysql/mysql_driver.c", line=586) at 
/build/php5-5.6.29+dfsg/ext/pdo_mysql/mysql_driver.c:67
#1  0x7f5fb5cc6159 in pdo_mysql_handle_factory (dbh=0x202b1a0, 
driver_options=0x0) at 
/build/php5-5.6.29+dfsg/ext/pdo_mysql/mysql_driver.c:772
#2  0x7f5fb5ed422a in zim_PDO_dbh_constructor (ht=33730976, 
return_value=0x0, return_value_ptr=0x7f5fb5cc7f80, this_ptr=0x272ab50, 
return_value_used=0) at /build/php5-5.6.29+dfsg/ext/pdo/pdo_dbh.c:389
#3  0x006e7aea in dtrace_execute_internal 
(execute_data_ptr=, fci=, 
return_value_used=) at 
/build/php5-5.6.29+dfsg/Zend/zend_dtrace.c:97
#4  0x007a84d0 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7f5fc166b3a0) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:560
#5  0x00736820 in execute_ex (execute_data=0x7f5fc166b3a0) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:363
#6  0x006e7988 in dtrace_execute_ex 
(execute_data=0x7f5fc166b3a0) at 
/build/php5-5.6.29+dfsg/Zend/zend_dtrace.c:73
#7  0x007a8a13 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7f5fc166b188) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:592
#8  0x00736820 in execute_ex (execute_data=0x7f5fc166b188) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:363
#9  0x006e7988 in dtrace_execute_ex 
(execute_data=0x7f5fc166b188) at 
/build/php5-5.6.29+dfsg/Zend/zend_dtrace.c:73
#10 0x007a8a13 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7f5fc166afa8) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:592
#11 0x00736820 in execute_ex (execute_data=0x7f5fc166afa8) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:363
#12 0x006e7988 in dtrace_execute_ex 
(execute_data=0x7f5fc166afa8) at 
/build/php5-5.6.29+dfsg/Zend/zend_dtrace.c:73
#13 0x006e9826 in zend_call_function (fci=0x7ffe8ec467a0, 
fci_cache=0x0, fci_cache@entry=0x7ffe8ec46770) at 
/build/php5-5.6.29+dfsg/Zend/zend_execute_API.c:831
#14 0x0060f4f3 in zif_call_user_func_array (ht=, 
return_value=0x2724118, return_value_ptr=, 
this_ptr=, return_value_used=)

at /build/php5-5.6.29+dfsg/ext/standard/basic_functions.c:4790
#15 0x006e7aea in dtrace_execute_internal 
(execute_data_ptr=, fci=, 
return_value_used=) at 
/build/php5-5.6.29+dfsg/Zend/zend_dtrace.c:97
#16 0x007a84d0 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7f5fc166adc8) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:560
#17 0x00736820 in execute_ex (execute_data=0x7f5fc166adc8) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:363
#18 0x006e7988 in dtrace_execute_ex 
(execute_data=0x7f5fc166adc8) at 
/build/php5-5.6.29+dfsg/Zend/zend_dtrace.c:73
#19 0x006e9826 in zend_call_function (fci=0x7ffe8ec46b50, 
fci_cache=0x0, fci_cache@entry=0x7ffe8ec46b20) at 
/build/php5-5.6.29+dfsg/Zend/zend_execute_API.c:831
#20 0x0060f4f3 in zif_call_user_func_array (ht=, 
return_value=0x2722e68, return_value_ptr=, 
this_ptr=, return_value_used=)

at /build/php5-5.6.29+dfsg/ext/standard/basic_functions.c:4790
#21 0x006e7aea in dtrace_execute_internal 
(execute_data_ptr=, fci=, 
return_value_used=) at 
/build/php5-5.6.29+dfsg/Zend/zend_dtrace.c:97
#22 0x007a84d0 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7f5fc166ac80) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:560
#23 0x00736820 in execute_ex (execute_data=0x7f5fc166ac80) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:363
#24 0x006e7988 in dtrace_execute_ex 
(execute_data=0x7f5fc166ac80) at 
/build/php5-5.6.29+dfsg/Zend/zend_dtrace.c:73
#25 0x007a8a13 in zend_do_fcall_common_helper_SPEC 
(execute_data=0x7f5fc166ab20) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:592
#26 0x00736820 in execute_ex (execute_data=0x7f5fc166ab20) at 
/build/php5-5.6.29+dfsg/Zend/zend_vm_execute.h:363
#27 0x006e7988 in dtrace_execute_ex 
(execute_data=0x7f5fc166ab20) at 
/build/php5-5.6.29+dfsg/Zend/zend_dtrace.c:73
#28 0x007a8a13 in ze

Bug#849765: [Reportbug-maint] Bug#849765: reportbug: produces invalid mails when there are long lines

[Adam Borowski]

On Fri, Dec 30, 2016 at 01:48:59PM -0500, Sandro Tosi wrote:
> On Fri, Dec 30, 2016 at 1:41 PM, Adam Borowski  wrote:
> > If the bug report contains an overlong line -- for example, mutt's bug
> > script includes its configure options, 1017 characters long -- reportbug
> > will send that unescaped.
> 
> would you be able to retrieve the saved version of the report (there
> is an output line saying where it is stored, /var/tmp/ IIRC) and
> attach it here? at least i have the exact text that causes the issue

Sure, here you go.  Nothing in /var/tmp but I have an editor backup file --
without my typed part but should be good enough.

> (i'm also not sure if there are limits to the line length in an email,
> but i'll look it up in the SMTP docs)

RFC 821:
# The maximum total length of a text line including the  is 1000
# characters (but not counting the leading dot duplicated for transparency).

Some MTAs are said to have a bit shorter limits, such as 990 bytes.

RFC 2822:
#2.1.1. Line Length Limits
#
#   There are two limits that this standard places on the number of
#   characters in a line. Each line of characters MUST be no more than
#   998 characters, and SHOULD be no more than 78 characters, excluding
#   the CRLF.
#
#   The 998 character limit is due to limitations in many implementations
#   which send, receive, or store Internet Message Format messages that
#   simply cannot handle more than 998 characters on a line. Receiving
#   implementations would do well to handle an arbitrarily large number
#   of characters in a line for robustness sake. However, there are so
#   many implementations which (in compliance with the transport
#   requirements of [RFC2821]) do not accept messages containing more
#   than 1000 character including the CR and LF per line, it is important
#   for implementations not to create such messages.

(1000 including \r\n = 998 excluding them)


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11
Subject: mutt: complains about GPGME
Package: mutt
Version: 1.7.1-5
Severity: normal



-- Package-specific info:
NeoMutt 20161126 (1.7.1)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.9.0+ (x86_64)
libidn: 1.33 (compiled with 1.33)
hcache backends: tokyocabinet

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 6.2.1-5' 
--with-bugurl=file:///usr/share/doc/gcc-6/README.Bugs 
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr 
--program-suffix=-6 --program-prefix=x86_64-linux-gnu- --enable-shared 
--enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext 
--enable-threads=posix --libdir=/usr/lib --enable-nls --with-sysroot=/ 
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk 
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-6-amd64/jre 
--enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-6-amd64 
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-6-amd64 
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar 
--enable-objc-gc=auto --enable-multiarch --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 6.2.1 20161124 (Debian 6.2.1-5) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-notmuch' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-Uun1o_/mutt-1.7.1=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compila

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

[Jason Pyeron]

I have opened https://sourceforge.net/p/logwatch/bugs/56/ .

I am working a test case for this right now.

As I see it, there are 3 paths to test.

Output as STDOUT, file, and email. In each case does an 8bit value (0x00..0xff 
unsigned) result in a valid UTF-8 character.

Is binmode(STDOUT, ":utf8") needed? Does it fix the issue if it was needed?

> > -Original Message-
> > From: Willi Mann
> > Sent: Friday, December 30, 2016 12:18
> > To: logwatch-devel
> > Cc: 849...@bugs.debian.org; 849531-forwar...@bugs.debian.org; Klaus Ethgen
> > What would be your suggested fix?


$ git show f9db5949c58321175bda66310156f43ae607109f
commit f9db5949c58321175bda66310156f43ae607109f
Author: bjorn 
Date:   Sat Oct 15 17:38:40 2016 -0700

Changed encoding to UTF-8, as suggested by Goran Uddeborg.

diff --git a/scripts/logwatch.pl b/scripts/logwatch.pl
index 0f863dc..0167755 100755
--- a/scripts/logwatch.pl
+++ b/scripts/logwatch.pl
@@ -1162,9 +1162,9 @@ sub initprint {
  }
  #Config{output} html
  if ( $Config{'format'} eq "html" ) {
-$out_mime .= "Content-Type: text/html; charset=\"iso-8859-1\"\n\n";
+$out_mime .= "Content-Type: text/html; charset=\"UTF-8\"\n\n";
  } else {
-$out_mime .= "Content-Type: text/plain; 
charset=\"iso-8859-1\"\n\n";
+$out_mime .= "Content-Type: text/plain; charset=\"UTF-8\"\n\n";
  }

  if ($Config{'hostformat'} eq "split") { #8.0 check hostlimit also? or 
ne none?

Bug#849750: Crashes the (LXDE) desktop

[James Cowgill]

Control: reassign libsfml-window2.4 2.4.1+dfsg-1
Control: tags -1 pending

Hi,

On 30/12/16 17:24, Markus Koschany wrote:
> Control: severity -1 serious
> 
> On 30.12.2016 15:27, Julien Puydt wrote:
>> Package: marsshooter
>> Version: 0.7.6-1+b1
>> Severity: critical
>>
>> Hi,
>>
>> I installed the package, clicked on the menu entry and my lxde panel
>> just disappeared. I restarted lxdm and retried : same effect!
>>
>> Restarting lxdm and launching in a terminal, I get :
>>
>> Cannot connect to server socket err = No such file or directory
>> Cannot connect to server request channel
>> jack server is not running or cannot be started
>> JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
>> 4294967295, skipping unlock
>> JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for
>> 4294967295, skipping unlock
>> Searching for configuration file... Found
>> /home/jpuydt/.marsshooter/mars.cfg
>> Searching for data files... Found /usr/share/games/marsshooter/
>> Happy Gaming...
>>
>> (comment: it doesn't find jackd which isn't a problem, but
>>
>> but the game doesn't display anything (it runs though: I have to ctrl+C
>> to get the prompt back), and it looks like both the panel and the window
>> manager are dead : all the running apps' windows turn borderless. I can
>> still launch new apps by clicking on the desktop icons.
>>
>> I didn't know if I should set the severity to grave or critical, but
>> since the game is both not usable and trying to run it breaks something
>> else, I settled for critical.
>>
>> Hope that helps,
> 
> Hello,
> 
> please help us by providing more information about your system next
> time. The reportbug tool is quite convenient for this matter because it
> automatically detects which Debian distribution you run, the
> architecture, and the versions of all installed package dependencies.
> Without those information I can only guess what went wrong. Also please
> always try to confirm or not confirm the bug with other games that use
> the same graphic stack. Very often the underlying issue is in SDL or
> SFML or even lower in the X or driver stack.
> 
> So for the record the game currently works fine on amd64, testing with
> GNOME 3. It doesn't work for me on i386, sid, Openbox, LXDE, Xfce4 and
> Enlightenment. The game just segfaults the moment when the window is
> normally created.
> 
> I am attaching a debug log with the relevant information. I am not sure
> if this is a bug in libsfml-window2.4 or marsshooter itself because I
> can't reproduce it with Extremetuxracer. I only know that the game
> worked fine a couple of months ago when I tried it on i386 and the code
> has not changed.

From the stacktrace, this bug is definitely this one related to the
sf::Window::setIcon function:
https://github.com/SFML/SFML/pull/1171

This would explain why it only crashes with marsshooter -
extremetuxracer doesn't try to change the application icon.

I can also reproduce LXDE crashing (specifically openbox crashes). It
seems to be random which of marsshooter or openbox crashes. GDB says
that openbox crashes in a function related to icons so it's probably
related to the above PR.

I will upload the fix from the above PR and hopefully that will fix both
segfaults here.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#849646: ImportError: No module named lldb.embedded_interpreter

[Sylvestre Ledru]

merge 849646 846612
thanks

Le 29/12/2016 à 14:27, Ole Andreas W. Lyngvaer a écrit :
> Package: lldb
> Version: 1:3.8-34
> Severity: important
>
> clean install lldb doesn't function due to missing python module
> 'lldb.embedded_interpreter'.
dup of 846612
> when given any input, the prompt outputs what looks like unicode
> escapes, but the bits are way off; for example '1' is \U+76931.
See bug #846616
This is caused by a recent change in lldb. I started investigating.

Sylvestre

Bug#849765: [Reportbug-maint] Bug#849765: reportbug: produces invalid mails when there are long lines

[Sandro Tosi]

On Fri, Dec 30, 2016 at 1:41 PM, Adam Borowski  wrote:
> If the bug report contains an overlong line -- for example, mutt's bug
> script includes its configure options, 1017 characters long -- reportbug
> will send that unescaped.

would you be able to retrieve the saved version of the report (there
is an output line saying where it is stored, /var/tmp/ IIRC) and
attach it here? at least i have the exact text that causes the issue
(i'm also not sure if there are limits to the line length in an email,
but i'll look it up in the SMTP docs)

-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
G+: https://plus.google.com/u/0/+SandroTosi

Bug#849765: reportbug: produces invalid mails when there are long lines

[Adam Borowski]

Package: reportbug
Version: 7.1.1
Severity: normal

Hi!
If the bug report contains an overlong line -- for example, mutt's bug
script includes its configure options, 1017 characters long -- reportbug
will send that unescaped.

The mail will then be rejected by certain MTAs, such as exim in Debian's
unmodified configuration.

Exim happens to do so in an extremely unhelpful way: the rejection message
says just:
Action: failed
Final-Recipient: rfc822;sub...@bugs.debian.org
Status: 5.0.0

and the log:
2016-12-30 19:19:55 1cN1mV-0003BB-EP ** sub...@bugs.debian.org R=smarthost 
T=remote_smtp_smarthost: message is too big (transport limit = 1)


Bad error handling by exim aside, reportbug must not send such invalid mails
in the first place.


Meow!
-- Package-specific info:
** Environment settings:
EDITOR="jstar"
EMAIL="kilob...@angband.pl"
INTERFACE="text"

** /home/kilobyte/.reportbugrc:
reportbug_version "3.17"
mode advanced
ui text

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

Kernel: Linux 4.9.0+ (SMP w/6 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages reportbug depends on:
ii  apt1.4~beta2
ii  python3-reportbug  7.1.1
pn  python3:any

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
pn  debconf-utils  
ii  debsums2.1.3
pn  dlocate
pn  emacs23-bin-common | emacs24-bin-common
ii  exim4  4.88-2
ii  exim4-daemon-light [mail-transport-agent]  4.88-2
ii  file   1:5.29-2
ii  gir1.2-gtk-3.0 3.22.5-1
pn  gir1.2-vte-2.91
ii  gnupg  2.1.17-2
ii  python3-gi 3.22.0-2
pn  python3-gtkspellcheck  
ii  python3-urwid  1.3.1-2+b1
ii  xdg-utils  1.1.1-1

-- no debconf information