Bug#832931: (no subject)

[Otto Kekäläinen]

Please also note the related
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852728 and PR at
https://github.com/ottok/mariadb-10.1/pull/8

Bug#852627: lcms2: diff for NMU version 2.8-3.1

[Salvatore Bonaccorso]

Hi Thomas,

On Fri, Jan 27, 2017 at 07:27:43AM +0100, Thomas Weber wrote:
> HI Salvatore,
> On Thu, Jan 26, 2017 at 09:44:49PM +0100, Salvatore Bonaccorso wrote:
> > Control: tags 852627 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for lcms2 (versioned as 2.8-3.1) and
> > uploaded it to DELAYED/2. Please feel free to tell me if I
> > should delay it longer.
> 
> Sorry, I just uploaded 2.8-4 without checking the bug log again (I
> prepard the fix yesterday). So, your NMU will probably never hit
> unstable. I am sorry for the extra work.

No problem! Thanks for the fix to unstable an the unblock request!

Regards,
Salvatore

Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Jens Lechtenboerger]

On 2017-01-26, at 18:13, Daniel Kahn Gillmor wrote:

> On Thu 2017-01-26 13:36:09 -0500, Jens Lechtenboerger wrote:

>> That’s customized in mml-secure-key-preferences.  So, the usual
>> customize interface is available.  And there is some code to detect
>> and remove unusable customizations.
>
> When was this introduced?  i don't see it, but then i'm still using
> emacs24.  Do i need to upgrade?

I introduced that about a year ago, when Gnus was still developed in
its own repository.  I don’t know anything about Gnus releases since
then.

The doc string reports those changes as of version 25.1 of Emacs.

Best wishes
Jens

Bug#852728: [debian-mysql] Bug#852728: FTBFS on non-Linux architectures

[Otto Kekäläinen]

The apply errors where:

$ git apply 0001-Fix-FTBFS-on-non-Linux-architectures.patch
0001-Fix-FTBFS-on-non-Linux-architectures.patch:18: trailing whitespace.
#!/usr/bin/dh-exec
0001-Fix-FTBFS-on-non-Linux-architectures.patch:27: trailing whitespace.
[linux-any] 
lib/systemd/system/mariadb@bootstrap.service.d/use_galera_new_cluster.conf
0001-Fix-FTBFS-on-non-Linux-architectures.patch:36: trailing whitespace.
[linux-any] usr/bin/galera_new_cluster
0001-Fix-FTBFS-on-non-Linux-architectures.patch:37: trailing whitespace.
[linux-any] usr/bin/galera_recovery
0001-Fix-FTBFS-on-non-Linux-architectures.patch:38: trailing whitespace.
[linux-any] usr/bin/mariadb-service-convert
error: patch failed: debian/mariadb-server-10.1.install:1
error: debian/mariadb-server-10.1.install: patch does not apply
error: patch failed: debian/rules:14
error: debian/rules: patch does not apply

However, today I tried
$ git am 0001-Fix-FTBFS-on-non-Linux-architectures.patch
Applying: Fix FTBFS on non-Linux architectures

..and it worked perfectly. I could have used that yesterday and then
just amended the bug # to the commit afterwards... I can see that
you've now sent the other patches as Github PRs. That should help rule
out any further manual typo errors I might make.

Bug#852627: lcms2: diff for NMU version 2.8-3.1

[Thomas Weber]

On Fri, Jan 27, 2017 at 07:27:43AM +0100, Thomas Weber wrote:
> HI Salvatore,
> On Thu, Jan 26, 2017 at 09:44:49PM +0100, Salvatore Bonaccorso wrote:
> > Control: tags 852627 + pending
> > 
> > Dear maintainer,
> > 
> > I've prepared an NMU for lcms2 (versioned as 2.8-3.1) and
> > uploaded it to DELAYED/2. Please feel free to tell me if I
> > should delay it longer.
> 
> Sorry, I just uploaded 2.8-4 without checking the bug log again (I
> prepard the fix yesterday). So, your NMU will probably never hit
> unstable. I am sorry for the extra work.

Unblock request is https://bugs.debian.org/852770

Thomas

Bug#852770: unblock: lcms2/2.8-4

[Thomas Weber]

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

Please unblock package lcms2

