Bug#828482: bug 828482 fix

2017-01-31 Thread Sebastian Andrzej Siewior
On 2017-02-01 09:59:02 [+0800], Di-Shi Sun wrote:
> Hi Sebastian,
Hi Di-Shi,

> I am pretty sure that 4.11.3+dfsg-1 is not influenced by 828482 (FTBFS with 
> openssl 1.1.0). Please send us the build log showing the issue you report.

sbuild (Debian sbuild) 0.73.0 (23 Dec 2016) on debbuildd

+==+
| osptoolkit 4.11.3+dfsg-1 (amd64) Wed, 01 Feb 2017 07:30:45 + |
+==+

Package: osptoolkit
Version: 4.11.3+dfsg-1
Source Version: 4.11.3+dfsg-1
Distribution: unstable
Machine Architecture: amd64
Host Architecture: amd64
Build Architecture: amd64
Build Type: any

+--+
| Build environment|
+--+

Kernel: Linux 4.9.0-1-amd64 amd64 (x86_64)
Toolchain package versions: binutils_2.27.90.20170124-2 dpkg-dev_1.18.21 
g++-6_6.3.0-5 gcc-6_6.3.0-5 libc6-dev_2.24-9 libstdc++-6-dev_6.3.0-5 
libstdc++6_6.3.0-5 linux-libc-dev_4.9.6-3
Package versions: adduser_3.115 apt_1.4~beta4 autoconf_2.69-10 
automake_1:1.15-6 autopoint_0.19.8.1-2 autotools-dev_20161112.1 base-files_9.8 
base-passwd_3.5.43 bash_4.4-4 binutils_2.27.90.20170124-2 bsdmainutils_9.0.12 
bsdutils_1:2.29.1-1 build-essential_12.3 bzip2_1.0.6-8.1 coreutils_8.26-2 
cpp_4:6.3.0-1 cpp-6_6.3.0-5 dash_0.5.8-2.4 debconf_1.5.60 debhelper_10.2.5 
debian-archive-keyring_2014.3 debianutils_4.8.1 dh-autoreconf_13 
dh-strip-nondeterminism_0.029-2 diffutils_1:3.5-3 dmsetup_2:1.02.137-1 
docbook_4.5-6 docbook-to-man_1:2.0.0-35 dpkg_1.18.21 dpkg-dev_1.18.21 
e2fslibs_1.43.4-1 e2fsprogs_1.43.4-1 eatmydata_105-5 fakeroot_1.21-3.1 
file_1:5.29-3 findutils_4.6.0+git+20161106-1 g++_4:6.3.0-1 g++-6_6.3.0-5 
gcc_4:6.3.0-1 gcc-6_6.3.0-5 gcc-6-base_6.3.0-5 gettext_0.19.8.1-2 
gettext-base_0.19.8.1-2 gnupg_2.1.18-3 gnupg-agent_2.1.18-3 gpgv_2.1.18-3 
grep_2.27-2 groff-base_1.22.3-9 gzip_1.6-5 hostname_3.18 init_1.47 
init-system-helpers_1.47 initscripts_2.88dsf-59.8 insserv_1.14.0-5.4 
intltool-debian_0.35.0+20060710.4 libacl1_2.2.52-3 libapparmor1_2.11.0-2 
libapt-pkg5.0_1.4~beta4 libarchive-zip-perl_1.59-1 libasan3_6.3.0-5 
libassuan0_2.4.3-2 libatomic1_6.3.0-5 libattr1_1:2.4.47-2 
libaudit-common_1:2.6.7-1 libaudit1_1:2.6.7-1 libblkid1_2.29.1-1 
libbsd0_0.8.3-1 libbz2-1.0_1.0.6-8.1 libc-bin_2.24-9 libc-dev-bin_2.24-9 
libc6_2.24-9 libc6-dev_2.24-9 libcap-ng0_0.7.7-3 libcap2_1:2.25-1 
libcap2-bin_1:2.25-1 libcc1-0_6.3.0-5 libcilkrts5_6.3.0-5 libcomerr2_1.43.4-1 
libcroco3_0.6.11-2 libcryptsetup4_2:1.7.3-3 libdb5.3_5.3.28-12+b1 
libdebconfclient0_0.221 libdevmapper1.02.1_2:1.02.137-1 libdpkg-perl_1.18.21 
libeatmydata1_105-5 libfakeroot_1.21-3.1 libfdisk1_2.29.1-1 libffi6_3.2.1-6 
libfile-stripnondeterminism-perl_0.029-2 libgcc-6-dev_6.3.0-5 libgcc1_1:6.3.0-5 
libgcrypt20_1.7.6-1 libgdbm3_1.8.3-14 libglib2.0-0_2.50.2-2 
libgmp10_2:6.1.2+dfsg-1 libgomp1_6.3.0-5 libgpg-error0_1.26-2 libicu57_57.1-5 
libidn11_1.33-1 libip4tc0_1.6.0+snapshot20161117-5 libisl15_0.18-1 
libitm1_6.3.0-5 libkmod2_23-2 libksba8_1.3.5-2 liblsan0_6.3.0-5 
liblz4-1_0.0~r131-2 liblzma5_5.2.2-1.2 libmagic-mgc_1:5.29-3 libmagic1_1:5.29-3 
libmount1_2.29.1-1 libmpc3_1.0.3-1 libmpfr4_3.1.5-1 libmpx2_6.3.0-5 
libncurses5_6.0+20161126-1 libncursesw5_6.0+20161126-1 libnpth0_1.3-1 
libosp5_1.5.2-13 libpam-modules_1.1.8-3.5 libpam-modules-bin_1.1.8-3.5 
libpam-runtime_1.1.8-3.5 libpam0g_1.1.8-3.5 libpcre3_2:8.39-2 
libperl5.24_5.24.1-1 libpipeline1_1.4.1-2 libprocps4_2:3.3.10-4+b1 
libprocps6_2:3.3.12-3 libquadmath0_6.3.0-5 libreadline6_6.3-9 
libreadline7_7.0-2 libseccomp2_2.3.1-2.1 libselinux1_2.6-3 
libsemanage-common_2.6-2 libsemanage1_2.6-2 libsepol1_2.6-2 libsigsegv2_2.10-5 
libsmartcols1_2.29.1-1 libsqlite3-0_3.16.2-2 libss2_1.43.4-1 
libssl-dev_1.1.0d-2 libssl1.1_1.1.0d-2 libstdc++-6-dev_6.3.0-5 
libstdc++6_6.3.0-5 libsystemd0_232-14 libtimedate-perl_2.3000-2 
libtinfo5_6.0+20161126-1 libtool_2.4.6-2 libtool-bin_2.4.6-2 libtsan0_6.3.0-5 
libubsan0_6.3.0-5 libudev1_232-14 libunistring0_0.9.6+really0.9.3-0.1 
libusb-0.1-4_2:0.1.12-30 libustr-1.0-1_1.0.4-6 libuuid1_2.29.1-1 
libxml2_2.9.4+dfsg1-2.2 linux-libc-dev_4.9.6-3 login_1:4.4-3 
lsb-base_9.20161125 m4_1.4.18-1 make_4.1-9 man-db_2.7.6.1-2 mawk_1.3.3-17 
mount_2.29.1-1 multiarch-support_2.24-9 ncurses-base_6.0+20161126-1 
ncurses-bin_6.0+20161126-1 opensp_1.5.2-13 passwd_1:4.4-3 patch_2.7.5-1 
perl_5.24.1-1 perl-base_5.24.1-1 perl-modules-5.24_5.24.1-1 
pinentry-curses_1.0.0-1 po-debconf_1.0.20 procps_2:3.3.12-3 
readline-common_7.0-2 sbuild-build-depends-core-dummy_0.invalid.0 
sbuild-build-depends-osptoolkit-dummy_0.invalid.0 sed_4.3-3 
sensible-utils_0.0.9 sgml-base_1.29 sgml-data_2.0.10 startpar_0.59-3.1 
systemd_232-14 systemd-sysv_232-14 sysv-rc_2.88dsf-59.8 
sysvinit-utils_2.88dsf-59.8 

Bug#853817: nautilus: Pressing enter with no selection while in search makes Nautilus crash.

2017-01-31 Thread GEHA
Package: nautilus
Version: 3.22.2-1
Severity: upstream

please include upstream patch in stretch

https://git.gnome.org/browse/nautilus/commit/?id=82a2d53e98758623cc2ebca176391d2d1f639e91


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

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

Versions of packages nautilus depends on:
ii  desktop-file-utils 0.23-1
ii  gsettings-desktop-schemas  3.22.0-1
ii  gvfs   1.30.3-1
ii  libatk1.0-02.22.0-1
ii  libc6  2.24-8
ii  libcairo-gobject2  1.14.8-1
ii  libcairo2  1.14.8-1
ii  libexempi3 2.4.0-1
ii  libexif12  0.6.21-2
ii  libgail-3-03.22.6-1
ii  libgdk-pixbuf2.0-0 2.36.3-1
ii  libglib2.0-0   2.50.2-2
ii  libglib2.0-data2.50.2-2
ii  libgnome-autoar-0-00.1.1-4+b1
ii  libgnome-desktop-3-12  3.22.2-1
ii  libgtk-3-0 3.22.6-1
ii  libnautilus-extension1a3.22.2-1
ii  libpango-1.0-0 1.40.3-3
ii  libselinux12.6-3
ii  libtracker-sparql-1.0-01.10.4-1
ii  libx11-6   2:1.6.4-2
ii  nautilus-data  3.22.2-1
ii  shared-mime-info   1.7-1

Versions of packages nautilus recommends:
ii  gnome-sushi  3.21.91-2
ii  gvfs-backends1.30.3-1
ii  librsvg2-common  2.40.16-1

Versions of packages nautilus suggests:
ii  brasero  3.12.1-4
ii  eog  3.20.5-1
ii  evince [pdf-viewer]  3.22.1-3
ii  nautilus-sendto  3.8.4-2
ii  okular [pdf-viewer]  4:16.08.2-1
ii  totem3.22.0-2+b1
ii  tracker  1.10.4-1
ii  vlc [mp3-decoder]2.2.4-13
ii  xdg-user-dirs0.15-2

-- no debconf information



Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

2017-01-31 Thread Joerg Jaspert

Am 2017-02-01 04:45, schrieb Sam Hartman:


What I think several of us did is look at the technical details and
decide we believe that the installer team was the right set of people 
to

make this technical decision.



So, I think the TC will make its decisions on a technical foundation a
lot less frequently than you do.
That said, I do think an understanding of which technical factors are
important is something we need to do.



If there are things I can to to help you believe that we did consider
the points you think important I'd like to do that.  If you can think 
of

things I can do to help you gain confidence that we have heard you,
please let me know.



That said, I'm hoping you can respect me when I say that hearing you
does not mean agreeing with you--not even about what factors are
important in making a decision.


You got asked as TC to decide which way it should go. Right now you try 
to shy out of giving an answer
to that. Instead you should just decide on it, and if you all think its 
the installers team to decide
and Ole lost, then issue such a statement. Everything else is just 
another plain fail.


--
bye Joerg



Bug#749031: transmission-gtk: Tray icon in mate-panel and gnome-shell has excessive spacing

2017-01-31 Thread Eric Pruitt
On Sat, Jan 07, 2017 at 07:19:00PM -0500, Sandro Tosi wrote:
> On Fri, Apr 3, 2015 at 1:05 PM, Eric Pruitt  wrote:
> > I don't use Sid, and I'm not particularly interested in mixing stable
> > and unstable packages just to test this. I intend to update to Jessie
> > when it's released later this month, and I will see if the problem is
> > still reproducible at that time.
>
> any update on this?

I just tried running transmission-gtk with trayer, and the spacing issue
was not present on Debian 8.7.

Eric



Bug#853816: ITP: golang-github-go-openapi-spec -- OpenAPI specification object model

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-spec
  Version : 0.0~git20161119.0.f7ae86d-1
  Upstream Author : Ivan Porto Carrero
* URL : https://github.com/go-openapi/spec
* License : Apache-2.0
  Programming Lang: Go
  Description : OpenAPI specification object model

 The OpenAPI Specification is a specification for machine-readable
 interface files for describing, producing, consuming, and visualizing
 RESTful Web services.
 .
 This module is a Go implementation of the OpenAPI object model which
 allows web interfaces to be specified and implemented using Go in a
 simple and elegant manner.



signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#853815: ITP: golang-github-go-openapi-jsonpointer -- Fork of gojsonpointer with support for structs

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-jsonpointer
  Version : 0.0~git20170102.0.779f453-1
  Upstream Author : Ivan Porto Carrero
* URL : https://github.com/go-openapi/jsonpointer
* License : Apache-2.0
  Programming Lang: Go
  Description : Fork of gojsonpointer with support for structs

 JSON Pointer is an extension to the JSON format which defines a
 string syntax for identifying a specific value within a JSON
 document.
 .
 This module is a fork of the github.com/xeipuuv/gojsonpointer
 project which implements the JSON Pointer standard for Go, but with
 support for structs added.



signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#846647: tinyeartrainer: please make the build reproducible

2017-01-31 Thread Chris Lamb
> Would you consider applying this patch and uploading?

Friendly ping on this :)


Best wishes,

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



Bug#845745: node-rimraf: please make the build reproducible

2017-01-31 Thread Chris Lamb
Hi,

> Thank you, and i did that in some other packages recently,
> i'll try to fix them.

Friendly ping on this? :)


Regards,

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



Bug#853814: ITP: golang-github-go-openapi-jsonreference -- Fork of gojsonreference with support for structs

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-jsonreference
  Version : 0.0~git20161105.0.36d33bf-1
  Upstream Author : Ivan Porto Carrero
* URL : https://github.com/go-openapi/jsonreference
* License : Apache-2.0
  Programming Lang: Go
  Description : Fork of gojsonreference with support for structs

 JSON Reference is an extension to the JSON format which allows a JSON
 value to reference another value within a JSON document.
 .
 This module is a fork of the github.com/xeipuuv/gojsonreference
 project which implements the JSON Reference standard for Go, but with
 support for structs added.



signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#853813: ITP: golang-github-go-openapi-swag -- General utilities for the go-openapi projects

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-go-openapi-swag
  Version : 0.0~git20161024.0.3b6d86c-1
  Upstream Author : Ivan Porto Carrero
* URL : https://github.com/go-openapi/swag
* License : Apache-2.0
  Programming Lang: Go
  Description : General utilities for the go-openapi projects

 This modules contains a collection of helper functions used in many
 of the go-openapi projects. It includes utilities to:
 .
   * convert between value and pointers for builtins
   * convert from string to builtin
   * fast json concatenation


signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#853812: vdr: [INTL:ru] Russian debconf templates translation update

2017-01-31 Thread Yuri Kozlov
Package: vdr
Version: 2.2.0-6
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.9.0-1-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#853811: ITP: golang-github-mailru-easyjson -- Fast JSON serializer for golang

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-mailru-easyjson
  Version : 0.0~git20161103.0.159cdb8-1
  Upstream Author : Victor Starodub
* URL : https://github.com/mailru/easyjson
* License : Expat
  Programming Lang: Go
  Description : Fast JSON serializer for golang

 The easyjson library allows the user to (un-)marshal JSON structs
 without the use of reflection by generating marshaller code.
 .
 One of the aims of the library is to keep generated code simple enough
 so that it can be easily optimized or fixed. Another goal is to
 provide users with ability to customize the generated code not
 available in 'encoding/json', such as generating snake_case names or
 enabling 'omitempty' behavior by default.



signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#853810: ITP: verboselogs -- Verbose logging level for Python's logging module

2017-01-31 Thread Gaurav Juvekar
Package: wnpp
Severity: wishlist
Owner: Gaurav Juvekar 

* Package name: verboselogs
  Version : 1.5
  Upstream Author : Peter Odding 
* URL : https://verboselogs.readthedocs.io
* License : Expat
  Programming Lang: Python
  Description : Verbose logging level for Python's logging module

Binary package names: python3-verboselogs python-verboselogs

The verboselogs package extends Python's logging module to add the log levels
VERBOSE, NOTICE, and SPAM:
 - The VERBOSE level sits between the predefined INFO and DEBUG levels.
 - The NOTICE level sits between the predefined WARNING and INFO levels.
 - The SPAM level sits between the predefined DEBUG and NOTSET levels.

This package is a dependency for coloredlogs (ITP #780187)
This package will be maintained in the Python modules team.

-- 
Regards,
Gaurav Juvekar



signature.asc
Description: OpenPGP digital signature


Bug#850951: CVE-2016-9962

2017-01-31 Thread Tianon Gravi
On 31 January 2017 at 20:46, Tianon Gravi  wrote:
> I'm preparing a patch for the package now, but I'm curious what the
> implications of an upload will be so close to the freeze -- do we need
> to request a freeze exception or a migration adjustment after the
> updated package is up?  Should I hold off on uploading?  (would rather
> not lose "runc" from stretch)

CVE fix backported for v0.1.1 is attached (applies cleanly in the
current packaging when added to "debian/patches/series").

Happy to do the actual upload if I can get some guidance on how to
make sure it's done properly WRT freeze (or just as happy to leave it
to someone else).  O:)


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4
Description: set "runc exec" processes as non-dumpable (CVE-2016-9962)
Origin: https://github.com/opencontainers/runc/commit/50a19c6ff828c58e5dab13830bd3dacde268afe5 (backported to v0.1.1)
Author: Tianon Gravi 
Forwarded: not-needed
Applied-Upstream: > 1.0.0-rc2

diff --git a/libcontainer/nsenter/nsexec.c b/libcontainer/nsenter/nsexec.c
index 8f37d6c..3c74c63 100644
--- a/libcontainer/nsenter/nsexec.c
+++ b/libcontainer/nsenter/nsexec.c
@@ -364,6 +364,12 @@ void nsexec(void)
 		return;
 	}
 
+	/* make the process non-dumpable */
+	if (prctl(PR_SET_DUMPABLE, 0, 0, 0, 0) != 0) {
+		pr_perror("Failed to set process as non-dumpable");
+		exit(1);
+	}
+
 	// Retrieve the netlink header
 	struct nlmsghdr nl_msg_hdr;
 	int		len;


Bug#850951: [pkg-go] Bug#850951: Bug#850951: CVE-2016-9962

2017-01-31 Thread Tianon Gravi
On 30 January 2017 at 11:31, Salvatore Bonaccorso  wrote:
> Disclaimer: I'm not too deep into that. I just noticed that
> https://bugzilla.novell.com/show_bug.cgi?id=1012568 though seem to
> indicate as well 0.1.1 based version are affected. But I cannot tell
> more (at the moment).

Reading more into the vuln itself, I think ignoring the "stateDirFD"
bits of the upstream patch is appropriate (and simply adding the
"PR_SET_DUMPABLE" bit for "runc exec" as in
"libcontainer/nsenter/nsexec.c").

I'm preparing a patch for the package now, but I'm curious what the
implications of an upload will be so close to the freeze -- do we need
to request a freeze exception or a migration adjustment after the
updated package is up?  Should I hold off on uploading?  (would rather
not lose "runc" from stretch)


♥,
- Tianon
  4096R / B42F 6819 007F 00F8 8E36  4FD4 036A 9C25 BF35 7DD4



Bug#852751: Fix buggy encfs behavior

2017-01-31 Thread Tony Sultana
I agree with fixing the buggy behavior in encfs.  I created an encfs
paranoid folder and use cryptkeeper to open it without issues in Stretch.

If someone creates one through cryptkeeper they will discover the problem
quickly.  That being said, I agree having a program with known bad behavior
(cryptkeeper) is not preferred but the cause appears to come from another
application.

Tony


Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf

