date:20190405

Bug#926499: ITP: ccls -- C/C++/ObjC language server

2019-04-05 Thread Shengjing Zhu

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: ccls
  Version : 0.20190314
  Upstream Author : Fangrui Song 
* URL : https://github.com/MaskRay/ccls/
* License : Apache-2.0
  Programming Lang: C++
  Description : C/C++/ObjC language server

  This originates from cquery, and supports:
  .
   * code completion (with both signature help and snippets)
   * definition/references, and other cross references
   * cross reference extensions:
 $ccls/call $ccls/inheritance $ccls/member $ccls/vars ...
   * formatting
   * hierarchies:
 call (caller/callee) hierarchy, inheritance (base/derived) hierarchy,
 member hierarchy
   * symbol rename
   * document symbols and approximate search of workspace symbol
   * hover information
   * diagnostics and code actions (clang FixIts)
   * semantic highlighting and preprocessor skipped regions
   * semantic navigation:
 $ccls/navigate

-BEGIN PGP SIGNATURE-

iQFEBAEBCgAuFiEE85F2DZP0aJKsSKyHONAPABi+PjUFAlyoPOQQHHpoc2pAZGVi
aWFuLm9yZwAKCRA40A8AGL4+Na3JB/9CAzBG28G3VWH3maO7tJaizrZfz5+p1uzc
yzflrp+iEDHymp2z4PhNGSnAXPMY1QkYG5+TrKbSHmisFhbfs3REpDTX3e1cJU9+
kCt1WysG4GMf4lN/6mHlfi4FuHnjj9BVOSmNbOEcxnPf9B5U2wYBo6xV/wFjzL6K
/OCV4z37rPzfZrKw5SKOjHUBDqoY8WRBzZx971D2Dj1zSwPM6PxJb5TdrgZII/Oa
sfuSeIsC64pXOotUIPUifmtSpmn0n4g6WpyGMuapkDlFe+eIUKzNivALi77WsdPG
mcPp0/FaHarADV7sS6HIpB2BbNV8AbhdSDt976tBic/do5g8fq3b
=ROSq
-END PGP SIGNATURE-

Bug#926430: fixed in camitk 4.1.2-3

2019-04-05 Thread Andreas Tille

On Fri, Apr 05, 2019 at 11:33:24PM +0200, Tobias Frost wrote:
> Hi Andreas,
> 
> thanks for the upload!
> Can you file an unblock request so that the package will migrate?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926435

It was even unblocked now. :-)
 

-- 
http://fam-tille.de

Bug#868483: cross-config: cross-config files missing for multiple architectures

2019-04-05 Thread Helmut Grohne

Control: severity -1 important
Control: tags -1 + patch

On Mon, Jul 24, 2017 at 05:07:28PM +0100, Wookey wrote:
> On 2017-07-16 00:01 +0200, John Paul Adrian Glaubitz wrote:
> > Either way, the list should be consistent or removed altogether.

Agreed.

> We have not tried to provide files for arches where we are not sure of
> the answers. The idea was that porters would provide info for their
> architectures, and thus get the details right. We could probably find
> out the answers for various arches with some effort. If you provide
> files I am happy to include them. I guess I could check by logging on
> to porter boxes and collecting suitable details.

There are a number of arch-specific cache variables, but also a number
that depend on kernel/libc. Given that all release archs are
Linux/glibc, the latter ones have been collected in
config/cross-config.cache despite being wrong for hurd-any, kfreebsd-any
and musl-linux-any.

I've set up crossqa.debian.net to deviate as little as possible from the
standard developer workflow (using sbuild) and that means using
dpkg-cross. Consequently, a lot (around 200) of packages FTCBFS for
mips64el, ppc64el and s390x, because they lack
ac_cv_func_malloc_0_nonnull=yes (which sits in the general
cross-config.cache). Failures due to really arch-specific values are
rare. The arch-specific sizeof caches are generally useless, because any
remotely recent autoconf doesn't need them any longer. We even fixed blt
to stop using them. At present I don't know a single package using them.

Therefore I suggest the following route:

For each "relevant" architecture (at least all release architectures),
create a config/cross-config.$ARCH containing at least:

. `dirname $ac_site_file`/cross-config.cache

For all existing per-arch cache files, ensure that this line is present
(e.g. amd64 misses it).

Doing just this solves a large fraction of the practical issues. The
attached patch shows how simply the change is.

Do you agree with the change?

Do you agree that it largely (but not entirely) solves the reported bug?

I think this should be fixed asap, ideally in buster. Do you agree with
bumping this bug to rcness?

Do you also agree with removing all ac_cv_sizeof_*? (At a later time)

Helmut
diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.alpha 
dpkg-cross-2.6.15/config/cross-config.alpha
--- dpkg-cross-2.6.15/config/cross-config.alpha 2015-01-22 20:16:37.0 
+0100
+++ dpkg-cross-2.6.15/config/cross-config.alpha 2019-04-06 07:18:42.0 
+0200
@@ -1,3 +1,4 @@
+. `dirname $ac_site_file`/cross-config.cache
 #
 # alpha specific configure variables
 #
diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.amd64 
dpkg-cross-2.6.15/config/cross-config.amd64
--- dpkg-cross-2.6.15/config/cross-config.amd64 2011-03-27 08:14:10.0 
+0200
+++ dpkg-cross-2.6.15/config/cross-config.amd64 2019-04-06 07:18:27.0 
+0200
@@ -1,3 +1,4 @@
+. `dirname $ac_site_file`/cross-config.cache
 #
 # amd64-specific configuration variables
 #
diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.hppa 
dpkg-cross-2.6.15/config/cross-config.hppa
--- dpkg-cross-2.6.15/config/cross-config.hppa  2011-03-27 08:14:10.0 
+0200
+++ dpkg-cross-2.6.15/config/cross-config.hppa  2019-04-06 07:19:17.0 
+0200
@@ -1,3 +1,4 @@
+. `dirname $ac_site_file`/cross-config.cache
 #
 # hppa specific configure variables
 #
diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.m68k 
dpkg-cross-2.6.15/config/cross-config.m68k
--- dpkg-cross-2.6.15/config/cross-config.m68k  2011-03-27 08:14:10.0 
+0200
+++ dpkg-cross-2.6.15/config/cross-config.m68k  2019-04-06 07:18:48.0 
+0200
@@ -1,3 +1,4 @@
+. `dirname $ac_site_file`/cross-config.cache
 #
 # m68k specific configure variables
 #
diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.mips64el 
dpkg-cross-2.6.15/config/cross-config.mips64el
--- dpkg-cross-2.6.15/config/cross-config.mips64el  1970-01-01 
01:00:00.0 +0100
+++ dpkg-cross-2.6.15/config/cross-config.mips64el  2019-04-06 
07:21:27.0 +0200
@@ -0,0 +1 @@
+. `dirname $ac_site_file`/cross-config.cache
diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.ppc64el 
dpkg-cross-2.6.15/config/cross-config.ppc64el
--- dpkg-cross-2.6.15/config/cross-config.ppc64el   1970-01-01 
01:00:00.0 +0100
+++ dpkg-cross-2.6.15/config/cross-config.ppc64el   2019-04-06 
07:19:31.0 +0200
@@ -0,0 +1 @@
+. `dirname $ac_site_file`/cross-config.cache
diff --minimal -Nru dpkg-cross-2.6.15/config/cross-config.s390x 
dpkg-cross-2.6.15/config/cross-config.s390x
--- dpkg-cross-2.6.15/config/cross-config.s390x 1970-01-01 01:00:00.0 
+0100
+++ dpkg-cross-2.6.15/config/cross-config.s390x 2019-04-06 07:19:27.0 
+0200
@@ -0,0 +1 @@
+. `dirname $ac_site_file`/cross-config.cache
diff --minimal -Nru dpkg-cross-2.6.15/debian/changelog 
dpkg-cross-2.6.15/debian/changelog
--- dpkg-cross-2.6.15/debian/changelog  2017-07-24

Bug#926498: blastem FTCBFS: builds for the wrong architecture

2019-04-05 Thread Helmut Grohne

Source: blastem
Version: 0.6.3-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

blastem fails to cross build from source, because it builds for the
build architecture. It does not pass any cross tools to make. The
easiest fix here is using dh_auto_build. Then the upstream Makefile hard
codes the build architecture pkg-config. It needs to be made
substitutable. The attached patch makes blastem cross buildable. Please
consider applying it.