The new package fixes a grave security bug (#852627), which was
submitted just two days ago. Debdiff with one-line change attached.

unblock lcms2/2.8-4

Thanks
Thomas

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru lcms2-2.8/debian/changelog lcms2-2.8/debian/changelog
--- lcms2-2.8/debian/changelog	2016-12-18 23:24:18.0 +0100
+++ lcms2-2.8/debian/changelog	2017-01-26 11:04:13.0 +0100
@@ -1,3 +1,11 @@
+lcms2 (2.8-4) unstable; urgency=medium
+
+  * New patch: debian/patches/fix-CVE-2016-10165.patch.
+Fix for CVE-2016-10165. (Closes: #852627)
+Thanks to Salvatore Bonaccorso  
+
+ -- Thomas Weber   Thu, 26 Jan 2017 11:04:13 +0100
+
 lcms2 (2.8-3) unstable; urgency=medium
 
   * New patch: lcms2-fix-strFrom16-byte-order.patch.
diff -Nru lcms2-2.8/debian/patches/fix-CVE-2016-10165.patch lcms2-2.8/debian/patches/fix-CVE-2016-10165.patch
--- lcms2-2.8/debian/patches/fix-CVE-2016-10165.patch	1970-01-01 01:00:00.0 +0100
+++ lcms2-2.8/debian/patches/fix-CVE-2016-10165.patch	2017-01-26 11:04:13.0 +0100
@@ -0,0 +1,17 @@
+Description: Fix for CVE-2016-10165
+ Fixes an out-of-bounds read in Type_MLU_Read()
+Origin: https://github.com/mm2/Little-CMS/commit/5ca71a7bc18b6897ab21d815d15e218e204581e2
+Author: Marti 
+Applied-upstream: https://github.com/mm2/Little-CMS/commit/5ca71a7bc18b6897ab21d815d15e218e204581e2
+Forwarded: not-needed
+Bug-Debian: https://bugs.debian.org/852627
+--- a/src/cmstypes.c
 b/src/cmstypes.c
+@@ -1460,6 +1460,7 @@
+ 
+ // Check for overflow
+ if (Offset < (SizeOfHeader + 8)) goto Error;
++if ((Offset + Len) > SizeOfTag + 8) goto Error;
+ 
+ // True begin of the string
+ BeginOfThisString = Offset - SizeOfHeader - 8;
diff -Nru lcms2-2.8/debian/patches/series lcms2-2.8/debian/patches/series
--- lcms2-2.8/debian/patches/series	2016-12-18 23:24:18.0 +0100
+++ lcms2-2.8/debian/patches/series	2017-01-26 11:04:13.0 +0100
@@ -1,3 +1,4 @@
 prepare-for-libtoolizing.patch
 dont-write-uninitialized-memory-for-color-strings.patch
 lcms2-fix-strFrom16-byte-order.patch
+fix-CVE-2016-10165.patch

Bug#852627: lcms2: diff for NMU version 2.8-3.1

[Thomas Weber]

HI Salvatore,
On Thu, Jan 26, 2017 at 09:44:49PM +0100, Salvatore Bonaccorso wrote:
> Control: tags 852627 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for lcms2 (versioned as 2.8-3.1) and
> uploaded it to DELAYED/2. Please feel free to tell me if I
> should delay it longer.

Sorry, I just uploaded 2.8-4 without checking the bug log again (I
prepard the fix yesterday). So, your NMU will probably never hit
unstable. I am sorry for the extra work.

Thomas

Bug#852769: ITP: node-timed-out -- Emit `ETIMEDOUT` or `ESOCKETTIMEDOUT` when ClientRequest is hanged

[Tushar Agey]

Package: wnpp
Severity: wishlist
Owner: Tushar Agey 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-timed-out
  Version : 4.0.1
  Upstream Author : Vsevolod Strukchinsky 
* URL : https://github.com/floatdrop/timed-out#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Emit `ETIMEDOUT` or `ESOCKETTIMEDOUT` when
ClientRequest is hanged

 This script helps to add custom timeout for HTTP/HTTPS request
 The timed-out script needs a `request URL` and `time in milliseconds`,
 which allows you to set timeout for the HTTPS/HTTPS request
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#828154: RFP: spacemacs -- Emacs configuration to get best of Emacs and Vim

[Lev Lamberov]

27.01.2017 04:24, Sean Whitton пишет:
> On Fri, Jan 27, 2017 at 01:10:51AM +0500, Lev Lamberov wrote:
>> With up-to-date Spacemacs source it produces a list of 558 packages.
>> Please, find the output attached. So, it is ready to put to the team's
>> wiki. ;-)
> 
> Done!

Cool! Thank you! Probably at some point we will need a script to mark
packages already in Debian as DONE. Otherwise task of selecting package
from that table to prepare Debian package will be time-consuming.

Cheers!
Lev



signature.asc
Description: OpenPGP digital signature

Bug#852768: ocrad FTCBFS: uses the build architecture C++ compiler

[Helmut Grohne]

Source: ocrad
Version: 0.25-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ocrad fails to cross build from source, because it uses the build
architecture C++ compiler. Simply passing a triplet-prefixed CXX
variable to configure makes the cross build succeed. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru ocrad-0.25/debian/changelog ocrad-0.25/debian/changelog
--- ocrad-0.25/debian/changelog 2017-01-17 18:36:35.0 +0100
+++ ocrad-0.25/debian/changelog 2017-01-27 07:16:16.0 +0100
@@ -1,3 +1,10 @@
+ocrad (0.25-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Pass triplet-prefixed CXX to configure (Closes: #-1).
+
+ -- Helmut Grohne   Fri, 27 Jan 2017 07:16:16 +0100
+
 ocrad (0.25-2) unstable; urgency=medium
 
   * QA upload.
diff --minimal -Nru ocrad-0.25/debian/rules ocrad-0.25/debian/rules
--- ocrad-0.25/debian/rules 2016-07-12 11:52:24.0 +0200
+++ ocrad-0.25/debian/rules 2017-01-27 07:16:15.0 +0100
@@ -4,7 +4,11 @@
 CPPFLAGS = -W -Wall $(shell dpkg-buildflags --get CPPFLAGS) 
-D_FILE_OFFSET_BITS=64
 LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
 
+DEB_HOST_GNU_TYPE ?= $(shell dpkg-architectur -qDEB_HOST_GNU_TYPE)
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+ifeq ($(origin CXX),default)
+CXX = $(DEB_HOST_GNU_TYPE)-g++
+endif
 
 .PHONY: build build-indep build-arch
 build: build-indep build-arch
@@ -23,6 +27,7 @@
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--mandir=\$${prefix}/share/man \
--infodir=\$${prefix}/share/info \
+   CXX="$(CXX)" \
CXXFLAGS="$(CXXFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
LDFLAGS="$(LDFLAGS)"
touch $(@)
 

Bug#852767: wordpress: 4.7.2 security release

[Salvatore Bonaccorso]

Source: wordpress
Version: 4.7.1+dfsg-1
Severity: grave
Tags: security upstream fixed-upstream

Hi

A new wordpress release was announced, marked as security release.

Cf. http://www.openwall.com/lists/oss-security/2017/01/27/2 for the
CVE request for the three issues.

Regards,
Salvatore

Bug#852766: tcpflow FTCBFS: configures for the build architecture

[Helmut Grohne]

Source: tcpflow
Version: 1.4.5+repack1-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

tcpflow fails to cross build from source, because it doesn't pass --host
to ./configure. By replacing the explicit ./configure invocations with
dh_auto_configure, this happens automatically and a lot of noise goes
away from debian/rules. After doing it, tcpflow cross builds
successfully. Please consider applying the attached patch.

Helmut
diff --minimal -Nru tcpflow-1.4.5+repack1/debian/changelog 
tcpflow-1.4.5+repack1/debian/changelog
--- tcpflow-1.4.5+repack1/debian/changelog  2016-10-28 20:49:16.0 
+0200
+++ tcpflow-1.4.5+repack1/debian/changelog  2017-01-27 07:05:48.0 
+0100
@@ -1,3 +1,10 @@
+tcpflow (1.4.5+repack1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCFBS: Let dh_auto_configure pass cross compilers (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 27 Jan 2017 07:05:48 +0100
+
 tcpflow (1.4.5+repack1-3) unstable; urgency=medium
 
   * Bug fix: "FTBFS with openssl 1.1.0", thanks to Kurt Roeckx (Closes:
diff --minimal -Nru tcpflow-1.4.5+repack1/debian/rules 
tcpflow-1.4.5+repack1/debian/rules
--- tcpflow-1.4.5+repack1/debian/rules  2016-07-17 21:24:33.0 +0200
+++ tcpflow-1.4.5+repack1/debian/rules  2017-01-27 07:05:45.0 +0100
@@ -3,32 +3,14 @@
 %:
dh $@
 
-export DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
-export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
-
 BUILDDIR := $(CURDIR)/debian/build
 BUILDDIR_NOX := $(CURDIR)/debian/build-nox
 
-conf_opts :=   \
-   --build=$(DEB_BUILD_GNU_TYPE)   \
-   --prefix=/usr   \
-   --includedir=/usr/include   \
-   --mandir=/usr/share/man \
-   --infodir=/usr/share/info   \
-   --sysconfdir=/etc   \
-   --localstatedir=/var\
-   --libdir=/usr/lib/$(DEB_HOST_GNU_TYPE)  \
-   --libexecdir=/usr/lib/$(DEB_HOST_GNU_TYPE)  \
-   --disable-maintainer-mode   \
-   --disable-dependency-tracking
-
-
 override_dh_auto_configure:
autoreconf -f -i
-   mkdir -p $(BUILDDIR)
-   cd $(BUILDDIR); ../../configure $(conf_opts)
-   mkdir -p $(BUILDDIR_NOX)
-   cd $(BUILDDIR_NOX);  ./../../configure $(conf_opts) --enable-cairo=false
+   dh_auto_configure --builddirectory=$(BUILDDIR)
+   dh_auto_configure --builddirectory=$(BUILDDIR_NOX) -- \
+   --enable-cairo=false
 
 override_dh_auto_build:
dh_auto_build -a -- -C $(BUILDDIR_NOX)/src

Bug#852749: Aw: Re: Bug#852749: linux-image-4.9.0-1-amd64: usb-audio-device not working since kernel 4.9.0.1

[el_murruk]

 Thanks!

i will test these patches this weekend and report any success/failure.

Marc


- Original Nachricht 
Von: Ben Hutchings 
An:  Marc Neudorfer , 852...@bugs.debian.org
Datum:   27.01.2017 01:56
Betreff: Re: Bug#852749: linux-image-4.9.0-1-amd64: usb-audio-device not
 working since kernel 4.9.0.1

> Control: tag -1 patch moreinfo
> 
> Please test whether the attached patches fix this.  You can find
> instructions for rebuilding the kernel package at:
> https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-offi
> cial
> 
> Ben.
> 
> -- 
> Ben Hutchings
> Design a system any fool can use, and only a fool will want to use it.
> 

Bug#852765: playonlinux: Nothing happens when I press the run button

[Tom Epperly]

Package: playonlinux
Version: 4.2.10-2
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***
I recently did a "apt-get dist-upgrade" on my system.  I use
PlayOnLinux to run League of Legends.

If I invoke playonlinux, select "League of Legends" from the list of
applications, and then click the run button, there is no evidence that
a process is starting up. Normally, there is output in the terminal
window as LOL starts up. I've also tried running Steam (the Windows
version) via PlayOnLinux, and it also shows no signs of starting up.

The outcome I expected was text in the terminal indicating that it's
trying to start up LOL or steam via Wine.

I've also watched the active processes via "top", and there is no sign
of wine processes launching.

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


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

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

Versions of packages playonlinux depends on:
ii  binutils  2.27.90.20170124-1
ii  bzip2 1.0.6-8+b1
ii  cabextract1.6-1
ii  curl  7.52.1-1
ii  eterm [x-terminal-emulator]   0.9.6-4
ii  gettext-base  0.19.8.1-2
ii  gnome-terminal [x-terminal-emulator]  3.22.1-1
ii  gnupg 2.1.18-3
ii  icoutils  0.31.1-1
ii  imagemagick   8:6.9.7.4+dfsg-1
ii  imagemagick-6.q16 [imagemagick]   8:6.9.7.4+dfsg-1
ii  konsole [x-terminal-emulator] 4:16.12.0-1
ii  lxterminal [x-terminal-emulator]  0.3.0-1
ii  mesa-utils8.3.0-3
ii  netcat1.10-41
ii  netcat-openbsd [netcat]   1.130-2
ii  netcat-traditional [netcat]   1.10-41
ii  p7zip-full16.02+dfsg-2
ii  python-wxgtk3.0   3.0.2.0+dfsg-3
pn  python:any
ii  unzip 6.0-21
ii  wget  1.18-4
ii  wine  1.8.6-3
ii  x11-utils 7.7+3
ii  xterm [x-terminal-emulator]   327-2

playonlinux recommends no packages.

Versions of packages playonlinux suggests:
ii  scrot  0.8-18
ii  ttf-mscorefonts-installer  3.6

-- no debconf information

Bug#847656: weston: Weston > 1.9 all have reproducable crash with browser in xwayland with Ivy Bridge class gpu

[Kelly Clowers]

On Sun, Dec 11, 2016 at 8:36 AM, Emilio Pozuelo Monfort
 wrote:
>
> On 11/12/16 11:28, Kelly Clowers wrote:
>> Done, https://bugs.freedesktop.org/show_bug.cgi?id=99050
>
> Thanks.
>
> Emilio

Looks like that bug is  likely
https://bugs.freedesktop.org/show_bug.cgi?id=94218 which now has a
patch.
Looking at dates, it should be in Weston 2.0. That is in alpha now,
don't know if that can make it into next Stable, or if it needs to be
applied to 1.12

Thanks,
Kelly

Bug#849493: RFS: vc/1.3.0-1 [ITP]

[Boyuan Yang]

Hi all,

This is the owner of RFP bug for vc package (#846491) and let's push
the process forward a little bit.

On Sun, 1 Jan 2017 21:10:49 +0100, Andreas Henriksson wrote:
> In Debian we have one shared namespace for all packages (and
> potential binaries, etc.). Shorter names often leads to
> collisions in the namespace.
> I don't see any other package currently named "vc" but still
> staying away from any 2letter name [...]
> [...]

I think the name "vc" and binary name "vc-dev" should be acceptable.
The reason is that "vc" is highly unlikely to be used by other packages
because *Ubuntu* named this package as "vc" and "vc-dev".
See http://packages.ubuntu.com/zesty/vc-dev.

That said, we should get into contact with upstream author if we really
want an alternative name.

Note that "libvc" cannot be used because we already have "libvc" and
"libvc-dev".

--
Sincerely,
Boyuan Yang

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

Bug#852763: boost1.63: outdated embedded data copy: unicode-data

[Paul Wise]

Source: boost1.63
Severity: normal
Usertags: embed built-using

Unicode 9.0 was semi-recently released and unicode-data 9.0-1 was uploaded.

The boost1.63 source package contains embedded data copies of several
files from the unicode-data package:

boost/spirit/home/support/char_encoding/unicode/UnicodeData.txt
boost/spirit/home/support/char_encoding/unicode/Scripts.txt
boost/spirit/home/support/char_encoding/unicode/PropList.txt
boost/spirit/home/support/char_encoding/unicode/DerivedCoreProperties.txt

Upstream appears to have converted those files into these files before
releasing the tarball. One of those files (query.hpp) is generated by a
python script that is not available in the source package, I think this
is therefore a severity serious bug but I'm not sure.

boost/spirit/home/support/char_encoding/unicode/query.hpp
boost/spirit/home/support/char_encoding/unicode/uppercase_table.hpp
boost/spirit/home/support/char_encoding/unicode/category_table.hpp
boost/spirit/home/support/char_encoding/unicode/script_table.hpp
boost/spirit/home/support/char_encoding/unicode/lowercase_table.hpp

These files are then shipped in the libboost1.63-dev binary package.

Please ask upstream to remove the above files from the source package
and instead build-depend on the unicode-data binary package, convert the
relevant files to headers at build time and add a Built-Using header:

https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#852764: boost1.62: outdated embedded data copy: unicode-data

[Paul Wise]

Source: boost1.62
Severity: normal
Usertags: embed built-using

Unicode 9.0 was semi-recently released and unicode-data 9.0-1 was uploaded.

The boost1.62 source package contains embedded data copies of several
files from the unicode-data package:

boost/spirit/home/support/char_encoding/unicode/UnicodeData.txt
boost/spirit/home/support/char_encoding/unicode/Scripts.txt
boost/spirit/home/support/char_encoding/unicode/PropList.txt
boost/spirit/home/support/char_encoding/unicode/DerivedCoreProperties.txt

Upstream appears to have converted those files into these files before
releasing the tarball. One of those files (query.hpp) is generated by a
python script that is not available in the source package, I think this
is therefore a severity serious bug but I'm not sure.

boost/spirit/home/support/char_encoding/unicode/query.hpp
boost/spirit/home/support/char_encoding/unicode/uppercase_table.hpp
boost/spirit/home/support/char_encoding/unicode/category_table.hpp
boost/spirit/home/support/char_encoding/unicode/script_table.hpp
boost/spirit/home/support/char_encoding/unicode/lowercase_table.hpp

These files are then shipped in the libboost1.62-dev binary package.

Please ask upstream to remove the above files from the source package
and instead build-depend on the unicode-data binary package, convert the
relevant files to headers at build time and add a Built-Using header:

https://www.debian.org/doc/debian-policy/ch-relationships.html#s-built-using

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#852762: ITP: node-cli-spinners -- Spinners for use in the terminal

[Tushar Agey]

Package: wnpp
Severity: wishlist
Owner: Tushar Agey 
X-Debbugs-CC: debian-de...@lists.debian.org

* Package name: node-cli-spinners
  Version : 1.0.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com)
* URL : https://github.com/sindresorhus/cli-spinners#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Spinners for use in the terminal

 This script can generate various interesting spinners
 to use in terminal. Spinners are various graphical small
 objects like arrows, right check,
 wrong cross, dots, etc
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#852761: ITP: deft -- Emacs mode for browsing, filtering and editing plain text notes

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: deft
  Version : 0.7
  Upstream Author : Jason R. Blevins 
* URL : http://jblevins.org/projects/deft/
* License : BSD-3-clause
  Programming Lang: Emacs Lisp
  Description : Emacs mode for browsing, filtering and editing plain text 
notes

I intend to maintain this as part of the pkg-emacsen team.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#852760: Input methods have no effect under LXDE

[laalaa]

Package: ibus
Version: jessie rc1

Dear Maintainer,

   * What led up to the situation?
Select Cangjie3 / Quick3 input method but has no effect, keyboard keys 
pressed are passing through directly to applications Leafpad / Firefox.

   * What exactly did you do (or not do) that was effective (or ineffective)?
Source:
netinst iso-cd weekly built on 2017-01-23, downloaded from debian 
website
System:
Debian Jessie running qemu-kvm 1:2.1+dfsg-12+deb8u6
KVM hardware:
1 x IDE CDROM (debian-testing netinst iso-cd)
1 x 8GB virtio disk (vda)
1 x virtio network adapter
QXL display
Key steps to get error:
1. Clean install the system, with task select "LXDE desktop", "SSH 
Server", "System Tools" only
2. Install ibus as root: apt-get install ibus ibus-table-cangjie3 
ibus-table-quick3 fonts-arphic-ukai fonts-arphic-uming
3. Reboot system
4. Login LXDE as normal user
5. Open LXDE desktop menu bar --> Preferences --> iBus Preferences
6. Activate Cangjie3 and Quick3 input method, Set "Shift-Space" as 
hotkey, "Show Property Panel" to "Always"
7. Reboot system
8. Login LXDE as the same user
9. Open Leafpad, switch input method to Cangjie3 by hotkey "Shift-Space"
10. Type alphabet keys (e.g. "mmm")

   * What was the outcome of this action?
"mmm" show on Leafpad

   * What outcome did you expect instead?
"?" ("three" show on Leafpad)

-- System Information:
Debian Release: stretch/sid
Architecture: amd64

Bug#852505: linux-image-4.8.0-2-amd64: Realtek Ethernet controller vanishes on reboot

[Ben Hutchings]

Control: tag -1 moreinfo

On Wed, 2017-01-25 at 00:00 +0100, Andrea Zuccherelli wrote:
> Package: src:linux
> Version: 4.8.15-2
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> The Ethernet controller RTL8105e in my Toshiba C660 notebook had a very 
> strange behaviour.
> It worked once but not after, being not even seen by BIOS for LAN boot on 
> next reboot.
> A hardware issue?

It sounds like it.  But all hardware has bugs, and drivers should work
around those bugs if possible.

[...]
> Searching for a solution I found that only a PCI reset, after unloading the 
> driver could help:
> 
> root@zbox:~# echo 1 >/sys/bus/pci/devices/:01:00.0/reset
> 
> So I added this to my "post-down" interface configuration.
> 
> Obviously this is just a workaround: so what is happening here?
> Is my hardware not resetting the PCI bus on an ACPI poweroff event?
> Should the kernel or driver do it?
> Where is the best place to force a device PCI reset so that no problem could 
> arise on hibernate/suspend?

In the driver. :-)

But first, please test without these kernel parameters:

pcie_aspm=force "acpi_osi=Windows 2009" "acpi_os_name=Windows 2009"

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



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

Bug#852556: linux-image-4.9.0-1-amd64: [Regression] Trendnet's TU-ET100C Pegasus II based LAN to USB adapter stopped to work

[Ben Hutchings]

Control: tag -1 patch moreinfo

Please test whether the attached patch fixes this.  You can find
instructions for rebuilding the kernel package at:
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.

From: Ben Hutchings 
Date: Fri, 27 Jan 2017 02:44:26 +
Subject: pegasus: Use heap buffers for all register access
Bug-Debian: https://bugs.debian.org/852556

Allocating USB buffers on the stack is not portable, and no longer
works on x86_64 (with VMAP_STACK enabled as per default).

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Ben Hutchings 
---
 drivers/net/usb/pegasus.c | 29 +
 1 file changed, 25 insertions(+), 4 deletions(-)

diff --git a/drivers/net/usb/pegasus.c b/drivers/net/usb/pegasus.c
index 24e803fe9a53..36674484c6fb 100644
--- a/drivers/net/usb/pegasus.c
+++ b/drivers/net/usb/pegasus.c
@@ -126,40 +126,61 @@ static void async_ctrl_callback(struct urb *urb)
 
 static int get_registers(pegasus_t *pegasus, __u16 indx, __u16 size, void *data)
 {
+	u8 *buf;
 	int ret;
 
+	buf = kmalloc(size, GFP_NOIO);
+	if (!buf)
+		return -ENOMEM;
+
 	ret = usb_control_msg(pegasus->usb, usb_rcvctrlpipe(pegasus->usb, 0),
 			  PEGASUS_REQ_GET_REGS, PEGASUS_REQT_READ, 0,
-			  indx, data, size, 1000);
+			  indx, buf, size, 1000);
 	if (ret < 0)
 		netif_dbg(pegasus, drv, pegasus->net,
 			  "%s returned %d\n", __func__, ret);
+	else if (ret <= size)
+		memcpy(data, buf, ret);
+	kfree(buf);
 	return ret;
 }
 
-static int set_registers(pegasus_t *pegasus, __u16 indx, __u16 size, void *data)
+static int set_registers(pegasus_t *pegasus, __u16 indx, __u16 size,
+			 const void *data)
 {
+	u8 *buf;
 	int ret;
 
+	buf = kmemdup(data, size, GFP_NOIO);
+	if (!buf)
+		return -ENOMEM;
+
 	ret = usb_control_msg(pegasus->usb, usb_sndctrlpipe(pegasus->usb, 0),
 			  PEGASUS_REQ_SET_REGS, PEGASUS_REQT_WRITE, 0,
-			  indx, data, size, 100);
+			  indx, buf, size, 100);
 	if (ret < 0)
 		netif_dbg(pegasus, drv, pegasus->net,
 			  "%s returned %d\n", __func__, ret);
+	kfree(buf);
 	return ret;
 }
 
 static int set_register(pegasus_t *pegasus, __u16 indx, __u8 data)
 {
+	u8 *buf;
 	int ret;
 
+	buf = kmemdup(, 1, GFP_NOIO);
+	if (!buf)
+		return -ENOMEM;
+
 	ret = usb_control_msg(pegasus->usb, usb_sndctrlpipe(pegasus->usb, 0),
 			  PEGASUS_REQ_SET_REG, PEGASUS_REQT_WRITE, data,
-			  indx, , 1, 1000);
+			  indx, buf, 1, 1000);
 	if (ret < 0)
 		netif_dbg(pegasus, drv, pegasus->net,
 			  "%s returned %d\n", __func__, ret);
+	kfree(buf);
 	return ret;
 }
 


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

Bug#852759: ITP: wc-mode -- display a word count in the Emacs modeline

[Sean Whitton]

Package: wnpp
Severity: wishlist
Owner: Sean Whitton 

* Package name: wc-mode
  Version : 1.3
  Upstream Author : Benjamin Beckwith
* URL : https://github.com/bnbeckwith/wc-mode
* License : GPL-3+
  Programming Lang: Emacs Lisp
  Description : display a word count in the Emacs modeline

I intend to maintain this as part of pkg-emacsen.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#852721: tunnelx: Non-ASCII character corruption

[Wookey]

On 2017-01-26 12:40 +, Toby Speight wrote:
> Package: tunnelx
> Version: 20160713-3
> Severity: normal
> Tags: patch
> 
> Characters outside US-ASCII get corrupted when saving and loading
> tunnel sketches.  The reason is that each char is simply cast to byte
> when saving, and sign-extended to char when loading.  I've made a patch
> which writes and reads XML numeric character references for characters
> not in US-ASCII as declared in the XML declaration.  I tested with my
> current survey which contains Gaelic names, and hand-edited the XML to
> ensure that reading hexadecimal representations works (we always write
> decimal).  The patch is probably suitable for forwarding upstream.
> 
> Perhaps an alternative approach might be considered - open the output
> file with UTF-8 encoding, and change the XML declaration to reflect
> that.

bugs - with patches - lovely!

Cheers for that. You missed debian stable deadline by about 1 day, and
debian is frozen for the time being, so I won't do an upload right
now, but will forward to Julian.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Bug#852758: procps: pkill returns success on failure due to operation not permitted

[Adrian Riordan]

Package: procps 
Version: 2:3.3.9-9
Severity: normal

Dear Maintainer,

When trying kill a process with insufficient privileges (see blow), pkill 
displays the error message “... failed: Operation not permitted”, but returns 
0. Surely it should return 3?

$ pkill syslogd ; echo $?
pkill: killing pid 373 failed: Operation not permitted
0

-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 8.0 (jessie)
Release:8.0
Codename:   jessie
Architecture: armv7l

Kernel: Linux 4.4.38-v7+ (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 procps depends on:
ii  initscripts   2.88dsf-59
ii  libc6 2.19-18+deb8u6
ii  libncurses5   5.9+20140913-1
ii  libncursesw5  5.9+20140913-1
ii  libprocps32:3.3.9-9
ii  libtinfo5 5.9+20140913-1
ii  lsb-base  4.1+Debian13+rpi1+nmu1

Versions of packages procps recommends:
ii  psmisc  22.21-2

procps suggests no packages.

-- no debconf information

Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daiki Ueno]

Daniel Kahn Gillmor  writes:

> On Thu 2017-01-26 14:34:22 -0500, Daiki Ueno wrote:
>> Jens Lechtenboerger  writes:
>>> The mml code is based on EasyPG by Daiki Ueno (cc’ed).  EasyPG makes
>>> use of sub-keys and their IDs for encryption commands, instead of
>>> relying on GnuPG’s selections.
>>
>> It was suggested by Werner to do key selection in Emacs, like GPGME.  I
>> don't know whether GPGME changed the logic though.
>
> I don't know what this means -- i don't think that GPGME itself does key
> selection.  Can you tell me more?

My wording might be confusing; let me rephase: I don't think GPGME has a
means of using GnuPG's selections, which the applications can rely on.

EasyPG is modelled after GPGME, and Gnus is an application using it,
thus it is a responsiblity of Gnus to select usable keys by itself.

> Presumably users who use emacs with gpg also use gpg with other tools
> (possibly even other MUAs), or even gpg on its own. Collecting key
> preference data in multiple places while sharing the underlying key
> store seems like a recipe for synchronization problems and confusing
> behavior, particularly for folks who don't know how the tools fit
> together.

If there is the means to do that in GPGME now, yes, it would be nice for
EasyPG to provide a similar mechanism which can be used from Gnus.
Otherwise, IMO, neither EasyPG nor Gnus should try to do the selection
by calling gpg directly, even if it could be useful.

Regards,
-- 
Daiki Ueno

Bug#828814: grafana: FTBFS: sqlstore/sqlstore.go:96: cannot assign to x.Logger

[Haruki TSURUMOTO]

Hi,

IMO, This FTBFS comes from golang-github-go-xorm-xorm-dev package's
imcompatible changes.
According to the upstream release
page(https://github.com/go-xorm/xorm/releases), version 0.5.0 of xorm
changed logging interface.
v0.5.3 is packaged into unstable at June 2016.

Anyone know how to solve this?

Regards,

-- 
Haruki TSURUMOTO
PGP Fingerprint:3718 C84E 4EDA 1B5C 4F26 8639 9D3D EE3F 63A6 000E

Bug#852321: timidity: fails to start after installation

[Adam Borowski]

> > /etc/timidity/freepats.cfg: No such file or directory
> > timidity: Error reading configuration file.
> > Please check /etc/timidity/timidity.cfg
>
> Installing freepats fixes this.
>
> Now, as freepats is in Recommends and probably does not need to
> be moved to Depends, I’ve got a suggestion for a fix:
>
> Preferably: change /etc/timidity/timidity.cfg so that
> /etc/timidity/freepats.cfg is only read/used if it exists.
>
> Otherwise: In the package postinst, if /etc/timidity/freepats.cfg
> does not exist, echo a warning (“install freepats or change
> /etc/timidity/timidity.cfg to not refer to it”).

I'd recommend against Recommending or even Suggesting freepats, that patch
set is of terrible quality, and on a typical .mid file lacks ⅓ to ½
instruments.

In the words of freepats' maintainer:
# However, if fluid is working well, wouldn't it make more sense to outright
# remove freepats from the archive?
#
# Can you give me your impression about freepats and fluid?  Is there any
# situation where one should prefer freepats over fluid?
#
# Because if there isn't one, I think we should remove freepats.

Besides fluid, there's also timgm6mb-soundfont.


Thus, to fix this bug, I'd recommend making the config try to include any of
the four soundfont packages, silently ignoring missing ones, complaining
only if _none_ (including any third-party sets installed by the user) was
loaded.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Tom Lee]

Alrighty, having read through the other responses I'm inclined to agree
something's not playing nice with certain hardware:

I think that the difference is more likely to be in the configuration,
> rather than the patches we apply.
>
> As in the kernel config? I guess that's possible. I think I built my
"good" vanilla 4.9 kernel using the debian 4.6 config. Perhaps in addition
the booting-from-power-off, maybe worth my time to try another vanilla 4.9
build using the debian 4.9 config to see if things get miserable again.


On Thu, Jan 26, 2017 at 6:10 PM, Tom Lee  wrote:

> Oops, somehow missed those follow-ups. Thanks, I'll catch up.
>
> Have you tried booting one of the newer kernel versions from power-off?
>
>
> I'll be sure to give that a go, thanks.
>
>
> On Thu, Jan 26, 2017 at 5:54 PM, Ben Hutchings 
> wrote:
>
>> On Wed, 2017-01-25 at 17:52 -0800, Tom Lee wrote:
>> > Just an update: I am still encountering similar performance issues with
>> the
>> > 4.9.0-1 kernel that was recently promoted to testing. In fact, the
>> 4.9.0-1
>> > kernel may be the worst yet in terms of this specific issue, with
>> IntelliJ
>> > starting so slowly as to be effectively unusable. One time the entire
>> > system appeared to become completely unresponsive & a hard reset was
>> > required.
>> >
>> > The most recent kernel with which I've experienced problems:
>> >
>> > $ apt-cache show linux-image-4.9.0-1-amd64
>> > Package: linux-image-4.9.0-1-amd64
>> > Source: linux-signed (4)
>> > Version: 4.9.2-2
>> > Installed-Size: 183299
>> >
>> > This problem does *not* seem to occur with a vanilla 4.9.2 kernel,
>> implying
>> > something Debian-specific:
>> >
>> > $ uname -a
>> > Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
>> > GNU/Linux
>> >
>> > If you're aware of any Debian patches that might be suspect, I'm happy
>> to
>> > try some custom builds. Reproducing the issue is trivial on my end when
>> a
>> > kernel is "bad".
>> [...]
>>
>> I think that the difference is more likely to be in the configuration,
>> rather than the patches we apply.
>>
>> Some other people followed up to your bug report suggesting there might
>> be a BIOS bug affecting behaviour after a warm reboot, but not booting
>> from power-off:
>>
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#17
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#32
>>
>> (Unfortunately I don't see any BIOS updates available for this model.)
>> Have you tried booting one of the newer kernel versions from power-off?
>>
>> Ben.
>>
>> --
>> Ben Hutchings
>> Design a system any fool can use, and only a fool will want to use it.
>>
>
>
>
> --
> *Tom Lee */ http://tomlee.co / @tglee 
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Tom Lee]

Oops, somehow missed those follow-ups. Thanks, I'll catch up.

Have you tried booting one of the newer kernel versions from power-off?


I'll be sure to give that a go, thanks.


On Thu, Jan 26, 2017 at 5:54 PM, Ben Hutchings  wrote:

> On Wed, 2017-01-25 at 17:52 -0800, Tom Lee wrote:
> > Just an update: I am still encountering similar performance issues with
> the
> > 4.9.0-1 kernel that was recently promoted to testing. In fact, the
> 4.9.0-1
> > kernel may be the worst yet in terms of this specific issue, with
> IntelliJ
> > starting so slowly as to be effectively unusable. One time the entire
> > system appeared to become completely unresponsive & a hard reset was
> > required.
> >
> > The most recent kernel with which I've experienced problems:
> >
> > $ apt-cache show linux-image-4.9.0-1-amd64
> > Package: linux-image-4.9.0-1-amd64
> > Source: linux-signed (4)
> > Version: 4.9.2-2
> > Installed-Size: 183299
> >
> > This problem does *not* seem to occur with a vanilla 4.9.2 kernel,
> implying
> > something Debian-specific:
> >
> > $ uname -a
> > Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
> > GNU/Linux
> >
> > If you're aware of any Debian patches that might be suspect, I'm happy to
> > try some custom builds. Reproducing the issue is trivial on my end when a
> > kernel is "bad".
> [...]
>
> I think that the difference is more likely to be in the configuration,
> rather than the patches we apply.
>
> Some other people followed up to your bug report suggesting there might
> be a BIOS bug affecting behaviour after a warm reboot, but not booting
> from power-off:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#17
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#32
>
> (Unfortunately I don't see any BIOS updates available for this model.)
> Have you tried booting one of the newer kernel versions from power-off?
>
> Ben.
>
> --
> Ben Hutchings
> Design a system any fool can use, and only a fool will want to use it.
>



-- 
*Tom Lee */ http://tomlee.co / @tglee 

Bug#852167: even with quirks gone, the tools are needed

[Adam Borowski]

> the quirks applied by pm-utils aren't really needed anymore nowadays.  I
> suspect some of the are actually harmful these days.

But even if we get rid of the quirks, the actual tools (/usr/sbin/pm-*) are
still needed.

> Also, with the switch to systemd/logind, pm-utils is no longer used by
> default for suspend/resume which means we are not actively using pm-utils
> either anymore.

With systemd-shim hardly working, and being likely on its way out, using
systemd/logind for suspend/resume is not a reasonable idea; pm-utils are a
simple building block.


The package consists of two parts:
* scripts that handle the commands, passing them to backends, some logic
  like setting disk spindown
* working around bugs in a random shit laptop whose vendor I won't call any
  names they deserve as any such comparison would be unfair to retarded
  monkeys on crack
The first part is much needed, maintaining the second would require an
extreme masochist.


-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#843349: linux-image-4.7.0-1-amd64: Intermittently high system load, sluggish response, no /proc//stat utime,stime,etc. reported

[Ben Hutchings]

On Wed, 2017-01-25 at 17:52 -0800, Tom Lee wrote:
> Just an update: I am still encountering similar performance issues with the
> 4.9.0-1 kernel that was recently promoted to testing. In fact, the 4.9.0-1
> kernel may be the worst yet in terms of this specific issue, with IntelliJ
> starting so slowly as to be effectively unusable. One time the entire
> system appeared to become completely unresponsive & a hard reset was
> required.
> 
> The most recent kernel with which I've experienced problems:
> 
> $ apt-cache show linux-image-4.9.0-1-amd64
> Package: linux-image-4.9.0-1-amd64
> Source: linux-signed (4)
> Version: 4.9.2-2
> Installed-Size: 183299
> 
> This problem does *not* seem to occur with a vanilla 4.9.2 kernel, implying
> something Debian-specific:
> 
> $ uname -a
> Linux desktop.local 4.9.2 #1 SMP Wed Jan 25 04:28:29 PST 2017 x86_64
> GNU/Linux
> 
> If you're aware of any Debian patches that might be suspect, I'm happy to
> try some custom builds. Reproducing the issue is trivial on my end when a
> kernel is "bad".
[...]

I think that the difference is more likely to be in the configuration,
rather than the patches we apply.

Some other people followed up to your bug report suggesting there might
be a BIOS bug affecting behaviour after a warm reboot, but not booting
from power-off:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#17
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=843349#32

(Unfortunately I don't see any BIOS updates available for this model.)
Have you tried booting one of the newer kernel versions from power-off?

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


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

Bug#744815: please compile against openssl

[Jonas Smedegaard]

Quoting Jamie McClelland (2017-01-26 22:26:10)
> I see that this is an old bug and would really like to see it 
> resolved.
> 
> I have had mixed success getting apache2 or ngninx to proxy icecast2. 
> It makes trouble shooting a lot harder.
> 
> And, without be able to access icecast2 over https, we get mixed 
> content warnings when displaying a stream on an https page.
> 
> From my tests, it compiles fine on amd64/jessie - I just needed to 
> install the libssl-dev package before building.

The problem here is that OpenSSL license is incompatible with GPL-2. 
license, and the latter is applied (without exception) to Icecast2.

That means anyone may compile with OpenSSL for their own use, but it is. 
not permitted to redistribute linked binaries to others, so Debian. 
cannot legally distribute with OpenSSL.

Other than the current approach of shipping without SSL support,. 
alternative options are to a) link with another TLS library providing an 
OpenSSL-compatible shim, b) patch the code to link against another TLS. 
library natively, or c) convince Icecast2 developers to relicense to a. 
license compatible with OpenSSL (the most minimal change being "GPL-2. 
with OpenSSL exception").


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#852601: API key is not available

[Haruki TSURUMOTO]

>Please see #845988 and /usr/share/doc/minitube/NEWS.Debian.gz.
> Sorry, but this is wontfix.

Oh, I missed d/NEWS file. Thank you for your time.

-- 
Haruki TSURUMOTO
PGP Fingerprint:3718 C84E 4EDA 1B5C 4F26 8639 9D3D EE3F 63A6 000E

Bug#852740: WARNING: …/fs/sysf/group.c:237 device_del : sysfs group 'power' not found for kobject 'event18'

[Ben Hutchings]

Control: tag -1 moreinfo

On Thu, 2017-01-26 at 15:40 -0500, Daniel Kahn Gillmor wrote:
> Package: src:linux
> Version: 4.9.2-2
> Severity: normal
> 
> Using the same USB webcam as from the crash reported in
> https://bugs.debian.org/852738, i plugged it in again after rebooting
> into 4.9.0-1-amd64 (version 4.9.2-2).  While i didn't get the null
> pointer dereference, i got several unusual messages ("Warning!
> Unlikely big volume range (=3072), cval->res is probably wrong") on
> insertion, and then 5 minutes later i yanked the camera and got a
> series of warnings on removal that all seem to be related to sysfs
> groups:
[...]

It looks like the camera was still in use when it was removed, as the
warning shows that a task called 'AudioThread' is closing a file
handle.  Do you know whether the behaviour is specific to this camera,
or does it also happen with other USB cameras?

(This looks somewhat similar to the problem discussed in
.  The real fix for that appears
to have been .  But that was in
PCI, not USB.)

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.


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

Bug#852601: API key is not available

[Jakob Haufe]

tags 852601 + wontfix
kthxbye

On Wed, 25 Jan 2017 23:25:38 +0900
Haruki TSURUMOTO  wrote:

> Dear maintainer,
> minitube requires YouTube API keys.(IMO, it required at build time)
> Upsteram's binary package (http://flavio.tordini.org/minitube) is
> usable,But Debian version is not.

Please see #845988 and /usr/share/doc/minitube/NEWS.Debian.gz.

Sorry, but this is wontfix.

Cheers,
sur5r

-- 
ceterum censeo microsoftem esse delendam.


pgplOavDnCsE3.pgp
Description: OpenPGP digital signature

Bug#821193: kicad: FTBFS on hurd-i386

[Jakob Haufe]

After studying the build logs I came to the following conclusion:

KiCAD depends on wxFileSystemWatcher which does not seem to be implemented
for hurd (yet?).

A quick search on the wxwidgets trac did not show any tickets related to this.

This means no KiCAD on hurd until someone implements wxFileSystemWatcher for 
hurd.

Cheers,
sur5r
-- 
ceterum censeo microsoftem esse delendam.


pgp8G7YAMHSU0.pgp
Description: OpenPGP digital signature

Bug#852757: apt calls malloc inside SIGWINCH handler, leading to deadlock

[Anders Kaseorg]

Package: apt
Version: 1.4~beta4ubuntu1

(I also checked the code of 1.4~beta4, hence reporting here.)

I just had an ‘apt install’ process freeze when I resized its terminal 
window.  Attaching gdb revealed the backtrace below, showing that free() 
was interrupted by the SIGWINCH handler, which calls Configuration::FindB, 
which builds the first argument of checkFindConfigOptionType with the 
std::string(const char *) constructor, which tries to call malloc(), 
leading to a deadlock.

malloc() is unsafe to call within a signal hander 
(https://www.securecoding.cert.org/confluence/display/c/SIG30-C.+Call+only+asynchronous-safe+functions+within+signal+handlers).

Probably the most straightforward solution is to have the signal handler 
do nothing other than set a volatile sig_atomic_t flag, and defer the real 
work to some safe point outside the handler.

Anders

#0  __lll_lock_wait_private ()
at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:95
#1  0x7fb4d0b6de82 in __GI___libc_malloc (bytes=140414575876864)
at malloc.c:2923
#2  0x7fb4d1155af8 in operator new(unsigned long) ()
   from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x7fb4d14ee54d in std::__cxx11::basic_string::_M_construct 
(this=0x7fffda2fe130, 
__beg=0x7fb4d15be6c1 "Debug::InstallProgress::Fancy", 
__end=) at /usr/include/c++/6/bits/basic_string.tcc:219
#4  0x7fb4d14f19b5 in std::__cxx11::basic_string::_M_construct_aux (
__end=, 
__beg=0x7fb4d15be6c1 "Debug::InstallProgress::Fancy", this=0x7fffda2fe130)
at /usr/include/c++/6/bits/basic_string.h:196
#5  std::__cxx11::basic_string::_M_construct (__end=, 
__beg=0x7fb4d15be6c1 "Debug::InstallProgress::Fancy", this=0x7fffda2fe130)
at /usr/include/c++/6/bits/basic_string.h:215
#6  std::__cxx11::basic_string::basic_string (__a=..., 
__s=0x7fb4d15be6c1 "Debug::InstallProgress::Fancy", this=0x7fffda2fe130)
at /usr/include/c++/6/bits/basic_string.h:456
#7  Configuration::FindB (this=0x561e68c59c20, 
Name=Name@entry=0x7fb4d15be6c1 "Debug::InstallProgress::Fancy", 
Default=Default@entry=@0x7fffda2fe19f: false)
at ./apt-pkg/contrib/configuration.cc:446
#8  0x7fb4d1579700 in APT::Progress::PackageManagerFancy::GetTerminalSize (
this=this@entry=0x561e69344bf0) at ./apt-pkg/install-progress.cc:253
#9  0x7fb4d157a379 in APT::Progress::PackageManagerFancy::HandleSIGWINCH (
this=0x561e69344bf0) at ./apt-pkg/install-progress.cc:299
#10 0x7fb4d157a3bf in APT::Progress::PackageManagerFancy::staticSIGWINCH (
signum=28) at ./apt-pkg/install-progress.cc:240
#11 
#12 0x7fb4d0b6a358 in _int_free (av=0x7fb4d0ea9b00 , 
p=0x561e69a6a890, have_lock=0) at malloc.c:4040
#13 0x7fb4d0b6e18c in __GI___libc_free (mem=)
at malloc.c:2982
#14 0x7fb4d157c918 in metaIndex::~metaIndex (this=0x561e699f0100, 
__in_chrg=) at ./apt-pkg/metaindex.cc:45
#15 0x7fb4d1524ee9 in debReleaseIndex::~debReleaseIndex (
this=0x561e699f0100, __in_chrg=)
at ./apt-pkg/deb/debmetaindex.cc:111
#16 0x7fb4d1534dd6 in debSLTypeDebian::CreateItemInternal (
this=0x7fb4d17f6800 <_apt_DebSrcType>, List=..., URI=..., Dist=..., 
Section="universe", IsSrc=IsSrc@entry=@0x7fffda2fee67: true, 
Options=std::map with 1 elements = {...})
at ./apt-pkg/deb/debmetaindex.cc:1156
#17 0x7fb4d1535005 in debSLTypeDebSrc::CreateItem (this=, 
List=..., URI=..., Dist=..., Section=..., Options=...)
at ./apt-pkg/deb/debmetaindex.cc:1199
#18 0x7fb4d15a0cfd in pkgSourceList::Type::ParseLine (
this=0x7fb4d17f6800 <_apt_DebSrcType>, 
List=std::vector of length 9, capacity 16 = {...}, Buffer=, 
CurLine=18, File="/etc/apt/sources.list") at ./apt-pkg/sourcelist.cc:271
#19 0x7fb4d159e892 in pkgSourceList::ParseFileOldStyle (
this=this@entry=0x561e6974cf10, File="/etc/apt/sources.list")
at ./apt-pkg/sourcelist.cc:415
#20 0x7fb4d15a4388 in pkgSourceList::ReadAppend (
this=this@entry=0x561e6974cf10, File="/etc/apt/sources.list")
at ./apt-pkg/sourcelist.cc:364
#21 0x7fb4d15a4715 in pkgSourceList::ReadMainList (
this=this@entry=0x561e6974cf10) at ./apt-pkg/sourcelist.cc:319
#22 0x7fb4d14d68c6 in pkgCacheFile::BuildSourceList (
this=this@entry=0x7fffda2ff880) at ./apt-pkg/cachefile.cc:145
#23 0x7fb4d14d768b in pkgCacheFile::BuildCaches (
this=this@entry=0x7fffda2ff880, Progress=Progress@entry=0x0, 
WithLock=WithLock@entry=true) at ./apt-pkg/cachefile.cc:107
#24 0x7fb4d154c28e in pkgDPkgPM::Go (this=0x561e697fbac0, 
progress=) at ./apt-pkg/deb/dpkgpm.cc:2154
#25 0x7fb4d1587c4b in pkgPackageManager::DoInstallPostFork (
this=0x561e697fbac0, progress=0x561e69344bf0)
at ./apt-pkg/packagemanager.cc:1154
#26 0x7fb4d181cb0d in InstallPackages(CacheFile&, bool, bool, bool) ()
   