2017-01-31 Thread Guillem Jover
Hi!

On Tue, 2017-01-31 at 22:44:36 +, James Cowgill wrote:
> Package: dpkg
> Version: 1.18.21
> Severity: serious
> X-Debbugs-CC: debian-...@lists.debian.org

> [Disclaimer: I'm not an ARM porter and I don't really know much about
> the ARM psABI]
> 
> The new ABI mismatch detector seems to be a bit too strict on armel and
> armhf. The detector forces the ELF_FLAG_ARM_HARD_FLOAT and
> ELF_FLAG_ARM_SOFT_FLOAT flags to be equal on both the library and its
> user but checking ABI comparability doesn't seem that simple.

Indeed. :(

> For example, on armel linking against libgsm.so currently gives this:
> 
> $ dpkg-shlibdeps -v -e../a.out -Ttest
> dpkg-shlibdeps: debug: >> Scanning ../a.out (for Depends field)
> dpkg-shlibdeps: debug: Skipping lib /usr/lib/arm-linux-gnueabi/libgsm.so.1, 
> libabi=0x010100280500 != objabi=0x0101002805000200
> dpkg-shlibdeps: error: cannot find library libgsm.so.1 needed by ../a.out 
> (ELF format: 'elf32-littlearm' abi: '0101002805000200'; RPATH: '')
> dpkg-shlibdeps: debug: Library libc.so.6 found in 
> /lib/arm-linux-gnueabi/libc.so.6
> dpkg-shlibdeps: debug: Using symbols file 
> /var/lib/dpkg/info/libc6:armel.symbols for libc.so.6
> dpkg-shlibdeps: warning: binaries to analyze should already be installed in 
> their package's directory
> dpkg-shlibdeps: error: cannot continue due to the error above
> Note: libraries are not searched in other binary packages that do not have 
> any shlibs or symbols file.
> To help dpkg-shlibdeps find private libraries, you might need to use -l.
> 
> Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to
> generate a library which does not link against libc (this is used by
> sonames2elf in some packages) causes both flags to be set (maybe
> because it's compatible with both?).

Even worse, I've found at least one instance of a package containing
binaries with EABIv4 (on armel, paris-traceroute). So I guess I'll have
to remove the flags matching on EM_ARM ELF binaries for now. At least
this will get us back to the previous behavior with objdump, no
regression in that sense.

To be able to distinguish armel from armhf I'd probably need to check
the arm attributes section for Tag_ABI_VFP_args, which annoyingly
seems to be set even when the HARD flag is not set. :/ But this will
be for dpkg 1.19.x.

> This was first seen with wine:
> https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0
> https://buildd.debian.org/status/fetch.php?pkg=wine=armel=1.8.6-4=1485847712=0
>
> But there seem to be some other recent build failures relating to this
> as well.

Oh, wow, I'm not sure this is very kosher, but if it is causing build
failures, then it does not matter much.

I'm preparing an upload right now.

Thanks,
Guillem



Bug#853809: unblock: e2fsprogs/1.43.4-2

2017-01-31 Thread Theodore Y. Ts'o
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package e2fsprogs

1.43.4 is the new upstream version of e2fsprogs which fixes a RC bug
(#840733: e2fsprogs contains non-free file).  n.b., the non-free file is
only used in a regression test and isn't actually included in any
binary.  There are also a number of important bug fixes that I'd really
like to get into stretch.  See the debian changelog or [1] for more
details.

[1] http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.43.4

Note: there is a udeb involved since this will also require a d-i
release manager unblock.  I'm unclear whether there is a separate
process for requesting that particlar unblock.  Please advise.

I just uploaded 1.43.4-2 to sid today, so it will be five days old when
the Stretch Freeze hits.  So I'm filing this bug now as a heads up,
since unless the release schedule slips, this isn't going to meet the
mandatory 10 day delay which was announced in December.


Files in second .deb but not in first
-
-rw-r--r--  root/root   /usr/share/locale/fi/LC_MESSAGES/e2fsprogs.mo
-rw-r--r--  root/root   /usr/share/locale/ms/LC_MESSAGES/e2fsprogs.mo

Files in first .deb but not in second
-
lrwxrwxrwx  root/root   /sbin/fsck.ext4dev -> e2fsck
lrwxrwxrwx  root/root   /sbin/mkfs.ext4dev -> mke2fs
lrwxrwxrwx  root/root   /usr/share/man/man8/fsck.ext4dev.8.gz -> e2fsck.8.gz
lrwxrwxrwx  root/root   /usr/share/man/man8/mkfs.ext4dev.8.gz -> mke2fs.8.gz

Control files: lines which differ (wdiff format)

Installed-Size: [-3851-] {+4022+}
Pre-Depends: e2fslibs (= [-1.43.3-1),-] {+1.43.4-2),+} libblkid1 (>= 2.17.2), 
libc6 (>= 2.14), libcomerr2 (>= 1.42~WIP-2011-10-05-1), libss2 (>= 1.34-1), 
libuuid1 (>= 2.16), util-linux (>= 2.15~rc1-1)
Version: [-1.43.3-1-] {+1.43.4-2+}

unblock e2fsprogs/1.43.4-2

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

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



Bug#853808: unblock: ora2pg/18.0-1

2017-01-31 Thread gustavo panizzo
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package ora2pg

Hello,
I've uploaded a new version of ora2pg to experimental, it is a new
upstream release which allows us to ship it as part of main instead of
contrib as it no longer depends on Oracle libraries

It has the same dependencies as the previous version, 17.6-1 already on
sid

thanks

unblock ora2pg/18.0-1

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

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



Bug#853787: wxmaxima: loadfile: failed to load /usr/share/wxMaxima/wxmathml.lisp

2017-01-31 Thread Gunter Königsmann
What is the exact error message you get? My hope is that wxMaxima might have 
mentioned the line number it runs into an error in.
-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#853751: [Pkg-dns-devel] Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-01-31 Thread Robert Edmonds
Steven Chamberlain wrote:
> Hi,
> 
> This bug has become important, since src:unbound became part of the
> build-essential closure (due to Build-Depends of gnutls28).  So this is
> now a blocking issue for rebootstrapping kfreebsd and hurd.

Hi, Steven:

Thanks for this patch. Is this needed before stretch releases? (IIUC,
kfreebsd and hurd are not release architectures?)

> You could perhaps use libbsd unconditionally - on linux arches too - and
> then the copy in compat/ would no longer be used.
> 
> There is a long history of software embedding copies of arc4random, and
> then forgetting to maintain them.  There is a longer discussion of that
> here:  https://wiki.debian.org/arc4random
> 
> I hold the opinion that packages should use the libbsd implementation
> whereever possible, and then in Debian we would only need to maintain it
> in one place, to the benefit of all reverse-deps.

I agree with this reasoning, but I'd rather have the libbsd support in
an upstream Unbound release rather than in the Debian package. I'll see
about producing a patch suitable for upstream.

-- 
Robert Edmonds
edmo...@debian.org



Bug#853805: unknown-horizons: Use .png icons instead of .xpm

2017-01-31 Thread Jeremy Bicha

From 8bf142da177acc287e4d5e5f53c26ee3cf074a60 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Tue, 31 Jan 2017 19:47:24 -0500
Subject: [PATCH] Use .png app icons instead of obsolete .xpm, Drop Debian menu

Closes: #853805
---
 debian/control |  2 +-
 debian/install |  1 -
 debian/menu|  6 --
 debian/rules   | 14 +++---
 4 files changed, 12 insertions(+), 11 deletions(-)
 delete mode 100644 debian/install
 delete mode 100644 debian/menu

diff --git a/debian/control b/debian/control
index ad0bbd3..59cfb9d 100644
--- a/debian/control
+++ b/debian/control
@@ -9,7 +9,7 @@ Build-Depends:
  dh-python,
  docbook-xml,
  docbook-xsl,
- imagemagick,
+ icnsutils,
  intltool,
  python,
  xsltproc
diff --git a/debian/install b/debian/install
deleted file mode 100644
index 6870a45..000
--- a/debian/install
+++ /dev/null
@@ -1 +0,0 @@
-unknown-horizons-32x32.xpm  usr/share/pixmaps
diff --git a/debian/menu b/debian/menu
deleted file mode 100644
index 8075772..000
--- a/debian/menu
+++ /dev/null
@@ -1,6 +0,0 @@
-?package(unknown-horizons):needs="X11" \
- section="Games/Strategy" \
- title="Unknown Horizons" \
- longtitle="Unknown Horizons - 2D realtime strategy simulation" \
- command="/usr/games/unknown-horizons" \
- icon="/usr/share/pixmaps/unknown-horizons-32x32.xpm"
diff --git a/debian/rules b/debian/rules
index a43bf83..27f2862 100755
--- a/debian/rules
+++ b/debian/rules
@@ -14,9 +14,17 @@ override_dh_auto_install:
 	 debian/unknown-horizons/usr/share/unknown-horizons/content/fonts/OFL
 	# Remove executable bit from files like tm_* and make Lintian happy
 	find debian/unknown-horizons/usr/share/unknown-horizons -type f -exec chmod a-x {} \;
-
-override_dh_auto_build-indep:
-	convert -monitor -resize 32x32 $(CURDIR)/content/packages/unknown-horizons.xpm $(CURDIR)/unknown-horizons-32x32.xpm
+	mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/16x16/apps
+	mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/32x32/apps
+	mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/128x128/apps
+	mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/256x256/apps
+	mkdir -p ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/512x512/apps
+	icns2png -x ${CURDIR}/content/gui/icons/Icon.icns -o ${CURDIR}
+	mv ${CURDIR}/Icon_16x16x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/16x16/apps/unknown-horizons.png
+	mv ${CURDIR}/Icon_32x32x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/32x32/apps/unknown-horizons.png
+	mv ${CURDIR}/Icon_128x128x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/128x128/apps/unknown-horizons.png
+	mv ${CURDIR}/Icon_256x256x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/256x256/apps/unknown-horizons.png
+	mv ${CURDIR}/Icon_512x512x32.png ${CURDIR}/debian/unknown-horizons/usr/share/icons/hicolor/512x512/apps/unknown-horizons.png
 
 get-orig-source:
 	uscan --force-download --download-current-version --repack --compression xz
-- 
2.10.2



Bug#828482: bug 828482 fix

2017-01-31 Thread Di-Shi Sun
Hi Sebastian,

I am pretty sure that 4.11.3+dfsg-1 is not influenced by 828482 (FTBFS with 
openssl 1.1.0). Please send us the build log showing the issue you report.

Thanks,

Di-Shi Sun.

-Original Message-
From: Sebastian Andrzej Siewior [mailto:sebast...@breakpoint.cc] 
Sent: Wednesday, February 01, 2017 4:43 AM
To: Di-Shi Sun
Cc: 828...@bugs.debian.org
Subject: Re: bug 828482 fix

On 2016-10-27 08:56:23 [+0800], Di-Shi Sun wrote:
> osptoolkit/3.4.2-1.2 is out of date and osptoolkit/4.11.3+dfsg-1 has 
> been released to replace it.

so what? 4.11.3+dfsg-1 is still affected by this problem.

> Regards,
> 
>  
> 
> Di-Shi Sun
> VoIP Routing, Accounting, Security

Sebastian



Bug#853807: -d stuck at end of -v in man page

2017-01-31 Thread 積丹尼 Dan Jacobson
Package: hydra
Version: 8.3-2
Severity: minor
File: /usr/share/man/man1/hydra.1.gz

   -v / -V
  verbose  mode  / show login+pass combination for each attempt -d
  debug mode



Bug#853806: ITP: golang-github-mrunalp-fileutils -- collection of utilities for file manipulation in golang

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-mrunalp-fileutils
  Version : 0.0~git20160930.0.4ee1cc9-1
  Upstream Author : Mrunal Patel
* URL : https://github.com/mrunalp/fileutils
* License : Apache-2.0
  Programming Lang: Go
  Description : Collection of utilities for file manipulation in golang

 This package is a collection of utilities for file manipulation in Go.
 .
 The library is based on the interface implemented by the Docker
 pkg/archive and pkg/idtools modules but does copies instead of
 handling archive formats.


signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#853805: unknown-horizons: Use .png icons instead of .xpm

2017-01-31 Thread Jeremy Bicha
Package: unknown-horizons
Version: 2017.1+ds-2
Tags: patch

unknown-horizons does not show up in the GNOME Software app in Ubuntu
but it does show up in Debian. This is because the appstream-generator
used by Ubuntu is a bit older and rejects all .xpm icons.

http://appstream.ubuntu.com/zesty/universe/issues/unknown-horizons.html
https://appstream.debian.org/sid/main/issues/unknown-horizons.html

The fix is pretty simple: use .png icons and do not ship a .xpm icon.
The higher resolution icons look better anyway.

I did see one difference. The .xpm has a banner that says Unknown
Horizons but the .png's don't. I think the clearer icon in an
interface like GNOME Shell's Activities Overview is more important
than that banner.

In my next email I'll attach a patch for this. There's also a patch to
drop the Debian menu because it's obsolete if your package has a
.desktop.
https://www.debian.org/doc/debian-policy/ch-opersys.html#s-menus

Thanks,
Jeremy Bicha



Bug#853802: FTBFS on armhf: cannot find library libmad.so.0

2017-01-31 Thread Rene Engelhard
On Wed, Feb 01, 2017 at 02:34:04AM +0100, Rene Engelhard wrote:
> Sounds like #853793.

Actually, not sure. Shouldn't have writen this in my current tired state.

Regards,
 
Rene



Bug#853802: FTBFS on armhf: cannot find library libmad.so.0

2017-01-31 Thread Rene Engelhard
Hi,

[ not the maintainer ]

On Wed, Feb 01, 2017 at 02:23:34AM +0100, Adam Borowski wrote:
[...]
>dh_shlibdeps
> dpkg-shlibdeps: error: cannot find library libmad.so.0 needed by 
> debian/sonic-visualiser/usr/bin/sonic-visualiser (ELF format: 
> 'elf32-littlearm' abi: '0101002805000400'; RPATH: '')
> dpkg-shlibdeps: warning: tried to merge the same object (ld-linux-armhf.so.3) 
> twice in a symfile
> dpkg-shlibdeps: error: cannot continue due to the error above
> Note: libraries are not searched in other binary packages that do not have 
> any shlibs or symbols file.
> To help dpkg-shlibdeps find private libraries, you might need to use -l.
> dh_shlibdeps: dpkg-shlibdeps -Tdebian/sonic-visualiser.substvars 
> debian/sonic-visualiser/usr/bin/sonic-visualiser returned exit code 2
> debian/rules:18: recipe for target 'binary' failed

Sounds like #853793.

Regards,

Rene



Bug#853804: ITP: golang-github-bshuster-repo-logrus-logstash-hook -- Logstash hook for logrus

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-bshuster-repo-logrus-logstash-hook
  Version : 0.0~git20170102.0.5f729f2-1
  Upstream Author : Boaz Shuster
* URL : https://github.com/bshuster-repo/logrus-logstash-hook
* License : Expat
  Programming Lang: Go
  Description : Logstash hook for Logrus logging library for Go

 Logrus is a structured logger for Go (golang), completely
 API compatible with the standard library logger.
 .
 This package is a hook to enable messages logged by Logrus to be sent
 to a Logstash instance.



signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#853803: Please add a bzip2.pc pkg-config file

2017-01-31 Thread John Marshall
Package: libbz2-dev

Unfortunately upstream bzip2 does not provide a pkg-config file for libbz2, 
which people who like pkg-config could use when compiling their software 
against libbz2.

For example, Fedora adds such a file, which they have called bzip2.pc, 
themselves in their RPM package: see 
https://bugzilla.redhat.com/show_bug.cgi?id=1289576

Someone notes here that they made a similar request to upstream in December 
2015, but apparently without a response: 
https://github.com/libimobiledevice/sbmanager/issues/1#issuecomment-163919580

Please consider adding a local patch so that the Debian libbz2-dev package also 
provides a pkg-config file, bzip2.pc.

Thanks,

John

--
 The Wellcome Trust Sanger Institute is operated by Genome Research
 Limited, a charity registered in England with number 1021457 and a
 company registered in England with number 2742969, whose registered
 office is 215 Euston Road, London, NW1 2BE.



Bug#853801: qjoypad: segfaults on left click

2017-01-31 Thread Frédéric Brière
Package: qjoypad
Version: 4.1.0-2
Severity: important

Left-clicking on the systray icon (or on the main window with --notray)
immediately triggers a segfault:

#0  0x5616b57ba023 in QBasicAtomicInt::deref() (this=0x7ffd)
at /usr/include/qt4/QtCore/qatomic_x86_64.h:133
#1  0x5616b57ba023 in QString::~QString() (this=0x7ffd91e48d50, 
__in_chrg=) at /usr/include/qt4/QtCore/qstring.h:880
#2  0x5616b57ba023 in LayoutEdit::LayoutEdit(LayoutManager*) 
(this=0x5616b67266f0, l=) at layout_edit.cpp:50
#3  0x5616b57b4240 in LayoutManager::iconClick() (this=0x5616b670b330)
at layout.cpp:258
#4  0x7fa25a512660 in QMetaObject::activate(QObject*, QMetaObject const*, 
int, void**) (sender=0x5616b6708dc0, m=m@entry=0x7fa25b546720 
, 
local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffd91e48f00) 
at kernel/qobject.cpp:3567
#5  0x7fa25b0d258e in 
QSystemTrayIcon::activated(QSystemTrayIcon::ActivationReason) (this=, _t1=, 
_t1@entry=QSystemTrayIcon::Trigger)
at .moc/release-shared/moc_qsystemtrayicon.cpp:147
#6  0x7fa25b09d335 in qtsystray_sendActivated(QSystemTrayIcon*, int) 
(i=, r=r@entry=3) at util/qsystemtrayicon.cpp:663
#7  0x7fa25b0b351e in QSystemTrayIconWidget::mousePressEvent(QMouseEvent*) 
(this=0x5616b671e260, ev=0x7ffd91e493f0)
at util/qxembedsystemtrayicon_x11.cpp:202
#8  0x7fa25aa81a40 in QWidget::event(QEvent*) (this=0x5616b671e260, 
event=0x7ffd91e493f0) at kernel/qwidget.cpp:8385
#9  0x7fa25aa2a54c in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
(this=this@entry=0x5616b669d110, receiver=receiver@entry=0x5616b671e260, 
e=e@entry=0x7ffd91e493f0) at kernel/qapplication.cpp:4570
#10 0x7fa25aa32ca7 in QApplication::notify(QObject*, QEvent*) 
(this=, receiver=0x5616b671e260, e=0x7ffd91e493f0)
at kernel/qapplication.cpp:4113
#11 0x7fa25a4fdf1d in QCoreApplication::notifyInternal(QObject*, QEvent*) 
(this=0x7ffd91e49c60, receiver=receiver@entry=0x5616b671e260, 
event=event@entry=0x7ffd91e493f0) at kernel/qcoreapplication.cpp:955
#12 0x7fa25aa30ccb in QCoreApplication::sendEvent(QObject*, QEvent*) 
(event=, receiver=)
at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231
#13 0x7fa25aa30ccb in QApplicationPrivate::sendMouseEvent(QWidget*, 
QMouseEvent*, QWidget*, QWidget*, QWidget**, QPointer&, bool) 
(receiver=receiver@entry=0x5616b671e260, event=event@entry=0x7ffd91e493f0, 
alienWidget=alienWidget@entry=0x0, 
nativeWidget=nativeWidget@entry=0x5616b671e260, 
buttonDown=buttonDown@entry=0x7fa25b550348 , 
lastMouseReceiver=..., spontaneous=true) at kernel/qapplication.cpp:3178
#14 0x7fa25aaac1a9 in QETWidget::translateMouseEvent(_XEvent const*) 
(this=this@entry=0x5616b671e260, event=event@entry=0x7ffd91e49750)
at kernel/qapplication_x11.cpp:4557
#15 0x7fa25b5c in QApplication::x11ProcessEvent(_XEvent*) 
(this=0x7ffd91e49c60, event=event@entry=0x7ffd91e49750) at 
kernel/qapplication_x11.cpp:3674
#16 0x7fa25aad4502 in x11EventSourceDispatch(GSource*, GSourceFunc, 
gpointer) (s=0x5616b669f920, callback=0x0, user_data=0x0)
at kernel/qguieventdispatcher_glib.cpp:146
#17 0x7fa2585ab7f7 in g_main_dispatch (context=0x5616b669e5a0)
at ././glib/gmain.c:3203
#18 0x7fa2585ab7f7 in g_main_context_dispatch 
(context=context@entry=0x5616b669e5a0) at ././glib/gmain.c:3856
#19 0x7fa2585aba60 in g_main_context_iterate 
(context=context@entry=0x5616b669e5a0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=)
at ././glib/gmain.c:3929
#20 0x7fa2585abb0c in g_main_context_iteration (context=0x5616b669e5a0, 
may_block=may_block@entry=1) at ././glib/gmain.c:3990
#21 0x7fa25a52e854 in 
QEventDispatcherGlib::processEvents(QFlags) 
(this=0x5616b669e460, flags=...)
at kernel/qeventdispatcher_glib.cpp:425
#22 0x7fa25aad45d6 in 
QGuiEventDispatcherGlib::processEvents(QFlags) 
(this=, flags=...)
at kernel/qguieventdispatcher_glib.cpp:204
#23 0x7fa25a4fc7ef in 
QEventLoop::processEvents(QFlags) 
(this=this@entry=0x7ffd91e49b30, flags=...)
at kernel/qeventloop.cpp:149
#24 0x7fa25a4fcb55 in 
QEventLoop::exec(QFlags) 
(this=this@entry=0x7ffd91e49b30, flags=...) at kernel/qeventloop.cpp:204
#25 0x7fa25a502bd9 in QCoreApplication::exec() ()
at kernel/qcoreapplication.cpp:1227
#26 0x5616b57a716a in main(int, char**) (argc=, 
argv=) at main.cpp:216


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

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

