Bug#897203: ripit: fails to handle directory name containing curly braces

[Elimar Riesebieter]

* Lars Kruse  [2018-04-30 01:58 +0200]:

> Package: ripit
> Version: 4.0.0~beta20140508-1
> Severity: normal
> Tags: patch
> 
> Dear Maintainer,
> 
> while trying to rip an album with a name containing curly braces ("{}"),
> ripit stopped with an error:
> 
>  Unescaped left brace in regex is illegal here in regex; marked by <--
>  HERE in m//foo { <-- HERE bar}.\d+/ at /usr/bin/ripit line 2958,  
> line 2.
> 
> Instead I expected the ripping process to continue as smoothly as usual.
> 
> The attached patch fixes the problem for me.

Thanks for the patch. Will include in next upload.

Elimar
-- 
.~.
/V\   L   I   N   U   X
   /( )\ >Phear the Penguin<
   ^^-^^


signature.asc
Description: PGP signature

Bug#897214: seafile-cli: Depends on python-ccnet which is not a listed as a dependency

[Jean-Francois Pirus]

Package: seafile-cli
Version: 6.1.5-1
Severity: grave
Tags: patch
Justification: renders package unusable

Dear Maintainer,

seafile stopped working after an upgrade of sid.

Required and install of "python-ccnet" which is not a listed dependency.




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

Kernel: Linux 4.15.0-3-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_NZ.utf8, LC_CTYPE=en_NZ.utf8 (charmap=UTF-8), 
LANGUAGE=en_NZ:en (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages seafile-cli depends on:
ii  ccnet   6.1.7-2
ii  libseafile0 6.1.5-1
ii  python  2.7.15~rc1-1
ii  python-searpc   3.0.8-4
ii  seafile-daemon  6.1.5-1

seafile-cli recommends no packages.

seafile-cli suggests no packages.

-- no debconf information

Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases

[Chris Lamb]

[adding Matthias to CC as he filed #883581]
[adding Holger to CC as he filed #886259]

Hi Scott,

Thanks for opening this!

> I understand (and agree with) the intent of this check, but in practice, it's
> harming the release.  I don't think it is salvageable.

This tag has quite a history:

 - https://bugs.debian.org/870822 — Added as P:
 - https://bugs.debian.org/883581 — P: → W:
 - https://bugs.debian.org/886259 — W: → I:
 - https://bugs.debian.org/897213 — removal requested (this bug)

I suppose one question would be: why not downgrade it and/or make
it more explicit that you shouldn't blindly remove it? :)


> There has been a lot of discussion on debian-devel about the future of
> python2.7 in Buster.  The dependency-on-python-version-marked-for-end-of-life
> flag is confusing people into thinking they should drop python2.7 support from
> their packages because it isn't going to be in Buster.

(Just out of interest, do you have any concrete examples? The
thread itself talks a lot about packages being removed with scant
citations.)


Regards,

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

Bug#895560: s3cmd has a runtime dependency on python3-distutils

[Matthias Klose]

Control: reopen -1
Control: retitle -1 s3cmd: avoid the runtime dependency on distutils

Please don't depend on distutils, when the dependency can be avoided at runtime.
See the attached patch.

diff -Nru s3cmd-2.0.1/debian/changelog s3cmd-2.0.1/debian/changelog
--- s3cmd-2.0.1/debian/changelog	2018-04-12 17:09:38.0 +
+++ s3cmd-2.0.1/debian/changelog	2018-04-30 05:31:16.0 +
@@ -1,3 +1,10 @@
+s3cmd (2.0.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Avoid the use of distutils at runtime.
+
+ -- Matthias Klose   Mon, 30 Apr 2018 07:31:16 +0200
+
 s3cmd (2.0.1-2) unstable; urgency=medium
 
   [ Nishanth Aravamudan  ]
diff -Nru s3cmd-2.0.1/debian/control s3cmd-2.0.1/debian/control
--- s3cmd-2.0.1/debian/control	2018-04-12 17:09:38.0 +
+++ s3cmd-2.0.1/debian/control	2018-04-30 05:31:10.0 +
@@ -16,7 +16,7 @@
 
 Package: s3cmd
 Architecture: all
-Depends: ${misc:Depends}, ${python3:Depends}, python3-distutils
+Depends: ${misc:Depends}, ${python3:Depends}
 Description: command-line Amazon S3 client
  Command-line tool to upload, retrieve and manage data in Amazon S3 service
  (http://www.amazon.com/s3/), designed for use in scripts. Features:
diff -Nru s3cmd-2.0.1/debian/patches/avoid-distutils.diff s3cmd-2.0.1/debian/patches/avoid-distutils.diff
--- s3cmd-2.0.1/debian/patches/avoid-distutils.diff	1970-01-01 00:00:00.0 +
+++ s3cmd-2.0.1/debian/patches/avoid-distutils.diff	2018-04-30 05:31:16.0 +
@@ -0,0 +1,20 @@
+--- a/s3cmd
 b/s3cmd
+@@ -57,7 +57,7 @@ import tempfile
+ from copy import copy
+ from optparse import OptionParser, Option, OptionValueError, IndentedHelpFormatter
+ from logging import debug, info, warning, error
+-from distutils.spawn import find_executable
++from shutil import which
+ 
+ from ssl import SSLError
+ import io
+@@ -2267,7 +2267,7 @@ def run_configure(config_file, args):
+ ]
+ ## Option-specfic defaults
+ if getattr(cfg, "gpg_command") == "":
+-setattr(cfg, "gpg_command", find_executable("gpg"))
++setattr(cfg, "gpg_command", which("gpg"))
+ 
+ if getattr(cfg, "proxy_host") == "" and os.getenv("http_proxy"):
+ autodetected_encoding = locale.getpreferredencoding() or "UTF-8"
diff -Nru s3cmd-2.0.1/debian/patches/series s3cmd-2.0.1/debian/patches/series
--- s3cmd-2.0.1/debian/patches/series	1970-01-01 00:00:00.0 +
+++ s3cmd-2.0.1/debian/patches/series	2018-04-30 05:29:55.0 +
@@ -0,0 +1 @@
+avoid-distutils.diff

Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases

[Matthias Klose]

I disagree that it should be removed.  There's no harm to add a phrase that
there might be no harm to keep the python2 package for the buster release.

Bug#897213: lintian: Please remove dependency-on-python-version-marked-for-end-of-life until after Buster releases

[Scott Kitterman]

Package: lintian
Version: 2.5.84
Severity: important

Dear Maintainer,

There has been a lot of discussion on debian-devel about the future of
python2.7 in Buster.  The dependency-on-python-version-marked-for-end-of-life
flag is confusing people into thinking they should drop python2.7 support from
their packages because it isn't going to be in Buster.

I understand (and agree with) the intent of this check, but in practice, it's
harming the release.  I don't think it is salvageable.

Scott K

Bug#897212: python-moinmoin: crash in account verification resend for accounts that don't have an account_verification attribute

[Paul Wise]

Package: python-moinmoin
Version: 1.9.9-1
Severity: important
Control: affects -1 wiki.debian.org
Usertags: crash

On wiki.debian.org, the link to re-send email verification mails
crashes when the account has already been verified:

https://wiki.debian.org/?action=newaccount&i=&resend=1

Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/werkzeug/wsgi.py", line 599, in 
__call__
return self.app(environ, start_response)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 264, in 
__call__
response = run(context)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 89, in run
response = dispatch(request, context, action_name)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 137, in 
dispatch
response = handle_action(context, pagename, action_name)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/wsgiapp.py", line 203, in 
handle_action
handler(context.page.page_name, context)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/action/newaccount.py", line 
259, in execute
mailok, msg = _send_verification_mail(request, theuser)
  File "/usr/lib/python2.7/dist-packages/MoinMoin/action/newaccount.py", line 
22, in _send_verification_mail
'v': user.account_verification}
AttributeError: User instance has no attribute 'account_verification'

-- System Information:
Debian Release: stretch

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#776240: pmount: bash completion hangs by grepping stdin

[Maxim Nikulin]

On Sun, 25 Jan 2015 23:54:02 +0300 Alexander Galanin wrote:
>
> bash completion for pmount hangs. The problem is in grepping stdin in
> line 62 of /etc/bash_completion.d/pmount:
> 
> devices="$( command ls $(grep -v '^[[:space:]]*#' /etc/pmount.allow ) 
> $(grep 1 /sys/block/*/removable | sed -e 
> 's,/sys/block/,/dev/,;s,/removable:1,*,') 2>/dev/null | sort -u | sed -e 
> 's,\(^/dev/\)\(.*\),\1\2 \2,' ; grep $mdir /proc/mounts | sed -e 
> 's,.*\($mdir/[^ ]*\).*,\1,' )"

It seems the problem was introduced in the commit 539bf17b for the bug 678713
"pumount tab completion doesn't support mounted paths" that was made in
the _pmount() function (line 62) instead of _pumount(), line 87.
See changelog entry:

> pmount (0.9.23-3) unstable; urgency=low
...
>   * Add bash completion for mounted paths in pumount (closes: #678713) .
> Thanks to Aaron Small <@> for the patch.
> 
>  -- Vincent Fourmond   Sun, 18 May 2014 10:03:13 +0200

Unfortunately original line 87 and the fix suggested in the bug 678713
has variable expansion $mdir prevented by single quotes

87c87
<   devices="$( grep $mdir /proc/mounts | sed -e 's,.*/$mdir/,,;s,\ 
.*,,;s,\(.*\),\1\n/dev/\1,;s,/dev//dev,/dev,' )"
---
>   devices="$( grep $mdir /proc/mounts | sed -e 's,.*/$mdir/,,;s,\ 
> .*,,;s,\(.*\),\1\n/dev/\1,;s,/dev//dev,/dev,';grep $mdir /proc/mounts | sed 
> -e 's,.*\($mdir/[^ ]*\).*,\1,' )"

Notice s,/dev//dev,/dev, that is necessary due to $mdir is not expanded to 
/media.
Moreover $mdir already contains leading slash so extra one leads to pattern
matching failure.

As I see the intention is provide /media completion option in addition
to /dev and directory name shortcut. The following variant works for me
unless I explicitly specify mount directory with e.g. spaces (otherwise
two of three completion options contain 040 sequence). I have found
tedious to get 3 variants for pumount when just one device is attached
that is why I have added one more "if" for immediate completion.

At least the _pmount() function should be reverted (first chunk),
_pumount() does its work even in the current state.

--- pmount.orig 2014-05-18 15:13:54.0 +0700
+++ pmount  2018-04-30 11:20:21.680935069 +0700
@@ -59,7 +59,7 @@
if [[ "$cur" == -* ]]; then
COMPREPLY=( $( compgen -W "$options" -- $cur ) )
else
-devices="$( command ls $(grep -v '^[[:space:]]*#' /etc/pmount.allow ) 
$(grep 1 /sys/block/*/removable | sed -e 
's,/sys/block/,/dev/,;s,/removable:1,*,') 2>/dev/null | sort -u | sed -e 
's,\(^/dev/\)\(.*\),\1\2 \2,' ; grep $mdir /proc/mounts | sed -e 's,.*\($mdir/[^
]*\).*,\1,' )"
+devices="$( command ls $(grep -v '^[[:space:]]*#' /etc/pmount.allow ) 
$(grep 1 /sys/block/*/removable | sed -e 
's,/sys/block/,/dev/,;s,/removable:1,*,') 2>/dev/null | sort -u | sed -e 
's,\(^/dev/\)\(.*\),\1\2 \2,' )"
COMPREPLY=( $( compgen -W "$devices" -- $cur ) )
fi

@@ -84,7 +84,13 @@
if [[ "$cur" == -* ]]; then
   COMPREPLY=( $( compgen -W "$options" -- $cur ) )
else
-  devices="$( grep $mdir /proc/mounts | sed -e 's,.*/$mdir/,,;s,\ 
.*,,;s,\(.*\),\1\n/dev/\1,;s,/dev//dev,/dev,' )"
+  if [ -z "$cur" -a 1 = "$(grep -c " $mdir" /proc/mounts)" ]; then
+ # Do not show variants if just one device is mounted, use /dev/sdXY.
+ devices="$(sed -n -e "s,^\([^ ]*\) \($mdir/\([^ ]*\)\) .*$,\1,p" 
/proc/mounts)"
+  else
+ # Add /dev, /media, and just shortcut entries. Caveat: only /dev 
works after pmount /dev/sdc1 "my usb"
+ devices="$(sed -n -e "s,^\([^ ]*\) \($mdir/\([^ ]*\)\) 
.*$,\1\n\2\n\3,p" /proc/mounts)"
+  fi
   COMPREPLY=( $( compgen -W "$devices" -- $cur ) )
fi

Bug#897211: stockfish completely messes up use of DEB_{BUILD,HOST}_*

[Helmut Grohne]

Source: stockfish
Version: 8-3
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

stockfish completely messes up the use of DEB_{BUILD,HOST}_* variables.

 * It does not set defaults for these variables. While dpkg-buildpackage
   sets them, running ./debian/rules directly is still permitted. In
   the latter case, the variables will be empty. An easy way to ensure
   that these variables are available is including
   /usr/share/dpkg/architecture.mk.
 * It confuses build and host breaking cross compilation. See man
   dpkg-architecture for when to use which.
 * It uses ARCH=general-32 for 64bit targets such as s390x or sparc64.
 * It generally uses loose matching on the architecture name rather than
   relevant aspects (e.g. matching only the cpu part).

The attached patch fixes a significant fraction of these issues while
trying hard not to introduce any accidental regressions. I recommend
moving further using constructs such as

ifneq (,$(filter $(DEB_HOST_ARCH_CPU),ia64 m68k))

to treat multiple architectures in the same way. The DEB_HOST_ARCH_CPU
variable is subtly different from the DEB_HOST_ARCH. When in doubt,
check the output of dpkg-architecture -a$somearch.

Please consider applying the attached patch.

Helmut
diff --minimal -Nru stockfish-8/debian/changelog stockfish-8/debian/changelog
--- stockfish-8/debian/changelog2016-11-12 18:55:54.0 +0100
+++ stockfish-8/debian/changelog2018-04-30 06:53:28.0 +0200
@@ -1,3 +1,10 @@
+stockfish (8-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix us of DEB_{BUILD,HOST}_* variables; closes: #-1.
+
+ -- Helmut Grohne   Mon, 30 Apr 2018 06:53:28 +0200
+
 stockfish (8-3) unstable; urgency=low
 
   * Set architecture bits from dpkg-architecture.
diff --minimal -Nru stockfish-8/debian/rules stockfish-8/debian/rules
--- stockfish-8/debian/rules2016-11-12 11:45:57.0 +0100
+++ stockfish-8/debian/rules2018-04-30 06:53:26.0 +0200
@@ -9,64 +9,64 @@
 # Uncomment this to turn on verbose mode.
 # export DH_VERBOSE=1
 
-DEB_BUILD_ARCH := $(shell dpkg-architecture -qDEB_BUILD_ARCH)
+include /usr/share/dpkg/architecture.mk
 
-TARGET := profile-build ARCH=general-$(shell dpkg-architecture 
-qDEB_HOST_ARCH_BITS)
+TARGET := profile-build ARCH=general-$(DEB_HOST_ARCH_BITS)
 
-ifneq (,$(findstring i386,$(DEB_BUILD_ARCH)))
+ifeq (i386,$(DEB_HOST_ARCH_CPU))
 TARGET := profile-build ARCH=x86-32-old
 endif
 
-ifneq (,$(findstring amd64,$(DEB_BUILD_ARCH)))
+ifneq (,$(findstring amd64,$(DEB_HOST_ARCH)))
 TARGET := profile-build ARCH=x86-64
 endif
 
 # no compile on the first shot so building without profile
-ifneq (,$(findstring hppa,$(DEB_BUILD_ARCH)))
-TARGET := build ARCH=general-32
+ifeq (hppa,$(DEB_HOST_ARCH_CPU))
+TARGET := build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
 # no compile on the first shot
-ifneq (,$(findstring powerpc,$(DEB_BUILD_ARCH)))
-TARGET := build ARCH=general-32
+ifneq (,$(findstring powerpc,$(DEB_HOST_ARCH_CPU)))
+TARGET := build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
-ifneq (,$(findstring s390,$(DEB_BUILD_ARCH)))
-TARGET := profile-build ARCH=general-32
+ifneq (,$(findstring s390,$(DEB_HOST_ARCH_CPU)))
+TARGET := profile-build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
-ifneq (,$(findstring sparc,$(DEB_BUILD_ARCH)))
-TARGET := build ARCH=general-32
+ifneq (,$(findstring sparc,$(DEB_HOST_ARCH_CPU)))
+TARGET := build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
-ifneq (,$(findstring mips,$(DEB_BUILD_ARCH)))
-TARGET := profile-build ARCH=general-32
+ifneq (,$(findstring mips,$(DEB_HOST_ARCH_CPU)))
+TARGET := profile-build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
 # Profiling fails due to compiler issues
-ifneq (,$(findstring mipsel,$(DEB_BUILD_ARCH)))
-TARGET := build ARCH=general-32
+ifneq (,$(findstring mipsel,$(DEB_HOST_ARCH_CPU)))
+TARGET := build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
-ifneq (,$(findstring alpha,$(DEB_BUILD_ARCH)))
-TARGET := build ARCH=general-64
+ifeq (alpha,$(DEB_HOST_ARCH_CPU))
+TARGET := build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
 # no compile on the first shot
-ifneq (,$(findstring armel,$(DEB_BUILD_ARCH)))
-TARGET := build ARCH=general-32
+ifneq (,$(findstring armel,$(DEB_HOST_ARCH)))
+TARGET := build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
-ifneq (,$(findstring armhf,$(DEB_BUILD_ARCH)))
-TARGET := build ARCH=general-32
+ifneq (,$(findstring armhf,$(DEB_HOST_ARCH)))
+TARGET := build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
-ifneq (,$(findstring ia64,$(DEB_BUILD_ARCH)))
-TARGET := profile-build ARCH=general-64 optimize=no
+ifeq (ia64,$(DEB_HOST_ARCH_CPU))
+TARGET := profile-build ARCH=general-$(DEB_HOST_ARCH_BITS) optimize=no
 endif
 
-ifneq (,$(findstring m86k,$(DEB_BUILD_ARCH)))
-TARGET := build ARCH=general-32
+ifeq (m68k,$(DEB_HOST_ARCH_CPU))
+TARGET := build ARCH=general-$(DEB_HOST_ARCH_BITS)
 endif
 
 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))

Bug#897210: nitrokey-app: Need to coordinate move of udev rule to libnitrokey

[Scott Kitterman]

Package: nitrokey-app
Version: 1.2-1
Severity: important

Nitrokey has released libnitrokey 3.3 and nitrokey-app 1.3.  They moved the
udev rule to the lib.  I have created a package and will upload it to
experimental.  Unfortunately, it has to go through New, so I don't know when
it will be there.

In the meantime, it's in git:  https://salsa.debian.org/kitterman/libnitrokey

I would appreciate it if you would review the upstream provided udev rule and
see what changes you would recommend (since I recall you patched the rule in
nitrokey-app).

Also, please take a look and see if nitrokey-app 1.3 works with libnitrokey
3.3.  Once I have confirmation, I'll upload to unstable.

Thanks,

Scott K

Bug#894770: alternative workaround

[bugs]

For those who need to get work done but are stuck due to this bug
here is an alternative work around that I was previously unaware of.
(I know this isn't exactly bug information but it will probably
 help quite a few people that arrive on this page looking for a solution)

Just install the package arduino-mk

You can compile upload and monitor arduino sketches using Makefile.
There are several tutorials around, here is one that I found.
https://hardwarefun.com/tutorials/compiling-arduino-sketches-using-makefile

This works well for me on debian buster.

Bug#897208: cdtool.1: Some fixes of the manual

[Bjarni Ingi Gislason]

Dear Maintainer,

  I sent the wrong file in the attachment in the earlier e-mail.