Bug#852756: gnome-logs crashes after starting

[Marc Bonnor]

Package: gnome-logs
Version: 3.22.1-1
Severity: important

Dear Maintainer,

The program starts but no log contents are visible.

Then after selecting any menu picks with the mouse the program crashes.

This program has never worked for me, so nothing has changed.

Maybe it has something to do with permissions, because if I try to start 
the program with sudo it just crashes, doesn't even start.

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

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

Versions of packages gnome-logs depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gsettings-desktop-schemas3.22.0-1
ii  libc62.24-9
ii  libglib2.0-0 2.50.2-2
ii  libgtk-3-0   3.22.7-2
ii  libsystemd0  232-14

gnome-logs recommends no packages.

gnome-logs suggests no packages.

-- no debconf information

Bug#852755: libkf5i18n-dev: should depend on gettext

[Frédéric Brière]

Package: libkf5i18n-dev
Version: 5.28.0-1
Severity: normal

KF5I18NMacros.cmake invokes find_package(Gettext REQUIRED).


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

Kernel: Linux 4.8.0-2-amd64 (SMP w/3 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: sysvinit (via /sbin/init)

Versions of packages libkf5i18n-dev depends on:
ii  libkf5i18n55.28.0-1
pn  python:any 
ii  qtscript5-dev  5.7.1~20161021+dfsg-2

libkf5i18n-dev recommends no packages.

libkf5i18n-dev suggests no packages.

-- no debconf information

Bug#852749: linux-image-4.9.0-1-amd64: usb-audio-device not working since kernel 4.9.0.1

[Ben Hutchings]

Control: tag -1 patch moreinfo

Please test whether the attached patches fix this.  You can find
instructions for rebuilding the kernel package at:
https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s-common-official

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.
From: Ben Hutchings 
Date: Fri, 27 Jan 2017 00:28:33 +
Subject: [1/2] ALSA: line6: toneport: Add error checks to toneport_setup()
 etc.
Origin: https://git.kernel.org/linus/fc5e7a3683e1a0ce039c7ed8440ae49d60e6dfd6
Bug-Debian: https://bugs.debian.org/852749

toneport_setup() currently ignores all errors and returns void.  Make
it and toneport_update_led() report errors, and make toneport_init()
check for this.

Fixes: 705ececd1c60 ("Staging: add line6 usb driver")
Signed-off-by: Ben Hutchings 
---
 sound/usb/line6/toneport.c | 43 +--
 1 file changed, 29 insertions(+), 14 deletions(-)

diff --git a/sound/usb/line6/toneport.c b/sound/usb/line6/toneport.c
index 8e22f430d700..646c27a79f68 100644
--- a/sound/usb/line6/toneport.c
+++ b/sound/usb/line6/toneport.c
@@ -294,11 +294,11 @@ static bool toneport_has_led(struct usb_line6_toneport *toneport)
 static const char * const led_colors[2] = { "red", "green" };
 static const int led_init_vals[2] = { 0x00, 0x26 };
 
-static void toneport_update_led(struct usb_line6_toneport *toneport)
+static int toneport_update_led(struct usb_line6_toneport *toneport)
 {
-	toneport_send_cmd(toneport->line6.usbdev,
-			  (toneport->leds[0].dev.brightness << 8) | 0x0002,
-			  toneport->leds[1].dev.brightness);
+	return toneport_send_cmd(toneport->line6.usbdev,
+ (toneport->leds[0].dev.brightness << 8) | 0x0002,
+ toneport->leds[1].dev.brightness);
 }
 
 static void toneport_led_brightness_set(struct led_classdev *led_cdev,
@@ -365,29 +365,42 @@ static bool toneport_has_source_select(struct usb_line6_toneport *toneport)
 /*
 	Setup Toneport device.
 */
-static void toneport_setup(struct usb_line6_toneport *toneport)
+static int toneport_setup(struct usb_line6_toneport *toneport)
 {
 	int ticks;
 	struct usb_line6 *line6 = >line6;
 	struct usb_device *usbdev = line6->usbdev;
+	int err;
 
 	/* sync time on device with host: */
 	ticks = (int)get_seconds();
-	line6_write_data(line6, 0x80c6, , 4);
+	err = line6_write_data(line6, 0x80c6, , 4);
+	if (err < 0)
+		return err;
 
 	/* enable device: */
-	toneport_send_cmd(usbdev, 0x0301, 0x);
+	err = toneport_send_cmd(usbdev, 0x0301, 0x);
+	if (err < 0)
+		return err;
 
 	/* initialize source select: */
-	if (toneport_has_source_select(toneport))
-		toneport_send_cmd(usbdev,
-  toneport_source_info[toneport->source].code,
-  0x);
+	if (toneport_has_source_select(toneport)) {
+		err = toneport_send_cmd(usbdev,
+	toneport_source_info[toneport->source].code,
+	0x);
+		if (err < 0)
+			return err;
+	}
 
-	if (toneport_has_led(toneport))
-		toneport_update_led(toneport);
+	if (toneport_has_led(toneport)) {
+		err = toneport_update_led(toneport);
+		if (err < 0)
+			return err;
+	}
 
 	mod_timer(>timer, jiffies + TONEPORT_PCM_DELAY * HZ);
+
+	return 0;
 }
 
 /*
@@ -451,7 +464,9 @@ static int toneport_init(struct usb_line6 *line6,
 			return err;
 	}
 
-	toneport_setup(toneport);
+	err = toneport_setup(toneport);
+	if (err < 0)
+		return err;
 
 	/* register audio system: */
 	return snd_card_register(line6->card);
From: Ben Hutchings 
Date: Fri, 27 Jan 2017 00:40:49 +
Subject: [2/2] ALSA: line6: Move USB message buffers off-stack
Origin: https://git.kernel.org/linus/13d338f1016e8898c98faa9c790d7056ef934307
Bug-Debian: https://bugs.debian.org/852749

Allocating USB buffers on the stack is not portable, and no longer
works on x86_64 (with VMAP_STACK enabled as per default).

Fixes: 705ececd1c60 ("Staging: add line6 usb driver")
Signed-off-by: Ben Hutchings 
---
 sound/usb/line6/driver.c   | 64 +-
 sound/usb/line6/podhd.c| 22 ++--
 sound/usb/line6/toneport.c | 10 +---
 3 files changed, 61 insertions(+), 35 deletions(-)

diff --git a/sound/usb/line6/driver.c b/sound/usb/line6/driver.c
index 90009c0b3a92..b3a7f0c809da 100644
--- a/sound/usb/line6/driver.c
+++ b/sound/usb/line6/driver.c
@@ -337,12 +337,16 @@ int line6_read_data(struct usb_line6 *line6, unsigned address, void *data,
 {
 	struct usb_device *usbdev = line6->usbdev;
 	int ret;
-	unsigned char len;
+	unsigned char *len;
 	unsigned count;
 
 	if (address > 0x || datalen > 0xff)
 		return -EINVAL;
 
+	len = kmalloc(1, GFP_ATOMIC);
+	if (!len)
+		return -ENOMEM;
+
 	/* query the serial number: */
 	ret = usb_control_msg(usbdev, usb_sndctrlpipe(usbdev, 0), 0x67,
 			  USB_TYPE_VENDOR | USB_RECIP_DEVICE | USB_DIR_OUT,
@@ -351,7 +355,7 @@ int line6_read_data(struct usb_line6 *line6, unsigned address, void *data,
 
 	if (ret < 0) {
 		

Bug#852513: grub-efi-amd64: during configuration: "No space left on device"

[Andrew Harvey]

On Wed, 25 Jan 2017 12:46:55  0900 Norbert Preining  wrote:
> > > Could not delete variable: No space left on device
>
> The problem is with efibootmgr that cannot add new entries.
>
> It turns out that there were incredible many entries in
> /sys/fs/pstore
> related to some dumps. I have removed all of them.

Thank you for that! I had a broken system due to the exact same error
as you for a few months now (needing to bootstrap boot with rEFInd
each time), and deleting the contents of /sys/fs/pstore and then doing
this grub upgrade fixed it.

Bug#852163: Change severity

[Gary Roach]

Control: severity -l critical

This bug is effecting at least reportbug, causing problems with spyder 
and may be causing periodic hangup with the kde desktop. From some of 
the emails, I get the impression that there may be more. Now numpy.py 
refused to work. Please fix this soon.


Gary R.

Bug#852697: [pkg-gnupg-maint] Bug#852697: gnupg-agent: automatically starts gpg-agent in root user slice

[Daniel Kahn Gillmor]

Hi Laurent--

On Thu 2017-01-26 09:06:03 -0500, Laurent Bonnaud wrote:
> I usually remotely log in (via ssh) as root on a system where gnupg
> packages are installed and I noticed that a gpg-agent process is
> created for the root user:
>
> # systemd-cgls
> Control group /:
> -.slice
> ├─user.slice
> │ └─user-0.slice
> │   ├─user@0.service
> │   │ ├─dbus.service
> │   │ │ └─16957 /usr/bin/dbus-daemon --session --address=systemd: --nofork 
> --nopidfile --systemd-activation --syslo
> │   │ ├─gpg-agent.service
> │   │ │ └─15353 /usr/bin/gpg-agent --supervised
> │   │ ├─init.scope
> │   │ │ ├─31495 /lib/systemd/systemd --user
> │   │ │ └─31497 (sd-pam)
> │   │ └─gvfs-daemon.service
> │   │   ├─17040 /usr/lib/gvfs/gvfsd
> │   │   └─17045 /usr/lib/gvfs/gvfsd-fuse /run/user/0/gvfs -f -o big_writes
>
> This process is of no use to the root user and therefore the system
> would be better without it.  Would it be possible to prevent the
> creation of this process?

It should only be active because some process queried the gpg-agent.  If
nothing queries the agent, then it won't get started.

Having it in the user@0.service subtree is good because that means it
will be terminated when your session ends.

You can safely terminate the systemd-supervised agent with the same way
that you would terminate any other systemd-supervised user service:

systemctl --user stop gpg-agent

But note that if some other process wants to talk to the agent, then
systemd will start it up again automatically as requested.

Does the agent process appear as soon as you log in?

Is it possible that something in your login scripts is invoking gpg in a
way that wants to talk to the agent?  

--dkg


signature.asc
Description: PGP signature

Bug#843926: (no subject)

[Daniel Black]

As Thadeu Lima de Souza Cascardo said, the build time detected page size
isn't correct, perhaps using --with-lg-page=/--with-lg-page-sizes at
compile time.

This is available in the 3.6.0 version of jemalloc.

(upstream currently
at 4.4.0).

As an aside, I've got part way though an upstream patch to change this
to runtime detection, no idea when it will be complete, and I have been
told that upstream won't risk performance regressions.

Bug#852754: picocom: Update picocom to new upstream version 2.2

[Cody Planteen]

Package: picocom
Version: 1.7-1
Severity: wishlist

It would be nice to have an updated version of the picocom package based on
upstream. The latest upstream release is 2.2 from October 2016. The current
Debian package is is picocom 1.7 from February 2012. If you are no longer
interested in maintaining this package, I would be happy to help out.

The picocom releases are in Github at:
https://github.com/npat-efault/picocom/release

Also, the homepage for picocom is no longer at Google Code as linked on the
Debian package page, it is on Github:
https://github.com/npat-efault/picocom/



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

Kernel: Linux 4.4.0-59-generic (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 picocom depends on:
ii  libc6  2.23-0ubuntu5

picocom recommends no packages.

picocom suggests no packages.

-- no debconf information

Bug#852753: diamond-aligner: builds with -march=native

[Aaron M. Ucko]

Source: diamond-aligner
Version: 0.8.34+dfsg-1
Severity: important

diamond-aligner builds with -march=native, which is inappropriate for
Debian (and any other binary-based distribution) because it limits the
portability of the resulting executables.  Could you please arrange to
switch that flag off?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

Bug#808463: ntfs-3g: non-free code in boot.c

[James Cowgill]

Control: fixed -1 1:2016.2.22AR.2-1
Control: retitle -1 ntfs-3g: non-free code in boot.c

Hi,

This looks fixed in experimental to me:

https://sources.debian.net/src/ntfs-3g/1:2016.2.22AR.2-1/ntfsprogs/boot.c/

Please can the new boot.c be backported to stretch / unstable.

Thanks,
James



signature.asc
Description: OpenPGP digital signature

Bug#852752: diamond-aligner: FTBFS (32-bit): assumes uint32_t and unsigned aren't size_t

[Aaron M. Ucko]

Source: diamond-aligner
Version: 0.8.34+dfsg-1
Severity: important
Justification: fails to build from source

Builds of diamond-aligner on 32-bit architectures such as i386 have
been failing:

  /«BUILDDIR»/diamond-aligner-0.8.34+dfsg/src/basic/../util/util.h:494:15: 
error: ambiguating new declaration of ‘double percentage(size_t, size_t)’
   inline double percentage(size_t x, size_t y)
 ^~
  /«BUILDDIR»/diamond-aligner-0.8.34+dfsg/src/basic/../util/util.h:489:17: 
note: old declaration ‘unsigned int percentage(unsigned int, unsigned int)’
   inline unsigned percentage(unsigned x, unsigned y)
   ^~
  [...]
  
/«BUILDDIR»/diamond-aligner-0.8.34+dfsg/src/basic/../util/text_buffer.h:154:15: 
error: ‘Text_buffer& Text_buffer::operator<<(size_t)’ cannot be overloaded
Text_buffer& operator<<(size_t x)
 ^~~~
  
/«BUILDDIR»/diamond-aligner-0.8.34+dfsg/src/basic/../util/text_buffer.h:138:15: 
error: with ‘Text_buffer& Text_buffer::operator<<(uint32_t)’
Text_buffer& operator<<(uint32_t x)
 ^~~~
Could you please take a look?  I'd suggest conditionalizing one
definition in each pair by #ifdef __LP64__.  (Also, please sweep for
other such cases.)

Thanks!

-- System Information:
Debian Release: 9.0
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (300, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, x32

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

-- no debconf information

Bug#851989: release.debian.org: de-branding Icedove, Thunderbird packages in Stretch?

[Emilio Pozuelo Monfort]

On 25/01/17 22:49, Carsten Schoenert wrote:
> One more minor note,
> 
> On Tue, Jan 24, 2017 at 08:07:02AM +0100, Carsten Schoenert wrote:
> ...
>> So maybe some extension may break now simply because the package
>> dependencies are now to strict. Such packages should be easy to find as
>> if the icedove package is referenced the thunderbird package needed to
>> be provided as well. Christoph could (and should) address such problems
>> in his announcement.
> 
> this statement is not fully true from a backview.
> We need to ship the transitional icedove package for Stretch at all
> times so a dependency on 'icedove' will end in the reverse dependency on
> 'thunderbird' and the extension will work. For Stretch+1 we need to proof
> the xul-ext packages for depending on thunderbird then.
> 
> Christoph will check which reverse depends on icedove-dev we have.

emilio@tatooine:~$ build-rdeps icedove-dev
WARNING: dose-extra >= 4.0 is not installed. Falling back to old unreliable
behaviour.
Reverse Build-depends in main:
--

calendar-exchange-provider
sogo-connector

Found a total of 2 reverse build-depend(s) for icedove-dev.

Cheers,
Emilio

Bug#852702: [pkg-gnupg-maint] Bug#852702: [gnupg2] gpg: OpenPGP card not available: No such device after upgrade to 2.1.18-3

[Daniel Kahn Gillmor]

Control: reassign 852702 scdaemon

Hi Shin Ice--

Thanks for the report!  I'm afraid i don't understand what's going on
here (and i don't have a yubikey 4 to test with, but maybe gniibe
(cc'ed) can shed some light on it.

Regards,

--dkg

On Thu 2017-01-26 09:46:04 -0500, Shin Ice wrote:
> Package: gnupg2
> Version: 2.1.18-3
> Severity: important
>
> --- Please enter the report below this line. ---
>
> Hi,
>
> after upgrading gnupg2 (and related) to version 2.1.18-3 the yubikey 4
> can't be used. On a different system (still sid) with version 2.1.16-3
> all works as desired and designed.
>
> $ gpg2 --card-status
> gpg: selecting openpgp failed: No such device
> gpg: OpenPGP card not available: No such device
>
> $ pcsc_scan
> PC/SC device scanner
> V 1.4.27 (c) 2001-2011, Ludovic Rousseau 
> Compiled with PC/SC lite version: 1.8.17
> Using reader plug'n play mechanism
> Scanning present readers...
> 0: Yubico Yubikey 4 CCID 00 00
>
> Thu Jan 26 14:50:02 2017
> Reader 0: Yubico Yubikey 4 CCID 00 00
>   Card state: Card inserted,
>   ATR: 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4
>
> ATR: 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4
> + TS = 3B --> Direct Convention
> + T0 = F8, Y(1): , K: 8 (historical bytes)
>   TA(1) = 13 --> Fi=372, Di=4, 93 cycles/ETU
> 43010 bits/s at 4 MHz, fMax for Fi = 5 MHz => 53763 bits/s
>   TB(1) = 00 --> VPP is not electrically connected
>   TC(1) = 00 --> Extra guard time: 0
>   TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1
> -
>   TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1 
> -
>   TA(3) = FE --> IFSC: 254
>   TB(3) = 15 --> Block Waiting Integer: 1 - Character Waiting Integer: 5
> + Historical bytes: 59 75 62 69 6B 65 79 34
>   Category indicator byte: 59 (proprietary format)
> + TCK = D4 (correct checksum)
>
> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
> 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4
> Yubico Yubikey 4 OTP+CCID
>
> output from /var/log/messages
> Jan 26 14:44:15 akira kernel: [ 1065.486401] perf: interrupt took too
> long (2507 > 2500), lowering kernel.perf_event_max_sample_rate to 79750
> Jan 26 14:48:08 akira kernel: [ 1298.188119] usb 2-1.2: USB disconnect,
> device number 13
> Jan 26 14:49:58 akira kernel: [ 1408.239508] usb 2-1.2: new full-speed
> USB device number 14 using ehci-pci
> Jan 26 14:49:58 akira kernel: [ 1408.355525] usb 2-1.2: New USB device
> found, idVendor=1050, idProduct=0404
> Jan 26 14:49:58 akira kernel: [ 1408.355529] usb 2-1.2: New USB device
> strings: Mfr=1, Product=2, SerialNumber=0
> Jan 26 14:49:58 akira kernel: [ 1408.355533] usb 2-1.2: Product: Yubikey
> 4 CCID
> Jan 26 14:49:58 akira kernel: [ 1408.355536] usb 2-1.2: Manufacturer:
> Yubico
>
> Same output from the system with 2.1.16-3 running:
> $ pcsc_scan 
> PC/SC device scanner
> V 1.4.27 (c) 2001-2011, Ludovic Rousseau 
> Compiled with PC/SC lite version: 1.8.17
> Using reader plug'n play mechanism
> Scanning present readers...
> 0: Yubico Yubikey 4 CCID 00 00
>
> Thu Jan 26 14:48:57 2017
> Reader 0: Yubico Yubikey 4 CCID 00 00
>   Card state: Card inserted, Exclusive Mode, 
>   ATR: 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4
>
> ATR: 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4
> + TS = 3B --> Direct Convention
> + T0 = F8, Y(1): , K: 8 (historical bytes)
>   TA(1) = 13 --> Fi=372, Di=4, 93 cycles/ETU
> 43010 bits/s at 4 MHz, fMax for Fi = 5 MHz => 53763 bits/s
>   TB(1) = 00 --> VPP is not electrically connected
>   TC(1) = 00 --> Extra guard time: 0
>   TD(1) = 81 --> Y(i+1) = 1000, Protocol T = 1 
> -
>   TD(2) = 31 --> Y(i+1) = 0011, Protocol T = 1
> -
>   TA(3) = FE --> IFSC: 254
>   TB(3) = 15 --> Block Waiting Integer: 1 - Character Waiting Integer: 5
> + Historical bytes: 59 75 62 69 6B 65 79 34
>   Category indicator byte: 59 (proprietary format)
> + TCK = D4 (correct checksum)
>
> Possibly identified card (using /usr/share/pcsc/smartcard_list.txt):
> 3B F8 13 00 00 81 31 FE 15 59 75 62 69 6B 65 79 34 D4
> Yubico Yubikey 4 OTP+CCID
>
> $ gpg2 --card-status
>
> Reader ...: Yubico Yubikey 4 CCID 00 00
>
> output from /var/log/messages
> Jan 26 14:40:22 motoko kernel: [1824155.938692] usb 4-2: USB disconnect,
> device number 8
> Jan 26 14:48:11 motoko kernel: [1824624.984164] usb 4-2: new full-speed
> USB device number 9 using ohci-pci
> Jan 26 14:48:11 motoko kernel: [1824625.177260] usb 4-2: New USB device
> found, idVendor=1050, idProduct=0404
> Jan 26 14:48:11 motoko kernel: [1824625.177267] usb 4-2: New USB device
> strings: Mfr=1, Product=2, SerialNumber=0
> Jan 26 14:48:11 motoko kernel: [1824625.177272] usb 4-2: Product:
> Yubikey 4 CCID
> Jan 26 14:48:11 motoko kernel: [1824625.177275] usb 4-2: Manufacturer:
> Yubico
>
> If you need more infos/tests, feel free to let me know =)
>
> c'ya
> Shin
>
>
>
> --- System information. ---
> Architecture: 
> Kernel:   

Bug#852326: libreoffice-common: Please add Multi-Arch: foreign

[Elrond]

Hi,

On Thu, Jan 26, 2017 at 12:32:58 +0100, Rene Engelhard wrote:
[...]
> True, but I gave in already for other packages where it might have made sense,
> but in this specific case it just doesn't.

Thanks for the note.

I will do a local repackage and see, if it resolves the
dependency problem I am seeing.  If it does, I will be
happy for my local setups and script the repackaging for
the updates.


> Regards,
> 
> Rene


Cheers

Elrond

Bug#826555: gcc-snapshot regression: -Warray-bounds false positive with -O2

[Vincent Lefevre]

Control: tags -1 - fixed-upstream

On 2017-01-17 12:06:17 +0100, Vincent Lefevre wrote:
> Control: tags -1 fixed-upstream
> 
> See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71433#c10

Well, I can no longer reproduce the warning with the simple test case,
but this is still reproducible with the MPFR code (get_d.c).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#852131: binutils-hppa-linux-gnu: Cannot crossbuild for hppa on i386: "libgcc.a: file not recognized: File format not recognized"

[Christoph Biedl]

Matthias Klose wrote...

> This seems to be a duplicate of #850191, please can you check if this is fixed
> with  gcc-6-cross-ports 12?

Build passes with gcc-6-hppa-linux-gnu 6.3.0-5cross1, Source: gcc-6-cross-ports 
(14)

Christoph


signature.asc
Description: Digital signature

Bug#852751: [cryptkeeper] Sets the same password "p" for everything independently of user input

[Kirill Tkhai]

Package: cryptkeeper
Version: 0.9.5-5.1
Severity: critical
Tags: security
X-Debbugs-CC: secure-testing-t...@lists.alioth.debian.org

Hello, guys,

today I tried to use cryptkeeper in the first time. I created
a new encrypted folder by wizzard, and copied my data into
the folder in Nautilus. Then I umounted the folder. But later,
when I mounted it once again, cryptkeeper said the password
is wrong (though, I 100% know, it's true!).

I've looked into cryptkeeper code and found, it calls encfs
with -S option:

execlp ("encfs", "encfs", "-S", crypt_dir, mount_dir, NULL);
exit (0);

While the password is passed to encfs using pipe in this way:
// paranoid default setup mode
//write (fd[1], "y\n", 2);
//write (fd[1], "y\n", 2);
write (fd[1], "p\n", 2);
write (fd[1], password, strlen (password));
write (fd[1], "\n", 1);

But it seems it's wrong. When I'm executing encfs program
from console

$ encfs -S crypt_dir mount_dir

and I'm passing "p\n", encfs exits and doesn't wait for a password
itself.

I do not know, who is blame, cryptkeeper or encfs, and even nothing
about if the interface above exists ("p\n" before the password).
But decrypting using "p" password works for any encrypted directory,
created using cryptkeeper. This obviously mustn't work such way.

Kirill

--- System information. ---
Architecture: 
Kernel:   Linux 4.9.3+

Debian Release: 9.0
  500 unstableftp.ru.debian.org 
  500 testing ftp.ru.debian.org 
  500 stable-updates  ftp.ru.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp.ru.debian.org 
1 experimentalftp.ru.debian.org 

--- Package information. ---
Depends   (Version) | Installed
===-+-=
gconf-service   | 3.2.6-4
libatk1.0-0 (>= 1.12.4) | 2.22.0-1
libc6  (>= 2.4) | 
libcairo2(>= 1.2.4) | 
libfontconfig1   (>= 2.9.0) | 
libfreetype6 (>= 2.2.1) | 
libgcc1(>= 1:4.1.1) | 
libgconf-2-4(>= 2.31.1) | 
libgdk-pixbuf2.0-0  (>= 2.22.0) | 
libglib2.0-0(>= 2.16.0) | 
libgtk2.0-0 (>= 2.10.0) | 
libpango1.0-0   (>= 1.14.0) | 
libstdc++6   (>= 4.1.1) | 
libx11-6| 
zenity  | 
fuse| 
encfs   | 


Package's Recommends field is empty.

Package's Suggests field is empty.

Bug#852732: torbrowser-launcher: sig verification failed: also for first time download

[Gregor Zattler]

Package: torbrowser-launcher
Version: 0.2.6-3
Followup-For: Bug #852732

Dear Maintainer,

I have the very same problem as Sebastian Niehaus with
torbrowser-launcher from debian testing while trying to download
tbb for the very first time.

Most probably the problem is with the files on the tor projects
server but ATM there is nothing at the tor mailinglist archives about
the problem.

Thanks, Gregor


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

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

Versions of packages torbrowser-launcher depends on:
ii  ca-certificates  20161130
ii  gnupg2.1.17-2
ii  python-gtk2  2.24.0-5.1
ii  python-lzma  0.5.3-3
ii  python-parsley   1.2-1
ii  python-psutil5.0.1-1
ii  python-twisted   16.6.0-2
ii  python-txsocksx  1.15.0.2-1
pn  python:any   
ii  wmctrl   1.07-7

Versions of packages torbrowser-launcher recommends:
ii  tor  0.2.9.8-2

Versions of packages torbrowser-launcher suggests:
pn  apparmor   
pn  python-pygame  

-- no debconf information

Bug#852380: still broken

[Brian Warner]

FWIW, ekeyd is still giving me errors when I try to launch it on my sid
box, updated today:

  $ dpkg -s lua-socket |grep Version:
  Version: 3.0~rc1+git+ac3201d-3

  $ dpkg -s ekeyd |grep Version:
  Version: 1.1.5-6.1

  $ sudo /usr/sbin/ekeyd
  Unable to run configuration file:
  control.lua:755: control.lua:526: attempt to index global 'socket' (a
nil value)

cheers,
 -Brian

Bug#828154: RFP: spacemacs -- Emacs configuration to get best of Emacs and Vim

[Sean Whitton]

Hello Lev,

On Fri, Jan 27, 2017 at 01:10:51AM +0500, Lev Lamberov wrote:
> With up-to-date Spacemacs source it produces a list of 558 packages.
> Please, find the output attached. So, it is ready to put to the team's
> wiki. ;-)

Done!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daniel Kahn Gillmor]

On Thu 2017-01-26 14:34:22 -0500, Daiki Ueno wrote:
> Jens Lechtenboerger  writes:
>> The mml code is based on EasyPG by Daiki Ueno (cc’ed).  EasyPG makes
>> use of sub-keys and their IDs for encryption commands, instead of
>> relying on GnuPG’s selections.
>
> It was suggested by Werner to do key selection in Emacs, like GPGME.  I
> don't know whether GPGME changed the logic though.

I don't know what this means -- i don't think that GPGME itself does key
selection.  Can you tell me more?

Presumably users who use emacs with gpg also use gpg with other tools
(possibly even other MUAs), or even gpg on its own.  Collecting key
preference data in multiple places while sharing the underlying key
store seems like a recipe for synchronization problems and confusing
behavior, particularly for folks who don't know how the tools fit
together.


>>> Modern versions of GnuPG also provide a "tofu" mechanism to store and
>>> track that kind of decision in.  Neal Walfield (also cc'ed here) put in
>>> a lot of that implementation, so he might have some suggestions for the
>>> best way to handle it.
>
> I'm afraid I wouldn't do any work toward tofu at this level of quality;
> in particular, until they reach the consensus whether tofu is only
> activated when encryption is triggered by an email address.

I don't think i understand this either.  Can you explain more about what
you need from the GnuPG TOFU code?

Thanks for this discussion, hopefully it'll lead somewhere fruitful.

   --dkg


signature.asc
Description: PGP signature

Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daniel Kahn Gillmor]

On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
> nowadays.  I certainly wouldn’t object if the default value was
> changed, but lots of long-term users might be surprised.

hm, i just noticed that mml-secure-openpgp-always-trust isn't in emacs24
either.  is this also limited to emacs25?  Maybe this change of variable
is a good chance to do the transition to a better default.

 --dkg


signature.asc
Description: PGP signature

Bug#745553: bug#17391: Bug#745553: emacs24-el: mml2015-always-trust should default to nil, not t

[Daniel Kahn Gillmor]

On Thu 2017-01-26 13:36:09 -0500, Jens Lechtenboerger wrote:
> On 2017-01-25, at 15:30, Daniel Kahn Gillmor wrote:
>> On Wed 2017-01-25 15:09:47 -0500, Jens Lechtenboerger wrote:
>>> mml2015-always-trust is replaced by mml-secure-openpgp-always-trust
>>> nowadays.  I certainly wouldn’t object if the default value was
>>> changed, but lots of long-term users might be surprised.
>>
>> It's also possible that lots of long-term users might be surprised to
>> find that refreshing one key in their keyring is likely to cause a
>> change in behavior for the use of other keys in their keyring.  this is
>> a silent surprise, which seems worse than a public surprise.
>
> Sorry, I don’t understand this.  What change in one key is causing
> silent changes for other keys?

Without the notification that multiple keys are available, Bob can add
Carol's User ID to his cert ; depending on where the certs are
positioned linearly in Alice's keyring, mail to Carol might be encrypted
to Bob's key, or to Alice's key.

I think this is mitigated at least in part by prompting the user when
there are multiple keys available, though.

> That’s customized in mml-secure-key-preferences.  So, the usual
> customize interface is available.  And there is some code to detect
> and remove unusable customizations.

When was this introduced?  i don't see it, but then i'm still using
emacs24.  Do i need to upgrade?

>> Modern versions of GnuPG also provide a "tofu" mechanism to store and
>> track that kind of decision in.  Neal Walfield (also cc'ed here) put in
>> a lot of that implementation, so he might have some suggestions for the
>> best way to handle it.
>
> If Emacs was relying on GnuPG’s decisions, nothing special would be
> necessary for tofu, right?  (Users could activate that in their
> gpg.conf.)

Neal can answer this better than i can.  I think the TOFU mode works
best when there's a bit of UI integration -- emacs would provide the way
for the user to answer a question prompted by gpg, and then gpg is
responsible for storing/tracking all the info.

--dkg

Bug#852750: libreadline7: readline() interferes with blocked SIGALRM

[Frédéric Brière]

Package: libreadline7
Version: 7.0-1
Severity: normal
Tags: patch upstream
Forwarded: https://lists.gnu.org/archive/html/bug-readline/2017-01/msg2.html
Control: affects -1 twinkle-console

readline() in 7.0-1 calls pselect() with an empty sigmask, thereby
unblocking all signals beforehand.  This causes twinkle-console to abort
after a few seconds, due to a now-unblocked SIGALRM being delivered to
the main thread, instead of the one calling sigwait().

Upstream has posted a one-line patch to fix this issue.  Is it too late
to have it applied before the freeze?  Otherwise, twinkle-console will
be pretty much unusable in stretch.


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

Kernel: Linux 4.8.0-2-amd64 (SMP w/3 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: sysvinit (via /sbin/init)

Versions of packages libreadline7 depends on:
ii  libc62.24-9
ii  libtinfo56.0+20161126-1
ii  readline-common  7.0-2

libreadline7 recommends no packages.

libreadline7 suggests no packages.

-- no debconf information

Bug#852746: [Pkg-opencl-devel] Bug#852746: beignet+mesa-opencl-icd crash if installed together

[Rebecca N. Palmer]

Control: retitle -1 beignet+mesa-opencl-icd crash if installed together

The lack of hardware isn't the trigger - having beignet-opencl-icd and 
mesa-opencl-icd installed at the same time is.  (beignet+pocl or 
mesa+pocl is OK.)


Looks like some kind of "seeing the other ICD's copy of libllvm instead 
of their own" problem (similar to 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768185 , and possibly 
appearing now because beignet just switched to the same LLVM version as 
mesa), but I haven't yet had time to confirm this.

Bug#852749: linux-image-4.9.0-1-amd64: usb-audio-device not working since kernel 4.9.0.1

[Marc Neudorfer]

Package: src:linux
Version: 4.9.2-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
After the last kernel update from version 4.8.0.2 to 4.9.0.1 my 
usb-audio-interface (Line6 Pod Studio UX2) stopped working.
The device powers on, but no audio-playback is possible.
Video-Playback (HMTL5-Videos) are also not possible and even some 
Playback-Software are crashing.
I have recieved the attached error-message (syslog)
   * What exactly did you do (or not do) that was effective (or ineffective)?
- Turning the device off and on again
- Switching back to kernel 4.8.0.2
- I also found a similar Bug on bugzilla.kernel.org "Bug 191891 - 
dtt200u usb driver no longer loads"
  -> https://bugzilla.kernel.org/show_bug.cgi?id=191891 
  Although this is a totaly different device, the problem seems to be 
the same.
  But the bug report didn't provide any useful information helping me 
fixing this problem.
   * What was the outcome of this action?
- Turning on and off didn't work
- After switching back to kernel 4.8.0.2 the device worked fine and no 
errors are reported in syslog.

-- Package-specific info:
** Version:
Linux version 4.9.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.3.0 
20161229 (Debian 6.3.0-2) ) #1 SMP Debian 4.9.2-2 (2017-01-12)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-1-amd64 root=/dev/mapper/vg1-root ro quiet

** Tainted: PWOE (12801)
 * Proprietary module has been loaded.
 * Taint on warning.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.103092] snd_usb_toneport 3-4:1.0: 
Line 6 POD Studio UX2 found
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106398] [ cut here 
]
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106410] WARNING: CPU: 0 PID: 408 at 
/build/linux-fgnWKv/linux-4.9.2/drivers/usb/core/hcd.c:1584 
usb_hcd_map_urb_for_dma+0x37c/0x570 [usbcore]
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106410] transfer buffer not dma 
capable
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106411] Modules linked in: joydev 
snd_usb_toneport(+) snd_usb_line6 evdev snd_rawmidi snd_seq_device pcspkr 
snd_hda_intel serio_raw snd_hda_codec snd_hda_core snd_hwdep snd_pcm sg 
snd_timer lpc_ich nvidia_drm(POE) ie31200_edac snd mei_me soundcore mei 
edac_core shpchp mfd_core wmi battery tpm_infineon drm_kms_helper 
pcc_cpufreq(-) acpi_cpufreq(-) tpm_tis button tpm_tis_core video tpm drm 
nvidia_modeset(POE) nvidia(POE) nct6775 hwmon_vid coretemp parport_pc ppdev lp 
parport ip_tables x_tables autofs4 ext4 crc16 jbd2 fscrypto ecb mbcache raid10 
raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c crc32c_generic raid0 multipath linear hid_logitech_hidpp 
hid_logitech_dj dm_mod raid1 md_mod sr_mod sd_mod cdrom hid_generic usbhid hid 
crc32c_intel ahci libahci xhci_pci
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106445]  aesni_intel xhci_hcd 
firewire_ohci libata psmouse firewire_core aes_x86_64 crc_itu_t glue_helper lrw 
gf128mul ehci_pci e1000e ablk_helper i2c_i801 ehci_hcd scsi_mod cryptd 
i2c_smbus usbcore ptp pps_core usb_common thermal fan fjes
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106457] CPU: 0 PID: 408 Comm: 
systemd-udevd Tainted: P   OE   4.9.0-1-amd64 #1 Debian 4.9.2-2
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106458] Hardware name: System 
manufacturer System Product Name/P8C WS, BIOS 3010 08/27/2012
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106459]   
a3128b84 aa5cc1ee7850 
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106461]  a2e76dbe 
976dc9a9fd80 aa5cc1ee78a8 
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106463]  aa5cc1ee7a5c 
976dc6ce 0002 a2e76e3f
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106465] Call Trace:
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106470]  [] ? 
dump_stack+0x5c/0x78
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106473]  [] ? 
__warn+0xbe/0xe0
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106475]  [] ? 
warn_slowpath_fmt+0x5f/0x80
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106482]  [] ? 
usb_hcd_map_urb_for_dma+0x37c/0x570 [usbcore]
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106489]  [] ? 
usb_hcd_submit_urb+0x330/0xaa0 [usbcore]
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106492]  [] ? 
__schedule+0x23b/0x6d0
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106499]  [] ? 
usb_start_wait_urb+0x6d/0x170 [usbcore]
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106506]  [] ? 
usb_control_msg+0xdc/0x130 [usbcore]
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106509]  [] ? 
line6_read_data+0xfe/0x210 [snd_usb_line6]
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106511]  [] ? 
toneport_init+0xa7/0x244 [snd_usb_toneport]
Jan 26 23:15:58 Th3M4ch1n3 kernel: [3.106513]  [] ? 
line6_probe+0x24e/0x470 [snd_usb_line6]
Jan 26 23:15:58 Th3M4ch1n3 