Versions of packages qjoypad depends on:
ii  libc6   2.24-9
ii  libgcc1 1:6.3.0-5
ii  libqtcore4  4:4.8.7+dfsg-11
ii  libqtgui4   4:4.8.7+dfsg-11
ii  libstdc++6  6.3.0-5
ii  libx11-62:1.6.4-3
ii  libxtst6

Bug#853800: 2048-qt: Does not show up in GNOME Software app

2017-01-31 Thread Jeremy Bicha

From 182effecf3cdd42fe9bde07d88144ec71f5974c6 Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Tue, 31 Jan 2017 19:40:19 -0500
Subject: [PATCH 1/2] Use .png icons instead of obsolete .xpm

Closes: #853800
---
 debian/2048-qt.install |   3 +-
 debian/2048-qt.xpm | 128 -
 2 files changed, 2 insertions(+), 129 deletions(-)
 delete mode 100644 debian/2048-qt.xpm

diff --git a/debian/2048-qt.install b/debian/2048-qt.install
index 7035daf..8c96930 100644
--- a/debian/2048-qt.install
+++ b/debian/2048-qt.install
@@ -1,2 +1,3 @@
-debian/2048-qt.xpm /usr/share/pixmaps
 res/2048-qt.desktop /usr/share/applications/
+res/icons/*x* /usr/share/icons/hicolor
+res/icons/scalable /usr/share/icons/hicolor
diff --git a/debian/2048-qt.xpm b/debian/2048-qt.xpm
deleted file mode 100644
index 521aeb7..000
--- a/debian/2048-qt.xpm
+++ /dev/null
@@ -1,128 +0,0 @@
-/* XPM */
-static char *_048_qt[] = {
-/* columns rows colors chars-per-pixel */
-"32 32 90 1 ",
-"  c #EDC22D",
-". c #EDC22E",
-"X c #EDC330",
-"o c #EDC433",
-"O c #EDC435",
-"+ c #EEC539",
-"@ c #EEC63C",
-"# c #EEC63D",
-"$ c #80C242",
-"% c #80C342",
-"& c #83C547",
-"* c #84C548",
-"= c #87C74D",
-"- c #8BC852",
-"; c #8DC956",
-": c #95CD62",
-"> c #98CE66",
-", c #99CF68",
-"< c #9DD16E",
-"1 c #A2D374",
-"2 c #A6D57B",
-"3 c #EEC843",
-"4 c #EFC946",
-"5 c #EFC948",
-"6 c #EFCB4F",
-"7 c #EFCC53",
-"8 c #EFCD56",
-"9 c #F0CE5A",
-"0 c #F0CF5E",
-"q c #F0D061",
-"w c #F0D062",
-"e c #F0D064",
-"r c #F1D36C",
-"t c #F1D473",
-"y c #F1D573",
-"u c #F1D576",
-"i c #F2D679",
-"p c #F2D77E",
-"a c #AAD781",
-"s c #AED986",
-"d c #B7DD94",
-"f c #B8DD95",
-"g c #BEE09E",
-"h c #F3DA87",
-"j c #F3DA88",
-"k c #F3DA89",
-"l c #F3DB8C",
-"z c #F3DC91",
-"x c #F3DD95",
-"c c #F4DF9B",
-"v c #C0E1A1",
-"b c #C6E4AA",
-"n c #C8E5AD",
-"m c #F4E0A0",
-"M c #F4E2A6",
-"N c #F5E3AB",
-"B c #F5E4AC",
-"V c #F5E5B3",
-"C c #F5E6B7",
-"Z c #F5E7B7",
-"A c #F6E7BA",
-"S c #F6E9BF",
-"D c #D5EBC0",
-"F c #D6ECC2",
-"G c #D7ECC4",
-"H c #D8EDC5",
-"J c #DCEECA",
-"K c #DFF0CF",
-"L c #F6E9C2",
-"P c #F6EAC4",
-"I c #F6EAC6",
-"U c #F6EBC8",
-"Y c #F7ECCB",
-"T c #F7ECCE",
-"R c #F7EDD1",
-"E c #F7EFD8",
-"W c #F7EFD9",
-"Q c #E2F1D3",
-"! c #E3F2D5",
-"~ c #E6F3D9",
-"^ c #F8F0DA",
-"/ c #F8F1DF",
-"( c #ECF6E2",
-") c #EDF7E4",
-"_ c #F8F1E0",
-"` c #F9F5ED",
-"' c #F0F8E9",
-"] c #F4FAEE",
-"[ c #F7FBF2",
-"{ c #FBFDF8",
-/* pixels */
-"",
-"",
-"",
-"",
-"XhPN8  0LPqhz  qCC0 ",
-"@x50R o/rq_+  8YB OE@3Ro",
-"_OeP  St oPtB +_OoEO",
-"   eC pM  ck cueB  pTPr ",
-"  3R3 pm  xl0B qB  BmLx ",
-" +Uq  rS  CiTABLElqC  S9",
-"OLr   @/+@/4800kL79C  A6",
-"p`^^Wu h//keB  mSLz ",
-"",
-"",
-"",
-"",
-"",
-"",
-"",
-"%%%~!f%%%-",
-"%%%KH,1!v%%K",
-"%%:{*%%:{*n{J1%%",
-"%%aQ%%$$]>*'",
-"%%sG%%$$)>&'",
-"%%<[%%$;{&&'",
-"%%%(d&=nD%%'",
-"%%%:!'{G&%%n!2%%",
-"%~*%%%*%%%",
-"%",
-"&%%%",
-"",
-""
-};
-- 
2.10.2

From c8533b374f2888e1d45f60cd97ed73a54d616dea Mon Sep 17 00:00:00 2001
From: Jeremy Bicha 
Date: Tue, 31 Jan 2017 19:51:56 -0500
Subject: [PATCH 2/2] Drop obsolete Debian menu

---
 debian/2048-qt.menu | 4 
 1 file changed, 4 deletions(-)
 delete mode 100644 debian/2048-qt.menu

diff --git a/debian/2048-qt.menu b/debian/2048-qt.menu
deleted file mode 100644
index db966ef..000
--- a/debian/2048-qt.menu
+++ /dev/null
@@ -1,4 +0,0 @@
-?package(2048-qt):needs="X11" section="Games/Puzzles" \
-  title="2048-qt" command="/usr/games/2048-qt" \
-  icon="/usr/share/pixmaps/2048-qt.xpm" \
-  longtitle="2048-qt: mathematics based puzzle game"
-- 
2.10.2



Bug#853800: 2048-qt: Does not show up in GNOME Software app

2017-01-31 Thread Jeremy Bicha
Package: 2048-qt
Version: 0.1.6-1
Tags: patch

2048-qt does not show up in the GNOME Software app. This app will be
included in the GNOME version of the next stable Debian release.

I don't use KDE but maybe this affects their app installer too.

https://appstream.debian.org/sid/main/issues/2048-qt.html

The fix is pretty simple: use .png icons and do not ship a .xpm icon.
(I think shipping a .xpm icon will upset the appstream generator).

In my next email I'll attach a patch for this. There's also a patch to
drop the Debian menu because it's obsolete if your package has a
.desktop.
https://www.debian.org/doc/debian-policy/ch-opersys.html#s-menus

Thanks,
Jeremy Bicha



Bug#853107: xapian-core: FTBFS under pbuilder with USENETWORK=no

2017-01-31 Thread Olly Betts
On Tue, Jan 31, 2017 at 10:09:57PM +0100, Georg Faerber wrote:
> > Daniel: What version of pbuilder are you using?  If it's more than a
> > year old, then upgrading will probably fix this.  If not, then either
> > that fix has regressed in pbuilder regression, or else something more
> > complex is going on.
> 
> This is happening here [1] as well, which is a recent pbuilder version,
> I guess. I'm wondering if this is a bug in pbuilder or a wrapper around.
> 
> Cheers,
> Georg
> (who debugged for some hours a similar problem over here [2]...)

Did you reach any useful conclusions?

FWIW, the code that appears to fail is:

struct addrinfo hints;
memset(, 0, sizeof(struct addrinfo));
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_PASSIVE | AI_ADDRCONFIG | AI_NUMERICSERV;
hints.ai_protocol = 0;
hints.ai_canonname = NULL;
hints.ai_addr = NULL;
hints.ai_next = NULL;

const char * node = host.empty() ? NULL : host.c_str();
struct addrinfo *result;
int s = getaddrinfo(node, str(port).c_str(), , );
 
if (s != 0) {
throw Xapian::NetworkError("Couldn't resolve host " + host,
   eai_to_xapian(s));
}

Where host is "127.0.0.1" and port is "1239".  It seems the error is:

EAI_NONAME
  The  node  or service is not known; or both node and service are
  NULL; or AI_NUMERICSERV was specified in hints.ai_flags and ser‐
  vice was not a numeric port-number string.

The reproducible build used to work but it looks like it regressed in
1.3.4-1:

https://tests.reproducible-builds.org/debian/history/xapian-core.html

That's very suspicious as that's the first version packaged for Debian
which used getaddrinfo() (1.2.x used gethostbyname(), etc), and the
history shows that 1.2.x continued to build OK at the same time.  So
that seems to point firmly to this not being a pbuilder regression.

But I've no idea what the cause is.  My only thoughts are that perhaps
there's only IPv6 loopback (but then 1.2.x wouldn't work), or that
getaddrinfo() is interacting badly with the restricted networking.

Cheers,
Olly



Bug#604754: Sehr geehrter E-Mail-Benutzer

2017-01-31 Thread Andrea Haider




Sehr geehrter E-Mail-Benutzer

Bitte folgen Sie dem Link, um Ihr Webmail-Konto zu aktualisieren:  
http://0sptfn211.ukit.me


Vielen Dank



Bug#853799: Please update to stable libevent 2.1 series

2017-01-31 Thread Eduard Bloch
Source: libevent
Version: 2.1.4~alpha-0.1+b1
Severity: wishlist

Version 2.1.8-stable has been released a couple of days ago on
libevent.org and I guess it's time to update this rotten package in
Experimental.

Regards,
Eduard.

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

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

-- 
Religionen haben Mord und Selbstmord verurteilt, haben aber, vom
Menschenopfer ganz abgesehen, grausamste Verfolgungen
Andersgläubiger erlaubt oder geboten.
-- Fritz Max Bauer



Bug#841185: closing RFS: genwqe-user/4.0.18-1 [ITP #826774]

2017-01-31 Thread Fernando Seiti Furusato
On Tue, 31 Jan 2017 22:20:44 + Bart Martens
 wrote:
> Package genwqe-user has been removed from mentors.
>
>

Sorry, I had deleted and re-uploaded it but had problems with the queue,
which was solved.
I fixed some problems with the package, that is why I reopened this RFS.

It can be checked out at:

  dget -x
https://mentors.debian.net/debian/pool/contrib/g/genwqe-user/genwqe-user_4.0.18-1.dsc

Thanks!

-- 
Fernando Seiti Furusato
IBM Linux Technology Center





signature.asc
Description: OpenPGP digital signature


Bug#852398: To load extensions

2017-01-31 Thread Alok Singh
Copying this over from #851692. A method of enabling extensions without
re-compiling Chromium. Not saying it is ideal

1. Find your extensions:
They are in $XDG_CONFIG_DIR/chromium//Extensions//

For example, uBlock is at
/home/alok/.config/chromium/Default/Extensions/cjpalhdlnbpafiamejdnhcphjbkeiagm/1.9.4_0

2. Create a file in /etc/chromium.d/enable-extensions with the content
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --load-extension="

3. You have to create multiple lines of the form above for each profile.
Note that you will have to update this file when the extension version
changes. If you have the same extension in multiple profiles, you will have
make explicit entries for it as per step 2.

-- 
—
Alok


Bug#853798: mpv: Segfaults on TV input

2017-01-31 Thread Frédéric Brière
Package: mpv
Version: 0.23.0-1
Severity: important

mpv quickly segfaults (before displaying any video) on TV input:

  $ mpv tv://
  Playing: tv://
  [tv] Selected driver: v4l2
  [tv]  name: Video 4 Linux 2 input
  [tv] Selected device: BT878 video (Hauppauge (bt878))
  [tv]  Tuner cap:
  [tv]  Tuner rxs: MONO
  [tv]  Capabilities:  video capture  video overlay  VBI capture device  tuner  
read/write  streaming
  [tv]  supported norms: 0 = NTSC; 1 = NTSC-M; 2 = NTSC-M-JP; 3 = NTSC-M-KR; 4 
= PAL; 5 = PAL-BG; 6 = PAL-H; 7 = PAL-I; 8 = PAL-DK; 9 = PAL-M; 10 = PAL-N; 11 
= PAL-Nc; 12 = PAL-60; 13 = SECAM; 14 = SECAM-B; 15 = SECAM-G; 16 = SECAM-H; 17 
= SECAM-DK; 18 = SECAM-L; 19 = SECAM-Lc;
  [tv]  inputs: 0 = Television; 1 = Composite1; 2 = S-Video; 3 = Composite3;
  [tv]  Current input: 0
  [tv]  Current format: YVU420
  [tv] current audio mode is : MONO
  Segmentation fault


For what it's worth, this bug does not seem to be present in MPlayer.

Backtrace follows.  Let me know if I can be of any further help.


#0  0x557aee3e8dc7 in set_norm_and_freq (tvh=tvh@entry=0x7f397001e700, 
chan=0x5a0005) at ../stream/tv.c:430
#1  0x557aee3e94d6 in open_tv (tvh=tvh@entry=0x7f397001e700)
at ../stream/tv.c:599
#2  0x557aee3950e4 in demux_open_tv (demuxer=0x7f3970007590, 
check=) at ../demux/demux_tv.c:52
#3  0x557aee383ab3 in open_given_type (global=global@entry=0x557aef6fc2b0, 
log=log@entry=0x7f39700035b0, desc=0x557aee6bf4c0 , 
stream=stream@entry=0x7f39805fc050, params=params@entry=0x7f397bffea50, 
check=check@entry=DEMUX_CHECK_REQUEST) at ../demux/demux.c:1274
#4  0x557aee383ef7 in demux_open (stream=0x7f39805fc050, 
params=params@entry=0x7f397bffea50, global=global@entry=0x557aef6fc2b0)
at ../demux/demux.c:1354
#5  0x557aee3840b6 in demux_open_url (url=, 
params=params@entry=0x7f397bffea50, cancel=, 
global=global@entry=0x557aef6fc2b0) at ../demux/demux.c:1393
#6  0x557aee3c5155 in open_demux_thread (pctx=0x7ffc0dd234f0)
at ../player/loadfile.c:797
#7  0x557aee3c8ca0 in thread_wrapper (pctx=0x7ffc0dd23460)
at ../player/misc.c:267
#8  0x7f39a996b424 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x7f39a4aa19bf in clone () from /lib/x86_64-linux-gnu/libc.so.6
#0  0x557aee3e8dc7 in set_norm_and_freq (tvh=tvh@entry=0x7f397001e700, 
chan=0x5a0005) at ../stream/tv.c:430
#1  0x557aee3e94d6 in open_tv (tvh=tvh@entry=0x7f397001e700)
at ../stream/tv.c:599
#2  0x557aee3950e4 in demux_open_tv (demuxer=0x7f3970007590, 
check=) at ../demux/demux_tv.c:52
#3  0x557aee383ab3 in open_given_type (global=global@entry=0x557aef6fc2b0, 
log=log@entry=0x7f39700035b0, desc=0x557aee6bf4c0 , 
stream=stream@entry=0x7f39805fc050, params=params@entry=0x7f397bffea50, 
check=check@entry=DEMUX_CHECK_REQUEST) at ../demux/demux.c:1274
#4  0x557aee383ef7 in demux_open (stream=0x7f39805fc050, 
params=params@entry=0x7f397bffea50, global=global@entry=0x557aef6fc2b0)
at ../demux/demux.c:1354
#5  0x557aee3840b6 in demux_open_url (url=, 
params=params@entry=0x7f397bffea50, cancel=, 
global=global@entry=0x557aef6fc2b0) at ../demux/demux.c:1393
#6  0x557aee3c5155 in open_demux_thread (pctx=0x7ffc0dd234f0)
at ../player/loadfile.c:797
#7  0x557aee3c8ca0 in thread_wrapper (pctx=0x7ffc0dd23460)
at ../player/misc.c:267
#8  0x7f39a996b424 in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#9  0x7f39a4aa19bf in clone () from /lib/x86_64-linux-gnu/libc.so.6


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

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

Versions of packages mpv depends on:
ii  libasound2  1.1.3-4
ii  libass5 1:0.13.4-2
ii  libavcodec577:3.2.2-2
ii  libavdevice57   7:3.2.2-2
ii  libavfilter67:3.2.2-2
ii  libavformat57   7:3.2.2-2
ii  libavutil55 7:3.2.2-2
ii  libbluray1  1:0.9.3-3
ii  libc6   2.24-9
ii  libcdio-cdda1   0.83-4.3
ii  libcdio-paranoia1   0.83-4.3
ii  libcdio13   0.83-4.3
ii  libdrm2 2.4.74-1
ii  libdvdnav4  5.0.3-3
ii  libdvdread4 5.0.3-2
ii  libegl1-mesa [libegl1-x11]  13.0.3-1
ii  libgbm1 13.0.3-1
ii  libgl1-mesa-glx [libgl1]13.0.3-1
ii  libjack0 [libjack-0.125]