Helmut
diff --minimal -Nru blastem-0.6.3/debian/changelog 
blastem-0.6.3/debian/changelog
--- blastem-0.6.3/debian/changelog  2019-03-10 02:10:42.0 +0100
+++ blastem-0.6.3/debian/changelog  2019-04-06 07:01:54.0 +0200
@@ -1,3 +1,12 @@
+blastem (0.6.3-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Let dh_auto_build pass cross tools to make.
++ cross.patch: Make pkg-config substitutable.
+
+ -- Helmut Grohne   Sat, 06 Apr 2019 07:01:54 +0200
+
 blastem (0.6.3-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru blastem-0.6.3/debian/patches/cross.patch 
blastem-0.6.3/debian/patches/cross.patch
--- blastem-0.6.3/debian/patches/cross.patch1970-01-01 01:00:00.0 
+0100
+++ blastem-0.6.3/debian/patches/cross.patch2019-04-06 07:01:51.0 
+0200
@@ -0,0 +1,36 @@
+--- blastem-0.6.3.orig/Makefile
 blastem-0.6.3/Makefile
+@@ -1,3 +1,4 @@
++PKG_CONFIG ?= pkg-config
+ ifndef OS
+ OS:=$(shell uname -s)
+ endif
+@@ -62,7 +63,7 @@
+ ifdef PORTABLE
+ ifdef USE_GLES
+ ifndef GLES_LIB
+-GLES_LIB:=$(shell pkg-config --libs glesv2)
++GLES_LIB:=$(shell $(PKG_CONFIG) --libs glesv2)
+ endif
+ LDFLAGS:=-lm $(GLES_LIB)
+ else
+@@ -78,7 +79,7 @@
+ CFLAGS+= -Isdl/include
+ LDFLAGS+= -Wl,-rpath='$$ORIGIN/lib' -Llib -lSDL2
+ ifndef USE_GLES
+-LDFLAGS+= $(shell pkg-config --libs gl)
++LDFLAGS+= $(shell $(PKG_CONFIG) --libs gl)
+ endif
+ endif #Darwin
+ 
+@@ -86,8 +87,8 @@
+ ifeq ($(MAKECMDGOALS),libblastem.so)
+ LDFLAGS:=-lm
+ else
+-CFLAGS:=$(shell pkg-config --cflags-only-I $(LIBS)) $(CFLAGS)
+-LDFLAGS:=-lm $(shell pkg-config --libs $(LIBS))
++CFLAGS:=$(shell $(PKG_CONFIG) --cflags-only-I $(LIBS)) $(CFLAGS)
++LDFLAGS:=-lm $(shell $(PKG_CONFIG) --libs $(LIBS))
+ endif #libblastem.so
+ 
+ ifeq ($(OS),Darwin)
diff --minimal -Nru blastem-0.6.3/debian/patches/series 
blastem-0.6.3/debian/patches/series
--- blastem-0.6.3/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ blastem-0.6.3/debian/patches/series 2019-04-06 07:00:56.0 +0200
@@ -0,0 +1 @@
+cross.patch
diff --minimal -Nru blastem-0.6.3/debian/rules blastem-0.6.3/debian/rules
--- blastem-0.6.3/debian/rules  2019-01-24 06:08:50.0 +0100
+++ blastem-0.6.3/debian/rules  2019-04-06 07:00:48.0 +0200
@@ -7,5 +7,5 @@
dh $@
 
 override_dh_auto_build:
-   make HOST_ZLIB=1 CONFIG_PATH=/etc/blastem \
+   dh_auto_build -- HOST_ZLIB=1 CONFIG_PATH=/etc/blastem \
DATA_PATH=/usr/share/games/blastem

Bug#926496: cassbeam FTCBFS: uses the wrong pkg-config

2019-04-05 Thread Helmut Grohne

Source: cassbeam
Version: 1.1-1
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

cassbeam fails to cross build from source, because its configure.in hard
codes the build architecture pkg-config. Things get much easier, once
you use pkg-config's autotools support macro. The attached patch
demonstrates that and makes cassbeam cross buildable. Please consider
applying it.

Helmut
--- cassbeam-1.1.orig/configure.in
+++ cassbeam-1.1/configure.in
@@ -11,32 +11,18 @@
 AC_PROG_CC
 AC_PROG_INSTALL
 
-AC_CHECK_PROG(GLIB_CONFIG, pkg-config, ok, NONE)
-
-if test "x$GLIB_CONFIG" != xNONE
-then
-	AC_MSG_CHECKING("for GLIB version")
-	glib_version=`pkg-config --version glib-2.0`
-	glib_flags=`pkg-config --cflags glib-2.0`
-	glib_libs=`pkg-config --libs glib-2.0`
-else
-	AC_MSG_ERROR("Could not find glib-config in PATH")
-fi
-
-AC_MSG_RESULT("$glib_version")
-
-dnl ADD CODE to check for version number
-
+dnl TODO: add the right version to check for
+PKG_CHECK_MODULES(GLIB,[glib-2.0 >= 0],,)
 
 dnl get rid of any duplicates in CFLAGS or LIBS
-for flag in ${glib_flags}
+for flag in $GLIB_CFLAGS
 do
 	if  echo "${CFLAGS}" | grep -v -- "$flag" > /dev/null
 	then
 		CFLAGS="${CFLAGS} $flag"
 	fi
 done
-for lib in ${glib_libs}
+for lib in $GLIB_LIBS
 do
 	if echo "${LIBS}" | grep -v -- "$lib" > /dev/null
 	then

Bug#926497: p910nd FTCBFS: does not pass cross tools to make

2019-04-05 Thread Helmut Grohne

Source: p910nd
Version: 0.97-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

p910nd fails to cross build from source, because it does not pass cross
tools to make and thus builds for the build architecture. The easiest
way of fixing that - using dh_auto_build - makes p910nd cross buildable.
Please consider applying the attached patch.

Helmut
diff --minimal -Nru p910nd-0.97/debian/changelog p910nd-0.97/debian/changelog
--- p910nd-0.97/debian/changelog2014-09-14 16:34:07.0 +0200
+++ p910nd-0.97/debian/changelog2019-04-06 06:55:02.0 +0200
@@ -1,3 +1,10 @@
+p910nd (0.97-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 06 Apr 2019 06:55:02 +0200
+
 p910nd (0.97-1) unstable; urgency=low
 
   * New upstream version
diff --minimal -Nru p910nd-0.97/debian/rules p910nd-0.97/debian/rules
--- p910nd-0.97/debian/rules2014-09-14 16:33:06.0 +0200
+++ p910nd-0.97/debian/rules2019-04-06 06:55:00.0 +0200
@@ -8,7 +8,7 @@
dh_auto_clean
 
 override_dh_auto_build:
-   $(MAKE) USE_WRAP=1 LOCKFILE_DIR=\"/var/lock/p910nd\"
+   dh_auto_build -- USE_WRAP=1 LOCKFILE_DIR=\"/var/lock/p910nd\"
# upstream don't provide changelog file, generate from p910nd.c header
head -107 p910nd.c | tail -89 | sed -e 's/ \*//g' > changelog

Bug#18567: Shouldn’t be wontfix

2019-04-05 Thread MK

I know this is a wontfix, but maybe this should be reconsidered in light of 
buster’s changes?
With the switch of su as referenced here: 
https://sources.debian.org/src/util-linux/2.33.1-0.1/debian/util-linux.NEWS , 
there is no reason why dpkg shouldn’t add /sbin and /usr/sbin to the back of 
the path, after any other user-defined path entries which would override it. 
Supposedly “dpkg ensures that the PATH is set to a reasonable value” but it’s 
certainly failing in this case. No harm is done- only benefit. With the new 
‘su’ as people get used to it, we’re going to see lots of failures. Failures 
that could incorrectly configure packages and lead to more bugs due to 
configuration issues. Bugs like this one ( 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926449 )

> Upgrading from 3.4.4 to 3.4.5-1, I see the following messages after a 'su'
> to root Preconfiguring packages ...
>     Can't exec "postconf": No such file or directory at
> /tmp/postfix.config.swGX60 line 220,  line 14. Can't exec
> "postconf": No such file or directory at /tmp/postfix.config.swGX60 line
> 284,  line 16. Can't exec "postconf": No such file or directory at
> /tmp/postfix.config.swGX60 line 386,  line 21.



Scott Kitterman’s comment when this bug was reported I think accurately points 
to this bug (thank you Scott)
“If there is a bug here, it's probably in dpkg.  I think that the postfix  
package is aligned to policy and Debian best practices.  See below.  Please  
review and consider if this should be reassigned.

Here's an extract from policy 6.1:

Programs called from maintainer scripts should not normally have a path 
prepended to them. Before installation is started, the package management 
system checks to see if the programs ldconfig, start-stop-daemon, and 
update-rc.d can be found via the PATH environment variable. Those programs, and 
any other program that one would expect to be in the PATH, should thus be 
invoked 
without an absolute pathname. Maintainer scripts should also not reset the 
PATH, though they might choose to modify it by prepending or appending 
package-specific directories. These considerations really apply to all shell 
scripts.

There is a related lintian [1] check which says, in part:

Programs called from maintainer scripts normally should not have a path 
prepended. dpkg ensures that the PATH is set to a reasonable value, and 
prepending a path may prevent the local administrator from using a replacement 
version of a command for some local reason.

[1] https://lintian.debian.org/tags/command-with-path-in-maintainer-script.html

Bug#926449: postfix: preconfig does not ensure /sbin and /usr/sbin is in $PATH

2019-04-05 Thread MK

Seems referenced here. Frustrating but thanks for pointing me in the right 
direction
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=18567 

On Friday, April 5, 2019, 2:27 PM, Scott Kitterman  wrote:

On Friday, April 05, 2019 09:46:09 AM Michael Krieger wrote:
> Package: postfix
> Version: 3.4.5-1
> Severity: normal
> 
> Upgrading from 3.4.4 to 3.4.5-1, I see the following messages after a 'su'
> to root Preconfiguring packages ...
>     Can't exec "postconf": No such file or directory at
> /tmp/postfix.config.swGX60 line 220,  line 14. Can't exec
> "postconf": No such file or directory at /tmp/postfix.config.swGX60 line
> 284,  line 16. Can't exec "postconf": No such file or directory at
> /tmp/postfix.config.swGX60 line 386,  line 21.
> 
> It most certainly relates to the news article at
>  
> https://sources.debian.org/src/util-linux/2.33.1-0.1/debian/util-linux.NEWS
> / however, that is no reason for the postfix preconfig to fail (and who
> knows what change I missed there)
> 
> The script should err on the side of caution, knowing full-well where
> postconf is and that it is required, and add /usr/sbin and /sbin to the
> PATH in the scripts. Right now it (potentially) fails to do what it is
> supposed to do with a $PATH it can't control.

If there is a bug here, it's probably in dpkg.  I think that the postfix 
package is aligned to policy and Debian best practices.  See below.  Please 
review and consider if this should be reassigned.

Here's an extract from policy 6.1:

Programs called from maintainer scripts should not normally have a path 
prepended to them. Before installation is started, the package management 
system checks to see if the programs ldconfig, start-stop-daemon, and update-
rc.d can be found via the PATH environment variable. Those programs, and any 
other program that one would expect to be in the PATH, should thus be invoked 
without an absolute pathname. Maintainer scripts should also not reset the 
PATH, though they might choose to modify it by prepending or appending 
package-specific directories. These considerations really apply to all shell 
scripts.

There is a related lintian [1] check which says, in part:

Programs called from maintainer scripts normally should not have a path 
prepended. dpkg ensures that the PATH is set to a reasonable value, and 
prepending a path may prevent the local administrator from using a replacement 
version of a command for some local reason.

Scott K

[1] https://lintian.debian.org/tags/command-with-path-in-maintainer-script.html

Bug#925288: ITP: diff-so-fancy -- Good-lookin' diffs. Actually… nah… The best-lookin' diffs.

2019-04-05 Thread Osamu Aoki

Hi,

On Fri, Mar 22, 2019 at 01:46:33PM +, Mo Zhou wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Mo Zhou 
> 
> * Package name: diff-so-fancy
>   Version : 1.2.5
>   Upstream Author :
> * URL : https://github.com/so-fancy/diff-so-fancy
> * License : MIT 
>   Programming Lang: Perl
>   Description : Good-lookin' diffs. Actually… nah… The best-lookin' diffs.
> 
> This is a pager that colorizes patch like the way github renders a diff.
>   
> It makes my life very much easier as I heavily depend on git and diff;
> and should definitely enter the archive as I cannot find any alternative.

Yah, finding single character diff in long line is pain.

As for the pin pointing diff feature, an old curses program imediff2 was
updated to support wdiff like display and interactively swichable diff
display style by me recently.  (Also now it support merging with diff2
and diff3 case renamed old package to imediff.

(It was originally supposed to python2 to python3 updates but ...)

Osamu

Bug#926181: want automatic forwarding of patches to the upstream branch

2019-04-05 Thread Osamu Aoki

Hi,

On Mon, Apr 01, 2019 at 06:05:28PM +0100, Ian Jackson wrote:
> Osamu Aoki writes ("Bug#926181: want automatic forwarding of patches to the 
> upstream branch"):
> > Package: dgit
> > Version: 8.4
> > Severity: wishlist
> 
> Hi.  Thanks for your message.  I'm always interested in hearing what
> people want so please don't be discouraged by what I say next:

No problem ;-)  This is more like a food-for-thought bug.
I am not particular about the use of dgit-maint-merge.

> > In case of the Debian maintainer is the same person as the upstream
> > maintainer, I would like to see automatic support to the operation
> > described in dgit-maint-merge(7).  This is nice alternative to native
> > package workflow and nice upstream history.
> 
> I am struggling to understand how you think this could work
> automatically.  The biggest problem is that the data model in
> dgit-maint-merge(7) does not necessarily break the Debian delta into
> individual commits.

As a starter, I wrote a very broad vague wishlist.  At the same time, I
understand this is a hard problem if this needs to be automatic for all
the use case.

> Also a problem is that I don't think there is an easy way of
> discovering what the upstream is like and how to submit patches there.

Let's make this simple by limiting the functionality of this wishlist
utility tool, say "dgit cherries", to function for a simple case.  Let
me try with following ascii art.

human actions
X release
~ commit
+ merge

actions by "dgit cherries" on upstream
= commit (simple cherry picking)
: commit (dropping debian/* part with modified message)
. no-commit no change

First, You are upstream and released upstream package 1.0

1.0
upstream X

Then, packaged 1.0-1 *without* any change to upstream source.

1.0
upstream X
  \
debian   --+~~~X
   1.0-1

Then, patched upstream part and released as 1.0-2, 1.0-3 as bug fix
version by changing upstream part on debian branch.

1.0
upstream X
  \
debian   --+~~~X~~X~~X
   1.0-1  1.0-2  1.0-3

Then, found major bug and locally created 1.0-4 by committing to debian
branch.  This is very convenient ;-)

1.0
upstream O
  \
debian   --+~~~X~~X~~X~~X
   1.0-1  1.0-2  1.0-3  1.0-4

You can verify your idea for major change worked with 1.0-4.

You decide not to release it as Debian revision 1.0-4 but as a new
upstream source 1.1.  Here, I think "dgit cherries" may be useful.

When HEAD is at 1.0-4 on debian branch, let's run "dgit cherries".

"dgit cherries" can find previous merge point "+".

Let "dgit cherries" cherry pick and apply cherry to the parent of merge
point on upstream branch.  In this example, "O" is the point.

If change in debian branch commit doesn't include debian/* files, cherry
is applied with the original commit message and move on to next commit
on debian branch.

If change includes debian/* files, that part of cherry should be dropped
and remaining cherry should be applied with the commit message modified
to indicate change to debian/* files are not included.  Then move on to
next commit on debian branch.

If change is only debian/* files, ignore that cherry and move on to next
commit on debian branch.

After all these are done, we should have

1.0
upstream O==.==:==...===.=.=.==...==.=.
  \
debian   --+~~~X~~X~~X~~X
   1.0-1  1.0-2  1.0-3  1.0-4

This is the end point of  "dgit cherries" in my POV.

Now, You being the upstream do whatever (rebase to merge and clean up
original change history or add more original changes.).  Then release
upstream 1.1.  (This usually involves changing some part of upstream
code manually to bump its version from 1.0 to 1.1.  Also, you may wish
to update some documentation etc in upstream source now.)

1.01.1
upstream O==.=~:==-~~-~==.=.=.=~-.=.O
  \
debian   --+~~~X~~X~~X~~X
   1.0-1  1.0-2  1.0-3  1.0-4

Then you package 1.1-1 by merging upstream to debian as follows.

1.01.1
upstream O==.==:==...===.=.=.==...==.=.O
  \ \
debian   --+~~~X~~X~~X~~X+~~~X
   1.0-1  1.0-2  1.0-3  1.0-41.1-1

> (As an aside: I don't think any of this depends on whether the Debian
> maintainer is the same person as the upstream with a different hat
> on.)

Well, I hope above use case explanation assumes clean -1 packaging.  I
thought that can be done only when DM is upstream.  Of course DM can
package with patch for -1. Let's

Bug#536459: zsh: Ctrl-ARROW gives ';5A' escape sequence instead of moving by word

2019-04-05 Thread Witold Baryluk

Package: zsh
Version: 5.7.1-1
Followup-For: Bug #536459

In previous update, I did forget to provide value of TERM

In Terminator

$ echo $TERM
xterm-256color
$

both when running locally and over ssh.

Again, thanks! I really hope it is fixed after ~10 years ;D


-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version Architecture Description
+++-==-===--===
ii  curl   7.64.0-1amd64command line tool 
for transferring data with URL syntax
ii  docker-engine  17.05.0~ce-0~debian-stretch amd64Docker: the 
open-source application container engine
ii  systemd241-1   amd64system and service 
manager
ii  udev   241-1   amd64/dev/ and hotplug 
management daemon

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh depends on:
ii  libc6   2.28-8
ii  libcap2 1:2.25-2
ii  libtinfo6   6.1+20181013-2
ii  zsh-common  5.7.1-1

Versions of packages zsh recommends:
ii  libc6 2.28-8
ii  libncursesw6  6.1+20181013-2
ii  libpcre3  2:8.39-12

Versions of packages zsh suggests:
pn  zsh-doc  

-- no debconf information

Bug#536459: zsh: Ctrl-ARROW gives ';5A' escape sequence instead of moving by word

2019-04-05 Thread Witold Baryluk

Package: zsh
Version: 5.7.1-1
Followup-For: Bug #536459

I also find it annoying in zsh.

I did found, that adding this lines to ~/.zshrc makes it work:

bindkey "^[[1;5C" forward-word
bindkey "^[[1;5D" backward-word


(I did discover it on 
https://unix.stackexchange.com/questions/58870/ctrl-left-right-arrow-keys-issue)

I am using Terminator. This happens both locally and over ssh in
Terminator. It is annoying because I do have dozens of computers and
servers, and I prefer not to edit any configs like ~/.zshrc and only use
default settings, as this is much easier. So I often find myself just
stopping using zsh and sticking to bash that works just fine with
Ctrl+Arrow with my terminator and ssh.


Regards!

Thanks,
Witold



-- Package-specific info:

Packages which provide vendor completions:

Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version Architecture Description
+++-==-===--===
ii  curl   7.64.0-1amd64command line tool 
for transferring data with URL syntax
ii  docker-engine  17.05.0~ce-0~debian-stretch amd64Docker: the 
open-source application container engine
ii  systemd241-1   amd64system and service 
manager
ii  udev   241-1   amd64/dev/ and hotplug 
management daemon

dpkg-query: no path found matching pattern /usr/share/zsh/vendor-functions/


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

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

Versions of packages zsh depends on:
ii  libc6   2.28-8
ii  libcap2 1:2.25-2
ii  libtinfo6   6.1+20181013-2
ii  zsh-common  5.7.1-1

Versions of packages zsh recommends:
ii  libc6 2.28-8
ii  libncursesw6  6.1+20181013-2
ii  libpcre3  2:8.39-12

Versions of packages zsh suggests:
pn  zsh-doc  

-- no debconf information

Bug#926495: unblock: gnome-gmail/2.6-1

2019-04-05 Thread David Steele

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

Please unblock package gnome-gmail

This version contains a minimal change that resolves the serious bug against
Buster - #926487.

A recent Gmail update is unable to properly process upload MIME-encoded
messages that do not include a message body.The latest gnome-gmail
resolves the
issue by taking more effort for messages to be well formed - to always
include
a message body, and to drop the "To:" header if otherwise blank.

Debdiff attached.


unblock gnome-gmail/2.6-1

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

diff -Nru gnome-gmail-2.5.6/debian/changelog gnome-gmail-2.6/debian/changelog
--- gnome-gmail-2.5.6/debian/changelog  2018-10-09 13:38:04.0 -0400
+++ gnome-gmail-2.6/debian/changelog2019-04-05 21:18:19.0 -0400
@@ -1,3 +1,9 @@
+gnome-gmail (2.6-1) unstable; urgency=medium
+
+  * Fix Gmail bug - bad message if no body (Closes: 926487).
+
+ -- David Steele   Fri, 05 Apr 2019 21:18:19 -0400
+
 gnome-gmail (2.5.6-1) unstable; urgency=medium
 
   * Fix bug in setup.py distutils.
diff -Nru gnome-gmail-2.5.6/gnome-gmail.appdata.xml.in 
gnome-gmail-2.6/gnome-gmail.appdata.xml.in
--- gnome-gmail-2.5.6/gnome-gmail.appdata.xml.in2018-10-09 
11:22:57.0 -0400
+++ gnome-gmail-2.6/gnome-gmail.appdata.xml.in  2019-04-05 21:22:56.0 
-0400
@@ -51,6 +51,7 @@
 
 
 
+
 
 
 
diff -Nru gnome-gmail-2.5.6/gnomegmail.py gnome-gmail-2.6/gnomegmail.py
--- gnome-gmail-2.5.6/gnomegmail.py 2018-10-09 11:22:57.0 -0400
+++ gnome-gmail-2.6/gnomegmail.py   2019-04-05 21:22:56.0 -0400
@@ -569,7 +569,8 @@
 
 qsdict = urllib.parse.parse_qs(query_string)
 
-qsdict['to'] = [address]
+if address:
+qsdict['to'] = [address]
 
 if 'attachment' in qsdict:
 qsdict['attach'] = qsdict['attachment']
@@ -587,6 +588,9 @@
 if 'su' in qsdict:
 outdict["subject"] = outdict["su"]
 
+if "body" not in qsdict:
+outdict["body"] = " "
+
 return(outdict)
 
 def simple_gmail_url(self):
diff -Nru gnome-gmail-2.5.6/setup.py gnome-gmail-2.6/setup.py
--- gnome-gmail-2.5.6/setup.py  2018-10-09 11:22:57.0 -0400
+++ gnome-gmail-2.6/setup.py2019-04-05 21:22:56.0 -0400
@@ -129,7 +129,7 @@
 
 setup(
 name='gnome-gmail',
-version='2.5.6',
+version='2.6',
 description='support for Gmail as the preferred GNOME email application',
 author='David Steele',
 author_email='dste...@gmail.com',
diff -Nru gnome-gmail-2.5.6/test/test_body.py gnome-gmail-2.6/test/test_body.py
--- gnome-gmail-2.5.6/test/test_body.py 2018-10-09 11:22:57.0 -0400
+++ gnome-gmail-2.6/test/test_body.py   2019-04-05 21:22:56.0 -0400
@@ -107,8 +107,8 @@
 
 
 @pytest.mark.parametrize("mailto, needs_api", (
-("mailto:joe;, False),
-("mailto:joe?subject=hi;, False),
+("mailto:joe;, True),
+("mailto:joe?subject=hi;, True),
 ("mailto:joe?body=%20;, True),
 ("mailto:joe?attach=file;, True),
 ("mailto:joe?attachment=file;, True),

Bug#926475: Uploads

2019-04-05 Thread Bruno Kleinert

Hi Stefan,

that's great! I offer reviews and will sponsor uploads :)

Cheers - Bruno


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

Bug#900912: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint

2019-04-05 Thread Matthias Klose

On 01.04.19 17:24, Samuel Thibault wrote:
> Samuel Thibault, le lun. 01 avril 2019 15:54:17 +0200, a ecrit:
>> Vincent Privat, le ven. 24 août 2018 18:33:56 +0200, a ecrit:
>>> Patching openjdk with your try/catch proposal and making the ATK wrapper a
>>> Recommends sounds a good idea.
>>>
>>> Don't wait for openjdk guys for an answer: they simply don't care anymore 
>>> with
>>> desktop technologies.
>>
>> FI, I plan to upload the attached NMU, which does it:
> 
> But currently the 11.0.3+4-3 version is blocked in unstable, and notably
> due to a regression on libreoffice, so I'm not sure what to do for now.

please don't NMU. In the past the atk patches broke the non-atk use case way too
often.  Maybe you want to upload to a PPA or to experimental to give this a
little bit more testing.

Matthias

Bug#926494: ITP: gitbrute -- brute-force a git commit hash

2019-04-05 Thread Adam Borowski

Package: wnpp
Severity: wishlist
Owner: Adam Borowski 

* Package name: gitbrute
  Version : -
  Upstream Author : Brad Fitzpatrick
* URL : https://github.com/bradfitz/gitbrute/
* License : Apache 2.0
  Programming Lang: Go
  Description : brute-force a git commit hash
 gitbrute brute-forces a pair of author+committer timestamps such that the
 resulting git commit has your desired prefix.

Bug#926493: irssi-plugin-otr: NEWS file not installed

2019-04-05 Thread gregor herrmann

Package: irssi-plugin-otr
Version: 1.2.0-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

It seems that the helpful NEWS file from [0] doesn't get installed in
the binary package; at least I neither see it in
/usr/share/doc/irssi-plugin-otr/ nor with apt-file.

My guess from looking into dh_installchangelogs(1) is that it should
be named debian/irssi-plugin-otr.NEWS in the source package to get it
installed as /usr/share/doc/irssi-plugin-otr/NEWS.Debian in the
binary package.

Thanks for writing up these instructions in the first place!


Cheers,
gregor


[0] https://salsa.debian.org/rhonda/irssi/raw/master/debian/NEWS.Debian

- -- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'unstable-debug'), (500, 
'oldoldstable'), (500, 'experimental'), (500, 'testing'), (500, 'stable'), 
(500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.19.0-3-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C, LC_CTYPE=de_AT.utf8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages irssi-plugin-otr depends on:
ii  irssi1.2.0-2
ii  libc62.28-8
ii  libgcrypt20  1.8.4-5
ii  libotr5  4.1.1-3

irssi-plugin-otr recommends no packages.

irssi-plugin-otr suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEE0eExbpOnYKgQTYX6uzpoAYZJqgYFAlyn9KNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEQx
RTEzMTZFOTNBNzYwQTgxMDREODVGQUJCM0E2ODAxODY0OUFBMDYACgkQuzpoAYZJ
qgYVJg//cu4y8OdUypt7uzTrN9uZBBgsoTWZXWhpHmlQgoSIBLuNh7piM2GhpRL0
oNjF+Y33xUEN0WYQ9wjjsWQ7NfZy84JisP2T9E4xvMZwDqlw4a/BNzFAc96l899g
AKq9LlULRMbyXE12ViuPdDYqG2nSG7VR3GXRef6jNWJGLQ/gDufCHrKSsdcp0f3z
dbExQiF1mF4ZIChqoVCG+wX9eXloZVRjiMJFKeeClW/22IXVDqjAKKHEY0WruYtC
GXIXNuxgnTLQXfM+vDoTIZK/nlAvhy8vqVhqYMQO0FOF6S8trzc8sfMdNrMG6lA1
15JwAx1QWV9fi7qpr1GjF5TL3H1OttdhuTSU23gvp4yDdFAm+/YbM03wFMMIE2lU
CryECqLC/WbbaXDfFOsVWO5lgruaCkgN9O2KEm62LfVW+H26JoFz7zRXr7glpjsw
jNDkHlDvGSkqV/jeD2+pGsj11GklKVEayD7A/Pvtwe+a3jxaOUUTbb3sJA6pSBcu
ZfAka/QgDo6KWGOyY69XTJqmpo2XiSmD+d5D+2H2iJV8KvydXmMaCguJZHMqI7mB
45gtE7gWqReTzFVdjuwxe48D81HmpiebdPtT/P1W5Htl90B6bfN00Z5JbzW0U3cO
PzZHxA4r1LIzZ1UZ5Vi9wtLKb7G5qyMeg6GRGBkmCEKex71HMck=
=RApW
-END PGP SIGNATURE-

Bug#926492: RM: xmlroff -- RoQA; package is orphaned since 2600days, popcon of 35

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Please remove the package xmlroff because:
 - it is orphaned since 2600days
 - the popcon is 35
 - DAC found no deps

 Thanks
 best regards,
 Stefan

Bug#926491: RM: skyeye -- RoQA; RoQA, unmainted, low popcon, dead upstream, alternatives exists

2019-04-05 Thread Tobias Frost

Package: ftp.debian.org
Severity: normal

skyeye's last upload of a new upstream version is from 2009, it has a
low popcorn and there are other alternatives available. I think it is
time to retire it.

-- 
tobi

Bug#926490: setupcon.1: Use the correct font macros in the manual

2019-04-05 Thread Bjarni Ingi Gislason

Package: console-setup
Version: 1.191
Severity: minor
Tags: patch

Dear Maintainer,

:63 (macro IR): only 1 argument, but more are expected
:101 (macro BR): only 1 argument, but more are expected
:105 (macro BR): only 1 argument, but more are expected
:112 (macro BR): only 1 argument, but more are expected
:130 (macro BR): only 1 argument, but more are expected
:148 (macro IR): only 1 argument, but more are expected

Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z

  [ "test-groff" is a developmental version of "groff" ]



  The patch:

--- setupcon.1  2019-04-05 23:29:23.0 +
+++ setupcon.1.new  2019-04-05 23:31:11.0 +
@@ -60,7 +60,7 @@ and in order to configure the console fo
 .SH OPTIONS
 
 .TP
-.IR VARIANT
+.I VARIANT
 Specifies which configuration file to use.  With no variant,
 the configuration files of
 .B setupcon
@@ -98,18 +98,18 @@ active).
 Setup the terminal only, do not setup the keyboard or the font.
 
 .TP
-.BR --current-tty
+.B --current-tty
 Setup the only the current virtual terminal.
 
 .TP
-.BR --force
+.B --force
 Do not check whether we are on the console.  Notice that you can be
 forced to hard-reboot your computer if you run
 .B setupcon
 with this option and the screen is controlled by a X server.
 
 .TP
-.BR --save
+.B --save
 This option can be useful if you want to use
 .B setupcon
 early in the boot process while
@@ -127,7 +127,7 @@ early in the boot process, then you shou
 after every change of the console configuration.
 
 .TP
-.BR --save-only
+.B --save-only
 The same as
 .IR --save ,
 but does not setup anything.  This option can be useful if you want to
@@ -145,7 +145,7 @@ For use by initrd builders.  Do not conf
 the directory
 .I DIR
 everything necessary in order to configure the console.  The file
-.IR DIR/morefiles
+.I DIR/morefiles
 lists all binaries the initrd builder has to install in the initrd
 image.  All other files in
 .I DIR

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

Kernel: Linux 4.19.28-2 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages console-setup depends on:
ii  console-setup-linux 1.191
ii  debconf 1.5.71
ii  keyboard-configuration  1.191
ii  xkb-data2.26-2

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales   2.28-8
ii  lsb-base  10.2019031300

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.71
ii  liblocale-gettext-perl  1.07-3+b4

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.56+nmu1
ii  initscripts 2.93-8
ii  kbd 2.0.4-4
ii  keyboard-configuration  1.191

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
ii  console-common0.7.90
ii  console-data  2:1.12-6
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.4-4
pn  systemd   

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#926488: RM: xlbiff -- RoQA; package orphaned since nearly 4000 days, no upstream sources available, popcon of 18

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Please remove the package xlbiff because:
 - the debian package is orphaned since nearly 4000days
 - upstream website is down, no sources available
 - popcon is at 18

 Thanks,
 best regards,
 Stefan

Bug#926489: ckbcomp.1: Use correct font macros and number of arguments in the manual

2019-04-05 Thread Bjarni Ingi Gislason

Package: console-setup
Version: 1.191
Severity: minor
Tags: patch

Dear Maintainer,

  Warnings from test-groff:

:90 (macro IR): only 1 argument, but more are expected
:92 (macro IR): only 1 argument, but more are expected
:100 (macro BI): only 1 argument, but more are expected
:104 (macro BI): only 1 argument, but more are expected

Output is from: test-groff -b -e -mandoc -T utf8 -rF0 -t -w w -z

  [ "test-groff" is a developmental version of "groff" ]

  Patch:

--- ckbcomp.1   2019-04-05 19:23:12.0 +
+++ ckbcomp.1.new   2019-04-05 19:20:15.0 +
@@ -87,9 +87,9 @@ multiple times.  If a file can not be fo
 directories, it will be searched also in some other standard
 locations, such as
 .IR /etc/console-setup/ckb ,
-.IR /usr/share/X11/xkb
+.I /usr/share/X11/xkb
 and
-.IR /etc/X11/xkb
+.IR /etc/X11/xkb .
 
 .TP
 .BI -v\  level
@@ -97,11 +97,11 @@ Set level of detail for listing.  The ar
 .I level
 must be a number from 1 to 10.
 .TP
-.BI -compact
+.B -compact
 Generate a compact keymap with at most two xkb groups and two levels
 in each or only one xkb-group and up to four levels.
 .TP
-.BI -freebsd
+.B -freebsd
 Generate a keymap for FreeBSD.
 .TP
 .BR -backspace\  [ bs | del ]




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

Kernel: Linux 4.19.28-2 (SMP w/2 CPU cores)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), 
LANGUAGE=is_IS.iso88591 (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages console-setup depends on:
ii  console-setup-linux 1.191
ii  debconf 1.5.71
ii  keyboard-configuration  1.191
ii  xkb-data2.26-2

console-setup recommends no packages.

Versions of packages console-setup suggests:
ii  locales   2.28-8
ii  lsb-base  10.2019031300

Versions of packages keyboard-configuration depends on:
ii  debconf 1.5.71
ii  liblocale-gettext-perl  1.07-3+b4

Versions of packages console-setup-linux depends on:
ii  init-system-helpers 1.56+nmu1
ii  initscripts 2.93-8
ii  kbd 2.0.4-4
ii  keyboard-configuration  1.191

console-setup-linux suggests no packages.

Versions of packages console-setup is related to:
ii  console-common0.7.90
ii  console-data  2:1.12-6
pn  console-tools 
pn  gnome-control-center  
ii  kbd   2.0.4-4
pn  systemd   

-- debconf information excluded

-- 
Bjarni I. Gislason

Bug#925564: congress: FTBFS: ValueError: Fernet key must be 32 url-safe base64-encoded bytes.

2019-04-05 Thread Tobias Frost

Control: tags -1 unreproducible
Control: severity -1 important

Hallo Lucas,

on the Salzburg BSP I've tried to reproduce the bug, hoever I could not
reproduce it in a clean pbuilder buster chroot. Maybe this was an
intermediate problem?

-- 
tob

Bug#926487: GNOME Gmail incompatibilty with Gmail

2019-04-05 Thread David Steele

Package: gnome-gmail
Version: 2.5.6-1
Severity: Serious

If GNOME Gmail is used to "Send To..." on a file via Nautilus, the
resulting uploaded message is not rendered properly - not showing the
Subject or attached file. It is not possible to send the message that
is opened.

This happens because the service does not properly handle mime message
with no body. The fix would be to always add a body to the message.

As a result of this issue, a core capability of the package is broken.
Setting to Serious.

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

Bug#926486: RM: zapping -- RoQA; Orphaned in Debian since 2140days, popcon < 100, last upstream release was 2006

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Please remove the package zapping for the following reasons:
 - package orphaned in Debian since 2140days
 - popcon < 100
 - last upstream release was 2006

Bug#926062: qbitorrent crashes, blames QNetworkAccessM

2019-04-05 Thread Tobias Frost

Control: serverity -1 important
Control: tags -1 unreproducible moreinfo

Hi shirish,

I tried to reproduce your SEGV, but here qbittorrent seems to work
fine. Do you have additional informations about how to trigger the
SEGV, like what you are doing to trigger it or like?

Cheers from the Salzburg BSP,
tobi

Bug#926386: free(): double free detected in tcache 2

2019-04-05 Thread Tobias Frost

I tried to reproduce this bug but unfortunatly I could not on my
machine... Is there any special with your machine?

Bug#926485: RM: ytalk -- RoQA; Package is orphaned since > 1500 days, latest upstream release is from 2005, Popcon is < 250

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Please remove the package ytalk due to following reasons:
 - Package is orphaned since > 1500 days
 - lates upstream release is from 2005
 - Popcon is < 250

 Thanks
 best regards,
 Stefan

Bug#925950: patches no longer apply for gcc-8 and gcc-9

2019-04-05 Thread Dima Kogan

Tobias Frost  writes:

> Control: tags -1 pending
>
>> My key situation should be resolved with the next keyring update, but
>> this will take a few weeks probably. If it's useful to you, you
>> should push the new package into the archive.
>
> I've uploaded your package to DELAYED/10. Let me know if I should
> accelerate it or if I should remove it from the DELAYED queue.

Hi Tobias. Helmut (Cc-ed) is the main user of these packages, so he's
the person to ask. I suspect that it doesn't matter a whole lot.

Thanks for the upload.

dima

Bug#895381: rpc.gssd: WARNING: handle_gssd_upcall: failed to find uid in upcall string 'mech=krb5'

2019-04-05 Thread Micha Lenk

On Tue, Apr 10, 2018 at 10:12:35PM +0200, Sergio Gelato wrote:
> One of my systems has logged
> rpc.gssd[1168]: WARNING: handle_gssd_upcall: failed to find uid in upcall 
> string 'mech=krb5'
> 
> This turns out to be a known problem, covered extensively in
> https://bugzilla.redhat.com/show_bug.cgi?id=1419280
> 
> Please cherry-pick upstream commit 5ae8be8b6af1a0fdf2fa26051a05d4c04d028849
> (and possibly 0a4f5e4daccdeba767b9ef36e30efbd7fd9a76d8 as well, although
> I'd rate that at a lower severity).

I tried to build the package with the commits you suggested applied. The
commits applied cleanly, but then the package failed to build from source.
The build failure is unrelated, because it also fails without the commits
applied (see Debian bug #926483).  But that stopped me from continuing any
further investigations.

The suggested changes to apply the commits where pushed to my cloned fork of
the nfs-utils package on salsa.d.o here:
https://salsa.debian.org/micha/nfs-utils/commits/fix_proposal_debian_bug_895381
As I couldn't validate them without a build, I left them there.

Cheers,
Micha

Bug#924835: adacontrol: FTBFS: test tfw_gpr.txt failed

2019-04-05 Thread Nicolas Boulenguez

Package: src:adacontrol
Followup-For: Bug #924835
Control: severity 924835  minor

1.20r7-2 disables all build time tests.

Bug#926103: libifd-cyberjack6: driver breaks with pcsc-lite versions >= 1.8.21

2019-04-05 Thread Tobias Frost

On Mon, 1 Apr 2019 12:40:37 +0200 Frank Neuber 
wrote:
> this bug is fixed in SP13.
> The version in the debian repo is SP9 and quite old.

Hi Frank,

as you are the maintainer of the package: Do you think you can backport
the fix, so that the package can be part of buster?

(It would be great if you could update it then with the latest upstream
versions for buster+1)

Thanks for your contributions!

-- 
tobi

Bug#926430: fixed in camitk 4.1.2-3

2019-04-05 Thread Tobias Frost

Hi Andreas,

thanks for the upload!
Can you file an unblock request so that the package will migrate?

Bug#926484: unblock: gpsd/3.17-6

2019-04-05 Thread Bernd Zeimetz

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

Hi release-team,

please unblock package gpsd.

The applied diff was discussed with the release team and we've
decided its the best way to fix the json related fixes.
Diff between 3.17-5 und 3.17-6 is attached to this mail.


  * [0a8e4e18] Pull json fixes from upstream to fix a stack-based
buffer overflow, which may allow remote attackers to execute
arbitrary code on embedded platforms via traffic on Port
2947/TCP or crafted JSON inputs.
CVE-2018-17937 / Closes: #925327
The update also fixes several other json parser bugs.
- ECMA-404 says JSON \u must have 4 hex digits
- Allow for \u escapes with fewer than 4 digits.
- Fail on bad escape string.


unblock gpsd/3.17-6


Thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
diff --git a/debian/changelog b/debian/changelog
index ebd29108b..16bb69795 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,19 @@
+gpsd (3.17-6) unstable; urgency=medium
+
+  * [0a8e4e18] Pull json fixes from upstream to fix a stack-based
+buffer overflow, which may allow remote attackers to execute
+arbitrary code on embedded platforms via traffic on Port
+2947/TCP or crafted JSON inputs.
+CVE-2018-17937 / Closes: #925327
+The update also fixes several other json parser bugs.
+- ECMA-404 says JSON \u must have 4 hex digits
+- Allow for \u escapes with fewer than 4 digits.
+- Fail on bad escape string.
+  * [71020f4f] Update git-buildpackage config to build from the
+buster branch.
+
+ -- Bernd Zeimetz   Fri, 05 Apr 2019 23:31:30 +0200
+
 gpsd (3.17-5) unstable; urgency=medium
 
   * [fd1e83f9] Add pkg-config as Build-Dependency.
diff --git a/debian/gbp.conf b/debian/gbp.conf
index 1529a93db..151b02d6b 100644
--- a/debian/gbp.conf
+++ b/debian/gbp.conf
@@ -4,7 +4,7 @@
 # the default branch for upstream sources:
 #upstream-branch = upstream
 # the default branch for the debian patch:
-#debian-branch = master
+debian-branch = buster
 # the default tag formats used:
 #upstream-tag = upstream/%(version)s
 #debian-tag = debian/%(version)s
diff --git a/debian/patches/json-cve-fix b/debian/patches/json-cve-fix
new file mode 100644
index 0..e81237bee
--- /dev/null
+++ b/debian/patches/json-cve-fix
@@ -0,0 +1,170 @@
+--- a/json.c
 b/json.c
+@@ -30,7 +30,7 @@ will match the right spec against the ac
+ recognize the JSON "null" value.  Secondly, arrays may not have
+ character values as elements (this limitation could be easily removed
+ if required). Third, all elements of an array must be of the same
+-type.
++type.  Fourth, it can not handle NaN's in doubles (Issue 53150).
+ 
+There are separate entry points for beginning a parse of either
+ JSON object or a JSON array. JSON "float" quantities are actually
+@@ -59,7 +59,7 @@ reusable module; search for "microjson".
+ 
+ PERMISSIONS
+This file is Copyright (c) 2010 by the GPSD project
+-   BSD terms apply: see the file COPYING in the distribution root for details.
++   SPDX-License-Identifier: BSD-2-clause
+ 
+ ***/
+ #include 
+@@ -188,7 +188,7 @@ static int json_internal_read_object(con
+ char *lptr;
+ 
+ if (end != NULL)
+-  *end = NULL;/* give it a well-defined value on parse 
failure */
++  *end = NULL;/* give it a well-defined value on parse failure */
+ 
+ /* stuff fields with defaults in case they're omitted in the JSON input */
+ for (cursor = attrs; cursor->attribute != NULL; cursor++)
+@@ -294,7 +294,8 @@ static int json_internal_read_object(con
+   }
+   if (cursor->attribute == NULL) {
+   json_debug_trace((1,
+-"Unknown attribute name '%s' (attributes 
begin with '%s').\n",
++"Unknown attribute name '%s'"
++  " (attributes begin with '%s').\n",
+ attrbuf, attrs->attribute));
+   /* don't update end here, leave at attribute start */
+   return JSON_ERR_BADATTR;
+@@ -374,6 +375,12 @@ static int json_internal_read_object(con
+   if (pval == NULL)
+   /* don't update end here, leave at value start */
+   return JSON_ERR_NULLPTR;
++  else if (pval > valbuf + JSON_VAL_MAX - 1
++ || pval > valbuf + maxlen) {
++  json_debug_trace((1, "String value too long.\n"));
++  /* don't update end here, leave at value start */
++  return JSON_ERR_STRLONG;/*  */
++  }
+   switch (*cp) {
+   case 'b':
+   *pval++ =

Bug#926483: FTBFS: utils/blkmapd/device-discovery.c:156: undefined reference to `major'

2019-04-05 Thread Micha Lenk

Source: nfs-utils
Version: 1:1.3.4-2.4
Severity: serious

The package fails to build from source (actually current Git branch
debian/sid, but that has no changes that I could imagine causing this)
in a clean sid chroot on amd64:

/usr/bin/ld: device-discovery.o: in function `bl_add_disk':
/home/micha/nfs-utils/utils/blkmapd/device-discovery.c:156: undefined
reference to `major'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:506: blkmapd] Error 1
make[3]: Leaving directory '/home/micha/nfs-utils/utils/blkmapd'
make[2]: *** [Makefile:451: all-recursive] Error 1
make[2]: Leaving directory '/home/micha/nfs-utils/utils'
make[1]: *** [Makefile:475: all-recursive] Error 1
make[1]: Leaving directory '/home/micha/nfs-utils'
make: *** [debian/rules:28: build-stamp] Error 2

See the attached build log for further details.

Regards,
Micha
Script started on 2019-04-05 21:38:08+00:00 [TERM="xterm-256color" 
TTY="/dev/pts/6" COLUMNS="159" LINES="20"]
]0;(sid_amd64-dchroot)micha@barriere: 
~/nfs-utils(sid_amd64-dchroot)micha@barriere:~/nfs-utils$ dpkg-buildpackage 
-uc -us
[1mdpkg-buildpackage: [0m[32minfo[0m: source package nfs-utils
[1mdpkg-buildpackage: [0m[32minfo[0m: source version 1:1.3.4-3
[1mdpkg-buildpackage: [0m[32minfo[0m: source distribution UNRELEASED
[1mdpkg-buildpackage: [0m[32minfo[0m: source changed by Laurent Bigonville 

[1mdpkg-buildpackage: [0m[32minfo[0m: host architecture amd64
[1;35m dpkg-source --before-build .
[0m[1mdpkg-source: [0m[32minfo[0m: using options from 
nfs-utils/debian/source/options: 
--extend-diff-ignore=(^|/)(config.sub|config.guess|Makefile.in|configure|config.log|aclocal.m4|ltmain.sh|aclocal/libtool.m4)$
[1mdpkg-source: [0m[32minfo[0m: using patch list from debian/patches/series
[1mdpkg-source: [0m[32minfo[0m: applying 21-no-more-var-run.patch
[1mdpkg-source: [0m[32minfo[0m: applying 01-sm-notify-in-sbin.patch
[1mdpkg-source: [0m[32minfo[0m: applying 03-handle-mtab-symlink.patch
[1mdpkg-source: [0m[32minfo[0m: applying 17-multiarch-kerberos-paths.patch
[1mdpkg-source: [0m[32minfo[0m: applying 19-iscsiadm-path.patch
[1mdpkg-source: [0m[32minfo[0m: applying 24-systemd-pipefs_in_run.patch
[1mdpkg-source: [0m[32minfo[0m: applying 25-systemd-daemon-paths.patch
[1mdpkg-source: [0m[32minfo[0m: applying 
27-systemd-enable-with-systemctl-statd.patch
[1mdpkg-source: [0m[32minfo[0m: applying 
unbreak-blkmapd-rpc_pipefs-run.patch
[1mdpkg-source: [0m[32minfo[0m: applying unbreak-gssd-rpc_pipefs-run.patch
[1mdpkg-source: [0m[32minfo[0m: applying 28-nfs-utils_env-location.patch
[1mdpkg-source: [0m[32minfo[0m: applying 29-start-statd-fd-9.patch
[1mdpkg-source: [0m[32minfo[0m: applying 
0001-rpc.c-added-include-file-so-UINT16_MAX-is-defined.patch
[1mdpkg-source: [0m[32minfo[0m: applying 30-remove-whitespace-service.patch
[1;35m fakeroot debian/rules clean
[0mdh_testdir
dh_testroot
rm -f build-stamp
rm -rf /home/micha/nfs-utils/debian/tmp
[ ! -f Makefile ] || /usr/bin/make distclean
dh_autoreconf_clean
dh_clean
[1;35m dpkg-source -b .
[0m[1mdpkg-source: [0m[32minfo[0m: using options from 
nfs-utils/debian/source/options: 
--extend-diff-ignore=(^|/)(config.sub|config.guess|Makefile.in|configure|config.log|aclocal.m4|ltmain.sh|aclocal/libtool.m4)$
[1mdpkg-source: [0m[32minfo[0m: using source format '3.0 (quilt)'
[1mdpkg-source: [0m[32minfo[0m: building nfs-utils using existing 
./nfs-utils_1.3.4.orig.tar.xz
[1mdpkg-source: [0m[32minfo[0m: using patch list from debian/patches/series
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file compile, use 
--include-removal to override
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file missing, use 
--include-removal to override
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file depcomp, use 
--include-removal to override
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file install-sh, 
use --include-removal to override
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file test-driver, 
use --include-removal to override
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file 
support/include/config.h.in, use --include-removal to override
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file 
aclocal/lt~obsolete.m4, use --include-removal to override
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file 
aclocal/ltversion.m4, use --include-removal to override
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file 
aclocal/ltoptions.m4, use --include-removal to override
[1mdpkg-source: [0m[1;33mwarning[0m: ignoring deletion of file 
aclocal/ltsugar.m4, use --include-removal to override
[1mdpkg-source: [0m[32minfo[0m: building nfs-utils in 
nfs-utils_1.3.4-3.debian.tar.xz
[1mdpkg-source: [0m[32minfo[0m: building nfs-utils in nfs-utils_1.3.4-3.dsc
[1;35m debian/rules build
[0mdh_testdir
dh_autoreconf

Bug#919486: osinfo-db: diff for NMU version 0.20181120-1.1

2019-04-05 Thread Chris Hofstaedtler

Control: tags 919486 - pending

Hi,

* Guido Günther  [190405 22:04]:
> If we had stable links for CD images (3813797) this would be different
> but I did not get around to look into this yet so help there would be
> appreciated and would make this fixable for real.
> 
> For now it would be cool if you could cancel the NMU.

Right.
Cancelled it :)

Cheers,
Chris

Bug#926482: gitlab: CVE-2018-5158 CVE-2019-10109 CVE-2019-10110 CVE-2019-10111 CVE-2019-10113 CVE-2019-10115 CVE-2019-10116 CVE-2019-10640

2019-04-05 Thread Salvatore Bonaccorso

Source: gitlab
Version: 11.8.3-1
Severity: grave
Tags: security upstream
Justification: user security hole

Hi,

The following vulnerabilities were published for gitlab, fixed
upstream in the 11.9.4, 11.8.6, and 11.7.10 releases.

CVE-2018-5158[0]:
| The PDF viewer does not sufficiently sanitize PostScript calculator
| functions, allowing malicious JavaScript to be injected through a
| crafted PDF file. This JavaScript can then be run with the permissions
| of the PDF viewer by its worker. This vulnerability affects Firefox
| ESR  52.8 and Firefox  60.


CVE-2019-10109[1]:
EXIF geolocation data not stripped from uploaded images

CVE-2019-10110[2]:
Improper authorization control "move issue"

CVE-2019-10111[3]:
Persistent XSS at merge request resolve conflicts

CVE-2019-10113[4]:
DoS potential on project languages page

CVE-2019-10115[5]:
Guest users of private projects have access to releases

CVE-2019-10116[6]:
Related branches visible in issues for guests

CVE-2019-10640[7]:
DoS potential for regex in CI/CD refs

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-5158
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-5158
[1] https://security-tracker.debian.org/tracker/CVE-2019-10109
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10109
[2] https://security-tracker.debian.org/tracker/CVE-2019-10110
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10110
[3] https://security-tracker.debian.org/tracker/CVE-2019-10111
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10111
[4] https://security-tracker.debian.org/tracker/CVE-2019-10113
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10113
[5] https://security-tracker.debian.org/tracker/CVE-2019-10115
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10115
[6] https://security-tracker.debian.org/tracker/CVE-2019-10116
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10116
[7] https://security-tracker.debian.org/tracker/CVE-2019-10640
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10640
[8] 
https://about.gitlab.com/2019/04/01/security-release-gitlab-11-dot-9-dot-4-released/

Regards,
Salvatore

Bug#926351: python3-tesserocr: segfaults on import

2019-04-05 Thread Bernhard Übelacker

Dear Maintainer,
just tried to help triaging this issue.

Seems this is "expected" behaviour with LC_ALL not
set to "C". In the end it leads to this upstream bug:

https://github.com/sirfz/tesserocr/issues/165

It contains some workarounds and more information.

Kind regards,
Bernhard

# Buster amd64 qemu VM 2019-04-05


apt update
apt dist-upgrade


apt install dpkg-dev devscripts systemd-coredump gdb python3-tesserocr 
python3-dbg python3-tesserocr-dbgsym libtesseract4-dbgsym



mkdir /home/benutzer/source/libtesseract4/orig -p
cd/home/benutzer/source/libtesseract4/orig
apt source libtesseract4
cd

mkdir /home/benutzer/source/libc6/orig -p
cd/home/benutzer/source/libc6/orig
apt source libc6
cd

mkdir /home/benutzer/source/python3-tesserocr/orig -p
cd/home/benutzer/source/python3-tesserocr/orig
apt source python3-tesserocr
cd





#


benutzer@debian:~$ echo $LANG
de_DE.UTF-8
benutzer@debian:~$ python3
Python 3.7.3rc1 (default, Mar 13 2019, 11:01:15) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tesserocr
!strcmp(locale, "C"):Error:Assert failed:in file baseapi.cpp, line 209
Speicherzugriffsfehler (Speicherabzug geschrieben)



benutzer@debian:~$ LC_ALL=C python3
Python 3.7.3rc1 (default, Mar 13 2019, 11:01:15) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tesserocr
>>> quit()



benutzer@debian:~$ python3
Python 3.7.3rc1 (default, Mar 13 2019, 11:01:15) 
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'C')
'C'
>>> import tesserocr
>>> quit()





#


dmesg
[  212.933342] python3[14744]: segfault at 0 ip 7fcfe93279d2 sp 
7ffc7c947e20 error 6 in libtesseract.so.4.0.0[7fcfe913e000+1fa000]
[  212.933352] Code: 15 03 00 31 c0 48 8d 3d 5c d9 31 00 e8 57 fe ff ff eb b7 
0f 1f 44 00 00 b8 0a 00 00 00 66 89 03 e9 7c ff ff ff e8 9e da e1 ff  04 25 
00 00 00 00 00 00 00 00 0f 0b 90 48 8b 36 48 8b 3f e9 65


root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Fri 2019-04-05 22:44:14 CEST  14744  1000  1000  11 present   /usr/bin/python3.7


root@debian:~# coredumpctl gdb 14744
   PID: 14744 (python3)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Fri 2019-04-05 22:44:14 CEST (1min 49s ago)
  Command Line: python3
Executable: /usr/bin/python3.7
 Control Group: /user.slice/user-1000.slice/session-3.scope
  Unit: session-3.scope
 Slice: user-1000.slice
   Session: 3
 Owner UID: 1000 (benutzer)
   Boot ID: 3194a9e501f04eda9f2e24fc8030724b
Machine ID: 32f43b50ac8c4b21941bc0b02f8e7811
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.python3.1000.3194a9e501f04eda9f2e24fc8030724b.14744.155449705400.lz4
   Message: Process 14744 (python3) of user 1000 dumped core.

Stack trace of thread 14744:
#0  0x7fcfe93279d2 
_ZNK7ERRCODE5errorEPKc16TessErrorLogCodeS1_z (libtesseract.so.4)
#1  0x7fcfe915f59e _ZN9tesseract11TessBaseAPIC1Ev 
(libtesseract.so.4)
#2  0x7fcfe96ac680 n/a 
(tesserocr.cpython-37m-x86_64-linux-gnu.so)
#3  0x7fcfea43c30a n/a (ld-linux-x86-64.so.2)
#4  0x7fcfea43c406 n/a (ld-linux-x86-64.so.2)
#5  0x7fcfea440263 n/a (ld-linux-x86-64.so.2)
#6  0x7fcfe9f52eaf _dl_catch_exception (libc.so.6)
#7  0x7fcfea43fb4a n/a (ld-linux-x86-64.so.2)
#8  0x7fcfea3c5256 n/a (libdl.so.2)
#9  0x7fcfe9f52eaf _dl_catch_exception (libc.so.6)
#10 0x7fcfe9f52f3f _dl_catch_error (libc.so.6)
#11 0x7fcfea3c5975 n/a (libdl.so.2)
#12 0x7fcfea3c52e6 dlopen (libdl.so.2)
#13 0x00626fdc _PyImport_FindSharedFuncptr (python3.7)
#14 0x006329b8 _PyImport_LoadDynamicModuleWithSpec 
(python3.7)
#15 0x00632d8b n/a (python3.7)
#16 0x005c8a37 _PyMethodDef_RawFastCallDict (python3.7)
#17 0x005c8bfa PyCFunction_Call (python3.7)
#18 0x00544aa5 _PyEval_EvalFrameDefault (python3.7)
#19 0x0053cfb2 _PyEval_EvalCodeWithName (python3.7)
#20 0x005c9222 _PyFunction_FastCallKeywords (python3.7)
#21 0x0053c430 n/a (python3.7)
#22 0x00543d9b _PyEval_EvalFrameDefault (python3.7)
#23 0x005c8f1c _PyFunction_FastCallKeywords (python3.7)
#24 0x0053fa6c _PyEval_EvalFrameDefault (python3.7)
#25 0x005c8f1c _PyFunction_FastCallKeywords (python3.7)

Bug#62763: Possible man page fix

2019-04-05 Thread Kevin Lyda

Hopefully this addresses the problem.

https://salsa.debian.org/xorg-team/app/x11-apps/merge_requests/1

Kevin
-- 
Kevin Lyda
Galway, Ireland

Bug#926481: stretch-pu: package open-vm-tools/2:10.1.5-5055683-4+deb9u2

2019-04-05 Thread Bernd Zeimetz

Package: release.debian.org
Severity: normal
Tags: stretch
User: release.debian@packages.debian.org
Usertags: pu

Hi release team,

as discuassed with the security team, I'd like to fix #925959
with the next stable pointrelease. The proposed debdiff is attached.


Please let me know if its okay to upload.

Thanks,

Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F
diff --git a/debian/changelog b/debian/changelog
index 0be9f865..9b8f4cbb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,20 @@
+open-vm-tools (2:10.1.5-5055683-4+deb9u2) stable; urgency=medium
+
+  * [34db05f] /tmp/VMwareDnD permissions security fix.
+Fix possible security issue with the permissions of the intermediate
+staging directory and path
+/tmp/VMwareDnD is a staging directory used for DnD and CnP.  It should be
+a regular directory, but malicious code or user may create the 
/tmp/VMwareDnD
+as a symbolic link which points elsewhere on the system.  This may provide
+user access to user B's files.
+Do not set the permission of the root directory if the root directory
+already exists and has the wrong permission.  The permission of the 
directory
+must be 1777 if it is created by the VMToolsi.  If not, then the directory
+has been created or modified by malicious code or user, so just cancel the
+host to guest DnD or CnP operation. (Closes: #925959)
+
+ -- Bernd Zeimetz   Fri, 05 Apr 2019 23:10:04 +0200
+
 open-vm-tools (2:10.1.5-5055683-4+deb9u1) stretch; urgency=medium
 
   * [dec8df6] Upstream fix for CVE-2015-5191 (Closes: #869633)
diff --git 
a/debian/patches/e88f91b00a715b79255de6576506d80ecfdb064c_vmware_dnd_fix.patch 
b/debian/patches/e88f91b00a715b79255de6576506d80ecfdb064c_vmware_dnd_fix.patch
new file mode 100644
index ..43daed8a
--- /dev/null
+++ 
b/debian/patches/e88f91b00a715b79255de6576506d80ecfdb064c_vmware_dnd_fix.patch
@@ -0,0 +1,54 @@
+commit e88f91b00a715b79255de6576506d80ecfdb064c
+Author: Oliver Kurth 
+Date:   Tue Jan 29 14:03:19 2019 -0800
+
+Fix possible security issue with the permissions of the intermediate
+staging directory and path
+
+/tmp/VMwareDnD is a staging directory used for DnD and CnP.  It should be
+a regular directory, but malicious code or user may create the 
/tmp/VMwareDnD
+as a symbolic link which points elsewhere on the system.  This may provide
+user access to user B's files.
+
+Do not set the permission of the root directory if the root directory
+already exists and has the wrong permission.  The permission of the 
directory
+must be 1777 if it is created by the VMToolsi.  If not, then the directory
+has been created or modified by malicious code or user, so just cancel the
+host to guest DnD or CnP operation.
+
+--- a/open-vm-tools/services/plugins/dndcp/dnd/dndCommon.c
 b/open-vm-tools/services/plugins/dndcp/dnd/dndCommon.c
+@@ -276,12 +276,11 @@ DnDCreateRootStagingDirectory(void)
+}
+ 
+if (File_Exists(root)) {
+-  if (!DnDRootDirUsable(root) &&
+-  !DnDSetPermissionsOnRootDir(root)) {
++  if (!DnDRootDirUsable(root)) {
+  /*
+-  * The directory already exists and its permissions are wrong and
+-  * cannot be set, so there's not much we can do.
++  * The directory already exists and its permissions are wrong.
+   */
++ Log("%s: The root dir is not usable.\n", __FUNCTION__);
+  return NULL;
+   }
+} else {
+--- a/open-vm-tools/services/plugins/dndcp/dnd/dndXdg.c
 b/open-vm-tools/services/plugins/dndcp/dnd/dndXdg.c
+@@ -318,12 +318,11 @@ CreateApparentRootDirectory(void)
+}
+ 
+if (File_Exists(root)) {
+-  if (   !DnDRootDirUsable(root)
+-  && !DnDSetPermissionsOnRootDir(root)) {
++  if (!DnDRootDirUsable(root)) {
+  /*
+-  * The directory already exists and its permissions are wrong and
+-  * cannot be set, so there's not much we can do.
++  * The directory already exists and its permissions are wrong.
+   */
++ Log_Trivia("dnd: The root dir is not usable.\n");
+  return NULL;
+   }
+} else {
diff --git a/debian/patches/series b/debian/patches/series
index 2c8fbff7..58f5849b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -5,3 +5,4 @@ from_arch/0001-Fix-vmxnet-module-on-kernels-3.16.patch
 debian/enable_vmhgfs-fuse_by_default
 debian/vmxnet_fix_kernel_4.7.patch
 debian/cve-2015-5191.patch
+e88f91b00a715b79255de6576506d80ecfdb064c_vmware_dnd_fix.patch

Bug#873012: Patch for broken live migration in qemu in stretch

2019-04-05 Thread Geoffrey Thomas


Control: tag -1 patch

I ended up tracking this down - the problem is that the target qemu 
accepts the NBD connection from the source but does not handle any of the 
data on the socket. That plus Berni's comment that the NBD security 
patches caused the regression helped me figure out what was going wrong 
and get a proper fix to the security patches.


The patch 
nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch 
was not backported / cherry-picked properly. It's taken from this commit 
in qemu 2.10:


https://github.com/qemu/qemu/commit/df8ad9f128c15aa0a0ebc7b24e9a22c9775b67af

Note that the backported patch moves around a call to nbd_set_handlers(), 
which doesn't exist in the upstream commit. The upstream commit has a call 
to nbd_client_receive_next_request() which _isn't_ moved by the patch; 
that call doesn't exist in the backported commit. That's because this call 
to nbd_set_handlers() was changed to nbd_client_receive_next_request() in 
qemu 2.9:


https://github.com/qemu/qemu/commit/ff82911cd3f69f028f2537825c9720ff78bc3f19

If you adjust the backported patch to leave nbd_set_handlers() alone 
instead of moving it around, the NBD server starts to work, and live 
migration works again. I've tested this by patching the qemu on the target 
hypervisor and doing a live migration using Stretch's versions of 
OpenStack and libvirt (nova live-migration --block-migrate, VM disks are 
qcow2 on local disk).


I've attached a debdiff of the local build I'm using. You should be able 
to fix the version number in d/changelog and upload. If it would help for 
me to prepare packages for upload (I'll need sponsorship, but I can upload 
to mentors or something with my DM key) or open a pull request to Salsa, I 
can do that too. (Not totally sure what the process is for an update to 
stable.)


--
Geoffrey Thomas
https://ldpreload.com
geo...@ldpreload.comdiff -Nru qemu-2.8+dfsg/debian/changelog qemu-2.8+dfsg/debian/changelog
--- qemu-2.8+dfsg/debian/changelog  2018-11-08 15:41:45.0 +
+++ qemu-2.8+dfsg/debian/changelog  2019-04-05 19:02:53.0 +
@@ -1,3 +1,14 @@
+qemu (1:2.8+dfsg-6+deb9u5+geofft1) stretch-security; urgency=medium
+
+  * Fix improper backport of CVE-2017-9524 fix that caused NBD
+connections to hang (Closes: #873012).
+- 
nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch:
+  Don't move nbd_set_handlers before nbd_negotiate.
+- nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch:
+  Refresh.
+
+ -- Geoffrey Thomas   Fri, 05 Apr 2019 19:02:53 +
+
 qemu (1:2.8+dfsg-6+deb9u5) stretch-security; urgency=medium
 
   * Backport SSBD support (Closes: #908682)
diff -Nru 
qemu-2.8+dfsg/debian/patches/nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch
 
qemu-2.8+dfsg/debian/patches/nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch
--- 
qemu-2.8+dfsg/debian/patches/nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch
  2018-05-26 10:04:06.0 +
+++ 
qemu-2.8+dfsg/debian/patches/nbd-fix-regression-on-resiliency-to-port-scan-CVE-2017-9524.patch
  2019-04-05 19:02:53.0 +
@@ -140,15 +140,15 @@
  }
  
  static void nbd_read(void *opaque)
-@@ -1410,7 +1410,7 @@ static coroutine_fn void nbd_co_client_start(void 
*opaque)
- nbd_set_handlers(client);
+@@ -1409,7 +1409,7 @@ static coroutine_fn void nbd_co_client_s
+ qemu_co_mutex_init(>send_lock);
  
  if (nbd_negotiate(data)) {
 -client_close(client);
 +client_close(client, false);
  goto out;
  }
- 
+ nbd_set_handlers(client);
 @@ -1418,11 +1418,17 @@ out:
  g_free(data);
  }
diff -Nru 
qemu-2.8+dfsg/debian/patches/nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch
 
qemu-2.8+dfsg/debian/patches/nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch
--- 
qemu-2.8+dfsg/debian/patches/nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch
  2018-05-26 10:04:06.0 +
+++ 
qemu-2.8+dfsg/debian/patches/nbd-fully-initialize-client-in-case-of-failed-negotiation-CVE-2017-9524.patch
  2019-04-05 19:02:53.0 +
@@ -51,14 +51,13 @@
 +QTAILQ_INSERT_TAIL(>clients, client, next);
  }
 +qemu_co_mutex_init(>send_lock);
-+nbd_set_handlers(client);
 +
  if (nbd_negotiate(data)) {
  client_close(client);
  goto out;
  }
 -qemu_co_mutex_init(>send_lock);
--nbd_set_handlers(client);
+ nbd_set_handlers(client);
  
 -if (exp) {
 -QTAILQ_INSERT_TAIL(>clients, client, next);

Bug#926477: dgit accepts short keyid even though debsign does not

2019-04-05 Thread Ian Jackson

Sam Hartman writes ("Bug#926477: dgit accepts short keyid even though debsign 
does not"):
> Package: dgit
> Version: 8.3
> Severity: important
...
> Someone wrote in a forum that I can't quote here something along the
> lines of it should be a bug for any Debian package to accept a
> short-form GPG keyid.  I agree.

That might even have been me.

> Dgit still accepts short-form keyids (and it doesn't look like this
> has been fixed in the repo) even though tools it calls does not.

I don't think dgit does anything with the keyid other than pass it to
other tools.  It doesn't validate the format at all, just treating it
as an opaque string.

I don't think it's dgit's job to do that ?  Is there a practical
problem that results from dgit not investigating the keyid syntax and
length ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#926480: unblock: tvtime/1.0.11-4

2019-04-05 Thread Tobias Frost

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

Please unblock package tvtime

The patch fixes #924076, a insecure usage of /tmp.

The important part of the debdiff is this:

--- a/src/utils.c
+++ b/src/utils.c
@@ -202,17 +202,11 @@
 }
 }

-/* If we can't use our /tmp directory, put the fifo in $HOME. */
-if( !mkdir_and_force_owner( fifodir, uid, getgid() ) ) {
-if( asprintf( , "%s/.tvtime/tvtimefifo-%s",
-  getenv( "HOME" ), hostname ) < 0 ) {
-fifo = 0;
-}
-} else {
-if( asprintf( , "%s/tvtimefifo-%s", fifodir, hostname ) < 0 ) {
-fifo = 0;
-}
-}
+/* put the fifo in $HOME */
+ if( asprintf( , "%s/.tvtime/tvtimefifo-%s",
+   getenv( "HOME" ), hostname ) < 0 ) {
+ fifo = 0;
+ }
 free( hostname );
 free( fifodir );
 return fifo;

(Sorry for the refreshing of the patches, I realized this just now that
this would not have been necessary)

Debdiff attached.

Cheers,
tobi


unblock tvtime/1.0.11-4

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tvtime-1.0.11/debian/changelog tvtime-1.0.11/debian/changelog
--- tvtime-1.0.11/debian/changelog  2018-12-10 23:50:07.0 +0100
+++ tvtime-1.0.11/debian/changelog  2019-04-05 20:27:01.0 +0200
@@ -1,3 +1,14 @@
+tvtime (1.0.11-5) unstable; urgency=medium
+
+  * QA upload.
+  * Create repository on salsa.
+  * Refresh patches
+  * Fix "insecure use of /tmp" by only using the fall back to $HOME.
+This is patch 0002-disable-insecure-temp-file.patch
+(Closes: #924076)
+
+ -- Tobias Frost   Fri, 05 Apr 2019 20:27:01 +0200
+
 tvtime (1.0.11-4) unstable; urgency=medium
 
   * QA upload.
diff -Nru tvtime-1.0.11/debian/control tvtime-1.0.11/debian/control
--- tvtime-1.0.11/debian/control2018-12-10 23:50:07.0 +0100
+++ tvtime-1.0.11/debian/control2019-04-05 19:56:54.0 +0200
@@ -22,6 +22,8 @@
  libasound2-dev
 Standards-Version: 3.9.3
 Homepage: https://linuxtv.org/wiki/index.php/Tvtime
+VCS-Browser: https://salsa.debian.org/debian/tvtime
+VCS-Git: https://salsa.debian.org/debian/tvtime.git
 
 Package: tvtime
 Architecture: any
diff -Nru 
tvtime-1.0.11/debian/patches/0001-Fix-warning-implicit-declaration-of-function-minor-m.patch
 
tvtime-1.0.11/debian/patches/0001-Fix-warning-implicit-declaration-of-function-minor-m.patch
--- 
tvtime-1.0.11/debian/patches/0001-Fix-warning-implicit-declaration-of-function-minor-m.patch
2018-12-10 21:35:44.0 +0100
+++ 
tvtime-1.0.11/debian/patches/0001-Fix-warning-implicit-declaration-of-function-minor-m.patch
2019-04-05 19:57:51.0 +0200
@@ -14,8 +14,6 @@
  src/get_media_devices.c | 1 +
  1 file changed, 1 insertion(+)
 
-diff --git a/src/get_media_devices.c b/src/get_media_devices.c
-index 619734ea..453b0677 100644
 --- a/src/get_media_devices.c
 +++ b/src/get_media_devices.c
 @@ -23,6 +23,7 @@
@@ -26,6 +24,3 @@
  #include 
  #include 
  #include 
--- 
-2.11.0
-
diff -Nru tvtime-1.0.11/debian/patches/0002-disable-insecure-temp-file.patch 
tvtime-1.0.11/debian/patches/0002-disable-insecure-temp-file.patch
--- tvtime-1.0.11/debian/patches/0002-disable-insecure-temp-file.patch  
1970-01-01 01:00:00.0 +0100
+++ tvtime-1.0.11/debian/patches/0002-disable-insecure-temp-file.patch  
2019-04-05 20:10:15.0 +0200
@@ -0,0 +1,25 @@
+--- a/src/utils.c
 b/src/utils.c
+@@ -202,17 +202,11 @@
+ }
+ }
+ 
+-/* If we can't use our /tmp directory, put the fifo in $HOME. */
+-if( !mkdir_and_force_owner( fifodir, uid, getgid() ) ) {
+-if( asprintf( , "%s/.tvtime/tvtimefifo-%s",
+-  getenv( "HOME" ), hostname ) < 0 ) {
+-fifo = 0;
+-}
+-} else {
+-if( asprintf( , "%s/tvtimefifo-%s", fifodir, hostname ) < 0 ) {
+-fifo = 0;
+-}
+-}
++/* put the fifo in $HOME */
++if( asprintf( , "%s/.tvtime/tvtimefifo-%s",
++  getenv( "HOME" ), hostname ) < 0 ) {
++fifo = 0;
++}
+ free( hostname );
+ free( fifodir );
+ return fifo;
diff -Nru tvtime-1.0.11/debian/patches/freetype.patch 
tvtime-1.0.11/debian/patches/freetype.patch
--- tvtime-1.0.11/debian/patches/freetype.patch 2018-10-26 17:32:26.0 
+0200
+++ tvtime-1.0.11/debian/patches/freetype.patch 2019-04-05 19:57:50.0 
+0200
@@ -2,9 +2,9 @@
 Author: Adrian Bunk 
 Bug-Debian:

Bug#925950: patches no longer apply for gcc-8 and gcc-9

2019-04-05 Thread Tobias Frost

Control: tags -1 pending

Hi Dimo,

> My key situation should be resolved with the next keyring update, but
> this will take a few weeks probably. If it's useful to you, you
should
> push the new package into the archive.

I've uploaded your package to DELAYED/10. Let me know if I should
accelerate it or if I should remove it from the DELAYED queue.

Cheers,
tobi


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

Bug#926291: [Pkg-puppet-devel] Bug#926291: puppetdb 6 not compatible with puppet-master 5

2019-04-05 Thread Chad W Seys

Hi Apollon,
   I've got it to work!  Not sure what changed, but must have missed 
soemthing earlier.

Thanks for you time!
Chad.

Bug#926479: strongswan: flaky autopkgtest: ERROR: starter IS NOT RUNNING

2019-04-05 Thread Paul Gevers

Source: strongswan
Version: 5.7.1-1
Severity: important
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: flaky

Dear maintainers,

Your package has an autopkgtest, great. However, it nearly always fails
in unstable and testing, while once in a while it passes. Because the
unstable-to-testing migration software now blocks on regressions in
testing, flaky tests, i.e. tests that flip between passing and failing
without changes to the list of installed packages, are wasting peoples
time. Please either fix the test to be more robust, or mark this
particular test as "flaky".

I copied some of the output at the bottom of this report. For the
failures I inspected the failure always seems to be on the same place.

More information about this bug and the reason for filing it can be found on
https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation

Looking at the output of your last test, I also wonder if something
somewhere isn't missing a "set -e" so that it fails on "sh: 1: modprobe:
not found". Is the last test passing correctly?

Paul

https://ci.debian.net/data/autopkgtest/testing/amd64/s/strongswan/2204395/log.gz

autopkgtest [16:13:34]: test daemon: [---
ERROR: starter IS NOT RUNNING
autopkgtest [16:13:35]: test daemon: ---]



signature.asc
Description: OpenPGP digital signature

Bug#926478: clang-tidy-7: Missng manpage

2019-04-05 Thread Moshe Piekarski

Package: clang-tidy-7
Version: 1:7.0.1-8
Severity: minor

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

The manpage for clang-tidy-7 does not display any text.
Thank you,
Moshe Piekarski

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/bash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages clang-tidy-7 depends on:
ii  clang-tools-7  1:7.0.1-8
ii  libc6  2.28-8
ii  libclang-common-7-dev  1:7.0.1-8
ii  libgcc11:8.3.0-4
ii  libllvm7   1:7.0.1-8
ii  libstdc++6 8.3.0-4
ii  python 2.7.15-4
ii  python-yaml3.13-2

clang-tidy-7 recommends no packages.

clang-tidy-7 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQJNBAEBCAA3FiEEXbk7X2RxJi0NGP5lMn/Nf3K/IoEFAlyntgkZHGRlYmlhbi5i
dWdzQG1lbGFjaGltLm5ldAAKCRAyf81/cr8igfuSD/9dMpxd6pe8RdJy6AVSWi7J
Ul0EpgoCQTIflWwa+tAcC+duLxSNgRTGfCSOx2Zims8tEb88Wc5ep5aivDz0MWWu
H0lxyXBYax199Z3qKdE0ZpOYn0D/MO7bSKNi5qXdIlnkkYY7T5tt0rjx6JdXZqED
wBAKFTb9tsQwX3F35RN/XRVRlTAZc0d3eBn1fayYqo3CrbdU8IXP/wKK8/ZK75hk
M1wQY9fhkLiVTslFpZ00yg/z0yYOpduH0p3f1FQYaG01LmOVo7lDusJovrf1UmZq
gbh3GW92kk5ewaky7hQuxQG3IHpylFejCNWy0zv+zIAFQZplGwPX/N2v04EKCdM4
ORiqgr8BPzsNGb1OW/bKJ8tZbD3kUgTrhIMnM5+hVGfW8DjO/sZ73fIPH4w3UTyP
A6BG/x2LdvU3Vhkit8x6yKuC/0ttj2obYViqetxR4UZOhBNpl+eqFnyoLhOOj2XT
utnJXoYn587zIk5mu3LUmWeViw4rfZCJW37/pLZj2WcedgovINQoyMkkEXwq1LB8
oBi+ddbTgBeWRsQJkuonmuLQ4BYToC7LmhyXz3MGsQmSM981sC6IR0vnXvMhaD+0
uVQhRsPriJAaa060IV/nxjvZFVco5QGVwIGtPKdZcP4ZT+QtGWFvv+N0iJdgbYDE
pWGWQg6I1bA6GM5aNz7BYA==
=uIJN
-END PGP SIGNATURE-

Bug#926477: dgit accepts short keyid even though debsign does not

2019-04-05 Thread Sam Hartman

Package: dgit
Version: 8.3
Severity: important

Dear Maintainer,

Someone wrote in a forum that I can't quote here something along the
lines of it should be a bug for any Debian package to accept a
short-form GPG keyid.  I agree.


Dgit still accepts short-form keyids (and it doesn't look like this
has been fixed in the repo) even though tools it calls does not.


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

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

Versions of packages dgit depends on:
ii  apt 1.8.0~rc4
ii  ca-certificates 20190110
ii  coreutils   8.30-3
ii  curl7.64.0-1
ii  devscripts  2.19.3
ii  dpkg-dev1.19.5
ii  dput1.0.3
ii  git [git-core]  1:2.20.1-1
ii  git-buildpackage0.9.13
pn  libdigest-sha-perl  
ii  libdpkg-perl1.19.5
ii  libjson-perl4.0-1
ii  liblist-moreutils-perl  0.416-1+b4
ii  liblocale-gettext-perl  1.07-3+b4
ii  libtext-glob-perl   0.10-1
ii  libtext-iconv-perl  1.7-5+b7
ii  libwww-perl 6.36-1
ii  perl5.28.1-3

Versions of packages dgit recommends:
ii  openssh-client [ssh-client]  1:7.9p1-5

Versions of packages dgit suggests:
ii  sbuild  0.78.0-2

-- no debconf information

Bug#926212: gnome-shell crashed (segfault)

2019-04-05 Thread Bernhard Übelacker

Hello Guenter Grodotzki,
I just tried to help triage that issue.

For some reason you just added the segfault line.
I assume there was one line following starting with "Code:".
Please add that line too when submitting bugs.

As this information is still kind of small, you might consider
to install a coredump collector like systemd-coredump.
That way you could list crashes of the current boot by:
coredumpctl list
And some more information is entered into journal that would
help a lot to triage such crashes ("Stack trace of thread...".
journalctl --no-pager

Even better would be if you could install the debug symbol
packages e.g. gnome-shell-dbgsym like described in [1].
Then following commands should print a backtrace
with source line information.


Nevertheless, I tried if that little information brings
us somewhere and I think it leads into function
shell_app_dispose. There, I assume, we reach line 1485,
unfortunately dereferencing a null pointer
in app->running_state->windows.


There are some upstream bugs [2], which point to that line.
Unfortunately it looks like there is no fix yet commited.


But, if I am right, something like this could
help already (untested)?

   while (app->running_state)
-_shell_app_remove_window (app, app->running_state->windows->data);
+if (app->running_state->windows) _shell_app_remove_window (app, 
app->running_state->windows->data);
 
   /* We should have been transitioned when we removed all of our windows */


Kind regards,
Bernhard


[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
[2] https://gitlab.gnome.org/GNOME/gnome-shell/issues/590
https://gitlab.gnome.org/GNOME/gnome-shell/issues/766
https://gitlab.gnome.org/GNOME/gnome-shell/issues/750
https://gitlab.gnome.org/GNOME/gnome-shell/issues/918
https://gitlab.gnome.org/GNOME/gnome-shell/issues/822
https://bugzilla.redhat.com/show_bug.cgi?id=1654420#c22


(gdb) list shell-app.c:1477,1492
1477static void
1478shell_app_dispose (GObject *object)
1479{
1480  ShellApp *app = SHELL_APP (object);
1481
1482  g_clear_object (>info);
1483
1484  while (app->running_state)
1485_shell_app_remove_window (app, app->running_state->windows->data);
1486
1487  /* We should have been transitioned when we removed all of our 
windows */
1488  g_assert (app->state == SHELL_APP_STATE_STOPPED);
1489  g_assert (app->running_state == NULL);
1490
1491  G_OBJECT_CLASS(shell_app_parent_class)->dispose (object);
1492}

# Buster amd64 qemu VM 2019-04-05


apt update
apt dist-upgrade


apt install dpkg-dev devscripts systemd-coredump bc xserver-xorg dbus-x11 gdm3 
gnome gdb elfutils binutils gnome-shell-dbgsym


systemctl start gdm3


mkdir /home/benutzer/source/gnome-shell/orig -p
cd/home/benutzer/source/gnome-shell/orig
apt source gnome-shell
cd





# From submitter
[39719.061358] gnome-shell[1279]: segfault at 0 ip 7fd4fa6ae3bf sp 
7ffcf4dbaea0 error 4 in libgnome-shell.so[7fd4fa6a6000+1f000]


https://www.enodev.fr/posts/decode-segfault-errors-in-dmesg.html
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/x86/mm/fault.c?h=linux-4.9.y#n31


/*
 * Page fault error code bits:
 *
 *   bit 0 ==<-> 0: no page found<->1: protection fault
 *   bit 1 ==<-> 0: read access><-->1: write access
 *   bit 2 ==<-> 0: kernel-mode access<>1: user-mode access
 *   bit 3 ==<-><--><--><-->1: use of reserved bit detected
 *   bit 4 ==<-><--><--><-->1: fault was an instruction fetch
 *   bit 5 ==<-><--><--><-->1: protection keys block access
 */
enum x86_pf_error_code {

<-->PF_PROT><-->=<-><-->1 << 0,
<-->PF_WRITE<-->=<-><-->1 << 1,
<-->PF_USER><-->=<-><-->1 << 2,
<-->PF_RSVD><-->=<-><-->1 << 3,
<-->PF_INSTR<-->=<-><-->1 << 4,
<-->PF_PK<-><-->=<-><-->1 << 5,
};


"error 4" == 0b100

bit 0 ==<--> 0: no page found
bit 1 ==<--> 0: read access
bit 2 ==<--> 1: user-mode access





# From submitter
[39719.061358] gnome-shell[1279]: segfault at 0 ip 7fd4fa6ae3bf sp 
7ffcf4dbaea0 error 4 in libgnome-shell.so[7fd4fa6a6000+1f000]


crash instruction  - start .init== diff
0x7fd4fa6ae3bf - 0x7fd4fa6a6000 == 0x83BF

benutzer@debian:~$ gdb -q -ex 'set width 0' -ex 'set pagination off' -ex 'info 
share' -ex 'info target' -ex 'detach' -ex 'quit' --pid $(pidof gnome-shell) 
2>&1 | grep libgnome-shell.so
0x7f2482ab2f10  0x7f2482acd22e  Yes 
/usr/lib/gnome-shell/libgnome-shell.so
0x7f2482a98238 - 0x7f2482a9825c is .note.gnu.build-id in 
/usr/lib/gnome-shell/libgnome-shell.so
0x7f2482a98260 - 0x7f2482a99004 is .gnu.hash in 
/usr/lib/gnome-shell/libgnome-shell.so
0x7f2482a99008 - 0x7f2482a9fd40 is .dynsym in 
/usr/lib/gnome-shell/libgnome-shell.so

Bug#919486: osinfo-db: diff for NMU version 0.20181120-1.1

2019-04-05 Thread Guido Günther

Hi,
On Fri, Apr 05, 2019 at 05:36:49PM +, z...@debian.org wrote:
> Control: tags 919486 + patch
> Control: tags 919486 + pending
> 
> Dear maintainer,
> 
> I've prepared an NMU for osinfo-db (versioned as 0.20181120-1.1) and
> uploaded it to DELAYED/5. Please feel free to tell me if I
> should delay it longer.

Thanks for looking into this!

The reason I've not dealt with that yet is that the links are all dead
atm. This will trigger frustration for people using this.

Also it'd be as important to have osinfodb support in stretch so people
building new buster VMs on our current stable can do so.

So what would be better here is to follow RCs like we did for stretch:

https://salsa.debian.org/libvirt-team/osinfo-db/commit/f34951d8f47fb6ec6546c8630c34c1365b825a02
https://salsa.debian.org/libvirt-team/osinfo-db/commit/efcfeb9c9420448c2d85f16560b70910b12f40b9

If we had stable links for CD images (3813797) this would be different
but I did not get around to look into this yet so help there would be
appreciated and would make this fixable for real.

For now it would be cool if you could cancel the NMU.
Cheers,
 -- Guido

Bug#926418: [Pkg-libvirt-maintainers] Bug#926418: libvirt: CVE-2019-3886: virsh domhostname command discloses guest hostname in readonly mode

2019-04-05 Thread Salvatore Bonaccorso

Hi Guido,

On Fri, Apr 05, 2019 at 07:10:25PM +0200, Guido Günther wrote:
> Hi,
> On Thu, Apr 04, 2019 at 10:30:14PM +0200, Salvatore Bonaccorso wrote:
> > Source: libvirt
> > Version: 5.0.0-1
> > Severity: important
> > Tags: security upstream
> > Forwarded: 
> > https://www.redhat.com/archives/libvir-list/2019-April/msg00339.html
> > 
> > Hi,
> > 
> > The following vulnerability was published for libvirt.
> > 
> > CVE-2019-3886[0]:
> > | An incorrect permissions check was discovered in libvirt 4.8.0 and
> > | above. The readonly permission was allowed to invoke APIs depending on
> > | the guest agent, which could lead to potentially disclosing unintended
> > | information or denial of service by causing libvirt to block.
> > 
> > I'm filling it here as well for ruther investigation. Is this only
> > affecting versions >= 4.8.0?
> 
> I'd assume this to affect older version as well (looking at the
> fix). I'll prepare an upload once upstream has this in git.

Thanks. Yes I'm confused that it's claimed to be 4.8.0 onwards, but
the submitted fix would in theory apply.

Regards,
Salvatore

Bug#924848: telegram-cli: FTBFS: build-dependency not installable: libwolfssl-dev

2019-04-05 Thread Tobias Frost

On Wed, 3 Apr 2019 22:16:23 +0500 Andrey Rahmatullin 
wrote:
> libwolfssl was removed from testing due to #918952.
> The shared lib was removed but this package was not, because it
doesn't
> depend on the lib. Maybe the B-D can be safely removed.

Checked, will FTBFS when done…
It will likely build with openssl (not tried), but the source code is
GPL2.0 without an OpenSSL license exception...
I asked upstream to add such an exception in 
https://github.com/vysheng/tg/issues/1591

> -- 
> WBR, wRAR

Bug#926474: [Pkg-samba-maint] Bug#926474: smbclient: Can browse samba shares as root but not as user

2019-04-05 Thread Mathieu Parent

Control: tag -1 + moreinfo

Le ven. 5 avr. 2019 à 20:27,  a écrit :
>
> Package: smbclient
> Version: 2:4.9.5+dfsg-2
> Severity: important
>
> Dear Maintainer,

Hi,

>  in a freshly installed testing/buster release, I installed samba + 
> smbclient and reproduced the same configuration
>  (smb.conf, smbpasswd for root and for user) that is perfectly working on a 
> Stretch release installed in a separated partition .
> Testparm gives a positive result, and  # pdbedit -w -L correctly provides
> root:0::564A9466B5B97FEBE398359543B5B07D:[U   
>]:LCT-5CA4C2F8:
> giuliano:1000::8C869E0D14E71B60877E785FE5F8A299:[U
>   ]:LCT-5CA4C312:
>
> Issuing the command smbtree as root I can see the available local and remote 
> resources, however issuing the same command
>  as user I get
> "Unable to initialize messaging context" on the first line,
> followed either by nothing, or by an incorrect or partial list of the shares.
> Restarting samba (# /usr/sbin/service smbd restart) then smbtree shows all 
> the shares, always with the same message on first
> line, but I cannot browse them:
> Dolphin does not show anything under Samba Shares.
>
> I have quite a limited experience and do not know which other details might 
> be of interest.

Please provide your smb.conf.

Regards
-- 
Mathieu Parent

Bug#924798: Fix for the FTBFS

2019-04-05 Thread Christian Ehrhardt

Hi,
I looked into the issue as it was listing the package for autoremoval.

The issue actually is quite easy as tox made a transition back in
August 2015 (2.1.1-2) that renamed python-tox to tox. This transition
now dropped the transitionals in 3.7.0-1.

There was no bug in python-scales for that transition, but the fix is
simple, just follow the rename will make python-scales build again.

I have test built unstable and testing before the change and saw
testing fail. The reason why unstable still works is that the old
binary (actually transitional) was never removed.

With the fix builds against testing works again.
I'm attaching a debdiff and will look for a sponsor.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd


fix-924798.debdiff
Description: Binary data

Bug#925812: qtbase-opensource-src: ftbfs with GCC-9

2019-04-05 Thread Dmitry Shachnev

On Wed, Mar 27, 2019 at 07:47:46PM +, Matthias Klose wrote:
> The package fails to build in a test rebuild on at least amd64 with
> gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The
> severity of this report will be raised before the bullseye release,
> so nothing has to be done for the buster release.
>
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc9-20190321/qtbase-opensource-src_5.11.3+dfsg1-1_unstable_gcc9.log
> The last lines of the build log are at the end of this report.

This particular issue is probably fixed in [1] which was applied in
Qt 5.12.1 and later versions (already available in experimental).

There may be other issues like symbols differences, so I am not yet
closing this bug until we verify that the build succeeds with GCC 9.

[1]: https://codereview.qt-project.org/245425

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#926476: apt search vs apt-cache search package list / output format

2019-04-05 Thread Darshaka Pathirana

Package: apt
Version: 1.4.9
Severity: normal

Dear Maintainer,

Please look at the following output:

  % apt search x-window-manager
  Sorting... Done
  Full Text Search... Done
  matchbox-themes-extra/stable,stable 0.3-4 all
extra themes for matchbox-window-manager

  matchbox-window-manager/stable 1.2-osso21-2+b1 amd64
window manager for resource-limited systems

  xorg/stable,now 1:7.7+19 amd64 [installed,automatic]
X.Org X Window System

  % apt-cache search x-window-manager
  9wm - X11 window manager inspired by Plan 9's rio
  aewm - minimalist window manager for X11
  aewm++ - minimal window manager written in C++
  afterstep - window manager with the NEXTSTEP look and feel
  awesome - highly configurable X window manager
  blackbox - Window manager for X
  bspwm - Binary space partitioning window manager
  [...]
  wm2 - small, unconfigurable window manager
  wmaker - NeXTSTEP-like window manager for X
  wmii - lightweight tabbed and tiled X11 window manager, version 3
  xfwm4 - window manager of the Xfce project
  xmonad - Lightweight X11 window manager written in Haskell
  xorg - X.Org X Window System
  amiwm - The Amiga look alike window manager
  notion - tiling tabbed window manager designed for keyboard users

  % apt-cache search x-window-manager | wc -l
  59

There are two issues here:

* [1] The list of packages differ (3 vs 59 packages)
* [2] The output format is not the same (2 lines + empty line vs 1 line per 
package)

Given that the man page of apt(8) states the following

,
| The apt(8) commandline is designed as an end-user tool and it may change 
behavior between
| versions. While it tries not to break backward compatibility this is not 
guaranteed either if a
| change seems beneficial for interactive use.
|
| All features of apt(8) are available in dedicated APT tools like apt-get(8) 
and apt-cache(8) as
| well.  apt(8) just changes the default value of some options (see apt.conf(5) 
and specifically
| the Binary scope). So you should prefer using these commands (potentially 
with some additional
| options enabled) in your scripts as they keep backward compatibility as much 
as possible.
`

we should be ok with [2] but we should document why the output looks different
and - if possible - how to change the output format.

But shouldn't the package list be the same? Or shouldn't there be a setting to
archive that and shouldn't that be documented?

After browsing the source (together with zeha, thx!), we found how to force apt
search to output in the "traditional" way:

  apt -oAPT::Cache::Search::Version=1 search x-window-manager

Thank you for looking into this and please tell us what we can do to help.

Regards from the Debian-BSP, Salzburg :),
 - Darsha

-- Package-specific info:

-- apt-config dump --

APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "false";
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\.18\.0-0\.bpo\.1-amd64$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-0\.bpo\.1-amd64-unsigned$";
APT::NeverAutoRemove:: "^linux-image-4\.19\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.18\.0-0\.bpo\.1-amd64$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-0\.bpo\.1-amd64-unsigned$";
APT::NeverAutoRemove:: "^linux-headers-4\.19\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.18\.0-0\.bpo\.1-amd64$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-0\.bpo\.1-amd64-unsigned$";
APT::NeverAutoRemove:: "^linux-image-extra-4\.19\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.18\.0-0\.bpo\.1-amd64$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-0\.bpo\.1-amd64-unsigned$";
APT::NeverAutoRemove:: "^linux-signed-image-4\.19\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.18\.0-0\.bpo\.1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-0\.bpo\.1-amd64-unsigned$";
APT::NeverAutoRemove:: "^kfreebsd-image-4\.19\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.18\.0-0\.bpo\.1-amd64$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-0\.bpo\.1-amd64-unsigned$";
APT::NeverAutoRemove:: "^kfreebsd-headers-4\.19\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.18\.0-0\.bpo\.1-amd64$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-0\.bpo\.1-amd64-unsigned$";
APT::NeverAutoRemove:: "^gnumach-image-4\.19\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.18\.0-0\.bpo\.1-amd64$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-0\.bpo\.1-amd64-unsigned$";
APT::NeverAutoRemove:: "^.*-modules-4\.19\.0-0\.bpo\.2-amd64$";
APT::NeverAutoRemove:: "^.*-kernel-4\.18\.0-0\.bpo\.1-amd64$";
APT::NeverAutoRemove::

Bug#924061: NMU uploaded to delayed-2

2019-04-05 Thread Bernd Zeimetz

Hi,

I've rised the severity to grave again. The excuse that it is possible
to use the package without the service is like explaining people they
should use a car without the car keys just because this is possible.

Also I've fixed the bug and uploaded the fix as NMU to delayed-2.

I'll also take care of the unblock request if you don't stop me.


 Bernd

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Bug#926475: ITP: dlt-viewer -- Viewer for GENIVI DLT traces

2019-04-05 Thread Stefan Potyra

Package: wnpp
Severity: wishlist
Owner: Stefan Potyra 

* Package name: dlt-viewer
  Version : 2.18.0
  Upstream Author : Alexander Wenzel  (et al.)
* URL : 
https://at.projects.genivi.org/wiki/display/PROJ/Diagnostic+Log+and+Trace
* License : MPL-2.0
  Programming Lang: C++
  Description : Viewer for GENIVI DLT traces

The Diagnostic Log and Trace Viewer is an application that can send and
receive control messages to the DLT daemon, e.g. to set individual log
levels of applications and contexts or get the list of applications
and contexts registered in the DLT daemon.

Co-maintainers welcome! @Aigars: You maintain dlt-daemon, interested?

Cheers,
  Stefan.

Bug#926474: smbclient: Can browse samba shares as root but not as user

2019-04-05 Thread gcab_dzan

Package: smbclient
Version: 2:4.9.5+dfsg-2
Severity: important

Dear Maintainer,

 in a freshly installed testing/buster release, I installed samba + 
smbclient and reproduced the same configuration
 (smb.conf, smbpasswd for root and for user) that is perfectly working on a 
Stretch release installed in a separated partition .
Testparm gives a positive result, and  # pdbedit -w -L correctly provides
root:0::564A9466B5B97FEBE398359543B5B07D:[U 
 ]:LCT-5CA4C2F8:
giuliano:1000::8C869E0D14E71B60877E785FE5F8A299:[U
  ]:LCT-5CA4C312:

Issuing the command smbtree as root I can see the available local and remote 
resources, however issuing the same command
 as user I get
"Unable to initialize messaging context" on the first line,
followed either by nothing, or by an incorrect or partial list of the shares.
Restarting samba (# /usr/sbin/service smbd restart) then smbtree shows all the 
shares, always with the same message on first
line, but I cannot browse them:
Dolphin does not show anything under Samba Shares.

I have quite a limited experience and do not know which other details might be 
of interest.

Thanks for your attention and work
Giuliano Cabrele




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

Kernel: Linux 4.19.0-4-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set LC_ALL 
to default locale: No such file or directory
UTF-8), LANGUAGE=en_US (charmap=locale: Cannot set LC_ALL to default locale: No 
such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages smbclient depends on:
ii  dpkg  1.19.6
ii  libarchive13  3.3.3-4
ii  libbsd0   0.9.1-2
ii  libc6 2.28-8
ii  libpopt0  1.16-12
ii  libreadline7  7.0-5
ii  libsmbclient  2:4.9.5+dfsg-2
ii  libtalloc22.1.14-2
ii  libtevent00.9.37-1
ii  samba-common  2:4.9.5+dfsg-2
ii  samba-libs2:4.9.5+dfsg-2

smbclient recommends no packages.

Versions of packages smbclient suggests:
ii  cifs-utils   2:6.8-2
pn  heimdal-clients  

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US",
LC_ALL = (unset),
LC_TIME = "it_IT.UTF-8",
LC_MONETARY = "it_IT.UTF-8",
LC_CTYPE = "C.UTF-8",
LC_MEASUREMENT = "it_IT.UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#921713: fix suggestion in merge request

2019-04-05 Thread Christian Ehrhardt

FYI - i have put a suggestion to fix it into [1].
I hope that helps to resolve this.

[1]: https://salsa.debian.org/libvirt-team/libvirt/merge_requests/12

Bug#920574: fix suggestion in merge request

2019-04-05 Thread Christian Ehrhardt

FYI - i have put a suggestion to fix it into [1].
I hope that helps to resolve this.

[1]: https://salsa.debian.org/libvirt-team/libvirt/merge_requests/12

Bug#926342: libprotobuf17: I was forced to download libprotobuf17 on this site: https://packages.debian.org/buster/amd64/libprotobuf17/download

2019-04-05 Thread gilles . charabot

Good morning or good evening!
A]I don't use pinning. 
B]I don't have a file which name is /etc/apt/preferences :

less /etc/apt/preferences
/etc/apt/preferences: Aucun fichier ou dossier de ce type

C]I have just a file which name is apt-listbugs in /etc/apt/preferences.d :

/etc/apt/preferences.d# ls -ail
total 12
1044672 drwxr-xr-x 2 root root 4096 mars   6  2018 .
1044507 drwxr-xr-x 8 root root 4096 avril  5 08:44 ..
1045052 -rw-r--r-- 1 root root  631 févr. 26 08:22 apt-listbugs


less apt-listbugs
Result :
Explanation: Pinned by apt-listbugs at 2018-08-14 08:06:20 +0200
Explanation:   #904059: clang-6.0: default target on armhf is 
armv8l-unknown-linux-gnueabihf
Package: clang-6.0
Pin: version *
Pin-Priority: -3

Explanation: Pinned by apt-listbugs at 2018-10-27 19:50:22 +0200
Explanation:   #910964: libprotobuf17 needs Breaks: libprotobuf10
Package: libprotobuf17
Pin: version *
Pin-Priority: -3


Explanation: Pinned by apt-listbugs at 2019-02-26 08:22:10 +0100
Explanation:   #918973: udev rules and created user conflict with the one 
shipped in trousers package
Package: libtss2-udev
Pin: version *
Pin-Priority: -3
~
~
~
D] my sources/list
# less /etc/apt/sources.list
Result : 
# deb cdrom:[Debian GNU/Linux 9.1.0 _Stretch_ - Official amd64 NETINST 
20170722-11:28]/ buster main

#deb cdrom:[Debian GNU/Linux 9.1.0 _Stretch_ - Official amd64 NETINST 
20170722-11:28]/ buster main

# Debian buster dépôt principal + paquets non-libres
deb http://ftp.de.debian.org/debian/ buster main 
deb-src http://ftp.de.debian.org/debian/ buster main

# Debian buster mises à jour de sécurité + paquets non-libres
deb http://security.debian.org/debian-security buster/updates main
deb-src http://security.debian.org/debian-security buster/updates main

# Debian buster mises à jour, auparavant connues sous le nom de 'volatiles'
# buster-updates, previously known as 'volatile'
deb http://ftp.de.debian.org/debian/ buster-updates main 
deb-src http://ftp.de.debian.org/debian/ buster-updates main

# les paquets pour débugguer
deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main

E] Output of apt udate :
# apt update
Atteint :1 http://security.debian.org/debian-security buster/updates InRelease
Atteint :2 http://debug.mirrors.debian.org/debian-debug testing-debug InRelease
Atteint :3 http://ftp.de.debian.org/debian buster InRelease
Atteint :4 http://ftp.de.debian.org/debian buster-updates InRelease
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances   
Lecture des informations d'état... Fait
19 paquets peuvent être mis à jour. Exécutez « apt list --upgradable » pour les 
voir.

F]# apt list --upgradable
En train de lister... Fait
cpp-8/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
g++-8/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
gcc-8-base/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
gcc-8/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libasan5/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libatomic1/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libcc1-0/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libgcc-8-dev/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libgcc1/testing 1:8.3.0-5 amd64 [pouvant être mis à jour depuis : 1:8.3.0-4]
libgfortran5/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libgomp1/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libitm1/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
liblsan0/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libmpx2/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libquadmath0/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libstdc++-8-dev/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libstdc++6/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libtsan0/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]
libubsan1/testing 8.3.0-5 amd64 [pouvant être mis à jour depuis : 8.3.0-4]

I will update after this message.

G]I have removed libprotobuf10 just after install libprotobuf17 many months ago.
# apt-cache policy libprotobuf10
N: Impossible de trouver le paquet libprotobuf10

/etc/apt# aptitude search  libprotobuf
p   libprotobuf-c-dev - Protocol Buffers C static 
library and headers (protobuf
i A libprotobuf-c1- Protocol Buffers C shared 
library (protobuf-c) 
p   libprotobuf-c1-dbgsym - debug symbols for 
libprotobuf-c1   
p   libprotobuf-dev   - protocol buffers C++ 
library (development files) and pr
i A libprotobuf-java  - Java bindings for protocol 
buffers 
p   libprotobuf-java-format-java  - Library to

Bug#926473: amavisd-new: Dependency on non-existing ZeroMQ Perl library

2019-04-05 Thread Michael Krieger

Package: amavisd-new
Version: 1:2.11.0-6
Severity: normal

amavisd-status does not work, depending on ZeroMQ which is no longer in Debian
 See https://bugs.debian.org/824905

# amavisd-status
Perl modules ZMQ::LibZMQ3 or ZMQ::LibZMQ2 or ZeroMQ not available
BEGIN failed--compilation aborted at /usr/sbin/amavisd-status line 110.

This was previously reported in 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801852
however in taht case it was to recommend making it a depend/recommend.

In this case, it is reporting the broken functionality as a result of that.

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

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

Versions of packages amavisd-new depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  file   1:5.35-4
ii  init-system-helpers1.56+nmu1
pn  libarchive-tar-perl
ii  libarchive-zip-perl1.64-1
ii  libberkeleydb-perl 0.55-2
ii  libconvert-tnef-perl   0.18-1
ii  libconvert-uulib-perl  1:1.5~dfsg-1+b1
pn  libdigest-md5-perl 
ii  libio-stringy-perl 2.111-3
ii  libmail-dkim-perl  0.54-1
ii  libmailtools-perl  2.18-1
pn  libmime-base64-perl
ii  libmime-tools-perl 5.509-1
ii  libnet-libidn-perl 0.12.ds-3+b1
ii  libnet-server-perl 2.009-1
pn  libtime-hires-perl 
ii  libunix-syslog-perl1.1-3+b1
ii  lsb-base   10.2019031300
ii  pax1:20190224-1
ii  perl   5.28.1-6

Versions of packages amavisd-new recommends:
ii  altermime 0.3.10-9
ii  libnet-patricia-perl  1.22-1+b5
pn  ripole

Versions of packages amavisd-new suggests:
ii  apt-listchanges  3.19
ii  arj  3.10.22-18
ii  cabextract   1.9-1
ii  clamav   0.101.2+dfsg-1
ii  clamav-daemon0.101.2+dfsg-1
ii  cpio 2.12+dfsg-6
pn  dspam
pn  lhasa
ii  libauthen-sasl-perl  2.1600-1
ii  libdbi-perl  1.642-1+b1
ii  libmail-dkim-perl0.54-1
pn  libnet-ldap-perl 
pn  libsnmp-perl 
pn  libzeromq-perl   
pn  lzop 
ii  nomarch  1.4-3+b2
pn  p7zip
pn  rpm  
ii  spamassassin 3.4.2-1
pn  unrar

-- no debconf information

Bug#884562: Enable CONFIG_SND_SOC_SPDIF for cubietruck spdif

2019-04-05 Thread Stefan Fritsch

Ping ?

I have opened a merge request 

https://salsa.debian.org/kernel-team/linux/merge_requests/137

Bug#919486: osinfo-db: diff for NMU version 0.20181120-1.1

2019-04-05 Thread zeha

Control: tags 919486 + patch
Control: tags 919486 + pending

Dear maintainer,

I've prepared an NMU for osinfo-db (versioned as 0.20181120-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

I'm also going to open a PR on salsa.

Cheers,
Chris


diff -Nru osinfo-db-0.20181120/debian/changelog 
osinfo-db-0.20181120/debian/changelog
--- osinfo-db-0.20181120/debian/changelog   2018-11-20 21:41:36.0 
+
+++ osinfo-db-0.20181120/debian/changelog   2019-04-05 17:33:34.0 
+
@@ -1,3 +1,10 @@
+osinfo-db (0.20181120-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add data file for Debian 10. (Closes: #919486)
+
+ -- Chris Hofstaedtler   Fri, 05 Apr 2019 17:33:34 +
+
 osinfo-db (0.20181120-1) unstable; urgency=medium
 
   * [aa777b6] New upstream version 0.20181120
diff -Nru osinfo-db-0.20181120/debian/patches/debian-10 
osinfo-db-0.20181120/debian/patches/debian-10
--- osinfo-db-0.20181120/debian/patches/debian-10   1970-01-01 
00:00:00.0 +
+++ osinfo-db-0.20181120/debian/patches/debian-10   2019-04-05 
17:30:38.0 +
@@ -0,0 +1,144 @@
+Description: Add Debian buster data
+ With preliminary/guessed URLs.
+Author: Chris Hofstaedtler 
+Last-Update: 2019-04-05
+
+Index: osinfo-db-0.20181120/data/os/debian.org/debian-10.xml.in
+===
+--- /dev/null
 osinfo-db-0.20181120/data/os/debian.org/debian-10.xml.in
+@@ -0,0 +1,134 @@
++
++
++  http://debian.org/debian/10;>
++debian10
++debianbuster
++<_name>Debian Buster
++10
++<_vendor>Debian Project
++linux
++debian
++http://debian.org/debian/9"/>
++http://debian.org/debian/9"/>
++
++2019-03-12
++
++
++  http://pcisig.com/pci/1af4/1041"/> 
++  http://pcisig.com/pci/1af4/1042"/> 
++  http://pcisig.com/pci/1af4/1043"/> 
++  http://pcisig.com/pci/1af4/1044"/> 
++  http://pcisig.com/pci/1af4/1045"/> 
++  http://pcisig.com/pci/1af4/1048"/> 
++  http://pcisig.com/pci/1af4/1049"/> 
++  http://pcisig.com/pci/1af4/1052"/> 
++  http://qemu.org/chipset/x86/q35"/> 
++  http://pcisig.com/pci/8086/10d3"/> 
++  http://pcisig.com/pci/8086/293e"/> 
++
++
++
++  
++10
++1
++1073741824
++10737418240
++  
++  
++10
++1073741824
++21474836480
++  
++
++
++
++  <_name>Debian 10
++
++
++  <_name>Debian 10
++
++
++
++
++  
++  
http://cdimage.debian.org/cdimage/release/10.0.0/i386/iso-cd/debian-10.0.0-i386-netinst.iso
++  
++Debian 10.(\d)+.(\d)+ i386 n
++  
++  install.386/vmlinuz
++  install.386/initrd.gz
++
++
++  
++  
http://cdimage.debian.org/cdimage/release/10.0.0/amd64/iso-cd/debian-10.0.0-amd64-netinst.iso
++  
++  Debian 10.(\d)+.(\d)+ amd64 n
++  
++  install.amd/vmlinuz
++  install.amd/initrd.gz
++
++
++  
++  
http://cdimage.debian.org/cdimage/release/10.0.0/arm64/iso-cd/debian-10.0.0-arm64-netinst.iso
++  
++  Debian 10.(\d)+.(\d)+ arm64 n
++  
++  install.arm64/vmlinuz
++  install.arm64/initrd.gz
++
++
++  
++  
http://cdimage.debian.org/cdimage/release/10.0.0/armhf/iso-cd/debian-10.0.0-armhf-netinst.iso
++  
++  Debian 10.(\d)+.(\d)+ armhf n
++  
++  install.armhf/vmlinuz
++  install.armhf/initrd.gz
++
++
++
++
++  
++  
http://cdimage.debian.org/cdimage/release/10.0.0/i386/iso-dvd/debian-10.0.0-i386-DVD-1.iso
++  
++Debian 10.(\d)+.(\d)+ i386 1
++  
++  install.386/vmlinuz
++  install.386/initrd.gz
++
++
++  
++  
http://cdimage.debian.org/cdimage/release/10.0.0/amd64/iso-dvd/debian-10.0.0-amd64-DVD-1.iso
++  
++  Debian 10.(\d)+.(\d)+ amd64 1
++  
++  install.amd/vmlinuz
++  install.amd/initrd.gz
++
++
++  
++  
http://cdimage.debian.org/cdimage/release/10.0.0/arm64/iso-dvd/debian-10.0.0-arm64-DVD-1.iso
++  
++  Debian 10.(\d)+.(\d)+ arm64 1
++  
++  install.arm64/vmlinuz
++  install.arm64/initrd.gz
++
++
++  
++  
http://cdimage.debian.org/cdimage/release/10.0.0/armhf/iso-dvd/debian-10.0.0-armhf-DVD-1.iso
++  
++  Debian 10.(\d)+.(\d)+ armhf 1
++  
++  install.armhf/vmlinuz
++  install.armhf/initrd.gz
++
++
++
++  
++  
++
++  
++
++
diff -Nru osinfo-db-0.20181120/debian/patches/series 
osinfo-db-0.20181120/debian/patches/series
--- osinfo-db-0.20181120/debian/patches/series  1970-01-01 00:00:00.0 
+
+++ osinfo-db-0.20181120/debian/patches/series  2019-04-05 17:18:31.0 
+
@@ -0,0 +1 @@
+debian-10

Bug#901040: libapt-pkg5.0: systemd in Triggers-pending state after upgrade with aptitude

2019-04-05 Thread Vincent Lefevre

On 2019-04-05 15:56:25 +0200, David Kalnischkies wrote:
> Hence closing as not-a-bug, but following a user request to the letter.

OK, but then this should be documented. Reported:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926472

for the documentation.

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

Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386

2019-04-05 Thread Jérémy Lal

Le ven. 5 avr. 2019 à 18:31, Bernhard Übelacker  a
écrit :

> Hello Jérémy,
> sorry for the delay.
>
>
> > So if i run qemu with the first P6 cpu that comes to mind, pentiumpro,
> > npm install electron-spellchecker@1.1.2
> > no longer crashes.
> >
> > That doesn't prove there is no crash on a supported cpu, but that's a
> start.
> > Comparing the flags and address sizes might help.
> > Also upstream nodejs does not support 32bit cpu on linux platform.
>
> Unfortunately my debian QEmu does not have a cpu "pentiumpro".
> (qemu-system-i386 -cpu help)
>

That's odd ! We should have the same options ?

I tried to debug it at real hardware, which also supports rr [1].
> Unfortunately there I hit a bug in rr that rr-upstream fixed very fast [2].
>
> At this real hardware [3] I could reproduce this bug with i386 userlands
> runnning at amd64- or i386-kernel. I assume that should be a supported CPU.
>
> I tried to follow that value 0x1085, that is shown in the original report
> and in all my debugging attempts, by reverse debugging.
> But unfortunately that led to no certain findings.
>

That's surely very hard to catch since v8 is generating assembly on the fly.

I'll try to get some info from upstream.

Jérémy


>
>
> Kind regards,
> Bernhard
>
>
> [1] https://rr-project.org/
> [2] https://github.com/mozilla/rr/issues/2342
>
> [3] Architecture:x86_64
> CPU op-mode(s):  32-bit, 64-bit
> Byte Order:  Little Endian
> Address sizes:   36 bits physical, 48 bits virtual
> Vendor ID:   GenuineIntel
> CPU family:  6
> Model name:  Intel(R) Pentium(R) CPU B950 @ 2.10GHz
>
>

Bug#926472: dpkg(1) man page: should document that putting a package on hold will require to process triggers manually

2019-04-05 Thread Vincent Lefevre

Package: dpkg
Version: 1.19.6
Severity: wishlist

When a package is on hold, its triggers are not processed
automatically, and this is regarded as a feature[*]. It
should be documented that triggers need to be processed
manually.

[*] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=901040

-- Package-specific info:

-- System Information:
Debian Release: buster/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=POSIX 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages dpkg depends on:
ii  libbz2-1.0   1.0.6-9
ii  libc62.28-8
ii  liblzma5 5.2.4-1
ii  libselinux1  2.8-1+b1
ii  tar  1.30+dfsg-5
ii  zlib1g   1:1.2.11.dfsg-1

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii  apt1.8.0
pn  debsig-verify  

-- no debconf information

Bug#926470: RFP: annocheck -- analyse an application's compilation

2019-04-05 Thread Chris Lamb

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

* Package name: annocheck
* URL : https://sourceware.org/git/?p=annobin.git
* License : GPL3
  Programming Lang: C
  Description : Analyse an application's compilation

>From annocheck(1)

The annocheck program can analyse programs and report information
about them.  It is designed to be modular, with a set of self-
contained tools providing the checking functionality. Currently the
following tools are implemented:

The annocheck program is able to scan inside rpm files and libraries.
It will automatically recurse into any directories that are specified
on the command line.  In addition annocheck knows how to find debug
information held in separate debug files, and it will search for these
whenever it needs the resources that they contain.

New tools can be added to the annocheck framework by creating a new
source file and including it in the Makefile used to build annocheck.
The modular nature of annocheck means that nothing else needs to be
updated.

New tools must fill out a "struct checker" structure (defined in
annocheck.h) and they must define a constructor function that calls
"annocheck_add_checker" to register their presence at program start-up.

The annocheck program supports some generic command line options that
are used regardless of which tools are enabled.

This RFP was prompted by the following wishlist request against
diffoscope:

  https://salsa.debian.org/reproducible-builds/diffoscope/issues/51


Regards,

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

Bug#926418: [Pkg-libvirt-maintainers] Bug#926418: libvirt: CVE-2019-3886: virsh domhostname command discloses guest hostname in readonly mode

2019-04-05 Thread Guido Günther

Hi,
On Thu, Apr 04, 2019 at 10:30:14PM +0200, Salvatore Bonaccorso wrote:
> Source: libvirt
> Version: 5.0.0-1
> Severity: important
> Tags: security upstream
> Forwarded: 
> https://www.redhat.com/archives/libvir-list/2019-April/msg00339.html
> 
> Hi,
> 
> The following vulnerability was published for libvirt.
> 
> CVE-2019-3886[0]:
> | An incorrect permissions check was discovered in libvirt 4.8.0 and
> | above. The readonly permission was allowed to invoke APIs depending on
> | the guest agent, which could lead to potentially disclosing unintended
> | information or denial of service by causing libvirt to block.
> 
> I'm filling it here as well for ruther investigation. Is this only
> affecting versions >= 4.8.0?

I'd assume this to affect older version as well (looking at the
fix). I'll prepare an upload once upstream has this in git.
 -- Guido

Bug#926471: lintian: add warning about missing init.d script

2019-04-05 Thread Dmitry Bogatov


Package: lintian
Version: 2.11.0
Severity: wishlist

Dear Maintainer,

According to Policy, 9.11:

Packages may integrate with these replacement init systems by
providing implementation-specific configuration information
about how and when to start a service or in what order to run
certain tasks at boot time. However, any package integrating
with other init systems must also be backwards-compatible with
sysvinit by providing a SysV- style init script with the same
name as and equivalent functionality to any init-specific job,
as this is the only start-up configuration method guaranteed to
be supported by all init implementations.

As such, presence in package files /lib/systemd/system/.service or
/etc/sv/ without corresponding /etc/init.d/ is violation of
"must" in Policy. Please add apporiate error to Lintian.


pgpvLNIxiCKgb.pgp
Description: PGP signature

Bug#919484: ping - how to procceed after buster?

2019-04-05 Thread Christian Ehrhardt

Hi,
since there was no reply yet i wonder how we should proceed.
I could create a pull request, but just as well we could just close the bug.
This is mostly depending on your preference how we should go on with this.

Therefore a kind "ping" on this bug.

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#926469: lintian: Postfix results missing from lintian.d.o

2019-04-05 Thread Scott Kitterman

Package: lintian
Version: 2.12.0
Severity: normal

Reporting this as a bug against the package because the web site says:

"Comments about these web pages? Please use reportbug to report a bug against
the lintian package."

I am 100% certain that postfix is not lintian clean, yet it isn't on
lintian.d.o as far as I can find.  It's neither linked from tracker.d.o nor
listed on:

https://lintian.debian.org/packages_3.html

This can't be right?

Scott K

Bug#849714: gbp-buildpackage test

2019-04-05 Thread halfdog

Rebuilt package to see the gbp/salsa still works on Debian Buster
build host, uploaded to mentors.
~

Bug#882324: amavisd-new: diff for NMU version 1:2.11.0-6.1

2019-04-05 Thread Tobias Frost

Control: tags 882324 + pending

Dear maintainer,

I've prepared an NMU for amavisd-new (versioned as 1:2.11.0-6.1) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru amavisd-new-2.11.0/debian/changelog amavisd-new-2.11.0/debian/changelog
--- amavisd-new-2.11.0/debian/changelog	2019-02-13 07:48:10.0 +0100
+++ amavisd-new-2.11.0/debian/changelog	2019-04-05 17:57:54.0 +0200
@@ -1,3 +1,11 @@
+amavisd-new (1:2.11.0-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix to honor "originating" configuration flag, by cherry-picking upstream
+patch. (Closes: #882324)
+
+ -- Tobias Frost   Fri, 05 Apr 2019 17:57:54 +0200
+
 amavisd-new (1:2.11.0-6) unstable; urgency=medium
 
   * Fix start-stop-daemon insecure error. Closes: #921016.
diff -Nru amavisd-new-2.11.0/debian/patches/0010-fix-882324.patch amavisd-new-2.11.0/debian/patches/0010-fix-882324.patch
--- amavisd-new-2.11.0/debian/patches/0010-fix-882324.patch	1970-01-01 01:00:00.0 +0100
+++ amavisd-new-2.11.0/debian/patches/0010-fix-882324.patch	2019-04-05 17:56:43.0 +0200
@@ -0,0 +1,26 @@
+Description: honor "originating" configuration flag, 
+Origin: https://gitlab.com/amavis/amavis/commit/206109d4c21f28dcd2ba3f42a19b7d77e2bbc100.patch
+Date: Wed, 10 Oct 2018 16:34:58 +0200
+Subject: [PATCH] Applied DKIM signing patch (#6)
+Applied-Upstream: Yes
+Last-Update: 2019-04-05
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/amavisd
 b/amavisd
+@@ -22829,6 +22829,7 @@
+ }
+ # load policy banks from the 'client_ipaddr_policy' lookup
+ Amavis::load_policy_bank($_,$msginfo) for @bank_names_cl;
++$msginfo->originating(c('originating'));
+ 
+ $msginfo->client_addr($cl_ip);  # ADDR
+ $msginfo->client_port($cl_port);# PORT
+@@ -34361,6 +34362,7 @@
+ $sig_ind++;
+   }
+   Amavis::load_policy_bank($_,$msginfo) for @bank_names;
++  $msginfo->originating(c('originating'));
+   $msginfo->dkim_signatures_valid(\@signatures_valid)  if @signatures_valid;
+ # if (ll(5) && $sig_ind > 0) {
+ #   # show which header fields are covered by which signature
diff -Nru amavisd-new-2.11.0/debian/patches/series amavisd-new-2.11.0/debian/patches/series
--- amavisd-new-2.11.0/debian/patches/series	2019-02-03 09:55:48.0 +0100
+++ amavisd-new-2.11.0/debian/patches/series	2019-04-05 17:54:53.0 +0200
@@ -7,3 +7,4 @@
 90_fix_snmp_subagent_warning
 95_amavisd_helpers_fixes
 0009-Fix-an-unescaped-brace-in-amavisd.patch
+0010-fix-882324.patch


signature.asc
Description: PGP signature

Bug#922075: [Pkg-javascript-devel] Bug#922075: npm: segfault during extract on i386

2019-04-05 Thread Bernhard Übelacker

Hello Jérémy,
sorry for the delay.


> So if i run qemu with the first P6 cpu that comes to mind, pentiumpro,
> npm install electron-spellchecker@1.1.2
> no longer crashes.
>
> That doesn't prove there is no crash on a supported cpu, but that's a start.
> Comparing the flags and address sizes might help.
> Also upstream nodejs does not support 32bit cpu on linux platform.

Unfortunately my debian QEmu does not have a cpu "pentiumpro".
(qemu-system-i386 -cpu help)


I tried to debug it at real hardware, which also supports rr [1].
Unfortunately there I hit a bug in rr that rr-upstream fixed very fast [2].

At this real hardware [3] I could reproduce this bug with i386 userlands
runnning at amd64- or i386-kernel. I assume that should be a supported CPU.

I tried to follow that value 0x1085, that is shown in the original report
and in all my debugging attempts, by reverse debugging.
But unfortunately that led to no certain findings.


Kind regards,
Bernhard


[1] https://rr-project.org/
[2] https://github.com/mozilla/rr/issues/2342

[3] Architecture:x86_64
CPU op-mode(s):  32-bit, 64-bit
Byte Order:  Little Endian
Address sizes:   36 bits physical, 48 bits virtual
Vendor ID:   GenuineIntel
CPU family:  6
Model name:  Intel(R) Pentium(R) CPU B950 @ 2.10GHz



debugging_4.txt.gz
Description: application/gzip

Bug#926468: linux-image-4.19.0-4-amd64: the k10temp module does not read CPU temperature any more

2019-04-05 Thread Francesco Potortì

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

I used to read core CPU temperature from
 /sys/class/hwmon/hwmon0/temp1_input

Now that file always reads 0, and the real temperature is found in
 /sys/class/hwmon/hwmon1/temp1_input

Maybe this is due to k10temp not reading the temperature any more, as
shown by sensors, which says that the value reported by k10temp is 0,
while the ACPI value is correct:

$ sensors
k10temp-pci-00c3
Adapter: PCI adapter
CPU Temp (rel):   +0.0°C  (high = +70.0°C)
  (crit = +99.5°C, hyst = +97.5°C)

atk0110-acpi-0
Adapter: ACPI interface
Vcore Voltage:  +1.46 V  (min =  +0.85 V, max =  +1.60 V)
 +3.3 Voltage:  +3.28 V  (min =  +2.97 V, max =  +3.63 V)
 +5 Voltage:+4.97 V  (min =  +4.50 V, max =  +5.50 V)
 +12 Voltage:  +11.85 V  (min = +10.20 V, max = +13.80 V)
CPU FAN Speed: 3096 RPM  (min =  600 RPM, max = 7200 RPM)
CHASSIS FAN Speed: 1117 RPM  (min =  600 RPM, max = 7200 RPM)
POWER FAN Speed:  0 RPM  (min =  600 RPM, max = 7200 RPM)
CPU Temperature:+58.0°C  (high = +60.0°C, crit = +95.0°C)
MB Temperature: +34.0°C  (high = +45.0°C, crit = +75.0°C)

-- 
IPIN'19 http://ipin2019.isti.cnr.itVoice:  +39.050.621.3058
Francesco Potortì (ricercatore)Mobile: +39.348.8283.107
ISTI - Area della ricerca CNR  Skype:  wnlabisti
via G. Moruzzi 1, I-56124 Pisa Web:http://fly.isti.cnr.it



-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 
root=UUID=4ee42fef-c2d5-406d-8aec-6832a5eb2e93 ro gfxpayload=1024x768x8,1024x768

** Tainted: POE (12289)
 * Proprietary module has been loaded.
 * Out-of-tree module has been loaded.
 * Unsigned module has been loaded.

** Kernel log:
Unable to read kernel log; any relevant messages should be attached

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Chassis Manufacture
chassis_version: Chassis Version
bios_vendor: American Megatrends Inc.
bios_version: 0703   
board_vendor: ASUSTeK Computer INC.
board_name: M4A88T-M/USB3
board_version: Rev X.0x

** Loaded modules:
fuse
pci_stub
cpufreq_userspace
vboxpci(OE)
cpufreq_powersave
vboxnetadp(OE)
cpufreq_conservative
vboxnetflt(OE)
vboxdrv(OE)
nft_counter
xt_tcpudp
nft_compat
nf_tables
nfnetlink
binfmt_misc
zfs(POE)
zunicode(POE)
zavl(POE)
icp(POE)
zcommon(POE)
znvpair(POE)
spl(OE)
ppdev
joydev
edac_mce_amd
kvm_amd
wmi_bmof
ccp
rng_core
kvm
irqbypass
pcmcia
serio_raw
yenta_socket
pcmcia_rsrc
pcmcia_core
parport_pc
parport
sg
asus_atk0110
evdev
snd_hda_codec_via
snd_hda_codec_generic
snd_hda_codec_hdmi
snd_hda_intel
snd_hda_codec
snd_hda_core
k10temp
snd_hwdep
snd_pcm_oss
snd_mixer_oss
sp5100_tco
snd_pcm
snd_timer
snd
soundcore
pcspkr
pcc_cpufreq
acpi_cpufreq
sunrpc
hwmon_vid
tcp_diag
inet_diag
firewire_sbp2
firewire_core
crc_itu_t
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
fscrypto
ecb
crypto_simd
cryptd
glue_helper
aes_x86_64
btrfs
zstd_decompress
zstd_compress
xxhash
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
raid6_pq
libcrc32c
crc32c_generic
raid0
multipath
linear
dm_mirror
dm_region_hash
dm_log
dm_mod
hid_generic
usbhid
hid
raid1
md_mod
sr_mod
cdrom
sd_mod
uas
usb_storage
radeon
psmouse
i2c_algo_bit
ttm
drm_kms_helper
ata_generic
drm
r8169
realtek
wmi
libphy
ahci
xhci_pci
libahci
pata_atiixp
xhci_hcd
ohci_pci
i2c_piix4
libata
button
scsi_mod
ehci_pci
ohci_hcd
ehci_hcd
usbcore
usb_common


** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] RS880 Host 
Bridge [1022:9601]
Subsystem: ASUSTeK Computer Inc. M5A88-V EVO [1043:843e]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- 

00:01.0 PCI bridge [0604]: ASUSTeK Computer Inc. AMD RS780/RS880 PCI to PCI 
bridge (int gfx) [1043:9602] (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=medium >TAbort- 
SERR- TAbort- 
Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 

00:06.0 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] RS780 PCI to PCI 
bridge (PCIE port 2) [1022:9606] (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:0a.0 PCI bridge [0604]: Advanced Micro

Bug#926467: RM: ekg2-ui-ncurses -- RoQA; very low popcon, meta package orphaned, no upstream release since 2011

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Plase remove the ekg2-core package because it is:
  - not used by many people (popcount of 88)
  - metapackage "ekg2" is orphaned since 2014
  - latest upstream release was 2011

Thanks.
I will also file removal requests for the depending packages:
 - ekg2-api-docs
 - ekg2-gnupg
 - ekg2-jabber
 - ekg2-scripting-python
 - ekg2-scripting-perl
 - ekg2-ui-gtk
 - ekg2-core

Bug#926466: RM: ekg2-ui-gtk -- RoQA; very low popcon, meta package orphaned, no upstream release since 2011

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Plase remove the ekg2-core package because it is:
  - not used by many people (popcount of 88)
  - metapackage "ekg2" is orphaned since 2014
  - latest upstream release was 2011

Thanks.
I will also file removal requests for the depending packages:
 - ekg2-api-docs
 - ekg2-gnupg
 - ekg2-jabber
 - ekg2-scripting-python
 - ekg2-scripting-perl
 - ekg2-core
 - ekg2-ui-ncurses

Bug#926465: RM: ekg2-scripting-python -- RoQA; very low popcon, meta package orphaned, no upstream release since 2011

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Plase remove the ekg2-core package because it is:
  - not used by many people (popcount of 88)
  - metapackage "ekg2" is orphaned since 2014
  - latest upstream release was 2011

Thanks.
I will also file removal requests for the depending packages:
 - ekg2-api-docs
 - ekg2-gnupg
 - ekg2-jabber
 - ekg2-core
 - ekg2-scripting-perl
 - ekg2-ui-gtk
 - ekg2-ui-ncurses

Bug#926464: RM: ekg2-scripting-perl -- RoQA; very low popcon, meta package orphaned, no upstream release since 2011

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Plase remove the ekg2-core package because it is:
  - not used by many people (popcount of 88)
  - metapackage "ekg2" is orphaned since 2014
  - latest upstream release was 2011

Thanks.
I will also file removal requests for the depending packages:
 - ekg2-api-docs
 - ekg2-gnupg
 - ekg2-jabber
 - ekg2-scripting-python
 - ekg2-core
 - ekg2-ui-gtk
 - ekg2-ui-ncurses

Bug#926462: RM: ekg2-gnupg -- RoQA; very low popcon, meta package orphaned, no upstream release since 2011

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Plase remove the ekg2-core package because it is:
  - not used by many people (popcount of 88)
  - metapackage "ekg2" is orphaned since 2014
  - latest upstream release was 2011

Thanks.
I will also file removal requests for the depending packages:
 - ekg2-api-docs
 - ekg2-core
 - ekg2-jabber
 - ekg2-scripting-python
 - ekg2-scripting-perl
 - ekg2-ui-gtk
 - ekg2-ui-ncurses

Bug#926463: RM: ekg2-jabber -- RoQA; very low popcon, meta package orphaned, no upstream release since 2011

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Plase remove the ekg2-core package because it is:
  - not used by many people (popcount of 88)
  - metapackage "ekg2" is orphaned since 2014
  - latest upstream release was 2011

Thanks.
I will also file removal requests for the depending packages:
 - ekg2-api-docs
 - ekg2-gnupg
 - ekg2-core
 - ekg2-scripting-python
 - ekg2-scripting-perl
 - ekg2-ui-gtk
 - ekg2-ui-ncurses

Bug#926460: RM: ekg2-core -- RoQA; very low popcon, meta package orphaned, no upstream release since 2011

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Plase remove the ekg2-core package because it is:
  - not used by many people (popcount of 88)
  - metapackage "ekg2" is orphaned since 2014
  - latest upstream release was 2011

Thanks.
I will also file removal requests for the depending packages:
 - ekg2-api-docs
 - ekg2-gnupg
 - ekg2-jabber
 - ekg2-scripting-python
 - ekg2-scripting-perl
 - ekg2-ui-gtk
 - ekg2-ui-ncurses

Bug#926461: RM: ekg2-api-docs -- RoQA; very low popcon, meta package orphaned, no upstream release since 2011

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Plase remove the ekg2-core package because it is:
  - not used by many people (popcount of 88)
  - metapackage "ekg2" is orphaned since 2014
  - latest upstream release was 2011

Thanks.
I will also file removal requests for the depending packages:
 - ekg2-core
 - ekg2-gnupg
 - ekg2-jabber
 - ekg2-scripting-python
 - ekg2-scripting-perl
 - ekg2-ui-gtk
 - ekg2-ui-ncurses

Bug#716767: This no more applies to any version >4.3

2019-04-05 Thread Christian Ehrhardt

fixed 716767 libvirt/5.0.0-1

FYI - The whole code that this bug was talking about was removed in
[1]. Given that and how non-active the bug over the years this can at
least have severity lowered.

[1]: 
https://libvirt.org/git/?p=libvirt.git;a=commit;h=1dac5f06a0341e8087dc33af75c8352d77a4

-- 
Christian Ehrhardt
Software Engineer, Ubuntu Server
Canonical Ltd

Bug#926260: debian-history: DebConf2 mistakenly referred to as the second DebConf

2019-04-05 Thread Osamu Aoki

Hi,

In short, 

 The First Debian Conference + debconf0 Bordeaux from the 5th to the 9th
of July 2000
 --> Missing in debian-history: Needs addition

 2001 ... The work around Debian didn't stop the developers from
organizing an  annual meeting called DebConf.  The first meeting was
held from the 2nd to the 5th of July together with the Libre Software
Meeting (LSM) at Bordeaux (France) gathered around forty Debian
developers. 
  --> This talks about debconf1 : second debconf --> Needs revise

The second conference took place in Toronto (Canada) July 5th 2002 with
over eighty participants.
  --> This talks about debconf2: third debconf  --> need revise
  
Google told me:
  https://debconf2.debconf.org/
  https://debconf2.debconf.org/pages/www.debian.org/0705-debconf.html
  https://debconf2.debconf.org/pages/www.debian.org/0705-debconf-schedule.html
So debconf2 exists!

It is only missing link to https://debconf2.debconf.org/ in
https://www.debconf.org/resources.shtml

So this debian-history page needs update ordinal numbers i++

Long reply:
On Thu, Apr 04, 2019 at 05:02:42PM +, Holger Levsen wrote:
> On Fri, Apr 05, 2019 at 01:02:13AM +0900, Osamu Aoki wrote:
> >  * definitive reference information.  I.e., PROOF.
> >("My understanding" is too weak.)
> >  * Endorsement by DEBCONF active organizer is nice to have as a
> >supporting evidence.
> 
> I'm "just" a former organizer but I can 100% assure you, that DebConf0
> was the 0th Debconf, Debconf1 was the first one, etc - if you start
> counting at 0.
> 
> ;)

I thought I heard the same story while I was attending Debconf17 at
Montreal.

> However, if you start counting at 1, DebConf0 in 2000 was the first
> DebConf, DebConf1 in 2001 was the 2nd DebConf, [...], DebConf18 in
> 2018 was the 19th DebConf and this year the 20th DebConf will take place
> as DebConf19 in Brasil.

Array index problem ;-) C/C++/Bash/Perl/Python vs. FORTRAN/COBOL/AWK

> It's confusing.

Certainly ... that calls for documenting these confusion point concisely
in debian-history.

> For referenence:
> 
> https://debconf1.debconf.org/ says: "The Debian people start counting
> from zero. Debian Conference 1 was the second big international meeting
> for this voluntary, at the same time anarchistic but focused group of
> developers."
> 
> Also, see https://debconf0.debconf.org/ - look at the title of that
> page! https://debconf2.debconf.org does not exist, while the rest is
> there too.

I also found a web page which seems to be most authentic source listing
all debconf (REFERENCE/PROOF?):

  https://www.debconf.org/resources.shtml

There exist good links to all previous ones.

DebconfN.debconf.org :: Previous DebConf sites

DebConf0 site - Bordeaux
DebConf1 site - Bordeaux
DebConf3 site - Oslo
DebConf4 site - Porto Alegre
DebConf5 site - Helsinki
DebConf6 site - Oaxtepec
DebConf7 site - Edinburgh   
DebConf8 site - Mar del plata   
DebConf9 site - Cáceres 
DebConf10 site - New York City  
DebConf11 site - Banja Luka 
DebConf12 site - Managua
DebConf13 site - Vaumarcus  
DebConf14 site - Portland   
DebConf15 site - Heidelberg 

Here, debconf2 is missing.


Osamu

Bug#911844: Severity 911844 normal

2019-04-05 Thread Brian Potkin

On Sun 10 Mar 2019 at 14:09:27 +, Andrew M.A. Cater wrote:

> Severity 911844 normal

It would be useful to know the reason why the severity has been reduced
to normal. I would have thought a confidential document should not end
up on a machine it was not intended for.

Regards,

Brian.

Bug#926164: Totem still sort of running, just UI not responding

2019-04-05 Thread Mike Crowe

It's just happened to me again and I was able to collect some more details.

1. The play/pause media key on my keyboard can still be used to play/pause
the track.

2. The "Videos is not responding" popup appears over the Totem window when
I try to focus it.

3. I captured the following strace when I attempted to focus the window and
clicked "Wait" on the not responding popup. It doesn't look particularly
helpful:

restart_syscall(<... resuming interrupted poll ...>) = 0
unlink("/home/mac/.config/totem/session_state.xspf") = 0
lstat("/home/mac/.config/totem", {st_mode=S_IFDIR|0700, st_size=4096, ...})
= 0
lstat("/home/mac/.config", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/home/mac", {st_mode=S_IFDIR|0755, st_size=12288, ...}) = 0
lstat("/home", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
lstat("/", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
eventfd2(0, EFD_CLOEXEC|EFD_NONBLOCK)   = 32
write(32, "\1\0\0\0\0\0\0\0", 8)= 8
write(6, "\1\0\0\0\0\0\0\0", 8) = 8
futex(0x7f4cb400dd20, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x7f4cb400dd20, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN (Resource
temporarily unavailable)
futex(0x7f4cb400dd20, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0x7f4cb400dcb0, FUTEX_WAKE_PRIVATE, 1) = 1
futex(0x55d55906a078, FUTEX_WAKE_PRIVATE, 1) = 1
poll([{fd=32, events=POLLIN}], 1, 25000) = 1 ([{fd=32, revents=POLLIN}])
read(32, "\1\0\0\0\0\0\0\0", 16)= 8
poll([{fd=32, events=POLLIN}], 1, 25000) = 1 ([{fd=32, revents=POLLIN}])
read(32, "\1\0\0\0\0\0\0\0", 16)= 8
write(32, "\1\0\0\0\0\0\0\0", 8)= 8
futex(0x55d55a1cac10, FUTEX_WAKE_PRIVATE, 2147483647) = 0
close(32)   = 0
openat(AT_FDCWD, "/home/mac/.config/totem/session_state.xspf",
O_WRONLY|O_CREAT|O_EXCL, 0666) = 32
write(32, "\n   file:///h"..., 147) = 147
write(32, "   BBC Radio 6 Music - Wi"..., 55) = 55
write(32, "   true\n", 29) = 29
write(32, "   \n", 16)  = 16
write(32, "  \n", 11)   = 11
write(32, " \n", 25) = 25
fstat(32, {st_mode=S_IFREG|0644, st_size=474, ...}) = 0
close(32)   = 0
poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=10, events=POLLIN},
{fd=16, events=POLLIN}, {fd=18, events=POLLIN}, {fd=21, events=POLLIN}], 6,
9993 

4. I have the Media Player Indicator GNOME shell extension enabled. Its
play/pause button also continues to work whilst the main Totem UI is
unresponsive.

Mike.

Bug#923866: aptly: diff for NMU version 1.3.0+ds1-2.1

2019-04-05 Thread Tobias Frost

Control: tags 923866 + pending

Dear maintainer,

I've prepared an NMU for aptly (versioned as 1.3.0+ds1-2.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.

Regards.

diff -Nru aptly-1.3.0+ds1/debian/changelog aptly-1.3.0+ds1/debian/changelog
--- aptly-1.3.0+ds1/debian/changelog	2018-10-26 19:22:38.0 +0200
+++ aptly-1.3.0+ds1/debian/changelog	2019-03-26 08:59:20.0 +0100
@@ -1,3 +1,10 @@
+aptly (1.3.0+ds1-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add patch to fix UUID struct field not encoded in msgpack (Closes: #923866)
+
+ -- Shengjing Zhu   Tue, 26 Mar 2019 15:59:20 +0800
+
 aptly (1.3.0+ds1-2) unstable; urgency=medium
 
   * Add NEWS to warn about database compatibility.
diff -Nru aptly-1.3.0+ds1/debian/patches/Fix-UUID-struct-field-not-encoded-in-msgpack.patch aptly-1.3.0+ds1/debian/patches/Fix-UUID-struct-field-not-encoded-in-msgpack.patch
--- aptly-1.3.0+ds1/debian/patches/Fix-UUID-struct-field-not-encoded-in-msgpack.patch	1970-01-01 01:00:00.0 +0100
+++ aptly-1.3.0+ds1/debian/patches/Fix-UUID-struct-field-not-encoded-in-msgpack.patch	2019-03-26 08:59:20.0 +0100
@@ -0,0 +1,62 @@
+From: Shengjing Zhu 
+Date: Tue, 26 Mar 2019 15:49:40 +0800
+Subject: Fix UUID struct field not encoded in msgpack
+
+golang-github-ugorji-go-codec-dev 1.1.1 takes the json field tag
+by default, thus the field which has `json:"-"` is ignored when
+marshal into msgpack.
+
+Upstream uses the old codec library, so there's no problem.
+
+Bug-Debian: https://bugs.debian.org/923866
+Forwarded: no
+---
+ deb/local.go| 4 ++--
+ deb/snapshot.go | 6 +++---
+ 2 files changed, 5 insertions(+), 5 deletions(-)
+
+diff --git a/deb/local.go b/deb/local.go
+index e9fa17c..79cc308 100644
+--- a/deb/local.go
 b/deb/local.go
+@@ -14,7 +14,7 @@ import (
+ // LocalRepo is a collection of packages created locally
+ type LocalRepo struct {
+ 	// Permanent internal ID
+-	UUID string `json:"-"`
++	UUID string `codec:"UUID" json:"-"`
+ 	// User-assigned name
+ 	Name string
+ 	// Comment
+@@ -24,7 +24,7 @@ type LocalRepo struct {
+ 	// DefaultComponent
+ 	DefaultComponent string `codec:",omitempty"`
+ 	// Uploaders configuration
+-	Uploaders *Uploaders `code:",omitempty" json:"-"`
++	Uploaders *Uploaders `code:"Uploaders,omitempty" json:"-"`
+ 	// "Snapshot" of current list of packages
+ 	packageRefs *PackageRefList
+ }
+diff --git a/deb/snapshot.go b/deb/snapshot.go
+index fc7689c..1aca3e3 100644
+--- a/deb/snapshot.go
 b/deb/snapshot.go
+@@ -19,15 +19,15 @@ import (
+ // Snapshot is immutable state of repository: list of packages
+ type Snapshot struct {
+ 	// Persisten internal ID
+-	UUID string `json:"-"`
++	UUID string `codec:"UUID" json:"-"`
+ 	// Human-readable name
+ 	Name string
+ 	// Date of creation
+ 	CreatedAt time.Time
+ 
+ 	// Source: kind + ID
+-	SourceKind string   `json:"-"`
+-	SourceIDs  []string `json:"-"`
++	SourceKind string   `codec:"SourceKind" json:"-"`
++	SourceIDs  []string `codec:"SourceIDs" json:"-"`
+ 	// Description of how snapshot was created
+ 	Description string
+ 
diff -Nru aptly-1.3.0+ds1/debian/patches/series aptly-1.3.0+ds1/debian/patches/series
--- aptly-1.3.0+ds1/debian/patches/series	2018-10-26 19:22:38.0 +0200
+++ aptly-1.3.0+ds1/debian/patches/series	2019-03-26 08:59:20.0 +0100
@@ -1,3 +1,4 @@
 
 kjk-lzma.patch
 pborman-uuid.patch
+Fix-UUID-struct-field-not-encoded-in-msgpack.patch


signature.asc
Description: PGP signature

Bug#923866: aptly: unable to delete local repositories

2019-04-05 Thread Tobias Frost

Control: tags -1 confirmed
Control: tags -1 pending

Can confirm that the patch works, I'm going to preapre a NMU for this.


-- 
tobi

Bug#926458: RM: gitstats -- RoQA; Low popcon, unmaintained, upstream inactive since 2015

2019-04-05 Thread Stefan Schörghofer

Package: ftp.debian.org
Severity: normal

Hello,

Is this package still needed?
It is:
 - orphaned since > 300days
 - has a low popcon (0.18%)
 - upstream is inactive since 2015

best regards,
Stefan

Bug#925967: upgrade to linux-image-4.19.0-4-amd64 fails to show login; unresponsive box.

2019-04-05 Thread John Ford

Package: src:linux
Version: 4.19.28-2
Severity: important

Dear Maintainer,

First, I apologize if I have omitted something.  This is my first 
attempt to file a bug report.

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

    * What led up to the situation?

routine upgrade, upon reboot, blank screen, no response

    * What exactly did you do (or not do) that was effective (or
  ineffective)?

I have done nothing.  I am at a loss.  I see nothing in dmesg or 
kern.log, not that I would really know what to look for.

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


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

** this is kern.log, less UFW messages and audit messages, for a failed 
boot of 4.19.0-4.
** I see no problem, making me wonder whether the problem is elsewhere...

Apr  3 17:20:17 PC08109 kernel: [719273.164167] snd_hda_intel 
:00:1f.3: azx_get_response timeout, switching to polling mode: last 
cmd=0x002f0600
Apr  3 17:39:34 PC08109 kernel: [720430.020009] systemd: 27 output lines 
suppressed due to ratelimiting
Apr  3 17:41:17 PC08109 kernel: [    0.00] microcode: microcode 
updated early to revision 0xc6, date = 2018-04-17
Apr  3 17:41:17 PC08109 kernel: [    0.00] Linux version 
4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 
(Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)
Apr  3 17:41:17 PC08109 kernel: [    0.00] Command line: 
BOOT_IMAGE=/boot/vmlinuz-4.19.0-4-amd64 
root=UUID=2ec4c5b3-d64a-44ea-a00e-80b1950ea3d8 ro quiet
Apr  3 17:41:17 PC08109 kernel: [    0.00] x86/fpu: Supporting XSAVE 
feature 0x001: 'x87 floating point registers'
Apr  3 17:41:17 PC08109 kernel: [    0.00] x86/fpu: Supporting XSAVE 
feature 0x002: 'SSE registers'
Apr  3 17:41:17 PC08109 kernel: [    0.00] x86/fpu: Supporting XSAVE 
feature 0x004: 'AVX registers'
Apr  3 17:41:17 PC08109 kernel: [    0.00] x86/fpu: Supporting XSAVE 
feature 0x008: 'MPX bounds registers'
Apr  3 17:41:17 PC08109 kernel: [    0.00] x86/fpu: Supporting XSAVE 
feature 0x010: 'MPX CSR'
Apr  3 17:41:17 PC08109 kernel: [    0.00] x86/fpu: 
xstate_offset[2]:  576, xstate_sizes[2]:  256
Apr  3 17:41:17 PC08109 kernel: [    0.00] x86/fpu: 
xstate_offset[3]:  832, xstate_sizes[3]:   64
Apr  3 17:41:17 PC08109 kernel: [    0.00] x86/fpu: 
xstate_offset[4]:  896, xstate_sizes[4]:   64
Apr  3 17:41:17 PC08109 kernel: [    0.00] x86/fpu: Enabled xstate 
features 0x1f, context size is 960 bytes, using 'compacted' format.
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-provided physical 
RAM map:
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0x-0x000903ff] usable
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0x00090400-0x0009] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0x000e-0x000f] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0x0010-0xc9757fff] usable
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xc9758000-0xc9758fff] ACPI NVS
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xc9759000-0xc9759fff] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xc975a000-0xd9876fff] usable
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xd9877000-0xdaeadfff] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xdaeae000-0xdaef1fff] ACPI data
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xdaef2000-0xdb812fff] ACPI NVS
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xdb813000-0xdbdfefff] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xdbdff000-0xdbdf] usable
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xdbe0-0xdfff] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xf800-0xfbff] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xfe00-0xfe010fff] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xfec0-0xfec00fff] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xfee0-0xfee00fff] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0xff00-0x] reserved
Apr  3 17:41:17 PC08109 kernel: [    0.00] BIOS-e820: [mem 
0x0001-0x00021dff] usable
Apr  3 17:41:17 PC08109 kernel: [    0.00] NX (Execute Disable) 
protection: active
Apr  3 17:41:17 PC08109 kernel: [    0.00] SMBIOS 3.0.0 present.
Apr  3 17:41:17 PC08109 kernel: [

Bug#926459: RFP: ponyorm -- Pony Object Relational Mapper

2019-04-05 Thread Antoine Beaupre

Package: wnpp
Severity: wishlist

* Package name: ponyorm
  Version : 0.7.9
  Upstream Author : Alexander Kozlovsky, Alexey Malashkevich 
* URL : https://ponyorm.org/
* License : Apache 2
  Programming Lang: Python
  Description : Pony Object Relational Mapper

Pony is an advanced object-relational mapper. The most interesting
feature of Pony is its ability to write queries to the database using
Python generator expressions. Pony analyzes the abstract syntax tree
of the generator expression and translates it into a SQL query.

Here is an example query in Pony:

select(p for p in Product if p.name.startswith('A') and p.cost <= 1000)

Pony translates queries to SQL using a specific database
dialect. Currently Pony works with SQLite, MySQL, PostgreSQL and
Oracle databases.

By providing a Pythonic API, Pony facilitates fast app
development. Pony is an easy-to-learn and easy-to-use library. It
makes your work more productive and helps to save resources. Pony
achieves this ease of use through the following:

 * Compact entity definitions
 * The concise query language
 * Ability to work with Pony interactively in a Python interpreter
 * Comprehensive error messages, showing the exact part where an error
   occurred in the query
 * Displaying of the generated SQL in a readable format with
   indentation

All this helps the developer to focus on implementing the business
logic of an application, instead of struggling with a mapper trying to
understand how to get the data from the database.



PonyORM is a dependency of supysonic (#926457), but could also be
useful for other Python packages. There are of course many other ORM
engines written in Python in the Debian archive, but I do not believe
any provides a compatibility layer that supysonic could use.

I do not plan on maintaining this and would love if the DPMT could
handle this one.

Bug#926457: RFP: supysonic -- multimedia streaming server

2019-04-05 Thread Antoine Beaupre

Package: wnpp
Severity: wishlist

* Package name: supysonic
  Version : N/A
  Upstream Author : spl0k 
* URL : https://github.com/spl0k/supysonic/
* License : AGPL-3.0
  Programming Lang: Python
  Description : multimedia streaming server

supysonic is a Python implementation of the Subsonic server API.
Current supported features are:

 * browsing (by folders or tags)
 * streaming of various audio file formats
 * transcoding
 * user or random playlists
 * cover arts (as image files in the same folder as music files)
 * starred tracks/albums and ratings
 * Last.FM scrobbling

The "Subsonic API" is a set of adhoc standards to browse, stream or
download a music collection over HTTP.



I have been using Subsonic for a while. it does wonders when combined
with mobile phone apps like dSub. It's similar in purpose to MPD and
other media players, except it can efficiently cache media files
(instead of always streaming them), enabling offline access, something
MPD doesn't handle well.

It also handles album covers, ratings and more. The supysonic
implementation is not complete, but it might be good enough for most
purposes. Being Python, it's much easier to deploy and manage than the
original upstream source, which is a Java package. The database
backend is (My|Postgre)SQL(ite) which makes it easier to interoperate,
although it depends on the PonyORM which does weird stuff like binary
foreign keys and is not packaged in Debian.

For now I've installed it in a virtualenv and the webserver
configuration is somewhat painful. I documented the process here:

https://anarc.at/services/radio/#supysonic

That being said, it might be easier to configure once installed
properly as a system-wide package.

There are no upstream releases yet:

https://github.com/spl0k/supysonic/issues/147

I'd love someone else to take care of this, but I can sponsor, mentor,
help, or, ultimately, do it myself if no one else steps in.

Bug#926330: RFS: cuba/4.2-1 [ITP]

2019-04-05 Thread Sébastien Villemot

Le vendredi 05 avril 2019 à 12:06 +0200, Francesco Montanari a écrit :
> On 4/4/19 9:13 AM, Sébastien Villemot wrote:
>  > 2. Put the packaging on salsa.debian.org in the science-team group
>  >
> https://salsa.debian.org/science-team
> 
>  >(you’ll need someone to create the project for you, once you have
>  > joined the group; I can do that if you want)
> 
> Yes please, that'd great. (Just registered as fmnt-guest and requested
> access.)

Done: https://salsa.debian.org/science-team/cuba

I granted you Maintainer access on that project.

-- 
⢀⣴⠾⠻⢶⣦⠀  Sébastien Villemot
⣾⠁⢠⠒⠀⣿⡁  Debian Developer
⢿⡄⠘⠷⠚⠋⠀  http://sebastien.villemot.name
⠈⠳⣄  http://www.debian.org



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

Bug#926456: unblock: debian-timeline/42

2019-04-05 Thread Boyuan Yang

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: debian-public...@lists.debian.org

Please unblock debian-timeline 42. This is a native package handled by Debian
Publicity Team that aims to build https://timeline.debian.net/ .

--
Thanks,
Boyuan Yang


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

Bug#871223: [871223] neverball: Strange squares instead of stars in the goals point

2019-04-05 Thread Markus Koschany

On Wed, 20 Mar 2019 17:50:39 + Qwerty Chouskie
 wrote:
> After much research at 
> https://github.com/Neverball/neverball/issues/170, it seems this issue 
> only affects the Debian package for some reason, likely a weird compiler 
> bug or such.  Anyways, the solution seems to be a rebuild of the 
> package.  No changes are needed, just re-compiling seems to fix the 
> issue.  If a maintainer can do this, the bug can be closed.

Just for the record: A rebuild doesn't change anything. I don't believe
that is a compiler bug. More likely it is related to libgl1-mesa-glx
[libgl1].





signature.asc
Description: OpenPGP digital signature

Bug#809997: emscripten not installable on Debian/testing...

2019-04-05 Thread Sylvestre Ledru


Le 05/04/2019 à 17:05, Sebastian Rasmussen a écrit :

Hi!

I have been attempting to install emscripten today, and ended up the
libstdc++6 breakage.
Next I found this bug and I'm simply wondering what I can do to help
you guys make progress on this bug?
Unfortunately, I'm just a new user of emscripten so I barely know how
to use it once it is installed,
but if I can assist in any way please let me know. :)

The problem is that emscripten uses a fork of LLVM and I am reluctant to add
yet-a-new-version of llvm in the archive...

I have been waiting for the changes to be merged upstream and, with the recent
progress on webassembly, we are getting there...

S

Bug#809997: emscripten not installable on Debian/testing...

2019-04-05 Thread Sebastian Rasmussen

Hi!

I have been attempting to install emscripten today, and ended up the
libstdc++6 breakage.
Next I found this bug and I'm simply wondering what I can do to help
you guys make progress on this bug?
Unfortunately, I'm just a new user of emscripten so I barely know how
to use it once it is installed,
but if I can assist in any way please let me know. :)

 / Sebastian

1 2 >

1 - 100 of 158 matches

Mail list logo