Bug#849401: restart silently fails

[Francesco Poli]

On Tue, 17 Jan 2017 01:38:42 +0100 Christian Hofstaedtler wrote:

> * Francesco Poli  [170115 17:39]:
> > Christian, have you decided which strategy should be adopted for the
> > ISCONFIGURED handling?
> 
> I'm going to set the default UPSTYPE to usb, so there will be no
> activity on /dev/ttyS0 caused by the default configuration, and then
> ignoring ISCONFIGURED under systemd should be okay.

Christian,
I would like to thank you for doing this NMU.
It's much appreciated!   :-)

Bye.

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgp2Sw3S5R29z.pgp
Description: PGP signature

Bug#832931: (no subject)

[Daniel Black]

As Thadeu Lima de Souza Cascardo said, the build time detected page size
isn't correct, perhaps using --with-lg-page=/--with-lg-page-sizes at
compile time.

This is available in the 3.6.0 version of jemalloc. (upstream currently
at 4.4.0). I've got part way though an upstream patch to change this to
runtime detection, no idea when it will be complete, and I have been
told that upstream won't risk performance regressions.

Bug#852748: system unbootable on Lenovo x260 with EFI

[Harald Welte]

Package: grub-efi-amd64-bin
Version: 2.02~beta3-4
Severity: important

