Bug#851821: linux: Please enable CONFIG_TOUCHSCREEN_GOODIX

2017-01-21 Thread Roger Shimizu
Control: tag -1 +pending

On Thu, Jan 19, 2017 at 12:40 PM, russm-debian-bugs
 wrote:
> Source: linux
> Version: 4.9.2-2
> Severity: wishlist
> Tags: patch
>
> Dear Maintainer,
>
> Please enable CONFIG_TOUCHSCREEN_GOODIX, for use on devices that have
> this touchscreen hardware installed.

Added, and will be applied on next debian kernel release.
Thanks for your contribution!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1



Bug#851678: RM: openchange -- RoQA; incompatible with updated samba

2017-01-21 Thread Paul Wise
Control: retitle -1 jessie-pu: package openchange/1:2.2-5+deb8u1
Control: release.debian@packages.debian.org
Control: usertags -1 - rm + pu

On Wed, 18 Jan 2017 07:21:49 +0800 Paul Wise wrote:

> This looks like the API issue in openchangeproxy mentioned in the
> samba changelog from the build log messages you posted.
> 
> This is the openchange bug and patch for this specific FTBFS:
> 
> https://github.com/openchange/openchange/issues/249
> https://github.com/openchange/openchange/commit/73a49af50bf0a496cfe62f49e60a662f1d04d685.patch

I've tested that this fixes the FTBFS in openchange.

I'm unable to test that openchangeproxy still works but the patch looks
like a fairly straight forward update to the newer samba APIs.

The rest of the binary packages still work fine in my tests. 

I've attached a patch for a pu to the openchange package in jessie.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
diff -Nru openchange-2.2/debian/changelog openchange-2.2/debian/changelog
--- openchange-2.2/debian/changelog	2014-09-22 07:00:28.0 +0800
+++ openchange-2.2/debian/changelog	2017-01-21 15:23:28.0 +0800
@@ -1,3 +1,9 @@
+openchange (1:2.2-5+deb8u1) jessie; urgency=medium
+
+  * Include upstream patch to fix FTBFS with samba 4.2
+
+ -- Paul Wise   Sat, 21 Jan 2017 15:23:28 +0800
+
 openchange (1:2.2-5) unstable; urgency=medium
 
   * Disable mysql tests. Closes: #761559
diff -Nru openchange-2.2/debian/patches/73a49af50bf0a496cfe62f49e60a662f1d04d685.patch openchange-2.2/debian/patches/73a49af50bf0a496cfe62f49e60a662f1d04d685.patch
--- openchange-2.2/debian/patches/73a49af50bf0a496cfe62f49e60a662f1d04d685.patch	1970-01-01 08:00:00.0 +0800
+++ openchange-2.2/debian/patches/73a49af50bf0a496cfe62f49e60a662f1d04d685.patch	2017-01-21 15:20:31.0 +0800
@@ -0,0 +1,45 @@
+From 73a49af50bf0a496cfe62f49e60a662f1d04d685 Mon Sep 17 00:00:00 2001
+From: Julien Kerihuel 
+Date: Thu, 20 Mar 2014 02:19:53 +0100
+Subject: [PATCH] Fix compilation with samba release > 4.1.4 - use new API
+ functions introduced to access opaque assoc_group_id
+
+---
+ mapiproxy/dcesrv_mapiproxy.c | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/mapiproxy/dcesrv_mapiproxy.c b/mapiproxy/dcesrv_mapiproxy.c
+index b4d39e7..33a69a6 100644
+--- a/mapiproxy/dcesrv_mapiproxy.c
 b/mapiproxy/dcesrv_mapiproxy.c
