Bug#855544: gitsome: embedded code copy of xonsh in source package + file conflict on installation: trying to overwrite '/usr/bin/xonsh', which is also in package xonsh 0.5.5+dfsg-1

[Axel Beckert]

Hi,

SZ Lin (林上智) wrote:
> Since xonsh version in gitsome (0.2.2) varies greatly from the version of
> SID (0.5.5+dfsg-1), I think it might have potential compatibility issues by
> using the SID version.

Questions are:

* Is it necessary that it varies, i.e. that the old version of xonsh
  is used?
* Is the version used by gitsome heavily patched compared to the
  original version 0.2.2?

If the answer is "no" both times, it should at least be tested if it
works with the version from Sid, too.

> Perhaps it is more proper to rename the bundled copies of the xonsh
> executable rather than build-depend on it.

I'd then rather move it to a directory outside the path, i.e. to
/usr/lib/gitsome/xonsh or so.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE

Bug#850459: [Pkg-xfce-devel] Bug#850459: xfce4-goodies: Please consider incliding xfce4-calculator-plugin

[Yves-Alexis Perez]

control: reassign -1 wnpp
control: retitle -1 RFP: xfce4-calculator-plugin

On Fri, Jan 06, 2017 at 06:12:29PM +, Tim Wootton wrote:
> Package: xfce4-goodies
> Version: 4.12.3
> Severity: wishlist
> 
> Dear Maintainer,
> 
> please consider packaging xfce4-calculator-plugin and including it as
> a suggests 

I have no idea what this package is about, but honestly we're not enough
maintainers to include new random packages. Fee free to join the team
and provide assistance if you really need this package.

Regards,
-- 
Yves-Alexis Perez


signature.asc
Description: PGP signature

Bug#855341: unblock: mini-httpd/1.23-1.2

[Sebastian Andrzej Siewior]

On 2017-02-18 12:22:06 [+0100], Emilio Pozuelo Monfort wrote:
> Go ahead, and ping us when it has been accepted and built.

it is built everywhere.

> Thanks,
> Emilio

Sebastian

Bug#855553: git-pbuilder: Add a quiet/silent option to disable "set -x"

[Guido Günther]

On Sun, Feb 19, 2017 at 08:56:41PM -0500, Frédéric Brière wrote:
> Package: git-buildpackage
> Version: 0.8.12.2
> Severity: wishlist
> 
> git-pbuilder unconditionally issues a "set -x" before invoking the
> builder; since this outputs to stderr, this makes it rather difficult to
> perform a silent run (such as in a cron job) without discarding any
> error message.

That's a good point. I'd rather print the the command on stdout but then
we'd need to make sure we're not subject to any quoting so it's 1:1
identical, the joys of shell.
Let's disable the output by defualt and trigger it by
GIT_PBUILDER_DEBUG. This allows us to have more verbose output in the
future. Fix pushed to git.
Cheers,
 -- Guido

Bug#855437: closed by Norbert Preining <prein...@debian.org> (Bug#855437: fixed in texlive-extra 2016.20170123-4)

[Adrian Immanuel Kieß]

Dear Norbert,

thank you for fixing this bug.

Yours sincerely,

Adrian Immanuel Kieß

-- 
With many greetings from Leipzig, Germany.
Adrian Immanuel Kieß 

Gothaer Straße 34
D-04155 Leipzig

Administrator & programmer
Unix ∧ Perl ∧ Java ∧ LaTeX

 — < adrian@kiess.engineer >
 — http://www.kiess.engineer # Homepage of Adrian Immanuel Kieß
 — http://www.totaleueberwachung.de # Site for people who hear voices
 — http://www.outanekka.org # Outanekka online image gallery

--SYSTEM--
echo "Your fortune cookie: " && /usr/games/fortune -c -s
> (wisdom) % Don't make a big deal out of everything; just deal with everything.

echo "IMMANUELK.NET uptime: " && /usr/bin/uptime
> 08:26:37 up 48 min, 10 users, load average: 2.08, 2.12, 2.16


On Mon, 2017-02-20 at 06:45 +, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the texlive-latex-extra package:
> 
> #855437: g-brief2.cls: Error on compile with LyX
> 
> It has been closed by Norbert Preining .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Norbert Preining
>  by
> replying to this email.
> 
> 

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

Bug#855143: unblock: wpa/2.5-2+v2.4-4stretch1

[Andrew Shadura]

On 20/02/17 00:08, Ivo De Decker wrote:
> We really, really want to avoid going through t-p-u if at all possible. In
> this case, there doesn't seem to be a real issue with doing a revert in
> unstable. There isn't really any point in having a version in unstable that
> isn't meant for testing. The 2.6 version can go to experimental.

It was meant for testing, but unfortunately the issues with it turned
out to be more serious than I thought, which is why I decided to stick
with an older version for now.

> As for the confusion, this can be avoided by using an epoch instead
> of the version you're using now (but that is really your call).

It was already in experimental, and it went to unstable at the point
when it seemed it had enough of testing, but it turned out it didn't. As
for the epoch, I'm not sure it's a good idea, as the package already
uses it in a bit inconsistent way (for one of the binary packages only).

On the other hand, all fixes I'm including are backports of fixes
included in the version currently in unstable.

> Please upload a targeted fix to unstable.

-- 
Cheers,
  Andrew

Bug#855555: unblock: hdmi2usb-fx2-firmware/0.0.0~git20151225-1

[Niels Thykier]

Control: tags -1 moreinfo

Stefano Rivera:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package hdmi2usb-fx2-firmware.
> 
> I screwed up a bit with hdmi2usb-fx2-firmware, and the version in
> unstable/testing doesn't actually work with the Numato Opsis board.
> Debian's boards are at IRILL in Paris, and I didn't have one to hand at
> the time.
> 
> There is no minimal diff to get us to a working image, because what we
> currently have is some random snapshot from before they worked. Yes,
> this is shitty, but that's what you get with small community hardware
> projects. (Once upstream found something that worked, they lobbed that
> firmware blob around a lot.)
> 
> [...]
> 
> unblock hdmi2usb-fx2-firmware/0.0.0~git20151225-1
> 

Hi,

Thanks for working on this.

How soon can we have confirmed whether this upload fixes the issue with
Numato Opsis boards?  If we unblock this, I would like to know it at
least fixes the issue we are unblocking it for.

Thanks,
~Niels

Bug#855534: unblock: multiple packages, didn't make it to testing due to openssl1.1

[Andrew Shadura]

Hi,

On 19 February 2017 at 22:25, Sebastian Andrzej Siewior
 wrote:
> Package: release.debian.org
> User: release.debian@packages.debian.org
> Usertags: unblock
> Severity: normal
>
> I hope it is okay, to open one bug instead of three:
> - libdigidoc
>   removed from testing [0] not sure why. Adrian Bunk NMUed it to to
>   build with libssl1.0-dev

Please no. If you read the bug tracker, you would know it was
intentional. This package is a part of a set of packages I intended to
package but never finished, and having it in Debian may make it more
difficult for the upstream to provide their own third party repository.
That is why I decided to remove it from testing for now. Please don't
revert that.

-- 
Cheers,
  Andrew

Bug#855359: [Pkg-phototools-devel] Bug#855359: darktable: 2.2.1 binary very slow compared to self-compiled

[matthias]

Am 2017-02-20 0:36, schrieb David Bremner:

Matthias Bodenbinder  writes:


And by the way, this are the commands I use to compile DT:

./build.sh --disable-gnome-keyring --prefix /home/software/darktable 
--build-type Release

cd build
echo "darktable 2.2.1" > description-pak
checkinstall --default --install=no --pkgname=darktable-mbo 
--pkgversion=$version --docdir=$INST/share/doc


Matthias


The debian package does not use build.sh. I looks like build.sh does 
not

pass -DBINARY_PACKAGE_BUILD=1 to cmake.

To test this, you could run something like

mkdir -p dtbuild && cd dtbuild && cmake  
-DCMAKE_INSTALL_PREFIX=/opt/darktable \

  -DCMAKE_BUILD_TYPE=Release  -DBINARY_PACKAGE_BUILD=1 ..

then I guess your same checkinstall should work.

d


Hi,

I do not understand your point. My checkinstall is working fine. It is 
just that my binaries are a lot faster than the debian testing binaries.


Matthias

Bug#855432: unblock: openssl/1.1.0e-1

[Niels Thykier]

Cyril Brulebois:
> Niels Thykier  (2017-02-19):
>> [...]
> 
> Hrm. You mentioned on IRC you were pondering possibly rebuilding wget
> against 1.1 for stretch; if that happens, this needs d-i testing…
> 
> 
> KiBi.
> 

I did and I agree on the testing part.  Would a "no-change rebuild" tpu
upload of wget be a solution for you?  That should ensure we control
when the wget change migrates to testing (which is somewhat more
difficult with binNMUs).

Thanks,
~Niels

Bug#855567: unblock: w3c-sgml-lib/1.3-2

[Kyle Robbertze]

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

Please unblock package w3c-sgml-lib

This new version fixes #826216 and updates the maintainer to reflect the
orphaned state of the package.

Source diff is attached

unblock w3c-sgml-lib/1.3-2

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