-- 
Bjarni I. Gislason
--- cdtool.12018-04-22 18:54:11.0 +
+++ cdtool.1.new2018-04-29 03:15:58.0 +
@@ -6,51 +6,52 @@
 cdtool \- play and catalog audio CDROMs on CDROM drive(s)
 .SH SYNOPSIS
 .nf
-\fBcdeject\fR   [-[0..9]|-d device]  [-V|-?|-h]
-\fBcdclose\fR   [-[0..9]|-d device]  [-V|-?|-h]
-\fBcdir\fR -n   [-[0..9]|-d device]  [-r|-s|-t|-V|-?|-h]
-\fBcdinfo\fR[-[0..9]|-d device]  [-a|-r|-s|-t|-v|-V|-?|-h]
-\fBcdpause\fR   [-[0..9]|-d device]  [-V|-?|-h]
-\fBcdplay\fR[-[0..9]|-d device]  [\fIstart\fR [\fIstop\fR]
-\fBcdplay\fR[-[0..9]|-d device]  [\fI+|-\fR \fInumber\fR]
-\fBcdplay\fR[-[0..9]|-d device]  [start|stop|resume|eject|close|info|dir] 
-\fBcdplay\fR[-[0..9]|-d device]  [-V|-?|-h]
-\fBcdstop\fR[-[0..9]|-d device]  [-V|-?|-h]
-\fBcdvolume\fR  [-[0..9]|-d device]  [-V|-?|-h|\fIlevel\fR]
-\fBcdshuffle\fR [-[0..9]|-d device]  [-V|-?|-h]
+\fBcdeject\fR   [\-[0..9]|\-d device]  [\-V|\-?|\-h]
+\fBcdclose\fR   [\-[0..9]|\-d device]  [\-V|\-?|\-h]
+\fBcdir\fR \-n   [\-[0..9]|\-d device]  [\-r|\-s|\-t|\-V|\-?|\-h]
+\fBcdinfo\fR[\-[0..9]|\-d device]  [\-a|\-r|\-s|\-t|\-v|\-V|\-?|\-h]
+\fBcdpause\fR   [\-[0..9]|\-d device]  [\-V|\-?|\-h]
+\fBcdplay\fR[\-[0..9]|\-d device]  [\,\fIstart\/\fR [\,\fIstop\/\fR]
+\fBcdplay\fR[\-[0..9]|\-d device]  [\,\fI+|\-\/\fR \,\fInumber\/\fR]
+\fBcdplay\fR[\-[0..9]|\-d device]  
[start|stop|resume|eject|close|info|dir] 
+\fBcdplay\fR[\-[0..9]|\-d device]  [\-V|\-?|\-h]
+\fBcdstop\fR[\-[0..9]|\-d device]  [\-V|\-?|\-h]
+\fBcdvolume\fR  [\-[0..9]|\-d device]  [\-V|\-?|\-h|\,\fIlevel\/\fR]
+\fBcdshuffle\fR [\-[0..9]|\-d device]  [\-V|\-?|\-h]
 
 .fi
 .SH DESCRIPTION
-The 
+The
 .I cdeject
 command ejects the current compact disc.
 .PP
-The 
+The
 .I cdclose
 command closes the CDROM tray.
 .PP
 The
 .I cdir
 command lists information about the currently loaded audio compact disc.
-In particular, it lists the lengths of all tracks. 
+In particular, it lists the lengths of all tracks.
 It also references the database files specified in the
 .B CDTOOLPATHDB
 environment variable and the
 .B ~/.cdtooldb
 file, which use a simplified version of the format used by
-.IR workman(1).
-If one of these files contains an entry for the current compact disc, 
-.I cdir 
+.IR workman (1).
+If one of these files contains an entry for the current compact disc,
+.I cdir
 will print title, artist, and track name information.
 .RS
-.IP \fB-n\fR
+.IP \fB\-n\fR
 Do not lookup any information in the database files.
-.IP \fB-s\fR
+.IP \fB\-s\fR
 Print information in a short format: only author, title, and current
 track, all on one line.
-.IP \fB-t\fR
+.IP \fB\-t\fR
 Print a template for the current cd, including title, artist, and track name
-information if available. If blank lines are filled in, this can be appended 
to the
+information if available.
+If blank lines are filled in, this can be appended to the
 .B ~/.cdtooldb
 file.
 .RE
@@ -59,19 +60,19 @@ The
 .I cdinfo
 command, with no option used, will print out the audiostatus (playing, etc.).
 .RS
-.IP \fB-a\fR
+.IP \fB\-a\fR
 Print out the absolute disc time.
-.IP \fB-r\fR
+.IP \fB\-r\fR
 Print out the relative track time.
-.IP \fB-s\fR
+.IP \fB\-s\fR
 Print out the audiostatus.
-.IP \fB-t\fR
+.IP \fB\-t\fR
 Print out the current track.
-.IP \fB-v\fR
+.IP \fB\-v\fR
 All info: \fBstatus track absolute relative\fR.
 .RE
 .PP
-The 
+The
 .I cdpause
 command pauses the currently playing compact disc.  Resume by using
 .I cdplay
@@ -81,12 +82,15 @@ The
 .I cdplay
 command plays the compact disc.  If called with one argument, this is
 the starting track number.  If called with two arguments, these are the
-starting and stopping track numbers. If the first argument is a
+starting and stopping track numbers.
+If the first argument is a
 .B +
 or
-.B -
-then skip the number of tracks given by the second argument forward or 
-backward. If no second argument is give, skip one. A
+.B \-
+then skip the number of tracks given by the second argument forward or
+backward.
+If no second argument is given, skip one.
+A
 .B 0
 as first argument or no argument replays current track.
 .PP
@@ -96,39 +100,41 @@ command stops the compact disc, if it is
 .PP
 The
 .I cdvolume
-command sets the output volume level of the CD player.  The level is an 
+command sets the output volume level of the CD player.  The level is an
 integer from 0 to 255.
 .PP
-The 
+The
 .I cdshuffle
 command plays the audio tracks on the disc in random order.
 .PP
 The default device opened is \fB/dev/cdrom\fR.  This default and others
-may be changed in \fIconfig.h\fR. Options supported by all programs are:
+may be changed in 
+.IR config.h .
+Options supported by all programs are:
 .RS
-.IP "\fB-[0..7]\fR"
+.IP "\fB\-[0..7]\fR"
 Multiple cdrom support to open \fB/dev/scd0../dev/scd7\fR [by default].
-.IP "\fB-d device\fR"
+.IP "

Bug#897209: poedit FTCBFS: broken, outdated, embedded copy of AX_BOOST_BASE

[Helmut Grohne]

Source: poedit
Version: 2.0.6-1
User: helm...@debian.org
Usertags: rebootstrap

poedit fails to cross build from source, because it uses a broken,
outdated, embedded copy of AX_BOOST_BASE (admin/ax_boost_base.m4). The
copy is affected by #872256 and the problem is described in that bug
report.

Please consider removing the embedded copy as recommended by the Debian
policy. Alternatively, please update it to fix your copy of #872256 and
get your copy registered at https://wiki.debian.org/EmbeddedCodeCopies.

This bug report comes without a patch, because the actual bug is already
fixed.

Helmut

Bug#897151: Package erroneously expects googletest headers in /usr/include

[GCS]

Control: tags -1 +pending

On Mon, Apr 30, 2018 at 5:37 AM Andres Salomon  wrote:
> Protobuf 3.0.0-9.1 (the version in unstable) already depends upon
> libgtest-dev; the FTBFS is due to a missing build-dependency
> on libgmock-dev.

> The version of protobuf in experimental (3.5.2-2) includes a build-dep
> on both libgtest-dev and libgmock-dev, so it should build properly
> with the latest googletest.
  Yes, the experimental version builds correctly[1]. Thanks Steve for
reporting it, but I've already fixed this.
The Sid upload is pending due to soname change.

Regards,
Laszlo/GCS
[1]
https://buildd.debian.org/status/package.php?p=protobuf&suite=experimental

Bug#897208: cdtool.1: Some fixes of the manual

[Bjarni Ingi Gislason]

Package: cdtool
Version: 2.1.8-release-5
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

  Warning about only one argument for the two-fonts macro "IR".

  The patch is in the attachment.

  Summary:

Input file is cdtool.1

  Spelling: give -> given

  Remove space characters at the end of lines.

  Separate the roman part from the only argument of the macro "IR".

  Use macros instead of the escapes "\fX".

  Change '-' to '\-' for options.

  Shorten lines longer than 80 characters.

  Begin sentences on a new line when only one space character is in
front of them.

  Add space in front of a tab to get the formatting correct (troff).

###

 MORE DETAILS

Test nr. 1:

Remove space at end of lines.

Use "git apply ... --whitespace=fix" to fix extra space issues, or use
global configuration "core.whitespace".

16:\fBcdplay\fR[-[0..9]|-d device]  
[start|stop|resume|eject|close|info|dir] 
24:The 
28:The 
35:In particular, it lists the lengths of all tracks. 
42:If one of these files contains an entry for the current compact disc, 
43:.I cdir 
74:The 
88:then skip the number of tracks given by the second argument forward or 
99:command sets the output volume level of the CD player.  The level is an 
102:The 
121:.B ~/.cdtooldb 
124:.B CDTOOLDBPATH 
125:- colon delimited path of database files to search.  It is not necessary to 
126:specify 
127:.BR ~/.cdtooldb , 
130:.B CDTOOLDEV 

#

Test nr. 2:

Enable and fix warnings from 'test-groff'.

Input file is /tmp/cdtool.1

:41 (macro IR): only 1 argument, but more are expected

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

  and

Test nr. 15:

Change the name of a macro for two fonts (e.g., BR and IR) to one
letter, if there is only one argument.
Add the second argument if needed.  It is sometimes part of the first
one.

41:.IR workman(1).

#

Test nr. 20:

Use a macro to change to the italic font, instead of \fI [1], if
possible.
The macros have the italic corrections, but "\c" removes them
  or
add the italic corrections.
[1] man-pages(7) [package "manpages"]

14:\fBcdplay\fR[-[0..9]|-d device]  [\fIstart\fR [\fIstop\fR]
15:\fBcdplay\fR[-[0..9]|-d device]  [\fI+|-\fR \fInumber\fR]
19:\fBcdvolume\fR  [-[0..9]|-d device]  [-V|-?|-h|\fIlevel\fR]
107:may be changed in \fIconfig.h\fR. Options supported by all programs are:

#

Test nr. 24:

Change a HYPHEN-MINUS (code 0x55, 2D) to a minus (\-), if in front of a
name for an option.

11:\fBcdir\fR -n   [-[0..9]|-d device]  [-r|-s|-t|-V|-?|-h]
46:.IP \fB-n\fR
48:.IP \fB-s\fR
51:.IP \fB-t\fR
62:.IP \fB-a\fR
64:.IP \fB-r\fR
66:.IP \fB-s\fR
68:.IP \fB-t\fR
70:.IP \fB-v\fR
111:.IP "\fB-d device\fR"
115:.IP "\fB-V\fR"
117:.IP "\fB-D\fR"

#

Test nr. 27:

Split lines longer than 80 characters into two or more lines.
Appropriate break points are the end of a sentence and a subordinate
clause.

cdtool.1: line 53   length 83

#

Test nr. 28:

Wrong distance between sentences or protect the indicator.

1) Separate the sentences and subordinate clauses; each begins on a new
line.  See man-pages(7) [package "manpages"] and "info groff".

Or

2) Adjust space between sentences (two spaces),

3) or protect the indicator by adding "\&" after it.

The "indicator" is an "end-of-sentence character" (.!?).

53:information if available. If blank lines are filled in, this can be appended 
to the
84:starting and stopping track numbers. If the first argument is a
89:backward. If no second argument is give, skip one. A
107:may be changed in \fIconfig.h\fR. Options supported by all programs are:
146:Daniel R. Risacher  

#

Test nr. 30:

Surround a block of comments with the macros ".ig" and "..".
The .\" (\#) at the beginning of each line is then not needed.
Makes it easier to add and remove text and adjust length of lines.

NO PATCH

2:.\" manual page copyright 1994 thomas insel
3:.\" copyright 1995,96 sven oliver moll
4:.\" copyright 1997, 1998 Wade Hampton and Dan Risacher

#

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

Kernel: Linux 4.9.82-1u3 (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 cdtool depends on:
ii  libc6  2.27-3

cdtool recommends no packages.

cdtool suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason


bug.cdtool.1
Description: Unix manual page

Bug#897151: Package erroneously expects googletest headers in /usr/include

[Andres Salomon]

Hi,

Protobuf 3.0.0-9.1 (the version in unstable) already depends upon
libgtest-dev; the FTBFS is due to a missing build-dependency
on libgmock-dev.

The version of protobuf in experimental (3.5.2-2) includes a build-dep
on both libgtest-dev and libgmock-dev, so it should build properly
with the latest googletest.

Bug#897191: [Debichem-devel] Bug#897191: pymol: autopkgtest times out with new version while succeeded in the past

[Stuart Prescott]

Hi all,

> With the upload of version 2.1.0+dfsg-1 of pymol, the autopkgtest¹
> started to fail due to it timing out (> 11 hours) on 4 of the tests and
> additionally due to unexpected output to stderr (see the relevant part
> of the log copied below). Previous versions only required a couple of
> minutes. Therefore I assume a lot of tests got added (albeit no note in
> the changelog about that), otherwise it is really worth it to try and
> find out why it now takes so much longer.
> 
> A note about time outs. Time outs can often be worked around by
> splitting a test into multiple autopkgtest because each gets its own
> timeout. On the other hand, is 11 hours or more really worth it?
> Couldn't a limited set of the test be run?

This doesn't appear to actually be a case of a test that is simply slow but a 
test that has hung.

Adding 'set -x' to the test runner shows that it gets stuck (for the first 
time) on

pymol-2.1.0+dfsg/examples/cookbook/scenes2movie.pml

Running that script by hand shows why -- it's playing the movie in a loop 
forever. Does someone know pymol well enough to say that the "mplay" syntax 
has changed or how to limit the movie to just one run through? 

> Output to stderr normally causes a test to fail. One can overrule that
> by add allow-stderr to the test Restrictions if the output is expected
> and to be ignored.

The stderr output also indicates that the test runner think that the test run 
has failed. Once more with set -x in place, the runner is not finding 'PyMOL: 
normal program termination.' in the pymol output. 

Andreas, as the uploader of the current version, do you have a log from your 
local run of the autopkgtests so that we can compare it to the current one on 
ci.d.n and see if there's an obvious difference? (Also, was deleting the Vcs-* 
fields from d/control with a commit titled "Standards-Version: 4.1.4" 
intentional?)

cheers
Stuart

-- 
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 
F2F7pymol-2.1.0+dfsg/examples/cookbook/scenes2movie.pml

Bug#865855: New version of tablib ready for review/upload

[Joseph Herlant]

Hi guys,

I updated the package to use standard branches, pybuild, autopkgtest,
make it run with python3 and get the latest version in.
I pushed it to the following repository:
https://salsa.debian.org/python-team/modules/python-tablib
Let me know if it's acceptable.

If so https://salsa.debian.org/openstack-team/python/python-tablib can
be dropped.

Let me know what you think.

Thanks for your help,
Joseph

Bug#886865: Bug#896969: Info received (Bug#896969: Acknowledgement (nlohmann-json: Version 3.1.2 is now available - any reason not to update?))

[Wookey]

On 2018-04-28 18:24 +0200, Muri Nicanor wrote:
> Hi Wookey,
> 
> sorry for the delay- there is an ITP for nlohmann-json3
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886865

Ah yes. Well, it looks like I've done that work 'accidentally' :-). 

Should this conflict with nlohmann-json, so only one or the other can
be installed? If both can be installed then they need different paths,
and software will fail to find the headers unless it is modified to use a
#include "nlohmann3/json.hpp" or similar.

If we go for that then a new nlohmann-json needs uploading which also
conflicts with nlohmann-json3.

nlohmann-json3 provides both a single-file interface and a multiple-file 
interface.

horizon-eda expects the multiple-header interface (it includes
nlohmann/json_fwd.hpp as well as nlohmann/json.hpp). I don't know this
package well enough to know whether providing the multiple-header
interface works for all the programs that expect to just include
nlohmann/json.hpp and get everything?

Maybe we ned to provide two (conflicting again?) json-dev packages:
nlhomann-json3-single-dev and nlohmann-json3-dev (or whatever) to
satisfy everyone (hopefully not - that seems excessive)

I've updated the copyright for new files in v3.1.2 as well as the
couple of small fixes for the build.

And the changes for nlohmann-json -> nlohmann-json3
 (Except I think the watch file is probably wrong now)

OK. Suggested patch file for that attached. This one installs the
multiple-file headers. I've also uploaded it to:
http://wookware.org/software/repo/ if you want to download it/install
it as-is.
http://wookware.org/software/repo/pool/main/n/nlohmann-json3/

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/
diff -Nru nlohmann-json-2.0.6/debian/changelog nlohmann-json3-3.1.2/debian/changelog
--- nlohmann-json-2.0.6/debian/changelog	2016-10-23 21:49:30.0 +0100
+++ nlohmann-json3-3.1.2/debian/changelog	2018-04-27 04:49:55.0 +0100
@@ -1,3 +1,9 @@
+nlohmann-json3 (3.1.2-1) unstable; urgency=medium
+
+  * New upstream release
+
+ -- Wookey   Fri, 27 Apr 2018 04:49:55 +0100
+
 nlohmann-json (2.0.6-1) unstable; urgency=medium
 
   * New upstream version 2.0.5
diff -Nru nlohmann-json-2.0.6/debian/control nlohmann-json3-3.1.2/debian/control
--- nlohmann-json-2.0.6/debian/control	2016-09-12 17:07:25.0 +0100
+++ nlohmann-json3-3.1.2/debian/control	2018-04-27 04:49:55.0 +0100
@@ -1,4 +1,4 @@
-Source: nlohmann-json
+Source: nlohmann-json3
 Priority: optional
 Maintainer: Muri Nicanor 
 Build-Depends:
@@ -6,18 +6,18 @@
  doxygen,
  ghostscript,
  graphviz,
- re2c,
  texlive-binaries,
  texlive-latex-base,
 Standards-Version: 3.9.8
 Section: libs
 Homepage: https://nlohmann.github.io/json/
 
-Package: nlohmann-json-dev
+Package: nlohmann-json3-dev
 Section: libdevel
 Architecture: all
 Depends:
- ${misc:Depends},
+ ${misc:Depends}
+Conflicts: nlohmann-json-dev
 Description: JSON for Modern C++
  JSON library with intuitive syntax, trivial integration and serious
  testing. Other aspects, as memory efficiency and speed were not so
diff -Nru nlohmann-json-2.0.6/debian/copyright nlohmann-json3-3.1.2/debian/copyright
--- nlohmann-json-2.0.6/debian/copyright	2016-09-12 17:07:25.0 +0100
+++ nlohmann-json3-3.1.2/debian/copyright	2018-04-27 04:49:55.0 +0100
@@ -3,7 +3,15 @@
 Source: https://github.com/nlohmann/json
 
 Files: *