+@@ -132,10 +132,10 @@ static NTSTATUS mapiproxy_op_connect(struct dcesrv_call_state *dce_call,
+ 		
+ 		switch (dce_call->pkt.ptype) {
+ 		case DCERPC_PKT_BIND:
+-			b->assoc_group_id = dce_call->pkt.u.bind.assoc_group_id;
++			status = dcerpc_binding_set_assoc_group_id(b, dce_call->pkt.u.bind.assoc_group_id);
+ 			break;
+ 		case DCERPC_PKT_ALTER:
+-			b->assoc_group_id = dce_call->pkt.u.alter.assoc_group_id;
++			status = dcerpc_binding_set_assoc_group_id(b, dce_call->pkt.u.alter.assoc_group_id);
+ 			break;
+ 		default:
+ 			break;
+@@ -152,7 +152,7 @@ static NTSTATUS mapiproxy_op_connect(struct dcesrv_call_state *dce_call,
+ 		if (!NT_STATUS_IS_OK(status)) {
+ 			return status;
+ 		}
+-		dce_call->context->assoc_group->id = private->c_pipe->assoc_group_id;
++		dce_call->context->assoc_group->id = dcerpc_binding_get_assoc_group_id(private->c_pipe->binding);
+ 		
+ 	} else {
+ 		status = dcerpc_pipe_connect(dce_call->context,
+@@ -167,7 +167,7 @@ static NTSTATUS mapiproxy_op_connect(struct dcesrv_call_state *dce_call,
+ 		if (!NT_STATUS_IS_OK(status)) {
+ 			return status;
+ 		}
+-		dce_call->context->assoc_group->id = private->c_pipe->assoc_group_id;
++		dce_call->context->assoc_group->id = dcerpc_binding_get_assoc_group_id(private->c_pipe->binding);
+ 	}
+ 
+ 	private->connected = true;
diff -Nru openchange-2.2/debian/patches/series openchange-2.2/debian/patches/series
--- openchange-2.2/debian/patches/series	2014-09-22 07:00:17.0 +0800
+++ openchange-2.2/debian/patches/series	2017-01-21 15:23:28.0 +0800
@@ -1 +1,2 @@
 01_disable_mysql_tests
+73a49af50bf0a496cfe62f49e60a662f1d04d685.patch


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


Bug#851963: linux: enable SENSORS_ADM1031

2017-01-21 Thread Roger Shimizu
Control: tag -1 +moreinfo

On Fri, Jan 20, 2017 at 9:17 PM, James Cowgill  wrote:
> Source: linux
> Version: 4.9.2-2
> Severity: wishlist
>
> Hi,
>
> Please can you enable CONFIG_SENSORS_ADM1031 as a module.
>
> I have a Cavium Octeon board which needs this driver to be able to read
> the CPU temperature / fan sensors.

I see this module already exists in the kernel you're using.
Can you help to confirm?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1



Bug#852057: ITP: puppet-module-puppetlabs-aws -- manages aws resources to build out cloud

2017-01-21 Thread Gustavo Soares de Lima
Package: wnpp
Severity: wishlist
Owner: Gustavo Soares de Lima 

* Package name : puppet-module-puppetlabs-aws
Version : 1.4.0
Upstream Author : Puppet Labs, Inc 
* URL : https://github.com/puppetlabs/puppetlabs-aws
* License : apache
Description : This module manages AWS resources to build out cloud

AWS exposes a powerful API for creating and managing its infrastructure as
a
 Service platform. The module allows you to drive that API using Puppet
code.
 .
 With this module this allow you to create new EC2 instances from Puppet.


Bug#852056: zeal: integration with doc-base

2017-01-21 Thread Ritesh Raj Sarraf
Package: zeal
Version: 0.3.1-1
Severity: wishlist
File: zeal

Hello,

Thanks for packaging zeal. I was wonder if zeal could be used/integrated
with Debian's doc-base system, or the equivalent ?

Would it be possible to make zeal use locally installed docs
(/usr/share/doc/ ) too ?


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

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



Bug#852032: libjavascriptcoregtk-4.0-18: Segmentation fault in LLIntAssembly.h:2610 on powerpc64

2017-01-21 Thread Emilio Pozuelo Monfort
On 20/01/17 23:29, Andrew Shadura wrote:
> On 20/01/17 23:28, Andrew Shadura wrote:
>> On 20/01/17 22:24, Andrew Shadura wrote:
>>> To reproduce, I built seed-webkit2 on ppc64, installed 
>>> libjavascriptcoregtk-4.0-18-dbgsym and ran in the directory with unpacked 
>>> package source:
>>>
>>> $ export LD_LIBRARY_PATH=$(pwd)/libseed/.libs:
>>> $ cd doc/modules/readline
>>> $ gdb ../../../src/seed
>>
>> Obviously, I meant this:
>>
>> $ gdb ../../../src/.libs/seed
>>
>>> (gdb) set args ../../../doc/modules/make-functions.js 
>>> ../../../doc/modules/readline/readline.js
>>> (gdb) run
> 
> By the way, nearly exactly the same error happens on mips:

Huh? mips built fine:

https://buildd.debian.org/status/package.php?p=webkit2gtk&suite=sid

Can you explain what you mean?

Emilio



Bug#852058: Coreutils corrupts its own error messages with "smart" quotes

2017-01-21 Thread Alain Knaff
Package: coreutils
Version: 8.23-4

The version of coreutils included in Debian generates error messages
containing "smart" quotes. According to coreutils developers, the issue
is fixed in coreutils 8.25 in order to make it easier to cut and paste
file names from diagnostics into shells.

Please consider including that new version into stable Debian, or at
least spot-backporting the fix.

Thanks,

Alain



Bug#427164: patch proposed for #427164

2017-01-21 Thread Diego Roversi
Hi,

  I've written this simple patch that fix the problem:

--- fretsonfire-1.3.110.dfsg2/src/Song.py   2017-01-21 09:06:24.0 
+0100
+++ fretsonfire-1.3.110.dfsg2.patched/src/Song.py   2017-01-21 
09:22:39.096991225 +0100
@@ -857,6 +857,8 @@
   libraryRoots = []
   
   for songRoot in songRoots:
+if not os.path.isdir(songRoot):
+  continue
 for libraryRoot in os.listdir(songRoot):
   libraryRoot = os.path.join(songRoot, libraryRoot)
   if not os.path.isdir(libraryRoot):
@@ -877,6 +879,8 @@
   songRoots = [engine.resource.fileName(library), 
engine.resource.fileName(library, writable = True)]
   names = []
   for songRoot in songRoots:
+if not os.path.isdir(songRoot):
+  continue
 for name in os.listdir(songRoot):
   if not os.path.isfile(os.path.join(songRoot, name, "song.ini")) or 
name.startswith("."):
 continue


-- 
Diego Roversi 



Bug#852059: opendnssec-signer: installation hangs on invoke-rc.d due to script name being to long

2017-01-21 Thread Jan Huijsmans
Package: opendnssec-signer
Version: 1:2.0.3-5
Severity: important

Dear Maintainer,

During installation of opendnssec the installation of this package
and opendnssec-enforcer hang on command:

invoke-rc.d  start

Each configuration round teh script has to be killed to end the
wait. Don't know of this should be reported here, as the scriptname is
longer then 15 characters, or with the maintainers of invoke-rc.d or the
start-stop-daemon function.

The scripts will never start this way. (at least on this system)

I haven't been able to fix this, and as this is a new installation, no
comparisons with older versions.

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_GB.ISO-8859-15, LC_CTYPE=en_GB.ISO-8859-15 (charmap=ISO-8859-15)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages opendnssec-signer depends on:
ii  init-system-helpers  1.46
ii  libc62.24-8
ii  libldns2 1.7.0-1
ii  libssl1.11.1.0c-2
ii  libxml2  2.9.4+dfsg1-2.1
ii  opendnssec-common1:2.0.3-5

Versions of packages opendnssec-signer recommends:
iu  opendnssec   1:2.0.3-5
ih  opendnssec-enforcer  1:2.0.3-5
pn  softhsm2 

opendnssec-signer suggests no packages.

-- no debconf information



Bug#852061: grub2: [INTL:ko] updated Korean debconf translation

2017-01-21 Thread Changwoo Ryu
Package: grub2
Version: 2.02~beta3-4
Severity: wishlist
Tags: patch l10n

Please find the updated Korean debconf translation (debian/po/ko.po)
for grub2 2.02~beta3-4 attached.

# Changwoo Ryu , 2014, 2017.
#
msgid ""
msgstr ""
"Project-Id-Version: grub_debian\n"
"Report-Msgid-Bugs-To: gr...@packages.debian.org\n"
"POT-Creation-Date: 2017-01-20 00:29+\n"
"PO-Revision-Date: 2017-01-21 17:41+0900\n"
"Last-Translator: Changwoo Ryu \n"
"Language-Team: Korean \n"
"Language: ko\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "Chainload from menu.lst?"
msgstr "menu.lst에서 단계별로 읽어들이시겠습니까?"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub."
msgstr ""
"GRUB 업그레이드 스크립트에서 /boot/grub 안의 GRUB 과거 버전 설정을 발견했습니"
"다."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"In order to replace the Legacy version of GRUB in your system, it is "
"recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image "
"from your existing GRUB Legacy setup. This step can be automatically "
"performed now."
msgstr ""
"시스템의 GRUB 구버전을 현재 GRUB 2로 바꾸려면, /boot/grub/menu.lst 파일을 조"
"정해 기존 GRUB 과거 버전 설정에서 GRUB 2 부팅 이미지를 읽어들이는 방법을 추천"
"합니다. 이 단계는 자동으로 수행할 수 있습니다."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"It's recommended that you accept chainloading GRUB 2 from menu.lst, and "
"verify that the new GRUB 2 setup works before it is written to the MBR "
"(Master Boot Record)."
msgstr ""
"먼저 menu.lst에서 단계별로 GRUB 2를 읽어들이게 하고, 그 다음에 GRUB 2 설정이 "
"동작하는지 확인한 다음 MBR(마스터 부트 레코드)에 GRUB 2를 설치하는 걸 추천합"
"니다."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"Whatever your decision, you can replace the old MBR image with GRUB 2 later "
"by issuing the following command as root:"
msgstr ""
"어떻게 선택하든, 나중에 root로 다음 명령을 실행하면 과거 MBR 이미지를 GRUB 2 "
"이미지로 바꿀 수 있습니다."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid "GRUB install devices:"
msgstr "GRUB 설치 장치:"

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"The grub-pc package is being upgraded. This menu allows you to select which "
"devices you'd like grub-install to be automatically run for, if any."
msgstr ""
"grub-pc 패키지를 업그레이드하는 중입니다. 이 메뉴에서 (실행할 장치가 있다면) "
"어떤 장치에 대해 grub-install을 자동으로 실행할지 설정합니다."

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"Running grub-install automatically is recommended in most situations, to "
"prevent the installed GRUB core image from getting out of sync with GRUB "
"modules or grub.cfg."
msgstr ""
"대부분의 상황에서는 grub-install 자동 실행을 추천합니다. 그래야 설치한 GRUB "
"이미지가 GRUB 모듈이나 grub.cfg 파일과 어긋나지 않습니다."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"If you're unsure which drive is designated as boot drive by your BIOS, it is "
"often a good idea to install GRUB to all of them."
msgstr ""
"어떤 드라이브를 BIOS에서 사용할 부팅 드라이브로 설정할지 잘 모르겠다면, GRUB"
"을 모든 드라이버에 설치하는 것도 좋은 방법입니다."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"Note: it is possible to install GRUB to partition boot records as well, and "
"some appropriate partitions are offered here. However, this forces GRUB to "
"use the blocklist mechanism, which makes it less reliable, and therefore is "
"not recommended."
msgstr ""
"주의: GRUB을 파티션 부트 레코드에 설치할 수도 있고, 해당 파티션이 여기 표시됩"
"니다. 하지만 파티션 부트 레코드에 설치하면 GRUB에서 덜 안정적인 블럭리스트 방"
"식을 사용하게 되므로 추천하지 않습니다."

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:4001
msgid ""
"The GRUB boot loader was previously installed to a disk that is no longer "
"present, or whose unique identifier has changed for some reason. It is "
"important to make sure that the installed GRUB core image stays in sync with "
"GRUB modules and grub.cfg. Please check again to make sure that GRUB is "
"written to the appropriate boot devices."
msgstr ""
"이전에 GRUB 부트로더를 설치했던 디스크가 이제 컴퓨터에 없거나, 어떤 이유에서"
"든 고유 아이디가 바뀌었습니다. GRUB 코어 이미지가 GRUB 모듈 및 grub.cfg와 동"
"기화하는 게 중요합니다. GRUB이 올바른 부팅 장치에 설치되도록 다시 확인하십시"
"오."

#. Type: text
#. Description
#. Disk sizes are in decimal megabytes, to match how disk manufacturers
#. usually describe them.
#: ../grub-pc.templates.in:5001
msgid "${DEVICE} (${SIZE} MB; ${MODEL})"
msgstr "${DEVICE} (${SIZE} MB, ${MODEL})"

#. Type: text
#. Description
#. The "-" is used to indicate indentation. Leading spaces may not work.
#: ../grub-pc.templates.in:6001
msgid "- ${DEVICE} (${SIZE} MB; ${PATH})"
msgstr "- ${DEVICE} (${SIZE} MB, ${PATH})"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:7001
msgid "Writing GRUB to boot device failed - continue?"
m

Bug#852060: font_manager.py: error getting fontconfig fonts

2017-01-21 Thread cataclop
Package: python3-matplotlib
Version: 2.0.0-1
Severity: normal

Dear Maintainer,

While using matplotlib to list installed files in a python3 script:
font_manager.get_fontconfig_fonts(),
the list I get has only one element, that contains all fonts names concatenated.

I've tried replacing
out = subprocess.check_output([str('fc-list'), '--format=%{file}'])
on line 284 by:
out = subprocess.check_output([str('fc-list'), '--format=%{file}\\n'])
and that works.


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

Kernel: Linux 4.8.0-34-generic (SMP w/8 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=UTF-8) (ignored: LC_ALL set to C.UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages python3-matplotlib depends on:
ii  libc6   2.24-9
ii  libfreetype62.6.3-3+b1
ii  libgcc1 1:6.3.0-2
ii  libjs-jquery3.1.1-2
ii  libjs-jquery-ui 1.12.1+dfsg-3
ii  libpng16-16 1.6.28-1
ii  libstdc++6  6.3.0-2
ii  python-matplotlib-data  2.0.0-1
ii  python3 3.5.1-4
ii  python3-cycler  0.10.0-1
ii  python3-dateutil2.5.3-2
ii  python3-numpy [python3-numpy-abi9]  1:1.12.0-1
ii  python3-pyparsing   2.1.10+dfsg1-1
ii  python3-six 1.10.0-3
ii  python3-tz  2016.7-0.2
pn  python3:any 

Versions of packages python3-matplotlib recommends:
ii  python3-pil  4.0.0-3
ii  python3-tk   3.5.1-1

Versions of packages python3-matplotlib suggests:
pn  dvipng 
pn  ffmpeg 
ii  ghostscript9.20~dfsg-1
pn  gir1.2-gtk-3.0 
pn  inkscape   
pn  ipython3   
pn  librsvg2-common
pn  python-matplotlib-doc  
pn  python3-cairocffi  
pn  python3-gi 
pn  python3-gi-cairo   
pn  python3-gobject
pn  python3-nose   
pn  python3-pyqt4  
pn  python3-scipy  
pn  python3-sip
pn  python3-tornado
ii  texlive-extra-utils2016.20161130-1
ii  texlive-latex-extra2016.20161130-1
pn  ttf-staypuft   

-- no debconf information



Bug#852062: RFS: puppet-module-puppetlabs-aws/1.4.0-1 [ITP]

2017-01-21 Thread Gustavo Soares de Lima
Package: sponsorship-requests
  Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "puppet-module-puppetlabs-aws"

 * Package name: puppet-module-puppetlabs-aws
   Version : 1.4.0-1
   Upstream Author : Puppet Labs, Inc 
 * URL : https://github.com/puppetlabs/puppetlabs-aws
 * License : apache
   Section : admin

  It builds those binary packages:

puppet-module-puppetlabs-aws - This module manages AWS resources
to build out cloud

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/puppet-module-puppetlabs-aws


  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/p/puppet-module-puppetlabs-aws/puppet-module-puppetlabs-aws_1.4.0-1.dsc

  More information about hello can be obtained from https://www.example.com.



  Regards,
   Gustavo Soares de Lima


Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

2017-01-21 Thread Sylvestre Ledru
Hello,

First, Rebecca, many thanks for the patch :)


Le 18/01/2017 à 19:54, Lisandro Damián Nicanor Pérez Meyer a écrit :
> On martes, 17 de enero de 2017 22:21:51 ART Rebecca N. Palmer wrote:
> [snip] 
>> This suggests the fix (warning: untested and not my area of expertise -
>> and if it is using that line, why is there no -Wl,--no-whole-archive in
>> the build log?):
> This part I don't know.
>
>> --- a/tools/llvm-shlib/CMakeLists.txt
>> +++ b/tools/llvm-shlib/CMakeLists.txt
>> @@ -42,7 +42,7 @@
>>   list(REMOVE_DUPLICATES LIB_NAMES)
>>   if("${CMAKE_SYSTEM_NAME}" STREQUAL "Linux" OR "${CMAKE_SYSTEM_NAME}"
>> STREQUAL "GNU" OR "${CMAKE_SYSTEM_NAME}" STREQUAL "kFreeBSD") # FIXME:
>> It should be "GNU ld for elf"
>> # GNU ld doesn't resolve symbols in the version script.
>> -  set(LIB_NAMES -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
>> +  set(LIB_NAMES
>> -Wl,--version-script,../../../tools/llvm-shlib/simple_version_script.map
>> -Wl,--whole-archive ${LIB_NAMES} -Wl,--no-whole-archive)
>>   elseif("${CMAKE_SYSTEM_NAME}" STREQUAL "Darwin")
>> set(LIB_NAMES -Wl,-all_load ${LIB_NAMES})
>>   endif()
>> --- a/dev/null
>> +++ b/simple_version_script.map
>> @@ -0,0 +1,1 @@
>> +LLVM_3.9 { global: *; };
> Probably the "../../../tools" path should be replaced by $
> {CMAKE_CURRENT_SOURCE_DIR}/tools


I think that we will have to replicate the change in
tools/llvm-shlib/CMakeLists.txt
for most (every?) library that llvm-toolchain ships as a matter of
consistency.

I feel a bit uncomfortable to implement the ELF symbol versions that
late in the cycle.
Especially for two reasons: I don't know enough that stuff to evaluate
and fix side effects
it has always been like that without causing too much issue.

Can we lower the priority and I will fix that for the next stable release?

Cheers,
S




signature.asc
Description: OpenPGP digital signature


Bug#851963: linux: enable SENSORS_ADM1031

2017-01-21 Thread James Cowgill
Hi,

On 21/01/17 08:05, Roger Shimizu wrote:
> Control: tag -1 +moreinfo
> 
> On Fri, Jan 20, 2017 at 9:17 PM, James Cowgill  wrote:
>> Source: linux
>> Version: 4.9.2-2
>> Severity: wishlist
>>
>> Hi,
>>
>> Please can you enable CONFIG_SENSORS_ADM1031 as a module.
>>
>> I have a Cavium Octeon board which needs this driver to be able to read
>> the CPU temperature / fan sensors.
> 
> I see this module already exists in the kernel you're using.
> Can you help to confirm?

I'm pretty certain it's not enabled. It is already enabled on x86 however.

James



signature.asc
Description: OpenPGP digital signature


Bug#851678: jessie-pu: package openchange/1:2.2-5+deb8u1

2017-01-21 Thread Andreas Beckmann
On 2017-01-21 09:03, Paul Wise wrote:
> Control: retitle -1 jessie-pu: package openchange/1:2.2-5+deb8u1

Thanks for taking over!

>> https://github.com/openchange/openchange/issues/249
>> https://github.com/openchange/openchange/commit/73a49af50bf0a496cfe62f49e60a662f1d04d685.patch
> 
> I've tested that this fixes the FTBFS in openchange.
> 
> I'm unable to test that openchangeproxy still works but the patch looks
> like a fairly straight forward update to the newer samba APIs.

But openchangeproxy will still not be installable in jessie since
samba-libs has

Conflicts: openchangeproxy (<< 1:2.2-6)

Lowering this to (<< 1:2.2-5+deb8u1) would require another samba upload
to jessie (or piggybacking it on the next security upload).

Since noone has complained about this uninstallability so far in a
production environment, maybe the package is not in wide use ... and
dropping it might be another option.


Andreas



Bug#848368: llvm-toolchain-3.9: Please add ELF symbols versions to the libraries

2017-01-21 Thread Julien Cristau
On Sat, Jan 21, 2017 at 09:52:58 +0100, Sylvestre Ledru wrote:

> I feel a bit uncomfortable to implement the ELF symbol versions that
> late in the cycle.
> Especially for two reasons: I don't know enough that stuff to evaluate
> and fix side effects
> it has always been like that without causing too much issue.
> 
> Can we lower the priority and I will fix that for the next stable release?
> 
I think that's a bad idea.

Cheers,
Julien



Bug#852063: consolekit: cannot git push

2017-01-21 Thread Andrea Zagli
Package: consolekit
Version: 0.4.6-5
Severity: normal

i cannot anymore "git push" from a client to a server (it worked yesterday); i
can access in ssh

that's what i found in syslog


Jan 21 10:08:57 deimos systemd[1]: Started Session 9 of user andreaz.
Jan 21 10:08:57 deimos udev-acl.ck[4446]: g_slice_set_config: assertion
'sys_page_size == 0' failed
Jan 21 10:08:57 deimos console-kit-daemon[2635]: missing action


and after ctrl+c


Jan 21 10:09:25 deimos udev-acl.ck[4641]: g_slice_set_config: assertion
'sys_page_size == 0' failed
Jan 21 10:09:25 deimos console-kit-daemon[2635]: missing action
Jan 21 10:09:25 deimos console-kit-daemon[2635]: console-kit-daemon[2635]:
GLib-CRITICAL: Source ID 138 was not found when attempting to remove it
Jan 21 10:09:25 deimos console-kit-daemon[2635]: GLib-CRITICAL: Source ID 138
was not found when attempting to remove it



-- 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=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages consolekit depends on:
ii  dbus   1.10.14-1
ii  libacl12.2.52-3
ii  libc6  2.24-9
ii  libck-connector0   0.4.6-5
ii  libdbus-1-31.10.14-1
ii  libdbus-glib-1-2   0.108-2
ii  libglib2.0-0   2.50.2-2
ii  libpolkit-gobject-1-0  0.105-17
ii  libudev1   232-12
ii  libx11-6   2:1.6.4-2
ii  zlib1g 1:1.2.8.dfsg-4

Versions of packages consolekit recommends:
ii  libpam-ck-connector  0.4.6-5

consolekit suggests no packages.

-- no debconf information



Bug#852064: grub2: [INTL:ru] Russian debconf templates translation update

2017-01-21 Thread Yuri Kozlov
Package: grub2
Version: 2.02~beta3-4
Severity: wishlist
Tags: l10n patch

Dear Maintainer,

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

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

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

Russian debconf templates translation update is attached.

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

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


ru.po.gz
Description: application/gzip


Bug#851513: Build fails with Linux kernel 4.9.0

2017-01-21 Thread Benjamin Eikel
Thanks, applying the patches onto the current Git master of zfs-linux and 
building the modules against Linux kernel 4.9.0-1-amd64 works for me.

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


Bug#851678: jessie-pu: package openchange/1:2.2-5+deb8u1

2017-01-21 Thread Paul Wise
Control: retitle -1 jessie-pu: package openchange/1:2.2-6+deb8u1

On Sat, 2017-01-21 at 10:13 +0100, Andreas Beckmann wrote:

> But openchangeproxy will still not be installable in jessie since
> samba-libs has
> 
> Conflicts: openchangeproxy (<< 1:2.2-6)

I forgot about that. Since 1:2.2-6 was once in Debian, it would be
probably best to use 1:2.2-6~deb8u1 but that doesn't match what samba
used in the Breaks, so it will have to be 1:2.2-6+deb8u1, which should
be fine since 1:2.2-7 was the latest version in Debian stretch.
I'll change the version number and upload once I have an ack.

http://snapshot.debian.org/package/openchange/

> Lowering this to (<< 1:2.2-5+deb8u1) would require another samba upload
> to jessie (or piggybacking it on the next security upload).

I think that isn't a useful use of samba maintainer/buildd time :)

> Since noone has complained about this uninstallability so far in a
> production environment, maybe the package is not in wide use ... and
> dropping it might be another option.

Ack, though the version change I mention above should be fine though.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#828915: dracut: on package setup, complains it cannot copy console-setup-dir/bin

2017-01-21 Thread intrigeri
Control: found -1 044+223-1
Control: tag -1 + patch

Hi,

Thomas Lange:
>> On Tue, 28 Jun 2016 23:52:13 +0200, Matteo Settenvini 
>>  said:

> > cp: cannot overwrite non-directory 
> '/var/tmp/dracut.NWphxq/initramfs/bin' with directory 
> '/var/lib/dracut/console-setup-dir/bin

> Please check if you have installed the package console-setup or
> console-setup-mini which include setupcon. It would be nice if you
> could provide verbose or debug output of the build process of the
> initrd. 

I can reproduce this, with console-setup 1.158 installed:

  /usr/lib/dracut/modules.d/09console-setup/module-setup.sh@26(install): cp -a 
/var/lib/dracut/console-setup-dir/bin /var/lib/dracut/console-setup-dir/etc 
/var/tmp/dracut.00KQcT/initramfs/
  cp: cannot overwrite non-directory '/var/tmp/dracut.00KQcT/initramfs/bin' 
with directory '/var/lib/dracut/console-setup-dir/bin'

I believe that's caused by 09console-setup/module-setup.sh not
supporting merged-/usr systems correctly, i.e. it assumes that
$initdir/bin is a directory. Here's what it attempts to do:

  cp -a $vardir/console-setup-dir/* $initdir/

… which fails on merged-/usr systems with the error message reported
by Matteo, because in that case, $initdir/bin is a symlink to
$initdir/usr/bin.

This patch fixes the problem for me:

--- /usr/lib/dracut/modules.d/09console-setup/module-setup.sh.orig  
2017-01-21 10:14:02.876715175 +0100
+++ /usr/lib/dracut/modules.d/09console-setup/module-setup.sh   2017-01-21 
10:14:32.979885559 +0100
@@ -23,7 +23,8 @@
 local vardir
 vardir=/var/lib/dracut
 
-cp -a $vardir/console-setup-dir/* $initdir/
+cp -a $vardir/console-setup-dir/bin/* $initdir/bin/
+cp -a $vardir/console-setup-dir/etc/* $initdir/etc/
 # gzip is workaround a bug in current console-setup
 inst_multiple gzip $(cat $vardir/console-setup-files)
 inst ${moddir}/console-setup.sh /lib/udev/console-setup


I don't know, however, whether there are cases when there could be
other things than 'bin' and 'etc' in $vardir/console-setup-dir/.
If that would be the case, then my simplistic patch would not be
enough, and a more subtle method (e.g. using rsync) would be needed.

Cheers,
-- 
intrigeri



Bug#851899: Can't fetch source from archive if "Package-List" is the last line of the apt output

2017-01-21 Thread Martin Pitt
Control: tag -1 pending

Hello Iain,

Iain Lane [2017-01-19 17:31 +]:
> This one works too, by adding a newline at the end of the apt-cache
> output, so that the block is always executed at the end.

Thanks! Committed with a test case for reproducing:

  
https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=ef7574f51

> BTW, git {diff,show} --color-words is one I learned to look at the diff
> for this patch. :)

Oh, nice trick, thanks!

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



Bug#797314: dracut: Behaves strangely when safe-rm is installed

2017-01-21 Thread intrigeri
Hi,

intrigeri:
> I can reproduce neither the original issue, nor the LUKS passphrase
> one anymore.

Oops, I've messed up: I can't reproduce that bug anymore, but… I don't
have safe-rm installed (and can't install it since usrmerge
Conflicts: safe-rm). So I don't know if this is still a problem or
not, and perhaps this bug should be reopened.

Cheers,
-- 
intrigeri



Bug#797315: dracut: behaves strangely when molly-guard is installed

2017-01-21 Thread intrigeri
Hi,

I wanted to try and reproduce this bug on current sid, but usrmerge
Conflicts: molly-guard, so I can't easily try that (even my sid test
VM has usrmerge installed).

Cheers,
-- 
intrigeri



Bug#852065: rust-gdb: adequate reports broken-symlink for rust-gdb

2017-01-21 Thread shirish शिरीष
Package: rust-gdb
Version: 1.14.0+dfsg1-3
Severity: normal
User: debian...@lists.debian.org
Usertags: broken-symlink adequate

Dear Maintainer,
Adequate reports broken-symlink for rust-gdb.

[$] adequate rust-gdb

rust-gdb: broken-symlink /usr/share/man/man1/rust-gdb.1.gz -> gdb.1.gz

I tried to see the manpage and sure enough it said -

[$] man rust-gdb

man: warning: /usr/share/man/man1/rust-gdb.1.gz is a dangling symlink
No manual entry for rust-gdb
See 'man 7 undocumented' for help when manual pages are not available.

Look forward to seeing it fixed.

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

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

Versions of packages rust-gdb depends on:
ii  gdb  7.12-4

rust-gdb recommends no packages.

rust-gdb suggests no packages.

-- no debconf information


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



Bug#737106: Ping?

2017-01-21 Thread Elena ``of Valhalla''
On 2017-01-21 at 00:59:18 +0100, gregor herrmann wrote:
> > What is not clear to me after thinking a bit about this new feature
> > is how it would work from a UI point of view: Should this be a third
> > icon/button next to alarm/clock and favourite/star, and should the
> > favourite-star turn into a tri-state button (grey/pink/red or
> > grey/half-red/full-red for no-favourite, soft-favourite,
> > hard-favourite)? 

I've been thinking a bit about it without reaching any definite idea

> It looks like we something working in git; we finally went for the
> tri-state solution if the fav button (no / weak / strong).
> 
> I'll try to get something out tomorrow; unless you want to try and
> build from git yourself to take a look:
> http://git.toastfreeware.priv.at/toast/confclerk.git

That's great, thanks!

I've only stumbled on one UI issue: when something is half-starred and
you're browsing it from the favourites view there is no way to turn it
into a full star, because clicking on the star goes through the
unstarred phase and removes it from the view.

On the PC using right click to go through the states in
the opposite direction looks to me like a natural interface to work
around the problem (and it would work on the Pandora / Pyra, even if
it's a bit less natural); I'm not sure how well it would work on other
mobile devices (maybe long tap? I don't know how easy/hard it would be
to do it with QT).

Anyway, you've just made my fosdem experience MUCH smoother, THANKS!

-- 
Elena ``of Valhalla''



Bug#852066: rpcbind: Please drop to unprivileged user

2017-01-21 Thread Laurent Bigonville
Package: rpcbind
Version: 0.2.3-0.5
Severity: normal

Hi,

On other distributions, the rpcbind daemon is running as "rpc" user
instead than root.

Debian maybe should also drop the root privileges after the daemon has
started, this would improve the security IMHO.

Regards,

Laurent Bigonville

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

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

Versions of packages rpcbind depends on:
ii  init-system-helpers  1.47
ii  libc62.24-9
ii  libsystemd0  232-12
ii  libtirpc10.2.5-1.1
ii  libwrap0 7.6.q-26
ii  lsb-base 9.20161125

rpcbind recommends no packages.

rpcbind suggests no packages.

-- no debconf information



Bug#852063: consolekit: cannot git push

2017-01-21 Thread Steven Chamberlain
Hello,

Andrea Zagli wrote:
> i cannot anymore "git push" from a client to a server (it worked yesterday); i
> can access in ssh

I think you can get more more detail on what is happening by running

$ export GIT_SSH="ssh -v"

before you git push.

> Jan 21 10:08:57 deimos systemd[1]: Started Session 9 of user andreaz.
> Jan 21 10:08:57 deimos udev-acl.ck[4446]: g_slice_set_config: assertion 
> 'sys_page_size == 0' failed
> Jan 21 10:08:57 deimos console-kit-daemon[2635]: missing action
> ...
> Jan 21 10:09:25 deimos udev-acl.ck[4641]: g_slice_set_config: assertion 
> 'sys_page_size == 0' failed
> Jan 21 10:09:25 deimos console-kit-daemon[2635]: missing action
> Jan 21 10:09:25 deimos console-kit-daemon[2635]: console-kit-daemon[2635]: > 
> GLib-CRITICAL: Source ID 138 was not found when attempting to remove it
> Jan 21 10:09:25 deimos console-kit-daemon[2635]: GLib-CRITICAL: Source ID 138 
> > was not found when attempting to remove it

consolekit seems to have a problem, but I think this is not the reason
Git is failing.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature


Bug#851556: autopkgtest: please add Restrictions for network access, or Features for lack of network access

2017-01-21 Thread Martin Pitt
Control: tag -1 pending

Hello Simon,

Simon McVittie [2017-01-16 15:19 +]:
> If it's through a proxy, it isn't unrestricted, because I've never
> encountered a proxy that supports more than DNS, TCP and occasionally
> UDP.

Right. Updated:

  
https://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=caf8a0239

Martin
-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



Bug#849688: package in debian/testing is development version, severely broken

2017-01-21 Thread Richard B. Kreckel
On Mon, 02 Jan 2017 11:19:47 +0100 Jörg Frings-Fürst wrote:
> I set the severity to normal because
>  * there are only 2 open bugs[5] for release 0.25.x at shotwell
>bugtracker
>  * the next release date is near enough to get it into
>unstable/testing.

Jörg, having the freeze in mind, may I ask what your plans are to get a
useable release into Debian/stretch?

  -richy.



Bug#851792: palo ships binary in the sources

2017-01-21 Thread Christoph Biedl
Helge Deller wrote...

> On 18.01.2017 20:40, Adrian Bunk wrote:
> > Package: palo
> ...
> > If palo should continue to be available on non-hppa machines,
> > a (binary-all) package that uses gcc-hppa-linux-gnu for building
> > might be an option.
> 
> I'll check if it's possile. May take some time.

As my hppa machine still suffers from systemd's assertion failure[0], I
cannot test the result of the changes attached below, or compare with
the result of a build on native hardware.

However, after applying palo builds on amd64 and produces an iplboot of
the same size but with partially different content. Helge, might want to
burn one your boxes trying out? :-)

Christoph

[0] https://lists.debian.org/debian-hppa/2014/09/msg00025.html

diff --git a/debian/control b/debian/control
index a31c4d5..6063f68 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: admin
 Priority: optional
 Maintainer: Helge Deller 
 Uploaders:
-Build-Depends: debhelper (>= 9), lynx
+Build-Depends: debhelper (>= 9), lynx, gcc-hppa-linux-gnu, libc6-dev-hppa-cross
 Standards-Version: 3.9.5
 Homepage: http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git
 Vcs-Browser: http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git
diff --git a/debian/rules b/debian/rules
index 0b99f7b..1ac9cdd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,14 +10,9 @@ override_dh_auto_clean:
# when building on hppa machines only. This way, palo
# can also be built on non-hppa build hosts without
# problems using the pre-built iplboot binary.
-   @if [ `dpkg --print-architecture` = hppa ]; \
-then \
-   echo "Regenerating iplboot."; \
-   $(MAKE) realclean; \
-   $(MAKE) iplboot; \
-else \
-   echo "Leaving iplboot in place since we're not building on 
hppa."; \
-fi
+   echo "Regenerating iplboot."; \
+   $(MAKE) realclean; \
+   $(MAKE) iplboot; \
 
 %:
dh $@
diff --git a/ipl/Makefile b/ipl/Makefile
index 6b8e105..02f5a8b 100644
--- a/ipl/Makefile
+++ b/ipl/Makefile
@@ -27,7 +27,7 @@ CROSS_COMPILE := $(call cc-cross-prefix, \
 
 CC = ${CROSS_COMPILE}gcc
 AR = ar
-LD = ld
+LD = ${CROSS_COMPILE}ld
 
 ifneq ("$(wildcard /etc/debian_version)","")
 BLDINFO := $(shell echo http://www.parisc-linux.org - `dpkg-parsechangelog 
-l../debian/changelog -SDate`)


signature.asc
Description: Digital signature


Bug#852067: scite: New upstream version available

2017-01-21 Thread Andreas Ronnquist
Package: scite
Severity: wishlist

Dear Maintainer,

Please update the version of SciTE in unstable to 3.7.2 - I am sending
this report since the freeze is almost here, and it would be a pity
to no have the latest version in unstable before the freeze.

Thanks for packaging SciTE in Debian!

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/1 CPU core)
Locale: LANG=sv_SE.utf8, LC_CTYPE=sv_SE.utf8 (charmap=UTF-8)



Bug#851897: dgit: please have generated source packages contain standard patch series

2017-01-21 Thread Daniel Shahaf
Sean Whitton wrote on Fri, Jan 20, 2017 at 14:32:16 -0700:
> On Fri, Jan 20, 2017 at 12:21:56AM +, Ian Jackson wrote:
> >This workflow is less suitable for some packages.  When the Debian
> >delta contains multiple pieces which interact, or which you aren't
> >going to be able to upstream soon, it might be preferable to
> >maintain the delta as a rebasing patch series.
> 
> +1 from me.
> 
> On Fri, Jan 20, 2017 at 03:52:09PM +, Daniel Shahaf wrote:
> > I do have a few editorial changes to suggest:
> > 
> > 1. Change you aren't going to..." to passive voice ("aren't going to be
> > upstreamed soon").
> 
> I prefer the active voice because this is a tutorial manpage (and the
> rest of the manpage already uses the active voice).

+1 to internal consistency.

> > 2. Maybe state the rationales explicitly, at least in a half sentence?
> > Warnings tend to have better retention when accompanied by rationales.
> >
> > So:
> >
> >This workflow is less suitable for some packages.  When the Debian
> >delta contains multiple logical changes, it might be preferable to
> >maintain the delta as a rebasing patch series, in order to
> >facilitate reviewing/upstreaming/dropping individual changes.
> 
> One of the reasons for using the dgit-maint-merge workflow is to make it
> simpler and easier to review, upstream and drop individual changes.
> This bug is about noting the cases in which the workflow can make it
> harder to do those things.  However, your text might suggest that
> dgit-maint-merge(7) makes those things harder in general, and I'm very
> keen to avoid that mistaken impression.  So I would prefer to stick with
> Ian's text.

Of course I'm not trying to cause a mistaken impression.  However, as
Ian noted, in a merge workflow merge conflict resolutions are not
represented in the history as first-class objects, which means that some
operations on "individual logical changes that comprise the delta" are
harder in that workflow than in others.  For example, the merge workflow
has no equivalent of 'git log debian/patches/01_foo.patch'.

To be clear, I'm not trying to open a holy war here; I'm just stating
what I think is an objective criticism of that workflow.  I suppose you
might not agree with the last paragraph entirely, and that's fine; I'd
be happy to go with whatever text Ian chooses.

Cheers,

Daniel



Bug#852063: consolekit: cannot git push

2017-01-21 Thread Andrea Zagli

Il giorno sab 21 gen 2017 10:44:36 CET, Steven Chamberlain ha scritto:

[...]


Jan 21 10:08:57 deimos systemd[1]: Started Session 9 of user andreaz.
Jan 21 10:08:57 deimos udev-acl.ck[4446]: g_slice_set_config:  
assertion 'sys_page_size == 0' failed

Jan 21 10:08:57 deimos console-kit-daemon[2635]: missing action
...
Jan 21 10:09:25 deimos udev-acl.ck[4641]: g_slice_set_config:  
assertion 'sys_page_size == 0' failed

Jan 21 10:09:25 deimos console-kit-daemon[2635]: missing action
Jan 21 10:09:25 deimos console-kit-daemon[2635]:  
console-kit-daemon[2635]: > GLib-CRITICAL: Source ID 138 was not  
found when attempting to remove it
Jan 21 10:09:25 deimos console-kit-daemon[2635]: GLib-CRITICAL:  
Source ID 138 > was not found when attempting to remove it


consolekit seems to have a problem, but I think this is not the reason
Git is failing.




yes i just found that is only a permissions issue... unfortunately git  
simply hanged until i ctrl+c (unlike other times that it saying it)



you can close the bug... and sorry



Bug#838164: New upstream from the git repository

2017-01-21 Thread Dariusz Dwornikowski
Hey,

I have very limited time this time of year but. What I propose to do is to
package the profanity without splitting it to sub packages. This means that
Jack's work will go for nothing, so Jack if you are ok with it I can do it.
Ofc this will be uploaded as your NMU. When stretch is there we can split
the package as you proposed.



On 7 January 2017 at 15:27, Jack Henschel  wrote:

> I did push a new branch 'profanity-0.5' to the collab-maint repository,
> containing solely the new version of profanity.
> https://anonscm.debian.org/cgit/collab-maint/profanity.git/
> log/?h=profanity-0.5
>
> From d/changelog:
> >  * Imported Upstream version 0.5.0:
> >- requires new version of libstrophe (>= 0.9.0)
> >  * Enable GTK status bar icons, Xscreensaver timeout
> >and C-plugin support
> >  * Patches
> > - removed (obsolete) fix_spelling_error.patch
> > - introduced new fix-spelling-errors.patch
> >  * Update Standards-Version to 3.9.8
>
> There are still some issues lintian complains about (especially the new
> library profanity 0.5 comes with):
>
> > I: profanity source: vcs-field-uses-insecure-uri vcs-git git://
> anonscm.debian.org/collab-maint/profanity.git
> > W: profanity source: changelog-should-mention-nmu
> > P: profanity source: debian-watch-may-check-gpg-signature
> > W: profanity: package-name-doesnt-match-sonames libprofanity
> > E: profanity: non-empty-dependency_libs-in-la-file
> usr/lib/x86_64-linux-gnu/libprofanity.la
> > W: profanity: shlib-without-versioned-soname
> usr/lib/x86_64-linux-gnu/libprofanity.so libprofanity.so
> > I: profanity: no-symbols-control-file usr/lib/x86_64-linux-gnu/libpr
> ofanity.so
> > E: profanity: package-must-activate-ldconfig-trigger
> usr/lib/x86_64-linux-gnu/libprofanity.so
>
> Dariusz told me he has some doubts about splitting libprofanity from the
> main profanity package, however I don't know how else to fix these
> shared-object library issues.
> Maybe someone else can look into that.
>
>


Bug#850317: reportbug attachment bug fix

2017-01-21 Thread Yuri Kozlov
Works for me, thanks.

-- 
Best Regards,
Yuri Kozlov



Bug#852063: consolekit: cannot git push

2017-01-21 Thread Steven Chamberlain
notfound 852063 consolekit/0.4.6-5
fixed 852063 consolekit/0.4.6-5
close 852063
thanks

Andrea Zagli wrote:
> yes i just found that is only a permissions issue... unfortunately git
> simply hanged until i ctrl+c (unlike other times that it saying it)
> 
> you can close the bug... and sorry

No problem... and thanks for explaining!

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature


Bug#851870: autopkgtest-virt-qemu: Hangs if test causes a kernel panic

2017-01-21 Thread Martin Pitt
Hello Iain,

Iain Lane [2017-01-19 14:06 +]:
> I was attempting to debug/fix LP: #1630578, so I wrote the attached
> package to trigger a panic manually.
> 
> Seems that the qemu runner hangs when the panic happens. (Hopefully it's
> going to timeout eventually.)

It does time out:

| $ runner/autopkgtest -B /tmp/panic -d --timeout-test=60 --timeout-copy=10 -- 
qemu -d autopkgtest-zesty-amd64.img
| [...]
| autopkgtest [11:03:40]: test panic: [---
| [...]
| make[1]: Leaving directory '/usr/src/linux-headers-4.9.0-11-generic'
| autopkgtest [11:04:40]: ERROR: timed out on command [...]
| autopkgtest [11:04:41]: test panic: ---]

it then tries to copy the results, which times out as well:

| autopkgtest-virt-qemu: DBG: executing copyup 
/tmp/autopkgtest.6i3fb7/panic-stdout 
/tmp/autopkgtest.output.e4e00v7l/panic-stdout
| autopkgtest: DBG: got reply from testbed: timeout
| autopkgtest: WARNING: Copying up test output timed out, ignoring
| autopkgtest [11:04:51]: test panic:  - - - - - - - - - - results - - - - - - 
- - - -
| panicFAIL timed out

and exits with error 4 (i. e. test failure). So while this is certainly not
optimal, it is at least reasonable. So I don't think it's an urgent/critical
bug.

> I thought about solving by slightly refactoring the auxverb use to use
> asyncio when waiting for the command to exit, and then also for reading
> from ttyS0 for occurrences of 'Kernel panic'.

This should take care to not catch kernel warnings or oopses -- when these
happen, the machine should limp on normally, and package tests like kerneloops
even trigger them deliberately.

Thanks,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)



Bug#852068: libgeo-coder-googlev3-perl: autopkgtest failure: Brandenburger Tor vs Pariser Platz

2017-01-21 Thread Niko Tyni
Package: libgeo-coder-googlev3-perl
Version: 0.14-1
Tags: fixed-upstream
User: debian-p...@lists.debian.org
Usertags: autopkgtest

This package recently started failing its autopkgtest test suite
on ci.debian.net.

  https://ci.debian.net/packages/libg/libgeo-coder-googlev3-perl/unstable/amd64/

  #   Failed test at t/geocode.t line 37.
  #   'Pariser Platz, 10117 Berlin, Germany'
  # doesn't match '(?^i:(brandenburger tor.*berlin|brandenburg gate))'
  
  #   Failed test at t/geocode.t line 46.
  #   'Pariser Platz, 10117 Berlin, Deutschland'
  # doesn't match '(?^i:brandenburger tor.*berlin)'

This seems to be fixed upstream:

 Changes for version 0.15

fixed test for changed results (Brandenburger Tor vs Pariser Platz)

I see the build process sets NO_NETWORK=1 so the build still succeeds.
Clearly one fix would be do that for autopkgtest as well. I'm not quite
sure what the current consensus is on network access during autopkgtest...
-- 
Niko Tyni   nt...@debian.org



Bug#851930: desktop-base: Include size 3840x2160 (4k) wallpaper and lockscreen

2017-01-21 Thread Yves-Alexis Perez
On Thu, 2017-01-19 at 22:22 -0500, Dave Allen Barker Jr wrote:
>   1. For each of the themes
>     1.1. In thier "image" directories
>   1.1.1 Copy a 16:9 aspect ratio ".svg" file to "3840x2160.svg"
>   1.1.2 Edit the "3840x2160.svg" "svg" header "width" and "height"
>   attributes to "3840" and "2160" respectively
>     1.2. In their "gnome-background.xml"s, add an entry for the
>     "3840x2160.svg"

Does it really make sense to edit the svg header anyway? Why can't you use the
original file directly, it should scale just fine?
-- 
Yves-Alexis

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


Bug#852069: DomU guests with pygrub as bootloader do not start after, upgrade from Xen 4.1 (wheezy) to Xen 4.4 (jessie)

2017-01-21 Thread Michael Bilow
Package: xen-utils-4.4
Version: 4.4.1-9+deb8u8
Severity: normal

Under Xen 4.1 in Debian 7 (wheezy), the following works when included in a
DomU configuration in "/etc/xen/cfg/" --

bootloader   = '/usr/lib/xen-default/bin/pygrub'

After upgrading to Xen 4.4 as part of an upgrade to Debian 8 (jessie), the
DomU silently fails to start. Examination of the log files shows that the
cause is that the old path for "bootloader" no longer exists. Correcting the
DomU configuration manually to the new path works --

bootloader   = '/usr/lib/xen-4.4/bin/pygrub'

I would assume that creating a symlink would work also, and perhaps the
package installer should do it (in "/usr/lib", "ln -s xen-4.4 xen-default").


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

Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=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 xen-utils-4.4 depends on:
ii  e2fslibs  1.42.12-2+b1
ii  libc6 2.19-18+deb8u7
ii  libncurses5   5.9+20140913-1+b1
ii  libtinfo5 5.9+20140913-1+b1
ii  libxen-4.44.4.1-9+deb8u8
ii  libxenstore3.04.4.1-9+deb8u8
ii  libyajl2  2.1.0-2
ii  python2.7 2.7.9-2+deb8u1
pn  python:any
ii  xen-utils-common  4.4.1-9+deb8u8

Versions of packages xen-utils-4.4 recommends:
ii  bridge-utils   1.5-9
ii  grub-xen-host  2.02~beta2-22+deb8u1
pn  qemu-system-x86
ii  xen-hypervisor-4.4-amd64 [xen-hypervisor-4.4]  4.4.1-9+deb8u8

xen-utils-4.4 suggests no packages.

-- no debconf information



Bug#852070: smemstat: The smemstat command crashes on ARM based machine

2017-01-21 Thread Miroslav Mitevski
Package: smemstat
Version: 0.01.10-1
Severity: important

Dear Maintainer,

after installing the package from the official Debian repository and executing 
the smemstat command on ARM based machine I discovered the following error:

The expectation is program to list running processes with the memory usage. 
Unfortunately the program crashes with "Segmentation fault".

There are no logs or additional error messages.

The Debian installation is on QNAP 219P II device, which is ARM based.

Current locale of the system is bg_BG.UTF-8

Itried with en_US.UTF-8 and "C" - the result was the same.

Regards,
Miro


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

   * What was the outcome of this action?
   * What outcome did you expect instead?

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


-- System Information:
Debian Release: 8.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-4-kirkwood
Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages smemstat depends on:
ii  libc6  2.19-18+deb8u7

smemstat recommends no packages.

smemstat suggests no packages.

-- no debconf information



Bug#838164: New upstream from the git repository

2017-01-21 Thread Jack Henschel
Hey Dariusz,

thanks for your reply. As mentioned in my previous mail, the branch 
'profanity-0.5' contains only the new version of profanity (without package 
split) - so my work wasn't all for nothing :-)

I'm totally fine with you merging this branch.

On 01/21/2017 10:56 AM, Dariusz Dwornikowski wrote:
> Hey,
> 
> I have very limited time this time of year but. What I propose to do is to 
> package the profanity without splitting it to sub packages. This means that 
> Jack's work will go for nothing, so Jack if you are ok with it I can do it. 
> Ofc this will be uploaded as your NMU. When stretch is there we can split the 
> package as you proposed. 
> 
> 
> 
> On 7 January 2017 at 15:27, Jack Henschel  > wrote:
> 
> I did push a new branch 'profanity-0.5' to the collab-maint repository, 
> containing solely the new version of profanity.
> 
> https://anonscm.debian.org/cgit/collab-maint/profanity.git/log/?h=profanity-0.5
>  
> 
> 
> From d/changelog:
> >  * Imported Upstream version 0.5.0:
> >- requires new version of libstrophe (>= 0.9.0)
> >  * Enable GTK status bar icons, Xscreensaver timeout
> >and C-plugin support
> >  * Patches
> > - removed (obsolete) fix_spelling_error.patch
> > - introduced new fix-spelling-errors.patch
> >  * Update Standards-Version to 3.9.8
> 
> There are still some issues lintian complains about (especially the new 
> library profanity 0.5 comes with):
> 
> > I: profanity source: vcs-field-uses-insecure-uri vcs-git 
> git://anonscm.debian.org/collab-maint/profanity.git 
> 
> > W: profanity source: changelog-should-mention-nmu
> > P: profanity source: debian-watch-may-check-gpg-signature
> > W: profanity: package-name-doesnt-match-sonames libprofanity
> > E: profanity: non-empty-dependency_libs-in-la-file 
> usr/lib/x86_64-linux-gnu/libprofanity.la 
> > W: profanity: shlib-without-versioned-soname 
> usr/lib/x86_64-linux-gnu/libprofanity.so libprofanity.so
> > I: profanity: no-symbols-control-file 
> usr/lib/x86_64-linux-gnu/libprofanity.so
> > E: profanity: package-must-activate-ldconfig-trigger 
> usr/lib/x86_64-linux-gnu/libprofanity.so
> 
> Dariusz told me he has some doubts about splitting libprofanity from the 
> main profanity package, however I don't know how else to fix these 
> shared-object library issues.
> Maybe someone else can look into that.
> 
> 



signature.asc
Description: OpenPGP digital signature


Bug#838164: New upstream from the git repository

2017-01-21 Thread Dariusz Dwornikowski
On 21 January 2017 at 11:18, Jack Henschel  wrote:

> Hey Dariusz,
>
> thanks for your reply. As mentioned in my previous mail, the branch
> 'profanity-0.5' contains only the new version of profanity (without
> package split) - so my work wasn't all for nothing :-)
>
> I'm totally fine with you merging this branch.
>

Ok I will fix if I can, then push with you as NMU.


>
> On 01/21/2017 10:56 AM, Dariusz Dwornikowski wrote:
> > Hey,
> >
> > I have very limited time this time of year but. What I propose to do is
> to package the profanity without splitting it to sub packages. This means
> that Jack's work will go for nothing, so Jack if you are ok with it I can
> do it. Ofc this will be uploaded as your NMU. When stretch is there we can
> split the package as you proposed.
> >
> >
> >
> > On 7 January 2017 at 15:27, Jack Henschel  j...@openmailbox.org>> wrote:
> >
> > I did push a new branch 'profanity-0.5' to the collab-maint
> repository, containing solely the new version of profanity.
> > https://anonscm.debian.org/cgit/collab-maint/profanity.
> git/log/?h=profanity-0.5  cgit/collab-maint/profanity.git/log/?h=profanity-0.5>
> >
> > From d/changelog:
> > >  * Imported Upstream version 0.5.0:
> > >- requires new version of libstrophe (>= 0.9.0)
> > >  * Enable GTK status bar icons, Xscreensaver timeout
> > >and C-plugin support
> > >  * Patches
> > > - removed (obsolete) fix_spelling_error.patch
> > > - introduced new fix-spelling-errors.patch
> > >  * Update Standards-Version to 3.9.8
> >
> > There are still some issues lintian complains about (especially the
> new library profanity 0.5 comes with):
> >
> > > I: profanity source: vcs-field-uses-insecure-uri vcs-git git://
> anonscm.debian.org/collab-maint/profanity.git  collab-maint/profanity.git>
> > > W: profanity source: changelog-should-mention-nmu
> > > P: profanity source: debian-watch-may-check-gpg-signature
> > > W: profanity: package-name-doesnt-match-sonames libprofanity
> > > E: profanity: non-empty-dependency_libs-in-la-file
> usr/lib/x86_64-linux-gnu/libprofanity.la 
> > > W: profanity: shlib-without-versioned-soname
> usr/lib/x86_64-linux-gnu/libprofanity.so libprofanity.so
> > > I: profanity: no-symbols-control-file usr/lib/x86_64-linux-gnu/
> libprofanity.so
> > > E: profanity: package-must-activate-ldconfig-trigger
> usr/lib/x86_64-linux-gnu/libprofanity.so
> >
> > Dariusz told me he has some doubts about splitting libprofanity from
> the main profanity package, however I don't know how else to fix these
> shared-object library issues.
> > Maybe someone else can look into that.
> >
> >
>
>


Bug#851866: wants to restart systemd-manager.service

2017-01-21 Thread Thomas Liske

Hi,

Sven Hartge  writes:

> Instead of doing "systemctl daemon-restart" needrestart tries to restart
> systemd-manager.service, which is of course unknown:

there was a change in needrestart 2.11 putting the special treatment
required to restart certain daemons into external scripts. Sadly the
Makefile was broken upstream and did use the wrong source directory
during install *and* Patrick's packaging stuff did not contain
restart.d/ at all.

@Patrick: I've patched the Makefile issue upstream and added a patch into your
debian/ VCS for needrestart 2.11-2 to fix the installation of the
restart.d/ directory.


HTH,
Thomas

> Failed to restart systemd-manager.service: Unit systemd-manager.service not 
> found.
>
> A log from "needrestart -v" showing the problem is attached.
>
> Grüße,
> Sven
>
>
> -- Package-specific info:
> needrestart output:
> Your outdated processes:
> alpine[355950], bash[355942, 355946, 356300, 355943, 355945, 355944], 
> ccze[355976],
>  dirmngr[355859], pkt-sudo[355953], syncthing[355857], syslogtail[355947], 
> systemd[355854],
>  tin[355949, 355981]
>
> checkrestart output:
>
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable-debug
>   APT policy: (500, 'unstable-debug'), (500, 'testing-debug'), (500, 
> 'unstable'), (500, 'testing'), (200, 'experimental'), (1, 
> 'experimental-debug')
> Architecture: i386 (x86_64)
> Foreign Architectures: amd64
>
> Kernel: Linux 4.8.0-2-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 needrestart depends on:
> ii  dpkg   1.18.18
> ii  gettext-base   0.19.8.1-1
> ii  libintl-perl   1.26-2
> ii  libmodule-find-perl0.13-1
> ii  libmodule-scandeps-perl1.23-1
> ii  libproc-processtable-perl  0.53-2
> ii  libsort-naturally-perl 1.03-1
> ii  libterm-readkey-perl   2.37-1
> ii  perl   5.24.1-1
> ii  xz-utils   5.2.2-1.2
>
> Versions of packages needrestart recommends:
> ii  libpam-systemd  232-12
>
> Versions of packages needrestart suggests:
> pn  needrestart-session | libnotify-bin  
>
> -- Configuration Files:
> /etc/needrestart/notify.d/200-write changed [not included]
> /etc/needrestart/notify.d/600-mail changed [not included]
>
> -- debconf-show failed
> [main] eval /etc/needrestart/needrestart.conf
> [main] needrestart v2.11
> [main] running in root mode
> [Core] Using UI 'NeedRestart::UI::stdio'...
> [main] detected systemd
> [main] #1 uses deleted /lib/i386-linux-gnu/libgcc_s.so.1
> [main] #1 is not a child
> [main] #1249 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #1249 is not a child
> [main] #355854 uses obsolete binary /lib/systemd/systemd
> [main] #355854 is not a child
> [main] #355855 uses obsolete binary /lib/systemd/systemd
> [main] #355855 is a child of #355854
> [main] #355857 uses deleted /lib/i386-linux-gnu/libc-2.24.so
> [main] #355857 is a child of #355854
> [main] #355858 uses obsolete binary /usr/bin/gpg-agent
> [main] #355858 is a child of #355854
> [main] #355859 uses obsolete binary /usr/bin/dirmngr
> [main] #355859 is a child of #355854
> [main] #355941 uses obsolete binary /usr/bin/screen
> [main] #355941 is not a child
> [main] #355942 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #355942 is a child of #355941
> [main] #355943 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #355943 is a child of #355941
> [main] #355944 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #355944 is a child of #355941
> [main] #355945 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #355945 is a child of #355941
> [main] #355946 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #355946 is a child of #355941
> [main] #355947 uses deleted /lib/i386-linux-gnu/libc-2.24.so
> [main] #355947 is a child of #355941
> [main] #355949 uses deleted /lib/i386-linux-gnu/libc-2.24.so
> [main] #355949 is a child of #355941
> [main] #355950 uses deleted /lib/i386-linux-gnu/libgcc_s.so.1
> [main] #355950 is a child of #355941
> [main] #355953 uses deleted /lib/i386-linux-gnu/libc-2.24.so
> [main] #355953 is a child of #355941
> [main] #355976 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #355976 is a child of #355947
> [main] #355981 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #355981 is a child of #355949
> [main] #356002 uses deleted /lib/x86_64-linux-gnu/libdl-2.24.so
> [main] #356002 is a child of #356001
> [main] #356262 uses deleted /lib/i386-linux-gnu/libc-2.24.so
> [main] #356262 is a child of #356261
> [main] #356300 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #356300 is a child of #355941
> [main] #356557 uses deleted /lib/i386-linux-gnu/libnss_files-2.24.so
> [main] #356557 is a child of #356556
> [main] #357646 uses deleted /lib/i386-linux-gnu/

Bug#852071: kde-telepathy cannot be ended

2017-01-21 Thread Hans-J. Ullrich
Package: kde-telepathy
Version: 15.08.3
Severity: normal

Dear Maintainer,

sorry to tell xýou, that I found no way to kill telepathy once it is started. 
IMO stopping a service like this should be possible by a button. Still I found 
none. There is an icon in the taskbar, when it is started, and I can open a 
menu, where I can configure my settings. But no "Close Application" button. The 
only way I found, is to kill the process in the shell or by using ksysguard.

It would be nice, if yoú could add one.

Thanks for your work.

Best

Hans

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

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

Versions of packages kde-telepathy depends on:
ii  kde-telepathy-desktop-applets   15.08.3-1
ii  kde-telepathy-filetransfer-handler  15.08.3-1
ii  kde-telepathy-minimal   15.08.3
ii  kde-telepathy-send-file 15.08.3-1
ii  plasma-runner-telepathy-contact 15.08.3-1

kde-telepathy recommends no packages.

kde-telepathy suggests no packages.

-- no debconf information


Bug#851963: linux: enable SENSORS_ADM1031

2017-01-21 Thread Roger Shimizu
On Sat, Jan 21, 2017 at 6:05 PM, James Cowgill  wrote:
> Hi,
>
> On 21/01/17 08:05, Roger Shimizu wrote:
>> Control: tag -1 +moreinfo
>>
>> On Fri, Jan 20, 2017 at 9:17 PM, James Cowgill  wrote:
>>> Source: linux
>>> Version: 4.9.2-2
>>> Severity: wishlist
>>>
>>> Hi,
>>>
>>> Please can you enable CONFIG_SENSORS_ADM1031 as a module.
>>>
>>> I have a Cavium Octeon board which needs this driver to be able to read
>>> the CPU temperature / fan sensors.
>>
>> I see this module already exists in the kernel you're using.
>> Can you help to confirm?
>
> I'm pretty certain it's not enabled. It is already enabled on x86 however.

Sorry, I just looked at amd64.
So you're asking for mips64 octeon support, right?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1



Bug#852070: smemstat: The smemstat command crashes on ARM based machine

2017-01-21 Thread Colin Ian King
Hi Miroslav,

Is that a 32 bit ARM platform?

How are you running smemstat?

Can you re-run smemstat using strace and capturing the output and adding
that to the bug report?

e.g.

strace smemstat >& smemstat.log

please can you use the same smemstat options that reproduce the bug.

Thanks!

On 21/01/17 10:19, Miroslav Mitevski wrote:
> Package: smemstat
> Version: 0.01.10-1
> Severity: important
> 
> Dear Maintainer,
> 
> after installing the package from the official Debian repository and 
> executing the smemstat command on ARM based machine I discovered the 
> following error:
> 
> The expectation is program to list running processes with the memory usage. 
> Unfortunately the program crashes with "Segmentation fault".
> 
> There are no logs or additional error messages.
> 
> The Debian installation is on QNAP 219P II device, which is ARM based.
> 
> Current locale of the system is bg_BG.UTF-8
> 
> Itried with en_US.UTF-8 and "C" - the result was the same.
> 
> Regards,
> Miro
> 
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> 
>* What was the outcome of this action?
>* What outcome did you expect instead?
> 
> *** End of the template - remove these template lines ***
> 
> 
> -- System Information:
> Debian Release: 8.7
>   APT prefers stable-updates
>   APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: armel (armv5tel)
> 
> Kernel: Linux 3.16.0-4-kirkwood
> Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages smemstat depends on:
> ii  libc6  2.19-18+deb8u7
> 
> smemstat recommends no packages.
> 
> smemstat suggests no packages.
> 
> -- no debconf information
> 



Bug#851897: dgit: please have generated source packages contain standard patch series

2017-01-21 Thread Daniel Shahaf
Sean Whitton wrote on Fri, Jan 20, 2017 at 14:16:28 -0700:
> On Fri, Jan 20, 2017 at 03:52:09PM +, Daniel Shahaf wrote:
> > Ian Jackson wrote on Fri, Jan 20, 2017 at 00:21:56 +:
> > > Let me quote yur preferred wording from your patch.  (I find it easier
> > > to deal with this inline as prose than as an attachment.  And I'd like
> > > Daniel's opinion, as someone who has to deal with "not their own"
> > > packages, before concluding that we have the wording right.)
> > 
> > I think in my case, the root problem was that the assumptions of
> > dgit-maint-merge(7) did not hold: I was using the source package
> > not as an "output format" but as a the primary source.
> 
> The suggested text for debian/source/patch-header is meant to avoid this
> misunderstanding.  Do you have any suggestions for improving that text?

Thanks for raising this question.

For reference, the text in 3.6 reads:

>   Sample text for debian/source/patch-header
> It is a good idea to explain how a user can obtain a break down of the
> changes to the upstream source:
> 
> The Debian packaging of foo is maintained using dgit. For the sake of
> an efficient workflow, Debian modifications to the upstream source are
> squashed into a single diff, rather than a series of quilt patches. To
> obtain a patch queue for package version 1.2.3-1:
> 
> # apt-get install dgit
> % dgit clone foo
> % cd foo
> % git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'
> 
> See dgit(1), dgit(7) and dgit-maint-merge(7) for more information.
> 
> Alternatively, this text could be added to README.source. However, this
> might distract from more important information present in the latter file.

I have two criticisms of this text:

1. That 'git log' command does not, strictly speaking, produce a patch
queue.  It produces a history of all relevant commits, but that history
is not a patch queue, since a single logical change may span two or
more commits (due to a mistake in the first commit, or due to an
upstream release necessitating extending a previous, not-yet-upstreamed
change).

2. This text can be interpreted as "If you want to see a patch queue,
you have to use the same tools the maintainer chose to use" — which
sounds like a vendor standard.  Simply giving a standard 'git clone'
command would go a long way towards avoiding that impression.  I'd also
reword without "squashed" (which implies the generated source package is
an inferior representation), e.g., —
.
The Debian packaging of foo is maintained using dgit, using the
dgit-maint-merge(7) merge-based workflow.  The Debian changes follow.
For a detailed history, refer to the canonical representation of the
Debian changes in the `...' branch of the packaging repository:
.
git clone bar://.../foo.git
cd foo
git log --oneline 1.2.3..debian/1.2.3-1 -- . ':!debian'

This could use a bit of wordsmithing.  The 'dgit clone' incantation
could be given too, alongside the 'git clone', for readers who do
have/know dgit already.

The point that should be sold to readers is that there is no patch queue
in the source package because there isn't a patch queue in the workflow
(point #1); i.e.: the source package is the best possible representation,
within the constraints of the "3.0 (quilt)" format, of what the maintainer
has.  I'm not entirely sure, however, whether the suggested text would
sell that point to an uninformed reader, since I'm myself informed —
both about dgit specifically (now) and about merge/rebase workflows in
general.

Cheers,

Daniel
(if we get into a longer discussion about this it might be good to
spin it off into a new bug)



Bug#812127: login: wrong German error message

2017-01-21 Thread Holger Wansing
Hi,

Helge Kreutzmann  wrote:
> Hello Balint,
> On Fri, Jan 20, 2017 at 09:19:34PM +0100, Balint Reczey wrote:
> > Control: tags -1 help moreinfo
> > 
> > Hi,
> > 
> > On Wed, 20 Jan 2016 21:33:21 +0100 "B. Ruva"  wrote:
> > > Package: login
> > > Version: 1:4.2-3.1
> > > Severity: l10n
> > > 
> > > Dear Maintainer,
> > > 
> > > the following error message of 'login':
> > > 
> > > "Cannot possibly work without effective root"
> > > 
> > > is translated into German as:
> > > 
> > > "Arbeit ohne effektive root-Rechte eventuell nicht möglich"
> > > 
> > > This wrong and pretty misleading. It means something like:
> > > 
> > > "It is perhaps not possible to work without effective root"
> > > 
> > > I would translate the original error message as:
> > > 
> > > "Kann unmöglich ohne effektive root-Rechte arbeiten"
> > 
> > I need help here for sure.
> > 
> > My wife says the proposed solution does not sound good and I don't speak
> > German thus I can't make a decision here. :-)
> 
> The incorrect translation is probably caused by a misunderstanding of
> the translator (I put him explicitly in CC).
> 
> I believe you mean:
> Under no cirumstance work is possible without effective root.

This means, the english version is incorrect too, right?
Since in english it says "Cannot possibly work ...", and that means 
something like "möglicherweise" or "eventuell" or "unter Umständen".

What do you think, is the correct english meaning, which is intended here?


Holger

> 
> > Please someone from the l10n team take a look and review the translations.
> 
> Yes.
> 
> If my interpretation is correct, the translation suggested by me would
> be:
> 
> Arbeit ohne effektive root-Rechte keinesfalls möglich.
> 
> (The version of the submitter is possible as well, however, it is sub
> optimal based on the translation standards established on
> debian-l10n-german).



-- 

Created with Sylpheed 3.5.0 under
D E B I A N   L I N U X   8 . 0   " J E S S I E " .

Registered Linux User #311290 - https://linuxcounter.net/




Bug#851162: Still unresolved upstream, help needed

2017-01-21 Thread Ghislain Vaillant

Cc'd to debian-powerpc

On Fri, 13 Jan 2017 10:17:18 + Ghislain Vaillant 
 wrote:

control: forwarded -1 https://github.com/h5py/h5py/issues/817


Upstream is running out of ideas, so any help from the team would be 
warmly welcome.


Cheers,
Ghis



Bug#851584: bareos-database-common: fails to upgrade from 'jessie': mysql said: ERROR 1067 (42000) at line 2: Invalid default value for 'CreateTime'

2017-01-21 Thread Felix Geyer
Control: tags -1 sid
Control: severity -1 normal

On Mon, 16 Jan 2017 17:19:06 +0100 Andreas Beckmann  wrote:
> Package: bareos-database-common
> Version: 16.2.4-3
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> Control: affects -1 + bareos-database-mysql
> 
> Hi,
> 
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
> It installed fine in 'jessie', then the upgrade to 'sid' fails.
> 
> >From the attached log (scroll to the bottom...):
> 
>   [...]
> 
> This was a jessie -> sid test and it picked to upgrade mysql-5.5 -> mysql-5.7
> Feel free to downgrade if this issue is specific to this weird combination.

Bareos doesn't support MySQL 5.7 (yet), see 
https://bugs.bareos.org/view.php?id=660

Felix



Bug#852072: packer: build time tests are failing

2017-01-21 Thread Daniel Stender
Package: packer
Version: 0.10.2+dfsg-1
Severity: serious
Justification: fails to build from source (but built successfully in the past)

dh_auto_test is currently failsafed because the tests aren't passing through,
there are some failures on missing test-fixtures which appear to be missing
in the tarball. But for the release the tests shouldn't be failsafed.

DS

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

Kernel: Linux 4.8.0-2-amd64 (SMP w/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 packer depends on:
ii  libc6  2.24-8

Versions of packages packer recommends:
pn  docker.io  
ii  qemu   1:2.7+dfsg-3+b1

Versions of packages packer suggests:
ii  ansible  2.2.0.0-1
pn  chef 

-- no debconf information



Bug#852073: grub2: [INTL:it] Italian debconf translation

2017-01-21 Thread Luca Monducci
Package: grub2
Severity: wishlist
Tags: l10n, patch

Hello,
please update the Italian debconf translation (attached).

Regards,
 Luca






































# Italian (it) translation of debconf templates for grub2
# This file is distributed under the same license as the grub2 package.
# Luca Monducci , 2007-2017.
#
msgid ""
msgstr ""
"Project-Id-Version: grub2 2.02~beta3-4 italian debconf templates\n"
"Report-Msgid-Bugs-To: gr...@packages.debian.org\n"
"POT-Creation-Date: 2017-01-20 00:29+\n"
"PO-Revision-Date: 2017-01-21 11:39+0100\n"
"Last-Translator: Luca Monducci \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "Chainload from menu.lst?"
msgstr "Effettuare il caricamento in cascata da menu.lst?"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub."
msgstr ""
"Gli script di aggiornamento hanno rilevato una installazione di GRUB Legacy "
"in /boot/grub."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"In order to replace the Legacy version of GRUB in your system, it is "
"recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image "
"from your existing GRUB Legacy setup. This step can be automatically "
"performed now."
msgstr ""
"Per sostituire la versione Legacy di GRUB sul proprio sistema si raccomanda "
"di modificare il file /boot/grub/menu.lst in modo da caricare l'immagine di "
"avvio di GRUB 2 dall'attuale installazione di GRUB Legacy. Questa modifica "
"può essere effettuata automaticamente adesso."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"It's recommended that you accept chainloading GRUB 2 from menu.lst, and "
"verify that the new GRUB 2 setup works before it is written to the MBR "
"(Master Boot Record)."
msgstr ""
"Si raccomanda di accettare il caricamento in cascata di GRUB 2 da menu.lst e "
"di verificare che la nuova installazione di GRUB 2 funzioni prima di "
"procedere con l'installazione diretta sul MBR (Master Boot Record)."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"Whatever your decision, you can replace the old MBR image with GRUB 2 later "
"by issuing the following command as root:"
msgstr ""
"Qualsiasi sia la decisione, in seguito sarà possibile sostituire la vecchia "
"immagine sul MBR con GRUB 2 eseguendo da root il seguente comando:"

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid "GRUB install devices:"
msgstr "Installare GRUB sui device:"

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"The grub-pc package is being upgraded. This menu allows you to select which "
"devices you'd like grub-install to be automatically run for, if any."
msgstr ""
"È in corso l'aggiornamento del pacchetto grub-pc. Questo menu permette di "
"scegliere su quali device, se specificati, si vuole eseguire automaticamente "
"grub-install."

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"Running grub-install automatically is recommended in most situations, to "
"prevent the installed GRUB core image from getting out of sync with GRUB "
"modules or grub.cfg."
msgstr ""
"Nella maggioranza dei casi si raccomanda l'esecuzione automatica di grub-"
"install in modo da prevenire la perdita di sincronia dell'immagine "
"principale di GRUB con i moduli di GRUB o con grub.cfg."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"If you're unsure which drive is designated as boot drive by your BIOS, it is "
"often a good idea to install GRUB to all of them."
msgstr ""
"Se non si è sicuri di quale sia il disco impostato come disco di avvio nel "
"BIOS, è consigliabile installare GRUB su tutti i device."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"Note: it is possible to install GRUB to partition boot records as well, and "
"some appropriate partitions are offered here. However, this forces GRUB to "
"use the blocklist mechanism, which makes it less reliable, and therefore is "
"not recommended."
msgstr ""
"Nota: è possibile installare GRUB anche nei boot record delle partizioni e "
"qui sono elencate le partizioni più appropriate. Purtroppo questo obbliga "
"GRUB a usare il meccanismo del \"blocklist\", che lo rende meno affidabile e "
"di conseguenza non è raccomandato."

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:4001
msgid ""
"The GRUB boot loader was previously installed to a disk that is no longer "
"present, or whose unique identifier has changed for some reason. It 

Bug#852074: openldap: [INTL:it] Italian debconf translation

2017-01-21 Thread Luca Monducci
Package: openldap
Severity: wishlist
Tags: l10n, patch

Hello,
please update the Italian debconf translation (attached).

Regards,
 Luca







































# Italian (it) translation of debconf templates for openldap
# This file is distributed under the same license as the openldap package.
# Luca Monducci , 2007-2017.
#
msgid ""
msgstr ""
"Project-Id-Version: openldap 2.4.40-2 italian debconf templates\n"
"Report-Msgid-Bugs-To: openl...@packages.debian.org\n"
"POT-Creation-Date: 2017-01-10 05:24+\n"
"PO-Revision-Date: 2017-01-21 11:42+0100\n"
"Last-Translator: Luca Monducci \n"
"Language-Team: Italian \n"
"Language: it\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../slapd.templates:1001
msgid "Omit OpenLDAP server configuration?"
msgstr "Omettere la configurazione del server OpenLDAP?"

#. Type: boolean
#. Description
#: ../slapd.templates:1001
msgid ""
"If you enable this option, no initial configuration or database will be "
"created for you."
msgstr ""
"Se si accetta, non verranno creati la configurazione iniziale né il database."

#. Type: select
#. Choices
#: ../slapd.templates:2001
msgid "always"
msgstr "sempre"

#. Type: select
#. Choices
#: ../slapd.templates:2001
msgid "when needed"
msgstr "quando necessario"

#. Type: select
#. Choices
#: ../slapd.templates:2001
msgid "never"
msgstr "mai"

#. Type: select
#. Description
#: ../slapd.templates:2002
msgid "Dump databases to file on upgrade:"
msgstr "Fare il dump su file dei database prima dell'aggiornamento:"

#. Type: select
#. Description
#: ../slapd.templates:2002
msgid ""
"Before upgrading to a new version of the OpenLDAP server, the data from your "
"LDAP directories can be dumped into plain text files in the standard LDAP "
"Data Interchange Format."
msgstr ""
"Prima dell'aggiornamento a una nuova versione del server OpenLDAP, è "
"possibile fare il dump delle proprie directory LDAP in dei semplici file di "
"testo in formato LDIF (lo standard per lo scambio di dati LDAP)."

#. Type: select
#. Description
#: ../slapd.templates:2002
msgid ""
"Selecting \"always\" will cause the databases to be dumped unconditionally "
"before an upgrade. Selecting \"when needed\" will only dump the database if "
"the new version is incompatible with the old database format and it needs to "
"be reimported. If you select \"never\", no dump will be done."
msgstr ""
"Selezionando \"sempre\" il dump dei database verrà effettuato prima di ogni "
"aggiornamento. Con \"quando necessario\" il dump dei database verrà fatto "
"solo quando la nuova versione è incompatibile con il vecchio formato del "
"database e quindi deve essere reimportato. Infine con \"mai\" il dump dei "
"database non verrà mai fatto."

#. Type: string
#. Description
#: ../slapd.templates:3001
msgid "Directory to use for dumped databases:"
msgstr "Directory per il dump dei database:"

#. Type: string
#. Description
#: ../slapd.templates:3001
msgid ""
"Please specify the directory where the LDAP databases will be exported. In "
"this directory, several LDIF files will be created which correspond to the "
"search bases located on the server. Make sure you have enough free space on "
"the partition where the directory is located. The first occurrence of the "
"string \"VERSION\" is replaced with the server version you are upgrading "
"from."
msgstr ""
"Indicare la directory in cui verranno esportati i database LDAP. In questa "
"directory verrà creato un file LDIF per ogni base di ricerca presente sul "
"server. Assicurarsi di avere spazio libero sufficiente sulla partizione che "
"contiene la directory indicata. La prima occorrenza della stringa \"VERSION"
"\" viene sostituita con la versione del server che si sta aggiornando."

#. Type: boolean
#. Description
#: ../slapd.templates:4001
msgid "Move old database?"
msgstr "Spostare il vecchio database?"

#. Type: boolean
#. Description
#: ../slapd.templates:4001
msgid ""
"There are still files in /var/lib/ldap which will probably break the "
"configuration process. If you enable this option, the maintainer scripts "
"will move the old database files out of the way before creating a new "
"database."
msgstr ""
"Ci sono ancora dei file in /var/lib/ldap che potrebbero intralciare il "
"processo di configurazione. Se si accetta, gli script di installazione "
"toglieranno di mezzo i file dei vecchi database prima di creare il nuovo "
"database."

#. Type: boolean
#. Description
#: ../slapd.templates:5001
msgid "Retry configuration?"
msgstr "Ripetere la configurazione?"

#. Type: boolean
#. Description
#: ../slapd.templates:5001
msgid ""
"The configuration you entered is invalid. Make sure that the DNS domain name "
"is syntactically valid, the field for the organization is not left empty and "
"the admin passwords match. If you decide not to retry the configuration the "
"LDAP server will not be set up. Run 'dpkg-reconfigure slapd' if you 

Bug#852075: mouse.screen => m.s.index in example

2017-01-21 Thread Jörg Sommer
Package: awesome
Version: 4.0-1
Severity: normal

Hi,

if built my rc.lua with
/usr/share/awesome/lib/shifty/example.rc.lua. After the upgrade to awesome
4.0 I've got the error "attempt to index field '?' (a nil value)" when
pressing mod+r or mod+x. I've changed mouse.screen to mouse.screen.index
and now it works. I'm not very familiar with the awesome library and don't
know if the change is intended or mouse.screen should still work.

diff -u /tmp/example.rc.lua /usr/share/awesome/lib/shifty/example.rc.lua
--- /tmp/example.rc.lua 2017-01-21 12:02:54.019960207 +0100
+++ /usr/share/awesome/lib/shifty/example.rc.lua2016-11-18 
13:31:45.0 +0100
@@ -408,12 +408,12 @@
 --~ awful.key({ modkey, "Control" }, "n", awful.client.restore),
 
 -- Prompt
-awful.key({ modkey },"r", function () 
mypromptbox[mouse.screen]:run() end),
+awful.key({ modkey },"r", function () 
mypromptbox[mouse.screen.index]:run() end),
 
 awful.key({ modkey }, "x",
   function ()
   awful.prompt.run({ prompt = "Run Lua code: " },
-  mypromptbox[mouse.screen].widget,
+  mypromptbox[mouse.screen.index].widget,
   awful.util.eval, nil,
   awful.util.getdir("cache") .. "/history_eval")
   end),

Bye Jörg

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

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

Versions of packages awesome depends on:
ii  dbus-x11  1.10.14-1
ii  gir1.2-freedesktop1.50.0-1
ii  gir1.2-pango-1.0  1.40.3-3
ii  libc6 2.24-9
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.14-1
ii  libgdk-pixbuf2.0-02.36.4-1
ii  libglib2.0-0  2.50.2-2
ii  liblua5.1-0   5.1.5-8.1+b2
ii  libstartup-notification0  0.12-4
ii  libx11-6  2:1.6.4-2
ii  libxcb-cursor00.1.1-3
ii  libxcb-icccm4 0.4.1-1
ii  libxcb-keysyms1   0.4.0-1
ii  libxcb-randr0 1.12-1
ii  libxcb-render01.12-1
ii  libxcb-shape0 1.12-1
ii  libxcb-util0  0.3.8-3
ii  libxcb-xinerama0  1.12-1
ii  libxcb-xkb1   1.12-1
ii  libxcb-xrm0   1.0-2
ii  libxcb-xtest0 1.12-1
ii  libxcb1   1.12-1
ii  libxdg-basedir1   1.2.0-1
ii  libxkbcommon-x11-00.7.1-1
ii  libxkbcommon0 0.7.1-1
ii  lua-lgi   0.9.1-1
ii  menu  2.1.47

Versions of packages awesome recommends:
ii  feh2.18-1
ii  rlwrap 0.42-3
ii  x11-xserver-utils  7.7+7

awesome suggests no packages.

-- no debconf information



Bug#824698: Debian bug #824698: redir and vagrant-lxc

2017-01-21 Thread Joachim Nilsson

Hi Antonio,

sorry for not noticing your comment on #824698 regarding vagrant-lxc and 
redir earlier!


I've just finished adding an --enable-compat to the redir configure 
script.  Only some testing remains before releasing v3.1


Best regards
 /Joachim



Bug#848141: diffoscope: diff output in markdown format

2017-01-21 Thread Chris Lamb
tags 848141 + pending
thanks

Pending release:

  
https://anonscm.debian.org/git/reproducible/diffoscope.git/commit/?id=42b7de5adf56e8c06e166c732f59d22b16931457

Regards,

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



Bug#851963: linux: enable SENSORS_ADM1031

2017-01-21 Thread James Cowgill
On 21/01/17 10:29, Roger Shimizu wrote:
> On Sat, Jan 21, 2017 at 6:05 PM, James Cowgill  wrote:
>> Hi,
>>
>> On 21/01/17 08:05, Roger Shimizu wrote:
>>> Control: tag -1 +moreinfo
>>>
>>> On Fri, Jan 20, 2017 at 9:17 PM, James Cowgill  wrote:
 Source: linux
 Version: 4.9.2-2
 Severity: wishlist

 Hi,

 Please can you enable CONFIG_SENSORS_ADM1031 as a module.

 I have a Cavium Octeon board which needs this driver to be able to read
 the CPU temperature / fan sensors.
>>>
>>> I see this module already exists in the kernel you're using.
>>> Can you help to confirm?
>>
>> I'm pretty certain it's not enabled. It is already enabled on x86 however.
> 
> Sorry, I just looked at amd64.
> So you're asking for mips64 octeon support, right?

Yes I am (although this isn't really MIPS specific, the board I have
just happens to use it).

James



signature.asc
Description: OpenPGP digital signature


Bug#852070: smemstat: The smemstat command crashes on ARM based machine

2017-01-21 Thread Miroslav Mitevski
It is 32 bit

Below is the content of /proc/cpuinfo

processor   : 0
model name  : Feroceon 88FR131 rev 1 (v5l)
BogoMIPS: 1974.27
Features: swp half thumb fastmult edsp
CPU implementer : 0x56
CPU architecture: 5TE
CPU variant : 0x2
CPU part: 0x131
CPU revision: 1

Hardware: QNAP TS-119/TS-219
Revision: 
Serial  : 

Regards,
Miro

> On 21.01.2017 г., at 12:32, Colin Ian King  wrote:
> 
> Hi Miroslav,
> 
> Is that a 32 bit ARM platform?
> 
> How are you running smemstat?
> 
> Can you re-run smemstat using strace and capturing the output and adding
> that to the bug report?
> 
> e.g.
> 
> strace smemstat >& smemstat.log
> 
> please can you use the same smemstat options that reproduce the bug.
> 
> Thanks!
> 
> On 21/01/17 10:19, Miroslav Mitevski wrote:
>> Package: smemstat
>> Version: 0.01.10-1
>> Severity: important
>> 
>> Dear Maintainer,
>> 
>> after installing the package from the official Debian repository and 
>> executing the smemstat command on ARM based machine I discovered the 
>> following error:
>> 
>> The expectation is program to list running processes with the memory usage. 
>> Unfortunately the program crashes with "Segmentation fault".
>> 
>> There are no logs or additional error messages.
>> 
>> The Debian installation is on QNAP 219P II device, which is ARM based.
>> 
>> Current locale of the system is bg_BG.UTF-8
>> 
>> Itried with en_US.UTF-8 and "C" - the result was the same.
>> 
>> Regards,
>> Miro
>> 
>> 
>> *** Reporter, please consider answering these questions, where appropriate 
>> ***
>> 
>>   * What was the outcome of this action?
>>   * What outcome did you expect instead?
>> 
>> *** End of the template - remove these template lines ***
>> 
>> 
>> -- System Information:
>> Debian Release: 8.7
>>  APT prefers stable-updates
>>  APT policy: (500, 'stable-updates'), (500, 'stable')
>> Architecture: armel (armv5tel)
>> 
>> Kernel: Linux 3.16.0-4-kirkwood
>> Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: systemd (via /run/systemd/system)
>> 
>> Versions of packages smemstat depends on:
>> ii  libc6  2.19-18+deb8u7
>> 
>> smemstat recommends no packages.
>> 
>> smemstat suggests no packages.
>> 
>> -- no debconf information
>> 
> 



Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

2017-01-21 Thread Fabian Greffrath
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I admit it's a bit hard to argue against three, but I'll try anyway. ;)

Am Mittwoch, den 18.01.2017, 01:12 + schrieb Scott Kitterman:
> DFSG #2 requires that "The program must include source
> code".  Preferred form of modification is the definition of source
> that the FTP team uses.  For Debian DFSG purposes it's not
> exclusively GPL relevant.

Is this the FTP Masters' position on this issue or your personal
opinion?

> FYI, you are mistaken that C code is always "source". C is sometimes
> generated from other forms, via transpilers or lexer generators etc.
> It can also be obfuscated C code from the real C source (cf #383465).
> [...]
> So like C, OTF can be source or not source, depending on the upstream
> project.

I find this by far the most convincing argument, although I still find
it difficult to accept that it should make a difference for Debian as a
mere downstream distributor. We provide many packages with fonts in OTF
format and while this is acepted as a proper source for some, it is not
for others because of upstream design decisions?

> It is unfortunate that the gsfonts upstream didn't ask the right
> questions before integrating these files into the project. They
> really
> should have done that. At that point in time we would have to remove
> the URW++ fonts from Debian since we would not be in compliance with
> the GPL.

Well, RMS himself told me that the Type1 format in which the fonts are
distributed is considered a proper source format. Apparently he doesn't
even care about what tools upstream used to create the fonts as long as
they are distributed in a proper source format.

> Please try to submit a git commit to Firacode upstream containing
> only
> changes to the generated files. Then you will see that this phrase
> has
> meaning in any software context, including in the world of fonts and
> Firacode in particular.

Agreed, but I don't think that this (i.e. "is it easy or even possible
to create a patch that upstream would outright accept in that form?")
should be a criterion to decide if a package is suitable for Debian
main or not (as long as it is possible to create the patch in the first
place, that is).

Cheers,

Fabian
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAliDSGYACgkQy+qOlwzN
Wd8qwxAAwWmJj0YOLdxQsBhXZh7mzC+LcvY3N04MVHPHNgkIsuAuw3LhU4pHf5xC
saninfv7e7GZ29na7i75Ug26v6FS+/3aE7Fej+np1m5pjeVAuvgtzMw4B/lKEeXb
UvoTwvLHSKVB1mrGWe4Bu1HU8mDFOn23dZyJmvDoaRxf4OkHcBtPHUkD7FZ35P70
t0GAEAnhAsAKyzFCsdEBGfdH8SGvw+UhHwhC31aGdCWv6to/CHsUd89HTmW2Ky0o
QZh/4pkHK7qnX+2Zd6C0WXDdhDVNLFHyYrZT/h8LbFYozLJROksncwIMOKmGhIrK
/pYKsqfTKshXO8X0luaQbJHCbldtyv/LbUMVmBGwr24a0+HS5rUPwM5AIhwu6MCk
qx4W5vaifunhkxr8Z6CMwBgkKzaK7MZB4BBh+D/C5XbSHcOZHf8HoE65btM8BZyd
8PIEWHZedUAt+HjYkY4RQfdV18XJHkVRiKK2VxCfTWz9bRF/y2+MmXF3/Cd0R09G
jrsxW0vsUFp3WaJXTJw3P810deSYvCJpwXAsTvzApHMvTSY9kal+xKVq9moEU34+
dvTtfV9ABf8ETooEd9FRk5R0Q+63aBoK8wU8dkzOP557UPuBeOfXqwBczi2WG4tR
1YzraE5mYf2VonXN8HanePQMC4QpmdZhV/+ds6f5AnbGu56372U=
=Qgwt
-END PGP SIGNATURE-



Bug#852076: mpgrafic: mips build of mpgrafic gives zero record size

2017-01-21 Thread Boud Roukema

Package: mpgrafic
Version: 0.3.7.8-1
Severity: serious
Tags: upstream
Justification: fails to build from source

Dear Maintainer,

Description:

After installing mpgrafics-0.3.7.8-1 on mips by the debian buildd system,
`make check' runs `regression-test-0.3.7.8.sh', which runs
`mpirun -n 1 --mca plm_rsh_agent sh ${srcdir}/src/mpgrafic --np=32 < 
${srcdir}/Input.stdin
and gives the output:

 Record size0  is different from expected4096

and then fatally exits (as it should in such a case).

Log:

https://buildd.debian.org/status/fetch.php?pkg=mpgrafic&arch=mips&ver=0.3.7.8-1&stamp=1484927169&raw=0
(line 1010 of the raw html file)

Analysis:

The error is presumably triggered at line 308 (v0.3.7.8-1) of
src/grafic_io.f90 - taille_tampon is read by f77_parallel_read() in
src/parallel_io.c .  The function f77_parallel_read() is a front end to
parallel_read(), in the same .c file, which calls pread()  to read
bytes from a disk file into a buffer.

The disk file is (previously to this) written by a similar hierarchy
of f90 and C functions to `white-outfile.dat' (assuming that
`Input.stdin' is the source package input file above).

Hypothesis:

This looks like an endianness/word size problem - bytes are written to
disk and read from disk as a raw sequence of bytes without any
casting, neither in writing nor in reading.

Proposed solution method:

On a real or emulated mips machine, a quick hack would be to play
around with casting and byte-swapping to find a way that the test
script is successful.

An acceptable solution would be to make changes that are not
machine dependent. The AC_C_BIGENDIAN should probably be added to configure.ac
and then the preprocessor macro WORDS_BIGENDIAN could be used.
See the autoconf documentation for details.

Appropriate use of casting and USE_ISO_C in src/grafic_io.f90 would
probably give a more elegant and robust solution in terms of
portability.

-- System Information:
Debian Release: sid
Architecture: mips



Bug#851884: RFS: fdkaac/0.6.3-1

2017-01-21 Thread Marius Gavrilescu
Sean Whitton  writes:

> Seems not:
>
> iris ~/rfs/fdkaac % git pull
> Already up-to-date.
> iris ~/rfs/fdkaac % git log -1
> commit c7da92702d4b4c4d7b63d50f7c29654e210c38ef
> Author: Marius Gavrilescu 
> Date:   Thu Jan 19 18:00:43 2017 +0200
> 
> Undo addition of XS-Autobuild: yes

Dear Sean,

Seems to be a caching issue on my end. Repo was updated, but Varnish was
still serving the old version. Seems to be working now, please tell me
if that is not the case.

Thanks,
-- 
Marius Gavrilescu


signature.asc
Description: PGP signature


Bug#852070: smemstat: The smemstat command crashes on ARM based machine

2017-01-21 Thread Miroslav Mitevski
I suspect the program hangs when the smemstat tries to read data about it’s own 
process.
> On 21.01.2017 г., at 13:46, Miroslav Mitevski  
> wrote:
> 
> The issue is reproduced when the command is executed as root only.
> 
> Attaching the log from strace.
> 
> Regards,
> Miro
> 
>> On 21.01.2017 г., at 13:33, Miroslav Mitevski  
>> wrote:
>> 
>> It is 32 bit
>> 
>> Below is the content of /proc/cpuinfo
>> 
>> processor: 0
>> model name   : Feroceon 88FR131 rev 1 (v5l)
>> BogoMIPS : 1974.27
>> Features : swp half thumb fastmult edsp
>> CPU implementer  : 0x56
>> CPU architecture: 5TE
>> CPU variant  : 0x2
>> CPU part : 0x131
>> CPU revision : 1
>> 
>> Hardware : QNAP TS-119/TS-219
>> Revision : 
>> Serial   : 
>> 
>> Regards,
>> Miro
>> 
>>> On 21.01.2017 г., at 12:32, Colin Ian King  wrote:
>>> 
>>> Hi Miroslav,
>>> 
>>> Is that a 32 bit ARM platform?
>>> 
>>> How are you running smemstat?
>>> 
>>> Can you re-run smemstat using strace and capturing the output and adding
>>> that to the bug report?
>>> 
>>> e.g.
>>> 
>>> strace smemstat >& smemstat.log
>>> 
>>> please can you use the same smemstat options that reproduce the bug.
>>> 
>>> Thanks!
>>> 
>>> On 21/01/17 10:19, Miroslav Mitevski wrote:
 Package: smemstat
 Version: 0.01.10-1
 Severity: important
 
 Dear Maintainer,
 
 after installing the package from the official Debian repository and 
 executing the smemstat command on ARM based machine I discovered the 
 following error:
 
 The expectation is program to list running processes with the memory 
 usage. Unfortunately the program crashes with "Segmentation fault".
 
 There are no logs or additional error messages.
 
 The Debian installation is on QNAP 219P II device, which is ARM based.
 
 Current locale of the system is bg_BG.UTF-8
 
 Itried with en_US.UTF-8 and "C" - the result was the same.
 
 Regards,
 Miro
 
 
 *** Reporter, please consider answering these questions, where appropriate 
 ***
 
 * What was the outcome of this action?
 * What outcome did you expect instead?
 
 *** End of the template - remove these template lines ***
 
 
 -- System Information:
 Debian Release: 8.7
 APT prefers stable-updates
 APT policy: (500, 'stable-updates'), (500, 'stable')
 Architecture: armel (armv5tel)
 
 Kernel: Linux 3.16.0-4-kirkwood
 Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
 Shell: /bin/sh linked to /bin/dash
 Init: systemd (via /run/systemd/system)
 
 Versions of packages smemstat depends on:
 ii  libc6  2.19-18+deb8u7
 
 smemstat recommends no packages.
 
 smemstat suggests no packages.
 
 -- no debconf information
 
>>> 
>> 
> 



Bug#852077: [src:libint2] What about packaging basisset definition files?

2017-01-21 Thread Katsuhiko Nishimra
Package: src:libint2
Version: 2.3.0~beta3-2
Severity: wishlist
Tags: patch

Dear maintainer,

As you probably know, libint2 has a feature to setup basisset objects by
the basisset name like code below, using bundled basisset definition files.
 libint2::BasisSet obs("cc-pVDZ", atoms);

What do you think about packaging the basisset definition files in
libint2-data package or something like that? I'm believing basisset
definition files can be considered under public domain as they are
scientific data, but I'm not very sure that there is no copyright issue.

I'm attaching a patch for this, and for some additional issues I've
found. I hope this will help you.

By the way, thank you very much for your quick fixing #851546. But it
is still marked as open, just in case you have not noticed. 

Kind regards.
diff -Nru libint2-2.3.0~beta3/debian/changelog 
libint2-2.3.0~beta3/debian/changelog
--- libint2-2.3.0~beta3/debian/changelog2017-01-21 04:40:07.0 
+0900
+++ libint2-2.3.0~beta3/debian/changelog2017-01-21 15:31:07.0 
+0900
@@ -1,3 +1,15 @@
+libint2 (2.3.0~beta3-2+basisset0) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Install basisset definition files via libint2-data package.
+  * Install document files from the upstream.
+  * Respect DEB_BUILD_OPTIONS=parallel.
+  * Avoid using convenience copy from boost.
+  * debian/watch: Scan the upstream github repository.
+  * Fix comma separated file list in the debian/copyright file.
+
+ -- Katsuhiko Nishimra   Sat, 21 Jan 2017 15:31:07 +0900
+
 libint2 (2.3.0~beta3-2) unstable; urgency=medium
 
   * Upload to unstable. 
diff -Nru libint2-2.3.0~beta3/debian/control libint2-2.3.0~beta3/debian/control
--- libint2-2.3.0~beta3/debian/control  2016-10-02 06:37:03.0 +0900
+++ libint2-2.3.0~beta3/debian/control  2017-01-21 15:31:07.0 +0900
@@ -14,6 +14,7 @@
 Section: libs
 Architecture: any
 Depends: ${shlibs:Depends}, ${misc:Depends}
+Recommends: libint2-data (=${binary:Version})
 Description: Computation Chemistry Integral Evaluation Library
  The LIBINT library is used to evaluate the traditional (electron repulsion)
  and certain novel two-body matrix elements (integrals) over Cartesian
@@ -34,7 +35,7 @@
 Package: libint2-dev
 Section: libdevel
 Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, libint2-2 (= ${binary:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, libint2-2 (= ${binary:Version}), 
libboost-dev
 Description: Computation Chemistry Integral Evaluation Library (development 
files)
  The Libint2 library is used to evaluate the traditional (electron 
  repulsion) and certain novel two-body matrix elements (integrals) over
@@ -51,3 +52,24 @@
  doubles (CCSD) method, as well as explicitly correlated R12 methods.
  .
  This package contains the static library and header files.
+
+Package: libint2-data
+Architecture: all
+Depends: ${misc:Depends}
+Recommends: libint2-2 (= ${binary:Version})
+Description: Computation Chemistry Integral Evaluation Library (data files)
+ The Libint2 library is used to evaluate the traditional (electron 
+ repulsion) and certain novel two-body matrix elements (integrals) over
+ Cartesian Gaussian functions used in modern atomic and molecular
+ theory.  The idea of the library is to let computer write optimized
+ code for computing such integrals. There are two primary advantages to
+ this: much less human effort is required to write code for computing
+ new integrals, and code can be optimized specifically for a particular
+ computer architecture (e.g., vector processor).
+ .
+ Libint2 has been utilized to implement methods such as Hartree-Fock
+ (HF) and Kohn-Sham density functional theory (KS DFT), second-order
+ Moeller-Plesset perturbation theory (MP2), coupled cluster singles and
+ doubles (CCSD) method, as well as explicitly correlated R12 methods.
+ .
+ This package contains basis set definition files.
diff -Nru libint2-2.3.0~beta3/debian/copyright 
libint2-2.3.0~beta3/debian/copyright
--- libint2-2.3.0~beta3/debian/copyright2015-09-02 21:30:13.0 
+0900
+++ libint2-2.3.0~beta3/debian/copyright2017-01-21 15:31:07.0 
+0900
@@ -10,7 +10,7 @@
 Copyright: Curtis Janssen
 License: GPL-2+
 
-Files: include/util_types.h, tests/*
+Files: include/util_types.h tests/*
 Copyright: 2004-2014 Edward F. Valeev
 License: GPL-2+
 
diff -Nru libint2-2.3.0~beta3/debian/libint2-2.docs 
libint2-2.3.0~beta3/debian/libint2-2.docs
--- libint2-2.3.0~beta3/debian/libint2-2.docs   1970-01-01 09:00:00.0 
+0900
+++ libint2-2.3.0~beta3/debian/libint2-2.docs   2017-01-21 15:29:11.0 
+0900
@@ -0,0 +1,2 @@
+CITATION
+README.md
diff -Nru libint2-2.3.0~beta3/debian/libint2-data.install 
libint2-2.3.0~beta3/debian/libint2-data.install
--- libint2-2.3.0~beta3/debian/libint2-data.install 1970-01-01 
09:00:00.0 +0900
+++ libint2-2.3.0~beta3/debian/libint2-data.install 2017-01-21 
15:29:11.0 +0900
@@ -0,0 +1 @@

Bug#852078: src:python-mkdocs: New upstream release (0.16.x)

2017-01-21 Thread Ghislain Antony Vaillant
Package: src:python-mkdocs
Severity: wishlist

Dear Maintainer,

A new version is available upstream [1]. Please consider packaging it,
perhaps in time for Stretch?

https://github.com/mkdocs/mkdocs/releases/tag/0.16.1

Thanks,
Ghis


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

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



Bug#851015: nut: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

2017-01-21 Thread Michael Stapelberg
Thanks! Let me know if you can’t get around to it, and I’ll be happy
to give a hand.

On Thu, Jan 19, 2017 at 8:47 PM, Laurent Bigonville  wrote:
> Le 19/01/17 à 19:52, Michael Stapelberg a écrit :
>>
>> [+aquette, bigon directly]
>>
>> Are you aware of this issue? This RC bug transitively marked freeradius
>> for removal from testing. If you need help, please let me know — I have
>> some incentive to look into it in order to keep freeradius in stretch.
>
> Apparently it lacks of asciidoc-dblatex build-dependency
>
> I'll try do an upload tonight



-- 
Best regards,
Michael



Bug#733304: wput: stack smashing detected

2017-01-21 Thread Pooly
Hi,

Can you reopen the bug?
Issue is still present in the latest package. Now every file I try to
backup crashes wput.

wput -p -a wput-daily.log -B --timestamping --reupload --dont-continue
/root/tmp/backup.tar.bz2 ftp://$login:$pas...@backupserver.net/


trace:

*** stack smashing detected ***: wput terminated
=== Backtrace: =
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0x6c773)[0xb75be773]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__fortify_fail+0x45)[0xb764e9b5]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(+0xfc96a)[0xb764e96a]
wput(+0xf3c4)[0xb773a3c4]
wput(+0x8fab)[0xb7733fab]
wput(+0x7e9f)[0xb7732e9f]
wput(+0x8819)[0xb7733819]
wput(+0x888c)[0xb773388c]
wput(+0x89e5)[0xb77339e5]
wput(+0x4a35)[0xb772fa35]
wput(+0x5c74)[0xb7730c74]
wput(+0xd35e)[0xb773835e]
wput(main+0x2cd)[0xb772cdfd]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xf3)[0xb756ba63]
wput(+0x2351)[0xb772d351]
=== Memory map: 
b7346000-b7362000 r-xp  08:03 520284
/lib/i386-linux-gnu/libgcc_s.so.1
b7362000-b7363000 rw-p 0001b000 08:03 520284
/lib/i386-linux-gnu/libgcc_s.so.1
b7369000-b738f000 r--p  08:05 260449
/usr/share/locale/fr/LC_MESSAGES/libc.mo
b738f000-b73a2000 r-xp  08:03 520637
/lib/i386-linux-gnu/i686/cmov/libresolv-2.19.so
b73a2000-b73a4000 r--p 00012000 08:03 520637
/lib/i386-linux-gnu/i686/cmov/libresolv-2.19.so
b73a4000-b73a5000 rw-p 00014000 08:03 520637
/lib/i386-linux-gnu/i686/cmov/libresolv-2.19.so
b73a5000-b73a7000 rw-p  00:00 0
b73a7000-b73ac000 r-xp  08:03 520593
/lib/i386-linux-gnu/i686/cmov/libnss_dns-2.19.so
b73ac000-b73ad000 r--p 4000 08:03 520593
/lib/i386-linux-gnu/i686/cmov/libnss_dns-2.19.so
b73ad000-b73ae000 rw-p 5000 08:03 520593
/lib/i386-linux-gnu/i686/cmov/libnss_dns-2.19.so
b73ae000-b73b9000 r-xp  08:03 520597
/lib/i386-linux-gnu/i686/cmov/libnss_files-2.19.so
b73b9000-b73ba000 r--p a000 08:03 520597
/lib/i386-linux-gnu/i686/cmov/libnss_files-2.19.so
b73ba000-b73bb000 rw-p b000 08:03 520597
/lib/i386-linux-gnu/i686/cmov/libnss_files-2.19.so
b73c-b73c1000 rw-p  00:00 0
b73c1000-b73c8000 r--s  08:05 528120
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache
b73c8000-b7551000 r--p  08:05 522007
/usr/lib/locale/locale-archive
b7551000-b7552000 rw-p  00:00 0
b7552000-b76f9000 r-xp  08:03 520515
/lib/i386-linux-gnu/i686/cmov/libc-2.19.so
b76f9000-b76fb000 r--p 001a7000 08:03 520515
/lib/i386-linux-gnu/i686/cmov/libc-2.19.so
b76fb000-b76fc000 rw-p 001a9000 08:03 520515
/lib/i386-linux-gnu/i686/cmov/libc-2.19.so
b76fc000-b770 rw-p  00:00 0
b770-b7705000 r--p  08:05 260082
/usr/share/locale/fr/LC_MESSAGES/wput.mo
b7705000-b7707000 rw-p  00:00 0
b7707000-b7708000 r-xp  00:00 0  [vdso]
b7708000-b770a000 r--p  00:00 0  [vvar]
b770a000-b7729000 r-xp  08:03 520309 /lib/i386-linux-gnu/
ld-2.19.so
b7729000-b772a000 r--p 0001f000 08:03 520309 /lib/i386-linux-gnu/
ld-2.19.so
b772a000-b772b000 rw-p 0002 08:03 520309 /lib/i386-linux-gnu/
ld-2.19.so
b772b000-b7744000 r-xp  08:05 129613 /usr/bin/wput
b7744000-b7745000 r--p 00018000 08:05 129613 /usr/bin/wput
b7745000-b7746000 rw-p 00019000 08:05 129613 /usr/bin/wput
b9616000-b9637000 rw-p  00:00 0  [heap]
bfbb2000-bfbd3000 rw-p  00:00 0  [stack]
Abandon


root@w-fenec:~# dpkg -l | grep wput
ii  wput   0.6.2+git20130413-2+b1i386
  tiny wget-like ftp-client for uploading files



-- 
http://www.w-fenec.org : webzine rock metal indus


Bug#733304: wput: stack smashing detected

2017-01-21 Thread Stephen Kitt
On Sat, 21 Jan 2017 12:34:44 +, Pooly  wrote:
> Can you reopen the bug?
> Issue is still present in the latest package. Now every file I try to
> backup crashes wput.

The bug was fixed in 0.6.2+git20130413-4, but you have an older package:

> root@w-fenec:~# dpkg -l | grep wput
> ii  wput   0.6.2+git20130413-2+b1i386
>   tiny wget-like ftp-client for uploading files

Could you download -4 from
https://packages.debian.org/stretch/i386/wput/download and see if the bug
still occurs with that version?

Regards,

Stephen


pgpuZAaAmxILC.pgp
Description: OpenPGP digital signature


Bug#852079: RFP: universal media server -- upnp dlna server

2017-01-21 Thread Aldrin P. S. Castro
Package: universal media server
Severity: wishlist


Universal Media Server is a media server capable of serving videos, audio
and images to any DLNA-capable device.

It is free, regularly updated and has more features than any other media
server, including paid media servers.

It streams to many devices including Sony PlayStation 3 (PS3) and
PlayStation 4 (PS4), Microsoft Xbox One and 360, many TVs (Samsung,
Panasonic, Sony, Vizio, LG, Philips, Sharp), smart phones (iPhone, Android,
etc.), Blu-ray players, and more.

* URL: www.universalmediaserver.com


Bug#852080: rsync might start before network is setup, cannot bind to certain IPs

2017-01-21 Thread Marcos Dione
Package: rsync
Version: 3.1.2-1
Severity: normal
Tags: patch


The service must be run after the network target, otherwise it can't
bind to only certain IP addresses. The patch is a oneliner (attached).


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

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

Versions of packages rsync depends on:
ii  base-files   9.7
ii  init-system-helpers  1.46
ii  libacl1  2.2.52-3
ii  libattr1 1:2.4.47-2
ii  libc62.24-8
ii  libpopt0 1.16-10
ii  lsb-base 9.20161125

rsync recommends no packages.

Versions of packages rsync suggests:
ii  openssh-client  1:7.3p1-5
ii  openssh-server  1:7.3p1-5

-- Configuration Files:
/etc/default/rsync changed:
RSYNC_ENABLE=true
RSYNC_OPTS=''
RSYNC_NICE=''
RSYNC_IONICE='-c3'


/etc/rsyncd.conf:
address= 10.42.27.42


-- 
(Not so) Random fortune:
Terrorism isn't a crime against people or property. It's a crime against
our minds, using the death of innocents and destruction of property to
make us fearful.
-- Bruce Schneier
--- /lib/systemd/system/rsync.service   2014-02-24 19:19:14.0 +0100
+++ rsync.service   2017-01-21 13:44:30.185460453 +0100
@@ -1,6 +1,7 @@
 [Unit]
 Description=fast remote file copy program daemon
 ConditionPathExists=/etc/rsyncd.conf
+After=network.target

 [Service]
 ExecStart=/usr/bin/rsync --daemon --no-detach


Bug#850299: libgnupg-perl: FTBFS randomly (not enough entropy)

2017-01-21 Thread Santiago Vila
Hi.

I can confirm that lack of entropy is indeed the problem.

Since I'm using sbuild, I added this line to /etc/schroot/default/fstab:

/dev/urandom/dev/random nonerw,bind 0   0

then tried to build this package 100 times, and I got 100 successful
builds (and a lot faster than ever).

I wonder if we can really assume that an autobuilder will always have
enough "entropy", like we do for memory.

Apparently we implicitly assume such thing, but I still think we should not.
For example: Does this package really need to generate a key at build
time? It may not be pregenerated and used during the build, like other
packages do? (mini-buildd comes to mind).

Thanks.



Bug#852068: libgeo-coder-googlev3-perl: autopkgtest failure: Brandenburger Tor vs Pariser Platz

2017-01-21 Thread gregor herrmann
On Sat, 21 Jan 2017 12:13:21 +0200, Niko Tyni wrote:

> This package recently started failing its autopkgtest test suite
> on ci.debian.net.
>   
> https://ci.debian.net/packages/libg/libgeo-coder-googlev3-perl/unstable/amd64/
> 

> This seems to be fixed upstream:
>  Changes for version 0.15

Thanks!
0.15-1 uploaded.
 
> I see the build process sets NO_NETWORK=1 so the build still succeeds.
> Clearly one fix would be do that for autopkgtest as well. I'm not quite
> sure what the current consensus is on network access during autopkgtest...

Good question.
I think there's no real consensus in the project, and in our packages
we also see both variants (allow network tests vs. turn them off) ...


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Don McLean: That's All Right


signature.asc
Description: Digital Signature


Bug#851826: pulseaudio: USB headset detected, but no sound

2017-01-21 Thread Felipe Sateler
Hi,

On Jan 21, 2017 00:24, "Michael Haag"  wrote:

Sorry it took so long to reply. My ISP was switching our service, so I
was without Internet access for a time. Please see attached screenshots.


You did not have an audio-using application when you took the screenshot.
Please open an audio player, start playing something, and check the
Playback tab. In there you can choose what device the player will play
through.


Saludos,
Felipe Sateler


Bug#851339: [Pkg-fonts-devel] Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

2017-01-21 Thread Jonas Smedegaard
Quoting Fabian Greffrath (2017-01-21 12:39:17)
>> FYI, you are mistaken that C code is always "source". C is sometimes 
>> generated from other forms, via transpilers or lexer generators etc. 
>> It can also be obfuscated C code from the real C source (cf #383465).
>> [...]
>> So like C, OTF can be source or not source, depending on the upstream 
>> project.
>
> I find this by far the most convincing argument, although I still find 
> it difficult to accept that it should make a difference for Debian as 
> a mere downstream distributor. We provide many packages with fonts in 
> OTF format and while this is acepted as a proper source for some, it 
> is not for others because of upstream design decisions?

I agree it feels weird that some fonts are fine to distribute as-is in 
Debian whereas other fonts using same format cannot - simply because we 
are aware that a different format is used for upstream development.

But I believe this is not a unique oddity.  A more common equivalent is 
makefiles, some of which are hand-written and others are auto-generated.  

"is used as source upstream" and "can be used as source downstream" are 
different things, and I believe Debian Policy talks about the former.


 - 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#851015: nut: FTBFS: a2x: ERROR: missing configuration file: /etc/asciidoc/dblatex/asciidoc-dblatex.xsl

2017-01-21 Thread Laurent Bigonville

I've comited the change, but it still FTBFS due to #852023


Le 21/01/17 à 13:23, Michael Stapelberg a écrit :

Thanks! Let me know if you can’t get around to it, and I’ll be happy
to give a hand.

On Thu, Jan 19, 2017 at 8:47 PM, Laurent Bigonville  wrote:

Le 19/01/17 à 19:52, Michael Stapelberg a écrit :

[+aquette, bigon directly]

Are you aware of this issue? This RC bug transitively marked freeradius
for removal from testing. If you need help, please let me know — I have
some incentive to look into it in order to keep freeradius in stretch.

Apparently it lacks of asciidoc-dblatex build-dependency

I'll try do an upload tonight







Bug#850299: libgnupg-perl: FTBFS randomly (not enough entropy)

2017-01-21 Thread gregor herrmann
On Sat, 21 Jan 2017 14:01:20 +0100, Santiago Vila wrote:

> I wonder if we can really assume that an autobuilder will always have
> enough "entropy", like we do for memory.

Yup, that's a good question ...
 
> Apparently we implicitly assume such thing, but I still think we should not.
> For example: Does this package really need to generate a key at build
> time? It may not be pregenerated and used during the build, like other
> packages do? (mini-buildd comes to mind).

The package has support for various gpg operations, and tests them.
This involves key generation, and signing/verifying,
encrypting/decrypting.

When I looked at this issue after you filed the bug, I tried to just
disable the key generation test, which is easy but not helpful
because some other tests then fail because of the missing key.

So yeah, maybe a pre-generated key would be a compromise ...


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Bob Dylan: Drifter's Escape


signature.asc
Description: Digital Signature


Bug#851784: [Pkg-nginx-maintainers] Bug#851784: libnginx-mod-http-dav-ext: unknown directive "dav_ext_methods"

2017-01-21 Thread Ñãzãr
Hello Christos,

Thanks for replying. I'm actually trying to install on a mixed
wheezy/jessie armhf system, a WDMyCloud NAS. Today I re-compiled both
1.10.2-2 and 1.11.8-1~exp1 from the deb-src on my dev system but this time
I removed the "dav-ext dynamic module" patch:

cd nginx_1.*/debian/;
rm -rf ./patches/modules/nginx-dav-ext-module/ ./libnginx-mod-http-dav-ext.
nginx;
cd .. && dpkg-buildpackage -b;

Using these re-compiled nginx-full package with the "dav-ext dynamic
module" patch removed (both 1.10.2-2 and 1.11.8-1~exp1), I can use the
dav_ext_methods directive without errors.

I'm wondering if you could help to point out what causes this "unknown
directive" issue on my system when the dav-ext is separated as a loaded
module (load_module modules/ngx_http_dav_ext_module.so;) because I have all
the dependencies met.

Thank you.


Bug#813658: virglrenderer support before the freeze?

2017-01-21 Thread Michael Neuffer
On Mon, 14 Nov 2016 19:39:22 +0100 Andreas Cadhalpun
 wrote:
> The only additional dependencies compared to the current
> qemu-system-x86 package are:
> libdrm2 libepoxy0 libexpat1 libgbm1 libvirglrenderer0
> libwayland-client0 libwayland-server0
>
> That doesn't seem excessive to me.

I am tracking testing. I'll show you the new dependencies pulled in by
the qemu-system-x86 package.
When talking about dependencies do not only look at direct dependencies,
but at the whole dependency tree.
We are talking about a HUGE number of additional packages and an
increased attack surface here.

This is for qemu-system-x86 1:2.7+dfsg-3+b1 --> 1:2.8+dfsg-1

I cringe at the thought that I have to install all these packages for
quemu on what were once a really lean and clean servers
just hosting virtual machines on the net. They are getting cluttered and
keeping them secure becomes harder and harder.

A headless console-only version is surgently needed.

EIOM Pri Section  Package  Description
  _* Opt otherosf qemu-system- QEMU full system emulation binaries
(x86)   
  

  _* Opt libs libcairo2Cairo 2D vector graphics library
  _* Opt libs libepoxy0OpenGL function pointer management library
  _* Opt libs libgbm1  generic buffer management API -- runtime
  _* Opt libs libgdk-pixbu GDK Pixbuf library
  _* Opt libs libgtk-3-0   GTK+ graphical user interface library
  _* Xtr libs libvirglrend virtual GPU for KVM virtualization
  _* Opt libs libvte-2.91- Terminal emulator widget for GTK+ 3.0 -
runtime files
  __ Opt net  sambaSMB/CIFS file, print, and login server
for Unix
  __ Opt net  vde2 Virtual Distributed Ethernet
  __ Opt otherosf qemu-block-e extra block backend modules for
qemu-system and qemu-utils
  __ Opt otherosf sgabios  bios option rom to provide legacy serial
console for x86
  __ Xtr misc ovmf UEFI firmware for 64-bit x86 virtual machines
  _* Opt libs libfontconfi generic font configuration library - runtime
  _* Opt libs libxcb-rende X C Binding, render extension
  _* Opt libs libxcb-shm0  X C Binding, shm extension
  _* Opt libs libxrender1  X Rendering Extension client library
  _* Opt libs libdrm2  Userspace interface to kernel DRM
services -- runtime
  _* Opt libs libwayland-c wayland compositor infrastructure -
client library
  _* Opt libs libwayland-s wayland compositor infrastructure -
server library
  _* Opt libs libtiff5 Tag Image File Format (TIFF) library
  _* Opt misc shared-mime- FreeDesktop.org shared MIME database and spec
  _* Opt libs libgdk-pixbu GDK Pixbuf library - data files
  _* Opt misc libgtk-3-com common files for the GTK+ graphical user
interface library
  _* Opt libs libatk-bridg AT-SPI 2 toolkit bridge - shared library
  _* Opt libs libatk1.0-0  ATK accessibility toolkit
  _* Opt libs libcairo-gob Cairo 2D vector graphics library (GObject
library)
  _* Opt libs libcolord2   system service to manage device colour
profiles -- runtime
  _* Opt libs libcups2 Common UNIX Printing System(tm) - Core
library
  _* Opt libs libjson-glib GLib JSON manipulation library
  _* Opt libs libpango-1.0 Layout and rendering of internationalized
text
  _* Opt libs libpangocair Layout and rendering of internationalized
text
  _* Opt libs libpangoft2- Layout and rendering of internationalized
text
  _* Opt libs librest-0.7- REST service access library
  _* Opt libs libsoup2.4-1 HTTP library implementation in C --
Shared library
  _* Opt libs libwayland-c wayland compositor infrastructure -
cursor library
  _* Opt libs libwayland-e implementation of the Wayland EGL
platform -- runtime
  _* Opt libs libxcomposit X11 Composite extension library
  _* Opt libs libxcursor1  X cursor management library
  _* Opt libs libxdamage1  X11 damaged region extension library
  _* Opt libs libxfixes3   X11 miscellaneous 'fixes' extension library
  _* Opt libs libxinerama1 X11 Xinerama extension library
  _* Opt libs libxkbcommon library interface to the XKB compiler -
shared library
  _* Opt libs libxrandr2   X11 RandR extension library
  _* Opt misc hicolor-icon default fallback theme for
FreeDesktop.org icon themes
  _* Opt gnomeadwaita-icon default icon theme of GNOME
  _* Opt misc libgtk-3-bin programs for the GTK+ graphical user
interface library
  _* Opt libs librsvg2-com SAX-based renderer library for SVG files
(extra runtime)
  __ Opt libs gvfs userspace virtual filesystem - GIO module
  _* Opt libs libpcre2-8-0 New Perl Compatible Regular Expression
Library- 8 bit runtime files
  _* Opt libs libvte-2.91- Terminal emulator widget for GTK+ 3.0 -
common files
 *** Opt otherosf qemu-utils   QEMU utilities
  _* Opt fontsfontconfig-c generic font configuration library -
configurat

Bug#852077: [Debichem-devel] Bug#852077: [src:libint2] What about packaging basisset definition files?

2017-01-21 Thread Michael Banck
Hi,

are you using libint2 yourself, and if so what project if I may ask?

On Sat, Jan 21, 2017 at 08:50:10PM +0900, Katsuhiko Nishimra wrote:
> As you probably know, libint2 has a feature to setup basisset objects
> by the basisset name like code below, using bundled basisset
> definition files.  libint2::BasisSet obs("cc-pVDZ", atoms);

I kinda noticed, but I wasn't sure whether those were just examples, for
test cases or generally useful.  If the latter is the case, I'm happy to
include them.
 
> What do you think about packaging the basisset definition files in
> libint2-data package or something like that? 

Happy to do that, but it's too late for stretch now, as no new packages
will enter at this point. So this will have to wait till after the
release.

> I'm believing basisset definition files can be considered under public
> domain as they are scientific data, but I'm not very sure that there
> is no copyright issue.

Typical issue, and personally, I am on the opinion of 'don't ask, don't
tell', when it comes to those data files.
 
> I'm attaching a patch for this, and for some additional issues I've
> found. I hope this will help you.

I'll take a look at the other changes once I have time, I am travelling
right now.
 
> By the way, thank you very much for your quick fixing #851546. But it
> is still marked as open, just in case you have not noticed. 

Ah right, I've closed it now, thanks.


Best,

Michael



Bug#851339: [Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

2017-01-21 Thread Scott Kitterman


On January 21, 2017 6:39:17 AM EST, Fabian Greffrath  wrote:
>-BEGIN PGP SIGNED MESSAGE-
>Hash: SHA256
>
>I admit it's a bit hard to argue against three, but I'll try anyway. ;)
>
>Am Mittwoch, den 18.01.2017, 01:12 + schrieb Scott Kitterman:
>> DFSG #2 requires that "The program must include source
>> code".  Preferred form of modification is the definition of source
>> that the FTP team uses.  For Debian DFSG purposes it's not
>> exclusively GPL relevant.
>
>Is this the FTP Masters' position on this issue or your personal
>opinion?

That's the FTP Masters' position.

Scott K


>> FYI, you are mistaken that C code is always "source". C is sometimes
>> generated from other forms, via transpilers or lexer generators etc.
>> It can also be obfuscated C code from the real C source (cf #383465).
>> [...]
>> So like C, OTF can be source or not source, depending on the upstream
>> project.
>
>I find this by far the most convincing argument, although I still find
>it difficult to accept that it should make a difference for Debian as a
>mere downstream distributor. We provide many packages with fonts in OTF
>format and while this is acepted as a proper source for some, it is not
>for others because of upstream design decisions?
>
>> It is unfortunate that the gsfonts upstream didn't ask the right
>> questions before integrating these files into the project. They
>> really
>> should have done that. At that point in time we would have to remove
>> the URW++ fonts from Debian since we would not be in compliance with
>> the GPL.
>
>Well, RMS himself told me that the Type1 format in which the fonts are
>distributed is considered a proper source format. Apparently he doesn't
>even care about what tools upstream used to create the fonts as long as
>they are distributed in a proper source format.
>
>> Please try to submit a git commit to Firacode upstream containing
>> only
>> changes to the generated files. Then you will see that this phrase
>> has
>> meaning in any software context, including in the world of fonts and
>> Firacode in particular.
>
>Agreed, but I don't think that this (i.e. "is it easy or even possible
>to create a patch that upstream would outright accept in that form?")
>should be a criterion to decide if a package is suitable for Debian
>main or not (as long as it is possible to create the patch in the first
>place, that is).
>
>Cheers,
>
>Fabian
>-BEGIN PGP SIGNATURE-
>
>iQIzBAEBCAAdFiEEIsF2SKlSa4TfGRyWy+qOlwzNWd8FAliDSGYACgkQy+qOlwzN
>Wd8qwxAAwWmJj0YOLdxQsBhXZh7mzC+LcvY3N04MVHPHNgkIsuAuw3LhU4pHf5xC
>saninfv7e7GZ29na7i75Ug26v6FS+/3aE7Fej+np1m5pjeVAuvgtzMw4B/lKEeXb
>UvoTwvLHSKVB1mrGWe4Bu1HU8mDFOn23dZyJmvDoaRxf4OkHcBtPHUkD7FZ35P70
>t0GAEAnhAsAKyzFCsdEBGfdH8SGvw+UhHwhC31aGdCWv6to/CHsUd89HTmW2Ky0o
>QZh/4pkHK7qnX+2Zd6C0WXDdhDVNLFHyYrZT/h8LbFYozLJROksncwIMOKmGhIrK
>/pYKsqfTKshXO8X0luaQbJHCbldtyv/LbUMVmBGwr24a0+HS5rUPwM5AIhwu6MCk
>qx4W5vaifunhkxr8Z6CMwBgkKzaK7MZB4BBh+D/C5XbSHcOZHf8HoE65btM8BZyd
>8PIEWHZedUAt+HjYkY4RQfdV18XJHkVRiKK2VxCfTWz9bRF/y2+MmXF3/Cd0R09G
>jrsxW0vsUFp3WaJXTJw3P810deSYvCJpwXAsTvzApHMvTSY9kal+xKVq9moEU34+
>dvTtfV9ABf8ETooEd9FRk5R0Q+63aBoK8wU8dkzOP557UPuBeOfXqwBczi2WG4tR
>1YzraE5mYf2VonXN8HanePQMC4QpmdZhV/+ds6f5AnbGu56372U=
>=Qgwt
>-END PGP SIGNATURE-



Bug#850299: Pending fixes for bugs in the libgnupg-perl package

2017-01-21 Thread pkg-perl-maintainers
tag 850299 + pending
thanks

Some bugs in the libgnupg-perl package are closed in revision
8e696b08fcb761fcfddac63b28bdc891dab152bf in branch 'master' by gregor
herrmann

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-perl/packages/libgnupg-perl.git/commit/?id=8e696b0

Commit message:

Add patch to disable key generation test

which can fail due to missing entropy.

Thanks: Santiago Vila for the bug report.
Closes: #850299



Bug#850299: libgnupg-perl: FTBFS randomly (not enough entropy)

2017-01-21 Thread gregor herrmann
On Sat, 21 Jan 2017 14:10:55 +0100, gregor herrmann wrote:

> > For example: Does this package really need to generate a key at build
> > time? It may not be pregenerated and used during the build, like other
> > packages do? (mini-buildd comes to mind).
> 
> So yeah, maybe a pre-generated key would be a compromise ...

Works :)

Thanks again for the proposal.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Beatles: Yellow Submarine


signature.asc
Description: Digital Signature


Bug#851823: Changing default emacs to 25 to allow emacs24 removal -- RoM

2017-01-21 Thread Jiri Palecek
Hello,

I noticed you are pursuing a switch from emacs24 to emacs25 in debian, 
however, there are still packages that need to be updated not to require 
specifically emacs24 which aren't on your list of packages needing update and 
reverse-dependencies.

Particularly, these are

icicles
 D: emacs24 | emacs23 | emacs22 | emacs-snapshot

psgml
 D: emacs24 | emacs23 | emacs-snapshot

e2wm
 D: emacs24 | emacs23

emacs-window-layout
 D: emacs24 | emacs23

sass-elisp
 D: emacs23 | emacs24

yc-el
 D: emacs24 | emacs23 | emacs21 | xemacs21-mule | xemacs21-mule-canna-wnn | 
xemacs21-gnome-mule-canna-wnn | xemacs21-gnome-mule | emacs-snapshot

sepia
 D: emacs24 | emacs23 | emacs22

yatex
 D: emacs24 | emacs23 | xemacs21-mule | xemacs21-mule-canna-wnn

wnn7egg
 D: emacs23 | emacs23-lucid | emacs23-nox | emacs-snapshot-gtk | emacs-
snapshot | emacs-snapshot-nonx | xemacs21-mule | xemacs21-mule-canna-wnn | 
xemacs21-gnome-mule | xemacs21-gnome-mule-canna-wnn

- note that this dependency cannot be satisfied by emacs24 as well, I wonder 
whether this package even works with emacs - there's nothing in its bug 
reports

These packages should be checked and possibly updated with amended 
dependencies.

Regards
  Jiri Palecek



Bug#852081: O: synergy -- Share mouse, keyboard and clipboard over the network

2017-01-21 Thread Mattia Rizzolo
Package: wnpp

The current maintainer of synergy, Jeff Licquia ,
is apparently not active anymore.  Therefore, I orphan this package now.

Maintaining a package requires time and skills. Please only adopt this
package if you will have enough time and attention to work on it.

If you want to be the new maintainer, please see
https://www.debian.org/devel/wnpp/index.html#howto-o for detailed
instructions how to adopt a package properly.

Some information about this package:

Package: synergy
Binary: synergy
Version: 1.4.16-1.2
Maintainer: Jeff Licquia 
Build-Depends: debhelper (>= 7), libxt-dev, libxtst-dev, libxinerama-dev, 
cmake, docbook-utils, libcrypto++-dev, pkg-config, libqt4-dev, 
libcurl4-gnutls-dev | libcurl-dev, google-mock, libgtest-dev
Architecture: any
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 4ab0ead20d7e1bcfaa742199bfe26362 1636 synergy_1.4.16-1.2.dsc
 a183166ac8aba42c94fd25582e921eec 4130057 synergy_1.4.16.orig.tar.gz
 cbbb9efdc6a3dade29a989a76a41744a 17960 synergy_1.4.16-1.2.debian.tar.xz
Vcs-Browser: http://git.licquia.org/?p=synergy-debian.git;a=summary
Vcs-Git: http://git.licquia.org/raw/synergy-debian.git
Checksums-Sha256:
 f7a539e0193e0d0134431b3b998f27204c070a100947aee9a02c709c656c7d21 1636 
synergy_1.4.16-1.2.dsc
 dd95dae13ef284b5554a48f0693b36519b956891a2b5bbfe4f5d07ea1e9aa552 4130057 
synergy_1.4.16.orig.tar.gz
 4a54434eb35ed1eca131ba699acde276d6b147b8c0eed6cc73b2a7b7373919a2 17960 
synergy_1.4.16-1.2.debian.tar.xz
Homepage: http://synergy-foss.org/
Package-List: 
 synergy deb x11 optional arch=any
Directory: pool/main/s/synergy
Priority: source
Section: x11

Package: synergy
Binary: synergy
Version: 1.4.16-1.1
Maintainer: Jeff Licquia 
Build-Depends: debhelper (>= 7), libxt-dev, libxtst-dev, libxinerama-dev, 
cmake, docbook-utils, libcrypto++-dev, pkg-config, libqt4-dev, 
libcurl4-gnutls-dev | libcurl-dev, google-mock, libgtest-dev
Architecture: any
Standards-Version: 3.9.5
Format: 3.0 (quilt)
Files:
 b82450041398f6f9264d63bec6acb6f0 1964 synergy_1.4.16-1.1.dsc
 a183166ac8aba42c94fd25582e921eec 4130057 synergy_1.4.16.orig.tar.gz
 e9356bc3f989afe178838023d181e335 16976 synergy_1.4.16-1.1.debian.tar.xz
Vcs-Browser: http://git.licquia.org/?p=synergy-debian.git;a=summary
Vcs-Git: http://git.licquia.org/raw/synergy-debian.git
Checksums-Sha256:
 e83eaabf5a4d49a85e2fa431354b06225174503f8ac472b59dd83724dcb0137c 1964 
synergy_1.4.16-1.1.dsc
 dd95dae13ef284b5554a48f0693b36519b956891a2b5bbfe4f5d07ea1e9aa552 4130057 
synergy_1.4.16.orig.tar.gz
 12c539e46ac8328e276d9c9e006c0ad14fe5950467072565a1593664dc159d0d 16976 
synergy_1.4.16-1.1.debian.tar.xz
Homepage: http://synergy-foss.org/
Package-List: 
 synergy deb x11 optional arch=any
Directory: pool/main/s/synergy
Priority: source
Section: x11

Package: synergy
Version: 1.4.16-1.2
Installed-Size: 3370
Maintainer: Jeff Licquia 
Architecture: amd64
Depends: libc6 (>= 2.14), libcrypto++6, libcurl3-gnutls (>= 7.16.2), libgcc1 
(>= 1:3.0), libice6 (>= 1:1.0.0), libqt4-network (>= 4:4.5.3), libqtcore4 (>= 
4:4.8.0), libqtgui4 (>= 4:4.8.0), libsm6, libstdc++6 (>= 5.2), libx11-6 (>= 
2:1.2.99.901), libxext6, libxi6 (>= 2:1.2.99.4), libxinerama1, libxtst6
Description: Share mouse, keyboard and clipboard over the network
Description-md5: 5fade0f66a7ce7fd1077db2409b0fd30
Homepage: http://synergy-foss.org/
Tag: hardware::input, hardware::input:keyboard, hardware::input:mouse,
 implemented-in::c, interface::daemon, interface::graphical,
 interface::x11, network::client, network::server, network::service,
 role::program, x11::application
Section: x11
Priority: optional
Filename: pool/main/s/synergy/synergy_1.4.16-1.2_amd64.deb
Size: 730090
MD5sum: 24325cff8cc04ece7bfe3eaca58afd69
SHA256: b412e56b641d46823bfac2a9f9efbfb3cd67fcdf888cf6c454b4ecfd0e57b7a0

Package: synergy
Version: 1.4.16-1.2
Installed-Size: 3370
Maintainer: Jeff Licquia 
Architecture: amd64
Depends: libc6 (>= 2.14), libcrypto++6, libcurl3-gnutls (>= 7.16.2), libgcc1 
(>= 1:3.0), libice6 (>= 1:1.0.0), libqt4-network (>= 4:4.5.3), libqtcore4 (>= 
4:4.8.0), libqtgui4 (>= 4:4.8.0), libsm6, libstdc++6 (>= 5.2), libx11-6 (>= 
2:1.2.99.901), libxext6, libxi6 (>= 2:1.2.99.4), libxinerama1, libxtst6
Description: Share mouse, keyboard and clipboard over the network
Description-md5: 5fade0f66a7ce7fd1077db2409b0fd30
Homepage: http://synergy-foss.org/
Tag: hardware::input, hardware::input:keyboard, hardware::input:mouse,
 implemented-in::c, interface::daemon, interface::graphical,
 interface::x11, network::client, network::server, network::service,
 role::program, x11::application
Section: x11
Priority: optional
Filename: pool/main/s/synergy/synergy_1.4.16-1.2_amd64.deb
Size: 730090
MD5sum: 24325cff8cc04ece7bfe3eaca58afd69
SHA256: b412e56b641d46823bfac2a9f9efbfb3cd67fcdf888cf6c454b4ecfd0e57b7a0


-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad

Bug#851792: palo ships binary in the sources

2017-01-21 Thread Helge Deller
On 21.01.2017 10:50, Christoph Biedl wrote:
> Helge Deller wrote...
> 
>> On 18.01.2017 20:40, Adrian Bunk wrote:
>>> Package: palo
>> ...
>>> If palo should continue to be available on non-hppa machines,
>>> a (binary-all) package that uses gcc-hppa-linux-gnu for building
>>> might be an option.
>>
>> I'll check if it's possile. May take some time.
> 
> As my hppa machine still suffers from systemd's assertion failure[0], I
> cannot test the result of the changes attached below, or compare with
> the result of a build on native hardware.
> [0] https://lists.debian.org/debian-hppa/2014/09/msg00025.html

We have long time ago fixed the systemd issues. If you update kernel
and glibc you won't see those problems any longer. systemd now works
on hppa. The step to "jump over to a working systemd" while upgrading
the packages may be hard though... I think a normal update to debian
latest unstable should work.
 
> However, after applying palo builds on amd64 and produces an iplboot of
> the same size but with partially different content. Helge, might want to
> burn one your boxes trying out? :-)

Thanks for the patches.
I'll try soon.

Helge



Bug#851963: linux: enable SENSORS_ADM1031

2017-01-21 Thread Roger Shimizu
Control: tag -1 -moreinfo +pending

On Sat, Jan 21, 2017 at 8:23 PM, James Cowgill  wrote:
> On 21/01/17 10:29, Roger Shimizu wrote:
>>>
 I see this module already exists in the kernel you're using.
 Can you help to confirm?
>>>
>>> I'm pretty certain it's not enabled. It is already enabled on x86 however.
>>
>> Sorry, I just looked at amd64.
>> So you're asking for mips64 octeon support, right?
>
> Yes I am (although this isn't really MIPS specific, the board I have
> just happens to use it).

Current status:

$ grep -r SENSORS_ADM1031 debian/config
debian/config/alpha/config:CONFIG_SENSORS_ADM1031=m
debian/config/kernelarch-mips/config.malta:CONFIG_SENSORS_ADM1031=m
debian/config/kernelarch-powerpc/config:CONFIG_SENSORS_ADM1031=m
debian/config/kernelarch-sparc/config:# CONFIG_SENSORS_ADM1031 is not set
debian/config/kernelarch-x86/config:CONFIG_SENSORS_ADM1031=m

So I added an entry in: debian/config/kernelarch-mips/config.octeon

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1



Bug#852082: gwc in testing crashes at startup

2017-01-21 Thread Christian Grigis
Package: gwc
Version: 0.21.19~dfsg0-6
Severity: important

Running 'gnome_wave_cleaner' from the testing package version
(0.21.19~dfsg0-6) crashes immediately at startup:

$ gnome_wave_cleaner 
Current stack limit: 8388608 bytes
Segmentation fault

This is reproducible when building from sources:

~/tmp/gwc-testing/gwc-0.21.19~dfsg0$ ./gwc
Current stack limit: 8388608 bytes
Segmentation fault

It does not appear to depend on package contents differences between
stable and testing, as using the 0.21.19~dfsg0-4 package version results
in the same crash.

The gdb backtrace gives:

(gdb) run
Starting program: /home/glove/tmp/gwc-testing/gwc-0.21.19~dfsg0/gwc 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Current stack limit: 8388608 bytes

Program received signal SIGSEGV, Segmentation fault.
0x76e047f9 in g_type_is_a () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
(gdb) bt
#0  0x76e047f9 in g_type_is_a () from 
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#1  0x77519084 in gtk_type_new () from 
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0
#2  0x5557223c in led_bar_new (segments=20, orientation=0) at 
gtkledbar.c:82
#3  0x55561cc9 in main (argc=1, argv=0x7fffe308) at gwc.c:3109

I experimented with optimization levels but even -O0 gives the crash.

However, it looks like it is related to the compiler, because forcing to
compile with gcc-5 instead of gcc-6 produces a binary that starts up
normally.

Please let me know if I can provide more information.

Thank you and best regards,

-Christian


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

Kernel: Linux 4.7.0-mooch.1-amd64 (SMP w/4 CPU cores; PREEMPT)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages gwc depends on:
ii  libc6 2.24-9
ii  libfftw3-double3  3.3.5-3
ii  libglib2.0-0  2.50.2-2
ii  libgnome-2-0  2.32.1-5
ii  libgnomeui-0  2.24.5-3.1
ii  libgtk2.0-0   2.24.31-1
ii  libpulse0 10.0-1
ii  libsndfile1   1.0.27-1
ii  libvorbisfile31.3.5-4

gwc recommends no packages.

Versions of packages gwc suggests:
ii  chromium [www-browser]   55.0.2883.75-5
ii  elinks [www-browser] 0.12~pre6-12
ii  elvis-console [www-browser]  2.2.0-12
ii  firefox-esr [www-browser]45.6.0esr-1
ii  lynx [www-browser]   2.8.9dev11-1
ii  w3m [www-browser]0.5.3-34
ii  yelp 3.22.0-1

-- no debconf information



Bug#852083: dracut-core should Recommends: binutils and systemd for the --uefi option to work out of the box

2017-01-21 Thread Alexander Kurtz
Package: dracut-core
Version: 044+189-2
Severity: minor

Hi!

dracut supports creating a single UEFI executable with the --uefi
option, but needs objcopy from the binutils package and the UEFI stub
loader from the systemd package for this. Please add these packages to
the Recommends: list, so that this feature works out of the box!

Best regards

Alexander Kurtz

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


Bug#851964: Small fixes to po file

2017-01-21 Thread Anders Jonsson
Hi Martin,
I have looked through the po file and made two changes:
(variable->variabler) and made a longer sentence sound better
grammatically. ("förhindra att den installerade GRUB-huvudavbildningen
för att hamna i ett förhållande" -> "förhindra den installerade
GRUB-huvudavbildningen från att hamna i ett förhållande"


Regards,
Anders Jonsson
# translation of grub2 debconf messages to Swedish
# Swedish translation for grub2.
# Copyright (C) 2007, 2008, 2009, 2010, 2014, 2017 Free Software Foundation, Inc.
# This file is distributed under the same license as the grub2 package.
#
# Daniel Nylander , 2007.
# Martin Ågren , 2008, 2009.
# Martin Bagge , 2010, 2014, 2017
msgid ""
msgstr ""
"Project-Id-Version: grub2_sv\n"
"Report-Msgid-Bugs-To: gr...@packages.debian.org\n"
"POT-Creation-Date: 2017-01-20 00:29+\n"
"PO-Revision-Date: 2017-01-21 15:16+0100\n"
"Last-Translator: Martin Bagge / brother \n"
"Language-Team: Swedish \n"
"Language: sv\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=(n != 1);\n"
"X-Generator: Poedit 1.8.11\n"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "Chainload from menu.lst?"
msgstr "Kedjeladda från menu.lst?"

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid "GRUB upgrade scripts have detected a GRUB Legacy setup in /boot/grub."
msgstr ""
"GRUB:s uppgraderingsskript har upptäckt en gammal GRUB-inställning i /boot/"
"grub."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"In order to replace the Legacy version of GRUB in your system, it is "
"recommended that /boot/grub/menu.lst is adjusted to load a GRUB 2 boot image "
"from your existing GRUB Legacy setup. This step can be automatically "
"performed now."
msgstr ""
"Om du vill ersätta den gamla versionen av GRUB i systemet, rekommenderas "
"att /boot/grub/menu.lst justeras till att kedjeladda GRUB 2 från din "
"existerande, gamla GRUB-inställning. Detta steg kan utföras automatiskt nu."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"It's recommended that you accept chainloading GRUB 2 from menu.lst, and "
"verify that the new GRUB 2 setup works before it is written to the MBR "
"(Master Boot Record)."
msgstr ""
"Det rekommenderas att GRUB 2 kedjeladdas från menu.lst så att det kan "
"säkerställas att den nya GRUB 2-inställningen fungerar innan den installeras "
"direkt till huvudstartsektorn (MBR)."

#. Type: boolean
#. Description
#: ../grub-pc.templates.in:2001
msgid ""
"Whatever your decision, you can replace the old MBR image with GRUB 2 later "
"by issuing the following command as root:"
msgstr ""
"Oberoende av ditt beslut kan den gamla MBR-avbildningen ersättas med GRUB 2 "
"vid ett senare tillfälle genom att följande kommando utförs som root:"

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid "GRUB install devices:"
msgstr "GRUB installationsenheter:"

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"The grub-pc package is being upgraded. This menu allows you to select which "
"devices you'd like grub-install to be automatically run for, if any."
msgstr ""
"Paketet grub-pc uppdateras. Denna meny ger dig möjlighet att välja vilka, om "
"några, enheter som grub-install ska köras automatiskt för."

#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001
msgid ""
"Running grub-install automatically is recommended in most situations, to "
"prevent the installed GRUB core image from getting out of sync with GRUB "
"modules or grub.cfg."
msgstr ""
"Att köra grub-install automatiskt är rekommenderat i de flesta situationer "
"för att förhindra den installerade GRUB-huvudavbildningen från att hamna i "
"ett förhållande där GRUB-moduler eller grub.cfg inte är i korrekt läge."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"If you're unsure which drive is designated as boot drive by your BIOS, it is "
"often a good idea to install GRUB to all of them."
msgstr ""
"Om du är osäker på vilken disk som är uppstartsdisken enligt BIOS så är det "
"vanligen en god idé att installera GRUB på alla."

#. Type: multiselect
#. Description
#. Type: multiselect
#. Description
#: ../grub-pc.templates.in:3001 ../grub-pc.templates.in:4001
msgid ""
"Note: it is possible to install GRUB to partition boot records as well, and "
"some appropriate partitions are offered here. However, this forces GRUB to "
"use the blocklist mechanism, which makes it less reliable, and therefore is "
"not recommended."
msgstr ""
"OBS: det är möjligt att installera GRUB i partitionens uppstartsområde "
"också, några av dessa visas nedan. Dock innebär installation där att GRUB "
"tvingas använda en blockeringslista

Bug#820974: bind9 crypto issue

2017-01-21 Thread Gedalya
On Fri, 20 Jan 2017 07:38:32 -0700 LaMont Jones wrote:

>
> Can you provide a named.conf that reproduces the issue?
>

I've tried commenting out everything locally modified, leaving basically a 
default config.
It seems the only thing needed to reproduce this issue is to run bind in a 
chroot.
bind-mounting /usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines (on amd64) into 
the chroot works around the issue.
I got this so far on several servers with dissimilar configurations.



Bug#852084: lintian: [PATCH] fix incorrect separator: | -> ||

2017-01-21 Thread Edward Betts
Package: lintian
Version: 2.5.50
Severity: normal
Tags: patch

---
 data/spelling/corrections | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/data/spelling/corrections b/data/spelling/corrections
index 08cc0f5ff..87a5aafec 100644
--- a/data/spelling/corrections
+++ b/data/spelling/corrections
@@ -548,7 +548,7 @@ calulated||calculated
 calulates||calculates
 calulating||calculating
 calulation||calculation
-calulations|calculations
+calulations||calculations
 cancelation||cancellation
 canidate||candidate
 canidates||candidates
-- 
2.11.0



Bug#851774: Stop using apt-key add to add keys in generators/60local

2017-01-21 Thread Philipp Kern
[Adding deity@l.d.o into the loop]

On 18.01.2017 17:43, Marga Manterola wrote:
> For a long time it's been possible to preseed a local repository that
> has it's own keyring. However, with the latest changes related to gpg
> dependencies getting dropped in apt, this is no longer possible.
> 
> I'm setting severity as serious as adviced by Julien Cristau on IRC.
> With the current state of things, in order to install a local repository
> with a keyring the user needs to somehow create a script that will put
> the keyring in place before 60local runs, and not preseed the keyring at
> all.  If the keyring is preseeded, *the whole installation will fail*
> because apt-key add fails which causes 60local to fail, which causes the
> install base system step to fail.
> 
> This is the offending code:
> https://sources.debian.net/src/apt-setup/1:0.123/generators/60local/#L33
> 
> This is using the deprecated apt-key add functionality.  From the
> apt-key manpage:
> 
> COMMANDS
>add filename
> (...)
>Note: Instead of using this command a keyring should be
> placed directly in the /etc/apt/trusted.gpg.d/ directory with a
> descriptive name and either "gpg" or "asc" as file extension.
> 
> So, the right thing to do is to copy the file to the right path instead
> of calling apt-key add with it.

Does that mean that we actually have to infer (check using grep?) if the
file is armored or not? I think `apt-key add' just dealt with whatever
it got and put the key into the keyring using gpg's --import function.
So it's a little unfortunate that we'd now need to know the format of
what we need to put into the fragment directory.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature


Bug#851870: autopkgtest-virt-qemu: Hangs if test causes a kernel panic

2017-01-21 Thread Iain Lane
On Sat, Jan 21, 2017 at 11:09:17AM +0100, Martin Pitt wrote:
> So while this is certainly not optimal, it is at least reasonable. So
> I don't think it's an urgent/critical bug.

Yep, that's why it's Severity: minor. I just happened to notice.

Thanks for the feedback!

-- 
Iain Lane  [ i...@orangesquash.org.uk ]
Debian Developer   [ la...@debian.org ]
Ubuntu Developer   [ la...@ubuntu.com ]



Bug#834987: clearsilver has been orphaned

2017-01-21 Thread Tobias Frost
Control: reopen -1 

On Sat, 21 Jan 2017 00:33:57 +0200 Adrian Bunk  wrote:
> clearsilver has been orphaned (see #849019).

mmm, shouldn't this bug be kept open so that a new maintainer / QA
upload will be reminded to remove them from the Uploaders file?

--
tobi



Bug#852085: packagekit: Add breaks packagekit-plugin-click

2017-01-21 Thread Jeremy Bicha
Package: packagekit
Version: 1.1.5-1
Severity: wishlist

If you add
Breaks: packagekit-plugin-click (<= 0.3.1)
Ubuntu can sync this package directly from Debian.

That can be dropped after Ubuntu 18.04 LTS.

Thanks,
Jeremy Bicha



Bug#852086: paxrat: Fails on removal with "sh: 1: /sbin/paxrat: not found"

2017-01-21 Thread intrigeri
Package: paxrat
Severity: normal
Version: 1.0-2

Hi,

I suspect that piuparts has already noticed that, but still:

$ sudo apt purge paxrat
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following packages will be REMOVED:
  paxrat*
0 upgraded, 0 newly installed, 1 to remove and 3 not upgraded.
After this operation, 2,354 kB disk space will be freed.
Do you want to continue? [Y/n] 
(Reading database ... 635829 files and directories currently installed.)
Removing paxrat (1.0-2) ...
Processing triggers for man-db (2.7.6.1-2) ...
(Reading database ... 635823 files and directories currently installed.)
Purging configuration files for paxrat (1.0-2) ...
sh: 1: /sbin/paxrat: not found
E: Problem executing scripts DPkg::Post-Invoke '/sbin/paxrat -c 
/etc/paxrat/paxrat.conf'
E: Sub-process returned an error code

I guess the dpkg/APT hook should check if /sbin/paxrat exists, and
exit nicely with return code 0 if it doesn't.

Cheers,
-- 
intrigeri



Bug#813658: virglrenderer support before the freeze?

2017-01-21 Thread Michael Tokarev
21.01.2017 16:19, Michael Neuffer wrote:
> On Mon, 14 Nov 2016 19:39:22 +0100 Andreas Cadhalpun
>  wrote:
>> The only additional dependencies compared to the current
>> qemu-system-x86 package are:
>> libdrm2 libepoxy0 libexpat1 libgbm1 libvirglrenderer0
>> libwayland-client0 libwayland-server0
>>
>> That doesn't seem excessive to me.
> 
> I am tracking testing. I'll show you the new dependencies pulled in by
> the qemu-system-x86 package.
> When talking about dependencies do not only look at direct dependencies,
> but at the whole dependency tree.
> We are talking about a HUGE number of additional packages and an
> increased attack surface here.
> 
> This is for qemu-system-x86 1:2.7+dfsg-3+b1 --> 1:2.8+dfsg-1
> 
> I cringe at the thought that I have to install all these packages for
> quemu on what were once a really lean and clean servers
> just hosting virtual machines on the net. They are getting cluttered and
> keeping them secure becomes harder and harder.
> 
> A headless console-only version is surgently needed.

As I described already, even a headless version will not come without
virglrenderer, and this one does pull other things.

Creating another variant of this package (besides modular display which
wont be in stretch) does not seem to be a good idea.

I know about the amount of packages (which does not mean anything
at all, since disk space is cheap) and increased attack surface
(which is also almost a non-issue, since most of that unused stuff
is well, unused, so does not add any new risks, since debian tries
to do a good job at keeping it all secure, and due to many other
reasons).  Unless there will be separate "client-only" graphics libs
as I already described, that's how we'll live here.

Sorry I don't see a reason to create 7 more packages just for "servers",
especially since many of these will require advanced guest support
anyway such as this virgl thing.

Note some packages you mention are suggested, not even recommended.
You don't need to install recommended packages on servers.

Thanks,

/mjt



Bug#852070: smemstat: The smemstat command crashes on ARM based machine

2017-01-21 Thread Colin Ian King
I believe this was fixed with the upstream fix:

commit 851c9d288a76b881ec547a61c2c3a8cc2b42f207
Author: Colin Ian King 
Date:   Fri Jul 10 00:33:25 2015 +0100

Fix null ptr dereference when UID can't be read (LP: #1473245)

..can you clone and build the latest smemstat and see if this fixes the
issue. If so, I'll get this fix into 0.01.10-1 version

git clone git://kernel.ubuntu.com/cking/smemstat
cd smemstat
make

and see if this version fixes the issue.

Colin



On 21/01/17 11:52, Miroslav Mitevski wrote:
> I suspect the program hangs when the smemstat tries to read data about it’s 
> own process.
>> On 21.01.2017 г., at 13:46, Miroslav Mitevski  
>> wrote:
>>
>> The issue is reproduced when the command is executed as root only.
>>
>> Attaching the log from strace.
>>
>> Regards,
>> Miro
>> 
>>> On 21.01.2017 г., at 13:33, Miroslav Mitevski  
>>> wrote:
>>>
>>> It is 32 bit
>>>
>>> Below is the content of /proc/cpuinfo
>>>
>>> processor   : 0
>>> model name  : Feroceon 88FR131 rev 1 (v5l)
>>> BogoMIPS: 1974.27
>>> Features: swp half thumb fastmult edsp
>>> CPU implementer : 0x56
>>> CPU architecture: 5TE
>>> CPU variant : 0x2
>>> CPU part: 0x131
>>> CPU revision: 1
>>>
>>> Hardware: QNAP TS-119/TS-219
>>> Revision: 
>>> Serial  : 
>>>
>>> Regards,
>>> Miro
>>>
 On 21.01.2017 г., at 12:32, Colin Ian King  
 wrote:

 Hi Miroslav,

 Is that a 32 bit ARM platform?

 How are you running smemstat?

 Can you re-run smemstat using strace and capturing the output and adding
 that to the bug report?

 e.g.

 strace smemstat >& smemstat.log

 please can you use the same smemstat options that reproduce the bug.

 Thanks!

 On 21/01/17 10:19, Miroslav Mitevski wrote:
> Package: smemstat
> Version: 0.01.10-1
> Severity: important
>
> Dear Maintainer,
>
> after installing the package from the official Debian repository and 
> executing the smemstat command on ARM based machine I discovered the 
> following error:
>
> The expectation is program to list running processes with the memory 
> usage. Unfortunately the program crashes with "Segmentation fault".
>
> There are no logs or additional error messages.
>
> The Debian installation is on QNAP 219P II device, which is ARM based.
>
> Current locale of the system is bg_BG.UTF-8
>
> Itried with en_US.UTF-8 and "C" - the result was the same.
>
> Regards,
> Miro
>
>
> *** Reporter, please consider answering these questions, where 
> appropriate ***
>
> * What was the outcome of this action?
> * What outcome did you expect instead?
>
> *** End of the template - remove these template lines ***
>
>
> -- System Information:
> Debian Release: 8.7
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: armel (armv5tel)
>
> Kernel: Linux 3.16.0-4-kirkwood
> Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages smemstat depends on:
> ii  libc6  2.19-18+deb8u7
>
> smemstat recommends no packages.
>
> smemstat suggests no packages.
>
> -- no debconf information
>

>>>
>>



Bug#851823: Changing default emacs to 25 to allow emacs24 removal -- RoM

2017-01-21 Thread Sean Whitton
Hello Jiri,

On Sat, Jan 21, 2017 at 02:50:17PM +0100, Jiri Palecek wrote:
> I noticed you are pursuing a switch from emacs24 to emacs25 in debian,
> however, there are still packages that need to be updated not to
> require specifically emacs24 which aren't on your list of packages
> needing update and reverse-dependencies.

Thank you for this reply.  I have been working on this transition with
Rob, and I don't know how we managed to miss those packages.

However, note that the change to emacs-defaults is not blocked by any of
the packages you've listed.  /This/ bug is about the version of Emacs
someone would get if they typed `apt-get install emacs`.  It would
require a bug against ftp.debian.org to remove emacs24.

Even if we can't remove emacs24 for stretch thanks to the packages
you've highlighted, it would still be good to update emacs-defaults.

-- 
Sean Whitton


signature.asc
Description: PGP signature


  1   2   3   >