Bug#853797: xjdic: May crash on long definitions when looking up plain form verbs

2017-01-31 Thread Frédéric Brière
Package: xjdic
Version: 24-10
Severity: normal

xjdic may trigger a buffer overflow on long definitions when looking up
plain form verbs, which occurs when fed an inflected verb in kanji form:

  $ echo '出て' | xjdic
  [...]
  *** buffer overflow detected ***: xjdic terminated
  [...]
  Aborted

The overflow happens in Vlookup(), at xjdfrontend.c, line 1155: vline is
just too short, at 250 bytes, for some of the longest definitions.
(出る seems to be the most extreme case, at 1129 bytes.)


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

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

Versions of packages xjdic depends on:
pn  edict:all 
pn  kanjidic:all  
ii  libc6 2.24-9

Versions of packages xjdic recommends:
ii  kterm  6.2.0-46.2

xjdic suggests no packages.

-- no debconf information


Bug#853775: a confirmation the newer pango helped

2017-01-31 Thread Milan Vancura
I may confirm that this workflow helped:

$ apt-get source libpango1.0-0/testing
$ cd pango1.0-1.40.3
$ # solve the dependency on newer version of libthai
$ dpkg-buildpackage -b -uc -d # "-d" because of the dependency on debhelper>=10

$ sudo dpkg -i ~user/{libpango,gir}*.deb  # needed BEFORE building inkscape 
package!

$ cd ; apt-get source inkscape/jessie-backports
$ cd inkscape-0.92.0
$ vim debian/control # fix the dependency on libpango1.0 >= 1.37.1
$ dpkg-buildpackage -b -uc -d # again, "-d" because of the dependency on 
debhelper>=10
$ # make a coffee or buy a faster machine than I have

$ sudo dpkg -i ~user/inkscape*.deb

$ # be happy with the test document, for example font features work now



Bug#853467: goldencheetah: Upload new version to support Garmin CIQ developer fields

2017-01-31 Thread Satoru KURASHIKI
hi,

On Tue, Jan 31, 2017 at 6:35 PM, Markus Braun  wrote:
> I'm using a Garmin watch as runner to track my workouts. Some days ago
> I received a Stryd footpod to track running power. Running power is
> recorded to the FIT file in an CIQ developer field. The current Debian
> version of goldencheetah does not support the additional fields but the
> current GIT version of goldencheetah does. The developers started adding
> these in October 2016. The current official version on
> www.goldencheetah.org does support my FIT files. But it is not possible
> to install the Debian package on SID because of missing dependencies.

I've uploaded GC4.0 series development build early 2016.
For now, upstream seems to focus on making enhancement into GC3.0
series stable build, at least since August 2016.

> Could you please provide a more current version of goldencheetah?

I think that soon after upstrem releasing new 4.0 series build, I will
update its packaging.
https://github.com/GoldenCheetah/GoldenCheetah/releases

regards,
-- 
KURASHIKI Satoru



Bug#852924: collectd: FTBFS: ld: cannot find -lssl

2017-01-31 Thread Sebastian Andrzej Siewior
control: reassign -1 collectd 5.7.1-1
control: retitle -1 Uses "-lssl -lcrypto" but does not depend on libssl