-Copyright: 2013-2016 Niels Lohmann
+Copyright: 2013-2018 Niels Lohmann
+License: MIT
+
+Files: include/nlohmann/detail/conversions/to_chars.hpp
+Copyright: 2009 Florian Loitsch
+License: MIT
+
+Files: include/nlohmann/detail/output/serializer.hpp
+Copyright: 2008-2009 Bjoern Hoehrmann 
 License: MIT
 
 Files: debian/*
@@ -14,6 +22,10 @@
 Copyright: 2015 Christopher Gilbert
 License: MIT
 
+Files: benchmarks/thirdyparty/benchmark/*
+Copyright: Numerous, listed in benchmarks/thirdyparty/benchmark/AUTHORS
+License: Apache-2.0
+
 Files: benchmarks/cxxopts.hpp
 Copyright: 2014 Jarryd Beck
 License: MIT
@@ -22,15 +34,39 @@
 Copyright: 2015 Louis Dionne
 License: BSL-1.0
 
-Files: test/src/catch.hpp
-Copyright: 2012 Two Blue Cubes Ltd. All rights reserved.
- Phil Nash 
-License: BSL-1.0
+Files: test/data/nst_json_testsuite/*
+Copyright: 2016 Nicolas Seriot
+License: MIT
 
 Files: test/data/json_testsuite/*
 Copyright: Yidong Fang
 License: Apache-2.0
 
+Files: test/data/markus_kuhn/UTF-8-test.txt
+Copyright: 2015 Markus Kuhn 
+License: CC-BY-4.0
+
+Files: test/data/big-list-of-naughty-strings/LICENSE*
+Copyright: 2015 Max Woolf
+License: MIT
+
+Files: test/data/json-patch-tests/README.md
+Copyright: 2014 The Authors
+License: Apache-2.0
+
+Files: test/thirdparty/catch/catch.hpp
+Copyright: 2012 Two Blue Cubes Ltd.
+ Phil Nash 
+License: BSL-1.0
+
+Files: test/thirdparty/Fuzzer
+Copyright: University of Illinois at Urbana-Champaign
+License: U-OF-I-BSD-LIKE
+
+Files: third_party/amalgamate/*
+Copyright: 2012, Erik Edlund 
+License: BSD-3-clause
+
 License: MIT
  

Bug#845297: Migration to Salsa

[Paul Wise]

On Mon, Apr 30, 2018 at 12:29 AM, Alex Muntada wrote:

> Thanks for pointing that out. I've been studying smart_change.pl
> and I couldn't find where that commit you mention is happening.

The commit is done after smart_change.pl is run, by the person who is
making the change. So if we use git commit ids in the headers that
smart_change.pl writes, they need to refer to a future commit that
hasn't happened yet, whose date is unknown and therefore whose SHA-1
hash is unknowable because it depends on the date.

> Could you elaborate a bit more on the git file+metafile details?
> I'm not following you, sorry.

Each file in a git tree is associated with a hash of some data that is
the file contents prefixed with a header containing the object type
('blob' for files), a space, the file size and a NUL character.
Storing these blob object hashes in the translation-check headers
would allow us to calculate them before commits (as smart_change.pl
does with CVS revision numbers). The machinery behind the translation
comparison stuff can then easily do a git diff between the two object
hashes. Since these git object hashes refer to individual files not
trees, they work more like CVS revision numbers than git commit hashes
do. The main question is, are they compatible with all of the VCS
operations used by the translation stuff (I think they are)?

https://git-scm.com/book/en/v2/Git-Internals-Git-Objects

The script converting all existing translation-check headers from CVS
revision numbers to git object hashes would also be more complicated,
since the cvs-revisions file produced by the git conversion contains
filenames, CVS revision IDs and corresponding git commits. So, we have
to run `git ls-tree` for each line in cvs-revisions to get the object
hashes to put into translation-check headers.

git ls-tree -zr 7c95dc979cd7184ec4f20b0dd37e73e001a22d4f
TRANSLATING.pages | cut -zf1 | cut -z -d' ' -f3

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#897207: nvidia-driver: redshift is now greenshift

[Heikki Hokkanen]

Package: nvidia-driver
Version: 390.48-2~bpo9+1
Severity: normal

Dear Maintainer,

After upgrading nvidia-driver from backports to version 390.48-2~bpo9+1,
redshift is no longer red, but green. It kind of ruins the whole
experience.


-- Package-specific info:
uname -a:
Linux vili 4.9.0-6-amd64 #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64
GNU/Linux

/proc/version:
Linux version 4.9.0-6-amd64 (debian-ker...@lists.debian.org) (gcc version
6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.82-1+deb9u3
(2018-03-02)

/proc/driver/nvidia/version:
NVRM version: NVIDIA UNIX x86_64 Kernel Module  390.48  Thu Mar 22 00:42:57
PDT 2018
GCC version:  gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)

lspci 'display controller [030?]':
00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200
v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev
06) (prog-if 00 [VGA controller])
 Subsystem: Gigabyte Technology Co., Ltd Xeon E3-1200 v3/4th Gen Core
Processor Integrated Graphics Controller [1458:d000]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx+
 Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
 Kernel driver in use: i915
 Kernel modules: i915

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GM107 [GeForce
GTX 750 Ti] [10de:1380] (rev a2) (prog-if 00 [VGA controller])
 Subsystem: Gigabyte Technology Co., Ltd GM107 [GeForce GTX 750 Ti]
[1458:362d]
 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
 Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
 Kernel driver in use: nvidia
 Kernel modules: nvidia

dmesg:

Device node permissions:
crw-rw+ 1 root video 226,   0 Apr 30 04:44 /dev/dri/card0
crw-rw+ 1 root video 226,   1 Apr 30 04:44 /dev/dri/card1
crw-rw  1 root video 226,  64 Apr 30 04:44 /dev/dri/controlD64
crw-rw+ 1 root video 226, 128 Apr 30 04:44 /dev/dri/renderD128
crw-rw+ 1 root video 226, 129 Apr 30 04:44 /dev/dri/renderD129
crw-rw-rw-  1 root root  195, 254 Apr 30 04:45 /dev/nvidia-modeset
crw-rw-rw-  1 root root  195,   0 Apr 30 04:45 /dev/nvidia0
crw-rw-rw-  1 root root  195, 255 Apr 30 04:45 /dev/nvidiactl
video:x:44:hoxu,hoxugames

OpenGL and NVIDIA library files installed:
lrwxrwxrwx 1 root root   15 Nov 18 10:33 /etc/alternatives/glx ->
/usr/lib/nvidia
lrwxrwxrwx 1 root root   42 Nov 18 10:33
/etc/alternatives/glx--libEGL.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   44 Nov 18 10:33
/etc/alternatives/glx--libEGL.so.1-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libEGL.so.1
lrwxrwxrwx 1 root root   48 Nov 18 10:33
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu ->
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   48 Nov 18 10:33
/etc/alternatives/glx--libGL.so-x86_64-linux-gnu ->
/usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so
lrwxrwxrwx 1 root root   41 Nov 18 10:33
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   41 Nov 18 10:33
/etc/alternatives/glx--libGL.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Nov 18 10:33
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   43 Nov 18 10:33
/etc/alternatives/glx--libGL.so.1-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1
lrwxrwxrwx 1 root root   48 Nov 18 10:33
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   48 Nov 18 10:33
/etc/alternatives/glx--libGLESv1_CM.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Nov 18 10:33
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   50 Nov 18 10:33
/etc/alternatives/glx--libGLESv1_CM.so.1-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv1_CM.so.1
lrwxrwxrwx 1 root root   45 Nov 18 10:33
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   45 Nov 18 10:33
/etc/alternatives/glx--libGLESv2.so.2-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Nov 18 10:33
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   47 Nov 18 10:33
/etc/alternatives/glx--libGLESv2.so.2-x86_64-linux-gnu ->
/usr/lib/x86_64-linux-gnu/nvidia/libGLESv2.so.2
lrwxrwxrwx 1 root root   49 Nov 18 10:33
/etc/alternatives/glx--libnvidia-cfg.so.1-i386-linux-gnu ->
/usr/lib/i386-linux-gnu/nvidia/libnvidia-cfg.so.1
lrwxrwxrwx 1 root

Bug#897206: libccnet0:amd64: libccnet0 breaks package system in multiarch setting

[Francois Gouget]

Package: libccnet0
Version: 6.0.2-2
Severity: important

Dear Maintainer,

libccnet0 is marked as Multi-Arch: same but its postinst and preinst scripts
call pycompile and pyclean without specifying the package architecture. As a
result if libccnet0 is installed for more than one architecture the package 
name is ambiguous, causing the postinst and prerm scripts fail.

This then prevents any package from being installed or removed, thus breaking
the system permanently.


The solution is to replace the following line in 
/var/lib/dpkg/info/libccnet0:*.postinst

pycompile -p libccnet0
with
pycompile -p libccnet0:$DPKG_MAINTSCRIPT_ARCH 

And the following line in /var/lib/dpkg/info/libccnet0:*.prerm

pyclean -p libccnet0 
with
pyclean -p libccnet0:$DPKG_MAINTSCRIPT_ARCH 


See also bug #770625 which shows how this same bug was fixed in gir1.2-ibus-1.0.


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

Kernel: Linux 4.9.0-3-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)

Versions of packages libccnet0:amd64 depends on:
ii  libc6   2.24-11+deb9u3
ii  libevent-2.0-5  2.0.21-stable-3
it  libglib2.0-02.50.3-2
ii  libjansson4 2.9-1
ii  libsearpc1  3.0.8-1
ii  libsqlite3-03.16.2-5+deb9u1
ii  libuuid12.29.2-1+deb9u1
ii  python  2.7.13-2
ii  python-searpc   3.0.8-1

libccnet0:amd64 recommends no packages.

libccnet0:amd64 suggests no packages.

-- no debconf information

Bug#896988: RFS: nautilus-hide/0.2.3-3

[Sergio Durigan Junior]

On Saturday, April 28 2018, Carlos Maddela wrote:

> On 29/04/18 07:11, Sergio Durigan Junior wrote:
>> By the way, if you want to move your packages repositories from your
>> private namespace to the Debian namespace on salsa, just let me know and
>> I can create the proper repos and give you authorization.  This applies
>> to any package that you maintain, of course.
>> 
>
> Thanks for sponsoring and your offer. Yes, I'd appreciate it if you
> created them for me.

No problem.  I created:

  https://salsa.debian.org/debian/nautilus-hide
  https://salsa.debian.org/debian/nautilus-admin
  https://salsa.debian.org/debian/ncurses-hexedit
  https://salsa.debian.org/debian/dmalloc
  https://salsa.debian.org/debian/rmlint

And added your username as Master on those.  Please let me know if you
need anything else on salsa.

Thanks,

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
http://sergiodj.net/


signature.asc
Description: PGP signature

Bug#897205: gpg: Encrypting lots of files with --multiple gets failed: Too many open files

[Russell Stuart]

Package: gpg
Version: 2.2.5-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Here is the error:

$ gpg --no-permission-warning --homedir A_HOMEDIR --recipient A_RECIPIENT 
--multifile --encrypt 

Bug#897204: linux-image-4.15.0-3-armmp: Please enable CONFIG_DRM_DW_HDMI_AHB_AUDIO=m and CONFIG_DRM_DW_HDMI_CEC=m

[Korbinian Rosenegger]

Package: src:linux
Version: 4.15.17-1+local
Severity: wishlist

Dear Maintainer,

please enable these two options for supporting audio and CEC over HDMI on the 
SolidRun Cubox-i

CONFIG_DRM_DW_HDMI_AHB_AUDIO=m
CONFIG_DRM_DW_HDMI_CEC=m


At the moment I'm using a self compiled kernel package.


Thank you :)


Korbi




-- Package-specific info:
** Version:
Linux version 4.15.0-3-armmp (debian-ker...@lists.debian.org) (gcc version 
7.3.0 (Debian 7.3.0-15)) #1 SMP Debian 4.15.17-1+local (2018-04-25)

** Command line:
root=/dev/mmcblk1p1 ro quiet cma=256M

** Tainted: O (4096)
 * Out-of-tree module has been loaded.

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

** Model information
Hardware: Freescale i.MX6 Quad/DualLite (Device Tree)
Revision: 
Device Tree model: SolidRun Cubox-i Dual/Quad

** Loaded modules:
joydev
hid_generic
usbhid
brcmfmac
brcmutil
dw_hdmi_cec
cfg80211
hid
dw_hdmi_ahb_audio
cec
rfkill
ahci_imx
libahci_platform
libahci
snd_soc_imx_spdif
snd_soc_fsl_spdif
imx_pcm_dma
libata
snd_soc_core
snd_pcm_dmaengine
ir_lirc_codec
lirc_dev
snd_pcm
scsi_mod
snd_timer
imx2_wdt
snd
soundcore
gpio_ir_recv
dw_hdmi_imx(O)
rc_core
pwm_imx
leds_pwm
imxdrm(O)
dw_hdmi(O)
imx_ipu_v3
imx6q_cpufreq
etnaviv
tda998x
drm_kms_helper
drm
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
crc32c_generic
fscrypto
ecb
ci_hdrc_imx
ci_hdrc
ehci_hcd
sdhci_esdhc_imx
usbcore
sdhci_pltfm
i2c_imx
udc_core
sdhci
usb_common
usbmisc_imx
phy_mxs_usb
anatop_regulator
evdev

** PCI devices:

** USB devices:
Bus 002 Device 002: ID 062a:0102 Creative Labs Wireless Keyboard/Mouse Combo 
[MK1152WC]
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable'), (1, 'experimental')
Architecture: armhf (armv7l)

Kernel: Linux 4.15.0-3-armmp (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)

Versions of packages linux-image-4.15.0-3-armmp depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod25-1
ii  linux-base  4.5

Versions of packages linux-image-4.15.0-3-armmp recommends:
pn  apparmor 
ii  firmware-linux-free  3.4
ii  irqbalance   1.3.0-0.1

Versions of packages linux-image-4.15.0-3-armmp suggests:
pn  debian-kernel-handbook  
pn  linux-doc-4.15  

Versions of packages linux-image-4.15.0-3-armmp is related to:
ii  firmware-amd-graphics 20170823-1
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
ii  firmware-brcm8021120170823-1
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
ii  firmware-linux-nonfree20170823-1
ii  firmware-misc-nonfree 20170823-1
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#887875: how is this going?

[Russell Coker]

https://www.akkadia.org/drepper/nonselsec.pdf

Page 8 of the above document gives some suggestions on how to solve this class 
of problem.

Do you need some help with this?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#887875: how is this going?

[Russell Coker]

https://www.akkadia.org/drepper/nonselsec.pdf

Page 8 of the above document gives some suggestions on how to solve this class 
of problem.

Do you need some help with this?

-- 
My Main Blog http://etbe.coker.com.au/
My Documents Bloghttp://doc.coker.com.au/

Bug#897203: ripit: fails to handle directory name containing curly braces

[Lars Kruse]

Package: ripit
Version: 4.0.0~beta20140508-1
Severity: normal
Tags: patch

Dear Maintainer,

while trying to rip an album with a name containing curly braces ("{}"),
ripit stopped with an error:

 Unescaped left brace in regex is illegal here in regex; marked by <--
 HERE in m//foo { <-- HERE bar}.\d+/ at /usr/bin/ripit line 2958,  line 
2.

Instead I expected the ripping process to continue as smoothly as usual.

The attached patch fixes the problem for me.

Thank you for maintaining ripit.

Cheers,
Lars

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

Kernel: Linux 4.15.0-3-686-pae (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages ripit depends on:
ii  cdparanoia  3.10.2+debian-13
ii  ffmpeg  7:3.4.2-2
ii  flac1.3.2-1
ii  lame3.100-2
ii  libcddb-get-perl2.28-2
ii  libdigest-md5-file-perl 0.08-1
ii  libmime-base64-urlsafe-perl 0.01-2
ii  libmp3-tag-perl 1.13-1.1
ii  libmusicbrainz-discid-perl  0.04-1
ii  libtext-unidecode-perl  1.30-1
ii  libunicode-utf8-perl0.60-1+b4
ii  libwebservice-musicbrainz-perl  1.0.4-2
ii  libwww-perl 6.33-1
ii  libxml-simple-perl  2.25-1
ii  normalize-audio 0.7.7-14+b1
ii  perl5.26.2-2
ii  vorbis-tools1.4.0-10.1

Versions of packages ripit recommends:
ii  ssmtp [mail-transport-agent]  2.64-8+b2

Versions of packages ripit suggests:
ii  eject  2.1.5+deb1+cvs20081104-13.2
pn  id3
pn  id3v2  

-- no debconf information
--- /usr/bin/ripit.orig 2018-04-30 01:33:00.313241809 +0200
+++ /usr/bin/ripit  2018-04-30 01:33:24.493772740 +0200
@@ -9785,6 +9785,8 @@
$_[0] =~ s/\)/\\\)/g;
$_[0] =~ s/\[/\\\[/g;
$_[0] =~ s/\]/\\\]/g;
+   $_[0] =~ s/\{/\\\{/g;
+   $_[0] =~ s/\}/\\\}/g;
$_[0] =~ s/\&/\\\&/g;
$_[0] =~ s/\!/\\\!/g;
$_[0] =~ s/\?/\\\?/g;

Bug#897202: ITP: seriousproton -- C++ game engine implemented atop SFML

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

* Package name: seriousproton
  Version : 2018.02.15
  Upstream Author : Daid & Nallath
* URL : https://github.com/daid/SeriousProton/
* License : MIT
  Programming Lang: C++
  Description : game engine implemented atop SFML

seriousprootn is the game engine used to implement Empty Epsilon
and thus a dependency of it.

Bug#897201: ITP: empty-epsilon -- a spaceship bridge simulator game

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

* Package name: empty-epsilon
  Version : 2018.02.15
  Upstream Author : Daid & Nallath
* URL : https://daid.github.io/EmptyEpsilon/
* License : GPL-2
  Programming Lang: C++ & Lua
  Description : a spaceship bridge simulator game

EmptyEpsilon places you in the roles of a spaceship's bridge officers, like
those seen in Star Trek. While you can play EmptyEpsilon alone or with friends,
the best experience involves 6 players working together on each ship.

Each officer fills a unique role: Captain, Helms, Weapons, Relay, Science, and
Engineering. Except for the Captain, each officer operates part of the ship
through a specialized screen. The Captain relies on their trusty crew to report
information and follow orders.


Artemis Spaceship Bridge Simulator was the inspiration for EmptyEpsilon. It is
pretty good as a bridge simulator, but had some issues that EmptyEpsilon's
authors wanted to fix. Moreover, Artemis is not opensource.

Bug#897200: lists.debian.org: debian-ci archives are broken

[Antonio Terceiro]

Package: lists.debian.org
Severity: normal

hi,

the debian-ci mailing was created a few weeks ago, and the archives from
the old corrsponding list (autopkgtest-de...@lists.alioth.debian.org) were
imported. However, new messagens sent to the new list are not being
published in the web archives:

https://lists.debian.org/debian-ci/2018/04/threads.html

if you look at the above link, only the messages from the old lists
appear. all the new messages are not there. If I hit the URL in the
List-Archive header of a list message, I get a "Internal Server Error"
page from apache.

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

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


signature.asc
Description: PGP signature

Bug#887107: regarding dl10n-check memory footprint

[Alex Muntada]

Hi,
an easy way of finding how much memory any command uses, you can
use this trick:

/usr/bin/time --verbose dl10n-check ...

OTOH, if you'd like to get more details about why or where is
this Perl script failing, you can try with Devel::SimpleTrace
module. Just add «use Devel::SimpleTrace;» and you're done
(you'll need libdevel-simpletrace-perl installed, of course).

I tried to debug this issue locally but I need a full mirror,
so I need to figure out where to put all that data first.

My guess is that loading all those details in memory is too
much for tye. We could try mapping the $data hash to disk
before rewriting the whole Debian::L10n::Db module.

Cheers,
Alex



signature.asc
Description: PGP signature

Bug#394315: Enquiry

[Pablo Luis Sica]

Good Morning,
I called your Office line this morning but no one answered.I have attached  
list of items our company need and we are ready to purchase the goods, please 
send  quotation of product in the attached and send a copy of your best price 
ASAP.
  
Thanks and Regards
Pablo Luis Sica

PURCHASE ORDER_PA94093003.xlsx
Description: MS-Excel 2007 spreadsheet

Bug#897199: cec-utils not installable wrong depends

[Randy]

Package: cec-utils 
Version: 4.0.1+dfsg1-1

:~$ sudo apt install cec-utils
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 cec-utils : Depends: libcec4 (= 4.0.1+dfsg1-1) but 2:4.0.2-dmo1 is to be 
installed
E: Unable to correct problems, you have held broken packages.
:~$ 

Regularly updated from

/etc/apt/sources.list
# Stable
   
deb http://ftp.us.debian.org/debian/ stretch main contrib non-free  
   
deb-src http://ftp.us.debian.org/debian/ stretch main contrib non-free  
   

   
deb http://security.debian.org/ stretch/updates main contrib non-free   
   
deb-src http://security.debian.org/ stretch/updates main contrib non-free 

/etc/apt/sources.list.d 
opera-stable.list
virtualbox.list
webmin.list
winswitch.list

/etc/debian_version 9.4
uname -r  4.9.0-6-amd64
kde


If it ain't broke tweek it

Bug#895718: python-pyqt5: import PyQt5.QtCore fails

[Scott Kitterman]

On Wed, 18 Apr 2018 12:48:27 +0300 Dmitry Shachnev  wrote:
> On Sun, Apr 15, 2018 at 01:26:50PM +0300, Dmitry Shachnev wrote:
> > Works for me in a clean sid chroot.
> 
> The CI tests for pyqt5 are also passing [1], so I am closing this bug.
> 
> [1]: https://ci.debian.net/packages/p/pyqt5/unstable/amd64/

I've reopened this at a normal priority since it seems to reliably happen in a 
pbuilder/cowbuilder chroot environment (I hit it again today), but nowhere 
else.

Scott K

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

Bug#897198: bluez: reconnecting HID device needs manual commands, documentation is worthless

[Eduard Bloch]

Package: bluez
Version: 5.49-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?

Trying to make a BT mouse work. Your documentation did NOT help. The
mouse was reported and I could connect it but mouse was not responsive. I
found https://wiki.archlinux.org/index.php/Bluetooth#GNOME_Bluetooth
instead.

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

I run the commands from Arch Linux in bluetoothctl console and then my
mouse started working. But not for long. On the next reconnect of this
mouse it was dead.

   * What was the outcome of this action?

Mouse was NO LONGER WORKING. When I moved it, I got this pointless
messages in bluetoothctl console. And no hint WTF is going on.

[CHG] Device DC:2C:26:ED:CB:8D Connected: yes
[CHG] Device DC:2C:26:ED:CB:8D Connected: no
[CHG] Device DC:2C:26:ED:CB:8D Connected: yes
[CHG] Device DC:2C:26:ED:CB:8D Connected: no
[CHG] Device DC:2C:26:ED:CB:8D Connected: yes
[CHG] Device DC:2C:26:ED:CB:8D Connected: no

Finally I guessed it might be the "default-agent" command missing. When I
run it, it asked me again for some confirmation, I had to enter "yes"
again, and then the mouse started working again. Looks like this
(although covered with the stupid spam from above).

[bluetooth]# default-agent
Default agent request successful
[CHG] Device DC:2C:26:ED:CB:8D Connected: yes
Authorize service
no): yesagent] Authorize service 1124--1000-8000-00805f9b34fb (yes/n
[CHG] Device DC:2C:26:ED:CB:8D Connected: no

   * What outcome did you expect instead?

That it remembers what i told it before and makes it work again on the
next reconnect. Do I have to run this action every time? SERIOUSLY? Open
the console and run bluetoothctl and default-agent command?

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

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

Versions of packages bluez depends on:
ii  dbus  1.12.6-2
ii  kmod  25-1
ii  libasound21.1.3-5
ii  libc6 2.27-3
ii  libdbus-1-3   1.12.6-2
ii  libdw10.170-0.3
ii  libglib2.0-0  2.56.0-6
ii  libreadline7  7.0-3
ii  libudev1  238-4
ii  lsb-base  9.20170808
ii  udev  238-4

bluez recommends no packages.

Versions of packages bluez suggests:
ii  pulseaudio-module-bluetooth  11.1-5

-- no debconf information

Bug#892382: devscripts: FTBFS in mipsel/mips64el: uscan_ftp test timeouts

[Mattia Rizzolo]

On Thu, Mar 08, 2018 at 05:22:40PM +0100, Mattia Rizzolo wrote:
> Hi Osamu-san :)

Hi again!

> Just to mention one:
> 
> |testWatch4NonNativeDlUversion
> |FTP starting ... /tmp/tmp.XEqC4nYhhq/repo
> |uscan warn: In directory ., downloading
> |  ftp://127.0.0.1:37207/0.0/foo/ooo/foo-0.0.tar.gz.asc failed: 401 
> [LWP::Protocol::MyFTP] Timeout
> |uscan die: FAIL Checking OpenPGP signature (no signature file downloaded).
> |uscan: Newest version of foo on remote site is 0.0, specified download 
> version is 0.0
> |ASSERT:uscan: exit_code!=0 but exit_code=0 expected:<255> but was:<0>
> |ASSERT:foo_0.0.orig.tar.gz missing: opts=pgpsigurlmangle=s/$/.asc/ 
> @@@url@@@([\.\d]+)/(.+)/(.+)/ @PACKAGE@@ANY_VERSION@@ARCHIVE_EXT@ debian 
> uupdate
> |./test_uscan_ftp: 293: cd: can't cd to /tmp/tmp.XEqC4nYhhq/foo-0.0
> |ASSERT:pristine tarball is not extracted
> |tail: cannot open 'debian/changelog' for reading: No such file or directory
> |dpkg-parsechangelog: error: tail of debian/changelog subprocess returned 
> exit status 1
> |ASSERT:uscan: Version should be 0.0-1 but  expected:<> but was:<0.0-1>
> 
> Could you please have a look at it?
> 
> 
> Seems to be an unreliable failure, as on mipsel it passed at the 3rd
> try.

It happened again with devscripts 2.18.2.  This time mips64el worked at
the first time, but two tries weren't enough for mipsel.  I've requested
another give-back there, but I really think somebody should have a look
these tests…

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#892270: [reportbug] Crash when report type set to None

[Nis Martensen]

control: tags -1 unreproducible moreinfo
control: severity -1 important


Hi Jérôme,

On 7 Mar 2018 Jérôme Bardot wrote:
> Reportbug (gtk2 ui) crash when i select package.
> 
> The command line  output :
> 
> Traceback (most recent call last):
>   File "/usr/bin/reportbug", line 2265, in 
>     main()
>   File "/usr/bin/reportbug", line 1109, in main
>     return iface.user_interface()
>   File "/usr/bin/reportbug", line 1721, in user_interface
>     latest_first=self.options.latest_first)
>   File "/usr/lib/python3/dist-packages/reportbug/ui/gtk2_ui.py", line
> 1764, in func
>     args, kwargs = op.sync_pre_operation(*args, **kwargs)
> TypeError: 'NoneType' object is not iterable

Thank you for the report!

The crash occurs when the sysinfo.get('btsroot') in line 1030 of
gtk2_ui.py does not return anything:

1029 sysinfo = debbugs.SYSTEMS[bts]
1030 root = sysinfo.get('btsroot')
1031 if not root:
1032 # do we need to make a dialog for this?
1033 return

This should normally not happen on any Debian system.
/etc/dpkg/origins/debian is the file from which the sysinfo['btsroot']
setting is populated. Did you modify any files in /etc/dpkg/origins/?

Bug#839102: (no subject)

[Michael Bemmerl]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Version: 1:1.13-1.2

FYI: This bug is also present in Version 1:1.13-1.2 (stretch).
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEARECAAYFAlrmOVwACgkQKmk3pLlDYV6rrQCeNRN2iFaEujHTINybh+SVzzLo
6+cAnjojjLJfGZkskchJg2EgQz/1arcg
=UOrU
-END PGP SIGNATURE-

Bug#895778: jruby: Several security vulnerabilities

[Markus Koschany]

Hi Miguel,

I have prepared security updates for Jessie and Stretch. Unfortunately I
discovered that jruby in Jessie FTBFS at the moment. This is unrelated
to the patches.

Do you know how to resolve that?

generate-method-classes:

_gmc_internal_:
 [echo] Generating invokers...
 [java] Exception in thread "main" java.lang.ClassFormatError:
Duplicate method name&signature in class file
org/jruby/RubyFixnum$i_method_multi$RUBYINVOKER$to_s
 [java] >---at java.lang.ClassLoader.defineClass1(Native Method)
 [java] >---at java.lang.ClassLoader.defineClass(ClassLoader.java:803)
 [java] >---at
org.jruby.util.JRubyClassLoader.defineClass(JRubyClassLoader.java:39)
 [java] >---at
org.jruby.internal.runtime.methods.DumpingInvocationMethodFactory.endClass(DumpingInvocationMethodFactory.java:64)
 [java] >---at
org.jruby.internal.runtime.methods.InvocationMethodFactory.getAnnotatedMethodClass(InvocationMethodFactory.java:721)
 [java] >---at
org.jruby.anno.InvokerGenerator.main(InvokerGenerator.java:45)

I'm attaching the stretch debdiff to this bug report and push the
patches for Jessie.

Cheers,

Markus
diff -Nru jruby-1.7.26/debian/changelog jruby-1.7.26/debian/changelog
--- jruby-1.7.26/debian/changelog   2016-11-12 21:33:13.0 +0100
+++ jruby-1.7.26/debian/changelog   2018-04-29 22:24:33.0 +0200
@@ -1,3 +1,25 @@
+jruby (1.7.26-1+deb9u1) stretch-security; urgency=high
+
+  * Team upload.
+  * Fix CVE-2018-173: Directory Traversal vulnerability in install_location
+function of package.rb that can result in path traversal when writing to a
+symlinked basedir outside of the root.
+  * Fix CVE-2018-174: possible Unsafe Object Deserialization Vulnerability
+in gem owner.
+  * Fix CVE-2018-175: Strictly interpret octal fields in tar headers to
+avoid infinite loop
+  * Fix CVE-2018-176: Raise a security error when there are duplicate
+files in a package
+  * Fix CVE-2018-177: Enforce URL validation on spec homepage attribute.
+  * Fix CVE-2018-178: Mitigate XSS vulnerability in homepage attribute
+when displayed via gem server.
+  * Fix CVE-2018-179: Directory Traversal vulnerability in gem installation
+that can result in writing to arbitrary filesystem locations during
+installation of malicious gems.
+(Closes: #895778)
+
+ -- Markus Koschany   Sun, 29 Apr 2018 22:24:33 +0200
+
 jruby (1.7.26-1) unstable; urgency=medium
 
   * Team upload.
diff -Nru jruby-1.7.26/debian/patches/CVE-2018-173.patch 
jruby-1.7.26/debian/patches/CVE-2018-173.patch
--- jruby-1.7.26/debian/patches/CVE-2018-173.patch  1970-01-01 
01:00:00.0 +0100
+++ jruby-1.7.26/debian/patches/CVE-2018-173.patch  2018-04-29 
22:24:33.0 +0200
@@ -0,0 +1,23 @@
+From: Markus Koschany 
+Date: Sun, 29 Apr 2018 21:29:28 +0200
+Subject: CVE-2018-173
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895778
+Origin: 
https://github.com/rubygems/rubygems/commit/1b931fc03b819b9a0214be3eaca844ef534175e2
+---
+ lib/ruby/shared/rubygems/package.rb | 2 ++
+ 1 file changed, 2 insertions(+)
+
+diff --git a/lib/ruby/shared/rubygems/package.rb 
b/lib/ruby/shared/rubygems/package.rb
+index e8b8b38..25ac814 100644
+--- a/lib/ruby/shared/rubygems/package.rb
 b/lib/ruby/shared/rubygems/package.rb
+@@ -405,6 +405,8 @@ EOM
+ destination_dir = File.expand_path destination_dir
+ 
+ destination = File.join destination_dir, filename
++destination = File.realpath destination if
++  File.respond_to? :realpath
+ destination = File.expand_path destination
+ 
+ raise Gem::Package::PathError.new(destination, destination_dir) unless
diff -Nru jruby-1.7.26/debian/patches/CVE-2018-174.patch 
jruby-1.7.26/debian/patches/CVE-2018-174.patch
--- jruby-1.7.26/debian/patches/CVE-2018-174.patch  1970-01-01 
01:00:00.0 +0100
+++ jruby-1.7.26/debian/patches/CVE-2018-174.patch  2018-04-29 
22:24:33.0 +0200
@@ -0,0 +1,23 @@
+From: Markus Koschany 
+Date: Sun, 29 Apr 2018 21:11:01 +0200
+Subject: CVE-2018-174
+
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895778
+Origin: 
https://github.com/rubygems/rubygems/commit/254e3d0ee873c008c0b74e8b8abcbdab4caa0a6d
+---
+ lib/ruby/shared/rubygems/commands/owner_command.rb | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lib/ruby/shared/rubygems/commands/owner_command.rb 
b/lib/ruby/shared/rubygems/commands/owner_command.rb
+index 322bf65..c5416f8 100644
+--- a/lib/ruby/shared/rubygems/commands/owner_command.rb
 b/lib/ruby/shared/rubygems/commands/owner_command.rb
+@@ -61,7 +61,7 @@ permission to.
+ end
+ 
+ with_response response do |resp|
+-  owners = YAML.load resp.body
++  owners = Gem::SafeYAML.load resp.body
+ 
+   say "Owners for gem: #{name}"
+   owners.each do |owner|
diff -Nru jruby-1.7.26/debian/patches/CVE-2018-175.patch 
jruby-1.7.26/debian/patches/CVE-2018-1

Bug#894159: OpenTTD, icu and ParagraphLayout

[GCS]

On Sun, Apr 29, 2018 at 10:27 PM Matthijs Kooijman 
wrote:
> I'm the maintainer of the OpenTTD package, and stumbled on this bug
> report, which refers to my package as the last user of the
> ParagraphLayout API in icu.
   Indeed. That's why I need the icu-le-hb loop which seems to be a dying
project.

> First off: I have a pending new upstream version of OpenTTD that I'd
> like to upload, but I don't want to interfere with this transition.
> Should I hold it off, or do we expect that resolving these issues will
> take a while and should I just upload it now (and have it build against
> the current icu version)?
   The transition will happen soon. I'm re-recompiled almost everything to
really start it.
I'm biased a bit. The current OpenTTD version in Sid compiles fine. If you
can make the package available before upload or can check the compilation
yourself with the experimental version of ICU then it would be good.
I think there's still a day or two before the actual transition so I think
you can upload OpenTTD after the mentioned test above.

> As for the layout issue, AFAIU the following is the case (but correct me
> if I'm wrong):
>- ICU used to offer a layout API (which handles the layout of a single
>  line of text).
>- Harfbuzz offers a similar layouting engine.
>- icu-le-hb is a separate piece of code that offers the (now removed)
>  ICU layout API, by using Harfbuzz
>- ICU offers a ParagraphLayout API (which handles wordwrapping a piece
>  of text). This code needs the (now removed) layout API, so currently
>  it can only be built on top of icu-le-hb.
  This is the exact case. ICU removed the (long [since the 54.1 release]
deprecated) Layout Engine API[1] and please don't ask me why they kept the
dependent Paragraph Layout API.

> This gives a dependency chain where Harfbuzz optionally depends on ICU,
> icu-le-hb depends on Harfbuzz and (I presume) ICU, and where
> ParagraphLayout depends on icu-le-hb. Since ICU and ParagraphLayout live
> in the same source package, this results in a circular dependency, which
> needs two successive builds of the ICU package (once without
> ParagraphLayout and once with), building icu-le-hb in between, to make
> this work.
  This is also correct and described by ICU upstream[2].

> This does seem like a weird situation, also for ICU upstream. Do they
> have any plans to resolve this?
  I don't know more about this. I still need to check the ICU 61.1 release
though. But I think it was not really used and they just step over it. At
last there's no alternative recommendation from ICU upstream.

> One suggested solution (by László) is to integrate icu-le-hb into the
> ICU source package, so the double compilation could at least happen
> inside the ICU source package instead of having to be managed
> externally. I do wonder: If icu-le-hb is properly integrated into the
> ICU build system (probably needs integration upstream to be feasible),
> this double build could be removed, right?
  I meant the double source package compilation (our tools can handle
multiple sources for one package for a while).
The whole story is the following. ICU removes the Layout Engine part due to
its bunch of bugs and not being maintained. Someone takes the last version
and begin fixing bugs. Then it's abandoned as well, last release is from
2015. It was me who patch it for ICU 60.2 so I've doubts there's any plan
to re-integrate icu-le-hb back to ICU itself.

> One alternative I can imagine is to move the ParagraphLayout code from
> the ICU library (where it seems a bit out of place now) into the
> icu-le-hb code. AFAICS that would resolve the circular dependency (or
> does Harfbuzz need ICU and is that still a problem? That seems hard to
> fix in any case...).
  As icu-le-hb is quite dead at the moment you need to find someone who
would fix its bugs first and may integrate the Paragraph Layout API into
it. I don't have any resources to do it, but if you know anybody then
please tell.

> Another solution is of course to disable ParagraphLayout. László also
> asked if OpenTTD, being the only user of this API, could migrate to
> another solution. I've discussed this with OpenTTD upstream yesterday,
> and they were already aware of the layout API removal and have been
> casually looking at Harfbuzz and Pango as a replacement, but they do not
> see an easy solution yet. ParagraphLayout seems to fit their usecase
> quite neatly: they need internationalized word-wrapping of text (e.g.
> also supporting right-to-left locales). Harfbuzz does not seem to offer
> that, and Pango seems heavy-handed (and might not be easy to adapt to
> OpenTTD's SDL renderer, and might not be portable enough).
  This is bad to read. I had the hope there's an easy solution and/or the
replacement might be already in the making.

> Neither me or upstream has much experience in this field, perhaps you
> have a different suggestion for an alternative?
  I don't know any other alternative. Onl

Bug#895993: closed by Luigi Gangitano (Bug#641944: fixed in squid 4.0.24-1~exp15)

[Heiko Richter]

The bug 895993 *has not been fixed*. Please reopen, as the listed fix 
has nothing to do with the problem described.


---

While it is true that upstream has added GnuTLS support to https_port 
that has nothing to do with the bug I reported. SSL is still not 
available on client connections because *it is disabled by you during 
builds*. This makes forward proxies incrediby insecure and reverse 
proxies almost completely unsusable. Currently any Debian packeged Squid 
can only be deployed securely by modifying source packages because 
https_port is not available.


1) The Debian package is compiled without ssl or tls support (configure 
options to enable SSL are not included and squid's default is to disable 
SSL) and therefor either https support added by upstream is disabled 
during package builds.


2) SSL support has always been in the source code (TLS has just been 
added additionally) but it could never be used in Debian without 
modifying the source packages. Neither can TLS because that is also 
disabled by default and needs to be activated during build.


3) Please add the appropriate configure options and package dependencies
* configure options should be extended by --enable-ssl 
--with-open-ssl="/etc/ssl/openssl.cnf"

* dependencies should be extended by libssl

Bug#897197: RFS: spacefm/1.0.6-3

[Mateusz Łukasik]

Package: sponsorship-requests
Severity:

  Dear mentors,

  I am looking for a sponsor for my package "spacefm"

 * Package name: spacefm
   Version : 1.0.6-3
   Upstream Author : IgnorantGuru 
 * URL : https://github.com/IgnorantGuru/spacefm
 * License : GPL-3+
   Section : utils

  It builds those binary packages:

spacefm- Multi-panel tabbed file manager - GTK2 version
 spacefm-common - Multi-panel tabbed file manager - common files
 spacefm-gtk3 - Multi-panel tabbed file manager - GTK3 version

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


  https://mentors.debian.net/package/spacefm


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

dget -x 
https://mentors.debian.net/debian/pool/main/s/spacefm/spacefm_1.0.6-3.dsc



  Changes since the last upload:

Added all cases to postrm script. (Closes: #893237)

piuparts for this version: http://paste.ubuntu.com/p/8BdpxkTR8x/

  Regards,
   Mateusz Łukasik

Bug#897196: CVE-2018-1000101

[Moritz Muehlenhoff]

Source: mingw-w64
Severity: normal
Tags: security

Please see http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-1000101

Cheers,
Moritz

Bug#894642: [Pkg-sugar-devel] Bug#894642: gst-plugins-espeak: diff for NMU version 0.4.0-3.1

[James Cameron]

Will you be sending this upstream?

https://github.com/sugarlabs/gst-plugins-espeak

-- 
James Cameron
http://quozl.netrek.org/

Bug#897168: proftp: FTBFS on kfreebsd

[Hilmar Preuße]

On 29.04.2018 14:01, Hilmar Preuße wrote:

Hi debian-bsd people,

I just noticed that our package fails to build on kfreebsd:

https://buildd.debian.org/status/fetch.php?pkg=proftpd-dfsg&arch=kfreebsd-amd64&ver=1.3.6-2&stamp=1524996945&raw=0

Could you help us here? proftp seems to build on FreeBSD in general so
there seems to be something specific to this port.

Thanks!

>* What led up to the situation?
> 
> Since we uploaded proftp 1.3.6 to unstable the package fails to build on
> kfreebsd, on i386 and kfreebsd-amd64. The last lines of the log are:
> 
> src/fsio.o: In function `sys_fsetxattr':
> ./fsio.c:1018: undefined reference to `extattr_set_fd'
> src/fsio.o: In function `unix_flistxattr':
> ./fsio.c:640: undefined reference to `extattr_list_fd'
> ./fsio.c:640: undefined reference to `extattr_list_fd'
> src/fsio.o: In function `unix_llistxattr':
> ./fsio.c:621: undefined reference to `extattr_list_file'
> ./fsio.c:621: undefined reference to `extattr_list_file'
> src/fsio.o: In function `unix_listxattr':
> ./fsio.c:602: undefined reference to `extattr_list_file'
> ./fsio.c:602: undefined reference to `extattr_list_file'
> src/fsio.o: In function `sys_fremovexattr':
> ./fsio.c:885: undefined reference to `extattr_delete_fd'
> src/fsio.o: In function `sys_fgetxattr':
> ./fsio.c:529: undefined reference to `extattr_get_fd'
> collect2: error: ld returned 1 exit status
> libtool: link: rm -f ".libs/proftpdS.o"
> 
> I guess some libs, needed for linking are not specified. I file that bug as
> important as FreeBSD is not a release arch.
> 

-- 
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#897180: Bug#897182 closed by Matthias Klose (Re: Bug#897182: gcc-8-x86-64-linux-gnu: Alternatives not set up)

[Heinrich Schuchardt]

On 04/29/2018 10:01 PM, Matthias Klose wrote:
> On 29.04.2018 21:49, Heinrich Schuchardt wrote:
>> Hello Matthias,
>>
>> I want to install GCC 8 and not GCC 7. So installing
>> package gcc-x86-64-linux-gnu is not a solution.
>>
>> I have no clue why you closed the bug. Instead I expect a fix.
> 
> different GCC versions have different APIs and ABIs.  They are not handled by
> alternatives. Point.  There is no fix for your request.
> 
For cross compiling the name of the gcc binary has to end with the
letters gcc and not with gcc-something. The prefix has to match the
binutils tools prefixes.

So the package is defintively buggy.

Best regards

Heinrich

Bug#892415: nvcc wants GCC 6 which we want to remove

[Graham Inggs]

Control: severity -1 important

Hi

I'm downgrading the severity of this bug so nvidia-cuda-toolkit can
remain in testing for longer.

I understand that gcc-6 will be removed before buster, but its removal
is currently blocked by pdftk, a key package.

Regards
Graham

Bug#897195: python-prov: autopkgtest fails with new version of rdflib

[Paul Gevers]

Source: python-prov
Version: 4.2.2-1
Severity: normal
User: debian...@lists.debian.org
Usertags: needs-update

With the upload of version 4.2.2-1 of rdflib, the autopkgtest of
python-prov¹ started to fail lots of failures on rdf items (log attached).

As I am unfamiliar with rdf and python-prov, I suggest you look into
this failure as it may be that your tests need updating for the new
rdflib package, or worse, that this is a genuine bug in rdflib (hence
the CC). If the latter is that case, please reassign this bug and raise
the severity if that is warranted to prevent migration of rdflib.

Paul

¹ https://ci.debian.net/packages/p/python-prov/unstable/amd64/


python-prov.log.gz
Description: application/gzip


signature.asc
Description: OpenPGP digital signature

Bug#894159: OpenTTD, icu and ParagraphLayout

[Matthijs Kooijman]

Hi folks,

I'm the maintainer of the OpenTTD package, and stumbled on this bug
report, which refers to my package as the last user of the
ParagraphLayout API in icu.

First off: I have a pending new upstream version of OpenTTD that I'd
like to upload, but I don't want to interfere with this transition.
Should I hold it off, or do we expect that resolving these issues will
take a while and should I just upload it now (and have it build against
the current icu version)?


As for the layout issue, AFAIU the following is the case (but correct me
if I'm wrong):
 - ICU used to offer a layout API (which handles the layout of a single
   line of text).
 - Harfbuzz offers a similar layouting engine.
 - icu-le-hb is a separate piece of code that offers the (now removed)
   ICU layout API, by using Harfbuzz
 - ICU offers a ParagraphLayout API (which handles wordwrapping a piece
   of text). This code needs the (now removed) layout API, so currently
   it can only be built on top of icu-le-hb.

This gives a dependency chain where Harfbuzz optionally depends on ICU,
icu-le-hb depends on Harfbuzz and (I presume) ICU, and where
ParagraphLayout depends on icu-le-hb. Since ICU and ParagraphLayout live
in the same source package, this results in a circular dependency, which
needs two successive builds of the ICU package (once without
ParagraphLayout and once with), building icu-le-hb in between, to make
this work.

This does seem like a weird situation, also for ICU upstream. Do they
have any plans to resolve this?

One suggested solution (by László) is to integrate icu-le-hb into the
ICU source package, so the double compilation could at least happen
inside the ICU source package instead of having to be managed
externally. I do wonder: If icu-le-hb is properly integrated into the
ICU build system (probably needs integration upstream to be feasible),
this double build could be removed, right?

One alternative I can imagine is to move the ParagraphLayout code from
the ICU library (where it seems a bit out of place now) into the
icu-le-hb code. AFAICS that would resolve the circular dependency (or
does Harfbuzz need ICU and is that still a problem? That seems hard to
fix in any case...).


Another solution is of course to disable ParagraphLayout. László also
asked if OpenTTD, being the only user of this API, could migrate to
another solution. I've discussed this with OpenTTD upstream yesterday,
and they were already aware of the layout API removal and have been
casually looking at Harfbuzz and Pango as a replacement, but they do not
see an easy solution yet. ParagraphLayout seems to fit their usecase
quite neatly: they need internationalized word-wrapping of text (e.g.
also supporting right-to-left locales). Harfbuzz does not seem to offer
that, and Pango seems heavy-handed (and might not be easy to adapt to
OpenTTD's SDL renderer, and might not be portable enough).

Neither me or upstream has much experience in this field, perhaps you
have a different suggestion for an alternative?

Gr.

Matthijs


signature.asc
Description: PGP signature

Bug#896998: python-pip: missing required _vendor module. Broken ${python:Depends}?

[Matthias Klose]

your proposed patch is certainly wrong.  You need to find out why these
references aren't resolved by the python-pip-whl package.

Bug#897194: RFS: gnustep-back/0.26.2-4

[Yavor Doganov]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "gnustep-back".

 * Package name: gnustep-back
   Version : 0.26.2-4
   Upstream Author : Fred Kiefer ,
 Adam Fedor ,
 Alexander Malmberg ,
 Banlu Kemiyatorn  et al
 * URL : http://gnustep.org
 * License : LGPL-2+ (bundles), GPL-3+ (tools)
   Section : gnustep

It builds these binary packages:

gnustep-back-common - GNUstep GUI Backend - common files
gnustep-back0.26 - GNUstep GUI Backend
gnustep-back0.26-art - GNUstep GUI Backend (art)
gnustep-back0.26-cairo - GNUstep GUI Backend (cairo)
gnustep-back0.26-xlib - GNUstep GUI Backend (xlib)

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

  https://mentors.debian.net/package/gnustep-back

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

  dget -x 
https://mentors.debian.net/debian/pool/main/g/gnustep-back/gnustep-back_0.26.2-4.dsc

Git repository:

  https://salsa.debian.org/gnustep-team/gnustep-back

Changes since the last upload:

  * debian/templates/control.m4: Let gnustep-backN provide gnustep-back so
that a backend can always be installed without specifying the version
(Closes: #892241).  Thanks Josh Freeman for the report.
(Standards-Version): Bump to 4.1.4 (no changes required).
  * debian/control: Regenerate.
  * debian/tests/file-tests: Replace dumb file tests with a minimalistic
test program which dynamically loads all backends (Closes: #896838).
Thanks to Paul Gevers for the report and the idea.
  * debian/tests/control (Restrictions): Define to allow-stderr.
(Depends): Remove shunit2 and file; add libgnustep-base-dev.
  * debian/tests/load_backends.m:
  * debian/tests/GNUmakefile: New files.

Bug#897193: RFS: ddccontrol-db/20171217-2

[Miroslav Kravec]

Package: sponsorship-requests
Severity: normal [important for RC bugs, wishlist for new packages]

Dear mentors,

I am looking for a sponsor for my package "ddccontrol-db"

 * Package name: ddccontrol-db
   Version : 20171217-2
   Upstream Author : Miroslav Kravec 
 * URL : https://github.com/ddccontrol/ddccontrol-db
 * License : GNU General Public License v2.0
   Section : utils

It builds those binary packages:

ddccontrol-db - monitor database for ddccontrol

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

  https://mentors.debian.net/package/ddccontrol-db


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

dget -x 
https://mentors.debian.net/debian/pool/main/d/ddccontrol-db/ddccontrol-db_20171217-2.dsc

Changes since the last upload:

* debian/changelog: fix file-contains-trailing-whitespace
* debian/compat, debian/control: bump debhelper to 11
* debian/control: update standards to 4.1.4
* debian/copyright: fix copyright-refers-to-symlink-license
* debian/rules: fix debian-rules-is-dh_make-template

Kind regards,
Miroslav Kravec

Bug#897180: Bug#897182 closed by Matthias Klose (Re: Bug#897182: gcc-8-x86-64-linux-gnu: Alternatives not set up)

[Matthias Klose]

On 29.04.2018 21:49, Heinrich Schuchardt wrote:
> Hello Matthias,
> 
> I want to install GCC 8 and not GCC 7. So installing
> package gcc-x86-64-linux-gnu is not a solution.
> 
> I have no clue why you closed the bug. Instead I expect a fix.

different GCC versions have different APIs and ABIs.  They are not handled by
alternatives. Point.  There is no fix for your request.

Bug#897180: Bug#897182 closed by Matthias Klose (Re: Bug#897182: gcc-8-x86-64-linux-gnu: Alternatives not set up)

[Heinrich Schuchardt]

Hello Matthias,

Package gcc-x86-64-linux-gnu is not available for Debian Buster.

So you answer is not applicable. Please, reopen the bug report.

Best regards

Heirnich

Bug#896806: systemd-resolved violates The Debian Free Software Guidelines

[Don Armstrong]

On Sun, 29 Apr 2018, Martin Hanson wrote:
> I have posted this bug report
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=896806 that has been
> rejected by the maintainer.
>
> Maybe I have misunderstood the issue completely, but I do have some
> experience with legal issues and AFAIK, there IS a problem here.

There isn't an issue here. I am aware of no US case law suggesting that
using an advertised public interface can cause third parties to be bound
by a license agreement that they have not been informed of or
accepted.[1]

Furthermore, this is not a DFSG violation, even if there was concern
about third parties being bound to license agreements.

If there is a concern here, it's a privacy concern. Google's public
statements regarding maintaining privacy and the need for working DNS to
do most things on the internet should counterbalance this privacy
concern for most users.

1: If you know of some, please provide specific citations.
-- 
Don Armstrong  https://www.donarmstrong.com

Good people are good because they've come to wisdom through failure.
We get very little wisdom from success, you know.
 -- William Saroyan _My Heart's in the Highlands_

Bug#897180: Bug#897182 closed by Matthias Klose (Re: Bug#897182: gcc-8-x86-64-linux-gnu: Alternatives not set up)

[Heinrich Schuchardt]

Hello Matthias,

I want to install GCC 8 and not GCC 7. So installing
package gcc-x86-64-linux-gnu is not a solution.

I have no clue why you closed the bug. Instead I expect a fix.

Best regards

Heinrich Schuchardt

On 04/29/2018 09:45 PM, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> which was filed against the gcc-8-x86-64-linux-gnu package:
> 
> #897182: gcc-8-x86-64-linux-gnu: Alternatives not set up
> 
> It has been closed by Matthias Klose .
> 
> Their explanation is attached below along with your original report.
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Matthias Klose 
>  by
> replying to this email.
> 
> 

Bug#896998: Not fixed in python-pip 9.0.1-2.2

[Nicholas D Steeves]

Control: reopen -1
Control: notfixed -1 python-pip/9.0.1-2.2
Control: retitle -1 python-pip: missing required _vendor module. Broken 
${python:Depends}?

On Sat, Apr 28, 2018 at 07:15:24PM -0400, Nicholas D Steeves wrote:
> On Sat, Apr 28, 2018 at 03:15:07PM +, Debian Bug Tracking System wrote:
> > This is an automatic notification regarding your Bug report
> > which was filed against the src:python-pip package:
> > 
> > #896998: python-pip: missing required _vendor module in 9.0.1-2.1
> > 
> > It has been closed by Matthias Klose .
> ...
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> > 
> > Format: 1.8
> > Date: Sat, 28 Apr 2018 15:31:03 +0200
> > Source: python-pip
> > Binary: python-pip python3-pip python-pip-whl
> > Architecture: source
> > Version: 9.0.1-2.2
> > Distribution: unstable
> > Urgency: medium
> > Maintainer: Debian Python Modules Team 
> > 
> > Changed-By: Matthias Klose 
> > Description:
> >  python-pip - Python package installer
> >  python-pip-whl - Python package installer
> >  python3-pip - Python package installer
> > Closes: 896998
> > Changes:
> >  python-pip (9.0.1-2.2) unstable; urgency=medium
> >  .
> >* Non-maintainer upload.
> >* debian/pip.dependencies: Add certifi.
> >* debian/rules: run dirtbike for certifi.
> >* pip/_vendor/__init__.py: Use the unvendored urllib3. Closes: #896998.
> 
> Thank you Matthias, I'm grateful that you fixed this so quickly! :-)

Sadly I spoke to soon :-(  The error now, in a clean and up-to-date
chroot after "apt install python-pip", is:

# python -m pip --help
Traceback (most recent call last):
  File "/usr/lib/python2.7/runpy.py", line 163, in _run_module_as_main
mod_name, _Error)
  File "/usr/lib/python2.7/runpy.py", line 111, in _get_module_details
__import__(mod_name)  # Do not catch exceptions initializing package
  File "/usr/lib/python2.7/dist-packages/pip/__init__.py", line 31, in 
from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/usr/lib/python2.7/dist-packages/pip/vcs/mercurial.py", line 9, in 

from pip.download import path_to_url
  File "/usr/lib/python2.7/dist-packages/pip/download.py", line 40, in 
from pip._vendor import requests, six
ImportError: cannot import name requests

# pip --help
Traceback (most recent call last):
  File "/usr/bin/pip", line 9, in 
from pip import main
  File "/usr/lib/python2.7/dist-packages/pip/__init__.py", line 31, in 
from pip.vcs import git, mercurial, subversion, bazaar  # noqa
  File "/usr/lib/python2.7/dist-packages/pip/vcs/mercurial.py", line 9, in 

from pip.download import path_to_url
  File "/usr/lib/python2.7/dist-packages/pip/download.py", line 40, in 
from pip._vendor import requests, six
ImportError: cannot import name requests

Maybe pip.dependencies and dirtbike are broken, which means
${python:Depends} isn't functioning properly?  Applying my patch
allows both "python -m pip --help" and "pip --help" to succeed.  From
what I can tell the reason is because python-certifi, python-requests,
python-urllib3, and their dependencies are still not installed for
python-pip-9.0.1-2.2.

https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=896998;filename=0001-python-pip-Add-missing-depends-on-certifi-urllib3-an.patch;msg=27

Kind regards,
Nicholas


signature.asc
Description: PGP signature

Bug#897192: RFP: testinfra -- server state testing framework based on pytest

[Daniel Stender]

Package: wnpp
Severity: wishlist

* Package name: testinfra
  Version : 1.12.0
  Upstream Author : Philippe Pepiot 
* URL : https://github.com/philpep/testinfra
* License : Apache-2.0
  Programming Lang: Python
  Description : server state testing framework based on pytest

This is a framework for writing arbitrary server status tests equivalent
to Serverspec [1]. It's implemented as a plugins for Pytest.
Recently discussed in current German IT Administrator magazine (Tim
Schürmann: "Wie läuft's? Server-Konfiguration testen mit Testinfra".
In: IT-Administrator 05/2018, p. 92-95).

Thanks,
DS

[1] https://testinfra.readthedocs.io/en/latest/

Bug#897191: pymol: autopkgtest times out with new version while succeeded in the past

[Paul Gevers]

Source: pymol
Version: 2.1.0+dfsg-1
Severity: normal
User: debian...@lists.debian.org
Usertags: regression timeout

With the upload of version 2.1.0+dfsg-1 of pymol, the autopkgtest¹
started to fail due to it timing out (> 11 hours) on 4 of the tests and
additionally due to unexpected output to stderr (see the relevant part
of the log copied below). Previous versions only required a couple of
minutes. Therefore I assume a lot of tests got added (albeit no note in
the changelog about that), otherwise it is really worth it to try and
find out why it now takes so much longer.

A note about time outs. Time outs can often be worked around by
splitting a test into multiple autopkgtest because each gets its own
timeout. On the other hand, is 11 hours or more really worth it?
Couldn't a limited set of the test be run?

Output to stderr normally causes a test to fail. One can overrule that
by add allow-stderr to the test Restrictions if the output is expected
and to be ignored.

Don't hesitate to ask for help for the Debian CI team if you need help
solving this issue.

Paul
PS: I don't want to threaten, but if the time out isn't going to be
fixed soon, we'll probably add pymol to the ci.d.n blacklist.

¹ https://ci.debian.net/packages/p/pymol/unstable/amd64/
² debian...@lists.debian.org

autopkgtest [10:06:31]: test command1: sh
debian/tests/call-pymol-scripts examples/ \
"(start_pymol)|(xmlrpc01)|(sd_annotate)|(povray01)|(contact)|(dali)|(density)|(groel_es)|(packing)|(packsurf)|(ref_frame)|(ribosome)|(ss_xfer)|(multiclip_ray)"
autopkgtest [10:06:31]: test command1: [---
Search pymol scripts in
/tmp/autopkgtest-lxc.abr4cnnf/downtmp/build.rFy/src/examples...
Processing new directory
/tmp/autopkgtest-lxc.abr4cnnf/downtmp/build.rFy/src/examples
Run 'pymol -c
/tmp/autopkgtest-lxc.abr4cnnf/downtmp/build.rFy/src/examples/chempy/generate_mmff.py'...
not ok - line 'PyMOL: normal program termination.' was not found
in pymol output
Run 'pymol -c
/tmp/autopkgtest-lxc.abr4cnnf/downtmp/build.rFy/src/examples/chempy/generate_amber.py'...
not ok - line 'PyMOL: normal program termination.' was not found
in pymol output
autopkgtest [12:53:11]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.abr4cnnf/downtmp/build.rFy/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.abr4cnnf/downtmp/command1-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.abr4cnnf/downtmp/command1-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.abr4cnnf/downtmp/autopkgtest_tmp"; export
AUTOPKGTEST_TMP="/tmp/autopkgtest-lxc.abr4cnnf/downtmp/autopkgtest_tmp";
export ADTTMP="$AUTOPKGTEST_TMP"; export DEBIAN_FRONTEND=noninteractive;
export LANG=C.UTF-8; export DEB_BUILD_OPTIONS=parallel=8; unset LANGUAGE
LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE   LC_MONETARY LC_MESSAGES
LC_PAPER LC_NAME LC_ADDRESS   LC_TELEPHONE LC_MEASUREMENT
LC_IDENTIFICATION LC_ALL;rm -f /tmp/autopkgtest_script_pid; set -C; echo
$$ > /tmp/autopkgtest_script_pid; set +C; trap "rm -f
/tmp/autopkgtest_script_pid" EXIT INT QUIT PIPE; cd "$buildtree"; touch
/tmp/autopkgtest-lxc.abr4cnnf/downtmp/command1-stdout
/tmp/autopkgtest-lxc.abr4cnnf/downtmp/command1-stderr; bash -ec 'sh
debian/tests/call-pymol-scripts examples/ \
"(start_pymol)|(xmlrpc01)|(sd_annotate)|(povray01)|(contact)|(dali)|(density)|(groel_es)|(packing)|(packsurf)|(ref_frame)|(ribosome)|(ss_xfer)|(multiclip_ray)"'
2> >(tee -a /tmp/autopkgtest-lxc.abr4cnnf/downtmp/command1-stderr >&2) >
>(tee -a /tmp/autopkgtest-lxc.abr4cnnf/downtmp/command1-stdout);" (kind:
test)
autopkgtest [12:53:12]: test command1: ---]
autopkgtest [12:53:12]: test command1:  - - - - - - - - - - results - -
- - - - - - - -
command1 FAIL timed out
autopkgtest [12:53:12]: test command1:  - - - - - - - - - - stderr - - -
- - - - - - -
not ok - line 'PyMOL: normal program termination.' was not found
in pymol output
not ok - line 'PyMOL: normal program termination.' was not found
in pymol output



autopkgtest [12:53:45]: test command2: [---
Search pymol scripts in
/tmp/autopkgtest-lxc.abr4cnnf/downtmp/build.rFy/src/data/demo...
Processing new directory
/tmp/autopkgtest-lxc.abr4cnnf/downtmp/build.rFy/src/data/demo
autopkgtest [15:40:26]: ERROR: timed out on command "su -s /bin/bash
debci -c set -e; export USER=`id -nu`; . /etc/profile >/dev/null 2>&1 ||
true;  . ~/.profile >/dev/null 2>&1 || true;
buildtree="/tmp/autopkgtest-lxc.abr4cnnf/downtmp/build.rFy/src"; mkdir
-p -m 1777 --
"/tmp/autopkgtest-lxc.abr4cnnf/downtmp/command2-artifacts"; export
AUTOPKGTEST_ARTIFACTS="/tmp/autopkgtest-lxc.abr4cnnf/downtmp/command2-artifacts";
export ADT_ARTIFACTS="$AUTOPKGTEST_ARTIFACTS"; mkdir -p -m 755
"/tmp/autopkgtest-lxc.abr4cnnf/downtmp

Bug#896263: django-haystack: 2 RC bugs => 1 MR

[Joseph Herlant]

Dear maintainer,

I believe those 2 bugs would be fixed by
https://salsa.debian.org/python-team/modules/django-haystack/merge_requests/1
Could you have a look please?

I see in  https://github.com/django-haystack/django-haystack/pull/1603
that other people outside of Debian seem to have the problem too so
the fix might change later on.

#896263 and #896296 generate several dependent packages to be on
autoremoval from testing soon, so it would be great if we could have
this one fixed.

Thanks for your help,
Joseph

Bug#895981: please cleanup /var/cache/nscd on restart

[Florian Weimer]

* Harald Dunkel:

> I am using both systemd and sysvinit-core, but I am not sure which one
> was active when I ran into this problem.
>
> Consider a split DNS setup for a remote network. I had started an IPsec
> connection to the remote side. /etc/resolv.conf was changed to include
> the new internal DNServer on the remote side, but a host lookup gave me
> still the old external address. Stopping nscd did not help, AFAIR.

That's arguably a bug in nscd.  It should flush the cache each time it
detects a change in /etc/resolv.conf (or /etc/gai.conf, for that
matter).

Bug#897190: ITP: wemux -- multi-user Tmux made easy

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

* Package name: wemux
  Version : 3.2.0
  Upstream Author : Matt Furden 
* URL : https://github.com/zolrath/wemux
* License : MIT
  Programming Lang: Shell
  Description : multi-user Tmux made easy

wemux enhances tmux to make multi-user terminal multiplexing both easier and
more powerful. It allows users to host a wemux server and have clients join in
either:

- Mirror Mode gives clients (another SSH user on your machine) read-only access 
to
  the session, allowing them to see you work, or

- Pair Mode allows the client and yourself to work in the same terminal (shared 
cursor)

- Rogue Mode allows the client to pair or work independently in another window
  (separate cursors) in the same tmux session.

It features multi-server support as well as user listing and notifications when
users attach/detach.


Best,

  nicoo

Bug#896550: kazam: Binding 'R' failed!

[Andrew Starr-Bochicchio]

On Sun, Apr 22, 2018 at 4:48 AM, Davide Prina  wrote:
> And the key for start/stop registration don't work.
> So I can set to save the screencast, start it, bug I cannot stop it (I can do 
> it with Ctrl-C or kill command, but I don't have the screencast with 
> something usable: I see a movie with area subdivided into black and withe 
> squares).

Hi,

Could you please provide a bit more info about your set up to help
track down the root cause here? What desktop environment is in use? I
was not able to reproduce this in a new Debian Testing VM running
Gnome.

Thanks for the report.

-- Andrew Starr-Bochicchio

   Debian Developer 
   Ubuntu Developer 
   PGP/GPG Key ID: 3B56E2BBD53FDCB1

Bug#897189: chromium 66 tab crash on certain sites with ublock origin

[Ryan Tandy]

Package: chromium
Version: 66.0.3359.117-1~deb9u1
Severity: normal

Dear Maintainer,

Steps to reproduce:

1. install chromium 66.0.3359.117-1~deb9u1
2. chromium --temp-profile
3. install the uBlock Origin extension
   
https://chrome.google.com/webstore/detail/ublock-origin/cjpalhdlnbpafiamejdnhcphjbkeiagm
4. browse to a site containing a tasty recipe
   https://www.budgetbytes.com/2016/07/slow-cooker-coconut-curry-lentils/

Expected result: delicious slow cooked meal

Actual result: "Aw, Snap!" and hungry user

With chromium 64.0.3282.119-1~deb9u1 there was no crash.

Apparently dbgsym packages are not published for the security archive, 
so I do not have debugging symbols and the backtrace is basically 
useless... I'm logging the bug anyway and hoping that someone can 
reproduce it on a system with dbgsyms available.


Received signal 11 SEGV_MAPERR 
#0 0x55930b590f1e 
#1 0x559309b5ba0a 
#2 0x55930b5912ee 
#3 0x7f49da1fd0c0 
#4 0x55930d8e7c5b 
#5 0x55930d8f7f22 
#6 0x55930ae0b0d2 
#7 0x55930afd9201 
#8 0x168ab420479d 
  r8: 55930d8f81ba  r9: 115a4d5674f1 r10: 09c9f40becf8 r11: 
385379a31b11
 r12: 7ffeea5ffe38 r13:  r14: 35da97c237e0 r15: 
350d55a74080
  di: 7ffeea5ffe40  si: 55930ebc7c58  bp: 7ffeea5ffe90  bx: 
7ffeea5ffe40
  dx: 55930d8e7c58  ax:   cx: 00e1  sp: 
7ffeea5ffe10
  ip: 55930d8e7c5b efl: 00010206 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: 
[end of stack trace]
Calling _exit(1). Core file will not be generated.


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

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

Versions of packages chromium depends on:
ii  libasound2   1.1.3-5
ii  libatk1.0-0  2.22.0-1
ii  libavcodec57 7:3.2.10-1~deb9u1
ii  libavformat577:3.2.10-1~deb9u1
ii  libavutil55  7:3.2.10-1~deb9u1
ii  libc62.24-11+deb9u3
ii  libcairo21.14.8-1
ii  libcups2 2.2.1-8+deb9u1
ii  libdbus-1-3  1.10.26-0+deb9u1
ii  libevent-2.0-5   2.0.21-stable-3
ii  libexpat12.2.0-2+deb9u1
ii  libflac8 1.3.2-1
ii  libfontconfig1   2.11.0-6.7+b1
ii  libfreetype6 2.6.3-3.2
ii  libgcc1  1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0   2.36.5-2+deb9u2
ii  libglib2.0-0 2.50.3-2
ii  libgtk2.0-0  2.24.31-2
ii  libicu57 57.1-6+deb9u2
ii  libjpeg62-turbo  1:1.5.1-2
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.12-6
ii  libnss3  2:3.26.2-1.1+deb9u1
ii  libopus0 1.2~alpha2-1
ii  libpango-1.0-0   1.40.5-1
ii  libpangocairo-1.0-0  1.40.5-1
ii  libpng16-16  1.6.28-1
ii  libpulse010.0-1+deb9u1
ii  libre2-3 20170101+dfsg-1
ii  libsnappy1v5 1.1.3-3
ii  libstdc++6   6.3.0-18+deb9u1
ii  libvpx4  1.6.1-3+deb9u1
ii  libwebp6 0.5.2-1
ii  libwebpdemux20.5.2-1
ii  libwebpmux2  0.5.2-1
ii  libx11-6 2:1.6.4-3
ii  libx11-xcb1  2:1.6.4-3
ii  libxcb1  1.12-1
ii  libxcomposite1   1:0.4.4-2
ii  libxcursor1  1:1.1.14-1+deb9u1
ii  libxdamage1  1:1.1.4-2+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-2.2+deb9u2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.29-2.1
ii  libxss1  1:1.2.2-1
ii  libxtst6 2:1.2.3-1
ii  x11-utils7.7+3+b1
ii  xdg-utils1.1.1-1
ii  zlib1g   1:1.2.8.dfsg-5

Versions of packages chromium recommends:
ii  fonts-liberation  1:1.07.4-2
ii  libgl1-mesa-dri   13.0.6-1+b2

Versions of packages chromium suggests:
pn  chromium-driver
pn  chromium-l10n  
pn  chromium-shell 
pn  chromium-widevine  

-- no debconf information

Bug#897165: transition: botan

[GCS]

On Sun, Apr 29, 2018 at 3:14 PM Emilio Pozuelo Monfort 
wrote:
> Control: tags -1 confirmed
> On 29/04/18 12:43, Laszlo Boszormenyi (GCS) wrote:
> > A small, incremental transition of botan 2.4 -> 2.6 as the dependent
> > packages are only biboumi and qtcreator. Both build fine with it.
> >
> > Two things to note. For sixteen days it's still doesn't scheduled to
> > build on armhf, but I don't think it would have any problem. Then it
> > failed to build on armel due to an unrelated problem. I've already
> > requested a give-back just in case.

> That should have been due to #895738, which is already fixed.
  Indeed, I should have noted it is known and fixed.

> Please go ahead.
  Uploaded and already built on most architectures.

Thanks,
Laszlo/GCS

Bug#897188: stretch-pu: package ghostscript/9.20~dfsg-3.2+deb9u2

[Salvatore Bonaccorso]

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

Hi

I would like to propose the following ghostscript update via a stretch
point release. It adresses two CVEs which do not warrant a DSA on it's
own but would still be good to be adressed in stable.

It adresses: 
 - CVE-2018-10194 / 896069. Triggering the poc was not possible here
   but the fix consist of doing an additional check in
   set_text_distance function.
 - CVE-2016-10317, testing happened with the fixed version against the
   provided poc. The fix requires a previous prerequisite change.

Given
https://lists.debian.org/debian-devel-announce/2018/04/msg7.html I
still prefered to get a peer an explicit ack before the upload.

Regards,
Salvatore
diff -Nru ghostscript-9.20~dfsg/debian/changelog 
ghostscript-9.20~dfsg/debian/changelog
--- ghostscript-9.20~dfsg/debian/changelog  2017-09-28 21:47:33.0 
+0200
+++ ghostscript-9.20~dfsg/debian/changelog  2018-04-29 10:58:15.0 
+0200
@@ -1,3 +1,14 @@
+ghostscript (9.20~dfsg-3.2+deb9u2) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Segfault with fuzzing file in gxht_thresh_image_init
+  * Buffer overflow in fill_threshold_buffer (CVE-2016-10317)
+(Closes: #860869)
+  * pdfwrite - Guard against trying to output an infinite number
+(CVE-2018-10194) (Closes: #896069)
+
+ -- Salvatore Bonaccorso   Sun, 29 Apr 2018 10:58:15 +0200
+
 ghostscript (9.20~dfsg-3.2+deb9u1) stretch-security; urgency=high
 
   * Non-maintainer upload by the Security Team.
diff -Nru 
ghostscript-9.20~dfsg/debian/patches/Fix-Bug-696398-Segfault-with-fuzzing-file.patch
 
ghostscript-9.20~dfsg/debian/patches/Fix-Bug-696398-Segfault-with-fuzzing-file.patch
--- 
ghostscript-9.20~dfsg/debian/patches/Fix-Bug-696398-Segfault-with-fuzzing-file.patch
1970-01-01 01:00:00.0 +0100
+++ 
ghostscript-9.20~dfsg/debian/patches/Fix-Bug-696398-Segfault-with-fuzzing-file.patch
2018-04-29 10:58:15.0 +0200
@@ -0,0 +1,29 @@
+From: Ray Johnston 
+Date: Wed, 19 Jul 2017 22:05:33 -0700
+Subject: Fix Bug 696398: Segfault with fuzzing file.
+Origin: 
http://git.ghostscript.com/?p=ghostpdl.git;h=983e56cb679768fe5a048fbb33a43259efb9afbf
+Bug: https://bugs.ghostscript.com/show_bug.cgi?id=696398
+
+Oveflow of integer caused later failure even if allocation of the
+ht_buffer succeeded.  Detect overflow, return error.
+---
+ base/gxht_thresh.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/base/gxht_thresh.c b/base/gxht_thresh.c
+index 35f8e3f57..3fb840213 100644
+--- a/base/gxht_thresh.c
 b/base/gxht_thresh.c
+@@ -711,6 +711,9 @@ gxht_thresh_image_init(gx_image_enum *penum)
+space */
+ max_height = (int) ceil(fixed2float(any_abs(penum->dst_height)) /
+ (float) penum->Height);
++if ((max_height > 0) && (penum->ht_stride * spp_out > max_int / 
max_height))
++return -1; /* overflow */
++
+ penum->ht_buffer =
+ gs_alloc_bytes(penum->memory,
+penum->ht_stride * max_height * spp_out,
+-- 
+2.17.0
+
diff -Nru 
ghostscript-9.20~dfsg/debian/patches/Fix-bug-697459-Buffer-overflow-in-fill_threshold_buf.patch
 
ghostscript-9.20~dfsg/debian/patches/Fix-bug-697459-Buffer-overflow-in-fill_threshold_buf.patch
--- 
ghostscript-9.20~dfsg/debian/patches/Fix-bug-697459-Buffer-overflow-in-fill_threshold_buf.patch
 1970-01-01 01:00:00.0 +0100
+++ 
ghostscript-9.20~dfsg/debian/patches/Fix-bug-697459-Buffer-overflow-in-fill_threshold_buf.patch
 2018-04-29 10:58:15.0 +0200
@@ -0,0 +1,78 @@
+From: Ray Johnston 
+Date: Tue, 21 Nov 2017 12:48:54 -0800
+Subject: Fix bug 697459 Buffer overflow in fill_threshold_buffer
+Origin: 
http://git.ghostscript.com/?p=ghostpdl.git;h=362ec9daadb9992b0def3520cd1dc6fa52edd1c4
+Bug-Debian: https://bugs.debian.org/860869
+Bug: https://bugs.ghostscript.com/show_bug.cgi?id=697459
+Bug-Debian-Security: https://security-tracker.debian.org/tracker/CVE-2016-10317
+
+There was an overflow check for ht_buffer size, but none for the larger
+threshold_buffer. Note that this file didn't fail on Windows because the
+combination of the ht_buffer and the size of the (miscalculated due to
+overflow) threshold_buffer would have exceeded the 2Gb limit.
+---
+ base/gxht_thresh.c | 13 ++---
+ base/gxipixel.c|  2 +-
+ 2 files changed, 11 insertions(+), 4 deletions(-)
+
+diff --git a/base/gxht_thresh.c b/base/gxht_thresh.c
+index 3fb840213..726861685 100644
+--- a/base/gxht_thresh.c
 b/base/gxht_thresh.c
+@@ -711,7 +711,9 @@ gxht_thresh_image_init(gx_image_enum *penum)
+space */
+ max_height = (int) ceil(fixed2float(any_abs(penum->dst_height)) /
+ (float) penum->Height);
+-if ((max_height > 0) && (penum->ht_stride * spp_out > max_int / 
max_height))
++if (m

Bug#897187: RM: ruby2.3 -- ROM; deprecated

[Antonio Terceiro]

Package: ftp.debian.org
Severity: normal

Please remove ruby2.3 from unstable. It has been superseded by ruby2.5,
which is the version that we will ship in Buster.

There are a few reverse dependencies remaining, and they fall in two
categories:

- deprecated binaries in non-release architectures
- deprecated binaries from release architectures, from sources that fail
  to build in unstable for months.

TIA.


signature.asc
Description: PGP signature

Bug#897157: lintian: Allow /usr/share/doc/$pkg/examples to be a symlink

[Chris Lamb]

tags 897157 + moreinfo
thanks

Hi Rafael,

> There are legitimate cases where /usr/share/doc/$pkg/examples is a 
> symlink instead of a directory.

That should be fine already. Indeed, I just added such a test for
symlinks and it passes without any code changes:

  
https://salsa.debian.org/lintian/lintian/commit/1b148029d55c3091bd3751cc5f9a674ae901

(It also does not trigger on, for example src:zsh.)


Best wishes,

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

Bug#482371: check for unregistered repos

[Antoine Beaupre]

As I mentioned in the upstream todo:

I have just used this hack to workaround this issue:

find -maxdepth 1 -type d -a -\( -execdir grep -q {} ~/.mrconfig \; -o -okdir mr 
register '{}' \; -\) 

What it does is look in the current directory, one level deep, for
directories and check if they are in ~/.mrconfig. If they aren't, ask if
they should be registered.

Obviously, this should check for stuff like if .git exists and so on,
but considering the variety of repos supported by mr, i figured I would
keep this simple.

A.


signature.asc
Description: PGP signature

Bug#897099: diffoscope FTBFS with file 5.33

[Chris Lamb]

Chris Lamb wrote:

> Cloning and re-assigning this second issue.

This was #897153, which was fixed in src:file 1:5.33-1. :)


Regards,

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

Bug#897141: RM: abstract-rendering/0.5.1-1

[Adam D. Barratt]

Control: tags -1 -moreinfo
Control: reassign -1 ftp.debian.org

On Sun, 2018-04-29 at 08:46 -0700, Diane Trout wrote:
> On Sun, 2018-04-29 at 10:29 +0100, Adam D. Barratt wrote:
> > Control: tags -1 + moreinfo
> > 
> > On Sat, 2018-04-28 at 16:45 -0700, Diane Trout wrote:
> > > Package: release.debian.org
> > > Severity: normal
> > > User: release.debian@packages.debian.org
> > > Usertags: rm
> > > 
> > > Upstream deleted the project.
> > > 
> > > It was a dependency for some of Continuum Analytics other
> > > projects,
> > > but for
> > > whatever reason they decided to drop it.
> > > 
> > > Nothing in Debian has ever depended on this package.
> > > 
> > 
> > This sounds like you're requesting removal of the package from
> > unstable?
> > 
> 
> Yes I am requesting removal of the package from unstable.
> 
> I haven't requested a removal before. 
> 
> FWIW The instructions at https://www.debian.org/doc/manuals/developer
> s-
> reference/ch05.en.html#removing-pkgs
> 
> Say to file the bug against ftp.debian.org but the reportbug told me
> to file against release.debian.org.

ftp.debian.org is the correct place for an unstable removal - reportbug
/should/ only redirect you if you tell it that you want the package
removing from testing or (old)stable instead.

In any case, re-assigning to ftp.d.o with this message.

Regards,

Adam

Bug#895866: tomcat8: Errors thrown when connecting to default HTTP connector (localhost:8080)

[Alan Orth]

Ubuntu imported tomcat8/8.5.31 just before the 18.04 release and Tomcat will 
not run with OpenJDK 8 there either. Will you be waiting for a new Tomcat 
release before re-compiling tomcat8 to work with OpenJDK 8, or can we schedule 
something sooner?

Bug#897080: Please detect long descriptions starting with lowercase to catch short descriptions continuing into long

[Chris Lamb]

Chris Lamb wrote:

> https://lintian.debian.org/tags/description-synopsis-might-not-be-phrased-properly.html

The following commit should make this easier:

  
https://salsa.debian.org/lintian/lintian/commit/7a2338a808c2dfd6da4d0fbebd0c5b8b0c34afc2


Best wishes,

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

Bug#897080: Please detect long descriptions starting with lowercase to catch short descriptions continuing into long

[Chris Lamb]

Hi Josh,

> With some heuristics to reduce false positives, could we promote this to
> a visible-by-default level?

The first step here would be to ensure that we don't have (too
many!) false-positives:

  
https://lintian.debian.org/tags/description-synopsis-might-not-be-phrased-properly.html

.. and then, perhaps, filing/cloning/retitling a wishlist bug for
it to be raised :)