After updating to 2.02~beta3-4 and successive grub-install (happens
during installation), the system was completely unable to boot.  I tried
various BIOS settings (boot order, EFI and Legacy mode, disabled all other boot
sources), played with efibootmgr settings, no avail.

The only way to boot the system was using an external USB drive that had
been created with a previous version of grub2-efi.  From there, I could
then load the lvm module and load the grub2 configuration file from my
built-in hard disk (the nataraja_x26-space volume) and boot the system.

When the system failed to boot, no grub output was seen on the display.
Rather, booting the hard disk immediately returned to the boot menu (or
proceeded to alternative boot sources such as PXE).  So it fails super
fast, without any output.

Booting into a Debian resuce system, chroot()ing into the root
filesystem and then running grub-install did not change the situation at
all.

Downgrading to 2.02~beta3-3 from testing immediately solved the problem,
so the breakage is definitely introduced between beta3-3 and beta3-4.

I am not sure if this is something specific to the x260, but I would be
surprised if I'm the only one hit by this and rendering systems
unbootable is quite a big problem :/

BIOS information from dmidecode:

BIOS Information
Vendor: LENOVO
Version: R02ET46W (1.19 )
Release Date: 03/15/2016
Address: 0xE
Runtime Size: 128 kB
ROM Size: 16384 kB
Characteristics:
PCI is supported
PNP is supported
BIOS is upgradeable
BIOS shadowing is allowed
Boot from CD is supported
Selectable boot is supported
EDD is supported
3.5"/720 kB floppy services are supported (int 13h)
Print screen service is supported (int 5h)
8042 keyboard services are supported (int 9h)
Serial services are supported (int 14h)
Printer services are supported (int 17h)
CGA/mono video services are supported (int 10h)
ACPI is supported
USB legacy is supported
BIOS boot specification is supported
Targeted content distribution is supported
UEFI is supported
BIOS Revision: 1.19
Firmware Revision: 1.11