Kernel: Linux 4.9.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_ZA.UTF-8, LC_CTYPE=en_ZA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru w3c-sgml-lib-1.3/debian/changelog w3c-sgml-lib-1.3/debian/changelog
--- w3c-sgml-lib-1.3/debian/changelog   2013-03-16 18:11:53.0 +0200
+++ w3c-sgml-lib-1.3/debian/changelog   2017-02-04 09:15:24.0 +0200
@@ -1,3 +1,11 @@
+w3c-sgml-lib (1.3-2) unstable; urgency=medium
+
+  * QA Upload
+  * New Maintainer: Debian QA Group
+  * Fixed inconsistencies in the copyright file (Closes: #826216)
+
+ -- Kyle Robbertze   Sat, 4 Feb 2017 09:15:24 +0200
+
 w3c-sgml-lib (1.3-1) unstable; urgency=low
 
   * New upstream release (Closes: #665298)
diff -Nru w3c-sgml-lib-1.3/debian/control w3c-sgml-lib-1.3/debian/control
--- w3c-sgml-lib-1.3/debian/control 2013-03-16 17:43:37.0 +0200
+++ w3c-sgml-lib-1.3/debian/control 2017-02-04 09:15:24.0 +0200
@@ -1,7 +1,7 @@
 Source: w3c-sgml-lib
 Section: text
 Priority: optional
-Maintainer: Nicholas Bamber 
+Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 9.20120909), xml-core (>= 0.13+nmu2~),
  libreadonly-perl, libxml-libxml-perl, libautodie-perl
 Standards-Version: 3.9.4
diff -Nru w3c-sgml-lib-1.3/debian/copyright w3c-sgml-lib-1.3/debian/copyright
--- w3c-sgml-lib-1.3/debian/copyright   2012-10-03 10:41:57.0 +0200
+++ w3c-sgml-lib-1.3/debian/copyright   2017-02-04 09:13:21.0 +0200
@@ -4,35 +4,69 @@
 Upstream-Name: W3C SGML Library
 
 Files: *
-Copyright: 1994-2010, W3C(R) (MIT, ERCIM, KEIO)
+Copyright: 1994-2002, W3C(R) (MIT, ERCIM, KEIO)
 License: W3C-Software
+Comment: License Grant
+ Schemas (and DTDs) are frequently part of our specifications and
+ seemingly fall under the document copyright terms. However, as long as
+ you do not use the same formal namespace or public identifier to
+ identify that modified W3C schema/DTD (which might confuse
+ applications), you may treat the schema/DTD under the software terms.
+ This means that you are permitted to make a derivative or modified W3C
+ schema/DTD, but even under the software terms you are obligated to
+ include/retain the W3C copyright notice. We further appreciate a couple
+ sentences regarding who made the modifications, when, and what changes
+ were made in the original DTD -- a common software documentation practice.
+ .
+ From: 
http://web.archive.org/web/20010602194347/http://www.w3.org/Consortium/Legal/IPR-FAQ-2620.html#DTD
+
+Files: htdocs/sgml-lib/REC-xhtml1-20020801/xhtml1-*.dtd
+Copyright: 1994-2002, W3C(R) (MIT, ERCIM, KEIO)
+License: W3C-Software
+Comment: License Grant
+ However, if no specific license exists for such a DTD or schema, as
+ long as you do not use the same formal namespace or public identifier
+ to identify that modified W3C schema/DTD (which might confuse
+ applications), you often may treat the schema/DTD under the software
+ terms. This means that you are permitted to make a derivative or
+ modified W3C schema/DTD, but even under the software terms you are
+ obligated to include/retain the W3C copyright notice. We further
+ appreciate a couple sentences regarding who made the modifications,
+ when, and what changes were made in the original DTD - a common
+ software documentation practice.
+ .
+ From: 
http://web.archive.org/web/20020806141443/http://www.w3.org/Consortium/Legal/IPR-FAQ-2620.html#DTD
 
 Files: debian/*
 Copyright: 2010-2012, Nicholas Bamber 
 License: Artistic
 
 License: W3C-Software
- By obtaining, using and/or copying this work, you (the licensee) agree
- that you have read, understood, and will comply with the following
- terms and conditions.
+ This W3C work (including software, documents, or other related items)
+ is being provided by the copyright holders under the following 
+ license. By obtaining, using and/or copying this work, you (the 
+ licensee) agree that you have read, understood, and will comply with
+ the following terms and conditions:
  .
- Permission to copy, modify, and distribute this software and its
- documentation, with or without modification, for any purpose and
+ Permission to use, copy, modify, and distribute this software and its
+ documentation, with or without modification,  for any purpose and
  without fee or royalty is hereby granted, provided that you include the
  following on ALL copies of the software and documentation or portions
- thereof, including 

Bug#855566: O: granule -- flashcard program for learning new words

[Riley Baird]

Package: wnpp
Severity: normal

I'm orphaning all of my packages in Debian because I have decided to
move onto other endevours and I don't think that I will have the time
to give my packages the attention they deserve.

It's been great being part of Debian and I still remain an enthusiastic
user.

The description reads:

Granule is a flashcard program that implements Leitner cardfile
methodology for learning new words. It features both short-term and
long-term memory training capabilities with scheduling. 

Bug#855565: cross-install-location.diff no longer applies

[Helmut Grohne]

Source: gcc-7
Version: 6.3.0-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

Hi Matthias,

I started trying cross toolchain builds with gcc-7 and quickly noticed
that cross-install-location.diff hasn't been updated for gcc-7 yet. I am
attaching a patch to that minimally updates it to apply again. After
applying it, the cross toolchain bootstrap appears to mostly work.

Helmut
--- a/debian/patches/cross-install-location.diff
+++ b/debian/patches/cross-install-location.diff
@@ -61,7 +61,7 @@
 @@ -255,7 +255,7 @@ with_libiberty = @with_libiberty@
  ACLOCAL_AMFLAGS = -I .. -I ../config
  AUTOMAKE_OPTIONS = no-dependencies
- gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
+ gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
 -libexecsubdir := $(libexecdir)/gcc/$(real_target_noncanonical)/$(gcc_version)$(accel_dir_suffix)
 +libexecsubdir := $(libexecdir)/gcc-cross/$(real_target_noncanonical)/$(gcc_version)$(accel_dir_suffix)
  AM_CPPFLAGS = -I$(top_srcdir)/../include $(DEFS)
@@ -167,9 +167,9 @@
 -  -DSTANDARD_LIBEXEC_PREFIX=\"$(libexecdir)/gcc/\" \
 +  -DSTANDARD_EXEC_PREFIX=\"$(libdir)/gcc-cross/\" \
 +  -DSTANDARD_LIBEXEC_PREFIX=\"$(libexecdir)/gcc-cross/\" \
-   -DDEFAULT_TARGET_VERSION=\"$(BASEVER_c)\" \
-   -DDEFAULT_TARGET_FULL_VERSION=\"$(FULLVER_c)\" \
+   -DDEFAULT_TARGET_VERSION=\"$(version)\" \
-DDEFAULT_REAL_TARGET_MACHINE=\"$(real_target_noncanonical)\" \
+   -DDEFAULT_TARGET_MACHINE=\"$(target_noncanonical)\" \
 @@ -2671,7 +2671,7 @@ PREPROCESSOR_DEFINES = \
-DTOOL_INCLUDE_DIR=\"$(gcc_tooldir)/include\" \
-DNATIVE_SYSTEM_HEADER_DIR=\"$(NATIVE_SYSTEM_HEADER_DIR)\" \
@@ -251,7 +251,7 @@
 @@ -68,7 +68,7 @@ GCC_DIR=$(MULTIBUILDTOP)../../$(host_sub
  
  target_noncanonical:=@target_noncanonical@
- version := $(shell cat $(srcdir)/../gcc/BASE-VER)
+ version := $(shell @get_gcc_base_ver@ $(srcdir)/../gcc/BASE-VER)
 -libsubdir := $(libdir)/gcc/$(target_noncanonical)/$(version)$(MULTISUBDIR)
 +libsubdir := $(libdir)/gcc-cross/$(target_noncanonical)/$(version)$(MULTISUBDIR)
  ADA_RTS_DIR=$(GCC_DIR)/ada/rts$(subst /,_,$(MULTISUBDIR))
@@ -265,9 +265,9 @@
  search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir) \
  	  $(top_srcdir)/../include
  
--fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude
+-fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude
 -libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include
-+fincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/finclude
++fincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude
 +libsubincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include
  AM_CPPFLAGS = $(addprefix -I, $(search_path))
  AM_CFLAGS = $(XCFLAGS)
@@ -280,9 +280,9 @@
  search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir) \
  	  $(top_srcdir)/../include
  
--fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude
+-fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude
 -libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include
-+fincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/finclude
++fincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude
 +libsubincludedir = $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include
  
  vpath % $(strip $(search_path))
@@ -307,7 +307,7 @@
 @@ -8,6 +8,6 @@ EXTRA_DIST=ffi.h.in
  
  # Where generated headers like ffitarget.h get installed.
- gcc_version   := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
+ gcc_version   := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
 -toollibffidir := $(libdir)/gcc/$(target_alias)/$(gcc_version)/include
 +toollibffidir := $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include
  
@@ -319,7 +319,7 @@
 @@ -251,7 +251,7 @@ EXTRA_DIST = ffi.h.in
  
  # Where generated headers like ffitarget.h get installed.
- gcc_version := $(shell cat $(top_srcdir)/../gcc/BASE-VER)
+ gcc_version := $(shell @get_gcc_base_ver@ $(top_srcdir)/../gcc/BASE-VER)
 -toollibffidir := $(libdir)/gcc/$(target_alias)/$(gcc_version)/include
 +toollibffidir := $(libdir)/gcc-cross/$(target_alias)/$(gcc_version)/include
  toollibffi_HEADERS = ffi.h ffitarget.h

Bug#855564: O: coq-highschoolgeometry -- coq library for high school geometry proofs/formalisation

[Riley Baird]

Package: wnpp
Severity: normal

I'm orphaning all of my packages in Debian because I have decided to
move onto other endevours and I don't think that I will have the time
to give my packages the attention they deserve.

It's been great being part of Debian and I still remain an enthusiastic
user.

The description reads:

Created by Frédérique Guilhot, this library consists of a collection
of "chapters" spanning most of the geometry taught in French high
schools.

The first part "2-3 dimensional affine geometry" deals with formalising:

 points, vectors, barycenters, oriented lengths
 collinearity, coplanarity
 parallelism and incidence of straight lines
 proofs of Thales and Desargues theorems.

In the second part "3 dimensional affine geometry", theorems about
these things are proven:

 relative positions of two straight lines in the space
 relative positions of a straight line and a plane
 relative positions of two planes
 parallelism and incidence properties for several planes and straight
lines

The third part "2-3 dimensional euclidean geometry" deals with
formalising:

 scalar product, orthogonal vectors, and unitary vectors
 Euclidean distance and orthogonal projection on a line
 proofs of Pythagorean theorem, median theorem

The fourth part "space orthogonality" deals with formalising:

 orthogonal line and plan

The fifth part "plane euclidean geometry" deals with formalising:

 affine coordinate system, orthogonal coordinate system, affine
coordinates oriented angles
 trigonometry
 proofs of Pythagorean theorem, median theorem, Al-Kashi and sine
theorems perpendicular bisector, isocel triangle, orthocenter
 circle, cocyclicity, tangency (line or circle tangent)
 signed area, determinant
 equations for straight lines and circles in plane geometry

The sixth part "plane transformations", deals with formalising:

 translations, homothety
 rotations, reflexions
 composition of these transformations.
 conservation of tangency for these transformations.

In the seventh part "applications", these are proven:

 Miquel's theorem, orthocenter theorem, Simson line
 circle power and plane inversion
 Euler line theorem and nine point circle theorem

The eighth part "complex numbers", deals with formalising:

 the field properties of complex numbers
 application to geometry of complex numbers

Bug#855563: O: 2vcard -- perl script to convert an addressbook to VCARD file format

[Riley Baird]

Package: wnpp
Severity: normal

I'm orphaning all of my packages in Debian because I have decided to
move onto other endevours and I don't think that I will have the time
to give my packages the attention they deserve.

It's been great being part of Debian and I still remain an enthusiastic
user.

The description reads:

2vcard converts address books and alias files into the widely-used
vCard format. Currently it can convert from abook, Eudora, Juno, LDIF,
mutt, mh and pine.

Bug#830601: Interested to assist in packaging matrix-synapse

[Rahul De]

Dear Andrew,


Thank you for taking up packaging of matrix-synapse.  Dependencies for
matrix-synapse seems to be mostly packaged by you. Sunil and I,
contributors to the FreedomBox, are interested in helping out with the
packaging effort of matrix-synapse server.  Could you please let know
if you have source repository for the Debian packaging work you are
doing? We could help by testing and submitting patches. So far, we
found out-of-debian packaging effort to have progressed significantly:
https://github.com/matrix-org/package-synapse-debian


-- 
Regards,

Rahul Dé

Bug#855562: Dependency Conflict in jessie-backports

[Matthias Faulstich]

Package: openjdk-8-jre
Version: 8u111-b14-2~bpo8+1
Architecture: amd64

Dear Maintainer,

the actual Jessie update prevents to update of the OpenJDK 8 packages 
with following message:

apt-get dist-upgrade
...
The following packages have been kept back:
  openjdk-8-jre openjdk-8-jre-headless
0 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.

The reason seems to be conflicts with certificates, installed by defaut.

apt-get install openjdk-8-jre
...
The following packages have unmet dependencies:
 openjdk-8-jre : Depends: openjdk-8-jre-headless (= 8u121-b13-1~bpo8+1) but it 
is not going to be installed


apt-get install openjdk-8-jre-headless
...
The following packages have unmet dependencies:
 openjdk-8-jre-headless : Breaks: ca-certificates-java (< 20160321~) but 
20140324 is to be installed

apt-get install ca-certificates-java
...
ca-certificates-java is already the newest version.





Kind Regards
Matthias FaulstichBEGIN:VCARD
ADR;TYPE=work:;;Frauenstuhlweg 31;Iserlohn;;58644;
EMAIL:faulstich.matth...@fh-swf.de
FN:Matthias Faulstich
N:Faulstich;Matthias;;;
ORG:Fachhochschule Südwestfalen
TEL;TYPE=WORK:02371 / 566 - 383
UID:efc690f3-3b7d-476f-9ddd-366377ff8bfc
VERSION:3.0
X-KADDRESSBOOK-X-Office:Z 104
END:VCARD

Bug#854186: network-manager: DHCP connection stopped working (however, it works perfectly by using the console)

[Marco Presi]

Hi, the bug seems to be disappeared after the latest network-manager
upgrade to version 1.6.2-1.

Thanks

Marco

2017-02-04 20:22 GMT+01:00 Marco Presi :

> Package: network-manager
> Version: 1.6.0-1
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>
> Apparently nothing, probably an upgrade made few days ago
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> I ran, as usual, "apt dist-uprgade"
>
>* What was the outcome of this action?
>
> Few days later, as soon as I started my Gnome session, the network-manager
> applet shows that the system tries to connect to
> the DHCP server running on my local router.
>
>* What outcome did you expect instead?
>
> I expected a fast dhcp connection as usual.
>
>
> *** End of the template - remove these template lines ***
>
> I am able to connect by first stopping the interface by using the GNOME
> applet.
> Then I am able to set up the connection by using the command line (e.g. by
> running dhclient).
> When I run dhclient, the system connect almost instantaneously, and the
> GNOME
> applet change status indicating that
> the dhcp server assigned an IP (and the DNS as well).
>
> Here is the output of "tail -f /var/log/messages" when I try to activate
> the
> eth interface through the GNOME applet:
>
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2952]
> device (enp2s0): Activation: starting connection 'Connessione via cavo 1'
> (3ffb3114-1734-39d2-be00-fb3b00bee8e8)
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2953]
> audit: op="connection-activate" uuid="3ffb3114-1734-39d2-be00-
> fb3b00bee8e8"
> name="Connessione via cavo 1" pid=3488 uid=1000 result="success"
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2954]
> device (enp2s0): state change: disconnected -> prepare (reason 'none') [30
> 40
> 0]
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2955]
> manager: NetworkManager state is now CONNECTING
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2957]
> device (enp2s0): state change: prepare -> config (reason 'none') [40 50 0]
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2960]
> device (enp2s0): state change: config -> ip-config (reason 'none') [50 70
> 0]
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2962]
> dhcp4
> (enp2s0): activation: beginning transaction (timeout in 45 seconds)
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2973]
> dhcp4
> (enp2s0): dhclient started with pid 4189
> Feb  4 20:18:59 irmafamily gnome-shell[602]: ((libnm-util/nm-
> connection.c:1549)): assertion '' failed
> Feb  4 20:18:59 irmafamily gnome-shell[832]: ((libnm-util/nm-
> connection.c:1549)): assertion '' failed
>
> Here it follows the output of "tail -f /var/log/messages" when I activate
> the
> eth interface by running dhclient:
>
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7153]
> keyfile: add connection in-memory
> (ab188d84-7201-45ac-8f69-2a405cdfc859,"enp2s0")
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7168]
> device (enp2s0): Activation: starting connection 'enp2s0'
> (ab188d84-7201-45ac-8f69-2a405cdfc859)
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7172]
> device (enp2s0): state change: disconnected -> prepare (reason 'none') [30
> 40
> 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7180]
> device (enp2s0): state change: prepare -> config (reason 'none') [40 50 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7183]
> device (enp2s0): state change: config -> ip-config (reason 'none') [50 70
> 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7321]
> device (enp2s0): state change: ip-config -> ip-check (reason 'none') [70
> 80 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7701]
> device (enp2s0): state change: ip-check -> secondaries (reason 'none') [80
> 90
> 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7707]
> device (enp2s0): state change: secondaries -> activated (reason 'none')
> [90 100
> 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7710]
> manager: NetworkManager state is now CONNECTED_LOCAL
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7953]
> manager: NetworkManager state is now CONNECTED_GLOBAL
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7956]
> policy: set 'enp2s0' (enp2s0) as default for IPv4 routing and DNS
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7958]
> device (enp2s0): Activation: successful, device activated.
> Feb  4 20:20:14 irmafamily gnome-shell[602]: ((libnm-util/nm-
> connection.c:1549)): assertion '' failed
> Feb  4 20:20:14 irmafamily gnome-shell[832]: ((libnm-util/nm-
> 

Bug#854186: network-manager: DHCP connection stopped working (however, it works perfectly by using the console)

[Marco Presi]

Hi, the bug seems to be disappeared after the latest network-manager
upgrade to version 1.6.2-1.

Thanks

Marco

2017-02-04 20:22 GMT+01:00 Marco Presi :

> Package: network-manager
> Version: 1.6.0-1
> Severity: important
>
> Dear Maintainer,
>
> *** Reporter, please consider answering these questions, where appropriate
> ***
>
>* What led up to the situation?
>
> Apparently nothing, probably an upgrade made few days ago
>
>* What exactly did you do (or not do) that was effective (or
>  ineffective)?
>
> I ran, as usual, "apt dist-uprgade"
>
>* What was the outcome of this action?
>
> Few days later, as soon as I started my Gnome session, the network-manager
> applet shows that the system tries to connect to
> the DHCP server running on my local router.
>
>* What outcome did you expect instead?
>
> I expected a fast dhcp connection as usual.
>
>
> *** End of the template - remove these template lines ***
>
> I am able to connect by first stopping the interface by using the GNOME
> applet.
> Then I am able to set up the connection by using the command line (e.g. by
> running dhclient).
> When I run dhclient, the system connect almost instantaneously, and the
> GNOME
> applet change status indicating that
> the dhcp server assigned an IP (and the DNS as well).
>
> Here is the output of "tail -f /var/log/messages" when I try to activate
> the
> eth interface through the GNOME applet:
>
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2952]
> device (enp2s0): Activation: starting connection 'Connessione via cavo 1'
> (3ffb3114-1734-39d2-be00-fb3b00bee8e8)
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2953]
> audit: op="connection-activate" uuid="3ffb3114-1734-39d2-be00-
> fb3b00bee8e8"
> name="Connessione via cavo 1" pid=3488 uid=1000 result="success"
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2954]
> device (enp2s0): state change: disconnected -> prepare (reason 'none') [30
> 40
> 0]
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2955]
> manager: NetworkManager state is now CONNECTING
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2957]
> device (enp2s0): state change: prepare -> config (reason 'none') [40 50 0]
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2960]
> device (enp2s0): state change: config -> ip-config (reason 'none') [50 70
> 0]
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2962]
> dhcp4
> (enp2s0): activation: beginning transaction (timeout in 45 seconds)
> Feb  4 20:18:59 irmafamily NetworkManager[507]:   [1486235939.2973]
> dhcp4
> (enp2s0): dhclient started with pid 4189
> Feb  4 20:18:59 irmafamily gnome-shell[602]: ((libnm-util/nm-
> connection.c:1549)): assertion '' failed
> Feb  4 20:18:59 irmafamily gnome-shell[832]: ((libnm-util/nm-
> connection.c:1549)): assertion '' failed
>
> Here it follows the output of "tail -f /var/log/messages" when I activate
> the
> eth interface by running dhclient:
>
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7153]
> keyfile: add connection in-memory
> (ab188d84-7201-45ac-8f69-2a405cdfc859,"enp2s0")
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7168]
> device (enp2s0): Activation: starting connection 'enp2s0'
> (ab188d84-7201-45ac-8f69-2a405cdfc859)
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7172]
> device (enp2s0): state change: disconnected -> prepare (reason 'none') [30
> 40
> 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7180]
> device (enp2s0): state change: prepare -> config (reason 'none') [40 50 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7183]
> device (enp2s0): state change: config -> ip-config (reason 'none') [50 70
> 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7321]
> device (enp2s0): state change: ip-config -> ip-check (reason 'none') [70
> 80 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7701]
> device (enp2s0): state change: ip-check -> secondaries (reason 'none') [80
> 90
> 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7707]
> device (enp2s0): state change: secondaries -> activated (reason 'none')
> [90 100
> 0]
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7710]
> manager: NetworkManager state is now CONNECTED_LOCAL
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7953]
> manager: NetworkManager state is now CONNECTED_GLOBAL
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7956]
> policy: set 'enp2s0' (enp2s0) as default for IPv4 routing and DNS
> Feb  4 20:20:14 irmafamily NetworkManager[507]:   [1486236014.7958]
> device (enp2s0): Activation: successful, device activated.
> Feb  4 20:20:14 irmafamily gnome-shell[602]: ((libnm-util/nm-
> connection.c:1549)): assertion '' failed
> Feb  4 20:20:14 irmafamily gnome-shell[832]: ((libnm-util/nm-
> 

Bug#855401: ifupdown2 [1.0~git20170114-1~bpo8+1/jessie-backports] missing python-pkg-resources dependency

[Roopa Prabhu]

Thanks for reporting the issue. pkg_resources is only used to get the package 
version today.
We will most likely fix it by removing the use of pkg_resources given so little 
value it adds.

we will post a fix soon.

thanks.

Bug#855561: eog: opening a 15MB jpeg in EOG uses up over 1.3GB of memory

[Ritchie Wilson]

Package: eog
Version: 3.20.5-1
Severity: important

Dear Maintainer,

EOG takes up a lot of memory when opening single files. A 5MB jpeg could take
up 400MB of memory when opening. A 15MB jpeg takes over 1.3GB memory to open
(often spilling onto swap and bringing my laptop almosts to a hault). Opening
large PNGs in EOG creates the same excesive memeory usage problem.

I have tried opening these same pics in other software an non create any issues
-- they all open fine in Firefox, Chromium, GIMP, sushi, and Gnome Photos
without taking up excessive memory.

This problem started recently, but I can't figure out what packages might have
changed to create this problem.

Let me know if there's other info I can get you.

Thanks
Ritchie

*** 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 ***



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

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

Versions of packages eog depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gir1.2-gtk-3.0   3.22.7-2
ii  gir1.2-peas-1.0  1.20.0-1
ii  gsettings-desktop-schemas3.22.0-1
ii  libatk1.0-0  2.22.0-1
ii  libc62.24-9
ii  libcairo21.14.8-1
ii  libexempi3   2.4.1-1
ii  libexif120.6.21-2
ii  libgdk-pixbuf2.0-0   2.36.4-1
ii  libgirepository-1.0-11.50.0-1
ii  libglib2.0-0 2.50.2-2
ii  libgnome-desktop-3-123.22.2-1
ii  libgtk-3-0   3.22.7-2
ii  libjpeg62-turbo  1:1.5.1-2
ii  liblcms2-2   2.8-4
ii  libpeas-1.0-01.20.0-1
ii  librsvg2-2   2.40.16-1
ii  libx11-6 2:1.6.4-3
ii  shared-mime-info 1.8-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages eog recommends:
ii  librsvg2-common  2.40.16-1
ii  yelp 3.22.0-1

Versions of packages eog suggests:
pn  eog-plugins  

-- no debconf information

Bug#854804: [sane-devel] Bug#854804: saned: SANE_NET_CONTROL_OPTION response packet may contain memory contents of the server

[Kritphong Mongkhonvanit]

Hi Olaf,


On 02/19/2017 02:53 PM, Olaf Meeuwissen wrote:
> Attached is a minimal hack/patch that *tries* to fix it.  I have only
> checked that it compiles.  Could you take a look at whether it fixes
> the issue and does not break saned?
Thank you for your patch. I performed some basic tests and it seems to
fix the issue for me. It doesn't break saned as far as I can tell.

Bug#498657: bottlerocket + udev

[Rob Leslie]

Hi Thorsten,

The udev rule I submitted for the bug report has worked for me. You may need to 
adjust the tty name if your FireCracker is attached to a different port.

Unfortunately since this is a passive device that sits on the serial port, 
there is no real communication between it and the kernel to even know it is 
there. So I think this is about the best one can do.

-- 
Rob Leslie
r...@mars.org


> On Feb 19, 2017, at 4:13 AM, Thorsten Alteholz  wrote:
> 
> Hi,
> 
> I don't know whether you still use bottlerocket, but do you have any idea 
> what might be the correct udev rule?
> 
> Is the one mentioned in [1] sufficient? Isn't there any prod_id or whatever 
> available from the hardware to narrow the rule a bit?
> 
>  Thorsten
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=498657#10

Bug#855560: python-ws4py: generate a -doc package instead of installing doc in both bin pkgs

[Sandro Tosi]

Package: python-ws4py
Version: 0.3.4-4
Severity: normal

hello,
currently python-ws4py and python3-ws4py have example and doc installed, instead
of duplicating these files, please generate a -doc package and make the other 2
Suggests it

Thanks,
Sandro

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

Versions of packages python-ws4py depends on:
ii  libjs-sphinxdoc  1.4.6-1
pn  python:any   

python-ws4py recommends no packages.

Versions of packages python-ws4py suggests:
ii  python-cherrypy3  3.5.0-2
ii  python-gevent 1.1.2-1
ii  python-tornado4.2.1-1+b1

-- no debconf information

Bug#855559: Use pybuild in packaging

[Jordan Justen]

Package: alot
Version: 0.3.6-1
Severity: wishlist
Owner: jljus...@gmail.com

Suggested by Gianfranco in #855354.


signature.asc
Description: signature

Bug#855544: gitsome: embedded code copy of xonsh in source package + file conflict on installation: trying to overwrite '/usr/bin/xonsh', which is also in package xonsh 0.5.5+dfsg-1

[林上智]

Hi Abe,

Since xonsh version in gitsome (0.2.2) varies greatly from the version of
SID (0.5.5+dfsg-1), I think it might have potential compatibility issues by
using the SID version.

Perhaps it is more proper to rename the bundled copies of the xonsh
executable rather than build-depend on it.

Do you have any suggestions on it?

--
Sun-Ze Lin  (林上智)


2017-02-20 8:29 GMT+08:00 Axel Beckert :

> Package: gitsome
> Severity: serious
>
> Hi,
>
> trying to install gitsome while xonsh is already installed fails as
> follows:
>
> Unpacking gitsome (0.6.0-1) ...
> dpkg: error processing archive /var/cache/apt/archives/gitsome_0.6.0-1_all.deb
> (--unpack):
>  trying to overwrite '/usr/bin/xonsh', which is also in package xonsh
> 0.5.5+dfsg-1
> dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
> Errors were encountered while processing:
>  /var/cache/apt/archives/gitsome_0.6.0-1_all.deb
>
> According to https://github.com/donnemartin/gitsome it is "powered by
> xonsh", so it should probably depend on it instead of shipping a copy of
> it.
>
> Additionally the gitsome source package seems to contain an embedded
> code copy of xonsh. Embedded code copies are not wanted in Debian (if
> possible), so you might want to repack the upstream tar ball to remove
> the copy of xonsh and instead build-depend on it. See
> https://wiki.debian.org/EmbeddedCodeCopies for details.
>
> Filing this as a single bug report because fixing the latter issue
> properly will likely also fix the former. Feel free to clone the bug
> report if you think these two issues should be regarded as separate
> issues.
>
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (600, 'testing'), (500,
> 'unstable-debug'), (500, 'buildd-unstable'), (110, 'experimental'), (1,
> 'experimental-debug'), (1, 'buildd-experimental')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: sysvinit (via /sbin/init)
>

Bug#855558: linux-image-4.9.0-1-amd64: ACPI boot error causes /sbin/init to segfault (!)

[lkcl]

Package: src:linux
Version: 4.9.6-3
Severity: important
Tags: upstream

this is a very recent (skylake) very expensive laptop with an intel core i7
full report is here, with a link (at the bottom of the report) to
hardware info:
http://lkcl.net/reports/aorus_x3_plus_v6.html

it includes some information not listed below in the usual automated
info-collection (below)


i cannot boot the 4.9.0 kernel because of a segfault on /sbin/init.
a screenshot is here:
http://hands.com/~lkcl/IMG_20170220_1127225_rewind.jpg

in text it's saing "ACPI Error: Region EmbeddedControl (ID=3) has no
handler (20160831/exfldio-299)" and it goes downhill from there.

in the 4.7.8 and 4.8.11 kernels there are quite a few ACPI errors
reported (ACPI regions unknown) but they did not have any effect on
the useability of the system.

this error however, it's in /sbin/init!

works perfectly fine on 4.7.8 and 4.8.11

btw i found this:

https://lists.gt.net/xen/devel/408777

which gives a bit of background.  no, no hypervisors involved.  this
is straight linux-image-4.9.0-1-amd64.


-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: GIGABYTE
product_name: X3V6
product_version: Default string
chassis_vendor: Default string
chassis_version: y.y
bios_vendor: American Megatrends Inc.
bios_version: FB02
board_vendor: GIGABYTE
board_name: X3V6
board_version: Default string

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Sky Lake Host Bridge/DRAM 
Registers [8086:1910] (rev 07)
Subsystem: Gigabyte Technology Co., Ltd Device [1458:3457]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 

00:01.0 PCI bridge [0604]: Intel Corporation Sky Lake PCIe Controller (x16) 
[8086:1901] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 VGA compatible controller [0300]: Intel Corporation Device [8086:191b] 
(rev 06) (prog-if 00 [VGA controller])
DeviceName:  Onboard IGD
Subsystem: Gigabyte Technology Co., Ltd Device [1458:3457]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: i915

00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-H USB 3.0 xHCI 
Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI])
Subsystem: Gigabyte Technology Co., Ltd Device [1458:3457]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd

00:14.2 Signal processing controller [1180]: Intel Corporation Sunrise Point-H 
Thermal subsystem [8086:a131] (rev 31)
Subsystem: Gigabyte Technology Co., Ltd Device [1458:3457]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 

00:16.0 Communication controller [0780]: Intel Corporation Sunrise Point-H CSME 
HECI #1 [8086:a13a] (rev 31)
Subsystem: Gigabyte Technology Co., Ltd Device [1458:3457]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me

00:17.0 SATA controller [0106]: Intel Corporation Sunrise Point-H SATA 
Controller [AHCI mode] [8086:a103] (rev 31) (prog-if 01 [AHCI 1.0])
Subsystem: Gigabyte Technology Co., Ltd Device [1458:3457]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ahci

00:1c.0 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express Root 
Port #1 [8086:a110] (rev f1) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:1c.1 PCI bridge [0604]: Intel Corporation Sunrise Point-H PCI Express Root 
Port #2 [8086:a111] (rev f1) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ 

Bug#843126: Man pages

[David Steele]

As I've been playing with freight, I am noticing that the man pages
are in need of updating.

-- 
AE0D BF5A 92A5 ADE4 9481  BA6F 8A31 71EF 3661 50CE

Bug#855557: primus: gl framedropping isn't handled correctly, apps need a restart to recover

[lkcl]

Package: primus
Version: 0~20150328-4
Severity: important


i am using fvwm2 which is not the cause of the problem, howevver it may
be used to exacerbate an underlying flaw in primus.

the laptop i am using is an amazingly powerful one with a 1060 GTX nvidia
GPU: again, this is not the underlying cause of the problem.

the problem is that if frames are ever dropped (which can occur for
example when moving a window in fvwm2, where it is turned into a
wire-frame in order to save resources) there is no error-recovery
path.  all further GL operations are completely terminated, leaving
whatever application is running as completely frozen with whatever
last graphics operations happened to be underway at the time.

this happens universally on *all* applications.  vlc, chromium,
openscad, glxgears: it does not matter what application it is:
the moment that the window is moved it is guaranteed to cause the
"dropping frame" error message, and that is the last frame ever to
be attempted to be written to screen.

framedropping can also occur intermittently without warning, resulting
*also* in screen freezing.

note that there are no segfaults occurring here (in *any* of the
applications tested), that the rest of the application is perfectly fine:
it's just the opengl-rendered part that is frozen.  in the case of vlc
configured to render with opengl that obviously *means* the entire screen
is frozen, but that's a different matter.


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

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

Versions of packages primus depends on:
ii  bumblebee 3.2.1-13
ii  primus-libs   0~20150328-4
ii  socat 1.7.3.1-2
ii  xserver-xorg-core 2:1.19.0-2.0nosystemd1
ii  xserver-xorg-video-intel  2:2.99.917+git20161206-1

Versions of packages primus recommends:
ii  primus-libs-ia32  0~20150328-4

primus suggests no packages.

-- no debconf information

Bug#855434: chromium: Invalid SSL connection failure

[Michael Armijo]

This bug is also affecting me on Debian Jessie 8.7. Chromium 
56.0.2924.76-1~deb8u1.

Bug#854905: nmu: petsc_3.7.5+dfsg1-4

[Drew Parsons]

On Thu, 16 Feb 2017 15:12:23 +0800 Drew Parsons 
wrote:
> 
> petsc 3.7.5+dfsg1-4 has now hit testing.
> 

Hi again.  There's some discussion on what to do about openmpi in
testing (#855217).  Regardless of how we resolve that, can I
affirmatively request we trigger the binNMU for petsc?  

This is for the sake of unstable users, who need the rebuild done
anyway. And will make the transition faster if we do decide to let
openmpi 2.0.2 into testing.

  nmu petsc_3.7.5+dfsg1-4 . ANY . unstable . -m "Rebuild with openmpi 2.0.2. 
Closes: #854905."

Thanks,
Drew

Bug#850982: Exact command to globally disable gpg-agent user service?

[Michael[tm] Smith]

"Michael[tm] Smith" , 2017-02-20 11:11 +0900:
> 
> Can you confirm what the exact command is for globally disabling the gpg-agent
> user service? Is it the following?
> 
> systemctl --global --user mask --now gpg-agent.service gpg-agent.socket 
> gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket

Actually I guess that’s wrong and it should instead be the following, right?

systemctl --global mask --now gpg-agent.service gpg-agent.socket 
gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket

-- 
Michael[tm] Smith https://sideshowbarker.net/


signature.asc
Description: PGP signature

Bug#855401: Also affects testing

[Felix Lechner]

Control: retitle -1 ifupdown2: missing dependency on python-pkg-resources
Control: severity -1 important

Affects the version in testing, as well (1.0~git20170114-1).

Also, headless machines may not boot properly, so I am upgrading the
severity.

Bug#850982: Exact command to globally disable gpg-agent user service?

[Michael[tm] Smith]

Can you confirm what the exact command is for globally disabling the gpg-agent
user service? Is it the following?

systemctl --global --user mask --now gpg-agent.service gpg-agent.socket 
gpg-agent-ssh.socket gpg-agent-extra.socket gpg-agent-browser.socket

-- 
Michael[tm] Smith https://sideshowbarker.net/


signature.asc
Description: PGP signature

Bug#855556: unblock: python-ws4py/0.3.4-4

[Sandro Tosi]

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

Please unblock package python-ws4py

I've just uploaded this package with a fix for a FTBFS on a 1 CPU machine.

The source debdiff between -3 and -4 is attached (some of the diffs are due to
git-dpm patch generation logic).

unblock python-ws4py/0.3.4-4

-- 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.2.0-1-amd64 (SMP w/8 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)
diff -Nru python-ws4py-0.3.4/debian/changelog 
python-ws4py-0.3.4/debian/changelog
--- python-ws4py-0.3.4/debian/changelog 2016-08-07 17:02:52.0 -0400
+++ python-ws4py-0.3.4/debian/changelog 2017-02-19 20:57:41.0 -0500
@@ -1,3 +1,14 @@
+python-ws4py (0.3.4-4) unstable; urgency=medium
+
+  [ Sandro Tosi ]
+  * Team upload.
+
+  [ Norimitsu Sugimoto ]
+  * fix to fail unittest test_manager.py on 1 core CPU machine.
+(Closes: #834921)
+
+ -- Sandro Tosi   Sun, 19 Feb 2017 20:57:41 -0500
+
 python-ws4py (0.3.4-3) unstable; urgency=medium
 
   [ Ondřej Nový ]
diff -Nru python-ws4py-0.3.4/debian/.git-dpm python-ws4py-0.3.4/debian/.git-dpm
--- python-ws4py-0.3.4/debian/.git-dpm  2016-08-07 16:56:14.0 -0400
+++ python-ws4py-0.3.4/debian/.git-dpm  2017-02-19 20:57:41.0 -0500
@@ -1,6 +1,6 @@
 # see git-dpm(1) from git-dpm package
-750981d4c6165b945def438b4dd790c3326d03de
-750981d4c6165b945def438b4dd790c3326d03de
+13ac903999b5f3472de0794d710e88d31793c436
+13ac903999b5f3472de0794d710e88d31793c436
 7f43f2a6bff1aabafad023652042439d7b9b8d84
 7f43f2a6bff1aabafad023652042439d7b9b8d84
 python-ws4py_0.3.4.orig.tar.gz
diff -Nru python-ws4py-0.3.4/debian/patches/0001-Fix-tests.patch 
python-ws4py-0.3.4/debian/patches/0001-Fix-tests.patch
--- python-ws4py-0.3.4/debian/patches/0001-Fix-tests.patch  2016-08-07 
16:56:14.0 -0400
+++ python-ws4py-0.3.4/debian/patches/0001-Fix-tests.patch  2017-02-19 
20:57:41.0 -0500
@@ -1,4 +1,4 @@
-From a7d5ce7c1e8d39c2e68eeb6ef5bab72b3981dc37 Mon Sep 17 00:00:00 2001
+From 3722f5ece7e22ed67a84bfaae464853a146d2eb4 Mon Sep 17 00:00:00 2001
 From: Stein Magnus Jodal 
 Date: Thu, 5 Nov 2015 15:46:08 +0100
 Subject: Fix tests
@@ -6,12 +6,14 @@
 Based on upstream commits:
 - b5d47f7b3497f1b713a20fe6306b7d9afdd8c408
 - b2a76a33960040d7d3d27c68bf17c12f169f81c7
+
+fix unittest failing on 1 CPU machines
 ---
- test/test_manager.py | 13 +++--
- 1 file changed, 7 insertions(+), 6 deletions(-)
+ test/test_manager.py | 14 --
+ 1 file changed, 8 insertions(+), 6 deletions(-)
 
 diff --git a/test/test_manager.py b/test/test_manager.py
-index 8c229b0..da57d44 100644
+index 8c229b0..fceb77d 100644
 --- a/test/test_manager.py
 +++ b/test/test_manager.py
 @@ -16,10 +16,10 @@ class WSManagerTest(unittest.TestCase):
@@ -36,7 +38,15 @@
  m.poller.reset_mock()
  
  m.remove(ws)
-@@ -97,8 +97,9 @@ class WSManagerTest(unittest.TestCase):
+@@ -62,6 +62,7 @@ class WSManagerTest(unittest.TestCase):
+ self.assertFalse(m.running)
+ 
+ m.start()
++time.sleep(0.2)
+ self.assertTrue(m.running)
+ 
+ m.stop()
+@@ -97,8 +98,9 @@ class WSManagerTest(unittest.TestCase):
  
  m.add(ws)
  m.start()
@@ -47,7 +57,7 @@
  
  m.stop()
  
-@@ -109,7 +110,7 @@ class WSManagerTest(unittest.TestCase):
+@@ -109,7 +111,7 @@ class WSManagerTest(unittest.TestCase):
  ws = MagicMock()
  m.add(ws)
  m.close_all()
@@ -56,7 +66,7 @@
  
  @patch('ws4py.manager.SelectPoller')
  def test_broadcast(self, MockSelectPoller):
-@@ -120,7 +121,7 @@ class WSManagerTest(unittest.TestCase):
+@@ -120,7 +122,7 @@ class WSManagerTest(unittest.TestCase):
  m.add(ws)
  
  m.broadcast(b'hello there')
diff -Nru 
python-ws4py-0.3.4/debian/patches/0002-Make-intersphinx-use-object.inv-from-python-doc.patch
 
python-ws4py-0.3.4/debian/patches/0002-Make-intersphinx-use-object.inv-from-python-doc.patch
--- 
python-ws4py-0.3.4/debian/patches/0002-Make-intersphinx-use-object.inv-from-python-doc.patch
2016-08-07 16:56:14.0 -0400
+++ 
python-ws4py-0.3.4/debian/patches/0002-Make-intersphinx-use-object.inv-from-python-doc.patch
2017-02-19 20:57:41.0 -0500
@@ -1,4 +1,4 @@
-From 750981d4c6165b945def438b4dd790c3326d03de Mon Sep 17 00:00:00 2001
+From 13ac903999b5f3472de0794d710e88d31793c436 Mon Sep 17 00:00:00 2001
 From: Stein Magnus Jodal 
 Date: Sun, 7 Aug 2016 22:56:09 +0200
 Subject: Make intersphinx use object.inv from python-doc

Bug#855555: unblock: hdmi2usb-fx2-firmware/0.0.0~git20151225-1

[Stefano Rivera]

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

Please unblock package hdmi2usb-fx2-firmware.

I screwed up a bit with hdmi2usb-fx2-firmware, and the version in
unstable/testing doesn't actually work with the Numato Opsis board.
Debian's boards are at IRILL in Paris, and I didn't have one to hand at
the time.

There is no minimal diff to get us to a working image, because what we
currently have is some random snapshot from before they worked. Yes,
this is shitty, but that's what you get with small community hardware
projects. (Once upstream found something that worked, they lobbed that
firmware blob around a lot.)

This is obviously a very leaf package, the risk of changing it is
negligible.
(include/attach the debdiff against the package in testing)

unblock hdmi2usb-fx2-firmware/0.0.0~git20151225-1
diff --git a/.travis-push-docs.sh b/.travis-push-docs.sh
new file mode 100755
index 000..630605e
--- /dev/null
+++ b/.travis-push-docs.sh
@@ -0,0 +1,103 @@
+#!/bin/bash
+
+set -e
+
+if [ "$TRAVIS" = true -a "$TRAVIS_SECURE_ENV_VARS" = false ]; then
+	echo "No environment variables found, skipping (probably a pull request)."
+	exit 0
+fi
+
+if [ "$TRAVIS" = true -a "$TRAVIS_BRANCH" != "master" ]; then
+	echo "No master branch, skipping."
+	exit 0
+fi
+
+if [ -z "$TRAVIS_REPO_SLUG" ]; then
+	echo "No TRAVIS_REPO_SLUG value found."
+	echo "Please set this if running outside Travis."
+	exit 0
+fi
+
+# FIXME: Replace this with a deploy key, so you don't end up with tokens which
+# potentially give people *a lot* of access to your GitHub repos.
+if [ -z "$GH_TOKEN" ]; then
+	echo "No GH_TOKEN value found."
+	echo
+	echo "Generate a GitHub token at https://github.com/settings/tokens/new;
+	echo "with *only* the public_repo option."
+	echo "Then go to https://travis-ci.org/$TRAVIS_REPO_SLUG/settings and"
+	echo "add an 'Environment Variables' with the following;"
+	echo " * Name == GH_TOKEN"
+	echo " * Value == your token value from above"
+	echo " * Display value in build log == OFF"
+	echo
+	echo "It is important that you protect this token, as it has full push"
+	echo "access to your repos!"
+	exit 1
+fi
+
+if [ -z "$GIT_NAME" ]; then
+	echo "No GIT_NAME value found."
+	echo
+	echo "Then go to https://travis-ci.org/$TRAVIS_REPO_SLUG/settings and"
+	echo "add an 'Environment Variables' with the following;"
+	echo " * Name == GIT_NAME"
+	echo " * Value == Human readable name for the commit author."
+	echo "   Something like \"Tim Ansell's Robot\" is a good choice."
+	echo " * Display value in build log == ON"
+	exit 1
+fi
+
+if [ -z "$GIT_EMAIL" ]; then
+	echo "No GIT_EMAIL value found."
+	echo
+	echo "Then go to https://travis-ci.org/$TRAVIS_REPO_SLUG/settings and"
+	echo "add an 'Environment Variables' with the following;"
+	echo " * Name == GIT_EMAIL"
+	echo " * Value == Email address the commit author."
+	echo "   Set up an email address, or use your own."
+	echo " * Display value in build log == ON"
+	exit 1
+fi
+
+TMPDIR=$(mktemp --directory)
+
+if ! git describe > /dev/null 2>&1; then
+	echo "- Fetching non shallow to get git version"
+	git fetch --unshallow && git fetch --tags
+fi
+ORIG_GIT_REVISION=`git describe`
+ORIG_COMMITTER_NAME=$(git log -1 --pretty=%an)
+ORIG_COMMITTER_EMAIL=$(git log -1 --pretty=%ae)
+
+echo "- Setting up the output"
+cp -aRf docs/html/* $TMPDIR/
+cp docs/intro/intro.pdf $TMPDIR/
+find $TMPDIR | sort
+
+echo "- Switching to the gh-pages branch"
+git remote set-branches --add origin gh-pages
+git fetch origin gh-pages
+git checkout origin/gh-pages -b gh-pages
+
+echo "- Updating the README"
+sed -e"s-github.com/[^/]\+/[^/ ]\+-github.com/$TRAVIS_REPO_SLUG-" README.md > $TMPDIR/README.md
+cat $TMPDIR/README.md
+
+echo "- Adding the newly generated content"
+rm -rf *
+cp -aRf $TMPDIR/* .
+git add -v -A .
+
+echo "- Committing"
+export GIT_AUTHOR_EMAIL="$ORIG_COMMITTER_EMAIL"
+export GIT_AUTHOR_NAME="$ORIG_COMMITTER_NAME"
+export GIT_COMMITTER_EMAIL="$GIT_NAME"
+export GIT_COMMITTER_NAME="$GIT_EMAIL"
+unset GIT_NAME
+unset GIT_EMAIL
+git commit -a -m "Travis build #$TRAVIS_BUILD_NUMBER of $ORIG_GIT_REVISION"
+
+echo "- Pushing"
+git remote set-url origin https://$gh_to...@github.com/$TRAVIS_REPO_SLUG.git > /dev/null 2>&1
+git push origin gh-pages > /dev/null 2>&1
diff --git a/.travis.yml b/.travis.yml
index e5c96c9..5d5960c 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -10,6 +10,12 @@ install:
   - # Install sdcc
   - sudo apt-get install --force-yes -y sdcc
   - sdcc --version
+  - # doxygen & rubber are needed for generating the documentation
+  - sudo apt-get install -y doxygen rubber
 
 script:
   - make
+  - make docs
+
+after_success:
+  - ./.travis-push-docs.sh
diff --git a/debian/changelog b/debian/changelog
index 3541a3a..82797f3 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,4 +1,12 @@
-hdmi2usb-fx2-firmware (0.0.0~git20151018-1) unstable; urgency=low
+hdmi2usb-fx2-firmware 

Bug#855553: git-pbuilder: Add a quiet/silent option to disable "set -x"

[Frédéric Brière]

Package: git-buildpackage
Version: 0.8.12.2
Severity: wishlist

git-pbuilder unconditionally issues a "set -x" before invoking the
builder; since this outputs to stderr, this makes it rather difficult to
perform a silent run (such as in a cron job) without discarding any
error message.


-- 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 git-buildpackage depends on:
ii  devscripts2.17.1
ii  git   1:2.11.0-2
ii  man-db2.7.6.1-2
ii  python-dateutil   2.5.3-2
ii  python-pkg-resources  33.1.1-1
ii  python-six1.10.0-3
pn  python:any

Versions of packages git-buildpackage recommends:
ii  cowbuilder   0.85
ii  pbuilder 0.228.4
ii  pristine-tar 1.38
ii  python-requests  2.12.4-1

Versions of packages git-buildpackage suggests:
ii  python-notify  0.1.1-4
ii  sudo   1.8.19p1-1
ii  unzip  6.0-21

-- no debconf information

Bug#855554: unblock: debian-goodies/0.69

[Axel Beckert]

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

Please unblock the just uploaded debian-goodies version 0.69. (Not yet
accepted due to a just started dinstall run, but should be accepted
within the next hour or so.)

It fixes a regression from the Python 3 conversion in 0.65. It only
happens with a specific option, but causes a syntax error if that
option is used, i.e. makes that option unusable.

Unfortunately I didn't notice the according bug report when preparing
the last upload before the freeze and only a second bug report for the
same issue made me aware of it.

Full debdiff:

diff -Nru debian-goodies-0.68/checkrestart debian-goodies-0.69/checkrestart
--- debian-goodies-0.68/checkrestart2017-01-21 16:27:32.0 +0100
+++ debian-goodies-0.69/checkrestart2017-02-20 02:28:58.0 +0100
@@ -126,7 +126,8 @@
 checkroot()
 
 for f in blacklistFiles:
-for line in file(f, "r"):
+blacklistFile = open(f, 'r')
+for line in blacklistFile.readlines():
 if line.startswith("#"):
 continue
 blacklist.append(re.compile(line.strip()))
diff -Nru debian-goodies-0.68/debian/changelog 
debian-goodies-0.69/debian/changelog
--- debian-goodies-0.68/debian/changelog2017-01-21 16:36:15.0 
+0100
+++ debian-goodies-0.69/debian/changelog2017-02-20 02:37:42.0 
+0100
@@ -1,3 +1,11 @@
+debian-goodies (0.69) unstable; urgency=low
+
+  * checkrestart: Fix regression with -b/--blacklist from python3
+conversion. Thanks to Andrew Rolfe and Michael Glockenstein!
+(Closes: #835523, #854982)
+
+ -- Axel Beckert   Mon, 20 Feb 2017 02:37:42 +0100
+
 debian-goodies (0.68) unstable; urgency=medium
 
   * Fix "TypeError: a bytes-like object is required, not 'str'" when


unblock debian-goodies/0.69

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

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

Bug#844505: patch seems to work!

[Brainslug]

Hi,

I applied the patch from #15 and it seems to have fixed the segfault
issues for me on stretch. Thanks Elias for fixing this.

Cheers!

Bug#852746: beignet+mesa-opencl-icd crash if installed together

[Ivan Baldo]

All OpenCL ICDs with shared LLVM are useless if they can't be used 
in real programs, so my opinion for whats its worth is that they link 
statically with LLVM until the issue is resolved in another way allowing 
shared LLVM (probably Stretch+1 material).


Of course this is just my opinion... but, please think about it.

Thanks A LOT!!!



El 18/02/17 a las 19:11, Rebecca N. Palmer escribió:

Control: tags -1 patch

Statically linking to LLVM (see attached) fixes this bug, but I'm not 
sure yet whether we want to do that.


--
Ivan Baldo - iba...@adinet.com.uy - http://ibaldo.codigolibre.net/
Freelance C++/PHP programmer and GNU/Linux systems administrator.
The sky is not the limit!

Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

[Markus Koschany]

On 20.02.2017 01:56, Steve Cotton wrote:
> On Sun, Feb 19, 2017 at 09:38:12PM +0100, Steve Cotton wrote:
>> Sorry, but it's turned out that my patch either doesn't completely
>> avoid the bug, or doesn't avoid another bug which gives the same error
>> message.  The build has failed on arm64.
> 
> I've tried to reproduce this locally (on amd64, not arm64).  With my
> patch, I can't replicate the failure. Santiago, please would you test
> how it fares on your autobuilders?
> 
> Testing by removing my patch and trying to debug the root cause, I
> haven't found the cause yet.  But I think it will need a complex patch
> to either libsdl1.2 or xvfb, and I don't think this bug justifies any
> complex patch during the freeze.
> 
> It seems that one of the XOpenDisplay calls in SDL's X11VideoInit fails.
> Having a GCC breakpoint at the start of X11VideoInit, or running MakeDat
> under strace, makes the bug unreproducible.  Adding a long sleep to the
> last point in the ri-li package's code before SDL_Init doesn't help.
> Running another SDL programe first in the same xvfb server doesn't
> change anything, so it seems that the server can't be primed in advance.
> 
> Markus, I'm really sorry that what looked like a risk-free patch has
> caused a failed rebuild.  Depending on the TC's ruling, does it sound
> sensible to say that 2.0.1+ds-4 is in Stretch, and -5 doesn't affect -4?

Hi Steve,

no worries and thanks for providing a helping hand here. I've also tried
a couple of different options in the past hours. I think your initial
patch wasn't completely wrong and the underlying issue has something to
do how SDL initializes its subsystems but I have reverted it for now.

I have read about issues when using SDL in virtual machines but I have
found only one clue namely to manually link with -lX11 to avoid this
kind of error. I have tried this solution at least 20 times on
asachi.debian.org (arm64 porterbox) and couldn't reproduce the build
failure anymore.

I have uploaded another revision a few minutes ago. -5 and -6 don't
affect Stretch. I don't know about a TC ruling but since it is obvious
that the claim of "99 %" build failures is not true I stand by my
opinion that this is not release critical.

We could also stop building the data from source but this isn't
something I would call an improvement over the current situation.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#855552: [zeroc-ice] - missing python 2 bindings

[Malte.Marquarding]

Package: zeroc-ice
Version: 3.6.3-4
Severity: normal
Source: zeroc-ice

Debian “stretch” no longer contains a package with python2 bindings. In 
previous releases this was available as ‘python-zeroc-ice’.
The source package’s “rules” seem to have been completely re-written without 
the inclusion of python2. The source of zeroc 3.6 still supports python2/
I can’t see this being is a deliberate choice as there is no trace in the 
“changelog” or an announcement for dropping this in NEWS.

Bug#855550: xflr5: more recent versions released upstream

[Kai-Martin Knaak]

Package: xflr5
Version: 6.09.06-2+b2
Severity: normal

Dear Maintainer,

current version of xflr5 in debian is v6.09.06 from december 2013.
Upstream has been quite active and released quite a number of versions
which fixed bugs and added substatially to the usability. Current
upstream version is v6.31
See the release notes of the project:
http://www.xflr5.com/ReleaseNotes.htm

Is there a chance to push the version of the Debian package?

Thanks for maintaining tis most useful application.

---<)kaimartin(>---

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



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

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

Versions of packages xflr5 depends on:
ii  libc6 2.24-9
ii  libgcc1   1:6.3.0-6
ii  libgl1-mesa-glx [libgl1]  13.0.3-1
ii  libqt4-opengl 4:4.8.7+dfsg-11
ii  libqt4-xml4:4.8.7+dfsg-11
ii  libqtcore44:4.8.7+dfsg-11
ii  libqtgui4 4:4.8.7+dfsg-11
ii  libstdc++66.3.0-6

Versions of packages xflr5 recommends:
ii  xflr5-doc  6.09.06-2

xflr5 suggests no packages.

-- no debconf information



-- 
Kai-Martin Knaak
Email: k...@familieknaak.de
Öffentlicher PGP-Schlüssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53

Bug#855551: ITP: astrodendro -- Generate a dendrogram from a dataset

[Josue Ortega]

Package: wnpp
Severity: wishlist
Owner: Josue Ortega 

*Package name: astrodendro
 Version: 0.1.0
 Upstream Author: Thomas Robitaille,
  Chris Beaumont,
  Braden MacDonald,
  Erik Rosolowsky
*URL: https://github.com/dendrograms/astrodendro
*Licence: MIT
Programming Lang: Python
Description: The aim of this module is to provide an easy way to compute
 dendrograms of observed or simulated Astronomical data in Python

---
Josue Ortega
«Happy Hacking»
http://josueortega.org

signature.asc
Description: PGP signature

Bug#841401: Bug#851927: chromium: Update removed all (local) installed extensions

[Michael Gilbert]

control: tag -1 moreinfo

Extension updating should be working correctly as of 56.0.2924.76-1.

Chromium varies how often it looks for updates.  I think the maximum
is a week, so if updates are still not fetched after a week then there
is still a problem.  Otherwise this is working as intended.

Best wishes,
Mike

Bug#848063: +patch: ri-li FTBFS on single-CPU buildds

[Steve Cotton]

On Sun, Feb 19, 2017 at 09:38:12PM +0100, Steve Cotton wrote:
> Sorry, but it's turned out that my patch either doesn't completely
> avoid the bug, or doesn't avoid another bug which gives the same error
> message.  The build has failed on arm64.

I've tried to reproduce this locally (on amd64, not arm64).  With my
patch, I can't replicate the failure. Santiago, please would you test
how it fares on your autobuilders?

Testing by removing my patch and trying to debug the root cause, I
haven't found the cause yet.  But I think it will need a complex patch
to either libsdl1.2 or xvfb, and I don't think this bug justifies any
complex patch during the freeze.

It seems that one of the XOpenDisplay calls in SDL's X11VideoInit fails.
Having a GCC breakpoint at the start of X11VideoInit, or running MakeDat
under strace, makes the bug unreproducible.  Adding a long sleep to the
last point in the ri-li package's code before SDL_Init doesn't help.
Running another SDL programe first in the same xvfb server doesn't
change anything, so it seems that the server can't be primed in advance.

Markus, I'm really sorry that what looked like a risk-free patch has
caused a failed rebuild.  Depending on the TC's ruling, does it sound
sensible to say that 2.0.1+ds-4 is in Stretch, and -5 doesn't affect -4?

Steve

Bug#855549: apt should have a history command which shows what updates/upgrades and removals were done to packages

[shirish शिरीष]

Package: apt
Version: 1.4~rc1
Severity: wishlist

Dear Maintainer,

Looking at apt --help it gives the following options -

[$] apt --help

apt 1.4~rc1 (amd64)
Usage: apt [options] command

apt is a commandline package manager and provides commands for
searching and managing as well as querying information about packages.
It provides the same functionality as the specialized APT tools, like
apt-get and apt-cache, but enables options more suitable for
interactive use by default.

Most used commands:
  list - list packages based on package names
  search - search in package descriptions
  show - show package details
  install - install packages
  remove - remove packages
  autoremove - Remove automatically all unused packages
  update - update list of available packages
  upgrade - upgrade the system by installing/upgrading packages
  full-upgrade - upgrade the system by removing/installing/upgrading packages
  edit-sources - edit the source information file

See apt(8) for more information about the available commands.
Configuration options and syntax is detailed in apt.conf(5).
Information about how to configure sources can be found in sources.list(5).
Package and version choices can be expressed via apt_preferences(5).
Security details are available in apt-secure(8).
 This APT has Super Cow Powers.

While all the above options are good, one option which is missing and
should be there is $ apt history which gives an output from

Doing a less /var/log/apt/history.log gives the following -

Start-Date: 2017-02-20  05:07:11
Requested-By: shirish (1000)
Upgrade: libmpx0:amd64 (5.4.1-4, 5.4.1-5), libgcj16:amd64 (5.4.1-4,
5.4.1-5), libgcc-5-dev:amd64 (5.4.1-4, 5.4.1-5),
gcj-5-jre-headless:amd64 (5.4.1-4, 5.4.1-5), cpp-5:amd64 (5.4.1-4,
5.4.1-5), binutils:amd64 (2.27.90.20170124-2, 2.27.90.20170218-1),
libgcj16-awt:amd64 (5.4.1-4, 5.4.1-5), gcj-5-jre:amd64 (5.4.1-4,
5.4.1-5), libgfortran-5-dev:amd64 (5.4.1-4, 5.4.1-5), libasan2:amd64
(5.4.1-4, 5.4.1-5), gcc-5-base:amd64 (5.4.1-4, 5.4.1-5),
gcj-5-jre-lib:amd64 (5.4.1-4, 5.4.1-5), libstdc++-5-dev:amd64
(5.4.1-4, 5.4.1-5), g++-5:amd64 (5.4.1-4, 5.4.1-5), gcc-5:amd64
(5.4.1-4, 5.4.1-5), gfortran-5:amd64 (5.4.1-4, 5.4.1-5)
End-Date: 2017-02-20  05:08:44

Now as can be seen from the excerpt I took from /var/log/apt/history.log

Would be nice if the output could be prettifed, means no package
versioning info unless the user demands it exclusively.


-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Sandbox "";
APT::Sandbox::User "_apt";
APT::Authentication "";
APT::Authentication::TrustCDROM "true";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^firmware-linux.*";
APT::NeverAutoRemove:: "^linux-firmware$";
APT::NeverAutoRemove:: "^linux-image-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-backports-modules-.*-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^linux-tools-4\.9\.0-1-amd64$";
APT::NeverAutoRemove:: "^postgresql-";
APT::VersionedKernelPackages "";
APT::VersionedKernelPackages:: "linux-image";
APT::VersionedKernelPackages:: "linux-headers";
APT::VersionedKernelPackages:: "linux-image-extra";
APT::VersionedKernelPackages:: "linux-signed-image";
APT::VersionedKernelPackages:: "kfreebsd-image";
APT::VersionedKernelPackages:: "kfreebsd-headers";
APT::VersionedKernelPackages:: "gnumach-image";
APT::VersionedKernelPackages:: ".*-modules";
APT::VersionedKernelPackages:: ".*-kernel";
APT::VersionedKernelPackages:: "linux-backports-modules-.*";
APT::VersionedKernelPackages:: "linux-tools";
APT::Never-MarkAuto-Sections "";
APT::Never-MarkAuto-Sections:: "metapackages";
APT::Never-MarkAuto-Sections:: "contrib/metapackages";
APT::Never-MarkAuto-Sections:: "non-free/metapackages";
APT::Never-MarkAuto-Sections:: "restricted/metapackages";
APT::Never-MarkAuto-Sections:: "universe/metapackages";
APT::Never-MarkAuto-Sections:: "multiverse/metapackages";
APT::Move-Autobit-Sections "";
APT::Move-Autobit-Sections:: "oldlibs";
APT::Move-Autobit-Sections:: "contrib/oldlibs";
APT::Move-Autobit-Sections:: "non-free/oldlibs";
APT::Move-Autobit-Sections:: "restricted/oldlibs";
APT::Move-Autobit-Sections:: "universe/oldlibs";
APT::Move-Autobit-Sections:: "multiverse/oldlibs";
APT::Update "";
APT::Update::Post-Invoke-Success "";
APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions
|| exit 0 ; apt-show-versions -i";

Bug#853233: jessie-pu: package groovy/1.8.6-4+deb8u1

[Markus Koschany]

On 19.02.2017 21:45, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2017-01-30 at 19:28 +0100, Markus Koschany wrote:
>> I would like to upload a security update for Groovy in Jessie.
>> (Debdiff is attached) This is Debian bug #851408 or CVE-2016-6814. The
>> security team has marked this CVE as no-dsa but it would be good to
>> fix CVE-2016-6814 in Jessie too. I will also file a bug report for
>> Groovy2 which is affected by the same issue shortly.
> 
> Please go ahead.
> 

Thank you. Uploaded.




signature.asc
Description: OpenPGP digital signature

Bug#855535: python-numpy: Crash of gconf2 configuration

[Sandro Tosi]

control: tags -1 +moreinfo +unreproducible

On Sun, Feb 19, 2017 at 4:33 PM, Nicolas Patrois
 wrote:
>
> dpkg (via aptitude) refuses to configure gconf2, here is the error output:
>
> Setting up gconf2 (3.2.6-4) ...
> Traceback (most recent call last):
>   File "/usr/sbin/gconf-schemas", line 8, in 
> import sys,os,os.path,shutil,tempfile
>   File "/usr/lib/python2.7/tempfile.py", line 32, in 
> import io as _io
>   File "/usr/lib/python2.7/dist-packages/io.py", line 72, in 
> import numpy as N
>   File "/usr/lib/python2.7/dist-packages/numpy/__init__.py", line 142, in 
> 
> from . import add_newdocs
>   File "/usr/lib/python2.7/dist-packages/numpy/add_newdocs.py", line 13, in 
> 
> from numpy.lib import add_newdoc
>   File "/usr/lib/python2.7/dist-packages/numpy/lib/__init__.py", line 8, in 
> 
> from .type_check import *
>   File "/usr/lib/python2.7/dist-packages/numpy/lib/type_check.py", line 11, 
> in 
> import numpy.core.numeric as _nx
>   File "/usr/lib/python2.7/dist-packages/numpy/core/__init__.py", line 24, in 
> 
> raise ImportError(msg)
> ImportError:
> Importing the multiarray numpy extension module failed.  Most
> likely you are trying to import a failed build of numpy.
> If you're working with a numpy git repo, try `git clean -xdf` (removes all
> files not under version control).  Otherwise reinstall numpy.
>
> I tried to reinstall python-numpy but no way.

there is clearly something wrong/corrupted on your machine, please
contact a user support forum such as debian-users mailing list to
understand what your problem is, but the python-numpy package installs
and is usable just fine a clean chroot.

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

Bug#853235: jessie-pu: package groovy/2.2.2+dfsg-3+deb8u1

[Markus Koschany]

On 19.02.2017 21:44, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2017-01-30 at 19:38 +0100, Markus Koschany wrote:
>> groovy2 is also affected by CVE-2016-6814. The patch is almost
>> identical to the one used in groovy. Please find attached the debdiff.
> 
> Please go ahead.
> 

Thank you. Uploaded.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Bug#855548: hdmi2usb-fx2-firmware: --mode serial doesn't work

[Stefano Rivera]

Package: hdmi2usb-fx2-firmware
Version: 0.0.0~git20151018-1
Severity: grave
Justification: renders package unusable
Control: affects -1 hdmi2usb-mode-switch

hdmi2usb-mode-switch usually needs to put an opsis into serial mode,
before it'll successfully flash an image.

Currently, the uart image included in hdmi2usb-fx2-firmware doesn't seem
to work.

It looks like this was fixed upstream, but we packaged the wrong branch.

SR

Bug#855547: gitsome: fails to run

[Norbert Preining]

Package: gitsome
Version: 0.6.0-1
Severity: grave
Justification: renders package unusable

$ gh configure
Traceback (most recent call last):
  File "/usr/bin/gh", line 11, in 
load_entry_point('gitsome==0.6.0', 'console_scripts', 'gh')()
  File "/usr/local/lib/python3.5/dist-packages/pkg_resources/__init__.py", line 
567, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
  File "/usr/local/lib/python3.5/dist-packages/pkg_resources/__init__.py", line 
2612, in load_entry_point
return ep.load()
  File "/usr/local/lib/python3.5/dist-packages/pkg_resources/__init__.py", line 
2272, in load
return self.resolve()
  File "/usr/local/lib/python3.5/dist-packages/pkg_resources/__init__.py", line 
2278, in resolve
module = __import__(self.module_name, fromlist=['__name__'], level=0)
  File "/usr/lib/python3/dist-packages/gitsome/main_cli.py", line 20, in 

from .githubcli import GitHubCli
  File "/usr/lib/python3/dist-packages/gitsome/githubcli.py", line 21, in 

from .github import GitHub
  File "/usr/lib/python3/dist-packages/gitsome/github.py", line 25, in 
from .lib.github3 import null
  File "/usr/lib/python3/dist-packages/gitsome/lib/github3/__init__.py", line 
18, in 
from .api import (
  File "/usr/lib/python3/dist-packages/gitsome/lib/github3/api.py", line 11, in 

from .github import GitHub, GitHubEnterprise
  File "/usr/lib/python3/dist-packages/gitsome/lib/github3/github.py", line 17, 
in 
from .gists import Gist
  File "/usr/lib/python3/dist-packages/gitsome/lib/github3/gists/__init__.py", 
line 16, in 
from .gist import Gist
  File "/usr/lib/python3/dist-packages/gitsome/lib/github3/gists/gist.py", line 
14, in 
from .comment import GistComment
  File "/usr/lib/python3/dist-packages/gitsome/lib/github3/gists/comment.py", 
line 12, in 
from ..users import User
  File "/usr/lib/python3/dist-packages/gitsome/lib/github3/users.py", line 13, 
in 
from uritemplate import URITemplate
ImportError: No module named 'uritemplate'
$


-- System Information:
Debian Release: 9.0
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (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_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gitsome depends on:
ii  python3   3.5.3-1
ii  python3-click 6.6-1
ii  python3-colorama  0.3.7-1
ii  python3-docopt0.6.2-1
ii  python3-feedparser5.1.3-3
ii  python3-numpydoc  0.6.0+ds1-1
ii  python3-ply   3.9-1
ii  python3-prompt-toolkit1.0.9-1
ii  python3-pygments  2.2.0+dfsg-1
ii  python3-requests  2.12.4-1
ii  python3-sigmavirus24-urltemplate  3.0.0-1
ii  python3-tz2016.7-0.2
pn  python3:any   

gitsome recommends no packages.

gitsome suggests no packages.

-- no debconf information

Bug#855546: unblock: hobbit-plugins/20170219

[Axel Beckert]

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

Please unblock package hobbit-plugins as just uploaded to Debian
Unstable.

It fixes a single issue caused by changed output of git ("working
directory" in older versions, "working tree" in more recent versions).

Full debdiff:

diff -Nru hobbit-plugins-20170122/debian/changelog 
hobbit-plugins-20170219/debian/changelog
--- hobbit-plugins-20170122/debian/changelog2017-01-22 14:54:14.0 
+0100
+++ hobbit-plugins-20170219/debian/changelog2017-02-19 21:09:58.0 
+0100
@@ -1,3 +1,10 @@
+hobbit-plugins (20170219) unstable; urgency=low
+
+  * dirtyvcs: Update regular expression to detect clean git
+repositories. (Closes: #852824)
+
+ -- Axel Beckert <a...@debian.org>  Sun, 19 Feb 2017 21:09:58 +0100
+
 hobbit-plugins (20170122) unstable; urgency=medium
 
   * Fix wrong package name in Suggest, long package description and
diff -Nru hobbit-plugins-20170122/src/usr/lib/xymon/client/ext/dirtyvcs 
hobbit-plugins-20170219/src/usr/lib/xymon/client/ext/dirtyvcs
--- hobbit-plugins-20170122/src/usr/lib/xymon/client/ext/dirtyvcs   
2016-06-05 03:29:28.0 +0200
+++ hobbit-plugins-20170219/src/usr/lib/xymon/client/ext/dirtyvcs   
2017-02-19 21:09:35.0 +0100
@@ -41,7 +41,7 @@
 my $empty_re = qr/^\s*$/s;
 my %vcs_to_dir = (
 'git' => { dir => '.git',
-   clean => qr/nothing to commit,? \(?working directory clean/ },
+   clean => qr/nothing to commit,? \(?working \w+ clean/ },
 'bzr' => { dir => '.bzr',
clean => $empty_re },
 'hg'  => { dir => '.hg',


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

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

Bug#855544: gitsome: embedded code copy of xonsh in source package + file conflict on installation: trying to overwrite '/usr/bin/xonsh', which is also in package xonsh 0.5.5+dfsg-1

[Axel Beckert]

Package: gitsome
Severity: serious

Hi,

trying to install gitsome while xonsh is already installed fails as
follows:

Unpacking gitsome (0.6.0-1) ...
dpkg: error processing archive /var/cache/apt/archives/gitsome_0.6.0-1_all.deb 
(--unpack):
 trying to overwrite '/usr/bin/xonsh', which is also in package xonsh 
0.5.5+dfsg-1
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/gitsome_0.6.0-1_all.deb

According to https://github.com/donnemartin/gitsome it is "powered by
xonsh", so it should probably depend on it instead of shipping a copy of
it.

Additionally the gitsome source package seems to contain an embedded
code copy of xonsh. Embedded code copies are not wanted in Debian (if
possible), so you might want to repack the upstream tar ball to remove
the copy of xonsh and instead build-depend on it. See
https://wiki.debian.org/EmbeddedCodeCopies for details.

Filing this as a single bug report because fixing the latter issue
properly will likely also fix the former. Feel free to clone the bug
report if you think these two issues should be regarded as separate
issues.

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

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

Bug#855545: gitsome: uses old bundled xonsh (0.2.2 vs. 0.5.5)

[Aaron M. Ucko]

Package: gitsome
Version: 0.6.0-1
Severity: serious
Justification: Policy 4.13; 6.6(4)

gitsome uses a bundled copy of xonsh 0.2.2, and is thereby impossible
to install alongside Debian's separate xonsh package:

  Unpacking gitsome (0.6.0-1) ...
  dpkg: error processing archive .../gitsome_0.6.0-1_all.deb (--unpack):
   trying to overwrite '/usr/bin/xonsh', which is also in package xonsh 
0.5.5+dfsg-1

Please repackage it against standalone xonsh, or at least rename the
bundled copies of the xonsh executable and dist-packages subtree to
permit coinstallability with xonsh.

Thanks!

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

Bug#533708: Packaging libhugetlbfs

[Punit Agrawal]

owner 533708 !
thanks

I'm taking over the bug as there's no visible activity or progress in
packaging libhugetlbfs. Query to the bug owner has gone unanswered for
over a week.

I've created a local package and am working through the issues in
preparation for an upload. I'll push the package source to a git repo
once I've had a chance to tidy it up.

Thanks,
Punit

Bug#820381: rar crashes.

[Michael Gilbert]

control: tag -1 moreinfo

I tried rar on up to date i386 and amd64 stretch systems.  Versions
5.3 and 5.4 both work fine for me.

I am not sure if this is related or not, but linux 4.8.15-1 changes
vsyscall, which was mentioned in message #25.

Has anyone else tested this lately?

Best wishes,
Mike

Bug#756897: Specify ways to proof-read document post-save

[martin f krafft]

also sprach Jeffrey Ratcliffe  [2017-02-19 00:26 
+1300]:
> I apologise for the previous poor tip. I've just tested exactly this,
> i.e. a user-defined tool "run-mailcap %i" and it worked as expected.

I can now confirm this:

> But then I realised what happened - updating the preferences after the
> save dialogue has already been opened does not update the preferences.
> So I can reproduce your problem.
> 
> Therefore the workaround is to create the user-defined tool "run-mailcap
> %i", quit, restart, and then you should be able to use it as a post-save
> hook.

Indeed, and this is good enough I guess to replace the
view-after-save feature, though there might be the situation where
you're post-processing a PDF and then want to auto-view it, yet
on-save hooks can't be chained… but I guess that's then the realm of
shell scripts…

-- 
 .''`.   martin f. krafft  @martinkrafft
: :'  :  proud Debian developer
`. `'`   http://people.debian.org/~madduck
  `-  Debian - when you have better things to do than fixing systems
 
in the beginning was the word,
and the word was content-type: text/plain


digital_signature_gpg.asc
Description: Digital GPG signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)

Bug#853100: linux-image-4.9.0-1-amd64: Blocked tasks and no X on Latitude E6530

[Thomas Vaughan]

Attached is a copy of /var/log/messages from boot up until just after the
time of the first occurrence of the report of a blockage more than 120
seconds.

I notice that there is a new kernel package in unstable today. I'll check
that out, too.


On Sat, Feb 18, 2017 at 1:38 PM, Ben Hutchings  wrote:

> On Thu, 2017-02-16 at 20:17 -0700, Thomas Vaughan wrote:
> > I have attached the output both for linux-3.16 (which seems to have no
> > problem) and for linux-4.9.
>
> OK, so you have the VirtalBox and Broadcom wl modules loaded.  I doubt
> that they are involved in this bug.
>
> Can you look through /var/log/messages and extract the messages around
> the same time as "INFO: task worker/1:1:68 blocked for more than 120
> seconds"?
>
> Ben.
>
> --
> Ben Hutchings
> Knowledge is power.  France is bacon.
>



-- 
Thomas E. Vaughan


messages-2017-Feb-19
Description: Binary data

Bug#855425: replay

[積丹尼 Dan Jacobson]

Here's a replay:

# aptitude install adb
The following NEW packages will be installed:
  adb{b} (B: android-tools-adb)  android-libadb{a} (D: adb) (adb D: 
android-libadb)
  android-libbase{a} (D: adb, D: android-libadb) (adb D: android-libbase)
  android-libcutils{a} (D: adb, D: android-libadb) (adb D: android-libcutils)
  android-liblog{a} (D: android-libbase, D: android-libcutils) (adb D: 
android-libcutils D: android-liblog)
The following packages are RECOMMENDED but will NOT be installed:
  android-sdk-platform-tools-common (R: adb)
The following packages will NOT be UPGRADED:
  libpam-systemd{a}  libsystemd0{a}  systemd{a} (S: policykit-1, S: 
systemd-container, S: systemd-ui, R: udev)
0 packages upgraded, 5 newly installed, 0 to remove and 3 not upgraded.
Need to get 0 B/230 kB of archives. After unpacking 620 kB will be used.
The following packages have unmet dependencies:
 adb : Breaks: android-tools-adb but 5.1.1.r29-2 is installed
The following actions will resolve these dependencies:

 Remove the following packages:
1) android-tools-adb [5.1.1.r29-2 (now)]



Accept this solution? [Y/n/q/?]
The following NEW packages will be installed:
  adb  android-libadb{a} (D: adb) (adb D: android-libadb)
  android-libbase{a} (D: adb, D: android-libadb) (adb D: android-libbase)
  android-libcutils{a} (D: adb, D: android-libadb) (adb D: android-libcutils)
  android-liblog{a} (D: android-libbase, D: android-libcutils) (adb D: 
android-libcutils D: android-liblog)
The following packages will be REMOVED:
  android-tools-adb{a}
The following packages are RECOMMENDED but will NOT be installed:
  android-sdk-platform-tools-common (R: adb)
The following packages will NOT be UPGRADED:
  libpam-systemd{a}  libsystemd0{a}  systemd{a} (S: policykit-1, S: 
systemd-container, S: systemd-ui, R: udev)
0 packages upgraded, 5 newly installed, 1 to remove and 3 not upgraded.
Need to get 0 B/230 kB of archives. After unpacking 386 kB will be used.
Do you want to continue? [Y/n/?]
(Reading database ... 103383 files and directories currently installed.)
Removing android-tools-adb (5.1.1.r29-2) ...
Selecting previously unselected package android-liblog.
(Reading database ... 103376 files and directories currently installed.)
Preparing to unpack .../android-liblog_1%3a7.0.0+r1-2_i386.deb ...
Unpacking android-liblog (1:7.0.0+r1-2) ...
Selecting previously unselected package android-libbase.
Preparing to unpack .../android-libbase_1%3a7.0.0+r1-2_i386.deb ...
Unpacking android-libbase (1:7.0.0+r1-2) ...
Selecting previously unselected package android-libcutils.
Preparing to unpack .../android-libcutils_1%3a7.0.0+r1-2_i386.deb ...
Unpacking android-libcutils (1:7.0.0+r1-2) ...
Selecting previously unselected package android-libadb.
Preparing to unpack .../android-libadb_1%3a7.0.0+r1-2_i386.deb ...
Unpacking android-libadb (1:7.0.0+r1-2) ...
Selecting previously unselected package adb.
Preparing to unpack .../adb_1%3a7.0.0+r1-2_i386.deb ...
Unpacking adb (1:7.0.0+r1-2) ...
Setting up android-liblog (1:7.0.0+r1-2) ...
Processing triggers for libc-bin (2.24-9) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up android-libbase (1:7.0.0+r1-2) ...
Setting up android-libcutils (1:7.0.0+r1-2) ...
Setting up android-libadb (1:7.0.0+r1-2) ...
Setting up adb (1:7.0.0+r1-2) ...
Processing triggers for libc-bin (2.24-9) ...

Current status: 0 (+0) broken, 3 (+0) upgradable, 20649 (+0) new.
# aptitude purge ~c
The following packages will be REMOVED:
  android-tools-adb{p} (adb B: android-tools-adb)  vlc{p}
The following packages will NOT be UPGRADED:
  libpam-systemd{a}  libsystemd0{a}  systemd{a} (S: policykit-1, S: 
systemd-container, S: systemd-ui, R: udev)
0 packages upgraded, 0 newly installed, 2 to remove and 3 not upgraded.
Need to get 0 B of archives. After unpacking 0 B will be used.
Do you want to continue? [Y/n/?]
(Reading database ... 103405 files and directories currently installed.)
Purging configuration files for vlc (2.2.4-13) ...
Purging configuration files for android-tools-adb (5.1.1.r29-2) ...

Current status: 0 (+0) broken, 3 (+0) upgradable, 20649 (+0) new.
#



Also from the above,

The following packages will be REMOVED:
  android-tools-adb{a}

The following packages will be REMOVED:
  android-tools-adb{p} (adb B: android-tools-adb)  vlc{p}

despite the slight difference in the { },
I would say PURGED:.

OK trying with
-o Aptitude::CmdLine::Show-Deps=0 -o Aptitude::CmdLine::Show-Why=0 -o 
Aptitude::CmdLine::Verbose=0
still doesn't eliminate the { } so I suppose they will still always look 
different.

Bug#853162: jessie-pu: package xmobar/0.22-1

[Apollon Oikonomopoulos]

On 20:48 Sun 19 Feb , Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Mon, 2017-01-30 at 13:45 +0200, Apollon Oikonomopoulos wrote:
> > I would like to update xmobar in Jessie to fix #835547. As outlined in 
> > #835547, xmobar has a weather plugin that uses NOAA's feed. NOAA 
> > recently changed their feed URLs and xmobar has been updated upstream to 
> > reflect that change.
> 
> Please go ahead.
> 
> Regards,
> 
> Adam

Uploaded, thanks!

Regards,
Apollon

Bug#855432: unblock: openssl/1.1.0e-1

[Cyril Brulebois]

Niels Thykier  (2017-02-19):
> Cyril Brulebois:
> > We have this right now:
> > 
> > wget-udeb  | 1.18-4| testing  → built against 1.0.2
> > wget-udeb  | 1.19.1-1  | unstable → built against 1.1
> > 
> > If we're not getting a newer wget for stretch (at least I didn't find
> > anything wget-related relevant for stretch in my debian-release folder),
> > I can't think of another libssl user for d-i, which seems confirmed by
> > looking at libssl*-udeb rdepends in sid.
> > 
> > Unless I'm missing something obvious: no objections.
> 
> Unblocked, thanks.

Hrm. You mentioned on IRC you were pondering possibly rebuilding wget
against 1.1 for stretch; if that happens, this needs d-i testing…


KiBi.


signature.asc
Description: Digital signature

Bug#855359: [Pkg-phototools-devel] Bug#855359: darktable: 2.2.1 binary very slow compared to self-compiled

[David Bremner]

Matthias Bodenbinder  writes:

> And by the way, this are the commands I use to compile DT:
>
> ./build.sh --disable-gnome-keyring --prefix /home/software/darktable 
> --build-type Release
> cd build
> echo "darktable 2.2.1" > description-pak
> checkinstall --default --install=no --pkgname=darktable-mbo 
> --pkgversion=$version --docdir=$INST/share/doc
>
> Matthias

The debian package does not use build.sh. I looks like build.sh does not
pass -DBINARY_PACKAGE_BUILD=1 to cmake.

To test this, you could run something like

mkdir -p dtbuild && cd dtbuild && cmake  -DCMAKE_INSTALL_PREFIX=/opt/darktable \
  -DCMAKE_BUILD_TYPE=Release  -DBINARY_PACKAGE_BUILD=1 .. 

then I guess your same checkinstall should work.

d

Bug#855543: clarify configuration files on man page

[積丹尼 Dan Jacobson]

Package: aptitude
Version: 0.8.5-1
Severity: wishlist
File: /usr/share/man/man8/aptitude-curses.8.gz

Man page says

/etc/apt/apt.conf, /etc/apt/apt.conf.d/*, ~/.aptitude/config
   The configuration files for aptitude.  ~/.aptitude/config overrides
   /etc/apt/apt.conf. See apt.conf(5) for documentation of the format
   and contents of these files.

it should also say if it overrides /etc/apt/apt.conf.d/* and if
overrides means "is read after" or "is only read instead of".

Bug#659404: laptop-detect: Use /sys/devices/virtual/dmi/id/chassis_type as alternative to dmidecode?

[Petter Reinholdtsen]

[Simó Albert i Beltran]
> Thanks for your contribution to laptop-detect.
>
> I'm doing an ITA of this package and I would like include your 
> contribution.

Very nice to see my 5 year old patch finally gain some traction. :)

Note, a copy of laptop-detect is in the debian-edu-install-udeb package.

> I created the following commit but please do a merge request if you
> prefer.
> https://gitlab.com/debiants/laptop-detect/commit/ac832efccff4ca87a5ca01a7c3cfbb808fa386ba

I am perfectly fine with not doing anything, as it seem to be in good
hands already. :)
-- 
Happy hacking
Petter Reinholdtsn

Bug#855542: Grammar error in Description

[積丹尼 Dan Jacobson]

Package: android-sdk-platform-tools-common
Version: 24.0.0+2
Severity: minor

> It also provides an UDEV rules enabling adb and fastboot to work without root 
> access to the host machine.
< It also provides UDEV rules enabling adb and fastboot to work without root 
access to the host machine.

Bug#792894: [pkg-dhcp-devel] Bug#792894: ping?

[Michael Gilbert]

On Sun, Feb 19, 2017 at 6:02 PM, Mario Lang wrote:
> What are current plans on this bug?  I guess it is too late for Stretch?

As represented by the buginfo, this is considered blocked by #826011
and #826012.  Help there would get this moving faster.

Best wishes,
Mike

Bug#855541: purple-matrix: Not ready for release yet

[Kurt Roeckx]

Package: purple-matrix
Version: 0.0.0+git20170105-1
Severity: serious

Hi,

I think this version shouldn't be shipped with the next
release. Like the description says, it's "somewhat alpha".

It works some times, but then stops working, it crashes,
and so on.


Kurt

Bug#855143: unblock: wpa/2.5-2+v2.4-4stretch1

[Ivo De Decker]

Hi Andrew,

On Sun, Feb 19, 2017 at 11:33:32PM +0100, Andrew Shadura wrote:
>   On Tue, Feb 14, 2017 at 05:25:42PM +0100, Andrew Shadura wrote:
>   > Please unblock package wpa.
>   > This fix has to go through testing-proposed-updates.
> 
>   Why? Is there any reason you can't just revert the version in unstable? That
>   way we don't have to push a new untested upload to stretch. If this upload
>   goes through unstable, there is a higher change that issues are detected 
> (and
>   fixed).
> 
> Because the version in unstable is a new upstream version, and the version in
> testing is already a revert of a newer upstream version. I don't want to 
> confuse
> things even more.
> The changes I propose are quite minimal, and the version we have in testing 
> has
> been there for quite some time already. I don't think there's a high risk of
> introducing a regression with a bug fix.

We really, really want to avoid going through t-p-u if at all possible. In
this case, there doesn't seem to be a real issue with doing a revert in
unstable. There isn't really any point in having a version in unstable that
isn't meant for testing. The 2.6 version can go to experimental. As for the
confusion, this can be avoided by using an epoch instead of the version you're
using now (but that is really your call).

Please upload a targeted fix to unstable.

Cheers,

Ivo

Bug#792894: ping?

[Mario Lang]

After a wheezy->jessie->stretch upgrade, isc-dhcp-server is reported
as failing in systemctl, but the daemon is running.  I suspect this
could have been prevented with a proper systemd service file for
isc-dhcp-server, although that is mostly just a gut feeling.
Last activity on this bug was in June 2016.  Seems like plenty of time
to get a service file into the package.

What are current plans on this bug?  I guess it is too late for Stretch?

-- 
CYa,
  ⡍⠁⠗⠊⠕

Bug#855539: logwatch: Excessive unmatched entries in SSHD section of logwatch

[Richard Scherping]

Package: logwatch
Version: 7.4.3+git20161207-2
Severity: normal

Dear Maintainer,

upgrading from Debian jessie to stretch results in excessive unmatched entries 
in the SSHD section of logwatch output.

Example:

Failed logins from:
normal number (e.g. 12) of lines in the format: IP-address (Hostname): X times
 
Illegal users from:
normal number (e.g. 6) of lines in the format: IP-address (Hostname): X times
 
Received disconnect:
 [preauth] : 1357 Time(s)
Bye Bye [preauth] : 24 Time(s)
Closed due to user request. [preauth] : 22 Time(s)
disconnected by user [preauth] : 1 Time(s)
 
**Unmatched Entries**
hundreds/thousands of lines like this:
Disconnected from XXX.XXX.XXX.XXX port XX [preauth] : 1 time(s)

This seems to be due to missing backports of upstream fixes for new SSHD log 
file format, see also 
https://bugs.launchpad.net/ubuntu/+source/logwatch/+bug/1644057

Expected: only summary in "Received disconnect", limited number of "unmatched 
entries"


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

Versions of packages logwatch depends on:
ii  exim4-daemon-light [mail-transport-agent]  4.88-5
pn  perl:any   

Versions of packages logwatch recommends:
ii  libdate-manip-perl   6.57-1
ii  libsys-cpu-perl  0.61-2+b1
ii  libsys-meminfo-perl  0.99-1

Versions of packages logwatch suggests:
pn  fortune-mod  

-- no debconf information

Bug#855540: bind9: CVE-2016-8864 causes more regressions

[Michael Gilbert]

package: src:bind9
severity: grave
version: 1:9.10.3.dfsg.P4-11

The fix for this issue causes more regressions.

Bug#855134: installation-guide: mips related cleanups and updates

[Holger Wansing]

Hi,

Ben Hutchings  wrote:
> On Sun, 2017-02-19 at 20:03 +0100, Holger Wansing wrote:
> > Hi,
> > 
> > > Ben Hutchings  wrote:
> > > On Sun, 2017-02-19 at 12:41 +0100, Holger Wansing wrote:
> > > > Ben Hutchings  wrote:
> [...]
> > > > > installer flavour is needed for Xen PV domains only.
> > > > > - For powerpc there are powerpc and powerpc64 installer flavours.
> > > > >   I believe powerpc64 is needed on all systems with 64-bit
> > > > >   OpenFirmware.
> > > > 
> > > > That means the same? Add to flavors for ppc64el? How to name them?
> > > > I am confused here, powerpc is no release arch anymore, right?
> > > 
> > > [...]
> > > 
> > > No, I don't mean ppc64el.  I looked at the published version of the
> > > installation manual so I didn't see you already removed powerpc a few
> > > hours earlier.
> > 
> > So we only need the ppc64el flavor for powerpc, right?
> [...]
> 
> We only need one flavour for _ppc64el_, yes.

I have committed the changings, so that we have now:

┌───┬┬─┬──┐
│ Architecture  │ Debian │ Subarchitecture │  Flavor  │
│   │  Designation   │ │  │
├───┼┼─┼──┤
│   ││default x86 machines │default   │
│Intel x86-based│i386├─┼──┤
│   ││Xen PV domains only  │xen   │
├───┼┼─┼──┤
│AMD64 & Intel 64   │amd64   │ │  │
├───┼┼─┼──┤
│ARM│armel   │Marvell Kirkwood and │marvell   │
│   ││Orion│  │
├───┼┼─┼──┤
│ARM with hardware FPU  │armhf   │multiplatform│armmp │
├───┼┼─┼──┤
│64bit ARM  │arm64   │ │  │
├───┼┼─┼──┤
│   ││MIPS Malta   │4kc-malta │
│32bit MIPS (big-endian)│mips├─┼──┤
│   ││Cavium Octeon│octeon│
├───┼┼─┼──┤
│   ││MIPS Malta   │5kc-malta │
│64bit MIPS │├─┼──┤
│(little-endian)│mips64el│Cavium Octeon│octeon│
│   │├─┼──┤
│   ││Loongson 3   │loongson-3│
├───┼┼─┼──┤
│   ││MIPS Malta   │4kc-malta │
│32bit MIPS │├─┼──┤
│(little-endian)│mipsel  │Cavium Octeon│octeon│
│   │├─┼──┤
│   ││Loongson 3   │loongson-3│
├───┼┼─┼──┤
│Power Systems  │ppc64el │IBM POWER8 or newer  │  │
│   ││machines │  │
├───┼┼─┼──┤
│64bit IBM S/390│s390x   │IPL from VM-reader and   │generic   │
│   ││DASD │  │
└───┴┴─┴──┘


Holger


-- 

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

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

Bug#659404: laptop-detect: Use /sys/devices/virtual/dmi/id/chassis_type as alternative to dmidecode?

[Simó Albert i Beltran]

Hello,

Thanks for your contribution to laptop-detect.

I'm doing an ITA of this package and I would like include your 
contribution.


I created the following commit but please do a merge request if you 
prefer.

https://gitlab.com/debiants/laptop-detect/commit/ac832efccff4ca87a5ca01a7c3cfbb808fa386ba


Thanks again.

Bug#855324: pdfsam fails to start

[gregor herrmann]

On Sun, 19 Feb 2017 18:09:22 +0100, Philip Rinn wrote:

> On 19.02.2017 at 04:56, gregor herrmann wrote:
> > After this change, pdfsam starts for me and shows me an empty white
> > window (or grey-ish) with nothing in it.
> Uh, strange. So this seems not to be a general fix :(
> Gregor, could you try '0'?

With "0" I still get an empty greyish window and nothing more.
 

Cheers,
gregor


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


signature.asc
Description: Digital Signature

Bug#855143: unblock: wpa/2.5-2+v2.4-4stretch1

[Andrew Shadura]

On 19 Feb 2017 23:15, "Ivo De Decker"  wrote:

Control: tags -1 moreinfo

Hi Andrew,

On Tue, Feb 14, 2017 at 05:25:42PM +0100, Andrew Shadura wrote:
> Please unblock package wpa.

> This fix has to go through testing-proposed-updates.

Why? Is there any reason you can't just revert the version in unstable? That
way we don't have to push a new untested upload to stretch. If this upload
goes through unstable, there is a higher change that issues are detected
(and
fixed).


Because the version in unstable is a new upstream version, and the version
in testing is already a revert of a newer upstream version. I don't want to
confuse things even more.

The changes I propose are quite minimal, and the version we have in testing
has been there for quite some time already. I don't think there's a high
risk of introducing a regression with a bug fix.

-- 
Cheers,
Andrew

Bug#794856: fixed in opencv 3.0.0+dfsg-1~exp1

[Jochen Sprickerhof]

Hi Nobuhiro,

I've pushed a new OpenCV version excluding the Lenna images to delayed/5
and the vcs. Please tell me, if I should delay it further.

I will take care of the unblock request once it's true, as well.

Cheers Jochen


signature.asc
Description: PGP signature

Bug#816699: [Debichem-devel] Bug#816699: libga-dev and libarmci-mpi-dev: error when trying to install together

[Ivo De Decker]

Control: reassign -1 src:ga/5.3+dfsg-1

Hi,

On Fri, Mar 04, 2016 at 08:12:10PM +0100, Michael Banck wrote:
> Thanks for the report.  I guess it makes sense considering armci-mpi is
> a reimplementation oft the libarmci.a library in GA.
> 
> The mid-term plan is to build GA against libarmci-dev, I guess we
> should remove or rename the internal libarmci.a (plus its headers) from
> libga-dev.

Reassigning this to src:ga only, as it seems it needs to be fixed there
(please note that libga-dev was renamed to libglobalarrays-dev).

Assigning it to a single package will also start the auto-removal process for
this bug.

Cheers,

Ivo

Bug#850163: xpdf/poppler miscommunication

[Albert Astals Cid]

El diumenge, 19 de febrer de 2017, a les 23:00:53 CET, Andries E. Brouwer va 
escriure:
> If you prefer to give that program a different name, let us call it xyzpdf.
> So, the situation is that there is a widely used program called xyzpdf.
> This program uses libpoppler, that is, ldd shows
> 
> % ldd /usr/bin/xyzpdf
> ..
> libpoppler.so.58 => /usr/lib/x86_64-linux-gnu/libpoppler.so.58
> 
> Now this libpoppler as used by this program fails to work.
> Maybe libpoppler is not buggy, but it blindly uses invalid data.

You want libpoppler to be Clippy?

Sincerely, if you tell poppler the data is in /foo it'll read /foo, if the 
data is not htere, though luck, maybe you want to fix the widely used program 
called xyzpdf to not tell poppler that the data is in a location /foo that 
doesn't really hold the data

Best Regards,
  Albert

Bug#855538: youtube-dl: fails to download from zdf.de

[Holger Levsen]

Package: youtube-dl
Version: 2017.02.07-1
Severity: important

Dear Maintainer,

youtube-dl 2017.02.07-1 fails to download from https://zdf.de which is a major
German tv station which has a nice online archive, except that it doesn't 
support
downloads by itself.

I've verified that just replacing zdf.py from the 2017.02.17 upstream version
was sufficient to fix this issue:

sudo cp youtube-dl-2017.02.17/youtube_dl/extractor/zdf.py 
/usr/lib/python3/dist-packages/youtube_dl/extractor/zdf.py


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#854327: pulseaudio: default configuration depends on consolekit

[Michael Gilbert]

control: tag -1 - moreinfo

On Mon, Feb 6, 2017 at 8:07 AM, Felipe Sateler wrote:
> module-console-kit does nothing when systemd-logind is detected. If
> it's failing for you then you do not have systemd (or the -shim)
> installed and running.

You are correct, I do not have systemd installed on this system, but
then again it's kfreebsd so I can't.  However, the only thing standing
in the way of working pulseaudio on kfreebsd is this consolekit error,
which as I suggest below can be worked around in a couple ways.

>> To fix this, either the "load-module module-console-kit" line can be
>> commented in /etc/pulse/default.pa.  Or the consolekit package can be
>> installed, but there are a lot of setups where it's not needed or
>> wanted.
>
> But if you are not using the default settings, you can surely also
> modify pulseaudio's configuration?  Or are you suggesting we drop
> consolekit support entirely?

I should have worded that paragraph more clearly.  Those are just a
couple workarounds that can be used while the bug exists.  I have not
thought about how to fix the problem generally.

Best wishes,
Mike

Bug#851060: marked as pending

[Marcos Fouces]

Hello Axel

This compiler flag (-fno-strict-aliasing) is needed in libnids. You are 
right. I will revert this change in dsniff. I added the other flag (-g) 
in order to avoid creating an empty dbgsym package.


I cannot reproduce this bug in amd64 with the current libnids package 
version (1.21). In fact, dsniff works as expected with this testcase.


I built and installed libnids 1.24 (which fix another minor issue 
already solved in Ubuntu) with -fno-strict-aliasing. At least in amd64, 
dsniff still works as expected and i did not noticed any difference.


If the current maintainer of libnids (CC'ed) gives me permission, i can 
import the package to pkg-security team repo, upload my work and 
maintain (or co-maintain) it by now. This makes sense as dsniff seems to 
be the only reverse dependence of libnids.


I believe that in pkg-security team there are some people with access to 
armhf machines so testing should not be an issue. Unfortunately, i can 
do it myself.


Greetings,

Marcos



El 17/02/17 a las 00:41, Axel Beckert escribió:

Hi Marcos,

Marcos Fouces wrote:

+dsniff (2.4b1+debian-24) UNRELEASED; urgency=medium
+
+  * Add -fno-strict-aliasing compiler flag in order to fix
+  TCP reassemble in some architectures as armhf.
+  Thanks to guent...@unix-ag.uni-kl.de (Closes: #851060)
+  * Add -g flag to compiler.

So it does not need those compiler flags in libnids but in dsniff?

Have you tested it on armhf?

Because I tried recompiling libnids with these flags and noticed no
difference. :-/

(But then again I could even reproduce the reported issue on amd64, so
I'm not 100% sure if I actually reproduced it correctly.)

Regards, Axel

Bug#855536: xrdp: Xorg fails to start with pam_mkhomedir

[Tim Fischer]

Package: xrdp
Version: 0.9.1-4
Severity: normal

Dear Maintainer,
when using xrdp with pam_mkhomedir to create users home directory
when they log in first, xrdp fails to start a Xorg-Session.
The reason for this (including possibles solution) is described on 
https://github.com/neutrinolabs/xrdp/issues/350
auth_start_session() should be called before Xorg is forked.
Maybe the following is resolving the bug:

--- xrdp-0.9.1.orig/sesman/session.c
+++ xrdp-0.9.1/sesman/session.c
@@ -540,6 +540,7 @@ session_start_fork(tbus data, tui8 type,
.
 g_waitpid(bsdsespid);
 #endif
+auth_start_session(data, display);
 wmpid = g_fork(); /* parent becomes X,
  child forks wm, and waits, todo */
 if (wmpid == -1)
@@ -548,7 +549,6 @@ session_start_fork(tbus data, tui8 type,
 else if (wmpid == 0)
 {
 wait_for_xserver(display);
-auth_start_session(data, display);
 pampid = g_fork(); /* parent waits, todo
   child becomes wm */
 if (pampid == -1)



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

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

Versions of packages xrdp depends on:
ii  adduser  3.115
ii  init-system-helpers  1.47
ii  libc62.24-9
ii  libfuse2 2.9.7-1
ii  libjpeg62-turbo  1:1.5.1-2
ii  libopus0 1.2~alpha2-1
ii  libpam0g 1.1.8-3.5
ii  libssl1.11.1.0d-2
ii  libx11-6 2:1.6.4-3
ii  libxfixes3   1:5.0.3-1
ii  libxrandr2   2:1.5.1-1
ii  lsb-base 9.20161125
ii  ssl-cert 1.0.38

Versions of packages xrdp recommends:
ii  fuse  2.9.7-1
ii  xorgxrdp  0.9.1-4

Versions of packages xrdp suggests:
pn  guacamole  

Versions of packages xorgxrdp depends on:
ii  libc6  2.24-9
pn  xorg-input-abi-24  
ii  xserver-xorg-core [xorg-video-abi-23]  2:1.19.1-4

Versions of packages xorgxrdp recommends:
ii  xorg  1:7.7+18

Versions of packages xrdp is related to:
pn  vnc-server   
pn  xserver-xorg-legacy  

-- no debconf information

Bug#855143: unblock: wpa/2.5-2+v2.4-4stretch1

[Ivo De Decker]

Control: tags -1 moreinfo

Hi Andrew,

On Tue, Feb 14, 2017 at 05:25:42PM +0100, Andrew Shadura wrote:
> Please unblock package wpa.

> This fix has to go through testing-proposed-updates.

Why? Is there any reason you can't just revert the version in unstable? That
way we don't have to push a new untested upload to stretch. If this upload
goes through unstable, there is a higher change that issues are detected (and
fixed).

Cheers,

Ivo

Bug#855445: unblock: kwin/4:5.8.5-2

[Ivo De Decker]

Hi,

On Sat, Feb 18, 2017 at 11:41:56AM +0100, Maximiliano Curia wrote:
> On 2016-11-23 I uploaded kwin 5.8.4-1 to be included in stretch, but I didn't 
> notice that it was blocked by two unreproducible "rc" bugs that should have 
> been downgraded.

I unblocked kwin/4:5.8.4-1.

Cheers,

Ivo

Bug#854849: Pending fixes for bugs in the golang-github-mattn-go-sqlite3 package

[pkg-go-maintainers]

tag 854849 + pending
thanks

Some bugs in the golang-github-mattn-go-sqlite3 package are closed in
revision 6b12265985334d09d9ee7b5460541953262b521c in branch ' 
debian/jessie-backports' by Martín Ferrari

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-mattn-go-sqlite3.git/commit/?id=6b12265

Commit message:

Backport commit b76c610 from release 1.2.0 to fix an RC bug. Closes: #854849

Bug#850163: xpdf/poppler miscommunication

[Andries E. Brouwer]

If you prefer to give that program a different name, let us call it xyzpdf.
So, the situation is that there is a widely used program called xyzpdf.
This program uses libpoppler, that is, ldd shows

% ldd /usr/bin/xyzpdf
...
libpoppler.so.58 => /usr/lib/x86_64-linux-gnu/libpoppler.so.58

Now this libpoppler as used by this program fails to work.
Maybe libpoppler is not buggy, but it blindly uses invalid data.
A very simple fix would make it slightly more robust, and make many
open source users happy.

I propose to change

>> const char *dataRoot = popplerDataDir ? popplerDataDir : POPPLER_DATADIR;

into

>> const char *dataRoot = (popplerDataDir && *popplerDataDir) ? popplerDataDir
>> : POPPLER_DATADIR;

Does that have any disadvantages?

Andries


On Sun, Feb 19, 2017 at 10:35:17PM +0100, Albert Astals Cid wrote:

> This is not a bug in poppler, it does what we intented it to do.
> 
> xpdf doesn't use poppler.
> 
> If you have a xpdf that is using poppler someone is giving you something that 
> they call xpdf but it is not really xpdf.
> 
> Please don't contact the poppler project about bugs in xpdf since it has 
> nothing to do with us.
> 
> Best Regards,
>   Albert
> 
> El diumenge, 19 de febrer de 2017, a les 20:16:13 CET, Andries E. Brouwer va 
> escriure:
> > Masanori Goto reports (Debian bug #850163):
> > "Syntax Error: Missing language pack for 'Adobe-Japan1' mapping"
> > 
> > I see the same problem. A silly workaround is adding links
> > 
> >/cMap -> /usr/share/poppler/cMap
> >/cidToUnicode -> /usr/share/poppler/cidToUnicode
> >/nameToUnicode -> /usr/share/poppler/nameToUnicode
> >/unicodeMap -> /usr/share/poppler/unicodeMap
> > 
> > With these links in place his example file displays well,
> > and no error messages are given.
> > 
> > What happens is that xpdf calls poppler, and poppler needs
> > to find appropriate cMap, cidToUnicode, nameToUnicode, unicodeMap
> > files and directories. The poppler code that I am looking at says
> > 
> > (poppler/GlobalParams.cc line 671)
> > 
> > const char *dataRoot = popplerDataDir ? popplerDataDir : POPPLER_DATADIR;
> > 
> > and the files mentioned are searched for in %s/cMap etc, where %s is
> > substituted by dataRoot. But the constructor of GlobalParams is called
> > with an empty string "", and %s/cMap becomes /cMap, which is why
> > creating these links solves the problem.
> > 
> > I suggest that this be fixed both in xpdf and in poppler.
> > 
> > The poppler fix might be to change the above line into
> > 
> > const char *dataRoot = (popplerDataDir && *popplerDataDir) ? popplerDataDir
> > : POPPLER_DATADIR;
> > 
> > The fixed poppler works together with the current xpdf and all is well.

Bug#855117: vlc: Please disable OpenGL ES 1 support

[Sebastian Ramacher]

On 2017-02-19 22:43:31, Matthias Heinz wrote:
> Dear Mateusz,
> 
> I'm a bit confused here, maybe you can clearify this for me.
> 
> Your patch is against 2.2.4-14, so I guess that this change should've gone 
> into 2.2.4-14. But when I view the Debian changelog of my installed vlc 
> package, I only see the "Updated to ffmpeg 2.8.11" line, not your change.
> 
> Is this intentional?

The change is pending in the experimental branch and will only take effect once
we start development of buster. (As it was asked for in the original bug
report.)

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature

Bug#855117: vlc: Please disable OpenGL ES 1 support

[Matthias Heinz]

Dear Mateusz,

I'm a bit confused here, maybe you can clearify this for me.

Your patch is against 2.2.4-14, so I guess that this change should've gone 
into 2.2.4-14. But when I view the Debian changelog of my installed vlc 
package, I only see the "Updated to ffmpeg 2.8.11" line, not your change.

Is this intentional?


Best regards
Matthias

Bug#830207: Next try

[Rolf Leggewie]

Hello and good morning!   

On 19.02.2017 19:45, David Rabel wrote:
> dpkg-source emits a warning concerning the fiels that dh-clean deletes,
> e.g.:
>
> dpkg-source: warning: ignoring deletion of file missing, use
> --include-removal to override
>
> Is this a problem?

No, that's just informational.

On 19.02.2017 19:29, David Rabel wrote:
> Good morning,
>
> On 19.02.2017 00:48, Rolf Leggewie wrote:
>>> What you actually say is: IF we leave it as it is, the worst case is
>>> that the software could be public domain.
>> No.  The software has whatever license it has.[...]
> I meant leave it as it is "upstream".
> In my opinion the software is DFSG-compliant in any way. If the
> copyright holder is Osmo or Team audio-recorder or the software is
> public domain.

Part of the work as maintainer and especially when doing an ITP is to
verify the code is indeed DFSG-free.  Personally, I'd have trouble with
ambiguity in the form of "Well, I can't really be certain if the
software is licensed as GPL, LGPL or public domain but since all those
are DFSG-free it should be OK".  One should clarify what the license is
and release the ITP only afterwards.

> There are source files without copyright notice. Do we have to add
> that? For example the header files under src/ . 

Publishing something without claiming copyright automatically makes it
public domain.  So, unless Person A publishes file X with a copyright
notice and person B republishes it, stripping the copyright notice,
those files do not usually have copyright.  It's OK to assume that files
for which we cannot find a copyright claim to be copyright-free (until
we are made aware of the contrary, that is).

> I think you are wrong here. intltoolize is not run by autoreconf.

That's what I read during my research about dh-autoreconf (not
autoreconf). It's entirely possible that I am mistaken.  As I said, my
changes were untested.  Does the package still compile?

By the way, why do you remove the autogenerated files in the first place
when upstream apparently is keen to ship them and it creates a "problem"
for you in having to recreate them?  This is usually only necessary if
those autogenerated files are old and do not support newer platforms. 
That's when you need to autoreconf.  Otherwise, it's unnecessary but it
does have the benefit of future-proofing the package somewhat.

>> The Depends and Build-Depends lines look surprisingly long.[...]
> I copied both Build-Depends and Depends from the upstream control file.
> I'm not too familiar with ${misc:Depends} and ${shlibs:Depends} . Maybe
> you would like to fix this?

Not sure if this is even wrong.  It just struck me as odd.

I have not compiled your package yet.  You could strip the additional
packages from Depends, build the package and inspect the resulting deb
file with "dpkg --info $path-to-deb-file" and if the dropped
dependencies are still listed then listing them explicitly in
debian/control wasn't necessary.  If they are no longer there, I'd
install the package, run the binary and unless I run into problems I'd
assume the dependencies weren't actually really necessary.

You can read more about ${misc:Depends} and ${shlibs:Depends} in "man 7
debhelper" under the heading "Automatic generation of miscellaneous
dependencies."

Regards

Rolf

Bug#850163: xpdf/poppler miscommunication

[Albert Astals Cid]

This is not a bug in poppler, it does what we intented it to do.

xpdf doesn't use poppler.

If you have a xpdf that is using poppler someone is giving you something that 
they call xpdf but it is not really xpdf.

Please don't contact the poppler project about bugs in xpdf since it has 
nothing to do with us.

Best Regards,
  Albert

El diumenge, 19 de febrer de 2017, a les 20:16:13 CET, Andries E. Brouwer va 
escriure:
> Masanori Goto reports (Debian bug #850163):
> "Syntax Error: Missing language pack for 'Adobe-Japan1' mapping"
> 
> I see the same problem. A silly workaround is adding links
> 
>/cMap -> /usr/share/poppler/cMap
>/cidToUnicode -> /usr/share/poppler/cidToUnicode
>/nameToUnicode -> /usr/share/poppler/nameToUnicode
>/unicodeMap -> /usr/share/poppler/unicodeMap
> 
> With these links in place his example file displays well,
> and no error messages are given.
> 
> What happens is that xpdf calls poppler, and poppler needs
> to find appropriate cMap, cidToUnicode, nameToUnicode, unicodeMap
> files and directories. The poppler code that I am looking at says
> 
> (poppler/GlobalParams.cc line 671)
> 
> const char *dataRoot = popplerDataDir ? popplerDataDir : POPPLER_DATADIR;
> 
> and the files mentioned are searched for in %s/cMap etc, where %s is
> substituted by dataRoot. The default POPPLER_DATADIR is /usr/share/poppler,
> and if this line was simplified to
> 
> const char *dataRoot = POPPLER_DATADIR;
> 
> then all would work. But the constructor of GlobalParams is called
> with an empty string "", and %s/cMap becomes /cMap, which is why
> creating these links solves the problem.
> 
> I suggest that this be fixed both in xpdf and in poppler.
> 
> The poppler fix might be to change the above line into
> 
> const char *dataRoot = (popplerDataDir && *popplerDataDir) ? popplerDataDir
> : POPPLER_DATADIR;
> 
> The fixed poppler works together with the current xpdf and all is well.
> 
> How come GlobalParams("") is called?
> The xpdf 3.04 source calls
>   globalParams = new GlobalParams(cfgFileName);
> where
>   static char cfgFileName[256] = "";
> 
> It appears that this xpdf call is entirely misguided:
> what poppler wants is a directory, a prefix, something like
> /usr/share/poppler, but cfgFileName is the name of the
> xpdfrc configuration file, the thing set by the -cfg option.
> 
> So, in the long run also xpdf needs to be fixed.
> 
> Andries

Bug#855535: python-numpy: Crash of gconf2 configuration

[Nicolas Patrois]

Package: python-numpy
Version: 1:1.12.0-2
Severity: normal

Dear Maintainer,

dpkg (via aptitude) refuses to configure gconf2, here is the error output:

Setting up gconf2 (3.2.6-4) ...
Traceback (most recent call last):
  File "/usr/sbin/gconf-schemas", line 8, in 
import sys,os,os.path,shutil,tempfile
  File "/usr/lib/python2.7/tempfile.py", line 32, in 
import io as _io
  File "/usr/lib/python2.7/dist-packages/io.py", line 72, in 
import numpy as N
  File "/usr/lib/python2.7/dist-packages/numpy/__init__.py", line 142, in 

from . import add_newdocs
  File "/usr/lib/python2.7/dist-packages/numpy/add_newdocs.py", line 13, in 

from numpy.lib import add_newdoc
  File "/usr/lib/python2.7/dist-packages/numpy/lib/__init__.py", line 8, in 

from .type_check import *
  File "/usr/lib/python2.7/dist-packages/numpy/lib/type_check.py", line 11, in 

import numpy.core.numeric as _nx
  File "/usr/lib/python2.7/dist-packages/numpy/core/__init__.py", line 24, in 

raise ImportError(msg)
ImportError: 
Importing the multiarray numpy extension module failed.  Most
likely you are trying to import a failed build of numpy.
If you're working with a numpy git repo, try `git clean -xdf` (removes all
files not under version control).  Otherwise reinstall numpy.

I tried to reinstall python-numpy but no way.

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

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

Versions of packages python-numpy depends on:
ii  libatlas3-base [liblapack.so.3]3.10.3-1+b1
ii  libblas3 [libblas.so.3]3.7.0-1
ii  libc6  2.24-9
ii  liblapack3 [liblapack.so.3]3.7.0-1
ii  libopenblas-base [liblapack.so.3]  0.2.19-2
ii  python 2.7.13-2
pn  python2.7:any  
pn  python:any 

python-numpy recommends no packages.

Versions of packages python-numpy suggests:
ii  gcc   4:6.3.0-1
ii  gfortran  4:6.3.0-1
ii  python-dev2.7.13-2
ii  python-nose   1.3.7-2
pn  python-numpy-dbg  
pn  python-numpy-doc  

-- no debconf information

Bug#855534: unblock: multiple packages, didn't make it to testing due to openssl1.1

[Sebastian Andrzej Siewior]

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

I hope it is okay, to open one bug instead of three:
- libdigidoc
  removed from testing [0] not sure why. Adrian Bunk NMUed it to to
  build with libssl1.0-dev

- h323plus
  got removed [1] due a RC bug in ptlib. ptlib is now in testing and
  later Adrian Bunk NMUed (h323plus) to build with libssl1.0-dev

- mosquitto-auth-plugin
  got removed [2] due two RC bugs (openssl related FTBFS and
  default-libmysqlclient-dev) and gut NMUed by Andreas Beckmann.

Those three look like openssl1.1 fallout and therefore I am kindly
asking you to unblock them.

unblock libdigidoc/3.10.1.1208+ds1-2.1
unblock h323plus/1.24.0~dfsg2-1.3
unblock mosquitto-auth-plugin/0.0.7-2.1

[0] https://tracker.debian.org/news/836300
[1] https://tracker.debian.org/news/787598
[2] https://tracker.debian.org/news/832504

Sebastian

Bug#854621: jessie-pu: package uwsgi/2.0.7-1

[Jonas Smedegaard]

Quoting Adam D. Barratt (2017-02-19 21:43:08)
> On Wed, 2017-02-08 at 20:10 +0100, Jonas Smedegaard wrote:
>> a FTBFS was discovered which affects uwsgi in stable (and only that): 
>> Bug#854535
>
> + * Add patch cherry-picked upstream to fix compilation with recent GCC.
>
> My understanding was that the change was in glibc, not gcc; is that
> incorrect?

Indeed it was glibc, not gcc.  Thanks for catching my mistake!


> Please go ahead.

Thanks.

I will now upload with changelog entry adjusted, targeted "jessie", and 
closing bug#854535 - but not mention nor close this bug#854621.  Hope 
that is correct procedure - if not please do correct me.


 - Jonas

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

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


signature.asc
Description: signature

Bug#855533: mate-dock-applet does not do anything

[Laszlo T.]

Package: mate-dock-applet
Version: 0.75-1
Severity: important

Dear Maintainer,

The mate-dock-applet does not do anything when I add it to the panel.

repro steps:
-create new panel
-add the dock applet to the panel
-run some applications

expected:

should show the running programs

Br,
Laszlo T.



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

Versions of packages mate-dock-applet depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.26.0-2
ii  gir1.2-gdkpixbuf-2.0 2.36.4-1
ii  gir1.2-glib-2.0  1.50.0-1
ii  gir1.2-gtk-3.0   3.22.7-2
ii  gir1.2-mate-panel1.16.0-2
ii  gir1.2-wnck-3.0  3.20.1-3
ii  libglib2.0-bin   2.50.2-2
ii  mate-panel   1.16.0-2
ii  python3  3.5.3-1
ii  python3-gi-cairo 3.22.0-2
ii  python3-pil  4.0.0-4
ii  python3-xdg  0.25-4

mate-dock-applet recommends no packages.

mate-dock-applet suggests no packages.

-- no debconf information

Bug#855532: perl-base: Regression with gnu_getopt and : in Getopt::Long 2.48

[Axel Beckert]

Package: perl-base,perl-modules-5.24
Version: perl/5.24.1-1
Severity: important
Control: affects -1 t-prot
Control: forwarded -1 https://rt.cpan.org/Ticket/Display.html?id=114999

Hi,

there seems to be a regression when using ":config gnu_getopt" together
with ":" in Getopt::Long between the version in Jessie
(2.42) and the version in Testing/Sid (2.48):

On Jessie:

$ perl -E'
   use Getopt::Long qw( :config gnu_getopt );
   say $Getopt::Long::VERSION;
   GetOptions(\my %opts, "c:20");
   say $opts{c} // "[undef]"
' -- -c
2.42
20

On Sid:

$ perl -E'
   use Getopt::Long qw( :config gnu_getopt );
   say $Getopt::Long::VERSION;
   GetOptions(\my %opts, "c:20");
   say $opts{c} // "[undef]"
' -- -c
2.48
[undef]

It seems to have been introduced in Getopt::Long 2.48 according to the
upstream bug report at https://rt.cpan.org/Ticket/Display.html?id=114999

This regression showed up at t-prot upstream (X-Debbugs-Cc'ed) and has
been discussed today on #debian-perl, too.

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

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

Versions of packages perl-base depends on:
ii  dpkg   1.18.22
ii  libc6  2.24-9

perl-base recommends no packages.

Versions of packages perl-base suggests:
ii  perl  5.24.1-1

-- no debconf information

Bug#855522: [Pkg-privacy-maintainers] Bug#855522: torbrowser-launcher: torbrowser won't start because of apparmor

[Julien Aubin]

Hi,

I added this line and yup, it works.

Added the line just after the other owner lines (Debian config file is
vastly different from the one on GitHub).

Rgds

Bug#854535: uwsgi: dpkg-buildpackage fails due to open with O_TMPFILE

[Jonas Smedegaard]

Quoting Jonas Smedegaard (2017-02-12 21:30:32)
> Hi Nobuhiro,
> 
> Quoting Nobuhiro Iwamatsu (2017-02-09 05:09:39)
> >>> This error is caused by updated libc6.
> >>> The changelog in libc6(2.19-18+deb8u6) says as follows.
> >>>
> >>> - Fix open and openat functions with O_TMPFILE.  Closes: #832521.
> >>>
> >>> I found a fix to this issue in upstream.
> >>>
> >>> https://github.com/unbit/uwsgi/commit/f6e5db93d8344d7f09ee5304394136d6f5cd7a38
> >>
> >> Thanks a lot both for reporting this and locating upstream fix for 
> >> it.
> >>
> >> This was fixed in Debian with the release of 2.0.10-1.  Closing 
> >> accordingly.
> >>
> >>  - Jonas
> >
> > Thanks for your work, but we want to fix this bug with *stable*.
> > Could you fix this bug and upload to stable as 2.0.7-1+deb8u1?
> 
> I tried - before closing - to follow the procedure to get a fix to 
> stable.  But seems the bugreport I filed about that got lost.
> 
> I don't have time to look into it now - please go ahead, anyone.

Ah, my attempt at following procedure _did_ succeed, and now had a bit 
of progress: See bug#854621.

I will act on this.

 - Jonas

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

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


signature.asc
Description: signature

Bug#855531: debhelper: include common options in all manpages

[Michael Gilbert]

package: src:debhelper
severity: wishlist

Options that are common to all of the debhelper commands are only
documented in the debhelper.7 manpage.

It could be helpful and clearer to add that information also to the
manpages for individual commands, like dh_strip.1.

Best wishes,
Mike

Bug#853162: jessie-pu: package xmobar/0.22-1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Mon, 2017-01-30 at 13:45 +0200, Apollon Oikonomopoulos wrote:
> I would like to update xmobar in Jessie to fix #835547. As outlined in 
> #835547, xmobar has a weather plugin that uses NOAA's feed. NOAA 
> recently changed their feed URLs and xmobar has been updated upstream to 
> reflect that change.

Please go ahead.

Regards,

Adam