Don't forget that these warnings (and/or the counts of them) are
available on the user's QA page, eg:

  https://qa.debian.org/developer.php?login=lamby&comaint=no


Best wishes,

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

Bug#845297: Migration to Salsa

[Alex Muntada]

Hi Paul,

> Please note that smart_change.pl needs to work with the new workflow.
> This means that we can't use git commit IDs in translations headers,
> unless we want smart_change.pl to make two commits instead of one.

Thanks for pointing that out. I've been studying smart_change.pl
and I couldn't find where that commit you mention is happening.

> The alternative is to use git file+metadata hashes, which can be
> calculated before a commit happens, placed into translations headers
> and used to diff between two versions of a file. I'm not sure how well
> this will fit with the existing webwml VCS modules though.

Could you elaborate a bit more on the git file+metafile details?
I'm not following you, sorry.

Thanks!
Alex



signature.asc
Description: PGP signature

Bug#896898: mirror submission for sjc.edge.kernel.org

[Bastian Blank]

Hi Konstantin

Do you expect users to explicitely configure this mirror or is this just
an internal name?

Regards,
Bastian

On Wed, Apr 25, 2018 at 03:04:50PM +, Konstantin Ryabitsev wrote:
> Submission-Type: new
> Site: sjc.edge.kernel.org
> Type: leaf
> Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 
> kfreebsd-amd64 kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
> Archive-http: /debian/
> Maintainer: Konstantin Ryabitsev 
> Country: US United States
> Location: San-Jose, CA
> Sponsor: packet.net https://packet.net