-- Package-specific info:

*** BEGIN /proc/mounts
/dev/mapper/nataraja_x260-root / btrfs 
rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/ 0 0
/dev/sda3 /boot/efi msdos 
rw,relatime,fmask=0022,dmask=0022,codepage=437,errors=remount-ro 0 0
/dev/mapper/nataraja_x260-space /space btrfs 
rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/ 0 0
/dev/mapper/crypt /crypt btrfs 
rw,noatime,ssd,discard,space_cache,subvolid=5,subvol=/ 0 0
*** END /proc/mounts

*** BEGIN /boot/grub/device.map
(hd0)   /dev/disk/by-id/ata-Hitachi_HTS723232L9A360_090830FC2400NEHEAGAG
(hd1)   /dev/sdg
*** END /boot/grub/device.map

*** BEGIN /boot/grub/grub.cfg
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
  set have_grubenv=true
  load_env
fi
if [ "${next_entry}" ] ; then
   set default="${next_entry}"
   set next_entry=
   save_env next_entry
   set boot_once=true
else
   set default="0"
fi

if [ x"${feature_menuentry_id}" = xy ]; then
  menuentry_id_option="--id"
else
  menuentry_id_option=""
fi

export menuentry_id_option

if [ "${prev_saved_entry}" ]; then
  set saved_entry="${prev_saved_entry}"
  save_env saved_entry
  set prev_saved_entry=
  save_env prev_saved_entry
  set boot_once=true
fi

function savedefault {
  if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
  fi
}
function load_video {
  if [ x$feature_all_video_module = xy ]; then
insmod all_video
  else
insmod efi_gop
insmod efi_uga
insmod ieee1275_fb
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
  fi
}

if [ x$feature_default_font_path = xy ] ; then
   font=unicode
else
insmod part_gpt
insmod lvm
insmod btrfs
set 
root='lvmid/BBL6ib-CjYL-8A8o-itKZ-EHiK-wAp8-v0kG1p/3ZjUVz-KvQI-jJK0-HsYA-RoP6-mQQj-dwG9mx'
if [ x$feature_platform_search_hint = xy ]; then
  search --no-floppy --fs-uuid --set=root 
--hint='lvmid/BBL6ib-CjYL-8A8o-itKZ-EHiK-wAp8-v0kG1p/3ZjUVz-KvQI-jJK0-HsYA-RoP6-mQQj-dwG9mx'
  3cabc80b-e273-47d5-b70a-b3742a50e9c0
else
  search --no-floppy --fs-uuid --set=root 3cabc80b-e273-47d5-b70a-b3742a50e9c0
fi
font="/usr/share/grub/unicode.pf2"
fi

if loadfont $font ; then
  set gfxmode=auto
  load_video
  insmod gfxterm
  set locale_dir=$prefix/locale
  set 

Bug#852747: enable kexec on arm64

[dann frazier]

Source: linux
Version: 4.9.2-2

Hi! Please enable CONFIG_KEXEC on arm64. The userspace side landed in
unstable yesterday, and I verified that it works (at least in QEMU) w/
a Debian kernel rebuilt w/ CONFIG_KEXEC=y.

  -dann

Bug#422207: odbc_config would have had SQL_WCHART_CONVERT - and that would have allowed one to use unixodbc wide-character functions

[Danny Milosavljevic]

Hi,

the prototypes of functions in sqlucode.h have SQLWCHAR* parameters but the 
size of SQLWCHAR depends on the definition SQL_WCHART_CONVERT (see sqltypes.h). 

"odbc_config --cflags" would have allowed a client to find out whether to 
define SQL_WCHART_CONVERT or not. If it's missing you can't.

This is necessary in order to use any of the wide variants in sqlucode.h at all.

Without "odbc_config --cflags" or an equivalent (pkg-config files could also 
store these flags) you can't really use all of unixodbc as a library in a 
program.

Regards,
   Danny

Bug#852380: ekeyd: Does not start after luasocket upgrade

[Mathieu Parent]

On Mon, 23 Jan 2017 20:57:59 -0600 Courtney Bane
 wrote:
> Package: ekeyd
> Version: 1.1.5-6.1
> Severity: grave
> Tags: patch
> Justification: renders package unusable
>
> After the recent upgrade of the lua-socket package to version
> 3.0~rc1+git+ac3201d-2, ekeyd no longer starts if Unix domain sockets are
> used (for either the control or EGD socket). Instead, it exits with this
> error message:

Hi Courtney,

Can you please test with lua-socket 3.0~rc1+git+ac3201d-3, which
includes your fix (backported)?

Then close this one...

Thanks!

Mathieu Parent

Bug#852696: gvfs-fuse: automatically starts gvfsd and gvfsd-fuse in root user slice

[Laurent Bonnaud]

On 26/01/2017 22:51, Simon McVittie wrote:

> If you unmask the unit, and change the apt configuration snippet that I
> mentioned in a previous mail to this bug so it runs
> "if ...; then GIO_USE_VFS=local appstream-cli refresh-cache > /dev/null..."
> then that should avoid the unwanted daemons without either producing
> error messages, or preventing the use of gvfs if some other program you
> run as root actually needs it.

I confirm that the GIO_USE_VFS=local environment variable prevents the creation 
of the gvfs processes, even when the gvfs-daemon.service unit is unmasked.

Thanks again,

-- 
Laurent.

Bug#851261: compiles but doesn't work, not our fault

[Adam Borowski]

On 01/13/2017 01:23 PM, Radovan Birdic wrote:
> Package: duperemove
> Version: 0.11~beta4-1
> Tags: sid + patch
> Justification: FTBFS
> User: debian-m...@lists.debian.org
> Usertags: mips-patch
> With these patches, package builds successfully on mips, mipsel, mips64el and 
> i386.

Alas, while it does compile (also on amd64, armhf, powerpc), it doesn't
actually work:

root@debian-sid-mipsel:/mnt/vol1# duperemove -Ardh a b
Using 128K blocks
Using hash: murmur3
Gathering file list...
Error 25: Inappropriate ioctl for device while finding subvolid for file 
"/mnt/vol1/a". Skipping.
Error 25: Inappropriate ioctl for device while finding subvolid for file 
"/mnt/vol1/b". Skipping.

This is not just duperemove, though:

root@debian-sid-mipsel:/mnt/vol1# btrfs fi sync .
ERROR: sync ioctl failed on '.': Inappropriate ioctl for device

Looks like this set of ioctls, like many others, breaks when mixing 64-bit
kernel with 32-bit userspace.

Do any non-ancient machines run 32-bit kernels on MIPS these days?  As far
as I know, they don't, thus fixing this FTBFS is rather pointless without
fixing COMPAT ioctls on the kernel side first.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Bug#852728: [debian-mysql] Bug#852728: FTBFS on non-Linux architectures

[James Clarke]

> On 26 Jan 2017, at 22:03, James Clarke  wrote:
> 
>> On 26 Jan 2017, at 21:59, Otto Kekäläinen  wrote:
>> 
>> Thanks for the patch!
>> 
>> It did though include whitespace characters etc so I had to apply it
>> manually.
> 
> Odd; I rebased the commit on top of 52e9f then did a git format-patch.

Sorry, got confused between the two bugs. Still not sure why it wouldn't
apply directly though.

Regards,
James

Bug#852728: [debian-mysql] Bug#852728: FTBFS on non-Linux architectures

[James Clarke]

> On 26 Jan 2017, at 21:59, Otto Kekäläinen  wrote:
> 
> Thanks for the patch!
> 
> It did though include whitespace characters etc so I had to apply it
> manually.

Odd; I rebased the commit on top of 52e9f then did a git format-patch.

> In the future I'd prefer to get patches as public git
> branches I can easily pull (and you can easily rebase when the target
> repo updates). Or alternatively you can send patches on Github as pull
> requests.
> 
> https://anonscm.debian.org/git/pkg-mysql/mariadb-10.1.git/
> (mirror https://github.com/ottok/mariadb-10.1)

Ok I'll try to remember that.

Thanks,
James

Bug#769792: (no subject)

[ZenWalker]

Hello, I have tested the patch for jessie, and it doesn't work for me 
(on a VM)


I attached the patchAuthor: monsta 
Description: don't change file permissions when saving the modified image

--- a/src/eom-image.c
+++ b/src/eom-image.c
@@ -1431,6 +1431,110 @@ transfer_progress_cb (goffset cur_bytes,
 	}
 }
 