On 2017-01-28 12:13:57 [+0100], Marc Fournier wrote:
> On Sat, Jan 28, 2017 at 09:30:20AM +0100, Lucas Nussbaum wrote:
> > During a rebuild of all packages in sid, your package failed to build on
> > amd64.
> > 
> > Relevant part (hopefully):
> > > /bin/bash ../libtool  --tag=CC   --mode=link x86_64-linux-gnu-gcc -Wall 
> > > -Werror -g -O2 -fdebug-prefix-map=/<>=. 
> > > -fstack-protector-strong -Wformat -Werror=format-security -Wall 
> > > -Wno-error=deprecated-declarations -module -avoid-version 
> > > -export-symbols-regex '\' -Wl,-z,relro -o 
> > > notify_email.la -rpath /usr/lib/collectd notify_email.lo -lesmtp -lssl 
> > > -lcrypto 
> > > libtool: link: /usr/bin/x86_64-linux-gnu-nm -B  .libs/notify_email.o   | 
> > > sed -n -e 's/^.*[ ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
> > > ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | 
> > > /bin/sed 's/.* //' | sort | uniq > .libs/notify_email.exp
> > > libtool: link: /bin/grep -E -e "\" 
> > > ".libs/notify_email.exp" > ".libs/notify_email.expT"
> > > libtool: link: mv -f ".libs/notify_email.expT" ".libs/notify_email.exp"
> > > libtool: link: echo "{ global:" > .libs/notify_email.ver
> > > libtool: link:  cat .libs/notify_email.exp | sed -e "s/\(.*\)/\1;/" >> 
> > > .libs/notify_email.ver
> > > libtool: link:  echo "local: *; };" >> .libs/notify_email.ver
> > > libtool: link:  x86_64-linux-gnu-gcc -shared  -fPIC -DPIC  
> > > .libs/notify_email.o   -lesmtp -lssl -lcrypto  -g -O2 
> > > -fstack-protector-strong -Wl,-z -Wl,relro   -Wl,-soname 
> > > -Wl,notify_email.so -Wl,-version-script -Wl,.libs/notify_email.ver -o 
> > > .libs/notify_email.so
> > > /usr/bin/ld: cannot find -lssl
> > > /usr/bin/ld: cannot find -lcrypto
> > > collect2: error: ld returned 1 exit status
> > 
> > The full build log is available from:
> >http://aws-logs.debian.net/2017/01/28/collectd_5.7.1-1_unstable.log
> 
> Nice catch, thanks !
> 
> One thing that puzzles me, is why didn't this pop up earlier. collectd does
> *not* build-depend on libssl-dev. But according to the latest build log[1]
> libssl1.0-dev gets installed nevertheless (making this mistake in
> collectd's Makefile work by accident). This is not the case on the
> AWS-based builder.

Okay. Unmerged, back. Earlier net-snmp's -dev package pulled in
libssl-dev. This packages explicitly adds "-lssl -lcrypto" but does not
need to link against any of those libs, it simply needs to link against
-lesmtp for the email plugin. Therefore I unmerged the two bugs and am
attaching the patch which strips the hardcoded libs. The result builds.
Any testing and feedback is appreciated.

> Cheers,
> Marc

Sebastian
Author: Sebastian Andrzej Siewior 
Subject: Remove SSL libs from libs

The Makefile/Configure adds "-lssl -lcrypto" but does not depend libssl-dev
nor does it use any of its functions diretly.
Depending on those should not be needed unless for static compilation thus
removing them.

---
 configure.ac|2 +-
 src/Makefile.am |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/configure.ac
+++ b/configure.ac
@@ -3574,7 +3574,7 @@ then
 
 	if test "x$LIBNETAPP_LIBS" = "x"
 	then
-		LIBNETAPP_LIBS="$PTHREAD_LIBS -lxml -ladt -lssl -lm -lcrypto -lz"
+		LIBNETAPP_LIBS="$PTHREAD_LIBS -lxml -ladt -lm -lz"
 	fi
 	AC_MSG_NOTICE([netapp LIBS: $LIBNETAPP_LIBS])
 
--- a/src/Makefile.am
+++ b/src/Makefile.am
@@ -825,7 +825,7 @@ if BUILD_PLUGIN_NOTIFY_EMAIL
 pkglib_LTLIBRARIES += notify_email.la
 notify_email_la_SOURCES = notify_email.c
 notify_email_la_LDFLAGS = $(PLUGIN_LDFLAGS)
-notify_email_la_LIBADD = -lesmtp -lssl -lcrypto
+notify_email_la_LIBADD = -lesmtp
 endif
 
 if BUILD_PLUGIN_NOTIFY_NAGIOS


Bug#852884: libesmtp: diff for NMU version 1.0.6-4.2

2017-01-31 Thread Sebastian Andrzej Siewior
Control: tags 852884 + patch
Control: tags 852884 + pending

Dear maintainer,

I've prepared an NMU for libesmtp (versioned as 1.0.6-4.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.
The following patches build with this change:

- balsa_2.4.12-3_amd64
- cacti-spine_0.8.8h-3_amd64
- hplip_3.16.11+repack0-2_amd64
- pacemaker_1.1.16-1_amd64
- syslog-ng_3.8.1-9_amd64

collectd_5.7.1-1_amd64 fails but it has the -lssl -lcrypto hardcoded and
I am going to supply a patch in #852924.

Regards.
diff -Nru libesmtp-1.0.6/debian/changelog libesmtp-1.0.6/debian/changelog
--- libesmtp-1.0.6/debian/changelog	2016-11-18 23:28:19.0 +0100
+++ libesmtp-1.0.6/debian/changelog	2017-01-31 23:51:33.0 +0100
@@ -1,3 +1,10 @@
+libesmtp (1.0.6-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop "-lssl -lcrypto" from exported libs flags (Closes: #852884).
+
+ -- Sebastian Andrzej Siewior   Tue, 31 Jan 2017 23:51:33 +0100
+
 libesmtp (1.0.6-4.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru libesmtp-1.0.6/debian/patches/remove_ssl_libs_from_libs.patch libesmtp-1.0.6/debian/patches/remove_ssl_libs_from_libs.patch
--- libesmtp-1.0.6/debian/patches/remove_ssl_libs_from_libs.patch	1970-01-01 01:00:00.0 +0100
+++ libesmtp-1.0.6/debian/patches/remove_ssl_libs_from_libs.patch	2017-01-31 23:51:33.0 +0100
@@ -0,0 +1,24 @@
+Author: Sebastian Andrzej Siewior 
+Subject: Remove SSL libs from libs
+
+The config script returns "-lssl -lcrypto" but does not depend libssl-dev.
+Depending on those should not be needed unless for static compilation thus
+removing them.
+
+BTS: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852884
+
+---
+ libesmtp-config.in |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/libesmtp-config.in
 b/libesmtp-config.in
+@@ -69,7 +69,7 @@ while test $# -gt 0; do
+	;;
+ 
+ --libs)
+-   	echo @PTHREAD_LDFLAGS@ -L@libdir@ -lesmtp @LIBS@ @PTHREAD_LIBS@
++   	echo @PTHREAD_LDFLAGS@ -L@libdir@ -lesmtp @PTHREAD_LIBS@
+	;;
+ 
+ --plugindir)
diff -Nru libesmtp-1.0.6/debian/patches/series libesmtp-1.0.6/debian/patches/series
--- libesmtp-1.0.6/debian/patches/series	2016-11-18 22:37:22.0 +0100
+++ libesmtp-1.0.6/debian/patches/series	2017-01-31 23:46:39.0 +0100
@@ -1,3 +1,4 @@
 headers-c
 sys-types-h
 openssl
+remove_ssl_libs_from_libs.patch


Bug#853776: Please provide deb.debian.org as an option

2017-01-31 Thread James Clarke
Control: clone -1 -2
Control: reassign -2 mirrors
Control: retitle -2 Please add deb.debian.org to Mirrors.masterlist
Control: block -1 by -2

On 31 Jan 2017, at 23:19, Cyril Brulebois  wrote:
> James Clarke  (2017-01-31):
>> Package: choose-mirror
>> Version: 2.74
>> Severity: wishlist
>> 
>> As the title says; as far as I can tell, deb.debian.org is still not
>> provided as an option during installation; instead, you have to enter it
>> manually.  Please add it alongside httpredir.
> 
> We sync the Mirrors.masterlist file from mirrors:
>  
> https://anonscm.debian.org/viewvc/webwml/webwml/english/mirror/Mirrors.masterlist?revision=HEAD
> 
> so please get it added there (clone/reassign/block if you like), and let
> us know once that's done so that we reupload choose-mirror.

Done (assuming I didn't mess up my control commands); thanks.

James



Bug#853776: Please provide deb.debian.org as an option

2017-01-31 Thread Cyril Brulebois
Hi,

James Clarke  (2017-01-31):
> Package: choose-mirror
> Version: 2.74
> Severity: wishlist
> 
> As the title says; as far as I can tell, deb.debian.org is still not
> provided as an option during installation; instead, you have to enter it
> manually.  Please add it alongside httpredir.

We sync the Mirrors.masterlist file from mirrors:
  
https://anonscm.debian.org/viewvc/webwml/webwml/english/mirror/Mirrors.masterlist?revision=HEAD

so please get it added there (clone/reassign/block if you like), and let
us know once that's done so that we reupload choose-mirror.


KiBi.


signature.asc
Description: Digital signature


Bug#853277: os-prober: triggers hang on default install with unencrypted LVM

2017-01-31 Thread Cyril Brulebois
Control: tag -1 patch pending

Hi,

Cyril Brulebois  (2017-01-31):
> When picking plain LVM (not encrypted), os-prober 1.73 hangs right after
> having printed this to syslog, with slight variations:
> | 50mount-tests: debug: creating device mapper device 
> /dev/mapper/osprober-linux-sda3 [Steve]
> | 50mount-tests: debug: creating device mapper device 
> /dev/mapper/osprober-linux-vda5 [Cyril]
> 
> The issue seems to be the dmsetup create call (with -r and the partition
> name) getting stuck in the kernel on the dm_ctl_ioctl call, possibly
> because we're trying to play with something that's mounted already?
> 
> Looking at commits touching dmsetup stuff, I went back to the first one
> between 1.71 and 1.72:
> | commit 8a8f565b43fd126e97b2c390bd81868c6653cf2c
> | Author: Ivo De Decker 
> | Date:   Sat Jul 13 21:15:41 2013 +0200
> | 
> | using read-only device mapper entry
> 
> and using a version built from it is sufficient to reproduce the hang.

Since that's basically the first time I'm touching os-prober, I first
went for special-casing the partition holding the root filesystem, and
tested an installation from a custom CD image successfully. Branch on
alioth: kibi-vs-lvm; and patches:
  
https://anonscm.debian.org/cgit/d-i/os-prober.git/commit/?id=16eae6151b713e4db2836b81e7958902544a5ecd
  
https://anonscm.debian.org/cgit/d-i/os-prober.git/commit/?id=d70f8416d3555a772666e105d13589416e6e5c0e

I wasn't too happy about it since there's a os-prober-udeb and lsblk
isn't available in a debian-installer context (it's available in /target
so it works properly for the use cases I had been testing).

Ivo joined the party and proposed a different approach: excluding
LVM2_member partitions (since they're physical volumes), and I liked
this approach a lot more.

Tests are looking fine so I went for it for 1.74.

Thinking about other use cases, Ivo noted that we might want to exclude
something else for which there's no codepath: linux_raid_member. But I
think I'll leave that for a later revision of this package, and try to
resume the D-I Stretch RC 2 release process with os-prober 1.74. The
linux_raid_member thing can be filed as a separate bug report (feel free
to; I'll be doing more testing).


KiBi.


signature.asc
Description: Digital signature


Bug#853179: libgraphite2-dev: the -dev package is missing the .a library for static linkage

2017-01-31 Thread M. Dietrich

Quotation from Rene Engelhard at Januar 30, 2017 15:55:

Not every upstream ships static libraries per default. So it
is with graphite2.


my assumption was that every -dev package provides it. sorry for
that.


And I am not going to "invent" it and patch around in the
cmake (brrr...)


agree. please close the report. thank you for your efforts on
that.

M. Dietrich


pgp1j_om_z6K7.pgp
Description: PGP signature


Bug#852267: upgrading mariadb-server-10.0 to mariadb-server-10.1 removed it instead of upgrading

2017-01-31 Thread Jean-Marc
Wed, 1 Feb 2017 00:18:18 +0200
Otto Kekäläinen  écrivait :

> Thank you very much Jean-Marc for helping with testing!

I helped with great pleasure.

> 
> Can you please also try running apt-get purge mysql-* and see if it removes
> the remnants cleanly? But not too cleanly, mysqld binary or /var/lib/mysql
> used by mariadb-10.1 should not get deleted by the mysql purge (one user
> reported he suffered such a case).

So, after the dist-upgrade + autoremove --purge, I listed remaining packages 
containing mysql:
$ dpkg --list | grep mysql
ii  default-mysql-client1.0.2   all  
MySQL database client binaries (metapackage)
ii  default-mysql-server1.0.2   all  
MySQL database server binaries and system database setup (metapackage)
ii  libdbd-mysql-perl   4.041-1 amd64
Perl5 database interface to the MariaDB/MySQL database
ii  mysql-common5.8+1.0.2   all  
MySQL database common files, e.g. /etc/mysql/my.cnf
rc  mysql-server-5.55.5.54-0+deb8u1 amd64
MySQL database server binaries and system database setup

So, mysql-common 5.8+1.0.2 is still installed and mysql-server-5.5 is removed 
but Config files remain on the machine.

And I simulated the purge you described:
$ apt-get purge --simulate mysql-*
[...]
The following packages were automatically installed and are no longer required:
  galera-3 libaio1 libdbi-perl libjemalloc1 libreadline5 libterm-readkey-perl 
rsync socat
Use 'apt autoremove' to remove them.
The following packages will be REMOVED:
  default-mysql-client* default-mysql-server* libdbd-mysql-perl* 
libmariadbclient18* mariadb-client-10.1* mariadb-client-core-10.1* 
mariadb-common*
  mariadb-server-10.1* mariadb-server-core-10.1* mysql-common* mysql-server-5.5*
0 upgraded, 0 newly installed, 11 to remove and 0 not upgraded.
Purg default-mysql-client [1.0.2]
Purg default-mysql-server [1.0.2]
Purg libdbd-mysql-perl [4.041-1]
Purg libmariadbclient18 [10.1.21-5]
Purg mariadb-server-10.1 [10.1.21-5]
Purg mariadb-client-10.1 [10.1.21-5]
Purg mariadb-client-core-10.1 [10.1.21-5]
Purg mariadb-server-core-10.1 [10.1.21-5]
Purg mariadb-common [10.1.21-5]
Purg mysql-common [5.8+1.0.2]
Purg mysql-server-5.5

Apparently, it is too cleanly.

:-)

I think it comes from the dependency between mysql-common and mariadb:
$ apt rdepends mysql-common 
mysql-common
Reverse Depends:
  PreDepends: mysql-server-5.5 (>= 5.5.54-0+deb8u1)
  Depends: mariadb-common (>= 5.6.25)
  Depends: libmariadbclient18

So, I think you can purge mysql-server-5.5 without any problem but not 
mysql-common:
$ apt purge --simulate mysql-server-5.5
[...]
The following packages will be REMOVED:
  mysql-server-5.5*
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Purg mysql-server-5.5


For your info, there is the files from mysql-server-5.5 remain on my VM:
$ dpkg --listfiles mysql-server-5.5
/etc
/etc/logrotate.d
/etc/logcheck
/etc/logcheck/ignore.d.paranoid
/etc/logcheck/ignore.d.paranoid/mysql-server-5_5
/etc/logcheck/ignore.d.server
/etc/logcheck/ignore.d.server/mysql-server-5_5
/etc/logcheck/ignore.d.workstation
/etc/logcheck/ignore.d.workstation/mysql-server-5_5
/etc/init.d
/etc/apparmor.d
/etc/mysql
/etc/mysql/conf.d
/etc/mysql/conf.d/mysqld_safe_syslog.cnf

I checked the /var/log/apt/history.log and mysql-server-5.5 was removed during 
the dist-upgrade.

And this process does not purge config files.

I do not know if it is really usefull to keep them.

Regards,

Jean-Marc 


pgplvJ49Tz1oV.pgp
Description: PGP signature


Bug#824670: ITP: dnsdiag -- DNS Diagnostics and Performance Measurement Tools

2017-01-31 Thread Antoine Beaupré
On 2017-01-20 13:41:49, Antoine Beaupré wrote:
> On 2017-01-20 16:23:02, Ana C. Custura wrote:
>> Hi Antoine, 
>>
>> Many thanks for the review, it is greatly appreciated.
>
> Alright, that looks all good to me. The only concern that remains is
> that I just noticed a 1.5.1 release on PyPI that is not on github - i
> wonder if we should be shipping that instead...
>
> I filed a bug upstream to try to get them to clarify that:
>
> https://github.com/farrokhi/dnsdiag/issues/33
>
> That would affect where we point the watch file, among other things.

I went ahead and just uploaded 1.4.0 as is so we get a slot in the NEW
queue already.

Congratulations! :)

A.

-- 
Use for yourself little but give to others much.
   - Albert Einstein



Bug#849932: libindicate: FTBFS (Fields cannot have void type)

2017-01-31 Thread Gilles Filippini
On Mon, 02 Jan 2017 12:01:41 + Santiago Vila  wrote:
> Package: src:libindicate
> Version: 0.6.92-3
> Severity: serious
> 
> Dear maintainer:
> 
> I tried to build this package in stretch with "dpkg-buildpackage -A"
> (which is what the "Arch: all" autobuilder would do to build it)
> but it failed:
> 
> 
> [...]
>  debian/rules build-indep
> CDBS WARNING:simple-patchsys.mk is deprecated since 0.4.85 - please use 
> source format 3.0 (quilt) instead
> test -x debian/rules
> mkdir -p "build"
> CDBS WARNING:DEB_DH_BUILDDEB_ARGS is deprecated since 0.4.85
> mkdir -p debian/stamp-makefile-build debian/stamp-makefile-install
> mkdir -p debian/stamp-makefile-check
> mkdir -p debian/stamp-autotools
> /usr/bin/make -f debian/rules reverse-config
> make[1]: Entering directory '/<>'
> CDBS WARNING:simple-patchsys.mk is deprecated since 0.4.85 - please use 
> source format 3.0 (quilt) instead
> set -e;
> if test -e debian/autoreconf.before; then \
> 
> [... snipped ...]
> 
> && touch generated-stamp
> Name: propertydata Type: GVariant*  in callback 
> indicate_listener_get_property_variant_cb
> Name: value Type: GVariant**  in callback 
> indicate_server_get_indicator_property_group_slot_t
> rettype: GVariant* in method GetPropertyVariant in type Indicate.Indicator
> Name: value Type: GVariant* in indicate_indicator_set_property_variant  in 
> method SetPropertyVariant in type Indicate.Indicator
> Name: menu Type: DbusmenuServer* in indicate_server_set_menu  in method 
> SetMenu in type Indicate.Server
> Name: propertydata Type: GVariant*  in callback GetPropertyVariantCallback
> Defaulting GetPropertyTimeCallback param to 'call' scope in method 
> Listener.GetPropertyTime
> Defaulting GetPropertyIntCallback param to 'call' scope in method 
> Listener.GetPropertyInt
> Defaulting GetPropertyCallback param to 'call' scope in method 
> Listener.GetProperty
> Defaulting GetPropertyBoolCallback param to 'call' scope in method 
> Listener.GetPropertyBool
> Defaulting GetCountCallback param to 'call' scope in method 
> ListenerServer.GetCount
> Defaulting GetDesktopCallback param to 'call' scope in method 
> ListenerServer.GetDesktop
> Defaulting GetTypeCallback param to 'call' scope in method 
> ListenerServer.GetGType
> Defaulting GetMenuCallback param to 'call' scope in method 
> ListenerServer.GetMenu
> Defaulting GetIconThemeCallback param to 'call' scope in method 
> ListenerServer.GetIconTheme
> 
> Generation Summary:
>   Enums: 1  Structs: 0  Boxed: 0  Opaques: 2  Interfaces: 0  Objects: 3  
> Callbacks: 18
>   Properties: 0  Signals: 2  Methods: 54  Constructors: 3  Throttled: 5
> Total Nodes: 88
> 
> /usr/bin/mono-csc  
> -keyfile:/<>/./bindings/mono/indicate/indicate.snk 
> -nowarn:0169,0612,0618 -unsafe -out:indicate-sharp.dll -target:library 
> -r:/usr/lib/pkgconfig/../../lib/cli/pango-sharp-2.0/pango-sharp.dll 
> -r:/usr/lib/pkgconfig/../../lib/cli/atk-sharp-2.0/atk-sharp.dll 
> -r:/usr/lib/pkgconfig/../../lib/cli/gdk-sharp-2.0/gdk-sharp.dll 
> -r:/usr/lib/pkgconfig/../../lib/cli/gtk-sharp-2.0/gtk-sharp.dll 
> -r:/usr/lib/pkgconfig/../../lib/cli/glib-sharp-2.0/glib-sharp.dll 
> ./generated/*.cs AssemblyInfo.cs
> ./generated/ListenerServer.cs(62,10): error CS0670: Fields cannot have void 
> type
> ./generated/ListenerServer.cs(62,28): error CS1547: Keyword `void' cannot be 
> used in this context
> Compilation failed: 2 error(s), 0 warnings
> Makefile:854: recipe for target 'indicate-sharp.dll' failed
> make[6]: *** [indicate-sharp.dll] Error 1
> make[6]: Leaving directory 
> '/<>/build/gtk2/bindings/mono/indicate'
> Makefile:546: recipe for target 'all-recursive' failed
> make[5]: *** [all-recursive] Error 1
> make[5]: Leaving directory 
> '/<>/build/gtk2/bindings/mono/indicate'

This is caused by gtk-sharp2 2.12.40 generating this line in file 
ListenerServer.cs:
static void _gtype = new void 
(indicate_listener_server_get_type(listener == null ? IntPtr.Zero : 
listener.Handle, server == null ? IntPtr.Zero : server.Handle, 
cb_wrapper.NativeDelegate, IntPtr.Zero));

This line doesn't appear when building against the previous gtk-sharp2 release 
from snapshot.d.o (2.12.10). According to [1] it works with gtk-sharp2 2.12.29 
as well. A bisect between releases 2.12.29 and 2.12.40 of gtk-sharp2 might give 
something.

[1] https://github.com/chenxiaolong/Unity-for-Arch/issues/243

Thanks,

_g.



signature.asc
Description: OpenPGP digital signature


Bug#853795: dpkg: Unable to disable .buildinfo generation

2017-01-31 Thread Alexander Wirt
Package: dpkg
Version: 1.18.21
Severity: normal

Hi, 

Ubuntu ppa's (launchpad) do not support .buildinfo files and reject
them:

Rejected: Unable to identify file icinga2_2.6.1-1~ppa1~trusty1_source.buildinfo
  (admin) in changes.
  Further error processing not possible because of a critical previous
  error.

Please make it possible to disable .buildinfo generation or inclusion in
changes files. 

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

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

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-8.1
ii  libc62.24-9
ii  liblzma5 5.2.2-1.2
ii  libselinux1  2.6-3
ii  tar  1.29b-1.1
ii  zlib1g   1:1.2.8.dfsg-5

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.4~beta4
pn  debsig-verify  

-- no debconf information



Bug#511094: 848789

2017-01-31 Thread Quang Đặng



Bug#707903: drgeo: Migrate to guile-2.0?

2017-01-31 Thread Petter Reinholdtsen
[Stephen Kitt]
> I agree it's sad... Upstream have switched to Pharo, so there won't be
> any Guile 2.0 port from there! (And bootstrapping Pharo
> seems... rather difficult.)

Aha.

Is there a WNPP request for Pharo?  I was unable to find one.

-- 
Happy hacking
Petter Reinholdtsen



Bug#853097: Bug 853097

2017-01-31 Thread Francesco Poli
On Tue, 31 Jan 2017 09:06:54 +0100 Andreas Bilke wrote:

> > First off, I wonder how they can support the loop option for
> >   
> > \href{run:mymovie.avi?loop}{\includegraphics[width=0.5\textwidth]{figs/mymovie_first_frame}}
> > then...
> 
> Because we get the full uri (in this case `mymovie.avi?loop`)
> via the poppler api and we can parse it as we like.
> 
> In constrast, if you use the multimedia package, it will add a movie
> annotation (instead of a link annotation in the previous example) to the
> pdf. And with the glib API we can not get enought information from this
> movie annotation.

Andreas,
thanks for clarifying this. It makes perfectly sense (shame on me for
not understanding it in the first place!).


As far as the feature request for poppler-glib is concerned, it seems
to me that the implementation is already on the to do list of poppler
library developers [1]:

[...]
| * glib frontend:
| - Sound/Movie actions support
[...]

[1] https://cgit.freedesktop.org/poppler/poppler/tree/TODO

Or am I misinterpreting this to do list entry?

Maybe they just need some more motivation to implement it sooner, rather
than later: I would strongly encourage you to file the feature request!
Perhaps you will even manage to help them in getting this feature
implemented...


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


pgpht52A_um2j.pgp
Description: PGP signature


Bug#852267: upgrading mariadb-server-10.0 to mariadb-server-10.1 removed it instead of upgrading

2017-01-31 Thread Jean-Marc
Hi everybody,

I found time to test a dist-upgrade scenario starting from a brand new Jessie 
and upgrading to Stretch
upgrading from mysql-5.5 to mariadb-10.1 (not exactly the one I got because I 
upgraded from mariadb-10.0 to 10.1)

And everything went fine, mariadb-server-10.1 replaced mysql-server-5.5 without 
any problem.

So, I think the bug can be closed.

Regards,

Jean-Marc 


pgp1yw5J26BBT.pgp
Description: PGP signature


Bug#853794: gcc-defaults-ports: Missing packages for powerpcspe

2017-01-31 Thread John Paul Adrian Glaubitz
Source: gcc-defaults-ports
Version: 4:6.3.0-1
Severity: normal
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi!

Although current versions of the gcc package have been building without
issues on powerpcspe, we're currently missing this architecture in
gcc-defaults-ports meaning that packages like gcc-powerpc-linux-gnuspe.

However, having these packages is important so powerpcspe can be
enabled in build-essential as cross-build-essential-powerpcspe so
that we're able to cross-build packages for powerpcspe.

I have looked into gcc-defaults-ports and figured that after applying
the changes from the attached patch, running debian/rules control, I
was able to rebuild gcc-defaults-ports with the default gcc packages
for powerpcspe enabled.

Thanks,
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
--- gcc-defaults-ports-1.165/debian/rules   2017-01-21 19:07:52.0 
+0100
+++ gcc-defaults-ports-1.165/debian/rules   2017-01-21 19:11:34.0 
+0100
@@ -312,7 +312,7 @@
 
 go_archs = alpha amd64 arm64 armel armhf i386 ia64 m68k \
mips mips64 mips64el mipsel \
-   powerpc ppc64 ppc64el s390 s390x sparc sparc64 x32
+   powerpc powerpcspe ppc64 ppc64el s390 s390x sparc sparc64 x32
 
 go_multilib_archs = $(filter $(go_archs), $(filter-out armel armhf, 
$(multilib_archs)))
 
@@ -337,6 +337,7 @@
 HOST_ARCHS_mips64 = amd64 i386 x32
 HOST_ARCHS_mips64el = amd64 i386 x32
 HOST_ARCHS_powerpc = amd64 i386 x32 ppc64el
+HOST_ARCHS_powerpcspe = amd64 i386 x32 ppc64el
 HOST_ARCHS_ppc64 = amd64 i386 x32
 HOST_ARCHS_ppc64el = amd64 i386 x32 ppc64
 HOST_ARCHS_s390x = amd64 i386 x32
@@ -348,9 +349,8 @@
   CROSS_ARCHS  ?= s390x ppc64el arm64 armhf armel \
$(if $(filter $(vendor), Ubuntu),, mips mipsel mips64el)
 else
-  CROSS_ARCHS  ?= alpha hppa m68k mips64 powerpc ppc64 sh4 sparc64 \
+  CROSS_ARCHS  ?= alpha hppa m68k mips64 powerpc powerpcspe ppc64 sh4 sparc64 \
$(if $(filter $(vendor), Ubuntu), mips mipsel mips64el)
-  # powerpcspe, outdated, ftbfs
 endif
 with_cross  = yes



Bug#853793: dpkg: ABI mismatch detector is too strict on armel/armhf

2017-01-31 Thread James Cowgill
Package: dpkg
Version: 1.18.21
Severity: serious
X-Debbugs-CC: debian-...@lists.debian.org

Hi,

[Disclaimer: I'm not an ARM porter and I don't really know much about
the ARM psABI]

The new ABI mismatch detector seems to be a bit too strict on armel and
armhf. The detector forces the ELF_FLAG_ARM_HARD_FLOAT and
ELF_FLAG_ARM_SOFT_FLOAT flags to be equal on both the library and its
user but checking ABI comparability doesn't seem that simple.

For example, on armel linking against libgsm.so currently gives this:

$ dpkg-shlibdeps -v -e../a.out -Ttest
dpkg-shlibdeps: debug: >> Scanning ../a.out (for Depends field)
dpkg-shlibdeps: debug: Skipping lib /usr/lib/arm-linux-gnueabi/libgsm.so.1, 
libabi=0x010100280500 != objabi=0x0101002805000200
dpkg-shlibdeps: error: cannot find library libgsm.so.1 needed by ../a.out (ELF 
format: 'elf32-littlearm' abi: '0101002805000200'; RPATH: '')
dpkg-shlibdeps: debug: Library libc.so.6 found in 
/lib/arm-linux-gnueabi/libc.so.6
dpkg-shlibdeps: debug: Using symbols file 
/var/lib/dpkg/info/libc6:armel.symbols for libc.so.6
dpkg-shlibdeps: warning: binaries to analyze should already be installed in 
their package's directory
dpkg-shlibdeps: error: cannot continue due to the error above
Note: libraries are not searched in other binary packages that do not have any 
shlibs or symbols file.
To help dpkg-shlibdeps find private libraries, you might need to use -l.

Here libgsm.so has neither HARD or SOFT flags set. Also, asking gcc to
generate a library which does not link against libc (this is used by
sonames2elf in some packages) causes both flags to be set (maybe
because it's compatible with both?).

This was first seen with wine:
https://buildd.debian.org/status/fetch.php?pkg=wine=armhf=1.8.6-4=1485847439=0
https://buildd.debian.org/status/fetch.php?pkg=wine=armel=1.8.6-4=1485847712=0

But there seem to be some other recent build failures relating to this
as well.

Thanks,
James



signature.asc
Description: OpenPGP digital signature


Bug#853153: It can't start by a segmentation fault

2017-01-31 Thread Steven Chamberlain
Michel Dänzer wrote:
> Looks like this happens because SMI_ScreenInit calls xf86HandleColormaps
> before xf86CrtcScreenInit, but xserver >= 1.19 requires the opposite order.

Aha, thank you!

I don't have any LynxEM+ hardware to test with until next week, but I've
attached a patch for xserver-xorg-video-siliconmotion, if Jonny would
like to try rebuilding with this perhaps.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/src/smi_driver.c b/src/smi_driver.c
index 8949cae..5023e63 100644
--- a/src/smi_driver.c
+++ b/src/smi_driver.c
@@ -1787,6 +1787,9 @@ SMI_ScreenInit(SCREEN_INIT_ARGS_DECL)
 		   "Hardware cursor initialization failed\n");
 }
 
+if(!xf86CrtcScreenInit(pScreen))
+	LEAVE(FALSE);
+
 /* Initialise default colormap */
 if (!miCreateDefColormap(pScreen))
 	LEAVE(FALSE);
@@ -1810,9 +1813,6 @@ SMI_ScreenInit(SCREEN_INIT_ARGS_DECL)
 
 SMI_InitVideo(pScreen);
 
-if(!xf86CrtcScreenInit(pScreen))
-	LEAVE(FALSE);
-
 /* Report any unused options (only for the first generation) */
 if (serverGeneration == 1) {
 	xf86ShowUnusedOptions(pScrn->scrnIndex, pScrn->options);


signature.asc
Description: Digital signature


Bug#853792: res_rtp_asterisk.c: Unable to allocate RTP socket: Address family not supported by protocol

2017-01-31 Thread Grzegorz Ojrzanowski
Package: asterisk
Version: 1:13.13.1~dfsg-2
Severity: important
Tags: upstream

After upgrading asterisk (1:13.12.2~dfsg-2 => 1:13.13.1~dfsg-2) I wasn't
able to make calls anymore, the message displayed by Linphone was
'Not acceptable here' and the following error was logged on asterisk host:

[2017-02-01 08:26:01] WARNING[1600] res_rtp_asterisk.c: Unable to allocate RTP 
socket: Address family not supported by protocol
[2017-02-01 08:26:01] WARNING[1600] res_rtp_asterisk.c: Failed to create a new 
socket for RTP instance '0x7fcea4049f30'
[2017-02-01 08:26:01] ERROR[1600] res_pjsip_sdp_rtp.c: Unable to create RTP 
instance using RTP engine 'asterisk'

Because I have IPv6 disabled (in /etc/defaults/grub using:
GRUB_CMDLINE_LINUX="ipv6.disable=1") this was my first suspect which
google soon confirmed.

A bug was introduced in Asterisk 13.13.0 which was reported in
https://issues.asterisk.org/jira/browse/ASTERISK-26617
and the fix will be included in next (13.13.2) asterisk release.

Until then, IPv6 needs to be enabled or Asterisk version 13.12.x used
instead


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

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

Versions of packages asterisk depends on:
ii  adduser   3.115
ii  asterisk-config   1:13.13.1~dfsg-2
ii  asterisk-core-sounds-en [asterisk-prompt-en]  1.4.27-1
ii  asterisk-core-sounds-en-gsm   1.4.27-1
ii  asterisk-modules  1:13.13.1~dfsg-2
ii  init-system-helpers   1.47
ii  libbsd0   0.8.3-1
ii  libc6 2.24-8
ii  libcap2   1:2.25-1
ii  libedit2  3.1-20160903-3
ii  libgcc1   1:6.3.0-5
ii  libjansson4   2.9-1
ii  libncurses5   6.0+20161126-1
ii  libpopt0  1.16-10
ii  libsqlite3-0  3.16.2-1
ii  libssl1.1 1.1.0c-2
ii  libstdc++66.3.0-5
ii  libsystemd0   232-14
ii  libtinfo5 6.0+20161126-1
ii  liburiparser1 0.8.4-1
ii  libuuid1  2.29-1
ii  libxml2   2.9.4+dfsg1-2.1
ii  libxslt1.11.1.29-2
ii  lsb-base  9.20161125

Versions of packages asterisk recommends:
ii  asterisk-moh-opsound-gsm 2.03-1
ii  asterisk-voicemail [asterisk-voicemail-storage]  1:13.13.1~dfsg-2
ii  sox  14.4.1-5+b1

Versions of packages asterisk suggests:
pn  asterisk-dahdi   
pn  asterisk-dev 
pn  asterisk-doc 
pn  asterisk-ooh323  
pn  asterisk-opus
pn  asterisk-vpb 

-- no debconf information



Bug#853790: ITP: golang-github-aanand-compose-file -- Parser for the Docker compose file format version 3

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-aanand-compose-file
  Version : 0.0~git20161122.0.a3e5876-1
  Upstream Author : Aanand Prasad
* URL : https://github.com/aanand/compose-file
* License : Apache-2.0
  Programming Lang: Go
  Description : Parser for the Docker compose file format version 3

 This library implements a parser for the Docker compose file format.
 Docker Compose is a tool for defining and running multi-container
 Docker applications. Applications can then be created and started
 using a single command.



signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#853789: ITP: golang-github-azure-go-ansiterm -- Go package for ANSI terminal emulation in Windows

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-azure-go-ansiterm
  Version : 0.0~git20160622.0.fa152c5-1
  Upstream Author : John Starks, Gabriel Hartmann
* URL : https://github.com/Azure/go-ansiterm
* License : Expat
  Programming Lang: Go
  Description : Go package for ANSI terminal emulation in Windows

 This package is a cross-platform ANSI terminal emulation library. It
 reads a stream of Ansi characters and produces the appropriate
 function calls. The results of the function calls are platform
 dependent.



signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#851513: Build failing

2017-01-31 Thread Arnoud Dekker
I can confirm that packages built manually from 
https://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/zfs.git and 
https://anonscm.debian.org/gitweb/?p=pkg-zfsonlinux/spl.git , which 
include fixes for this bug (thanks Aron!), seem to resolve this issue.




Bug#852751: Why not fix buggy encfs behavior?

2017-01-31 Thread Francesco Namuri

On 31/01/2017 19:43, .. ink .. wrote:

Greetings,i am a current maintainer of a project called
"SiriKali"[1][4] and it is also affected[2] by this bug in encfs.

encfs upstream has said that this "new" behavior of encfs is a bug
that needs to be fixed[3]. Why not fix this
buggy encfs behavior and let cryptkeeper among other front ends to
encfs continue to work as expected?

This bug is not in cryptkeeper,its in encfs and continuing with this
buggy behavior of encfs will break a lot more
projects than SiriKali and cryptkeeper and will cause encfs in debian
to behave differently from everybody else when
upstream release a new version that does not have this behavior.

I think cryptkeeper should be left alone and focus be redirected to
the change in encfs behavior that upstream now
disagrees with that started all this.

[1] https://mhogomchungu.github.io/sirikali/
[2] 
https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276288921
[3] 
https://github.com/tomm/cryptkeeper/issues/23#issuecomment-276304206

[4] https://packages.debian.org/sid/sirikali


Hello,
thanks for the comment.

Maybe a better solution could be to check output of encfs before piping 
anything,
or maybe, we can do a mount result check to see if all worked fine; but 
we can't
send "p" command trusting that encfs is waiting for a choice between "p" 
and "x".


This is my humble opinion.

Cheers,
Francesco



Bug#853788: ITP: golang-github-docker-goamz -- Enable Go programs to interact with Amazon Web Services

2017-01-31 Thread Potter, Tim
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org
Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: golang-github-docker-goamz
  Version : 0.0~git20160206.0.f0a21f5-1
  Upstream Author : Docker
* URL : https://github.com/docker/goamz
* License : LGPL-3.0
  Programming Lang: Go
  Description : Enable Go programs to interact with Amazon Web Services

 The goamz package enables Go programs to interact with the Amazon Web
 Services including AWS, EC2, S3, ELB, SQS and SNS.
 .
 It was developed within Canonical as part of an experiment related to
 using the Go language with the juju project, but is now a set of
 generally adopted and maintained Go packages that talk to several
 Amazon Web Services.
 .
 This package is a fork of the GOAMZ version developed within
 Canonical with additional functionality and services, including
 DynamoDB.



signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#852267: upgrading mariadb-server-10.0 to mariadb-server-10.1 removed it instead of upgrading

2017-01-31 Thread Otto Kekäläinen
Thank you very much Jean-Marc for helping with testing!

Can you please also try running apt-get purge mysql-* and see if it removes
the remnants cleanly? But not too cleanly, mysqld binary or /var/lib/mysql
used by mariadb-10.1 should not get deleted by the mysql purge (one user
reported he suffered such a case).


Bug#825864: ITP: sedutil -- Tool to use functionality of Self Encrypting Drives (SED) that comply with the TCG OPAL 2.00 standard

2017-01-31 Thread Stingley, Mark
Gentlemen;

I was wondering if there is any progress toward packaging sedutil in Debian?

Much thanks.

Mark Stingley 
Network Security Architect  

UTHealth | The University of Texas Health Science Center at Houston
7000 Fannin St | Suite M50-F | Houston, Texas 77030   
https://inside.uth.edu/itsecurity/sac/phishing-awareness/



Bug#853787: wxmaxima: loadfile: failed to load /usr/share/wxMaxima/wxmathml.lisp

2017-01-31 Thread Damian Zaręba
Package: wxmaxima
Version: 16.12.2-1
Severity: important

Dear Maintainer,
I wanted to use a wxMaxima package,but I'm unable to,because It don't
want to load wxmathml.lisp file,which performs all of the calculations
in wxMaxima.it just appears in main window of the program.

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

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

Versions of packages wxmaxima depends on:
ii  ibus-gtk31.5.14-2
ii  imagemagick  8:6.9.7.4+dfsg-1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-1
ii  libc62.24-9
ii  libgcc1  1:6.3.0-5
ii  libstdc++6   6.3.0-5
ii  libwxbase3.0-0v5 3.0.2+dfsg-2
ii  libwxgtk3.0-0v5  3.0.2+dfsg-2
ii  maxima   5.38.1-8
ii  maxima-doc   5.38.1-8

Versions of packages wxmaxima recommends:
ii  fonts-jsmath 0.090709+0-3
ii  texlive-latex-extra  2016.20170123-1

wxmaxima suggests no packages.

-- no debconf information




signature.asc
Description: OpenPGP digital signature


Bug#2297: Very Urgent

2017-01-31 Thread Tuula Tähkäaho


Regards from me to you i have a promising proposal for you write me through 
this mail:: mrswangju...@gmail.com


Yours Faithfully,

Mrs. Wang.




































Bug#853786: ITP: golang-github-cbroglie-mapstructure -- Go library for decoding generic map values into native Go structures

2017-01-31 Thread Potter, Tim
Package: wnpp
Severity: wishlist
Owner: Tim Potter 
X-Debbugs-CC: debian-de...@lists.debian.org, 
pkg-go-maintain...@lists.alioth.debian.org

* Package name: golang-github-cbroglie-mapstructure
  Version : 0.0~git20150405.0.25325b4-1
  Upstream Author : Chris Broglie
* URL : https://github.com/cbroglie/mapstructure
* License : Expat
  Programming Lang: Go
  Description : Go library for decoding generic map values into native 
structures

 mapstructure is a Go library for decoding generic map values to structures and
 vice versa, while providing helpful error handling.
 .
 This library is most useful when decoding values from some data stream (JSON,
 Gob, etc.) where you don't quite know the structure of the underlying data
 until you read a part of it. You can therefore read a map[string]interface{}
 and use this library to decode it into the proper underlying native Go
 structure.
 .
 This package is a fork of the golang-github-mitchellh-mapstructure
 package to more elegantly support decoding data with an unknown
 structure by using the runtime reflection features of the Go
 language.




signature.asc
Description: Message signed with OpenPGP using GPGMail


Bug#853726: tunnelx: Dead link in man page

2017-01-31 Thread Wookey
On 2017-01-31 11:09 +, Toby Speight wrote:
> Package: tunnelx
> Version: 20160713-3
> Severity: normal
> 
> Sorry, no patch this time, because I couldn't find a fix!
> 
> The manual page says:
> 
> /
> |  This manual page was written for the Debian distribution because the
> |  original program does not have a manual page.  Instead, it has
> |  excellent documentation online at
> |  http://www.freesteel.co.uk/wiki/index.php/Tunnel .  Please refer to
> |  that.
> \
> 
> Sadly, the "excellent documentation" is no longer available from that
> URI - I get a HTTP 404 response.  There seems to be a cached copy at
>  http://expo.survex.com/expofiles/tunnelwiki/www.freesteel.co.uk/wiki/index.php/Tunnel.html
>  > -

yes. I put it there after the original disappeared. I'll fix the URL.

> although I'm having trouble accessing that as it's not providing a
> HTTPS version properly.

It doesn't need to. Just because https is a good idea on those
new-fangled sites that require you to be logged in so you can be
properly tracked like a good little internet-user, there is no reason
to provide the expo website as https. So tell your browser to piss off
and let you browse as you see fit :-) We have many more important
things to fix first.

> Perhaps there's a case (given a sufficient supply of Round Tuits) for
> creating a 'tunnelx-doc' package with a snapshot of that documentation
> (if the licensing permits)?

Yes. That would probably be a good idea. I used to package the therion
wiki in a -doc package. I'll leave this bug open as a wishlist reminder.
 
Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature


Bug#853756: debian-installer: no cryptsetup available in rescue mode

2017-01-31 Thread Cyril Brulebois
Toni Mueller  (2017-01-31):
> > Toni Mueller  (2017-01-31):
> > > I downloaded the testing installer using Jigdo from here:
> > > http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo
> > > because the Jessie installer in 8.7.1 would not work for me (#750586).
> > 
> > Well that isn't D-I Stretch RC 1 then. That one lives under:
> >   http://cdimage.debian.org/cdimage/stretch_di_rc1/
> 
> I'm confused - the testing CD does not use the latest d-i?

See description here:
  http://cdimage.debian.org/cdimage/weekly-builds/

“latest d-i” is ambiguous. It can be the latest d-i build (see
https://d-i.debian.org/daily-images/daily-build-overview.html), or the
latest d-i release (D-I Stretch RC 1 right now).

The image you're trying to use uses the former definition of “latest
d-i”, as explained on the link above.

> > Anyway, trying this image:
> > f234f4aa708bdb226c0f412e85c37541c654526e  
> > downloads/debian-testing-amd64-netinst.iso
> 
> I could set up an encrypted partition in the installation procedure,
> just not access it during the rescue operation.
> 
> $ sha1sum debian-testing-amd64-netinst.iso 
> 1d50301e6eccba6b116253f323cf397cfccd88fe  debian-testing-amd64-netinst.iso
> 
> Your image is different. I downloaded "mine" this morning, btw.

I downloaded the iso directly instead of going through the jigdo dance,
because it's oh so simpler, but maybe I hit a different iso, which would
be slightly surprising… Anyway, I'm busy trying to find a workaround for
RC 2 right now, so I'll avoid spending more time on this.

> I used the manual method, because I wanted to have a RAID1 underneath.

OK, fair. I know for a fact this works with Debian 8 since I've used
this many time for Debian/Linux teaching sessions, with RAID1 and
encrypted LVM on top of it; purposefully breaking the encrypted LVM
(removing cryptsetup) then repairing from rescue mode.

> > Given my test results above, we'll need those…
> 
> Ok. I'll see what I can do.

Thanks already!


KiBi.


signature.asc
Description: Digital signature


Bug#811576: tpm-utils 1.3.9 fixes this issue

2017-01-31 Thread Philipp Kern
On 01/31/2017 09:55 PM, Adrian Bunk wrote:
> Which tarball are you using, and do you have the build dependency 
> libopencryptoki-dev installed?

Yay conditional compilation. I didn't forward port the packaging yet.

> I am using the one from
>   https://sourceforge.net/projects/trousers/files/tpm-tools/1.3.9/
> 
> and the error I get is:
> 
> ...
> gcc -DHAVE_CONFIG_H -I. -I../..  -I../../include -D_LINUX -Wdate-time 
> -D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/tmp/tpm-tools-1.3.9=. 
> -fstack-protector-strong -Wformat -Werror=format-security -m64 -Wall 
> -Wreturn-type -Wsign-compare -c -o data_import.o data_import.c
> data_import.c: In function 'readX509Cert':
> data_import.c:375:26: error: dereferencing pointer to incomplete type 
> 'EVP_PKEY {aka struct evp_pkey_st}'
>   if ( EVP_PKEY_type( pKey->type ) != EVP_PKEY_RSA ) {
>   ^~
> In file included from /usr/include/openssl/asn1.h:24:0,
>  from /usr/include/openssl/rsa.h:16,
>  from data_import.c:34:
> data_import.c: In function 'createRsaPubKeyObject':
> data_import.c:694:34: error: dereferencing pointer to incomplete type 'RSA 
> {aka struct rsa_st}'
>   int  nLen = BN_num_bytes( a_pRsa->n );
>   ^
> Makefile:524: recipe for target 'data_import.o' failed
> make[4]: *** [data_import.o] Error 1
> make[4]: Leaving directory '/tmp/tpm-tools-1.3.9/src/data_mgmt'
> Makefile:401: recipe for target 'all-recursive' failed
> make[3]: *** [all-recursive] Error 1

I suppose all this needs is the following patch. I'm a little unhappy
about the naming of the intermediate variables, but I suppose as long as
it does the trick:

> Index: tpm-tools/src/data_mgmt/data_import.c
> ===
> --- tpm-tools.orig/src/data_mgmt/data_import.c
> +++ tpm-tools/src/data_mgmt/data_import.c
> @@ -372,7 +372,7 @@ readX509Cert( const char  *a_pszFile,
>   goto out;
>   }
>  
> - if ( EVP_PKEY_type( pKey->type ) != EVP_PKEY_RSA ) {
> + if ( EVP_PKEY_base_id( pKey ) != EVP_PKEY_RSA ) {
>   logError( TOKEN_RSA_KEY_ERROR );
>  
>   X509_free( pX509 );
> @@ -691,8 +691,13 @@ createRsaPubKeyObject( RSA
>  
>   int  rc = -1;
>  
> - int  nLen = BN_num_bytes( a_pRsa->n );
> - int  eLen = BN_num_bytes( a_pRsa->e );
> + const BIGNUM *bn;
> + const BIGNUM *be;
> +
> + RSA_get0_key( a_pRsa, , , NULL );
> +
> + int  nLen = BN_num_bytes( bn );
> + int  eLen = BN_num_bytes( be );
>  
>   CK_RV  rv;
>  
> @@ -732,8 +737,8 @@ createRsaPubKeyObject( RSA
>   }
>  
>   // Get binary representations of the RSA key information
> - BN_bn2bin( a_pRsa->n, n );
> - BN_bn2bin( a_pRsa->e, e );
> + BN_bn2bin( bn, n );
> + BN_bn2bin( be, e );
>  
>   // Create the RSA public key object
>   rv = createObject( a_hSession, tAttr, ulAttrCount, a_hObject );
> @@ -760,14 +765,27 @@ createRsaPrivKeyObject( RSA
>  
>   int  rc = -1;
>  
> - int  nLen = BN_num_bytes( a_pRsa->n );
> - int  eLen = BN_num_bytes( a_pRsa->e );
> - int  dLen = BN_num_bytes( a_pRsa->d );
> - int  pLen = BN_num_bytes( a_pRsa->p );
> - int  qLen = BN_num_bytes( a_pRsa->q );
> - int  dmp1Len = BN_num_bytes( a_pRsa->dmp1 );
> - int  dmq1Len = BN_num_bytes( a_pRsa->dmq1 );
> - int  iqmpLen = BN_num_bytes( a_pRsa->iqmp );
> + const BIGNUM *bn;
> + const BIGNUM *be;
> + const BIGNUM *bd;
> + const BIGNUM *bp;
> + const BIGNUM *bq;
> + const BIGNUM *bdmp1;
> + const BIGNUM *bdmq1;
> + const BIGNUM *biqmp;
> +
> + RSA_get0_key( a_pRsa, , , );
> + RSA_get0_factors( a_pRsa, , );
> + RSA_get0_crt_params( a_pRsa, , ,  );
> +
> + int  nLen = BN_num_bytes( bn );
> + int  eLen = BN_num_bytes( be );
> + int  dLen = BN_num_bytes( bd );
> + int  pLen = BN_num_bytes( bp );
> + int  qLen = BN_num_bytes( bq );
> + int  dmp1Len = BN_num_bytes( bdmp1 );
> + int  dmq1Len = BN_num_bytes( bdmq1 );
> + int  iqmpLen = BN_num_bytes( biqmp );
>  
>   CK_RV  rv;
>  
> @@ -821,14 +839,14 @@ createRsaPrivKeyObject( RSA
>   }
>  
>   // Get binary representations of the RSA key information
> - BN_bn2bin( a_pRsa->n, n );
> - BN_bn2bin( a_pRsa->e, e );
> - BN_bn2bin( a_pRsa->d, d );
> - BN_bn2bin( a_pRsa->p, p );
> - BN_bn2bin( a_pRsa->q, q );
> - BN_bn2bin( a_pRsa->dmp1, dmp1 );
> - BN_bn2bin( a_pRsa->dmq1, dmq1 );
> - BN_bn2bin( a_pRsa->iqmp, iqmp );
> + BN_bn2bin( bn, n );
> + BN_bn2bin( be, e );
> + BN_bn2bin( bd, d );
> + BN_bn2bin( bp, p );
> + BN_bn2bin( bq, q );
> + BN_bn2bin( bdmp1, dmp1 );
> + BN_bn2bin( bdmq1, dmq1 );
> + BN_bn2bin( biqmp, iqmp );
>  
>   // Create the RSA private key object
>   rv = createObject( a_hSession, tAttr, ulAttrCount, a_hObject );

There's also no test suite, which is unhelpful. Hence 

Bug#853785: RM: tightvnc [mips mips64el mipsel] -- ROM; FTBFS

2017-01-31 Thread Ola Lundqvist
Package: ftp.debian.org

I'd like you to remove two binary packages xtightvncviewer and
tightvncserver from testing as it prevents tightvnc from entering
testing.

Best regards

// Ola

-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---



Bug#815212: lilypond: Changing the output paper size is "hard"

2017-01-31 Thread Anthony Fok
Control: tags -1 - wontfix

Hi Karl,

Thank you for your follow up.

On Tue, Jan 31, 2017 at 10:22 AM, Karl O. Pinc  wrote:
> On Mon, 30 Jan 2017 22:29:46 -0700 Anthony Fok  wrote:
>> Rather, the officially documented method is outlined in
>> http://lilypond.org/doc/v2.18/Documentation/notation/paper-size-and-automatic-scaling,
>> i.e., by setting the paper size in the .ly file itself:
>>
>> \paper {
>>   #(set-paper-size "letter")
>> }
>
> Ok.  I probably went to the man page first, to wind up using the
> command line option.
>
>> I use Frescobaldi (a great GUI editor for LilyPond) myself, and its
>> Score Wizard feature automatically generates needed skeleton LilyPond
>> code for you, together with the set-paper-size command above.
>>
>> I highly recommend that you do the same instead, i.e. using
>> Frescobaldi (sudo apt-get install frescobaldi) and setting the paper
>> size inside your .ly file.
>
> Thanks.  But I'm not interested in a GUI.

Sorry for my poor choice of words.  Frescobaldi is actually more a
text editor with the added benefits of creating the overall structure
of the .ly file, things like \header, \paper, lyrics, \score section
etc. for you.  After that, the end user still needs to go to the
appropriate sections and enter notes like "c2 d4 e | f2 g" manually.
It is none of those GUI entering-notes-by-clicking-with-the-mouse
things which I am not used to myself either.

Of course, LilyPond is self-sufficient on its own, and you definitely
don't need Frescobaldi per se.

But yes, it is very handy for both newbies and professional music
engravers like Frescobaldi's author who organized and coordinated the
production of a professionally-printed Dutch hymnal called "Liedboek"
a few years ago.  It is a tremendous time-saver and learning aid, and
that is why I highly recommended that you at least give it a try.

>> Changing the paper size on-the-fly using -dpaper-size is unreliable
>> IMHO. You yourself may remember to add the "-dpaper-size letter"
>> option, but others who receive the same .ly file with are not obliged
>> to do so, and would get unexpected results such as extra page, ugly
>> line-breaks, etc. due to unexpectedly different page width and page
>> height.
>
> Good advice.  Makes sense to me that every lilypond input file
> contain a paper size specification.
>
> (Perhaps this should be a recommendation in the lilypond manual.)

It *is* in the manual (info page, HTML and PDF).  As a matter of fact,
it is the only documented method, so I guess that would count as a
recommendation?  :-)

Seriously though, I have gotten used to using on-line search engines,
and thankfully, a search on "LilyPond paper size" on Google or
DuckDuckGo.com gives me the correct LilyPond HTML documentation page
as its first result.

I find it easier than to search through the locally installed
documentation, actually.  :-)

>> The fact that LilyPond does not read /etc/papersize is by design, and
>> I think it is a good thing.  Ignoring user environment variations like
>> /etc/papersize helps ensure that the same .ly would produce the
>> exactly same result everywhere.
>
> This sounds laudable, but unrealistic.  I don't have any a4 paper,
> the default, and this is probably true for almost everybody in North
> America.
>
> My feeling is that if the author of the lilypond file did not
> explicitly specify a paper size then lilypond should be free
> to print on the paper available.  Even if it means
> that the result comes out looking different.  If the composer wants
> to ensure conformity in print output it's up to the composer
> to do so.  Otherwise, the composer should be allowed to distribute
> music to be printed on whatever paper the musician has available.

You have a good point there, but it is a design decision that both
LilyPond (default: A4) and TeX/LaTeX (default: US Letter) have made.

Another user has brought up the same issue some years ago.  Check out
the following conversations for an interesting read:


http://lilypond.1069038.n5.nabble.com/LC-PAPER-and-default-paper-size-td131547.html

> Speaking as a novice, I'd like to be able to typeset some music
> and print it with minimum effort.  It's bad enough having to figure
> out lilypond itself without having
> oh-my-!-now-I-have-to-deal-with-paper-size issues.

Haha, been there, done that.  (Oh yes, the learning pain.)

> If you're expecting everybody to use a GUI that takes care of paper
> size issues that's one thing, but it seems to me that the lilypond
> packaging should at least have some options available for non-GUI
> users.

No, it wasn't the GUI with preset template, it was that Google search
on "LilyPond paper size" or other creative searches to find helpful
documentation or forum posts and useful snippets.  Otherwise, how do
you think I would come up with the following "monstrosity" to be able
to change the "paper size" to fit 1280x720 (16:9 aspect ratio) for
screen projection?


Bug#853751: unbound: FTBFS[!linux]: missing getentropy implementations

2017-01-31 Thread Steven Chamberlain
Hi,

I forgot an important piece of the patch which is actually adding the
build-dependency:

--- a/debian/control
+++ b/debian/control
@@ -15,6 +15,7 @@ Build-Depends:
  dh-systemd ,
  dpkg-dev (>= 1.16.1~),
  flex,
+ libbsd-dev (>= 0.8.1~) [!linux-any],
  libevent-dev,
  libexpat1-dev,
  libfstrm-dev ,

0.8.1 was the first version to implement a modern arc4random (using
ChaCha20 cipher) and implement genentropy on kfreebsd and hurd.

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


signature.asc
Description: Digital signature


Bug#800588: [debian-mysql] Bug#800588: Upgrade from jessie

2017-01-31 Thread Otto Kekäläinen
Micah,

According to your logs, you had mysql-server 5.5.54-0+deb8u1 and then
upgraded to mysql-server 5.6.30-1. So your bug is about MySQL, not
about MariaDB. The libmariadbclient18 library you had installed does
not affect mysqld before or after in any way.

Indeed Bug#800588 is filed agains mysql-server, which is no longer in
Debian Stretch. For the time being I am trying to focus on Stretch
issues as it is close to freeze and release.



Bug#846099: ping

2017-01-31 Thread Jelmer Vernooij
Any news on this? There's a fair amount of (Russian) spam coming
in daily that's quite annoying.


signature.asc
Description: PGP signature


Bug#852346: kdenlive: crash on startup

2017-01-31 Thread Luca Boccassi
On Tue, 2017-01-31 at 21:56 +0100, Vincent Pinon wrote:
> Hello,
> 
> Actually this is Kdenlive bug 375094, fixed just after 16.12.1 release :(
> See Kdenlive revert commit 8a20fca86e9e2ce3d04b3e024b0752e19f9d8c8e
> (attached as patch)
> 
> Actually the following commit in 16.12 branch also fixes NVidia crash with 
> GPU effects:
> kdenlive commit 754b8eeed8c1a874a5535eb5136b02841a812180
> (attached too)
> 
> maybe worth to include in a 16.12.1-2 for stretch users, if not too late? 
> (16.12.2 won't come on time)
> 
> Cheers and thanks to all,
> 
> Vincent

Thanks for the analysis!

Patrick, are you happy for me to punt these bugs back to kdenlive then?

Kind regards,
Luca Boccassi


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


Bug#721600: Wrong priority

2017-01-31 Thread Marcin Owsiany
FWIW, a simple:
 sudo cp /lib/udev/rules.d/52-nut-usbups.rules
/etc/udev/rules.d/63-nut-usbups.rules
fixed this issue for me on a jessie system, with freshly installed
nut-server 2.7.2-4 (I never had nut-server installed on this system before).


Bug#853107: xapian-core: FTBFS under pbuilder with USENETWORK=no

2017-01-31 Thread Georg Faerber
Hi Olly,

> Daniel: What version of pbuilder are you using?  If it's more than a
> year old, then upgrading will probably fix this.  If not, then either
> that fix has regressed in pbuilder regression, or else something more
> complex is going on.

This is happening here [1] as well, which is a recent pbuilder version,
I guess. I'm wondering if this is a bug in pbuilder or a wrapper around.

Cheers,
Georg
(who debugged for some hours a similar problem over here [2]...)


[1] 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/xapian-core_1.4.3-1.rbuild.log
[2] 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/schleuder_3.0.1-1.rbuild.log


signature.asc
Description: Digital signature


Bug#845565: Bug#853066: gnupg-agent: opens dialog on the wrong computer.

2017-01-31 Thread Charles Plessy
Control: reassign 853066 pinentry-gnome3
Control: reassign 845565 pinentry-gnome3
Control: forcemerge 845565 853066 841909

Le Tue, Jan 31, 2017 at 03:38:23PM +0100, Vincent Lefevre a écrit :
> On 2017-01-31 22:57:07 +0900, Charles Plessy wrote:
> > Control: forcemerge -1 845565
> 
> Note that the bug was merged to itself. Do not use -1 when several
> bugs are mentioned in To/Cc. I think that both bugs 845565 and
> 853066 should be reassigned to pinentry-gnome3, *then* forcemerge'd
> with bug 841909.

Argh, sorry for the mess !

> > Do you think it might help to put the Debian GNOME maintainers in the
> > loop ?  Perhaps there is a GNOMEish way to ensure that the GNOME tools
> > are launched in GNOME context, and text tools are launched in text
> > context.
> 
> In my case, I do not use GNOME at all, but expect X11 tools in a X11
> context (e.g. pinentry-gtk-2). IMHO, either pinentry-gnome3 should
> detect the context and do the necessary fallback(s), or a pinentry
> wrapper should be preferred to the alternatives system: it would
> detect the context and launch the right pinentry-* program (with
> fallback when not installed).

Indeed, I think that pinentry-gnome3 should not be called in this
context.  For instance, from my SSH session, if I type `sudo apt install
foo`, my password is prompted in text mode in the SSH session, not as a
popup on a distant computer.  Similarly, if I type `exit`, then the SSH
session where I entered the command is ended; I do not get a popup on
the distant computer asking if I want to close the graphical session
instead.  I think that the gpg ~ gpg-agent ~ pinentry chain should to the
same: prompting the user at the location where the user ran the command,
as it used to do in Jessie.

I understand that this UI problem is quite far from what the Debian
GnuPG Maintainers are able to commit to solve, and that the freeze is
near.  So where is the best place to call for help ?  Perhaps
planet.debian.org ?

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan



Bug#853784: schleuder: accesses the internet during build

2017-01-31 Thread Chris Lamb
Source: schleuder
Version: 3.0.1-1
Severity: important
Justification: Policy 4.9
User: la...@debian.org
Usertags: network-access

Dear Maintainer,

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

   00:00:00.00 IP 1bda71ae498f.21600 > OpenWrt.lan.domain: 53623+ PTR? 
1.0.0.127.in-addr.arpa. (40)
   00:00:00.001484 IP OpenWrt.lan.domain > 1bda71ae498f.21600: 53623* 1/0/0 PTR 
localhost.lan. (67)
   00:00:00.001604 IP 1bda71ae498f.24754 > OpenWrt.lan.domain: 15484+ PTR? 
1.0.0.127.in-addr.arpa. (40)
   00:00:00.002947 IP OpenWrt.lan.domain > 1bda71ae498f.24754: 15484* 1/0/0 PTR 
localhost.lan. (67)
   00:00:01.289711 IP 1bda71ae498f.31343 > OpenWrt.lan.domain: 2272+ PTR? 
1.0.0.127.in-addr.arpa. (40)
   00:00:01.291147 IP OpenWrt.lan.domain > 1bda71ae498f.31343: 2272* 1/0/0 PTR 
localhost.lan. (67)
   00:00:06.308390 IP 1bda71ae498f.21600 > OpenWrt.lan.domain: 53623+ PTR? 
1.0.0.127.in-addr.arpa. (40)
   00:00:06.309862 IP OpenWrt.lan.domain > 1bda71ae498f.21600: 53623* 1/0/0 PTR 
localhost.lan. (67)
   00:00:06.309992 IP 1bda71ae498f.24754 > OpenWrt.lan.domain: 15484+ PTR? 
1.0.0.127.in-addr.arpa. (40)
   00:00:06.311301 IP OpenWrt.lan.domain > 1bda71ae498f.24754: 15484* 1/0/0 PTR 
localhost.lan. (67)

  [..]

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


Regards,

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


schleuder.3.0.1-1.unstable.amd64.log.txt.gz
Description: Binary data


Bug#853756: debian-installer: no cryptsetup available in rescue mode

2017-01-31 Thread Toni Mueller


Hi KiBi,

On Tue, Jan 31, 2017 at 09:20:53PM +0100, Cyril Brulebois wrote:
> Control: notfound -1 20170112
> Control: tag -1 moreinfo
> 
> Toni Mueller  (2017-01-31):
> > I downloaded the testing installer using Jigdo from here:
> > http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo
> > because the Jessie installer in 8.7.1 would not work for me (#750586).
> 
> Well that isn't D-I Stretch RC 1 then. That one lives under:
>   http://cdimage.debian.org/cdimage/stretch_di_rc1/

I'm confused - the testing CD does not use the latest d-i?

> > > Were you prompted with a passphrase for the detected LUKS partition?
> > When I tried to run the installer in the "rescue" mode, it did not
> > prompt me with anything, but when it said something like "partition
> > disks", it did not have any crypto entries. On the console, it was
> > complaining about two missing modules, one of which ended with _crypto.
> > 
> > I looked for cryptsetup, but could not find it.
> 
> cryptsetup is the component installed in /target (the installed system),
> not what d-i uses.
> 
> Anyway, trying this image:
> f234f4aa708bdb226c0f412e85c37541c654526e  
> downloads/debian-testing-amd64-netinst.iso

I could set up an encrypted partition in the installation procedure,
just not access it during the rescue operation.

$ sha1sum debian-testing-amd64-netinst.iso 
1d50301e6eccba6b116253f323cf397cfccd88fe  debian-testing-amd64-netinst.iso

Your image is different. I downloaded "mine" this morning, btw.

> with a VM installed with guided encrypted LVM, and starting graphical
> rescue mode, I'm getting prompted for a passphrase to unlock /dev/sda5
> as expected, so d-i seems to behave properly.

I used the manual method, because I wanted to have a RAID1 underneath.

> > > Syslog might be interesting (vt4, or /var/log/syslog from another vt).
> > 
> > :/
> > 
> > I am sorry, but currently I can't produce those logs.
> 
> Given my test results above, we'll need those…

Ok. I'll see what I can do.


Cheers,
--Toni++



Bug#853008: [debian-mysql] Bug#853008: Bug#853008: mysql-server-5.7: purge could delete mariadb-server files with inadequate warning

2017-01-31 Thread Lars Tangvald

- j...@debian.org wrote:

> On Mon, Jan 30, 2017 at 06:38:16PM +, Robie Basak wrote:
> > > So how about this, just a sketch at the moment rather than a full
> > > patch?
> > 
> > Your sketch seems good to me, assuming that "dpkg-query --search"
> is
> > permitted from maintainer scripts (I know there are some
> re-entrancy
> > problems with some particular types of dpkg-related invocations?)
> > [...]
> > 
> > I wondered this too. But without thinking it through in more
> detail,
> > it'd certainly be better than what we have now.
> 
> Please find attached a patch against the current
> mysql-5.7/debian/master branch on alioth.  I have also updated the
> github branch for mariadb-10.1 to address the same issue (the one
> with
> a pull request to otto/mariadb-10.1).
> 
> It's been tested for upgrades, clean install, remove and purge.
> 
> Best wishes,
> 
>Julian


Thanks!

I'll look it over and test a little myself.

--
Lars



Bug#827068: m2crypto: doesn't work together with OpenSSL 1.1 (API changes)

2017-01-31 Thread Sebastian Andrzej Siewior
On 2016-11-15 12:36:09 [+0100], Daniel Stender wrote:
> On Mon, 14 Nov 2016 19:52:31 +0100 Daniel Stender  
> wrote:
> > The diff doesn't work like that on the upstream code in the archive
> 
> ... the same is true for 0.25.1.
> 
> I'm on it.

Should I take 0.25.1 and cherry-pick the patches or B-D on openssl 1.0
for Stretch?

> DS
> 

Sebastian



Bug#811576: tpm-utils 1.3.9 fixes this issue

2017-01-31 Thread Adrian Bunk
On Tue, Jan 31, 2017 at 09:24:34PM +0100, Philipp Kern wrote:
> Hi,
> 
> On 01/31/2017 07:46 PM, Adrian Bunk wrote:
> > On Tue, Jan 31, 2017 at 04:02:53PM +0100, Philipp Kern wrote:
> >> so tpm-utils 1.3.9 fixes OpenSSL 1.1 compatibility
> > does 1.3.9 compile for you with OpenSSL 1.1?
> 
> 1.3.9 still has two issues with -Werror, but none with OpenSSL 1.1 AFAICS.
>...

Which tarball are you using, and do you have the build dependency 
libopencryptoki-dev installed?

I am using the one from
  https://sourceforge.net/projects/trousers/files/tpm-tools/1.3.9/

and the error I get is:

...
gcc -DHAVE_CONFIG_H -I. -I../..  -I../../include -D_LINUX -Wdate-time 
-D_FORTIFY_SOURCE=2  -g -O2 -fdebug-prefix-map=/tmp/tpm-tools-1.3.9=. 
-fstack-protector-strong -Wformat -Werror=format-security -m64 -Wall 
-Wreturn-type -Wsign-compare -c -o data_import.o data_import.c
data_import.c: In function 'readX509Cert':
data_import.c:375:26: error: dereferencing pointer to incomplete type 'EVP_PKEY 
{aka struct evp_pkey_st}'
  if ( EVP_PKEY_type( pKey->type ) != EVP_PKEY_RSA ) {
  ^~
In file included from /usr/include/openssl/asn1.h:24:0,
 from /usr/include/openssl/rsa.h:16,
 from data_import.c:34:
data_import.c: In function 'createRsaPubKeyObject':
data_import.c:694:34: error: dereferencing pointer to incomplete type 'RSA {aka 
struct rsa_st}'
  int  nLen = BN_num_bytes( a_pRsa->n );
  ^
Makefile:524: recipe for target 'data_import.o' failed
make[4]: *** [data_import.o] Error 1
make[4]: Leaving directory '/tmp/tpm-tools-1.3.9/src/data_mgmt'
Makefile:401: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
...

> Kind regards
> Philipp Kern

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed



Bug#852346: kdenlive: crash on startup

2017-01-31 Thread Vincent Pinon
Hello,

Actually this is Kdenlive bug 375094, fixed just after 16.12.1 release :(
See Kdenlive revert commit 8a20fca86e9e2ce3d04b3e024b0752e19f9d8c8e
(attached as patch)

Actually the following commit in 16.12 branch also fixes NVidia crash with GPU 
effects:
kdenlive commit 754b8eeed8c1a874a5535eb5136b02841a812180
(attached too)

maybe worth to include in a 16.12.1-2 for stretch users, if not too late? 
(16.12.2 won't come on time)

Cheers and thanks to all,

Vincent>From 8a20fca86e9e2ce3d04b3e024b0752e19f9d8c8e Mon Sep 17 00:00:00 2001
From: Jean-Baptiste Mardelle 
Date: Mon, 16 Jan 2017 20:06:00 +0100
Subject: [PATCH 1/9] Revert "Fix warning about QOffscreenSurface thread"
 Caused startup crash on NVidia cards CCBUG: 375094

This reverts commit 6675c4a509046aa3b57c60cbc3f31435e09c2df7.
---
 src/monitor/glwidget.cpp | 10 +++---
 src/monitor/glwidget.h   |  1 -
 2 files changed, 3 insertions(+), 8 deletions(-)

diff --git a/src/monitor/glwidget.cpp b/src/monitor/glwidget.cpp
index e4089e661..cd4f56add 100644
--- a/src/monitor/glwidget.cpp
+++ b/src/monitor/glwidget.cpp
@@ -109,7 +109,6 @@ GLWidget::GLWidget(int id, QObject *parent)
 mlt_properties_set_data(mlt_global_properties(), "glslManager", NULL, 0, NULL, NULL);
 emit gpuNotSupported();
 }
-connect(this, SIGNAL(sceneGraphInitialized()), SLOT(createOffscreen()));
 connect(this, SIGNAL(sceneGraphInitialized()), SLOT(initializeGL()), Qt::DirectConnection);
 connect(this, SIGNAL(beforeRendering()), SLOT(paintGL()), Qt::DirectConnection);
 }
@@ -143,17 +142,14 @@ void GLWidget::updateAudioForAnalysis()
 	m_frameRenderer->sendAudioForAnalysis = KdenliveSettings::monitor_audio();
 }
 
-void GLWidget::createOffscreen()
+void GLWidget::initializeGL()
 {
+if (m_isInitialized || !isVisible() || !openglContext()) return;
 if (!m_offscreenSurface.isValid()) {
 m_offscreenSurface.setFormat(openglContext()->format());
 m_offscreenSurface.create();
+openglContext()->makeCurrent(this);
 }
-}
-
-void GLWidget::initializeGL()
-{
-if (m_isInitialized || !isVisible() || !openglContext()) return;
 initializeOpenGLFunctions();
 qDebug() << "OpenGL vendor: " << QString::fromUtf8((const char*) glGetString(GL_VENDOR));
 qDebug() << "OpenGL renderer: " << QString::fromUtf8((const char*) glGetString(GL_RENDERER));
diff --git a/src/monitor/glwidget.h b/src/monitor/glwidget.h
index dc1e0e2f3..d12500a57 100644
--- a/src/monitor/glwidget.h
+++ b/src/monitor/glwidget.h
@@ -182,7 +182,6 @@ private slots:
 void updateTexture(GLuint yName, GLuint uName, GLuint vName);
 void paintGL();
 void onFrameDisplayed(const SharedFrame );
-void createOffscreen();
 
 protected:
 void resizeEvent(QResizeEvent* event);
-- 
2.11.0

>From 754b8eeed8c1a874a5535eb5136b02841a812180 Mon Sep 17 00:00:00 2001
From: Jean-Baptiste Mardelle 
Date: Fri, 20 Jan 2017 01:15:01 +0100
Subject: [PATCH 2/9] Fix NVIDIA crash with GPU accel (movit)

---
 src/main.cpp|  2 +-
 src/mltcontroller/producerqueue.cpp | 14 +-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/src/main.cpp b/src/main.cpp
index fc93963de..b081e056f 100644
--- a/src/main.cpp
+++ b/src/main.cpp
@@ -44,7 +44,7 @@ int main(int argc, char *argv[])
 // Force QDomDocument to use a deterministic XML attribute order
 extern Q_CORE_EXPORT QBasicAtomicInt qt_qhash_seed;
 qt_qhash_seed.store(0);
-
+QCoreApplication::setAttribute(Qt::AA_ShareOpenGLContexts, true);
 #if defined(Q_OS_UNIX) && !defined(Q_OS_MAC)
 QCoreApplication::setAttribute(Qt::AA_X11InitThreads);
 #endif
diff --git a/src/mltcontroller/producerqueue.cpp b/src/mltcontroller/producerqueue.cpp
index 07fd234d3..aa06cf6fb 100644
--- a/src/mltcontroller/producerqueue.cpp
+++ b/src/mltcontroller/producerqueue.cpp
@@ -299,7 +299,19 @@ void ProducerQueue::processFileProperties()
 } else if (service.contains(QStringLiteral("avformat"))) {
 Mlt::Profile *blankProfile = new Mlt::Profile();
 blankProfile->set_explicit(false);
-blankProfile->from_producer(*producer);
+if (KdenliveSettings::gpu_accel()) {
+Clip clp(*producer);
+Mlt::Producer *glProd = clp.softClone(ClipController::getPassPropertiesList());
+Mlt::Filter scaler(*m_binController->profile(), "swscale");
+Mlt::Filter converter(*m_binController->profile(), "avcolor_space");
+glProd->attach(scaler);
+glProd->attach(converter);
+blankProfile->from_producer(*glProd);
+delete glProd;
+}
+else {
+blankProfile->from_producer(*producer);
+}
 

Bug#853198: simple-cddd cannot handle reprepro home made d-i repository

2017-01-31 Thread Vagrant Cascadian
Control: tags 853198 wontfix

On 2017-01-30, Laurent COOPER wrote:
> I tried to use simple-cdd to build a set of CD with a customised 
> debian-installer
> I have a personnal debian repository with a custom debian installer. It's all 
> handled with reprepro
>
> The problem is about signature of the files
>
> In official repository, Release file has a hash for the SHA256 file in 
> main/debian-installer branche
>
> Reprepro does not handle this
...
> As reprepro does not handle control sums for main/installer , simple-cdd 
> failed with no clue.

I'd recommend using the custom_installer option, which specifies a path
to a custom built installer image, which skips the verification step for
the installer.

With "custom_installer=/path/to/dir", it should search for the installer
files at:

  /path/to/dir/$ARCH/ or /path/to/dir/installer-$ARCH/current/


> Should this verification be turned into a warning or at least be
> switchable in config or by command line option swicth?

I don't really like the idea of simple-cdd adding workarounds for
incomplete mirrors.

In general, simple-cdd is designed to work with the official debian
mirrors, and only add a small number of additional custom packages or
configurations.


live well,
  vagrant


signature.asc
Description: PGP signature


Bug#853744: cloud-init needs net-tools

2017-01-31 Thread Sam Hartman
> "Marco" == Marco d'Itri  writes:

Marco> On Jan 31, Sam Hartman  wrote:
>> Why?  I can understand "it would be nice if cloud-init used ip
>> instead", but you seem to have a preference stronger than that.
Marco> To save space on the images.

I think having it work is more important than space.
I think applying the patch and then opening a wishlist bug to use
iproute2 would be a good path forward.



Bug#853783: libsane-hpaio: Failed to open hpaio:/net/HP_Color_Laserjet_MFP_M277DW?ip=194.168.1.4: Error during device I/O

2017-01-31 Thread Svante Signell
Package: libsane-hpaio
Version: 3.16.11+repack0-2
Severity: important

Hello,

Upgrading libane-hpaio (and hplip*, etc) to 3.16.11+repack0-2 makes the scanner
non-functional. (The same applies to 3.16.10+repack0-1 and 3.16.9+repack0-2).
Even if awahi-daemon is running the message is:
Failed to open hpaio:/net/HP_Color_Laserjet_MFP_M277DW?ip=194.168.1.4: Error
during device I/O.

Searching for the printer works (as well as the printer itself):
scanimage -L
device `hpaio:/net/HP_Color_LaserJet_MFP_M277dw?ip=192.168.1.4' is a Hewlett-
Packard HP_Color_LaserJet_MFP_M277dw all-in-one

Installed driver is:
hp-color_laserjet_pro_mfp_m277-ps.ppd.gz downloaded from HP.

Previous working version is: 3.16.7-1

Printer/Scanner/Copier/Faxer: Network connected HP Color Laserjet Pro MFP M277dw
Tested software: scanimage, xscanimage, simple-scan



Bug#846002: blends-tasks must be priority:standard and not make a mess out of tasksel menu

2017-01-31 Thread Sam Hartman
> "Ole" == Ole Streicher  writes:

Ole> Hi Sam, Am 31.01.2017 um 16:26 schrieb Sam Hartman:
>> If you go back one meeting further, my interpretation is that the
>> consensus of the committee seems to be that ultimately this
>> decision belongs to the installer team.  That is, in this case, a
>> number of members on the TC seem to believe that the installer
>> team gets to decide whether/how the installer makes it easy to
>> install blends.  If they don't want to do that for stretch,
>> that's a decision within their pervue that we clearly don't have
>> the votes to override.

Ole> Hmm, IMO there are two things here: First, in our constitution,
Ole> the installer team has no specific granted rights, apart from
Ole> being maintainers of the relevant packages. This makes the
Ole> conflict primarily a conflict between developers having
Ole> different opinions about how to solve a certain problem. A
Ole> decision here falls under the rights granted to the Technical
Ole> Team by the Project leader.

I think you mean by the constitution.
I could see that argument.

Ole> And I would expect that a decision
Ole> would be made on some technical foundation.

A lot of people expect that.
A lot of what the TC does involves understanding how to balance
technical and non-technical factors.
It seems entirely appropriate for the TC to look at the technical issues
here and decide who should be making the decision rather than to make a
decision.

What I think several of us did is look at the technical details and
decide we believe that the installer team was the right set of people to
make this technical decision.

So, I think the TC will make its decisions on a technical foundation a
lot less frequently than you do.
That said, I do think an understanding of which technical factors are
important is something we need to do.

If there are things I can to to help you believe that we did consider
the points you think important I'd like to do that.  If you can think of
things I can do to help you gain confidence that we have heard you,
please let me know.

That said, I'm hoping you can respect me when I say that hearing you
does not mean agreeing with you--not even about what factors are
important in making a decision.

--Sam



Bug#828482: bug 828482 fix

2017-01-31 Thread Sebastian Andrzej Siewior
On 2016-10-27 08:56:23 [+0800], Di-Shi Sun wrote:
> osptoolkit/3.4.2-1.2 is out of date and osptoolkit/4.11.3+dfsg-1 has been
> released to replace it.

so what? 4.11.3+dfsg-1 is still affected by this problem.

> Regards,
> 
>  
> 
> Di-Shi Sun
> VoIP Routing, Accounting, Security

Sebastian



Bug#853285: ghc: Patch to add support for cross-compilation of GHC

2017-01-31 Thread John Paul Adrian Glaubitz
On 01/31/2017 08:17 PM, Helmut Grohne wrote:
> On Tue, Jan 31, 2017 at 09:20:46AM +0100, John Paul Adrian Glaubitz wrote:
>>   Setting "--target" allows enabling cross-compiling, adding
>>   --enable-unregisterised is important for architectures not
>>   having native code generation support. Disabling the documentation
>>   is required by GHC itself. Trying to build the documentation
>>   when cross-compiling causes an error message.
> 
> I'm not entirely sold on the idea that we cannot cross build haddock.
> What about using the haddock from the ghc:native package to build the
> documentation? But then maybe I understand too little of the
> requirements here.

Oh, I'm absolutely with you on this. The problem is just that GHC upstream
currently doesn't support building the documentation when cross-building
because of these lines in the main ghc.mk makefile:

ifneq "$(CrossCompiling) $(Stage1Only)" "NO NO"
$(error Can not build haddock docs when CrossCompiling or Stage1Only. \
  Set HADDOCK_DOCS=NO in your mk/build.mk file. \
  See Note [No stage2 packages when CrossCompiling or Stage1Only])
endif
endif

> In any case, disabling haddock should not be a thing that just happens
> for cross compilation. We want cross builds to be reproducible (when
> compared against native builds). So disabling haddock should be a
> concious choice (even if cross building without disabling haddock
> doesn't work). Also building ghc without haddock should produce a
> package that doesn't list haddock under Provides. This calls for a build
> profile. So I went ahead and split out this part of your patch into a
> patch that adds a pkg.ghc.nohaddock build profile.

I actually want the cross-built GHC package to match the natively built
package as closely as possible because I prefer it as an alternative to
building GHC on slower architectures. Building GHC on m68k can take
over 20 days since m68k also doesn't have a native code generator.

> I hope that this makes sense and that the resulting profile is useful
> for cross compiling ghc. Do you agree?

As long as the cross-built GHC package can be fully used on the target
system, I'm all for these changes. But, as I explained in my initial
report, the are still issues with ghc-pkg when trying to build haskell-text
that I haven't resolved yet.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#811576: tpm-utils 1.3.9 fixes this issue

2017-01-31 Thread Philipp Kern
Hi,

On 01/31/2017 07:46 PM, Adrian Bunk wrote:
> On Tue, Jan 31, 2017 at 04:02:53PM +0100, Philipp Kern wrote:
>> so tpm-utils 1.3.9 fixes OpenSSL 1.1 compatibility
> does 1.3.9 compile for you with OpenSSL 1.1?

1.3.9 still has two issues with -Werror, but none with OpenSSL 1.1 AFAICS.

Specifically it still needs this:

> Index: tpm-tools/src/tpm_mgmt/tpm_nvcommon.c
> ===
> --- tpm-tools.orig/src/tpm_mgmt/tpm_nvcommon.c
> +++ tpm-tools/src/tpm_mgmt/tpm_nvcommon.c
> @@ -164,8 +164,8 @@ int parseStringWithValues(const char *aA
>   return -1;
>   }
>  
> - if (!aArg[offset+numbytes] == '|' &&
> - !aArg[offset+numbytes] == 0) {
> + if (aArg[offset+numbytes] == '|' ||
> + aArg[offset+numbytes] == 0) {
>   logError(_("Illegal character following decimal 
> "
>  "number in %s\n"),
>aArg + offset);
> Index: tpm-tools/src/tpm_mgmt/tpm_present.c
> ===
> --- tpm-tools.orig/src/tpm_mgmt/tpm_present.c
> +++ tpm-tools/src/tpm_mgmt/tpm_present.c
> @@ -357,5 +357,5 @@ out_close:
>  out:
>  if (szTpmPasswd && !isWellKnown)
>   shredPasswd( szTpmPasswd );
> - return iRc;
> +return iRc;
>  }

I'd hold that -Werror is a problem in itself, but the comparison warning
was actually appreciated:

> tpm_nvcommon.c: In function ‘parseStringWithValues’:
> tpm_nvcommon.c:167:31: warning: comparison of constant ‘124’ with boolean 
> expression is always false [-Wbool-compare]
> if (!aArg[offset+numbytes] == '|' &&
>^~
> tpm_nvcommon.c:167:31: warning: logical not is only applied to the left hand 
> side of comparison [-Wlogical-not-parentheses]

So what happened is that the upstream maintainer only fixed one of the
two identical comparisons (the one for hexadecimals, not the one for
decimals).

With that I think we should be fine to upload this. It's quite late,
though, so it will need a little convincing of the Release Team.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature


Bug#850883: libapache2-mod-auth-cas: diff for NMU version 1.1-2.1

2017-01-31 Thread Sebastian Andrzej Siewior
Control: tags 850883 + patch

Dear maintainer,

I've prepared an NMU for libapache2-mod-auth-cas (versioned as 1.1-2.1). The 
diff
is attached to this message.

Regards.
Sebastian
diff -Nru libapache2-mod-auth-cas-1.1/debian/changelog libapache2-mod-auth-cas-1.1/debian/changelog
--- libapache2-mod-auth-cas-1.1/debian/changelog	2016-11-03 09:41:34.0 +0100
+++ libapache2-mod-auth-cas-1.1/debian/changelog	2017-01-31 21:23:57.0 +0100
@@ -1,3 +1,10 @@
+libapache2-mod-auth-cas (1.1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Build depend open OpenSSL 1.0 for Stretch (Closes: #850883).
+
+ -- Sebastian Andrzej Siewior   Tue, 31 Jan 2017 21:23:57 +0100
+
 libapache2-mod-auth-cas (1.1-2) unstable; urgency=medium
 
   * Update configure for OpenSSL 1.1 (closes: #828378).
diff -Nru libapache2-mod-auth-cas-1.1/debian/control libapache2-mod-auth-cas-1.1/debian/control
--- libapache2-mod-auth-cas-1.1/debian/control	2016-11-03 09:41:29.0 +0100
+++ libapache2-mod-auth-cas-1.1/debian/control	2017-01-31 21:23:18.0 +0100
@@ -3,7 +3,7 @@
 Priority: extra
 Maintainer: CAS packaging team 
 Uploaders: Michele Baldessari , Thijs Kinkhorst 
-Build-Depends: debhelper (>= 9), dh-apache2, apache2-dev, libssl-dev, libcurl4-openssl-dev, libpcre3-dev, dpkg-dev (>= 1.16.1)
+Build-Depends: debhelper (>= 9), dh-apache2, apache2-dev, libssl1.0-dev | libssl-dev (<< 1.1), libcurl4-openssl-dev, libpcre3-dev, dpkg-dev (>= 1.16.1)
 Standards-Version: 3.9.8
 Vcs-Svn: https://anonscm.debian.org/pkg-cas/libapache2-mod-auth-cas/svn-buildpackage/trunk/
 Vcs-Browser: https://anonscm.debian.org/viewsvn/pkg-cas/libapache2-mod-auth-cas/svn-buildpackage/trunk/


Bug#853756: debian-installer: no cryptsetup available in rescue mode

2017-01-31 Thread Cyril Brulebois
Control: notfound -1 20170112
Control: tag -1 moreinfo

Hi,

Toni Mueller <supp...@oeko.net> (2017-01-31):
> I downloaded the testing installer using Jigdo from here:
> http://cdimage.debian.org/cdimage/weekly-builds/amd64/jigdo-cd/debian-testing-amd64-netinst.jigdo
> because the Jessie installer in 8.7.1 would not work for me (#750586).

Well that isn't D-I Stretch RC 1 then. That one lives under:
  http://cdimage.debian.org/cdimage/stretch_di_rc1/

> > Were you prompted with a passphrase for the detected LUKS partition?
> 
> When I tried to run the installer in the "rescue" mode, it did not
> prompt me with anything, but when it said something like "partition
> disks", it did not have any crypto entries. On the console, it was
> complaining about two missing modules, one of which ended with _crypto.
> 
> I looked for cryptsetup, but could not find it.

cryptsetup is the component installed in /target (the installed system),
not what d-i uses.

Anyway, trying this image:
f234f4aa708bdb226c0f412e85c37541c654526e  
downloads/debian-testing-amd64-netinst.iso

(According to syslog: Jan 31 20:15:20 cdrom-detect: Detected CD 'Debian 
GNU/Linux testing "Stretch" - Official Snapshot amd64 NETINST Binary-1 
20170131-16:00')

with a VM installed with guided encrypted LVM, and starting graphical
rescue mode, I'm getting prompted for a passphrase to unlock /dev/sda5
as expected, so d-i seems to behave properly.

> > Syslog might be interesting (vt4, or /var/log/syslog from another vt).
> 
> :/
> 
> I am sorry, but currently I can't produce those logs.

Given my test results above, we'll need those…


KiBi.


signature.asc
Description: Digital signature


Bug#828449: net-snmp will stay with 1.0 for stretch

2017-01-31 Thread Sebastian Andrzej Siewior
control: retitle -1 net-snmp: Please migrate to openssl1.1 in buster
control: unblock 827061 with -1

Dmitry, in [0] you said, that this bug affects zabbix. If it is still
the case, please explain how otherwise please remove the `affects' tag.

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828449;msg=25

Sebastian



Bug#848813: blacs-mpi: FTBFS: make[3]: *** No rule to make target '/usr/lib/openmpi/include/mpif.h', needed by 'mpif.h'. Stop.

2017-01-31 Thread Gilles Filippini
Control: tags -1 + patch

On Sun, 1 Jan 2017 17:38:52 +0500 Andrey Rahmatullin 
wrote:
> On Mon, Dec 19, 2016 at 10:26:42PM +0100, Lucas Nussbaum wrote:
> > > make[3]: *** No rule to make target '/usr/lib/openmpi/include/mpif.h', 
> > > needed by 'mpif.h'.  Stop.
> The /usr/lib/openmpi path is hardcoded in
> debian/blacs-mpi-implementations.patch  and should be replaced with the
> correct triplet path.

Indeed.
The attached patch does the trick.

Thanks,

_g.
diff -u blacs-mpi-1.1/debian/blacs-mpi-implementations.patch blacs-mpi-1.1/debian/blacs-mpi-implementations.patch
--- blacs-mpi-1.1/debian/blacs-mpi-implementations.patch
+++ blacs-mpi-1.1/debian/blacs-mpi-implementations.patch
@@ -73,7 +73,7 @@
 +endif
 +ifeq ($(MPI),openmpi)
 +# for compilation with openmpi:
-+   MPIdir = /usr/lib/openmpi
++   MPIdir = /usr/lib/$(DEB_HOST_MULTIARCH)/openmpi
 +   MPILIBdir = $(MPIdir)/lib
 +   MPIINCdir = $(MPIdir)/include
 +   MPILIB = $$(pkg-config mpi-fort --libs)


signature.asc
Description: OpenPGP digital signature


Bug#850882: lastpass-cli: diff for NMU version 1.0.0-1.2

2017-01-31 Thread Sebastian Andrzej Siewior
Control: tags 850882 + patch

Dear maintainer,

I've prepared an NMU for lastpass-cli (versioned as 1.0.0-1.2). The diff
is attached to this message.

Regards.
Sebastian
diff -Nru lastpass-cli-1.0.0/debian/changelog lastpass-cli-1.0.0/debian/changelog
--- lastpass-cli-1.0.0/debian/changelog	2016-12-06 21:10:47.0 +0100
+++ lastpass-cli-1.0.0/debian/changelog	2017-01-31 21:05:57.0 +0100
@@ -1,3 +1,10 @@
+lastpass-cli (1.0.0-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Switch to openssl 1.0 (Closes: #850882).
+
+ -- Sebastian Andrzej Siewior   Tue, 31 Jan 2017 21:05:57 +0100
+
 lastpass-cli (1.0.0-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru lastpass-cli-1.0.0/debian/control lastpass-cli-1.0.0/debian/control
--- lastpass-cli-1.0.0/debian/control	2016-10-20 16:17:08.0 +0200
+++ lastpass-cli-1.0.0/debian/control	2017-01-31 21:05:24.0 +0100
@@ -2,7 +2,7 @@
 Section: utils
 Priority: optional
 Maintainer: Troy Heber 
-Build-Depends: debhelper (>= 9), quilt (>= 0.47), libssl-dev, libxml2-dev, libcurl4-openssl-dev, asciidoc, xsltproc, docbook-xsl
+Build-Depends: debhelper (>= 9), quilt (>= 0.47), libssl1.0-dev | libssl-dev (<< 1.1), libxml2-dev, libcurl4-openssl-dev, asciidoc, xsltproc, docbook-xsl
 Standards-Version: 3.9.8.0
 
 Package: lastpass-cli


  1   2   3   4   >