-- 
There is an order of things in this universe.
-- Apollo, "Who Mourns for Adonais?" stardate 3468.1

Bug#897179: FTBFS: A build dependency is lacking: appstream-util (>= 0.7.7)

[Jeremy Bicha]

On Sun, Apr 29, 2018 at 11:35 AM, jean-christophe manciot
 wrote:
> You can try yourself to build gimp from an up-to-date sid chroot without
> appstream-util pre-installed.
> You will notice that it is not pulled by dpkg-checkbuilddeps and that the
> build will consequently fail..

Respectfully, the build does work just fine.

https://buildd.debian.org/status/package.php?p=gimp

I spent a fair amount of time today testing the build in different
configurations with the appstream test. If you have appstream-util
installed, you either need to have network access or build using
--without-appdata-test (I applied that change in the Debian packaging
repository today).

Your specific error was because you had an old version of
appstream-util installed (as mentioned on the upstream bug).

Thanks,
Jeremy Bicha

Bug#845297: Migration to Salsa

[Laura Arjona Reina]

Hello again

El 29/04/18 a las 15:01, Paul Wise escribió:
> On Sun, 2018-04-29 at 13:49 +0200, Alex Muntada wrote:
>
>> Therefore, it seems that we'll need to translate CVS revisions to
>> commit IDs at least once after the repository has been migrated
>> finally to git and before any translation is performed.
> Please note that smart_change.pl needs to work with the new workflow.
> This means that we can't use git commit IDs in translations headers,
> unless we want smart_change.pl to make two commits instead of one.
I'm not an expert but getting smart_change.pl doing 2 commits looks like
easy to understand (and maybe to implement?).
First commit for the english folder, and then other commit updating
translations.
> The alternative is to use git file+metadata hashes, which can be
> calculated before a commit happens, placed into translations headers
> and used to diff between two versions of a file. I'm not sure how well
> this will fit with the existing webwml VCS modules though.
>
No idea, either :/