+static void
+tmp_file_restore_unix_attributes (GFile *temp_file,
+  GFile *target_file)
+{
+	GFileInfo *file_info;
+	guint  uid;
+	guint  gid;
+	guint  mode;
+	guint  mode_mask = 00600;
+
+	GError*error = NULL;
+
+	g_return_if_fail (G_IS_FILE (temp_file));
+	g_return_if_fail (G_IS_FILE (target_file));
+
+	/* check if file exists */
+	if (!g_file_query_exists (target_file, NULL)) {
+		eom_debug_message (DEBUG_IMAGE_SAVE,
+   "Target file doesn't exist. Setting default attributes.");
+		return;
+	}
+
+	/* retrieve UID, GID, and MODE of the original file info */
+	file_info = g_file_query_info (target_file,
+   "unix::uid,unix::gid,unix::mode",
+   G_FILE_QUERY_INFO_NONE,
+   NULL,
+   );
+
+	/* check that there aren't any error */
+	if (error != NULL) {
+		eom_debug_message (DEBUG_IMAGE_SAVE,
+   "File information not available. Setting default attributes.");
+
+		/* free objects */
+		g_object_unref (file_info);
+		g_clear_error ();
+
+		return;
+	}
+
+	/* save UID, GID and MODE values */
+	uid = g_file_info_get_attribute_uint32 (file_info,
+		G_FILE_ATTRIBUTE_UNIX_UID);
+
+	gid = g_file_info_get_attribute_uint32 (file_info,
+		G_FILE_ATTRIBUTE_UNIX_GID);
+
+	mode = g_file_info_get_attribute_uint32 (file_info,
+		 G_FILE_ATTRIBUTE_UNIX_MODE);
+
+	/* apply default mode mask to file mode */
+	mode |= mode_mask;
+
+	/* restore original UID, GID, and MODE into the temporal file */
+	g_file_set_attribute_uint32 (temp_file,
+ G_FILE_ATTRIBUTE_UNIX_UID,
+ uid,
+ G_FILE_QUERY_INFO_NONE,
+ NULL,
+ );
+
+	/* check that there aren't any error */
+	if (error != NULL) {
+		eom_debug_message (DEBUG_IMAGE_SAVE,
+   "You do not have the permissions necessary to change the file UID.");
+
+		g_clear_error ();
+	}
+
+	g_file_set_attribute_uint32 (temp_file,
+ G_FILE_ATTRIBUTE_UNIX_GID,
+ gid,
+ G_FILE_QUERY_INFO_NONE,
+ NULL,
+ );
+
+	/* check that there aren't any error */
+	if (error != NULL) {
+		eom_debug_message (DEBUG_IMAGE_SAVE,
+   "You do not have the permissions necessary to change the file GID. Setting user default GID.");
+
+		g_clear_error ();
+	}
+
+	g_file_set_attribute_uint32 (temp_file,
+ G_FILE_ATTRIBUTE_UNIX_MODE,
+ mode,
+ G_FILE_QUERY_INFO_NONE,
+ NULL,
+ );
+
+	/* check that there aren't any error */
+	if (error != NULL) {
+		eom_debug_message (DEBUG_IMAGE_SAVE,
+   "You do not have the permissions necessary to change the file MODE.");
+
+		g_clear_error ();
+	}
+
+	/* free objects */
+	g_object_unref (file_info);
+}
+
 static gboolean
 tmp_file_move_to_uri (EomImage *image,
 		  GFile *tmpfile,
@@ -1441,6 +1545,10 @@ tmp_file_move_to_uri (EomImage *image,
 	gboolean result;
 	GError *ioerror = NULL;
 
+	/* try to restore target file unix attributes */
+	tmp_file_restore_unix_attributes (tmpfile, file);
+
+	/* replace target file with temporal file */
 	result = g_file_move (tmpfile,
 			  file,
 			  (overwrite ? G_FILE_COPY_OVERWRITE : 0) |

Bug#852746: beignet-opencl-icd: Every OpenCL application crashes (CLInfo, LibreOffice, etc.)

[Ivan Baldo]

Package: beignet-opencl-icd
Version: 1.2.1-1+b1
Severity: important

Hello.
Every application that uses OpenCL crashes in this way:
$ clinfo
X server found. dri2 connection failed! 
/dev/dri/card0 not authenticated
: CommandLine Error: Option 'enable-value-profiling' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

Uninstalling this package fixes every application.
Installing the version in Sid 1.3.0-1 also crashes in the same way.
Running as root it crashes like this (with 1.3.0-1):
# clinfo
X server found. dri2 connection failed! 
DRM_IOCTL_I915_GEM_APERTURE failed: Invalid argument
Assuming 131072kB available aperture size.
May lead to reduced performance or incorrect rendering.
get chip id failed: -1 [22]
param: 4, val: 0
: CommandLine Error: Option 'enable-value-profiling' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

I know that under KVM I don't need this package, but I will run this same Linux 
in different PCs,
some Intel, some AMD, some virtualized.
The expected behaviour is that it would not load and use another ICD instead, 
without crashing.
Thanks!!!

-- Package-specific info:
Graphics hardware:
Providers: number : 1
Provider 0: id: 0x41 cap: 0x0 crtcs: 1 outputs: 1 associated providers: 0 
name:modesetting
server glx vendor string: SGI
client glx vendor string: Mesa Project and SGI
Extended renderer info (GLX_MESA_query_renderer):
OpenGL vendor string: VMware, Inc.
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 3.9, 128 bits)
00:02.0 VGA compatible controller [0300]: Device [1234:]

Processor:
Architecture:  i686
CPU op-mode(s):32-bit, 64-bit
Byte Order:Little Endian
CPU(s):4
On-line CPU(s) list:   0-3
Thread(s) per core:1
Core(s) per socket:1
Socket(s): 4
Vendor ID: GenuineIntel
CPU family:6
Model: 2
Model name:QEMU Virtual CPU version 2.1.2
Stepping:  3
CPU MHz:   3199.996
BogoMIPS:  6399.99
Hypervisor vendor: KVM
Virtualization type:   full
L1d cache: 32K
L1i cache: 32K
L2 cache:  4096K
Flags: fpu de pse tsc msr pae mce cx8 apic mtrr pge mca cmov 
pse36 clflush mmx fxsr sse sse2 syscall nx lm eagerfpu pni cx16 popcnt 
hypervisor lahf_lm abm

OpenCL library:
un  libopencl-1.1-1 
un  libopencl-1.2-1 
un  libopencl-2.0-1 
un  libopencl-2.1-1 
un  libopencl1  
un  nvidia-libopencl1-dev   
ii  ocl-icd-libopencl1:i386 2.2.10-2
ii  beignet-opencl-icd:i386 1.2.1-1+b1
ii  mesa-opencl-icd:i38613.0.3-1
un  opencl-icd  
un  opencl-icd-1.1-1
un  opencl-icd-1.2-1
ii  pocl-opencl-icd 0.13-8
==> /etc/OpenCL/vendors/intel-beignet-i386-linux-gnu.icd <==
/usr/lib/i386-linux-gnu/beignet//libcl.so

==> /etc/OpenCL/vendors/mesa.icd <==
libMesaOpenCL.so.1

==> /etc/OpenCL/vendors/pocl.icd <==
libpocl.so.1

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

Kernel: Linux 4.9.0-1-686-pae (SMP w/4 CPU cores)
Locale: LANG=es_UY.UTF-8, LC_CTYPE=es_UY.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to es_UY.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages beignet-opencl-icd depends on:
ii  libc6  2.24-8
ii  libdrm-intel1  2.4.74-1
ii  libdrm22.4.74-1
ii  libgcc11:6.2.1-5
ii  libllvm3.9 1:3.9.1-1
ii  libstdc++6 6.2.1-5
ii  libx11-6   2:1.6.4-2
ii  libxext6   2:1.3.3-1
ii  libxfixes3 1:5.0.3-1

beignet-opencl-icd recommends no packages.

beignet-opencl-icd suggests no packages.

-- no debconf information

Bug#852728: [debian-mysql] Bug#852728: FTBFS on non-Linux architectures

[Otto Kekäläinen]

Thanks for the patch!

It did though include whitespace characters etc so I had to apply it
manually. In the future I'd prefer to get patches as public git
branches I can easily pull (and you can easily rebase when the target
repo updates). Or alternatively you can send patches on Github as pull
requests.

https://anonscm.debian.org/git/pkg-mysql/mariadb-10.1.git/
(mirror https://github.com/ottok/mariadb-10.1)

Thanks!

Bug#852696: gvfs-fuse: automatically starts gvfsd and gvfsd-fuse in root user slice

[Simon McVittie]

On Thu, 26 Jan 2017 at 21:59:09 +0100, Laurent Bonnaud wrote:
> Now with the workaround in place (masking the gvfs-daemon.service service) I 
> see the following error message:
> 
> # apt-get update
> [...]
> (appstreamcli:11277): GVFS-WARNING **: Error creating proxy: Error calling 
> StartServiceByName for org.gtk.vfs.Daemon: 
> GDBus.Error:org.freedesktop.systemd1.UnitMasked: Unit gvfs-daemon.service is 
> masked. (g-io-error-quark, 36)

That's as expected.

If you unmask the unit, and change the apt configuration snippet that I
mentioned in a previous mail to this bug so it runs
"if ...; then GIO_USE_VFS=local appstream-cli refresh-cache > /dev/null..."
then that should avoid the unwanted daemons without either producing
error messages, or preventing the use of gvfs if some other program you
run as root actually needs it.

S

Bug#852709: [debian-mysql] Bug#852709: Patch

[James Clarke]

Patch actually attached this time...

Regards,
James
>From 47cc704d11d8991818fb7bf5ebff63c5a727da01 Mon Sep 17 00:00:00 2001
From: James Clarke 
Date: Thu, 26 Jan 2017 21:46:28 +
Subject: [PATCH] Allow mariadb-plugin-tokudb/mroonga on non-linux and
 non-release arches

---
 debian/control | 5 +++--
 debian/rules   | 6 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/debian/control b/debian/control
index 5cca4947..852aa7ac 100644
--- a/debian/control
+++ b/debian/control
@@ -360,7 +360,7 @@ Description: OQGraph storage engine for MariaDB
  This package contains the OQGraph plugin for MariaDB.
 
 Package: mariadb-plugin-tokudb
-Architecture: amd64
+Architecture: base-any-any-amd64
 Depends: mariadb-server-10.1, ${misc:Depends}, ${shlibs:Depends}
 Breaks: mariadb-server-10.0, mariadb-server-10.1 (<< ${source:Version})
 Replaces: mariadb-server-10.0, mariadb-server-10.1 (<< ${source:Version})
@@ -371,7 +371,8 @@ Description: TokuDB storage engine for MariaDB
  This package contains the TokuDB plugin for MariaDB.
 
 Package: mariadb-plugin-mroonga
-Architecture: amd64 arm64 armel armhf i386 mips64el mipsel ppc64el
+# Supports little-endian architectures only
+Architecture: any-i386 any-ia64 any-alpha any-amd64 any-arm any-arm64 any-mipsel any-mipsr6el any-mips64el any-mips64r6el any-nios2 any-powerpcel any-ppc64el any-sh3 any-sh4 any-tilegx
 Depends: mariadb-server-10.1, ${misc:Depends}, ${shlibs:Depends}
 Breaks: mariadb-server-10.0, mariadb-server-10.1 (<< ${source:Version})
 Replaces: mariadb-server-10.0, mariadb-server-10.1 (<< ${source:Version})
diff --git a/debian/rules b/debian/rules
index f0b3aec4..abcae5fe 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,6 +14,8 @@ BUILDDIR := builddir
 DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_SYSTEM ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_SYSTEM)
 DEB_BUILD_ARCH ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH)
+DEB_BUILD_ARCH_ABI ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_ABI)
+DEB_BUILD_ARCH_CPU ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_CPU)
 DEB_BUILD_ARCH_OS ?= $(shell dpkg-architecture -qDEB_BUILD_ARCH_OS)
 DEBVERSION := $(shell dpkg-parsechangelog | awk '/^Version: / { print $$2 }' | sed 's/^.*-//' )
 DEB_SOURCE_PACKAGE ?= $(strip $(shell egrep '^Source: ' debian/control | cut -f 2 -d ':'))
@@ -48,7 +50,9 @@ else
 endif
 
 # Skip TokuDB if arch is not amd64
-ifneq ($(ARCH), amd64)
+# Skipped on the x32 ABI too; untested, but unlikely to work given i386 is not
+# supported.
+ifneq ($(DEB_HOST_ARCH_ABI)-$(DEB_HOST_ARCH_CPU), base-amd64)
 CMAKEFLAGS += -DWITHOUT_TOKUDB=true
 endif
 
-- 
2.11.0

Bug#823577: Patches

[Michael Biebl]

On Sat, 3 Dec 2016 00:43:49 +0100 Michael Biebl  wrote:
> control: tags -1 + moreinfo
> control: user pkg-systemd-maintain...@lists.alioth.debian.org
> control: usertag -1 + jessie-backport
> Hi
> 
> On Mon, 6 Jun 2016 15:26:31 +0200 Michael Biebl  wrote:
> > Am 06.05.2016 um 15:47 schrieb Nik Johnson:
> > > The previous message w/ patches was from me, just clicked the wrong button
> > > in gmail.
> > 
> > The patches are missing a proper commit message
> 
> could you re-export the patches with proper commit messages so we have
> some context.

Ping

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



signature.asc
Description: OpenPGP digital signature

Bug#852709: [debian-mysql] Bug#852709: Patch

[James Clarke]

On Thu, Jan 26, 2017 at 09:42:01PM +, James Clarke wrote:
> On Thu, 26 Jan 2017 22:07:51 +0200 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
>  wrote:
> > Great work Dieter!
> > 
> > I'll merge and upload immediately. I just hope this will be in time
> > before the Feb 5th freeze... Because the unstable->testing counter
> > resets on every upload, all old fixes are still pending +10 days after
> > this upload.
> 
> That's not right. You've ignored all of kfreebsd (and hurd);
> kfreebsd-amd64 currently builds mroonga but not tokudb, but in theory it
> could build both. I was about to finalise a patch myself which does it
> more thoroughly.

I have attached a patch to fix this. It also re-enables mroonga on many
of the ports architectures, which were neglected, as well as those that
aren't even available in the archive. Generated with:

> awk '/^#/{next;} $5 == "little"{print "any-"$1}' /usr/share/dpkg/cputable | 
> xargs

Regards,
James

Bug#774430: systemd: service makes as not reloadable

[Michael Biebl]

Am 26.01.2017 um 15:44 schrieb Michael Biebl:
> Am 18.01.2017 um 14:31 schrieb James Cowgill:

>> After debugging a bit I found this commit which seems likely to be the
>> cause. I haven't actually tested 215 with the patch though:
>> https://github.com/systemd/systemd/commit/c2fa048c4a70c8386c6d8fe939e5ea9edecf1e98
> 
> That looks very promising
> Could you try that patch on top of v215 and test if it fixes the issue?
> If so I'd cherry-pick that for the next stable upload.

Since I'm pretty sure this fixes the issue, I've pulled this patch into
the jessie branch [1] so the fix can be made available in the next stabe
release.

Regards,
Michael

[1]
https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=783367f

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



signature.asc
Description: OpenPGP digital signature

Bug#852745: abcde: last year in latest changelog entries

[Michal Politowski]

Package: abcde
Version: 2.8.1-1
Severity: minor

The entries for the recently uploaded versions 2.8-1 and 2.8.1-1
in the Debian chagelog are dated January 2016.

-- 
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.

Bug#852709: [debian-mysql] Bug#852709: Patch

[James Clarke]

On Thu, 26 Jan 2017 22:07:51 +0200 =?UTF-8?B?T3R0byBLZWvDpGzDpGluZW4=?= 
 wrote:
> Great work Dieter!
> 
> I'll merge and upload immediately. I just hope this will be in time
> before the Feb 5th freeze... Because the unstable->testing counter
> resets on every upload, all old fixes are still pending +10 days after
> this upload.

That's not right. You've ignored all of kfreebsd (and hurd);
kfreebsd-amd64 currently builds mroonga but not tokudb, but in theory it
could build both. I was about to finalise a patch myself which does it
more thoroughly.

Regards,
James

Bug#851379: dietlibc FTBFS on arm64: Bus error when running tst-calloc.c

[Thorsten Glaser]

Christian Seiler dixit:

>If you have time, could you install gdb, compile the binary with

Well, I should have “lunch” (had breakfast at 12:30 this noon…),
but this much I can do.

>-g, and generate a backtrace? That might already help me to figure
>out what's going on...

Recursive calls; the SIGBUS is likely a stack underflow.

GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from debian/unittests/ttt...done.
(gdb) set pagination off
(gdb) r
Starting program: /home/tg/dietlibc-0.34~cvs20160606/debian/unittests/ttt
[Inferior 1 (process 29556) exited normally]
(gdb) r
Starting program: /home/tg/dietlibc-0.34~cvs20160606/debian/unittests/ttt

Program received signal SIGBUS, Bus error.
0x00401740 in __testandset ()
(gdb) bt
#0  0x00401740 in __testandset ()
#1  0x004016a0 in __pthread_lock ()
#2  0x004016a0 in __pthread_lock ()
#3  0x004016a0 in __pthread_lock ()
#4  0x004016a0 in __pthread_lock ()
#5  0x004016a0 in __pthread_lock ()
#6  0x004016a0 in __pthread_lock ()
#7  0x004016a0 in __pthread_lock ()
#8  0x004016a0 in __pthread_lock ()
#9  0x004016a0 in __pthread_lock ()
#10 0x004016a0 in __pthread_lock ()
#11 0x004016a0 in __pthread_lock ()
#12 0x004016a0 in __pthread_lock ()
#13 0x004016a0 in __pthread_lock ()
#14 0x004016a0 in __pthread_lock ()
#15 0x004016a0 in __pthread_lock ()
#16 0x004016a0 in __pthread_lock ()
#17 0x004016a0 in __pthread_lock ()
#18 0x004016a0 in __pthread_lock ()
#19 0x004016a0 in __pthread_lock ()
#20 0x004016a0 in __pthread_lock ()
#21 0x004016a0 in __pthread_lock ()
#22 0x004016a0 in __pthread_lock ()
#23 0x004016a0 in __pthread_lock ()
#24 0x004016a0 in __pthread_lock ()
#25 0x004016a0 in __pthread_lock ()
#26 0x004016a0 in __pthread_lock ()
#27 0x004016a0 in __pthread_lock ()
#28 0x004016a0 in __pthread_lock ()
#29 0x004016a0 in __pthread_lock ()
#30 0x004016a0 in __pthread_lock ()
#31 0x004016a0 in __pthread_lock ()
#32 0x004016a0 in __pthread_lock ()
#33 0x004016a0 in __pthread_lock ()
#34 0x004016a0 in __pthread_lock ()
#35 0x004016a0 in __pthread_lock ()
#36 0x004016a0 in __pthread_lock ()
#37 0x004016a0 in __pthread_lock ()
#38 0x004016a0 in __pthread_lock ()
#39 0x004016a0 in __pthread_lock ()
#40 0x004016a0 in __pthread_lock ()
#41 0x004016a0 in __pthread_lock ()

[…]

#11411 0x004016a0 in __pthread_lock ()
#11412 0x004016a0 in __pthread_lock ()
#11413 0x004016a0 in __pthread_lock ()
#11414 0x004016a0 in __pthread_lock ()
#11415 0x004016a0 in __pthread_lock ()

[…]


But where’s the cause? I gave up around stack frame #25854 because
I have another lead:


(sid_arm64-dchroot)tg@asachi:~/dietlibc-0.34~cvs20160606$ gdb 
debian/unittests/ttt
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "aarch64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from debian/unittests/ttt...done.
(gdb) b __pthread_lock
Breakpoint 1 at 0x401674
(gdb) r
Starting program: /home/tg/dietlibc-0.34~cvs20160606/debian/unittests/ttt

Breakpoint 1, 0x00401674 in __pthread_lock ()
(gdb) bt
#0  0x00401674 in __pthread_lock ()
#1  0x00400858 in __thread_find_ ()
#2  0x00400894 in __thread_self ()
#3  0x0040059c in malloc ()
#4  0x0040059c in malloc ()
#5  0x0040059c in malloc ()
#6  0x0040059c in malloc ()
#7  0x0040059c in malloc 

Bug#852744: unblock: tcpdump/4.9.0-1

[Romain Francoise]

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

tcpdump 4.9.0 is a security upstream release which fixes 41 distinct
vulnerabilities, most of which are remotely exploitable. I would
appreciate if you could grant 4.9.0-1 an exemption from the current
mandatory 10-day migration delay rule. The debdiff is too large to
include, but the corresponding changelog entry is below. Thanks!

unblock tcpdump/4.9.0-1

tcpdump (4.9.0-1) unstable; urgency=high

  * New upstream security release, fixing the following:
+ CVE-2016-7922: buffer overflow in print-ah.c:ah_print().
+ CVE-2016-7923: buffer overflow in print-arp.c:arp_print().
+ CVE-2016-7924: buffer overflow in print-atm.c:oam_print().
+ CVE-2016-7925: buffer overflow in print-sl.c:sl_if_print().
+ CVE-2016-7926: buffer overflow in print-ether.c:ethertype_print().
+ CVE-2016-7927: buffer overflow in print-802_11.c:ieee802_11_radio_print().
+ CVE-2016-7928: buffer overflow in print-ipcomp.c:ipcomp_print().
+ CVE-2016-7929: buffer overflow in print-juniper.c:juniper_parse_header().
+ CVE-2016-7930: buffer overflow in print-llc.c:llc_print().
+ CVE-2016-7931: buffer overflow in print-mpls.c:mpls_print().
+ CVE-2016-7932: buffer overflow in print-pim.c:pimv2_check_checksum().
+ CVE-2016-7933: buffer overflow in print-ppp.c:ppp_hdlc_if_print().
+ CVE-2016-7934: buffer overflow in print-udp.c:rtcp_print().
+ CVE-2016-7935: buffer overflow in print-udp.c:rtp_print().
+ CVE-2016-7936: buffer overflow in print-udp.c:udp_print().
+ CVE-2016-7937: buffer overflow in print-udp.c:vat_print().
+ CVE-2016-7938: integer overflow in print-zeromq.c:zmtp1_print_frame().
+ CVE-2016-7939: buffer overflow in print-gre.c, multiple functions.
+ CVE-2016-7940: buffer overflow in print-stp.c, multiple functions.
+ CVE-2016-7973: buffer overflow in print-atalk.c, multiple functions.
+ CVE-2016-7974: buffer overflow in print-ip.c, multiple functions.
+ CVE-2016-7975: buffer overflow in print-tcp.c:tcp_print().
+ CVE-2016-7983: buffer overflow in print-bootp.c:bootp_print().
+ CVE-2016-7984: buffer overflow in print-tftp.c:tftp_print().
+ CVE-2016-7985: buffer overflow in print-calm-fast.c:calm_fast_print().
+ CVE-2016-7986: buffer overflow in print-geonet.c, multiple functions.
+ CVE-2016-7992: buffer overflow in print-cip.c:cip_if_print().
+ CVE-2016-7993: a bug in util-print.c:relts_print() could cause a
  buffer overflow in multiple protocol parsers (DNS, DVMRP, HSRP, IGMP,
  lightweight resolver protocol, PIM).
+ CVE-2016-8574: buffer overflow in print-fr.c:frf15_print().
+ CVE-2016-8575: buffer overflow in print-fr.c:q933_print().
+ CVE-2017-5202: buffer overflow in print-isoclns.c:clnp_print().
+ CVE-2017-5203: buffer overflow in print-bootp.c:bootp_print().
+ CVE-2017-5204: buffer overflow in print-ip6.c:ip6_print().
+ CVE-2017-5205: buffer overflow in print-isakmp.c:ikev2_e_print().
+ CVE-2017-5341: buffer overflow in print-otv.c:otv_print().
+ CVE-2017-5342: a bug in multiple protocol parsers (Geneve, GRE, NSH,
  OTV, VXLAN and VXLAN GPE) could cause a buffer overflow in
  print-ether.c:ether_print().
+ CVE-2017-5482: buffer overflow in print-fr.c:q933_print().
+ CVE-2017-5483: buffer overflow in print-snmp.c:asn1_parse().
+ CVE-2017-5484: buffer overflow in print-atm.c:sig_print().
+ CVE-2017-5485: buffer overflow in addrtoname.c:lookup_nsap().
+ CVE-2017-5486: buffer overflow in print-isoclns.c:clnp_print().
  * Re-enable all tests and bump build-dep on libpcap0.8-dev to >= 1.8
accordingly.
  * Switch Vcs-Git URL to the https one.
  * Adjust lintian override name about dh 9.

 -- Romain Francoise   Thu, 26 Jan 2017 20:04:11 +0100

Bug#744815: please compile against openssl

[Jamie McClelland]

I see that this is an old bug and would really like to see it resolved. 

I have had mixed success getting apache2 or ngninx to proxy icecast2. It
makes trouble shooting a lot harder.

And, without be able to access icecast2 over https, we get mixed content
warnings when displaying a stream on an https page.

>From my tests, it compiles fine on amd64/jessie - I just needed to
install the libssl-dev package before building.

Bug#805988: aboot : cross-compile aboot-base

[jhcha54008]

Le mercredi 18 janvier à 18h 54mn 10s (+0100), Santiago Vila a écrit :
> On Wed, Jan 18, 2017 at 06:38:44PM +0100, jhcha54008 wrote:
> 
> > I wonder if the following solution would be accepted (see the two patches 
> > attached) : let the source package ship the two binaries (bootlx and 
> > net_aboot.nh). [...]
> 
> Hmm, but this is like removing a hack and creating another one in another 
> place.
> 
> The previous package was a "fake" Arch:all package, so to speak, and now
> we would have a "fake" source package, as it would include binaries.
> 
> We don't want binaries inside source packages (and I think ftpmasters
> would surely agree on this).
> 
> If alpha is not a release architecture, would it really be a problem
> to remove this from testing before the release of stretch while we keep it in
> unstable?
> 
> We could meet the release goal of all packages being buildable
> in our Arch:all autobuilder that way without causing a major headache
> to users of alpha.
> 
> Alternatively, there is also the possibility of asking the Release
> Managers for permission to use stretch-ignore here.
> 
> Thanks.

Hi, 

I was able to build aboot-base on amd64 with the two attached patches.
(dpkg-buildpackage -A -uc -us builds successfully on amd64, i386 and alpha)
I have tested the resulting package to boot a real alpha workstation
(both CDROM- and TFTP-boot).

A build-dependency on gcc-alpha-linux-gnu was added.
Three (possibly different) compilers are needed :
1. a native one to compile helpers which are run during the build
2. one to generate Alpha code to build aboot-base (and possibly aboot)
3. one to generate $DEB_HOST_ARCH code to build aboot-cross
debian/rules sets variables for each.

Cross-building the alpha specific aboot binary package on amd64
requires some manual tweaking :
* libc6.1:alpha is needed when dh_shlibdeps is run, and is currently
(Version: 2.24-5) not co-installable (libc6:amd64 is Version: 2.24-9)
* opensp:alpha is flagged as a missing build-dependency (opensp is 
Arch: any and not Multi-Arch). It is currently uninstallable because
libc6.1:alpha is.
As a workaround, one may enable the alpha architecture
(dpkg --add-architecture alpha), unpack (and not install)
libc6.1:alpha and run dpkg-buildpackage -a alpha -d

I hope it will help to find an acceptable solution !

Regards,
JH Chatenet
Description: Build-depends on opensp instead of sp (deprecated, removed)
 This is the concatenation of two patches from the thread of bug
 #832491 (see the discussion therein). Should close #832491
Forwarded: no
Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832491#5
Origin: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832491#23
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832491
Author: Neil Roeth 
Author: jhcha54008 

diff -Naur aboot-1.0~pre20040408.orig/debian/control aboot-1.0~pre20040408/debian/control
--- aboot-1.0~pre20040408.orig/debian/control
+++ aboot-1.0~pre20040408/debian/control
@@ -1,5 +1,5 @@
 Source: aboot
-Build-Depends: debhelper (>= 9), sp, sgmlspl, docbook-utils
+Build-Depends: debhelper (>= 9), opensp, sgmlspl, docbook-utils
 Build-Depends-Indep: sgmltools-lite
 Section: admin
 Priority: standard
diff -Naur aboot-1.0~pre20040408.orig/doc/man/Makefile aboot-1.0~pre20040408/doc/man/Makefile
--- aboot-1.0~pre20040408.orig/doc/man/Makefile
+++ aboot-1.0~pre20040408/doc/man/Makefile
@@ -32,20 +32,20 @@
 	rm -f aboot.8 aboot.conf.5 abootconf.8 isomarkboot.1 sdisklabel.8 netabootwrap.1 manpage.log manpage.links manpage.refs
 
 aboot.8: aboot.sgml
-	nsgmls aboot.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
+	onsgmls aboot.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
 
 aboot.conf.5: aboot.conf.sgml
-	nsgmls aboot.conf.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
+	onsgmls aboot.conf.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
 
 abootconf.8: abootconf.sgml
-	nsgmls abootconf.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
+	onsgmls abootconf.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
 
 isomarkboot.1: isomarkboot.sgml
-	nsgmls isomarkboot.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
+	onsgmls isomarkboot.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
 
 netabootwrap.1: netabootwrap.sgml
-	nsgmls netabootwrap.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
+	onsgmls netabootwrap.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
 
 sdisklabel.8: sdisklabel.sgml
-	nsgmls sdisklabel.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
+	onsgmls sdisklabel.sgml | sgmlspl sgmlspl-specs/docbook2man-spec.pl
 
diff -Naur aboot-1.0~pre20040408.orig/doc/man/README aboot-1.0~pre20040408/doc/man/README
--- aboot-1.0~pre20040408.orig/doc/man/README	2003-05-30 16:57:34.0 +
+++ aboot-1.0~pre20040408/doc/man/README
@@ -26,7 +26,7 @@
 please contact me.
 
 Technical note:
-To create the nroff version from the SGML sources, nsgml was used like
-nsgmls abootconf.sgml | sgmlspl 

Bug#852707: schleuder: FTBFS : refresh_keys test suite fails

[Daniel Kahn Gillmor]

On Thu 2017-01-26 10:59:21 -0500, Daniel Kahn Gillmor wrote:
> one way to resolve this in a principled fashion without skipping the
> tests is to have the test suite set up a mini-keyserver on the loopback
> (this is really just an http server that responds correctly to the
> specific queries that it might receive) and configure schleuder to use
> it during the testing.

OK, it seems that schleuder was already doing this, which is good :)

however, it was doing it by binding to 127.0.0.1:11371, which is not so
good.  In particular, it failed on a machine that has an instance of sks
already running on it, bound to the same IP address and port (which is
the typical way that one installs sks).

So at the very least, you probably want a Build-Conflicts: sks with the
current setup.  however, i saw the same problem on other hosts too that
don't have sks installed, and i haven't yet been able to diagnose why
those systems failed :(

That said, the best fix would be to launch the mock keyserver on an
OS-selected port (port 0, which means let the OS choose one that's
free), and then automatically write the selected port into the keyserver
line on spec/schleuder.yml before the tests begin.

A third alternative is to use a hard-coded port other than 11371,
possibly coupled with a hard-coded address other than 127.0.0.1.  since
127.0.0.0/8 are all loopback addresses, you could use, for example:

   127.11.3.71:17311


this is not as principled an approach as using port 0, but it's much
more likely to Just Work than the current approach.

Regards,

 --dkg


signature.asc
Description: PGP signature

Bug#813718: mricron FTBFS because fpc check got more strict

[Graham Inggs]

Ping to reset autoremoval counter.

Bug#702051: dovecot-sieve: Can't remove package (dovecot.pem: No such file or directory)

[Apollon Oikonomopoulos]

Control: fixed -1 dovecot/1:2.2.13-6

On Sat, 02 Mar 2013 10:37:55 +0200 Jari Aalto  wrote:
> $ dpkg --purge remove dovecot-sieve
> 
> dpkg: warning: ignoring request to remove remove which isn't installed
> (Reading database ... 371986 files and directories currently installed.)
> Removing dovecot-sieve ...
> Starting IMAP/POP3 mail server: dovecotdoveconf: Fatal: Error in 
> configuration file /etc/dovecot/conf.d/10-ssl.conf line 12: ssl_cert: Can't 
> open file /etc/dovecot/dovecot.pem: No such file or directory
>  failed!
> invoke-rc.d: initscript dovecot, action "start" failed.
> dpkg: error processing dovecot-sieve (--purge):
>  subprocess installed post-removal script returned error exit status 1
> Errors were encountered while processing:
>  dovecot-sieve

> Versions of packages dovecot-sieve depends on:
> ih  dovecot-core  1:2.1.7-7

Note that dovecot-core is half-installed, so the state is inconsistent.  
I'm marking this as fixed in 2.2.13-6, since SSL certificate handling 
was removed in that version and left up to the administrator.

Regards,
Apollon

Bug#852322: geany-plugin-addons: Task window does not get populated

[Enrico Tröger]

This is not particularly a bug.
Tasks are only parsed in comments, e.g.

# TODO: do something

or

/* TODO: do something */

Simple TODO (or other configured keywords) are not parsed.
Especially on documents without a set filetype, nothing will be parsed
at all. This feature had been implemented in
https://github.com/geany/geany-plugins/pull/449.

If you want this to be configurable, please open a issue at
https://github.com/geany/geany-plugins/issues (or ideally even with a
patch as pull request).

Thanks.

Regards,
Enrico



signature.asc
Description: OpenPGP digital signature

Bug#780477: dovecot-core: purging removes symlink targets rather than symlinks

[Apollon Oikonomopoulos]

On 21:59 Thu 26 Jan , Adam Borowski wrote:
> On Thu, Jan 26, 2017 at 10:41:21PM +0200, Apollon Oikonomopoulos wrote:
> > Control: tags -1 unreproducible moreinfo
> > Control: fixed -1 dovecot/1:2.2.13-6
> 
> > On Sat, 14 Mar 2015 17:28:31 +0100 Adam Borowski  
> > wrote:
> > > If dovecot is being purged, and ssl certificates (both the private and
> > > public parts) are symlinks, the symlink targets will be deleted instead
> > > of dovecot.pem.
> > 
> > I'm unable to reproduce this with wheezy's version (1:2.1.7-7+deb7u1), 
> > and (looking at the maintainer scripts) I can't figure out how this 
> > could happen.
> 
> What's "wheezy"?  My memory doesn't last that long. :)

Indeed, I had some difficulty mapping +deb7u1 to a name as well.

> I've already upgraded my production machines to stretch (after extensive
> testing shown no regressions, which couldn't have been said about jessie);
> I somehow don't feel like attempting to reproduce that bug on a release
> that's long since out of mainstream support.
> 
> > Since SSL certificate management was dropped in 2.2.13-6, I'm marking it 
> > as fixed since that version.
> 
> As it's fixed in jessie, I guess that closing this indeed is a better
> prioritising of our time.

Agreed. I'm just removing some cruft from dovecot's buglist :)

Cheers,
Apollon

Bug#852742: python-oslo.middleware: CVE-2017-2592: CatchErrors leaks sensitive values in oslo.middleware

[Salvatore Bonaccorso]

Source: python-oslo.middleware
Version: 3.19.0-2
Severity: grave
Tags: security patch upstream
Forwarded: https://launchpad.net/bugs/1628031

Hi,

the following vulnerability was published for python-oslo.middleware.

CVE-2017-2592[0]:
CatchErrors leaks sensitive values in oslo.middleware

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-2017-2592
[1] https://launchpad.net/bugs/1628031

Regards,
Salvatore

Bug#852743: dialign FTCBFS: uses the build architecture compiler

[Helmut Grohne]

Source: dialign
Version: 2.2.1-8
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

dialign fails to cross build from source, because it uses the build
architecture compiler. Ultimately dh_strip fails operating on build
architecture ELF objects. Fortunately, dh_auto_build knows how to pass
cross compilers for the makefile buildsystem. Indirecting the explicit
$(MAKE) invocation through dh_auto_build thus fixes cross compilation.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru dialign-2.2.1/debian/changelog 
dialign-2.2.1/debian/changelog
--- dialign-2.2.1/debian/changelog  2016-07-19 07:55:08.0 +0200
+++ dialign-2.2.1/debian/changelog  2017-01-26 22:07:54.0 +0100
@@ -1,3 +1,11 @@
+dialign (2.2.1-8.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross compilers
+Closes: #-1
+
+ -- Helmut Grohne   Thu, 26 Jan 2017 22:07:54 +0100
+
 dialign (2.2.1-8) unstable; urgency=medium
 
   * Team upload
diff --minimal -Nru dialign-2.2.1/debian/rules dialign-2.2.1/debian/rules
--- dialign-2.2.1/debian/rules  2016-07-19 07:55:08.0 +0200
+++ dialign-2.2.1/debian/rules  2017-01-26 22:07:51.0 +0100
@@ -11,4 +11,4 @@
 
 override_dh_auto_build:
## CFLAGS = -c -I$ -DCONS -O2
-   $(MAKE) -C src
+   dh_auto_build --sourcedirectory=src

Bug#697758: dovecot-core: "starting up" log message should have the same priority "stop" does

[Apollon Oikonomopoulos]

Control: tags -1 wontfix

Hi,

On Wed, 09 Jan 2013 05:46:36 -0700 Teodor  wrote:
> I've noticed these entries in syslog (mail.info):
> | Jan  9 04:33:15 palomino dovecot: master: Warning: Killed with
> |   signal 15 (by pid=1037 uid=0 code=kill)
> | Jan 09 04:33:15 master: Info: Dovecot v2.1.7 starting up (core
> |   dumps disabled)
> 
> I've configured info (and debug) messages to not log via syslog:
> #log_path = syslog
> info_log_path = /var/log/mail.info

According to the source code, shutdown is logged with a Warning level, 
while startup is logged with an info level. There's nothing wrong with 
that and both messages will appear in /var/log/mail.log (but not 
mail.info or mail.warn). I don't feel there is something to be fixed 
here, so I'm tagging this as wontfix. Please remove the tag if you 
disagree.

Regards,
Apollon

Bug#852528: liferea: crashes when the database isn't readable instead of notifying the user

[Paul Gevers]

Control: forwarded -1 https://github.com/lwindolf/liferea/issues/474

Hi Paul,

On 25-01-17 08:14, Paul Wise wrote:
> liferea crashes when the database isn't readable and does not attempt
> to fix the issue nor notify the user about the issue. This sort of
> thing can happen accidentally when restoring backups or running cleanup
> tools so it would be nice to handle it more elegantly.

Thanks for your report, I have forwarded this issue upstream.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#844376: [bts-link] source package src:caja-actions

[Mike Gabriel]

Control: tags -1 patch

On Thu Jan 26 18:31:41 2017 GMT+0100, bts-link-upstr...@lists.alioth.debian.org 
wrote:
 
> # remote status report for #844376 (http://bugs.debian.org/844376)
> # Bug title: caja-actions: Uses deprecated libunique3
> #  * https://github.com/raveit65/caja-actions/issues/13

Upstream has a patch for the libunique -> GtkApplication transition. Tagging 
this bug accordingly.

Mike

-- 
Sent from my Faeirphone (running Sailfish OS)...

Bug#780477: dovecot-core: purging removes symlink targets rather than symlinks

[Adam Borowski]

On Thu, Jan 26, 2017 at 10:41:21PM +0200, Apollon Oikonomopoulos wrote:
> Control: tags -1 unreproducible moreinfo
> Control: fixed -1 dovecot/1:2.2.13-6

> On Sat, 14 Mar 2015 17:28:31 +0100 Adam Borowski  wrote:
> > If dovecot is being purged, and ssl certificates (both the private and
> > public parts) are symlinks, the symlink targets will be deleted instead
> > of dovecot.pem.
> 
> I'm unable to reproduce this with wheezy's version (1:2.1.7-7+deb7u1), 
> and (looking at the maintainer scripts) I can't figure out how this 
> could happen.

What's "wheezy"?  My memory doesn't last that long. :)
I've already upgraded my production machines to stretch (after extensive
testing shown no regressions, which couldn't have been said about jessie);
I somehow don't feel like attempting to reproduce that bug on a release
that's long since out of mainstream support.

> Since SSL certificate management was dropped in 2.2.13-6, I'm marking it 
> as fixed since that version.

As it's fixed in jessie, I guess that closing this indeed is a better
prioritising of our time.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11