Cheers

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#896840: lintian: autopkgtest fails with new version of file

[Chris Lamb]

Hey Christoph et al.,

> > The more I think about it, the more I think this is a misleading
> > and non-intuitive misfeature of file.
[…]
> > Any thoughts before I essentially re-assign this?
> 
> Rather somehow deal with it?

Whilst I understand what you mean here, the problem is a little
more subtle. Lintian is deliberately making the distinction between
shared objects and PIE executables at the moment in order to detect
various things in this area.

However, with this change, a whole category of files have been
moved from one category to another due to an (almost!) arbitrary
and certainly orthogonal piece of metadata.

Indeed, as I mentioned in passing there is a specific case in the
testsuite to ensure that lintian correctly warns (or doesn't warn),
despite executable bits on a file in question, so this is unlikely
to be hypothethical pedanticism on my part.

This is also ignoring that dealing with it would be rather ugly
AFIACT.

(Certainly understand what you mean about not wishing to carry a
Debian-specific patch, don't worry.)


Regards,

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

Bug#845297: Migration to Salsa

[Laura Arjona Reina]

Hi
Note: you can drop me in the CC, I'm following the bug report via the
debian-www mailing list.

El 29/04/18 a las 13:49, Alex Muntada escribió:

> Laura explained the translation workflow to me, and I thought
> that we wouldn't need to keep track of current CVS revisions
> because using the last commit id from a file and checking if a
> commit id is ancestor to another should be enough:
No, as you note below.
>
>   $ git log -1 --oneline english/license.wml
>   8e8136309fa use https for the link to www.spi-inc.org
>   $ git log -1 --oneline catalan/license.wml
>   8e8136309fa use https for the link to www.spi-inc.org
>   $ git merge-base --is-ancestor 8e8136309fa 8e8136309fa
>   $ echo $?
>   0
>
> However, I didn't take into account that sometimes there are
> changes applied to several files at the same time that have
> nothing to do with translations (as showed in the example above).
>
> Therefore, it seems that we'll need to translate CVS revisions to
> commit IDs at least once after the repository has been migrated
> finally to git and before any translation is performed.
This can be done in the meanwhile in the test_cvs2git repo:

https://salsa.debian.org/webmaster-team/webwml/test_webwml_cvs2git

I've just added there the file cvs-revisions which was generated by the
cvs2git script during the conversion.

> Since we can't be sure that people translating will stop during
> the migration, maybe we can add a kill-switch in the scripts so
> we can enable it before migrating and removing it to enable the
> translation work after everything is setup correctly in git.
>
> Something like this makes sense?
>
>   1. People translate on CVS.
>   2. Add a kill-switch to translations scripts.
>   3. Let people translate on CVS until migration date.
>   4. Enable kill-switch so people cannot translate.
>   5. Migrate repo to git.
>   6. Setup new workflow.
>   7. Make changes to translations docs.
>   8. Remove kill-switch.
>   9. Let people translate on git.
>
> Steps 5-7 should take the shortest time possible to avoid impact,
> of course.
>
> The kill-switch should be very easy to implement, e.g.:
>
>   my $kill_switch = 0;
>   die "Sorry! webwml migration in progress. Check the wiki.\n"
>   if $kill_switch;

I have no opinion on this. Frankly I don't know what to do if we cannot
get the new workflow working when Alioth is shutdown or the cvs service
stopped.
Maybe we can try to setup a CVS repo in other place, or ask translators
to manually keep track of the translation-check line (even when the
dashboards are not working).

>
> Since I'm not very familiar with the translation workflow yet,
> I'd like to work on the Perl scripts that will deal with the
> files in git, etc. But I'm fine doing something else if someone
> prefers to do that.
I think the next steps are:
1.- Writing a script to get all the files with translation-check line to
be updated using the corresponding git hash. (This can be done in the
test_webwml_cvs2git repo, and when we do the authentic migration we run
it again)
2.- Get the copypage.pl and the smart_change.pl scripts working with git
hashes.

Thanks!

-- 
Laura Arjona Reina
https://wiki.debian.org/LauraArjona

Bug#897170: autopkgtest: qemu, lxc, lxd: suggests wrong normal user account if systemd-sysusers is active

[Simon McVittie]

Control: tags -1 + patch
Control: forwarded -1 
https://salsa.debian.org/ci-team/autopkgtest/merge_requests/8

On Sun, 29 Apr 2018 at 14:23:12 +0100, Simon McVittie wrote:
> The patch had a typo in the lxc backend which would have caused it to
> use the wrong uid there. I'll send a new patch and a pull request when
> I've tested it with lxc, and hopefully also lxd.

Fixed and tested with lxc and lxd.

smcv
>From 8e035834f083ad232be3ad180edd7be02015c31b Mon Sep 17 00:00:00 2001
From: Simon McVittie 
Date: Sun, 29 Apr 2018 11:47:47 +0100
Subject: [PATCH] qemu, lxc, lxd: Try to use a user account in the 1000-5
 range

Some autopkgtests, such as the ones for dbus, require an ordinary user
account with a non-trivial home directory. Debian Policy says we are
most likely to find such accounts in the 1000-5 range, and the
vmdebootstrap invocation suggested in autopkgtest-virt-qemu(1)
creates one.

These virt providers look for uids >= 500, which is usually OK,
because adduser --system creates system users in the range 100-999,
starting from the bottom and working upwards.

However, some system users for systemd daemons are now allocated
dynamically by systemd-sysusers, which allocates uids in the system
range 100-999 from the top down: on my test VM, the offending user
account was systemd-coredump, which is used by systemd-coredump but
currently created by /usr/lib/sysusers.d/systemd.conf in systemd.
This is not a suitable account for automated testing, because it
cannot write to its home directory '/' and has the nologin shell.

Signed-off-by: Simon McVittie 
Closes: #897170
---
 virt/autopkgtest-virt-lxc  | 17 -
 virt/autopkgtest-virt-lxd  | 15 +++
 virt/autopkgtest-virt-qemu | 21 -
 3 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/virt/autopkgtest-virt-lxc b/virt/autopkgtest-virt-lxc
index 2dceb72..b47f27b 100755
--- a/virt/autopkgtest-virt-lxc
+++ b/virt/autopkgtest-virt-lxc
@@ -139,7 +139,22 @@ def determine_normal_user(lxc_name):
 
 global capabilities, normal_user
 
-# get the first UID >= 500
+# get the first UID in the Debian Policy §9.2.2 "dynamically allocated
+# user account" range
+cmd = ['lxc-attach', '--name', lxc_name, '--', 'sh', '-c',
+   'getent passwd | sort -t: -nk3 | '
+   "awk -F: '{if ($3 >= 1000 && $3 <= 5) { print $1; exit } }'"]
+out = VirtSubproc.execute_timeout(None, 10, sudoify(cmd),
+  stdout=subprocess.PIPE)[1].strip()
+if out:
+normal_user = out
+capabilities.append('suggested-normal-user=' + normal_user)
+adtlog.debug('determine_normal_user: got user "%s"' % normal_user)
+return
+else:
+adtlog.debug('determine_normal_user: no uid in [1000,5] available')
+
+# failing that, get the first UID >= 500
 cmd = ['lxc-attach', '--name', lxc_name, '--', 'sh', '-c',
'getent passwd | sort -t: -nk3 | '
"awk -F: '{if ($3 >= 500) { print $1; exit } }'"]
diff --git a/virt/autopkgtest-virt-lxd b/virt/autopkgtest-virt-lxd
index a79316f..30e 100755
--- a/virt/autopkgtest-virt-lxd
+++ b/virt/autopkgtest-virt-lxd
@@ -115,6 +115,21 @@ def determine_normal_user():
 
 global capabilities, normal_user
 
+# get the first UID in the Debian Policy §9.2.2 "dynamically allocated
+# user account" range
+cmd = ['lxc', 'exec', container_name, '--', 'sh', '-c',
+   'getent passwd | sort -t: -nk3 | '
+   "awk -F: '{if ($3 >= 1000 && $3 <= 5) { print $1; exit } }'"]
+out = VirtSubproc.execute_timeout(None, 10, cmd,
+  stdout=subprocess.PIPE)[1].strip()
+if out:
+normal_user = out
+capabilities.append('suggested-normal-user=' + normal_user)
+adtlog.debug('determine_normal_user: got user "%s"' % normal_user)
+return
+else:
+adtlog.debug('determine_normal_user: no uid in [1000,5] available')
+
 # get the first UID >= 500
 cmd = ['lxc', 'exec', container_name, '--', 'sh', '-c',
'getent passwd | sort -t: -nk3 | '
diff --git a/virt/autopkgtest-virt-qemu b/virt/autopkgtest-virt-qemu
index afb82e7..37b5db5 100755
--- a/virt/autopkgtest-virt-qemu
+++ b/virt/autopkgtest-virt-qemu
@@ -494,7 +494,26 @@ def determine_normal_user(shared_dir):
 normal_user = args.user
 return
 
-# get the first UID >= 500
+# get the first UID in the Debian Policy §9.2.2 "dynamically allocated
+# user account" range
+term = VirtSubproc.get_unix_socket(os.path.join(workdir, 'ttyS1'))
+term.send(b"getent passwd | sort -t: -nk3 | "
+  b"awk -F: '{if ($3 >= 1000 && $3 <= 5) { print $1; exit } }'"
+  b"> /run/autopkgtest/shared/normal_user\n")
+with VirtSubproc.timeout(5, 'timed out on determining normal user'):
+outfile = os.path.join(shared_dir, 'normal_user')
+while not os.path.exists

Bug#897141: RM: abstract-rendering/0.5.1-1

[Diane Trout]

On Sun, 2018-04-29 at 10:29 +0100, Adam D. Barratt wrote:
> Control: tags -1 + moreinfo
> 
> On Sat, 2018-04-28 at 16:45 -0700, Diane Trout wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: rm
> > 
> > Upstream deleted the project.
> > 
> > It was a dependency for some of Continuum Analytics other projects,
> > but for
> > whatever reason they decided to drop it.
> > 
> > Nothing in Debian has ever depended on this package.
> > 
> 
> This sounds like you're requesting removal of the package from
> unstable?
> 

Yes I am requesting removal of the package from unstable.

I haven't requested a removal before. 

FWIW The instructions at https://www.debian.org/doc/manuals/developers-
reference/ch05.en.html#removing-pkgs

Say to file the bug against ftp.debian.org but the reportbug told me to
file against release.debian.org.

(I think I forgot to be more specific because I'd just filled out the f
tp.debian.org template which was more specific.)

Diane

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

Bug#897153: returns empty string for Berkeley DB databases

[Chris Lamb]

Dear Christoph,

> Yeah, upstream screwed up at another place, and someone was too pushy
> about 5.33 so I ignored the regression although I saw it. Will not
> happen again.

No problem; these things happen. This is what QA and testsuites are
for, after all :)


Best wishes,

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

Bug#897163: Remove CONFIG_SYSTEM_TRUSTED_KEYS="debian/certs/b...@debian.org.cert.pem"

[Ben Hutchings]

Control: tag -1 - security
Control: reassign -1 src:linux 4.15.17-1

There was a Secure Boot sprint earlier this month, during which we
agreed how to do centralised code signing, and I reimplemented the
kernel side of this.

We'll remove this certificate when there's a production certificate to
replace it with, which should happen soon.

Ben.

-- 
Ben Hutchings
[W]e found...that it wasn't as easy to get programs right as we had
thought. I realized that a large part of my life from then on was going
to be spent in finding mistakes in my own programs.
 - Maurice Wilkes, 1949



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

Bug#787289: Rearing it's ugly head again

[Dominique Brazziel]

The last three days have given HTTP connection timeouts (500) on several
mirrors. Direct connection to 'ftp.us.debian.org' works, but using acng
fails.

Bug#897186: libraw: CVE-2018-10529

[Salvatore Bonaccorso]

Source: libraw
Version: 0.18.8-2
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/LibRaw/LibRaw/issues/144

Hi,

The following vulnerability was published for libraw.

CVE-2018-10529[0]:
| An issue was discovered in LibRaw 0.18.9. There is an out-of-bounds
| read affecting the X3F property table list implementation in
| libraw_x3f.cpp and libraw_cxx.cpp.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10529
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10529
[1] https://github.com/LibRaw/LibRaw/issues/144
[2] 
https://github.com/LibRaw/LibRaw/commit/f0c505a3e5d47989a5f69be2d0d4f250af6b1a6c

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#846793: Proposed patch for STIX Two

[Frédéric WANG]

Hi Hugo,

I attach a patch, based on the existing source
https://sources.debian.org/src/fonts-stix/1.1.1-4/debian/

Some comments:

* I just doing this to help so feel free to take authorship (I actually
used your name in the files).

* I created a new package fonts-stix-two since the font is a complete
redesign. I don't know how where you are going to host the source so I
dropped the VCS-* link from the control file (anyway it seems svn is now
deprecated per
https://lintian.debian.org/tags/vcs-deprecated-in-debian-infrastructure.html).

* STIX has moved to github unfortunately I'm not sure there is now an
easy way to track the latest releases so I dropped the watch file.

* I used
https://github.com/stipub/stixfonts/blob/master/STIXv2.0.0.zip?raw=true
as the source file.

* I'm not included any files from the STIXv2.0.0/docs/ directory as
that's what we do for the fonts-stix package.

-- 
Frédéric Wang - frederic-wang.fr

commit b871d6002b3e7d72d4b7b93f2d08b88e57cddfa4
Author: Frédéric Wang 
Date:   Sun Apr 29 15:56:34 2018 +0200

Initial release

diff --git a/README.Debian b/README.Debian
new file mode 100644
index 000..fa2f371
--- /dev/null
+++ b/README.Debian
@@ -0,0 +1,8 @@
+otf-stix-two for Debian
+---
+
+This contains the "STIX Two" fonts, a complete redesign of the original STIX
+fonts. Because of incompatibility with the old versions, it is provided as a
+separate package. See http://stixfonts.org/press_release_v2_00.html
+
+-- Hugo Lefeuvre   Sun, 29 Apr 2018 16:00:00 +0200
diff --git a/changelog b/changelog
new file mode 100644
index 000..40e0e5f
--- /dev/null
+++ b/changelog
@@ -0,0 +1,6 @@
+fonts-stix-two (2.0.0-1) unstable; urgency=low
+
+  * Initial release (Closes: #846793)
+
+ -- Hugo Lefeuvre   Wed, 23 Sep 2015 15:56:16 +0200
+
diff --git a/compat b/compat
new file mode 100644
index 000..f599e28
--- /dev/null
+++ b/compat
@@ -0,0 +1 @@
+10
diff --git a/control b/control
new file mode 100644
index 000..cf7a316
--- /dev/null
+++ b/control
@@ -0,0 +1,19 @@
+Source: fonts-stix-two
+Section: fonts
+Priority: optional
+Maintainer: Hugo Lefeuvre 
+Build-Depends: debhelper (>= 10),
+   unzip
+Standards-Version: 4.1.4
+Homepage: http://www.stixfonts.org
+
+Package: fonts-stix-two
+Architecture: all
+Multi-Arch: foreign
+Depends: ${misc:Depends}
+Description: Scientific and Technical Information eXchange fonts
+ The mission of the Scientific and Technical Information Exchange (STIX) 
+ font creation project is the preparation of a comprehensive set of fonts
+ that serve the scientific and engineering community in the process from
+ manuscript creation through final publication, both in electronic and print
+ formats.
diff --git a/copyright b/copyright
new file mode 100644
index 000..03d544a
--- /dev/null
+++ b/copyright
@@ -0,0 +1,111 @@
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Upstream-Name: stix
+Source: http://www.stixfonts.org/
+
+Files: *
+Copyright: 2001-2016 STI Pub Companies (www.stixfonts.org)
+   1998-2003 MicroPress, Inc. (www.micropress-inc.com) 
+   1990 Elsevier, Inc. 
+License: SIL-OFL-1.1 
+
+Files: debian/*
+Copyright: 2018 Hugo Lefeuvre 
+License: GPL-2
+  This package is free software; you can redistribute it and/or modify
+  it under the terms of the GNU General Public License as published by
+  the Free Software Foundation; either version 2 of the License, or
+  (at your option) any later version.
+  .
+  This package is distributed in the hope that it will be useful,
+  but WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+  GNU General Public License for more details.
+  .
+  You should have received a copy of the GNU General Public License
+  along with this program. If not, see 
+  .
+  On Debian systems, the complete text of the GNU General
+  Public License version 2 can be found in "/usr/share/common-licenses/GPL-2".
+
+License: SIL-OFL-1.1
+  --- 
+  SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007 
+  --- 
+  .
+  PREAMBLE 
+  .
+  The goals of the Open Font License (OFL) are to stimulate worldwide development 
+  of collaborative font projects, to support the font creation efforts of academic 
+  and linguistic communities, and to provide a free and open framework in which 
+  fonts may be shared and improved in partnership with others. 
+  .
+  The OFL allows the licensed fonts to be used, studied, modified and redistributed 
+  freely as long as they are not sold by themselves. The fonts, including any 
+  derivative works, can be bundled, embedded, redistributed and/or sold with any 
+  software provided that any reserved names are not used by derivative works. The
+  fonts and derivatives, however, cannot be rel

Bug#897185: libraw: CVE-2018-10528

[Salvatore Bonaccorso]

Source: libraw
Version: 0.18.8-2
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/LibRaw/LibRaw/issues/144

Hi,

The following vulnerability was published for libraw.

CVE-2018-10528[0]:
| An issue was discovered in LibRaw 0.18.9. There is a stack-based buffer
| overflow in the utf2char function in libraw_cxx.cpp.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2018-10528
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-10528
[1] https://github.com/LibRaw/LibRaw/issues/144
[2] 
https://github.com/LibRaw/LibRaw/commit/895529fc2f2eb8bc633edd6b04b5b237eb4db564

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#897179: FTBFS: A build dependency is lacking: appstream-util (>= 0.7.7)

[jean-christophe manciot]

I pull the sources within the sid chroot from
https://packages.debian.org/source/sid/gimp.
You can try yourself to build gimp from an up-to-date sid chroot
without appstream-util pre-installed.
You will notice that it is not pulled by dpkg-checkbuilddeps and that the
build will consequently fail..

On Sun, Apr 29, 2018 at 5:23 PM Jeremy Bicha  wrote:

> On Sun, Apr 29, 2018 at 11:19 AM, jean-christophe manciot
>  wrote:
> > There is a misunderstanding: this thread is about an up-to-date sid
> chroot
> > built of  gimp.
>
> The build would not have failed in an up-to-date sid chroot with
> networking.
>
> The error you posted in this bug must have been from your Ubuntu 17.10
> build.
>
> Thanks,
> Jeremy Bicha
>


-- 
Jean-Christophe

Bug#897179: FTBFS: A build dependency is lacking: appstream-util (>= 0.7.7)

[Jeremy Bicha]

On Sun, Apr 29, 2018 at 11:19 AM, jean-christophe manciot
 wrote:
> There is a misunderstanding: this thread is about an up-to-date sid chroot
> built of  gimp.

The build would not have failed in an up-to-date sid chroot with networking.

The error you posted in this bug must have been from your Ubuntu 17.10 build.

Thanks,
Jeremy Bicha

Bug#897184: [mnemosyne] No meaningful error message for malformed file on csv import

[bugs]

Package: mnemosyne
Version: 2.4-0.1
Severity: normal

--- Please enter the report below this line. ---

I tried to convert an existing wordlist to be able to import it
to Mnemosyne as 'tab delimited (txt)'.

However, the importer wasn't able to import it and presented an error
message:

"""
An unexpected error has occurred.
Please forward the following info to the developers:

Traceback (innermost last):
  File "/usr/lib/python3/dist-packages/mnemosyne/pyqt_ui/import_dlg.py",
line 76, in accept
self.format().do_import(filename, extra_tag_names)
  File
"/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/file_formats/tsv.py",
line 82, in do_import
tag_names=tag_names, check_for_duplicates=False, save=False)
  File
"/usr/lib/python3/dist-packages/mnemosyne/libmnemosyne/controllers/default_controller.py",
line 112, in create_new_cards
assert card_type.is_fact_data_valid(fact_data)
 AssertionError
"""

In the end, the input file was not absolutely correct: one entry was
missing.
I found out hat this happens when a line directly starts with a tab
(i.e. content is missing).
See also attached file where an error is in line 3.

The other way round (content, tab, line-end) there is a meaningful error
message:
"Badly formed input on line 3:"

--- System information. --
Architecture: Kernel:   Linux 4.9.0-6-amd64

Debian Release: 9.4
  500 stable-updates  ftp.de.debian.org   500 stable
security.debian.org   500 stable  ftp.de.debian.org
--- Package information. ---
Depends (Version) | Installed
=-+-===
libqt5sql5-sqlite | 5.7.1+dfsg-3+b1
python3  (>= 3.5) | 3.5.3-1
python3-cherrypy3 | 3.5.0-2
python3-matplotlib| 2.0.0+dfsg1-2
python3-pyqt5 | 5.7+dfsg-5
python3-pyqt5.qtsql   | 5.7+dfsg-5
python3-pyqt5.qtwebchannel| 5.7+dfsg-5
python3-pyqt5.qtwebengine | 5.7+dfsg-5
python3-webob | 1:1.6.2-2
python3:any (>= 3.5~) | libjs-sphinxdoc
(>= 1.0) | 1.4.9-2

 
 
 

Bug#897179: FTBFS: A build dependency is lacking: appstream-util (>= 0.7.7)

[jean-christophe manciot]

There is a misunderstanding: this thread is about an up-to-date sid chroot
built of  gimp.
Since the build-depends lack the dependency, the first build failed.
But, then I tried to build it on Ubuntu artful (with an outdated
appstream-util) and that gave the other report on gnome.org, where I
discovered what triggered the issue and I tried to build it again in the
same sid chroot with appstream-util  0.7.7 to confirm that the issue was
solved.

On Sun, Apr 29, 2018 at 5:11 PM Jeremy Bicha  wrote:

> On Sun, Apr 29, 2018 at 11:05 AM, jean-christophe manciot
>  wrote:
> > No,  it was built in a sid chroot without appstream-util despite a
> > dpkg-checkbuilddeps.
>
> Could you update your sid chroot then so that it's not a month out of
> date? :)
>
> Jeremy
>


-- 
Jean-Christophe

Bug#896563: RM: libsynctex1 -- ROM; replaced by libsynctex2, should not be used in unstable

[Samuel Thibault]

Hello,

Hilmar Preuße, le ven. 27 avril 2018 09:08:24 +0200, a ecrit:
> On 27.04.2018 08:57, Samuel Thibault wrote:
> >> Furthermore, how should we proceed?
> >>
> >> The texworks and zathura are fixed, but  emacs-pdf-tools, gummi, and
> >> texmaker are still open.
> > 
> > Just a guess: just rebuild them?  Since libsynctex-dev points at 
> > libsynctex2, the rebuild should get the dependency to libsynctex2.
> > 
> libsynctex changed the API, so simply rebuilding the packages does not
> solve the problem. At last for gummi the build fails due to the API change.

Ok.  I have sent patches to the corresponding FTBFS bugs.

Samuel

Bug#896567: texmaker: FTBFS against newer libsyntex

[Samuel Thibault]

Control: tags -1 + patch

Hello,

Sebastian Ramacher, le dim. 22 avril 2018 13:20:24 +0200, a ecrit:
> | ./pdfviewerwidget.cpp:988: undefined reference to `synctex_next_result'

Here is a proposed patch.

Samuel
Index: texmaker-5.0.2/pdfviewer.cpp
===
--- texmaker-5.0.2.orig/pdfviewer.cpp
+++ texmaker-5.0.2/pdfviewer.cpp
@@ -539,7 +539,7 @@ if (scanner == NULL)
   }
 const QFileInfo sourceFileInfo(sourceFile);
 QDir curDir(QFileInfo(pdf_file).canonicalPath());
-synctex_node_t node = synctex_scanner_input(scanner);
+synctex_node_p node = synctex_scanner_input(scanner);
 QString name;
 bool found = false;
 while (node != NULL) 
@@ -558,11 +558,11 @@ if (!found)
   gotoPage(currentPage);
   return;
   }
-if (synctex_display_query(scanner, name.toUtf8().data(), source_line, 0) > 0) 
+if (synctex_display_query(scanner, name.toUtf8().data(), source_line, 0, -1) > 
0) 
   {
   int page = -1;
   path= QPainterPath();
-  while ((node = synctex_next_result(scanner)) != NULL) 
+  while ((node = synctex_scanner_next_result(scanner)) != NULL) 
 {
 if (page == -1) page = synctex_node_page(node);
 if (synctex_node_page(node) != page) continue;
@@ -1018,8 +1018,8 @@ void PdfViewer::jumpToEditor(int page, c
 if (scanner == NULL) return;
 if (synctex_edit_query(scanner, page+1, pos.x(), pos.y()) > 0) 
   {
-  synctex_node_t node;
-  while ((node = synctex_next_result(scanner)) != NULL) 
+  synctex_node_p node;
+  while ((node = synctex_scanner_next_result(scanner)) != NULL) 
 {
 QString filename = QString::fromUtf8(synctex_scanner_get_name(scanner, 
synctex_node_tag(node)));
 QDir curDir(QFileInfo(pdf_file).canonicalPath());
Index: texmaker-5.0.2/pdfviewer.h
===
--- texmaker-5.0.2.orig/pdfviewer.h
+++ texmaker-5.0.2/pdfviewer.h
@@ -37,7 +37,7 @@
 
 #include "qpdfdocument.h"
 #include "documentview.h"
-#include 
+#include 
 
 
 
@@ -84,7 +84,7 @@ bool fileLoaded;
 QPointer proc;
 QString lastFile;
 int lastPage, altern;
-synctex_scanner_t scanner;
+synctex_scanner_p scanner;
 QStringList scalePercents;
 QLineEdit *zoomCustom;
 int lastSearchPos;
Index: texmaker-5.0.2/pdfviewerwidget.cpp
===
--- texmaker-5.0.2.orig/pdfviewerwidget.cpp
+++ texmaker-5.0.2/pdfviewerwidget.cpp
@@ -502,7 +502,7 @@ if (scanner == NULL)
   }
 const QFileInfo sourceFileInfo(sourceFile);
 QDir curDir(QFileInfo(pdf_file).canonicalPath());
-synctex_node_t node = synctex_scanner_input(scanner);
+synctex_node_p node = synctex_scanner_input(scanner);
 QString name;
 bool found = false;
 while (node != NULL) 
@@ -522,11 +522,11 @@ if (!found)
   return;
   }
 
-if (synctex_display_query(scanner, name.toUtf8().data(), source_line, 0) > 0) 
+if (synctex_display_query(scanner, name.toUtf8().data(), source_line, 0, -1) > 
0) 
   {
   int page = -1;
   path= QPainterPath();
-  while ((node = synctex_next_result(scanner)) != NULL) 
+  while ((node = synctex_scanner_next_result(scanner)) != NULL) 
 {
 if (page == -1) page = synctex_node_page(node);
 if (synctex_node_page(node) != page) continue;
@@ -984,8 +984,8 @@ void PdfViewerWidget::jumpToEditor(int p
 if (scanner == NULL) return;
 if (synctex_edit_query(scanner, page+1, pos.x(), pos.y()) > 0) 
   {
-  synctex_node_t node;
-  while ((node = synctex_next_result(scanner)) != NULL) 
+  synctex_node_p node;
+  while ((node = synctex_scanner_next_result(scanner)) != NULL) 
 {
 QString filename = QString::fromUtf8(synctex_scanner_get_name(scanner, 
synctex_node_tag(node)));
 QDir curDir(QFileInfo(pdf_file).canonicalPath());
Index: texmaker-5.0.2/pdfviewerwidget.h
===
--- texmaker-5.0.2.orig/pdfviewerwidget.h
+++ texmaker-5.0.2/pdfviewerwidget.h
@@ -38,7 +38,7 @@
 
 #include "qpdfdocument.h"
 #include "documentview.h"
-#include 
+#include 
 #include "minisplitter.h"
 
 
@@ -83,7 +83,7 @@ bool fileLoaded;
 QPointer proc;
 QString lastFile;
 int lastPage, altern;
-synctex_scanner_t scanner;
+synctex_scanner_p scanner;
 QStringList scalePercents;
 QLineEdit *zoomCustom;
 int lastSearchPos;

Bug#897179: FTBFS: A build dependency is lacking: appstream-util (>= 0.7.7)

[Jeremy Bicha]

On Sun, Apr 29, 2018 at 11:05 AM, jean-christophe manciot
 wrote:
> No,  it was built in a sid chroot without appstream-util despite a
> dpkg-checkbuilddeps.

Could you update your sid chroot then so that it's not a month out of date? :)

Jeremy

Bug#897179: FTBFS: A build dependency is lacking: appstream-util (>= 0.7.7)

[jean-christophe manciot]

No,  it was built in a *sid chroot* without appstream-util despite
a dpkg-checkbuilddeps.

On Sun, Apr 29, 2018 at 4:26 PM Jeremy Bicha  wrote:

> Oh I see you were actually building with Ubuntu 17.10. Well hopefully
> upgrades from 17.10 to 18.04 LTS will be enabled in a few days which
> should also fix this issue for you.
>
> Jeremy
>


-- 
Jean-Christophe

Bug#896562: emacs-pdf-tools: FTBFS against new libsynctex

[Samuel Thibault]

Control: tags -1 + patch

Sebastian Ramacher, le dim. 22 avril 2018 13:12:31 +0200, a ecrit:
> | epdfinfo.c:2974:3: error: unknown type name 'synctex_scanner_t'; use 
> 'struct' keyword to refer to the type

Here is a proposed patch.

Samuel
Index: emacs-pdf-tools-0.80/server/epdfinfo.c
===
--- emacs-pdf-tools-0.80.orig/server/epdfinfo.c
+++ emacs-pdf-tools-0.80/server/epdfinfo.c
@@ -2971,8 +2971,8 @@ cmd_synctex_forward_search (const epdfin
   const char *source = args[1].value.string;
   int line = args[2].value.natnum;
   int column = args[3].value.natnum;
-  synctex_scanner_t scanner = NULL;
-  synctex_node_t node;
+  synctex_scanner_p scanner = NULL;
+  synctex_node_p node;
   float x1, y1, x2, y2;
   PopplerPage *page = NULL;
   double width, height;
@@ -2982,8 +2982,8 @@ cmd_synctex_forward_search (const epdfin
   perror_if_not (scanner, "Unable to create synctex scanner,\
  did you run latex with `--synctex=1' ?");
 
-  perror_if_not (synctex_display_query (scanner, source, line, column)
-&& (node = synctex_next_result (scanner)),
+  perror_if_not (synctex_display_query (scanner, source, line, column, -1)
+&& (node = synctex_scanner_next_result (scanner)),
 "Destination not found");
 
   pn = synctex_node_page (node);
@@ -3026,10 +3026,10 @@ cmd_synctex_backward_search (const epdfi
   int pn = args[1].value.natnum;
   double x = args[2].value.edge;
   double y = args[3].value.edge;
-  synctex_scanner_t scanner = NULL;
+  synctex_scanner_p scanner = NULL;
   const char *filename;
   PopplerPage *page = NULL;
-  synctex_node_t node;
+  synctex_node_p node;
   double width, height;
   int line, column;
 
@@ -3044,7 +3044,7 @@ cmd_synctex_backward_search (const epdfi
   y = y * height;
 
   if (! synctex_edit_query (scanner, pn, x, y)
-  || ! (node = synctex_next_result (scanner))
+  || ! (node = synctex_scanner_next_result (scanner))
   || ! (filename =
 synctex_scanner_get_name (scanner, synctex_node_tag (node
 {

Bug#896566: gummi: FTBFS against new libsyntex

[Samuel Thibault]

Control: tags -1 + patch

Hello,

Sebastian Ramacher, le dim. 22 avril 2018 13:17:48 +0200, a ecrit:
> | gui/gui-preview.c:1044:5: error: unknown type name 'synctex_scanner_t'; use 
> 'struct' keyword to refer to the type

Here is a proposed patch.

Samuel
Index: gummi-0.6.6/src/gui/gui-preview.c
===
--- gummi-0.6.6.orig/src/gui/gui-preview.c
+++ gummi-0.6.6/src/gui/gui-preview.c
@@ -1041,18 +1041,18 @@ static gboolean synctex_run_parser(GuPre
 gint column = gtk_text_iter_get_line_offset(sync_to);
 slog(L_DEBUG, "Syncing to %s, line %i, column %i\n", tex_file, line, 
column);
 
-synctex_scanner_t sync_scanner = 
synctex_scanner_new_with_output_file(pc->uri, C_TMPDIR, 1);
+synctex_scanner_p sync_scanner = 
synctex_scanner_new_with_output_file(pc->uri, C_TMPDIR, 1);
 
 synctex_clear_sync_nodes(pc);
 
-if(synctex_display_query(sync_scanner, tex_file, line, column)>0) {
-synctex_node_t node;
+if(synctex_display_query(sync_scanner, tex_file, line, column, -1)>0) {
+synctex_node_p node;
 /*
  * SyncTeX can return several nodes. It seems best to use the last 
one, as
  * this one rarely is below (usually slighly above) the edited line.
  */
 
-while ((node = synctex_next_result(sync_scanner))) {
+while ((node = synctex_scanner_next_result(sync_scanner))) {
 
 SyncNode *sn = g_new0(SyncNode, 1);
 
@@ -2038,16 +2038,16 @@ gboolean on_button_pressed(GtkWidget* w,
 
 slog(L_DEBUG, "Ctrl-click to %i, %i\n", x, y);
 
-synctex_scanner_t sync_scanner = 
synctex_scanner_new_with_output_file(pc->uri, C_TMPDIR, 1);
+synctex_scanner_p sync_scanner = 
synctex_scanner_new_with_output_file(pc->uri, C_TMPDIR, 1);
 
 if(synctex_edit_query(sync_scanner, page+1, x/pc->scale, 
y/pc->scale)>0) {
-synctex_node_t node;
+synctex_node_p node;
 /*
  * SyncTeX can return several nodes. It seems best to use the last 
one, as
  * this one rarely is below (usually slighly above) the edited 
line.
  */
 
-if ((node = synctex_next_result(sync_scanner))) {
+if ((node = synctex_scanner_next_result(sync_scanner))) {
 
 const gchar *file = synctex_scanner_get_name(sync_scanner, 
synctex_node_tag(node));
 gint line = synctex_node_line(node);

Bug#897152: Bug #897152 in flightcrew marked as pending

[Mattia Rizzolo]

On Sun, Apr 29, 2018 at 09:11:45AM -0500, Steve Robbins wrote:
> Thanks for the heads up.  I looked at the commit and made a comment there.  
> Not sure if you get notified...

I did, but it was kind of too late since I had already uploaded… (pushed
everything and dput at the same time, not good for peer reviews!)

I'll follow up there.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature