Bug#873160: python-pymad: pymad in stretch decodes to noise

[Marc Dahn]

Package: python-pymad
Version: 0.10-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

When decoding at least several MP3 files (including at 22050 kHz
single-channel and 44100 kHz dual-channel, non-VBR), python-pymad in
stretch generates fairly horrific sound (chr-chr-chr) at least on i386.
If one looks at the decoded bytes, there's a clear overabundance of
zeroes, but in the one case I looked at they even included a string .
"7/email/encoders.py", so it's probably not just an integer format
issue.

The good news is:  The version currently in testing, 0.10-1, fixes
the problem, so it's probably not worth further investigating this
particular issue.  It *would* be good if the fix could somehow slip
into stable, though.


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

Kernel: Linux 4.12.2 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=de_DE.ISO-8859-1 (charmap=ISO-8859-1), LANGUAGE=C 
(charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)

Versions of packages python-pymad depends on:
ii  libc62.24-11+deb9u1
ii  libmad0  0.15.1b-8
ii  python   2.7.13-2

python-pymad recommends no packages.

python-pymad suggests no packages.

-- no debconf information

Bug#873159: jack-capture FTCBFS: unsatisfiable Build-Depends: binutils

[Helmut Grohne]

Source: jack-capture
Version: 0.9.73-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

jack-capture fails to satisfy its cross build dependencies, because its
(host architecture) binutils dependency is in conflict with the (build
architecture) binutils dependency from build-essential. In theory, the
dependency would need "toolchain dependency cross translation", but it
is much easier to just drop the redundant dependency. After doing so,
jack-capture cross builds successfully. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru jack-capture-0.9.73/debian/changelog 
jack-capture-0.9.73/debian/changelog
--- jack-capture-0.9.73/debian/changelog2017-06-27 14:22:21.0 
+0200
+++ jack-capture-0.9.73/debian/changelog2017-08-25 07:13:17.0 
+0200
@@ -1,3 +1,10 @@
+jack-capture (0.9.73-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop implicitly satisfied binutils build dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Fri, 25 Aug 2017 07:13:17 +0200
+
 jack-capture (0.9.73-2) unstable; urgency=medium
 
   * Fix build on mips and mipsel.
diff --minimal -Nru jack-capture-0.9.73/debian/control 
jack-capture-0.9.73/debian/control
--- jack-capture-0.9.73/debian/control  2017-06-27 14:13:49.0 +0200
+++ jack-capture-0.9.73/debian/control  2017-08-25 07:13:15.0 +0200
@@ -6,7 +6,6 @@
  Jaromír Mikeš ,
  Adrian Knoth 
 Build-Depends:
- binutils,
  debhelper (>= 10),
  libgtk2.0-dev,
  libjack-dev | libjack-jackd2-dev,

Bug#873158: liboggz FTCBFS: unsatisfiable Build-Depends, fails running tests despite DEB_BUILD_OPTIONS=nocheck

[Helmut Grohne]

Source: liboggz
Version: 1.1.1-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

liboggz fails to cross build from source for two reasons:

 * The binutils build dependency (treated as host arch) conflicts with
   the binutils dependency from build-essential. It would need
   "toolchain dependency cross translation", but the version restriction
   is so old, that it is simpler to just remove the dependency.
 * It fails running tests despite DEB_BUILD_OPTIONS=nocheck.

After fixing both, liboggz cross builds successfully. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru liboggz-1.1.1/debian/changelog 
liboggz-1.1.1/debian/changelog
--- liboggz-1.1.1/debian/changelog  2016-05-26 14:50:02.0 +0200
+++ liboggz-1.1.1/debian/changelog  2017-08-25 07:03:49.0 +0200
@@ -1,3 +1,12 @@
+liboggz (1.1.1-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Drop ancient binutils build dependency satisfied in wheezy.
++ Honour DEB_BUILD_OPTIONS=nocheck.
+
+ -- Helmut Grohne   Fri, 25 Aug 2017 07:03:49 +0200
+
 liboggz (1.1.1-5) unstable; urgency=medium
 
   * Changed Standards-Version from 3.9.6 to 3.9.8.
diff --minimal -Nru liboggz-1.1.1/debian/control liboggz-1.1.1/debian/control
--- liboggz-1.1.1/debian/control2016-05-26 14:17:54.0 +0200
+++ liboggz-1.1.1/debian/control2017-08-25 07:03:48.0 +0200
@@ -10,7 +10,6 @@
  , libogg-dev
  , doxygen
  , docbook-to-man
- , binutils (>= 2.12.90.0.9)
  , libtool
  , bash-completion (>= 1.1)
  , dh-autoreconf
diff --minimal -Nru liboggz-1.1.1/debian/rules liboggz-1.1.1/debian/rules
--- liboggz-1.1.1/debian/rules  2016-05-26 13:36:01.0 +0200
+++ liboggz-1.1.1/debian/rules  2017-08-25 07:03:49.0 +0200
@@ -6,9 +6,11 @@
 override_dh_strip:
dh_strip --dbg-package=liboggz2-dbg
 
+ifeq ($(filter nocheck,$(DEB_BUILD_OPTIONS)),)
 # Run our test suite until the upstream source get one
 override_dh_auto_test:
dh_auto_test
for t in debian/tests/test-*; do \
BUILDDIR=`pwd` $$t; \
done
+endif

Bug#873157: diffoscope: Support the new fork of python-progressbar

[Santiago Torres-Arias]

Package: diffoscope
Version: 85
Severity: wishlist
Tags: upstream

Dear Maintainer,

While trying to install/use diffoscope from pip (or the Arch Linux
package), I realized that the --progress flag triggers a crash. The
reason as to why this happens is that there are two forks of the
python-progressbar package available, whith slightly different api's.

The one being used by Debian[1] seems to be an abandoned version
(without any updates in two years), whereas there exists a more
actively-developed alternative[2] (possible a takeover). This issue has
also been brought up to the maintainers of python-progressbar, who are
evaluating this upstream change[3]. An arch user suggested a fairly
minimal patch to fix it[4], and there is an more-elaborate descrption of
the API change on the comments of this bug report[5].

It'd be nice if diffoscope was made aware of these versions and possibly
choose the right one depending on which one is available.

Thanks!
-Santiago.

[1] https://github.com/niltonvolpato/python-progressbar
[2] https://github.com/WoLpH/python-progressbar
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=839149
[4] http://codepad.org/oIr6JudF
[5] https://bugs.archlinux.org/task/53505

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

Kernel: Linux 4.12.7-coreos (SMP w/8 CPU cores) 
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Versions of packages diffoscope depends on:
ii  python33.5.3-1
pn  python3-libarchive-c   
pn  python3-magic  
ii  python3-pkg-resources  33.1.1-1

Versions of packages diffoscope recommends:
pn  acl
pn  apktool
pn  binutils-multiarch 
ii  bzip2  1.0.6-8.1
pn  caca-utils 
pn  colord 
pn  default-jdk-headless | default-jdk | java-sdk  
pn  enjarify   
pn  fontforge-extras   
pn  fp-utils   
pn  genisoimage
pn  gettext
pn  ghc
pn  ghostscript
pn  gnupg  
pn  imagemagick
pn  jsbeautifier   
pn  llvm   
pn  mono-utils 
pn  openssh-client 
pn  pdftk  
pn  poppler-utils  
pn  python3-argcomplete
ii  python3-debian 0.1.30
pn  python3-guestfs
pn  python3-progressbar
pn  python3-rpm
pn  python3-tlsh   
pn  rpm2cpio   
pn  sng
pn  sqlite3
pn  squashfs-tools 
pn  unzip  
pn  xxd | vim-common   
ii  xz-utils   5.2.2-1.2+b1

Versions of packages diffoscope suggests:
pn  libjs-jquery  

Bug#873136: New upstream release

[Adam Bilbrough]

Hi,I have uploaded a new xz tarball to mentors.debian.org version 0.5-1
~Adam

Bug#873156: fofix: FoFiX.py rises a NotImplementedError on startup

[Christian Trenkwalder]

Package: fofix
Version: 3.121-4
Severity: important
Tags: patch

Dear Maintainer,
after installing the fofix package on a (up-to-date) system, 
the application terminates due to unhandlet exception.
This is caused by the usage of the removed 'tostring()' within python and 
python suggests 'tobytes()' should be used instead. 

After replacing the tostring() calls with tobytes() as suggested, 
the application becomes usable.

I have attached a diff at the end of the report.

kind regards
Christian


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

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

Versions of packages fofix depends on:
ii  python  2.7.13-2
ii  python-imaging  4.2.1-1
ii  python-numpy1:1.12.1-3+b2
ii  python-opengl   3.1.0+dfsg-1
ii  python-pygame   1.9.1release+dfsg-10+b2

Versions of packages fofix recommends:
ii  python-ogg   1.3+repack-7
ii  python-pyaudio   0.2.11-1+b1
ii  python-pyvorbis  1.5-4

Versions of packages fofix suggests:
pn  python-psyco  

-- no debconf information

-- Diff after patching:

30c30
< 
---
> 
77c77
<   string = image.tostring('raw', 'RGBA', 0, -1)
---
>   string = image.tobytes('raw', 'RGBA', 0, -1)
80c80
<   string = image.tostring('raw', 'RGB', 0, -1)
---
>   string = image.tobytes('raw', 'RGB', 0, -1)
83c83
<   string = image.tostring('raw', 'L', 0, -1)
---
>   string = image.tobytes('raw', 'L', 0, -1)
89c89
< string = image.tostring('raw', 'RGB', 0, -1)
---
> string = image.tobytes('raw', 'RGB', 0, -1)
114c114
<   string = pygame.image.tostring(surface, "RGB")
---
>   string = pygame.image.tobytes(surface, "RGB")
116c116
<   string = image.tostring('raw', 'L', 0, -1)
---
>   string = image.tobytes('raw', 'L', 0, -1)
120c120
< string = pygame.image.tostring(surface, "RGBA", True)
---
> string = pygame.image.tobytes(surface, "RGBA", True)
123c123
< string = pygame.image.tostring(surface, "RGB", True)
---
> string = pygame.image.tobytes(surface, "RGB", True)

Bug#871688: exim4-base: using su in cronjob invokes a full pam-session. use runuser instead

[Jakob Schürz]

Am 2017-08-14 um 16:30 schrieb Marc Haber:
> On Thu, Aug 10, 2017 at 07:19:14PM +0200, Jakobus Schürz wrote:
>> You find my changes below to use runuser instead of su, which solves the
>> problems comming from the su-command.
> 
> Given that I have never heard of runuser in 20+ years of Unix
> experience, shouldn't probably the su man page mention runuser?

I've also heard about runuser first time, when i asked in the
systemd-list... It seems, it's build from the su-code-base (found a
Website on searching about this command) to avoid the problems if you
want to run a command as another UID/GID with a whole session... like my
Problem.

It's available since util-linux 2.23

:)

Greetings

Jakob








signature.asc
Description: OpenPGP digital signature

Bug#873155: [uim-gtk3] Invokes segmentation fault with ibus integrated into gnome

[Katsuhiko Nishimra]

Package: uim-gtk3
Version: 1:1.8.6+gh20161003.0.d63dadd-4
Severity: minor
Control: affects -1 + ibus

Dear maintainer,

While I was moving from uim to ibus, I removed uim-skk but failed to
remove uim-gtk3 package. And then, with ibus integrated into gnome,
every gnome application started to being killed by SIGSEGV.

To prevent this kind of failure, wouldn't it be better to mark uim-gtk3
as Conflicts with ibus or some other packages?

FWIW, I attach environment varibles and a backtrace from a coredump that
gnome-terminal-server dumped.
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/gnome-terminal/gnome-terminal-server...Reading 
symbols from 
/usr/lib/debug/.build-id/fe/f468d5716310ec7ba75f54802770c465c07f61.debug...done.
done.
[New LWP 8172]
[New LWP 8173]
[New LWP 8174]
[New LWP 8175]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `/usr/lib/gnome-terminal/gnome-terminal-server'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fcf6eb2ff22 in _XReply () from /usr/lib/x86_64-linux-gnu/libX11.so.6
[Current thread is 1 (Thread 0x7fcf72b3ba80 (LWP 8172))]
(gdb) $1 = (char ***) 0x7fcf7076df38 
(gdb) $2 = {0x7ffd882cbb33 
"DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus", 0x7ffd882cbb69 
"DEBEMAIL=ktns...@gmail.com", 0x7ffd882cbb84 "DEBFULLNAME=Katsuhiko Nishimra", 
0x7ffd882cbba3 "DESKTOP_SESSION=gnome", 
  0x7ffd882cbbb9 "DISPLAY=:0", 0x7ffd882cbbc4 "EMAIL=ktns...@gmail.com", 
0x7ffd882cbbdc "GDMSESSION=gnome", 0x7ffd882cbbed "GDM_LANG=ja_JP.UTF-8", 
0x7ffd882cbc02 "GNOME_DESKTOP_SESSION_ID=this-is-deprecated", 
  0x7ffd882cbc2e "HOME=/home/ktns", 0x7ffd882cbc3e "JOURNAL_STREAM=9:67267", 
0x7ffd882cbc55 "LANG=ja_JP.UTF-8", 0x7ffd882cbc66 
"LD_LIBRARY_PATH=/usr/local/lib:/usr/local/vmd/lib", 0x7ffd882cbc98 
"LOGNAME=ktns", 
  0x7ffd882cbca5 
"MANPATH=/usr/local/man:/usr/local/share/man:/usr/share/man:/home/ktns/.rvm/man",
 0x7ffd882cbcf4 "OLDPWD=/home/ktns", 
  0x7ffd882cbd06 
"PATH=/usr/local/vmd/bin:/usr/local/cmake-trunk/bin:/usr/local/bin:/usr/bin:/bin:/usr/games:/home/ktns/scripts/bin:/home/ktns/.rvm/bin",
 0x7ffd882cbd8c "PWD=/home/ktns", 0x7ffd882cbd9b "QT_IM_MODULE=ibus", 
  0x7ffd882cbdad "RUBYLIB=/home/ktns/preferences/rubylib", 0x7ffd882cbdd4 
"SESSION_MANAGER=local/netzach:@/tmp/.ICE-unix/1396,unix/netzach:/tmp/.ICE-unix/1396",
 0x7ffd882cbe28 "SHELL=/bin/zsh", 0x7ffd882cbe37 "SHLVL=0", 
  0x7ffd882cbe3f "SSH_AUTH_SOCK=/run/user/1000/keyring/ssh", 0x7ffd882cbe68 
"SYSTEMD_PAGER=less -R", 0x7ffd882cbe7e "USER=ktns", 0x7ffd882cbe88 
"USERNAME=ktns", 0x7ffd882cbe96 "WAYLAND_DISPLAY=wayland-0", 
  0x7ffd882cbeb0 "XDG_CURRENT_DESKTOP=GNOME", 0x7ffd882cbeca 
"XDG_MENU_PREFIX=gnome-", 0x7ffd882cbee1 "XDG_RUNTIME_DIR=/run/user/1000", 
0x7ffd882cbf00 "XDG_SEAT=seat0", 0x7ffd882cbf0f "XDG_SESSION_DESKTOP=gnome", 
  0x7ffd882cbf29 "XDG_SESSION_ID=2", 0x7ffd882cbf3a "XDG_SESSION_TYPE=wayland", 
0x7ffd882cbf53 "XDG_VTNR=2", 0x7ffd882cbf5e "XMODIFIERS=@im=ibus", 
0x7ffd882cbf72 "_=/usr/bin/gnome-session", 0x7ffd882cbf8b "MANAGERPID=1380", 
  0x7ffd882cbf9b "INVOCATION_ID=507470d6283b43eab1fb815c6ed43db7", 
0x557b9a124aa0 "G_ENABLE_DIAGNOSTIC=0"}
(gdb) #0  0x7fcf6eb2ff22 in _XReply () at 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#1  0x7fcf6eb1ea0f in XGetModifierMapping () at 
/usr/lib/x86_64-linux-gnu/libX11.so.6
#2  0x7fcf57246435 in im_uim_init_modifier_keys () at 
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-uim.so
#3  0x7fcf57245d68 in im_module_init () at 
/usr/lib/x86_64-linux-gnu/gtk-3.0/3.0.0/immodules/im-uim.so
#4  0x7fcf7201d7cb in gtk_im_module_load (module=0x557b9a6aa3c0 
[GtkIMModule]) at ././gtk/gtkimmodule.c:171
#5  0x7fcf70edea83 in g_type_module_use (module=module@entry=0x557b9a6aa3c0 
[GtkIMModule]) at ../../../../gobject/gtypemodule.c:244
#6  0x7fcf7201e0a2 in _gtk_im_module_create (context_id=) at 
././gtk/gtkimmodule.c:651
#7  0x7fcf7201ebeb in gtk_im_multicontext_get_slave 
(multicontext=multicontext@entry=0x557b9a696e30 [GtkIMMulticontext]) at 
././gtk/gtkimmulticontext.c:275
#8  0x7fcf7201efa5 in gtk_im_multicontext_set_client_window 
(context=0x557b9a696e30 [GtkIMMulticontext], window=0x557b9a6ae320 
[GdkWaylandWindow]) at 

Bug#873154: dpkg: warning: unable to delete old directory '/etc/java-9-openjdk': Directory not empty

[積丹尼 Dan Jacobson]

Package: openjdk-9-jre-headless
Version: 9~b181-3

Unpacking openjdk-9-jre-headless:amd64 (9~b181-3) over (9~b181-2) ...
dpkg: warning: unable to delete old directory 
'/usr/lib/jvm/java-9-openjdk-amd64/lib/server': Directory not empty
dpkg: warning: unable to delete old directory 
'/etc/java-9-openjdk/security/policy/unlimited': Directory not empty
dpkg: warning: unable to delete old directory 
'/etc/java-9-openjdk/security/policy/limited': Directory not empty
dpkg: warning: unable to delete old directory 
'/etc/java-9-openjdk/security/policy': Directory not empty
dpkg: warning: unable to delete old directory '/etc/java-9-openjdk/security': 
Directory not empty
dpkg: warning: unable to delete old directory '/etc/java-9-openjdk/management': 
Directory not empty
dpkg: warning: unable to delete old directory '/etc/java-9-openjdk': Directory 
not empty

$ find /etc/java-9-openjdk -type f|xargs ls -og
-rw-r--r-- 1   357 2015-09-05  /etc/java-9-openjdk/accessibility.properties
-rw-r--r-- 1  1628 08-07 22:28 /etc/java-9-openjdk/jvm-amd64.cfg
-rw-r--r-- 1  2731 08-07 22:28 /etc/java-9-openjdk/logging.properties
-rw-r--r-- 1  3997 08-07 22:28 /etc/java-9-openjdk/management/jmxremote.access
-rw-r--r-- 1 14634 08-07 22:28 
/etc/java-9-openjdk/management/management.properties
-rw-r--r-- 1  4464 08-07 22:28 /etc/java-9-openjdk/net.properties
-rw-r--r-- 1  3793 08-07 22:28 /etc/java-9-openjdk/psfont.properties.ja
-rw-r--r-- 1 11390 08-07 22:28 /etc/java-9-openjdk/psfontj2d.properties
-rw-r--r-- 1  1253 08-07 22:28 /etc/java-9-openjdk/security/blacklisted.certs
-rw-r--r-- 1  7589 08-07 22:28 /etc/java-9-openjdk/security/default.policy
-rw-r--r-- 1  2180 08-07 22:28 /etc/java-9-openjdk/security/java.policy
-rw-r--r-- 1 38660 08-07 22:28 /etc/java-9-openjdk/security/java.security
-rw-r--r-- 1   106 08-07 22:28 /etc/java-9-openjdk/security/nss.cfg
-rw-r--r-- 1  1490 08-07 22:28 /etc/java-9-openjdk/security/policy/README.txt
-rw-r--r-- 1   146 08-07 22:28 
/etc/java-9-openjdk/security/policy/limited/default_US_export.policy
-rw-r--r-- 1   647 08-07 22:28 
/etc/java-9-openjdk/security/policy/limited/default_local.policy
-rw-r--r-- 1   566 08-07 22:28 
/etc/java-9-openjdk/security/policy/limited/exempt_local.policy
-rw-r--r-- 1   146 08-07 22:28 
/etc/java-9-openjdk/security/policy/unlimited/default_US_export.policy
-rw-r--r-- 1   193 08-07 22:28 
/etc/java-9-openjdk/security/policy/unlimited/default_local.policy
-rw-r--r-- 1  1210 08-07 22:28 /etc/java-9-openjdk/sound.properties
-rw-r--r-- 1   113 2015-06-16  /etc/java-9-openjdk/swing.properties

Bug#873153: dependency problems - leaving unconfigured

[積丹尼 Dan Jacobson]

Package: openjdk-9-jre

dpkg: dependency problems prevent configuration of openjdk-9-jre:amd64:
 openjdk-9-jre:amd64 depends on openjdk-9-jre-headless (= 9~b181-3); however:
  Package openjdk-9-jre-headless:amd64 is not configured yet.

dpkg: error processing package openjdk-9-jre:amd64 (--configure):
 dependency problems - leaving unconfigured
Processing triggers for man-db (2.7.6.1-2) ...
Processing triggers for dbus (1.11.16+really1.11.16-2) ...
Processing triggers for hicolor-icon-theme (0.15-1) ...
Setting up openjdk-8-jre-headless:amd64 (8u144-b01-1) ...
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
Setting up systemd-sysv (234-2.3) ...
Setting up libpangoft2-1.0-0:amd64 (1.40.11-1) ...
Setting up openjdk-8-jre:amd64 (8u144-b01-1) ...
update-alternatives: warning: alternative 
/usr/lib/jvm/java-9-openjdk-amd64/bin/java (part of link group java) doesn't 
exist; removing from list of alternatives
Setting up libpam-systemd:amd64 (234-2.3) ...
Setting up libpangoxft-1.0-0:amd64 (1.40.11-1) ...
Setting up libpangocairo-1.0-0:amd64 (1.40.11-1) ...
Setting up gir1.2-pango-1.0:amd64 (1.40.11-1) ...
Setting up libpango1.0-0:amd64 (1.40.11-1) ...
Processing triggers for initramfs-tools (0.130) ...
update-initramfs: Generating /boot/initrd.img-4.12.0-1-amd64
Processing triggers for libc-bin (2.25-0experimental1) ...
Errors were encountered while processing:
 openjdk-9-jre-headless:amd64
 openjdk-9-jre:amd64
E: Sub-process /usr/bin/dpkg returned an error code (1)
Setting up openjdk-9-jre-headless:amd64 (9~b181-3) ...
update-alternatives: error: alternative path 
/usr/lib/jvm/java-9-openjdk-amd64/bin/rmid doesn't exist
dpkg: error processing package openjdk-9-jre-headless:amd64 (--configure):
 subprocess installed post-installation script returned error exit status 2
dpkg: dependency problems prevent configuration of openjdk-9-jre:amd64:
 openjdk-9-jre:amd64 depends on openjdk-9-jre-headless (= 9~b181-3); however:
  Package openjdk-9-jre-headless:amd64 is not configured yet.

dpkg: error processing package openjdk-9-jre:amd64 (--configure):
 dependency problems - leaving unconfigured
Errors were encountered while processing:
 openjdk-9-jre-headless:amd64
 openjdk-9-jre:amd64

Bug#870729: NMU for the FTBFS

[Adam Borowski]

Hi!
I see you guys don't exactly give any damn about libgnomeui.  I don't do so
either, but:
* there's still a lot of packages depending on it
* I was the last NMUer and I dislike RC bugs on my QA pages

Thus, here's a NMU with Adrian Bunk's patch, debdiff attached.  I'm
uploading to DELAYED/7 right away for fire-and-forget goodness.  As usually,
dcut or holler if anything is wrong.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 
diff -Nru libgnomeui-2.24.5/debian/changelog libgnomeui-2.24.5/debian/changelog
--- libgnomeui-2.24.5/debian/changelog  2016-01-14 07:19:42.0 +0100
+++ libgnomeui-2.24.5/debian/changelog  2017-08-25 03:25:24.0 +0200
@@ -1,3 +1,10 @@
+libgnomeui (2.24.5-3.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTBFS with glib 2.54 (Adrian Bunk). Closes: #870729.
+
+ -- Adam Borowski   Fri, 25 Aug 2017 03:25:24 +0200
+
 libgnomeui (2.24.5-3.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru libgnomeui-2.24.5/debian/patches/03_glib-2.54-ftbfs.patch 
libgnomeui-2.24.5/debian/patches/03_glib-2.54-ftbfs.patch
--- libgnomeui-2.24.5/debian/patches/03_glib-2.54-ftbfs.patch   1970-01-01 
01:00:00.0 +0100
+++ libgnomeui-2.24.5/debian/patches/03_glib-2.54-ftbfs.patch   2017-08-25 
03:24:24.0 +0200
@@ -0,0 +1,16 @@
+Description: Fix FTBFS with glib 2.54
+ glib-mkenums now expects input files to be UTF-8,
+ fix the encoding of libgnomeui/gnome-scores.h
+Author: Adrian Bunk 
+
+--- libgnomeui-2.24.5.orig/libgnomeui/gnome-scores.h
 libgnomeui-2.24.5/libgnomeui/gnome-scores.h
+@@ -27,7 +27,7 @@
+  * "High Scores" Widget 
+  *
+  * AUTHOR: 
+- * Horacio J. Pe�a 
++ * Horacio J. Peña 
+  *
+  * This is free software (under the terms of the GNU LGPL)
+  *
diff -Nru libgnomeui-2.24.5/debian/patches/series 
libgnomeui-2.24.5/debian/patches/series
--- libgnomeui-2.24.5/debian/patches/series 2016-01-14 07:20:34.0 
+0100
+++ libgnomeui-2.24.5/debian/patches/series 2017-08-25 03:24:24.0 
+0200
@@ -1,2 +1,3 @@
 01_link_libm.patch
 02_time_t_printfs.patch
+03_glib-2.54-ftbfs.patch

Bug#871572: urweb FTBFS with gcc 7 on arm64 and mips64el: test failure

[Benjamin Barenblat]

On Mon, Aug 21, 2017 at 10:02 AM, Benjamin Barenblat  wrote:
> I did an arm64 build with -O1 (i.e., I put
>
> export DEB_CFLAGS_MAINT_APPEND := -O1
>
> in debian/rules), and everything worked fine […]. I’m doing a mips64el
> build with -O1 right now to see if that fixes the issue on mipsel64. If
> it does, I’ll start binary-searching the individual -O2 optimization
> flags to see exactly what’s triggering this.

-O1 built fine on mipsel64. One binary search later, and I’ve determined
that the problematic optimization on both platforms is
-fcode-hoisting. This is a new optimization pass in GCC 7 which “tries
to move the evaluation of expressions executed on all paths to the
function exit as early as possible.”¹

While this doesn’t eliminate either a bug in MLton or in GCC, it does
provide a workaround for this package, namely

export DEB_CFLAGS_MAINT_APPEND := -fno-code-hoisting

However, the correct solution is still to fix whatever compiler is
miscompiling here. I’m going to do a bit more digging to see if I can
figure out whether it’s MLton or GCC.


¹https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Optimize-Options.html#index-fcode-hoisting

Bug#872942: vim-python: neovim missed

[James McCoy]

On Wed, Aug 23, 2017 at 01:34:47PM +0300, Adrian Bunk wrote:
> reassign 872942 neovim

Looping in python-neovim folks, since it might be better to have the
Provides there.  Without python(3)-neovim installed, there is no python
support.  It's probably also worth having those "Recommends: neovim",
since the most common use is in conjunction with a local neovim
instance.

> On Tue, Aug 22, 2017 at 09:44:23PM +0300, Ulyanich Michael wrote:
> > Probably package neovim should be added to the list of alternative versions 
> > of
> > package vim-python.
> > It will allow neovim users install some packages with vim plugins (such as 
> > vim-
> > youcompleteme) without installing another versions of vim (right now I have 
> > the
> > package vim-nox installed on my system only in order to satisfy 
> > dependencies,
> > although I don't use vim-nox).
> > I am not pretty sure that neovim is absolutely compatible with every package
> > that depends on "vim-python", so you should decide whether or not to perform
> > any changes.

That's not entirely true.  python-neovim only provides the older python
interface, not the bindeval interface.  From a quick perusal of
codesearch.debian.net, nothing packaged appears to be using the bindeval
interface (except powerline, which has a fallback).

Another piece to consider is that there should probably be a
differentiation between the Python2 and Python3 interfaces.  I didn't
rename the Provides when Vim was changed to use Python3, since it can
only provide one or the other.  However, for the sake of clarity, and
because src:python-neovim builds both bindings, there should probably be
"Provides: vim-python" and "Provides: vim-python3".

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

Bug#873128: texlive-lang-arabic: XEPERSIAN PROBLEM WITH FONTSPEC ON DEBIAN STABLE

[Norbert Preining]

severity -1 minor
tags -1 + moreinfo
thanks

Please provide details - the subject alone is not enough.

In particular, see what is written here in *your* email:

On Thu, 24 Aug 2017, Hassan Abedi wrote:
> If you report an error when running one of the TeX-related binaries 
> (latex, pdftex, metafont,...), or if the bug is related to bad or wrong
> output, please include a MINIMAL example input file that produces the
> error in your report.

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#873152: utopia-documents: Fails to build with qt5.9

[Steve Langasek]

Package: utopia-documents
Version: 3.0.2-1
Severity: serious
Tags: patch
Justification: FTBFS
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu artful ubuntu-patch

Hi James,

In Ubuntu, we've found that utopia-documents fails to build against Qt5.9
with the following error:

[ 16%] Generating moc_bubble.cpp
cd /<>/utopia-build/libutopia2_qt/utopia2/qt && 
/usr/lib/x86_64-linux-gnu/qt5/bin/moc 
@/<>/utopia-build/libutopia2_qt/utopia2/qt/moc_bubble.cpp_parameters
/<>/libutopia2_qt/utopia2/qt/bubble.h:56: Error: Namespace 
declaration lacks Q_NAMESPACE macro.
libutopia2_qt/utopia2/qt/CMakeFiles/utopia2_qt_autogen.dir/build.make:80: 
recipe for target 'libutopia2_qt/utopia2/qt/moc_bubble.cpp' failed

Full build logs can be found at 
https://launchpad.net/ubuntu/+source/utopia-documents/3.0.2-1

Since the Qt stack is nearly identical between artful and Debian unstable, I
believe (but have not tested) that this build failure applies to Debian as
well.

I have attached the attached patch to fix the build failure in Ubuntu.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru utopia-documents-3.0.2/debian/patches/fix-namespace-declaration.patch 
utopia-documents-3.0.2/debian/patches/fix-namespace-declaration.patch
--- utopia-documents-3.0.2/debian/patches/fix-namespace-declaration.patch   
1969-12-31 16:00:00.0 -0800
+++ utopia-documents-3.0.2/debian/patches/fix-namespace-declaration.patch   
2017-08-24 17:05:58.0 -0700
@@ -0,0 +1,17 @@
+Description: add required Q_NAMESPACE macro to namespace
+ Qt 5.9 doesn't like namespaces without Q_NAMESPACE macro.
+Author: Steve Langasek 
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1710317
+
+Index: utopia-documents-3.0.2/libutopia2_qt/utopia2/qt/bubble.h
+===
+--- utopia-documents-3.0.2.orig/libutopia2_qt/utopia2/qt/bubble.h
 utopia-documents-3.0.2/libutopia2_qt/utopia2/qt/bubble.h
+@@ -55,6 +55,7 @@
+ 
+ namespace Utopia
+ {
++Q_NAMESPACE
+ 
+ typedef enum
+ {
diff -Nru utopia-documents-3.0.2/debian/patches/series 
utopia-documents-3.0.2/debian/patches/series
--- utopia-documents-3.0.2/debian/patches/series2017-04-10 
05:13:10.0 -0700
+++ utopia-documents-3.0.2/debian/patches/series2017-08-24 
16:58:24.0 -0700
@@ -1 +1,2 @@
 remove-utopia-update-check.diff
+fix-namespace-declaration.patch

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Russ Allbery]

Henrique de Moraes Holschuh  writes:
> On Thu, 24 Aug 2017, Sean Whitton wrote:

>> Seconded, but I think the integrity protection is a more important
>> reason to avoid the git protocol or http, so if we can come up with a
>> further change to reflect that it would be better.

> Attacking the integrity of the messages in transit requires active MITM
> attacks for all three protocols (http, https, git).

> https *without* strong certificate validation has no defense against
> active MITM, i.e. it does *not* protect message integrity against
> attacks.

> And since all of the required PKI for https to do strong certificate
> validation is out-of-band, we have to assume naive https use.

> So, no, this is not about integrity.  It is, at most, about privacy
> against passive eavesdropers.  If you want integrity, a lot more is
> needed.

Right, exactly.

That said, the *scheme* still offers "integrity protection" in the
technical protocol sense (it protects against the tampering of messages
between the two endpoints of the protocol scheme), so we can say
confidentiality and integrity protection in the Policy language.  People
just shouldn't assume this provides any meaningful integrity protection in
the semantic sense.

-- 
Russ Allbery (r...@debian.org)   

Bug#872867: is ISO-3166 really the optimal list for our users?

[Charles Plessy]

Le Thu, Aug 24, 2017 at 06:22:16PM +0200, Daniel Pocock a écrit :
> 
> mirrors in Kosovo.

Hi again Daniel and everybody,

please do not take it as a negative view on the work who set up these
mirrors, but for most installations in Kosovo, do you know how their
performance compares to the deb.debian.org content delivery network ?

Some of the users in Kosovo may travel in other countries, or other
continents, and for them having deb.debian.org by default can make their
regular system updates simpler, as they would not have to manage
/etc/apt/sources.list according to their geographical location.

Have a nice day,

-- 
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan

Bug#870426: cython: Break build dependency cycle with python-numpy

[Ximin Luo]

Control: tags -1 upstream
Control: forwarded -1 https://github.com/cython/cython/issues/1843

I've asked upstream about this, waiting for an answer.

X

On Tue, 1 Aug 2017 14:04:57 -0700 Daniel Schepler  wrote:
> Source: cython
> Version: 0.25.2-2
> Severity: wishlist
> 
> Currently, src:cython and src:python-numpy both have Build-Depends on
> each other which makes it difficult to bootstrap those packages.  It
> would be nice if one or the other could provide a build profile to
> break this cycle.
> 
> The cython source package successfully builds if I drop the build
> dependencies on python-numpy, python3-numpy, and gdb and then build
> with DEB_BUILD_OPTIONS=nocheck.  However, I don't really know enough
> about the package to tell whether the resulting binary packages are
> unchanged.  If so, then it should be enough just to update
> debian/control with something like:
> 
> Build-Depends: debhelper (>= 7.0.50~), dpkg-dev (>= 1.16.1~),
> python-all-dev (>= 2.6.6-3~), python-all-dbg, help2man (>= 1.37.1~),
> python-sphinx, python-numpy , python3-all-dev,
> python3-all-dbg, python3-numpy , gdb 
> 
> Otherwise, the results might still be useful for bootstrapping; but
> then you would need to have it produce renamed packages like
> cython-stage1, and then update other source packages involved in
> cycles to be able to build using that.
> -- 
> Daniel Schepler
> 
> 

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Henrique de Moraes Holschuh]

On Thu, 24 Aug 2017, Sean Whitton wrote:
> Seconded, but I think the integrity protection is a more important
> reason to avoid the git protocol or http, so if we can come up with a
> further change to reflect that it would be better.

Attacking the integrity of the messages in transit requires active MITM
attacks for all three protocols (http, https, git).

https *without* strong certificate validation has no defense against
active MITM, i.e. it does *not* protect message integrity against
attacks.

And since all of the required PKI for https to do strong certificate
validation is out-of-band, we have to assume naive https use.

So, no, this is not about integrity.  It is, at most, about privacy
against passive eavesdropers.  If you want integrity, a lot more is
needed.

-- 
  Henrique Holschuh

Bug#873132: RFS: dav-text/0.8.6-2 [ITA] -- minimal ncurses-based text editor

[Adam Borowski]

On Thu, Aug 24, 2017 at 09:09:17PM +0200, Adam Bilbrough wrote:
> Package name: dav-text
> Version: 0.8.6-2


> Changes since the last upload:
> 
> * Wishlist bug implemented (closes: #872848)

This changelog entry is quite useless.  Could you please describe what the
change is?


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#873136: xmltoman_0.4-5_source.changes REJECTED

[Adam Borowski]

On Thu, Aug 24, 2017 at 11:24:47PM +, Debian FTP Masters wrote:
> xmltoman_0.4-5.dsc: Refers to non-existing file 'xmltoman_0.4.orig.tar.xz'
> Perhaps you need to include the file in your upload?

Turns out your orig tarball differs from what's in the archive.
Since they use different compression (.gz vs .xz), both the previous and new
versions of the source built okay on my side, the problem didn't show up on
debdiff, etc.

When using the unmodified 0.4 tarball, the source fails to build:

 dpkg-source -b xmltoman-0.4
dpkg-source: info: using source format '3.0 (quilt)'
dpkg-source: info: building xmltoman using existing ./xmltoman_0.4.orig.tar.gz
dpkg-source: info: local changes detected, the modified files are:
 xmltoman-0.4/Makefile
 xmltoman-0.4/xmlmantohtml
 xmltoman-0.4/xmltoman
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/xmltoman_0.4-5.diff.SHeBKD

As you're using the quilt format, you'd need to either:
* put the changes as a patch (dpkg-source --commit can be helpful), or
* (as you're the new upstream) release a new upstream version


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ Vat kind uf sufficiently advanced technology iz dis!?
⢿⡄⠘⠷⠚⠋⠀ -- Genghis Ht'rok'din
⠈⠳⣄ 

Bug#873150: tracker: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly.

[Jorge Morais Neto]

Package: tracker
Version: 1.10.5-1
Severity: important
Tags: upstream

Dear Maintainer, this is upstream bug
[https://bugzilla.gnome.org/show_bug.cgi?id=779342].  It was fixed upstream, but
still occurs in my workstation.  The only symptom I perceive is the message in
/var/log/messages, but I do not know what bad effects this may have.
Can I safely ignore this issue?

I manually sent this report via Gmail because reportbug was unable to
send it itself.

Regards

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

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

Versions of packages tracker depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.10.18-1
ii  dbus-x11 [dbus-session-bus]   1.10.18-1
ii  dconf-gsettings-backend [gsettings-backend]   0.26.0-2+b1
ii  libc6 2.24-11+deb9u1
ii  libexempi32.4.1-1
ii  libglib2.0-0  2.50.3-2
ii  libglib2.0-bin2.50.3-2
ii  libtagc0  1.11.1+dfsg.1-0.1
ii  libtracker-control-1.0-0  1.10.5-1
ii  libtracker-sparql-1.0-0   1.10.5-1
ii  shared-mime-info  1.8-1

Versions of packages tracker recommends:
ii  tracker-gui   1.10.5-1
ii  tracker-miner-fs  1.10.5-1

tracker suggests no packages.

-- no debconf information

Bug#873151: tigervnc-standalone-server: Forced disconnections clog up the VNC server

[Mikko Rasa]

Package: tigervnc-standalone-server
Version: 1.7.0+dfsg-7
Severity: normal

I am running a graphical IRC client in a VNC server.  Previously I used
realvnc, but since it got removed from Debian I switched to tigervnc around
the start of the year.  Since then I've noticed that after the VNC server has
been running for a month or two, I can no longer get in on the first try.  A
second attempt is successful, until eventually it will require three attempts
and so on.  Eventually enough attempts are required that my client is
blacklisted before I can successfully connect.

Some methodical testing revealed a way to reproduce the issue.  Start a vnc
server process:

tigervncserver :10 -SecurityTypes None

Then run a loop to start client processes:

while :; do xvncviewer localhost:10 & sleep 1; done

You can do a tail -f on the server log in another terminal if you wish.  Soon
enough you will start getting popups for "Too many security failures".  The
log will look something like this:

Fri Aug 25 01:51:26 2017
 Connections: accepted: 127.0.0.1::34667

Fri Aug 25 01:51:27 2017
 Connections: accepted: 127.0.0.1::34668

Fri Aug 25 01:51:28 2017
 Connections: accepted: 127.0.0.1::34669
 SConnection: Client needs protocol version 3.8
 SConnection: Client requests security type None(1)
 VNCSConnST:  Server default pixel format depth 24 (32bpp) little-endian rgb888
 Connections: closed: 127.0.0.1::34668 (Non-shared connection requested)
 EncodeManager: Framebuffer updates: 0
 EncodeManager:   Total: 0 rects, 0 pixels
 EncodeManager:  0 B (1:-nan ratio)
 Connections: closed: 127.0.0.1::34667 (Non-shared connection requested)
 EncodeManager: Framebuffer updates: 0
 EncodeManager:   Total: 0 rects, 0 pixels
 EncodeManager:  0 B (1:-nan ratio)
 Connections: closed: 127.0.0.1::34666 (Non-shared connection requested)
 EncodeManager: Framebuffer updates: 1
 EncodeManager:   Tight:
 EncodeManager: Solid: 1 rects, 2.28 Mpixels
 EncodeManager:16 B (1:570001 ratio)
 EncodeManager:   Total: 1 rects, 2.28 Mpixels
 EncodeManager:  16 B (1:570001 ratio)
 VNCSConnST:  Client pixel format depth 24 (32bpp) little-endian rgb888

Note that no client information was printed for the two stub attempts.  After
a successful connection is made, the two stub connections are terminated, as
well as the previous live connection.

Using shared connections can be used to work around the problem.  The failure
mechanism seems to rely on connection "slots"; after a connection is forcibly
terminated, its slot will become permanently unusable and the next connection
to land in that slot will remain in a limbo indefinitely.  However since a
shared connection does not terminate other connections, the defunct slots
remain filled with stub connections and each new connection gets a viable
slot.

I have not yet delved into the code, but based on this observation my theory
is that there's an array of connections that gets reused, and new connections
are incompletely initialized.  A forced disconnection and subsequent new
connection in the same array index would then land in a bad state where the
server won't process it further.

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

Kernel: Linux 3.19.1-core2 (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages tigervnc-standalone-server depends on:
ii  libaudit1 1:2.7.7-1+b2
ii  libbsd0   0.8.6-1
ii  libc6 2.24-14
ii  libgcc1   1:7.2.0-1
ii  libgcrypt20   1.7.8-2
ii  libgl1-mesa-glx [libgl1]  13.0.6-1+b2
ii  libgnutls30   3.5.13-2
ii  libjpeg62-turbo   1:1.5.1-2
ii  libpam0g  1.1.8-3.6
ii  libpixman-1-0 0.34.0-1
ii  libselinux1   2.6-3+b2
ii  libstdc++67.2.0-1
ii  libsystemd0   232-25
ii  libx11-6  2:1.6.4-3
ii  libxau6   1:1.0.8-1+b2
ii  libxdmcp6 1:1.1.2-3
ii  libxfont2 1:2.0.1-3
ii  libxshmfence1 1.2-1+b2
ii  perl  5.26.0-5
ii  x11-xkb-utils 7.7+3+b1
ii  xauth 1:1.0.9-1+b2
ii  xkb-data  2.19-1.1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages tigervnc-standalone-server recommends:
pn  libgl1-mesa-dri
ii  tigervnc-common1.7.0+dfsg-7
ii  x11-xserver-utils  7.7+7+b1
ii  xfonts-base1:1.0.4+nmu1

Versions of packages tigervnc-standalone-server suggests:
ii  xfonts-75dpi 1:1.0.4+nmu1
pn  xfonts-scalable  

-- no debconf information

Bug#869006: Pending fixes for bugs in the jnr-unixsocket package

[pkg-java-maintainers]

tag 869006 + pending
thanks

Some bugs in the jnr-unixsocket package are closed in revision
b6e37392bd2d4bd212334360dcd22013a21ca1de in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/jnr-unixsocket.git/commit/?id=b6e3739

Commit message:

Removed the build dependency on libmaven-assembly-plugin-java (Closes: 
#869006)

Bug#871162: Pending fixes for bugs in the carrotsearch-hppc package

[pkg-java-maintainers]

tag 871162 + pending
thanks

Some bugs in the carrotsearch-hppc package are closed in revision
0d1117f57f126cbaf3435672ed4725e688b9dedf in branch 'master' by
Emmanuel Bourg

The full diff can be seen at
https://anonscm.debian.org/cgit/pkg-java/carrotsearch-hppc.git/commit/?id=0d1117f

Commit message:

Fixed the build failure caused by the build-helper-maven-plugin upgrade 
(Closes: #871162)

Bug#872299: gnome-orca: Orca segfaults on startup

[Tim Smith]

I upgraded python3-pyatspi and libatspi2.0-0, and now orca runs!  Let me
know if you still want me to install the debug packages and send you the
gdb result using the old core file.

Unfortunately, there is a new problem: there is no audio.  The console
output shows several errors:

/usr/lib/python3/dist-packages/pyatspi/Accessibility.py:184: Warning:
g_object_unref: assertion 'G_IS_OBJECT (object)' failed
  Atspi.Event.host_application = property(fget=lambda x:
x.source.get_application())

(orca:8089): Gtk-CRITICAL **: gtk_notebook_get_tab_label: assertion 'list
!= NULL' failed

/usr/lib/python3/dist-packages/pyatspi/Accessibility.py:41: Warning:
g_object_unref: assertion 'G_IS_OBJECT (object)' failed
  len=self.get_child_count()

Thanks for any help you can give.

Tim


On Wed, Aug 23, 2017 at 4:03 PM, Samuel Thibault 
wrote:

> Tim Smith, on mar. 22 août 2017 23:43:45 -0400, wrote:
> > Here's the generated core file:
> >
> > [1]https://www.dropbox.com/s/94ymmn8uhmdyge4/core?raw=1
>
> Mmm, it doesn't match the binaries on my system, it looks like you have
> a mixture of packages from stable, testing and unstable...
>
> Could you for a start upgrade these packages:
>
>   python3-pyatspi libatspi2.0-0
>
> and enable this in apt's sources.list:
>
>   deb http://debug.mirrors.debian.org/debian-debug/ stable-debug main
>   deb http://debug.mirrors.debian.org/debian-debug/ testing-debug main
>   deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main
>
> and install these packages:
>
>   gdb python3-dbg python3-pyatspi-dbgsym libatspi2.0-0-dbgsym
> libdbus-1-3-dbgsym libglib2.0-0-dbgsym
>
> and run gdb yourself on the core file:
>
>   gdb /usr/bin/python3 core
>
> and at the gdb> prompt, type
>
>   bt full
>
> and send us the result.
> Samuel
>

Bug#873149: python-argcomplete: Should set TERM while running tests

[Michael Hudson-Doyle]

Source: python-argcomplete
Version: 1.8.1-1
Severity: normal
Tags: patch

Dear Maintainer,

Hi, python-argcomplete does not build in Ubuntu because apparently TERM is
unset during the build. Setting to something sane when running the tests seems
like a good idea for this package anyway, so here's a patch that does that.

Cheers,
mwh

-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (400, 'xenial-proposed'), (100, 'xenial-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-92-generic (SMP w/4 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru python-argcomplete-1.8.1/debian/rules python-argcomplete-1.8.1/debian/rules
--- python-argcomplete-1.8.1/debian/rules	2017-01-25 06:05:43.0 +1300
+++ python-argcomplete-1.8.1/debian/rules	2017-07-20 14:40:02.0 +1200
@@ -26,6 +26,9 @@
 		cp debian/$$i.1 debian/python3-argcomplete/usr/share/man/man1/$${i}3.1; \
 	done
 
+override_dh_auto_test:
+	TERM=vt100 dh_auto_test
+
 generate_manpages:
 	VERSION=$$(./setup.py -V) ; \
 	for file in \

Bug#872944: www.debian.org: Debian Policy Manual not fully published

[Laura Arjona Reina]

El 24/08/17 a las 23:05, Sean Whitton escribió:
> Hello Laura,
> 
> On Thu, Aug 24 2017, Laura Arjona Reina wrote:
> 
>>
>> * If we should use the packages from "sid" as we use for the
>> documentation packages, or stable, or backports...
> 
> If it's easy, we'd prefer you to use them from sid, because that's what
> we develop the package against.
> 

I guess it's the same easy to use one of another. My concern is about doing the
right thing... making our web visitors run javascript code from sid in their
browsers does not sound right for me.

Would you (Debian Policy Team) consider acceptable to leave the website version
of the manual as it is now, without any javascript? I guess we are loosing some
search function and maybe some text animations, but for what I've seen, the page
looks ok... and in the manual it's said that the manual is provided by the
package debian-policy, and that is available in different formats. The website
version could be considered a "plain HTML" version, then...

Best regards

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

Bug#873148: Fails to properly escape the ;, {, }, <, and > characters

[Bastien ROUCARIES]

Package: node-shell-quote
severity: serious
forwarded: https://github.com/substack/node-shell-quote/issues/31

couple of open issues that seem reasonably
serious for a package that appears to be intended for sanitising user
input before passing it on to the shell:

Bug#873047: libgfshare: gfsplit SIGSEGV if /dev/urandom is not accessible

[Chris Lamb]

Hi Simon,

> Patch attached

Updated patch attached.

For some reason vim went a bit crazy and set gfshare_fill_rand twice. Y'know,
just to be sure it's set...


Best wishes,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/tools/gfsplit.c b/tools/gfsplit.c
index 9aadb22..c02c4d4 100644
--- a/tools/gfsplit.c
+++ b/tools/gfsplit.c
@@ -164,6 +164,7 @@ main( int argc, char **argv )
   if (access("/dev/urandom", R_OK) == 0) {
 gfshare_fill_rand = gfsplit_fill_rand;
   } else {
+gfshare_fill_rand = gfshare_bad_idea_but_fill_rand_using_random;
 fprintf(stderr, "\
 %s: Cannot access /dev/urandom, so using rand() instead (not secure!)\n\
 ", progname);

Bug#873042: [tryton-debian] Bug#873042: tryton-meta: Please combine src:tryton-modules-* to a single source package with multiple binaries

[Chris Lamb]

Hi Mathias,

Thanks for your reply. :)

> Yes, this was considered and discussed in depth quite some time ago with my AM
> (Wouter), who had the same idea. After some tests it turned out that it is
> still better (mainly for maintenance reasons) to stick with separate source
> packages.

Hm, could you spend a moment listing the reasons here? At least it'll
give you something to link to in the future :)


Best wishes,

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

Bug#682347: mark 'editor' virtual package name as obsolete

[Russ Allbery]

Christoph Berg  writes:

> Thanks for the notice. I'm quite surprised that my dnsvi seems to be the
> only package in Debian that requires a text editor. Given that our base
> doesn't really include one, and getting dependencies Just Right is among
> the things that Debian is really good at, dropping the existing "editor"
> virtual package seems Just Wrong to me.

Yeah, that gut instinct resonates with me too.  But... we've not done this
since 1996, so is it worth the effort to try to get everyone to change?  I
feel like going the other route would be some amount of work for a bunch
of packages with no perceivable benefit in Debian.

I can write language for that instead, but I know way, way more packages
assume that editor is available than currently depend on it, and I'm
reluctant to declare them to be buggy.  You seem to be the only package
maintainer who was using this "correctly."

Note that if we do go down the path of making it official, we'd probably
need to introduce something like default-editor and standardize a
dependency of default-editor | editor, so this is a non-trivial amount of
work.  (You don't want a package to depend on editor and pull emacs25 into
a minimal chroot because that happened to be the first package providing
editor that apt saw.)  For instance, you depend on vim | editor right now,
but vim is quite heavy-weight, and our default editor is nano.

> Even if "editor" was de-officialized in 1996, it is very much used
> today. Bill's original list from 2015 was incomplete (it is much longer
> now, but given that even emacs was missing, I'd think the grep command
> used back then was wrong):

I re-ran this check with my original message and Bcc'd everyone who came
up as providing editor (using grep-aptavail).  I didn't include the list
in one of the bug messages but probably should have.

-- 
Russ Allbery (r...@debian.org)   

Bug#682347: mark 'editor' virtual package name as obsolete

[Russ Allbery]

Jonathan Nieder  writes:
> Russ Allbery wrote:

>> +++ b/policy/ch-customized-programs.rst
>> @@ -93,19 +93,21 @@ page.
> [...]
>> -It is not required for a package to depend on ``editor`` and ``pager``,
>> -nor is it required for a package to provide such virtual
>> -packages. [#]_
>> +Packages may assume that ``/usr/bin/editor`` and ``/usr/bin/pager`` are
>> +available as fallbacks without adding an explicit package dependency, and
>> +may fail if they are not present.  There are no ``editor`` or ``pager``
>> +virtual packages.

> One change this patch makes is to talk about /usr/bin/editor and
> /usr/bin/pager files instead of editor and pager files.  Is that
> intentional?

> E.g. git uses "editor" as its default editor, not /usr/bin/editor.

This isn't a change -- that was already the language from the paragraph
above:

Thus, every program that launches an editor or pager must use the
EDITOR or PAGER environment variable to determine the editor or pager
the user wishes to use. If these variables are not set, the programs
``/usr/bin/editor`` and ``/usr/bin/pager`` should be used,
respectively.

So in theory git has a (non-RC) bug for using editor and not
/usr/bin/editor.  (If you think that's wrong, that's probably a separate
bug; I can see it both ways, depending on how much you want to trust the
PATH.)

> What should packages do if an editor is configured and the "editor"
> command is not available?

I tried to address that by saying that the program can just fail.  In
other words, do whatever you would do when the system() or execv() call
fails for some other reason.

-- 
Russ Allbery (r...@debian.org)   

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Russ Allbery]

Sean Whitton  writes:
> On Wed, Aug 23 2017, Russ Allbery wrote:

>> --- a/policy/ch-controlfields.rst
>> +++ b/policy/ch-controlfields.rst
>> @@ -962,6 +962,10 @@ repository where the Debian source package is developed.
>>  
>>  More than one different VCS may be specified for the same package.
>>  
>> +For both fields, any URLs given should use a scheme that provides
>> +confidentiality (``https``, for example, rather than ``http`` or ``git``)
>> +if the VCS repository supports it.
>> +
>>  .. _s-f-Package-List:
>>  
>>  ``Package-List``

> Seconded, but I think the integrity protection is a more important
> reason to avoid the git protocol or http, so if we can come up with a
> further change to reflect that it would be better.

Maybe I should just say:

a scheme that provides confidentiality and integrity protection

I think I was over-thinking it.

(That said, my understanding is that you don't get any meaningful
integrity protection for Git from using https over http.)

-- 
Russ Allbery (r...@debian.org)   

Bug#873122: HTTP Link to Keyring

[Andreas Ronnquist]

On Thu, 24 Aug 2017 19:53:59 +0200,
Hanno Böck wrote:

>Package: www.debian.org
>
>When downloading a Debian CD there's a webpage explaining how to verify
>signatures:
>https://www.debian.org/CD/verify
>
>This recommends to check the signatures with the keys from the Debian
>GPG keyring. However that link is HTTP, pointing to:
>http://keyring.debian.org/
>
>It will immediately redirect to HTTPS, but an attacker could intercept
>that redirection and present a user with a malicious keyring instead.
>
>This makes the verification kinda pointless, as the keyring is
>delivered over a potentially insecure channel. The lack of HSTS on
>debian.org makes this particularly worriesome. Please change that link
>to HTTPS.
>

Thanks guys, this has been fixed in the CVS repository (including
translations) - It will be visible on the debian web pages when it has
been rebuilt (It rebuilds several times a day).

Thanks for your report!

-- Andreas Rönnquist
mailingli...@gusnan.se
gus...@debian.org

Bug#873147: pam-krb5-migrate: please revert #837695 change (Heimdal removal)

[Thorsten Glaser]

Source: pam-krb5-migrate
Version: 0.0.11-4
Severity: important

Dear Maintainer,

please revert the change from #837695 as Heimdal made it back,
and provide the package in stretch-backports once it will have
entered testing, to make libpam-krb5-migrate-heimdal available
again.

Thanks!

Bug#873079: unattended-upgrades FTBFS: test failures

[Balint Reczey]

Control: tags -1 confirmed

Hi Adrian,

Thanks for the report.

On Thu, 24 Aug 2017 13:10:16 +0300 Adrian Bunk  wrote:
> Source: unattended-upgrades
> Version: 0.95
> Severity: serious
>
>
https://buildd.debian.org/status/fetch.php?pkg=unattended-upgrades=all=0.95=1503510785=0
>

Interestingly the package built (and builds) fine in my schroot. I
suspect the issue is related to using system's apt config which i'll fix
in the next upload.

Cheers,
Balint

Bug#868794: Please check bppphyview

[Andreas Tille]

Hi Julien,

I reassigned this bug to bppphyview.  Unfortunately this error

...
[100%] Linking CXX executable phyview
cd /build/bppphyview-0.5.1/obj-x86_64-linux-gnu/bppPhyView && /usr/bin/cmake -E 
cmake_link_script CMakeFiles/phyview.dir/link.txt --verbose=1
/usr/bin/c++  -std=c++11 -Wall  -Wl,-z,relro -Wl,-z,now -rdynamic 
CMakeFiles/phyview.dir/PhyView.cpp.o CMakeFiles/phyview.dir/TreeSubWindow.cpp.o 
CMakeFiles/phyview.dir/TreeCommands.cpp.o 
CMakeFiles/phyview.dir/moc_PhyView.cxx.o 
CMakeFiles/phyview.dir/moc_TreeSubWindow.cxx.o  -o phyview 
/usr/lib/x86_64-linux-gnu/libbpp-qt.so.1.0.1 
/usr/lib/x86_64-linux-gnu/libQtCore.so /usr/lib/x86_64-linux-gnu/libQtGui.so 
/usr/lib/x86_64-linux-gnu/libbpp-phyl.so.11.0.0 
/usr/lib/x86_64-linux-gnu/libbpp-seq.so.11.0.0 
/usr/lib/x86_64-linux-gnu/libbpp-core.so.3.0.0 
/usr/lib/x86_64-linux-gnu/libQtCore.so 
/usr/lib/x86_64-linux-gnu/libbpp-phyl.so.11.0.0: undefined reference to 
`virtual thunk to bpp::AbstractParameterAliasable::getAliases() const'
collect2: error: ld returned 1 exit status
bppPhyView/CMakeFiles/phyview.dir/build.make:218: recipe for target 
'bppPhyView/phyview' failed
make[3]: *** [bppPhyView/phyview] Error 1
make[3]: Leaving directory '/build/bppphyview-0.5.1/obj-x86_64-linux-gnu'
CMakeFiles/Makefile2:153: recipe for target 
'bppPhyView/CMakeFiles/phyview.dir/all' failed
make[2]: *** [bppPhyView/CMakeFiles/phyview.dir/all] Error 2
make[2]: Leaving directory '/build/bppphyview-0.5.1/obj-x86_64-linux-gnu'
Makefile:154: recipe for target 'all' failed
make[1]: *** [all] Error 2
...

remains even with the gcc-7 rebuilt libs.  Could you have a look?

   Vcs-Git: https://anonscm.debian.org/git/debian-med/bppphyview.git

Kind regards

  Andreas.

-- 
http://fam-tille.de

Bug#873113: RFS: xssproxy/1.0.0-1 [ITP]

[Andrey Rahmatullin]

On Thu, Aug 24, 2017 at 09:02:38PM +, t...@timakro.de wrote:
> The upstream signature is already included in the debian directory
You are confusing the signing key with the actual signature.

> what is further needed to add it to the source package?
From dpkg-source(1):
"each  original  tarball  can  be  accompanied  by  a  detached  upstream  
signature
(.orig.tar.ext.asc and .orig-component.tar.ext.asc)"

> The man page contains everything the README.md contains and more, should the
> README.md file be also shipped in that case?
In that case it's OK to not ship it.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#873146: RM: lush -- RoQA; dead upstream; RC buggy

[Sébastien Villemot]

Package: ftp.debian.org
Severity: normal
X-Debbugs-CC: y...@debian.org

Dear ftpmasters,

Please remove src:lush from the archive. Upstream is dead, the Debian package
is outdated and RC buggy, and trying to compile the latest upstream version
(2.0.1) leads to an unusable binary.

Also note that Yaroslav Halchenko, the maintainer of the package (in CC),
agrees with the removal.

Thanks,

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


signature.asc
Description: PGP signature

Bug#872944: www.debian.org: Debian Policy Manual not fully published

[Sean Whitton]

Hello Laura,

On Thu, Aug 24 2017, Laura Arjona Reina wrote:

> The CSS and images issue is solved now.

Thank you for this!

> If you publish a future version of Debian Policy including a
> customized theme, if that theme is in the _static folders, it will be
> shown too. If the theme is in another folder, ping us, because the
> function mvhtml_sphinx() in our
> https://anonscm.debian.org/cgit/debwww/cron.git/tree/parts/7doc script
> should be modified to include the new folder.

Okay.  I don't know enough about Sphinx themes to say in advance.

> * If we should copy those javascript files to "live" under
> www.debian.org/doc/policy-manual or in another place in the
> www.debian.org site (or in cgi.debian.org?). For now, policy-manual is
> the only manual using them, but maybe in the future, more manuals are
> moved to use sphinx too. I'm not aware of any other piece of the website
> using Javascript, so I have no references of a canonical place to copy
> the files (we would also need to change the symlinks to point to that
> place, but that's another topic).
>
> * If we should use the packages from "sid" as we use for the
> documentation packages, or stable, or backports...

If it's easy, we'd prefer you to use them from sid, because that's what
we develop the package against.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#868550: [pkg-gnupg-maint] Bug#868550: Bug#868550: reprepro seems to provide a repro

[Werner Koch]

On Thu, 24 Aug 2017 22:08, ijack...@chiark.greenend.org.uk said:

> I have a log generated by this
>   log-file /home/ian/things/Dgit/dgit/tests/tmp/gnupg/gnupg/AGENT.log
> in gpg-agent.conf but due to an infelicitly in my arrangments all of

Use 

  log-file socket:///home/ian/things/Dgit/dgit/tests/tmp/gnupg/gnupg/S.log

and run

  watchgnupg --force --time-only \
/home/ian/things/Dgit/dgit/tests/tmp/gnupg/gnupg/S.log >AGENT.log

in another tty to get combined output.


Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpwpHjm9CD6s.pgp
Description: PGP signature

Bug#873113: RFS: xssproxy/1.0.0-1 [ITP]

[tim]

Quoting Andrey Rahmatullin :


Control: tags -1 + moreinfo

Please switch to the debhelper compat level 10.
Please update to the current Standards-Version.
Please remove or uncomment Vcs-*
Please remove commented out sample lines from debian/rules.
Please add the upstream sig to the source package.
Please ship README.md.

--
WBR, wRAR


Thanks for your feedback. The upstream signature is already included  
in the debian directory, what is further needed to add it to the  
source package? The man page contains everything the README.md  
contains and more, should the README.md file be also shipped in that  
case?


Regards, Tim Schumacher


binvcbfCOC21s.bin
Description: PGP Public Key


pgpNoVXM_15ek.pgp
Description: PGP Digital Signature

Bug#810381: debian-policy: Update wording of 5.6.26 VCS-* fields to reflect the need for security

[Sean Whitton]

On Wed, Aug 23 2017, Russ Allbery wrote:

> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -962,6 +962,10 @@ repository where the Debian source package is developed.
>  
>  More than one different VCS may be specified for the same package.
>  
> +For both fields, any URLs given should use a scheme that provides
> +confidentiality (``https``, for example, rather than ``http`` or ``git``)
> +if the VCS repository supports it.
> +
>  .. _s-f-Package-List:
>  
>  ``Package-List``

Seconded, but I think the integrity protection is a more important
reason to avoid the git protocol or http, so if we can come up with a
further change to reflect that it would be better.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#866965: re: dosemu: DPMI unhandled exception instability back again

[eric . 17 . debian]

Hello,after migrating to stretch an old business program crashed, as this 
isessential here I tried various things which might be useful inanalyzing the 
DPMI behavior.some workarounds:current solution here: everything is running 
fine on stretch with thejessie dosemu package without any tweaks!dosemu2 also 
was able to run fine but there was no way back to dosemu1.4, I couldn't sort 
out why, so as I was short in time I reinstalledthe whole systemthe stetch 
dosemu package runs with$_dpmi = (0x)in dosemu.conf which is a strange 
settingon the 386 architecture does not come up with the stack overflow, 
itwas possible to run the software but I prefer amd64 on the machine, sothis 
was just a short test.the relevant part of the bootlog:=== 
ENTER CPU-EMU ===ERROR: PM stack overflowed: 
in_dpmi_pm_stack=452leavedos(enter_lpms|1283) called - shutting downleavedos() 
called from within a signal context!=== LEAVE CPU-EMU 
===hope this is related/eric

Bug#682347: mark 'editor' virtual package name as obsolete

[Jonathan Nieder]

Hi,

Russ Allbery wrote:

> +++ b/policy/ch-customized-programs.rst
> @@ -93,19 +93,21 @@ page.
[...]
> -It is not required for a package to depend on ``editor`` and ``pager``,
> -nor is it required for a package to provide such virtual
> -packages. [#]_
> +Packages may assume that ``/usr/bin/editor`` and ``/usr/bin/pager`` are
> +available as fallbacks without adding an explicit package dependency, and
> +may fail if they are not present.  There are no ``editor`` or ``pager``
> +virtual packages.

One change this patch makes is to talk about /usr/bin/editor and
/usr/bin/pager files instead of editor and pager files.  Is that
intentional?

E.g. git uses "editor" as its default editor, not /usr/bin/editor.

[...]
> @@ -572,10 +574,6 @@ installed in ``/usr/share/man/man6``.
> portion is handled internally by the package system based on the os
> and cpu.
>  
> -.. [#]
> -   The Debian base system already provides an editor and a pager
> -   program.
> -

What should packages do if an editor is configured and the "editor"
command is not available?

That's an existing issue but I had never thought about it before.  It
would be nice if policy could say something about it.

Thanks,
Jonathan

Bug#873115: Acknowledgement (concurrent apache2 -k graceful hang)

[Joey Hess]

Seems similar to #779077. mod_fcgid is not enabled on our server.
Regular cgi scripts are in use and one is quite likely running when
apache is reloaded. Using mpm_worker.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#872996: RFS: node-unicode-tr51/9.0.0-1 ITP

[Julien Puydt]

control: tags -1 - moreinfo

Hi,

Le 23/08/2017 à 22:05, roucaries bastien a écrit :
> * debian/control:
>+ section is javascript

Done.

>+ you should use package.json version in source depends

I use the currently available mocha in Debian, as it looks like it's
enough ; apart from this remark : done.

>+ Description is too short. Define emoji for instance. What contain
> emoji data ?

Done, hopefully to your satisfaction.

>  * copyright:
>  please mention in general comment what I have just opened #873028
> for adding emoji to unicode-data
Done.

>  * rules
>   They are no guarantee that .js file are overwritten by script
> and even in this case your package does not build cleanly. Better is
> to create a debian/build directory (rm -rf during clean) that will get
> a symlink of script and data. Than run script on it.

Done.

>  * debian/test/mocha: please you a copy on my runtestsuite script. It
> will use installed version instead of source

Done, but you might still want to check what I did with it :-/

> * debian/watch is 4

Done.

Snark on #debian-js

Bug#873145: mercurial-git: hg-git needs to be updated to 0.8.9 to work with mercurial 4.3

[derfel]

Package: mercurial-git
Version: 0.8.5-4
Severity: grave
Justification: renders package unusable

Tags: fixed-upstream, sid

With the new mercurial 4.3 in sid mercurial-git cannot work anymore. A sample
error is:

$ hg status
abort: No module named osutil!

$ hg log
** Unknown exception encountered with possibly-broken third-party extension
hggit
** which supports versions 3.7 of Mercurial.
** Please disable hggit and try your action again.
** If that fixes the bug please report it to https://bitbucket.org/durin42/hg-
git/issues
** Python 2.7.13+ (default, Jul 19 2017, 18:15:03) [GCC 6.4.0 20170704]
** Mercurial Distributed SCM (version 4.3.1)
** Extensions loaded: hggit
Traceback (most recent call last):
  File "/usr/bin/hg", line 45, in 
mercurial.dispatch.run()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 81, in
run
status = (dispatch(req) or 0) & 255
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 162, in
dispatch
ret = _runcatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 302, in
_runcatch
return _callcatch(ui, _runcatchfunc)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 310, in
_callcatch
return scmutil.callcatch(ui, func)
  File "/usr/lib/python2.7/dist-packages/mercurial/scmutil.py", line 150, in
callcatch
return func()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 292, in
_runcatchfunc
return _dispatch(req)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 896, in
_dispatch
cmdpats, cmdoptions)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 658, in
runcommand
ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 904, in
_runcommand
return cmdfunc()
  File "/usr/lib/python2.7/dist-packages/mercurial/dispatch.py", line 893, in

d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 1079, in
check
return func(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/mercurial/commands.py", line 3379, in
log
displayer.show(ctx, copies=copies, matchfn=revmatchfn)
  File "/usr/lib/python2.7/dist-packages/mercurial/cmdutil.py", line 1510, in
show
self._show(ctx, copies, matchfn, props)
  File "/usr/lib/python2.7/dist-packages/mercurial/cmdutil.py", line 1553, in
_show
for name in ns.names(self.repo, changenode):
  File "/usr/lib/python2.7/dist-packages/mercurial/namespaces.py", line 195, in
names
return sorted(self.nodemap(repo, node))
  File "/usr/lib/python2.7/dist-packages/mercurial/namespaces.py", line 44, in

tagnodemap = lambda repo, node: repo.nodetags(node)
  File "/usr/lib/python2.7/dist-packages/mercurial/localrepo.py", line 895, in
nodetags
if not self._tagscache.nodetagscache:
  File "/usr/lib/python2.7/dist-packages/mercurial/repoview.py", line 239, in
__getattr__
return getattr(self._unfilteredrepo, attr)
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 823, in
__get__
result = self.func(obj)
  File "/usr/lib/python2.7/dist-packages/mercurial/localrepo.py", line 817, in
_tagscache
cache.tags, cache.tagtypes = self._findtags()
  File "/usr/local/lib/python2.7/dist-
packages/hg_git-0.8.5-py2.7.egg/hggit/hgrepo.py", line 47, in _findtags
for tag, rev in self.githandler.tags.iteritems():
  File "/usr/lib/python2.7/dist-packages/mercurial/util.py", line 823, in
__get__
result = self.func(obj)
  File "/usr/local/lib/python2.7/dist-
packages/hg_git-0.8.5-py2.7.egg/hggit/hgrepo.py", line 66, in githandler
return GitHandler(self, self.ui)
  File "/usr/local/lib/python2.7/dist-
packages/hg_git-0.8.5-py2.7.egg/hggit/git_handler.py", line 110, in __init__
self.gitdir = self.repo.join('git')
AttributeError: 'hgrepo' object has no attribute 'join'

hg log don't work anymore even if the upstream repository is mercurial and not
git. So, basically, you cannot use mercurial anymore if not disabling the
extension in hgrc or updating to the latest version which is already fixed.



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

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

Versions of packages mercurial-git depends on:
ii  mercurial   4.3.1-2
ii  python  2.7.13-2
ii  python-dulwich  0.18.2-1

mercurial-git recommends no packages.

mercurial-git suggests no packages.

Bug#873122: HTTP Link to Keyring

[Phil]

Note that this will also need to be applied for all the translated
pages as well. Please let me know if there's anything I can do to speed
the process up.

Bug#873122: HTTP Link to Keyring

[Phil]

Package: www.debian.org
Severity: normal
Tags: patch

I'm attaching the original wml file + patches to change http to https.

I wanted to rename them version 1.5 /1.6 etc but didn't want to put an
extra dot. Do let me know what's good practice as this is just my
second patch submitted.

On Thu, 24 Aug 2017 21:28:00 +0100 Phil  wrote:
> Hi Hanno,
> 
> Thank you very much for bringing this to our attention.
> 
> I'll submit a patch shortly for approval to get this amended.
> 
> Please do let us know if you spot anything else!
> 
> Phil
> 
> On Thu, 24 Aug 2017 19:53:59 +0200 Hanno =?UTF-8?B?QsO2Y2s=?=  oeck.de> wrote:
> > Package: www.debian.org
> > 
> > When downloading a Debian CD there's a webpage explaining how to
> verify
> > signatures:
> > https://www.debian.org/CD/verify
> > 
> > This recommends to check the signatures with the keys from the
Debian
> > GPG keyring. However that link is HTTP, pointing to:
> > http://keyring.debian.org/
> > 
> > It will immediately redirect to HTTPS, but an attacker could
> intercept
> > that redirection and present a user with a malicious keyring
instead.
> > 
> > This makes the verification kinda pointless, as the keyring is
> > delivered over a potentially insecure channel. The lack of HSTS on
> > debian.org makes this particularly worriesome. Please change that
> link
> > to HTTPS.
> > 
> > 
> -- 
> Phil
> 
> 
-- 
Phil#use wml::debian::cdimage title="Verifying authenticity of Debian CDs" BARETITLE=true


Official releases of Debian CDs come with signed checksum files;
look for them alongside the images in the iso-cd,
jigdo-dvd, iso-hybrid etc. directories.
These allow you to check that the images you download are correct.
First of all, the checksum can be used to check that the CDs have not
been corrupted during download.
Secondly, the signatures on the checksum files allow you to confirm
that the files are the ones officially released by the Debian CD /
Debian Live team and have not been tampered with.



To validate the contents of a CD image, just be sure to use the
appropriate checksum tool.
Cryptographically strong checksum
algorithms (SHA256 and SHA512) are available for every releases; you should use the tools
sha256sum or sha512sum to work with these.



To ensure that the checksums files themselves are correct, use GnuPG to
verify them against the accompanying signature files (e.g.
SHA512SUMS.sign).
The keys used for these signatures are all in the https://keyring.debian.org;>Debian GPG keyring and the best
way to check them is to use that keyring to validate via the web of
trust.
To make life easier for users, here are the fingerprints for the keys
that have been used for releases in recent years:


#include "$(ENGLISHDIR)/CD/CD-keys.data"
--- verify_v15.wml	2017-08-24 21:29:56.068732095 +0100
+++ verify_v16.wml	2017-08-24 21:31:26.540391738 +0100
@@ -25,7 +25,7 @@
 verify them against the accompanying signature files (e.g.
 SHA512SUMS.sign).
 The keys used for these signatures are all in the http://keyring.debian.org;>Debian GPG keyring and the best
+href="https://keyring.debian.org;>Debian GPG keyring and the best
 way to check them is to use that keyring to validate via the web of
 trust.
 To make life easier for users, here are the fingerprints for the keys
#use wml::debian::cdimage title="Verifying authenticity of Debian CDs" BARETITLE=true


Official releases of Debian CDs come with signed checksum files;
look for them alongside the images in the iso-cd,
jigdo-dvd, iso-hybrid etc. directories.
These allow you to check that the images you download are correct.
First of all, the checksum can be used to check that the CDs have not
been corrupted during download.
Secondly, the signatures on the checksum files allow you to confirm
that the files are the ones officially released by the Debian CD /
Debian Live team and have not been tampered with.



To validate the contents of a CD image, just be sure to use the
appropriate checksum tool.
Cryptographically strong checksum
algorithms (SHA256 and SHA512) are available for every releases; you should use the tools
sha256sum or sha512sum to work with these.



To ensure that the checksums files themselves are correct, use GnuPG to
verify them against the accompanying signature files (e.g.
SHA512SUMS.sign).
The keys used for these signatures are all in the http://keyring.debian.org;>Debian GPG keyring and the best
way to check them is to use that keyring to validate via the web of
trust.
To make life easier for users, here are the fingerprints for the keys
that have been used for releases in recent years:


#include "$(ENGLISHDIR)/CD/CD-keys.data"

Bug#873122: HTTP Link to Keyring

[Phil]

Hi Hanno,

Thank you very much for bringing this to our attention.

I'll submit a patch shortly for approval to get this amended.

Please do let us know if you spot anything else!

Phil

On Thu, 24 Aug 2017 19:53:59 +0200 Hanno =?UTF-8?B?QsO2Y2s=?=  wrote:
> Package: www.debian.org
> 
> When downloading a Debian CD there's a webpage explaining how to
verify
> signatures:
> https://www.debian.org/CD/verify
> 
> This recommends to check the signatures with the keys from the Debian
> GPG keyring. However that link is HTTP, pointing to:
> http://keyring.debian.org/
> 
> It will immediately redirect to HTTPS, but an attacker could
intercept
> that redirection and present a user with a malicious keyring instead.
> 
> This makes the verification kinda pointless, as the keyring is
> delivered over a potentially insecure channel. The lack of HSTS on
> debian.org makes this particularly worriesome. Please change that
link
> to HTTPS.
> 
> 
-- 
Phil

Bug#873001: [debian-policy] get-orig-source documentation should include a pointer to devref and a minimal example

[gregor herrmann]

On Thu, 24 Aug 2017 22:10:15 +0200, Bill Allombert wrote:

> How do you plan to instruct uscan how repacking should be done ?

Adding files to be removed to Files-Excluded in d/copyright covers
about (rough guess) 95% of the cases, without any further changes
needed.
And for the remaining cases, uscan honours a parameter in
d/watch to call a repacking script.

What I've seen about get-orig-source targets are very rare esoteric
cases. And I guess using the target is not forbidden, as well as
converting the makefiles runes from d/rules to a shell script called
by uscan+d/watch should just do the same.


Cheers,
gregor

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


signature.asc
Description: Digital Signature

Bug#873144: glexmx FTCBFS: unsatisfiable Build-Depends, uses the build architecture toolchain

[Helmut Grohne]

Source: glewmx
Version: 1.13.0-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

glewmx fails to cross build from source for a number of reasons:

 * Build-Depends: binutils is unsatisfiable, because it conflicts with
   the build architecture binutils requested by build-essential. The
   dependency can be dropped as the version constraint is satisfied in
   wheezy.
 * It uses the build architecture toolchain. Let dh_auto_build pass
   cross compilers.
 * It still uses the build architecture compiler via the LD variable and
   it misdetects the host features as the SYSTEM variable is discovered
   for the build architecture.

After fixing all of the above, glewmx cross builds successfully. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru glewmx-1.13.0/debian/changelog 
glewmx-1.13.0/debian/changelog
--- glewmx-1.13.0/debian/changelog  2016-09-16 07:34:13.0 +0200
+++ glewmx-1.13.0/debian/changelog  2017-08-24 22:15:39.0 +0200
@@ -1,3 +1,13 @@
+glewmx (1.13.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Drop binutils build dependency satisfied in wheezy.
++ Let dh_auto_build pass cross compilers to make.
++ Pass the correct LD and SYSTEM to make.
+
+ -- Helmut Grohne   Thu, 24 Aug 2017 22:15:39 +0200
+
 glewmx (1.13.0-3) unstable; urgency=medium
 
   * New maintainer
diff --minimal -Nru glewmx-1.13.0/debian/control glewmx-1.13.0/debian/control
--- glewmx-1.13.0/debian/control2016-09-16 07:34:13.0 +0200
+++ glewmx-1.13.0/debian/control2017-08-24 22:15:37.0 +0200
@@ -2,8 +2,7 @@
 Priority: optional
 Section: libs
 Maintainer: Paul Wise 
-Build-Depends: binutils (>> 2.18),
-   debhelper (>= 9),
+Build-Depends: debhelper (>= 9),
docbook-to-man,
libgl1-mesa-dev | libgl-dev,
libglu1-mesa-dev | libglu-dev,
diff --minimal -Nru glewmx-1.13.0/debian/rules glewmx-1.13.0/debian/rules
--- glewmx-1.13.0/debian/rules  2016-09-16 07:34:13.0 +0200
+++ glewmx-1.13.0/debian/rules  2017-08-24 22:15:39.0 +0200
@@ -18,7 +18,7 @@
INSTALL_PROGRAM += -s
 endif
 
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
 
 configure: configure-stamp
 configure-stamp:
@@ -32,7 +32,7 @@
dh_testdir
dh_testroot
dh_prep
-   $(MAKE) glew.lib.mx STRIP= POPT="-g $(POPT)" WARN=-Wall GL_LDFLAGS=-lGL 
GLU_LDFLAGS=-lGLU GLUT_LDFLAGS=-lglut LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH)
+   dh_auto_build -- glew.lib.mx STRIP= POPT="-g $(POPT)" WARN=-Wall 
GL_LDFLAGS=-lGL GLU_LDFLAGS=-lGLU GLUT_LDFLAGS=-lglut 
LIBDIR=/usr/lib/$(DEB_HOST_MULTIARCH) 'LD=$$(CC)' SYSTEM=$(firstword $(subst -, 
,$(DEB_HOST_GNU_SYSTEM)))
touch build-stamp
dh_installdirs
$(MAKE) install.mx GLEW_DEST=$(CURDIR)/debian/tmp/usr 
LIBDIR=$(CURDIR)/debian/tmp/usr/lib/$(DEB_HOST_MULTIARCH)

Bug#873124: [Pkg-telepathy-maintainers] Bug#873124: telepathy-gabble: Unable to add jabber/XMPP account

[Diane Trout]

Are you using kde-telepathy or empathy?

These instructions should work.

https://squaremotion.blogspot.com/2011/11/xmpp-support-for-n9.html

You might also try configuring the account via ktp or empathy instead
of online accounts. some of the configuration files specifying what
services are available appear to be wrong


On Thu, 2017-08-24 at 21:09 +0300, kpp wrote:
> Package: telepathy-gabble
> Version: 0.18.3-3
> Severity: important
> 
> Dear Maintainer,
> 
> * What led up to the situation?
> Attempt to add xmpp account to KDE 5 telepathy
> 
> * What exactly did you do (or not do) that was effective (or
>   ineffective)?
> Launch system settings of KDE5, choose Personalization, Online
> Accounts, 
> Create
> 
> * What was the outcome of this action?
> I can see only Google and Twitter (see attachment)
> 
> * What outcome did you expect instead?
> Button to add Jabber/XMPP account
> 
> 
> -- System Information:
> Debian Release: 9.1
>    APT prefers stable
>    APT policy: (500, 'stable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages telepathy-gabble depends on:
> ii  libc6   2.24-11+deb9u1
> ii  libdbus-1-3 1.10.18-1
> ii  libdbus-glib-1-20.108-2
> ii  libglib2.0-02.50.3-2
> ii  libgnutls30 3.5.8-5+deb9u2
> ii  libnice10   0.1.13-2
> ii  libsoup2.4-12.56.0-2
> ii  libsqlite3-03.16.2-5
> ii  libtelepathy-glib0  0.24.1-1.1
> ii  libxml2 2.9.4+dfsg1-2.2
> 
> telepathy-gabble recommends no packages.
> 
> telepathy-gabble suggests no packages.
> 
> -- no debconf information
> 
> ___
> Pkg-telepathy-maintainers mailing list
> pkg-telepathy-maintain...@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-telepathy
> -maintainers

Bug#873001: [debian-policy] get-orig-source documentation should include a pointer to devref and a minimal example

[Bill Allombert]

On Wed, Aug 23, 2017 at 02:37:25PM -0700, Russ Allbery wrote:
> roucaries bastien  writes:
> 
> > you call the rules with something (using shebang or directly) make -f
> > somepath/package/debian/rules, uscan need to be excuted on
> > somepath/package/.
> 
> Oh, I see the edge case this is trying to handle.
> 
> I'll be honest: I'm personally more inclined to just drop get-orig-source
> entirely than to try to handle special cases like this.  I feel like the
> target has outlived its usefulness and it would be better to just enhance
> uscan to support repacking scripts.  (And people can still keep the target
> if they want; I'm not saying people need to remove it.  I just question
> whether it's useful for Policy to bless it and try to standardize it,
> since I'm dubious it's an important part of the workflow to try to
> standardize.)

How do you plan to instruct uscan how repacking should be done ?
To me, having a debian/rules target seems the correct think to do.
(That is what I do with my packages with comple repacking.)
That said, maybe the shell magic that could be moved inside uscan.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#873142: virtualbox-dkms: Installation hangs running depmod...

[Ivan Kohler]

Package: virtualbox-dkms
Version: 5.1.24-dfsg-2
Severity: critical
Justification: breaks the whole system

Installation hangs running "depmod..." and printing a period every few seconds.

ps shows the command being run is:
  depmod -a 4.11.0-1-amd64 -F /boot/System.map-4.11.0-1-amd64

It has been running for over 25 minutes now, but does not appear to be using
any CPU or resources.

Ctrl-C does not stop the installation process.  Sending a kill signal to the
depmod process does not have any effect.

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

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

Versions of packages virtualbox-dkms depends on:
ii  dkms  2.3-3

Versions of packages virtualbox-dkms recommends:
ii  virtualbox  5.1.24-dfsg-2

virtualbox-dkms suggests no packages.

-- no debconf information

Bug#873141: google-perftools FTCBFS: binutils build dependency unsatisfiable

[Helmut Grohne]

Source: google-perftools
Version: 2.5-2.2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

google-perftools fails to cross build from source, because its build
dependency on binutils is unsatisfiable. build-essential already depends
on the build architecture binutils and thus conflicts with the host
architecture one requested via Build-Depends as binutils is not
Multi-Arch: same. Simply dropping the redundant dependency makes
google-perftools cross build successfully. Please consider applying the
attached patch.

Helmut
diff -u google-perftools-2.5/debian/changelog 
google-perftools-2.5/debian/changelog
--- google-perftools-2.5/debian/changelog
+++ google-perftools-2.5/debian/changelog
@@ -1,3 +1,10 @@
+google-perftools (2.5-2.3) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop implicitly satisfied binutils from Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Thu, 24 Aug 2017 22:03:39 +0200
+
 google-perftools (2.5-2.2) unstable; urgency=medium
 
   * Non-maintainer upload
diff -u google-perftools-2.5/debian/control google-perftools-2.5/debian/control
--- google-perftools-2.5/debian/control
+++ google-perftools-2.5/debian/control
@@ -2,7 +2,7 @@
 Section: libs
 Priority: optional
 Maintainer: Daigo Moriwaki 
-Build-Depends: cdbs, autoconf, automake, libtool, patchutils, debhelper (>= 
10.2.1), binutils, libunwind8-dev [amd64]
+Build-Depends: cdbs, autoconf, automake, libtool, patchutils, debhelper (>= 
10.2.1), libunwind8-dev [amd64]
 Build-Conflicts: autoconf2.13, automake1.4
 Standards-Version: 3.9.8
 Homepage: https://github.com/gperftools/gperftools

Bug#872828: RFS: node-regjsgen/0.3.0-1 ITP

[Julien Puydt]

Hi,

Le 24/08/2017 à 21:07, Bastien ROUCARIES a écrit :
> example.js should not be installed with dh_installdoc but with
> dh_installexample thus supply a file debian/examples with
> debian/example.js.
> 
> This is the last remark

Done. I didn't know about the example vs documentation nuance.

Snark on #debian-js

Bug#872859: kate: fails to build against libgit2 0.26.0

[Ximin Luo]

Control: notfound -1 4:16.08.2-1
Control: close -1

Hi,

Actually the package does build fine, you just need to rebuild ktexteditor 
against libgit2 0.26 first, then use this rebuilt version when building kate.

Sorry I missed this earlier, closing the bug now.

Ximin

On Mon, 21 Aug 2017 22:42:08 +0200 Russell Sim  wrote:
> Package: kate
> Version: 4:16.08.2-1
> Severity: normal
> 
> Dear Maintainer,
> 
> Currently Kate fails to build against libgit2 0.26.0 which has just been
> uploaded to experimental. Please consider updating Kates dependencies to see 
> if
> it will sucessfuly build against this newer version.
> 
> From what I can see, support for libgit2 has been removed from Kates master
> branch because it was deemed to be too unstable, so you may be able to 
> backport
> that patch if it's too troublesome getting it to build against 0.26.0.
> 
> Thanks,
> Russell
> 
> 
> 
> -- System Information:
> Debian Release: 9.0
>   APT prefers unstable
>   APT policy: (990, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages kate depends on:
> ii  kate5-data   4:16.08.3-1
> ii  ktexteditor-katepart 5.27.0-1
> ii  libc62.24-11
> ii  libgit2-24   0.25.1+really0.24.6-1
> ii  libkf5activities55.27.0-1
> ii  libkf5bookmarks5 5.27.0-1
> ii  libkf5completion55.27.0-1
> ii  libkf5configcore55.27.0-1
> ii  libkf5configgui5 5.27.0-1
> ii  libkf5configwidgets5 5.27.0-1
> ii  libkf5coreaddons55.27.0-1
> ii  libkf5crash5 5.27.0-1
> ii  libkf5dbusaddons55.27.0-1
> ii  libkf5guiaddons5 5.27.0-1
 > ii  libkf5i18n5  5.27.0-2
> ii  libkf5iconthemes55.27.0-1
> ii  libkf5itemmodels55.27.0-1
> ii  libkf5jobwidgets55.27.0-1
> ii  libkf5kiocore5   5.27.0-2
> ii  libkf5kiofilewidgets55.27.0-2
> ii  libkf5kiowidgets55.27.0-2
> ii  libkf5newstuff5  5.28.0-1
> ii  libkf5parts5 5.28.0-1
> ii  libkf5plasma55.28.0-2
> ii  libkf5service-bin5.27.0-1
> ii  libkf5service5   5.27.0-1
> ii  libkf5texteditor55.28.0-2
> ii  libkf5textwidgets5   5.27.0-1

-- 
GPG: ed25519/56034877E1F87C35
GPG: rsa4096/1318EFAC5FBBDBCE
https://github.com/infinity0/pubkeys.git

Bug#873143: python-pygit2: New upstream version 0.26.0

[Ximin Luo]

Package: python-pygit2
Version: 0.24.2-3
Severity: important
Control: block 873139 by -1

Dear Maintainer,

libgit2 0.26 is now available in Debian experimental. I will soon be uploading
it to Debian unstable (once the Release Team) grants me a transition slot [1],
after which this bug will be raised to severity serious.

python-pygit2 0.26.0 is available in the upstream git, please package this and
upload it to unstable once libgit2 0.26 is available there. In the meantime,
you can test builds against the version in experimental and/or upload there.

Thanks,
Ximin

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

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

Bug#868550: [pkg-gnupg-maint] Bug#868550: reprepro seems to provide a repro

[Ian Jackson]

Hi.  Thanks for your help with debugging this.

NIIBE Yutaka writes ("Re: [pkg-gnupg-maint] Bug#868550: reprepro seems to 
provide a repro"):
> Ian Jackson  wrote:
> > This might be relevant.  My test suite failures occur on a loaded
> > machine, because the test case runner parallelises separate tests.
> >
> > Does this produce a particular message, when it occurs ?
> 
> Yes.
...}
> +  if (i >= SECS_TO_WAIT_FOR_AGENT)
> +log_error ("agent invoked successfully, but...\n");

I tried this.  I applied this change and I can confirm that I have
seen this message in all the failing tests I looked at.

However, I also tried with the patch below, to increase the timeout.

With that patch, I can still reproduce the failure.  The passing tests
succeed and exit, leaving a failing test (so far, only one out of a
test run) sitting about.  The machine load is low.  There is no
gpg-agent running.  So the problem I am seeing is not simply that the
agent process is starved (although I don't doubt that the race you
describe exists).

The message, with this patch and yours, is still the same.  Here is an
example:

+ fakeroot apt-key add
W: Unable to read 
/home/ian/things/Dgit/dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
W: Unable to read 
/home/ian/things/Dgit/dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
Warning: apt-key output should not be parsed (stdout is not a terminal)
W: Unable to read 
/home/ian/things/Dgit/dgit/tests/tmp/downstream-gitless/ds-etc-apt/apt.conf.d/ 
- DirectoryExists (2: No such file or directory)
gpg: agent invoked successfully, but...
gpg: can't connect to the agent: IPC connect call failed
+ test 2 = 0

Each individual test runs with its own GNUPGHOME and is largely
singlethreaded so I think there are probably not multpile competing
agents starting up.  Is it possible that the agent started up and then
exited for some reason ?

I have a log generated by this
  log-file /home/ian/things/Dgit/dgit/tests/tmp/gnupg/gnupg/AGENT.log
in gpg-agent.conf but due to an infelicitly in my arrangments all of
the logs for concurrent tests share a logfile.  The log seems to
contain many fewer messages than expected leading me to suspect it is
not opened with O_APPEND.  I may see about sorting out a separate
logfile from each run which should tell me whether gpg-agent started
or not.

I hope some of this is of some use...

Thanks,
Ian.

commit 335bc79cc1ebeba1eb529c8e6b574d8ca1d9d947
Author: Ian Jackson 
Date:   Tue Aug 22 19:17:05 2017 +0100

increase timeouts

diff --git a/common/asshelp.c b/common/asshelp.c
index 2cab310..4a9fb45 100644
--- a/common/asshelp.c
+++ b/common/asshelp.c
@@ -58,8 +58,8 @@
 # define SECS_TO_WAIT_FOR_AGENT 30
 # define SECS_TO_WAIT_FOR_DIRMNGR 30
 #else
-# define SECS_TO_WAIT_FOR_AGENT 5
-# define SECS_TO_WAIT_FOR_DIRMNGR 5
+# define SECS_TO_WAIT_FOR_AGENT 500
+# define SECS_TO_WAIT_FOR_DIRMNGR 500
 #endif
 
 /* A bitfield that specifies the assuan categories to log.  This is

Bug#873140: snapd, insane built-using field when built on derivatives.

[peter green]

Package: snapd
Severity: important

A tool we use in raspbian to check that packages listed in built-using are 
actually available recently popped up the following.

failed to find 
s/sbuild-build-depends-core-dummy/sbuild-build-depends-core-dummy_0.invalid.0.dsc
 needed by package snapd
failed to find 
s/sbuild-build-depends-snapd-dummy/sbuild-build-depends-snapd-dummy_0.invalid.0.dsc
 needed by package snapd

I traced this back to the following code in debian/rules

# Currently, we enable confinement for Ubuntu only, not for derivatives,
# because derivatives may have different kernels that don't support all the
# required confinement features and we don't to mislead anyone about the
# security of the system.  Discuss a proper approach to this for downstreams
# if and when they approach us
ifeq ($(shell dpkg-vendor --query Vendor),Ubuntu)
# On Ubuntu 16.04 we need to produce a build that can be used on wide
# variety of systems. As such we prefer static linking over dynamic linking
# for stability, predicability and easy of deployment. We need to link some
# things dynamically though: udev has no stable IPC protocol between
# libudev and udevd so we need to link with it dynamically.
VENDOR_ARGS=--enable-nvidia-ubuntu --enable-static-libcap 
--enable-static-libapparmor --enable-static-libseccomp
BUILT_USING_PACKAGES=libcap-dev libapparmor-dev libseccomp-dev
else
ifeq ($(shell dpkg-vendor --query Vendor),Debian)
VENDOR_ARGS=--disable-apparmor --disable-seccomp --enable-static-libcap
BUILT_USING_PACKAGES=libcap-dev
else
VENDOR_ARGS=--disable-apparmor
endif
endif
BUILT_USING=$(shell dpkg-query -f '$${source:Package} (= $${source:Version}), ' 
-W $(BUILT_USING_PACKAGES))


There are a couple of issues I see with this code.

1. In general the principle of least surprise says that derivatives should be 
treated the same as their parent distros unless they have requested otherwise. 
A justification is given for treating deriviatives of Ubuntu differently from 
Ubuntu but no justification is given for treating derivatives of Debian 
differently from Debian.
2. If BUILT_USING_PACKAGES is empty as it currently is on everything other than 
Debian and Ubuntu then BUILT_USING includes entries for every package on the 
system. Including things like dummy packages built by sbuild.

I would also note that many deriviatives don't rebuild everything, so just 
because you only build with certain options on Ubuntu and not it's derivatives 
doesn't mean that the packages built with those options will only be used on 
Ubuntu and not it's derivatives.

Bug#873046: linux-image-4.12.0-1-amd64: changelog.Debian.gz should only have changes made by the Debian kernel team and changelog.gz should have the upstream changes.

[Salvatore Bonaccorso]

Hi

On Thu, Aug 24, 2017 at 07:37:39AM +0530, shirish शिरीष wrote:
> Package: src:linux
> Version: 4.12.6-1
> Severity: normal
> 
> Dear Maintainer,
> 
> AFAIK there is/was either a policy or a common practise for all
> packages to have changelog.Debian.gz giving only changes/patches made
> by Debian for the distribution and all upstream changes made by
> kernel.org in its own changelog.gz . While I'm sure that the
> debian-kernel team would probably have done this with some reason that
> is somehow not apparent or unknown here.
> 
> I did look at 
> https://bugs.debian.org/cgi-bin/pkgreport.cgi?repeatmerged=no=linux
> to see if I could find any bug-report about changelogs but apparently
> haven't found anything.
> 
> If there has been some discussion which explains the reason why it was
> done (and if memory serves right, we used to have changelog.gz and
> Debian.changelog.gz both)
> a link to the same would be helpful.
> 
> Looking forward to know more.
> 
> ┌─[shirish@debian] - [/usr/share/doc/linux-image-4.12.0-1-amd64] - [10256]
> └─[$] ls
> 
> changelog.Debian.gz  copyright

Upstream does not provide a changelog in the orig source. For the
mentioning of the upstream changes, cf. debian/README.source:

[...]
Recording updates in the changelog
--
[...]
* For an upstream release candidate, don't attempt to list the changes

* For a stable release by Linus, refer to the summary at
  kernelnewbies.org, e.g. https://kernelnewbies.org/Linux_4.5

* For a stable update, refer to the changelog on kernel.org, e.g.
  https://www.kernel.org/pub/linux/kernel/v4.x/ChangeLog-4.5.1, and
  list all changes that are relevant to our package and that fix bugs
  that we would consider 'important' or higher severity

  - The script debian/bin/stable-update updates the changelog
version and inserts the list of changes.  It doesn't attempt to
filter out irrelevant or unimportant changes.

  - The script debian/bin/ckt-stable-update.sh does the same for
stable updates by the Canonical Kernel Team.

  - If you have time, please delete irrelevant changes such as:
+ Fixes for architectures not supported by the package
+ Fixes for drivers that aren't enabled in any of our configurations
+ Build fixes for configurations that we don't use
+ Fixes for lockdep false positives
[...]

Hope this helps,

Regards,
Salvatore

Bug#873139: transition: libgit2

[Ximin Luo]

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

Dear release team,

libgit2 0.26 is in experimental and ready to start the transition from 0.24 in 
unstable.

I've rebuilt the relevant reverse-build-dependencies from unstable. The
following succeed and can be binNMU'd directly:

geany-plugins kup-backup ktexteditor gall: immediately
kate: after ktexteditor

The following fail, but succeed after trivial changes such as removing
too-strict version constraints:

gnuastro: remove a hard Build-Dep on libgit2-24

The following fail, but probably just need to be bumped to the latest upstream
version:

libgit2-glib-1.0-0 python-pygit2 ruby-rugged: bindings to libgit2
gnome-builder: depends on libgit2-glib-1.0-0

The following fail, and probably need more invasive changes such as upgrading 
to the new API.

fritzing: has no reverse-dependencies in Debian

I will file bugs to the failing packages right after this one, and link them 
here.

Thanks,
Ximin

Ben file:

title = "libgit2";
is_affected = .depends ~ "libgit2-24" | .depends ~ "libgit2-26";
is_good = .depends ~ "libgit2-26";
is_bad = .depends ~ "libgit2-24";


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

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

Bug#873113: RFS: xssproxy/1.0.0-1 [ITP]

[Andrey Rahmatullin]

Control: tags -1 + moreinfo

Please switch to the debhelper compat level 10.
Please update to the current Standards-Version.
Please remove or uncomment Vcs-*
Please remove commented out sample lines from debian/rules.
Please add the upstream sig to the source package.
Please ship README.md.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Bug#873138: Installed-Build-Depends lack architecture qualification

[Helmut Grohne]

Package: dpkg-dev
Version: 1.18.24
File: /usr/bin/dpkg-genbuildinfo
User: helm...@debian.org
Usertags: rebootstrap

Hi Guillem,

while looking into a .buildinfo file, I noticed that
Installed-Build-Depends are useless beyond #871494: They lack
architecture qualification. Thus there is no way to figure out for which
architecture to install which package. The installation set cannot be
reproduced.

I believe that a good solution here would be to simply arch qualify
every package and then drop all :$DEB_BUILD_ARCH qualifications. For
native builds there won't be a difference. For cross builds, the field
becomes useful. I am proposing DEB_BUILD_ARCH rather than DEB_HOST_ARCH
here, because essential will always be installed for the build
architecture and thus poses significant chunk of packages.

Helmut

Bug#869926: RFS: oprofile/1.2.0-1 [ITP]

[Roberto Oliveira]

Hi Andrey,

I think I did all the changes you suggested, can you take a look on it
again, please?


> Control: tags -1 + moreinfo
>
> I still see a lot of old junk in debian/control:
> - did you write that Build-Depends? if no, please write them from scratch,
>   making sure they are complete and necessary.
I Checked all the dependencies and now just the required dependencies are
in control file.

> - why Conflicts: oprofile-modules*? There are no such packages in last
>   releases.
Fixed.

> - Replaces: oprofile-common? Suggests: oprofile-gui? Replaces: oprofile
>   (<< 0.9.6-1ubuntu1)? The same.
Fixed.

> - oprofile gets a Depends: binutils via libbfd-2.29-system.so, it
>   shouldn't also Recommend it.
Fixed.

> You don't need .shlibs when you use .symbols.
Fixed.

> Why does the oprofile user need /bin/bash as a shell?
It doesn't need it, fixed.

> Why do you need the debconf snippet in postrm?
Actually don't need this step in purge as it doesn't store any configuration and
it doesn't use the debconf. As postrm was just doing that, I removed it.

> What is /usr/doc/oprofile which is removed in prerm?
It seems a deprecated file and oprofile doesn't install it. As prerm was just
doing that, I removed it.

> Please don't mix debhelper files with and without package prefixes (this
> is about maintainer script files).
> Instead of editing .la you should delete it.
Fixed.

> Instead of manually installing to debian/oprofile and manually moving to
> other package dirs you should use dh_install to move from debian/tmp to
> package dirs.
Fixed.

> Please upgrade to the current Standards-Version.
Fixed.

> Please switch to the debhelper compat level 10.
Fixed.

> Is libjvmti_oprofile intended to be a public shared library? It looks like
> a plugin.
Yes, it is a plugin, I moved it to the correct location.


> --
> WBR, wRAR

Bug#873137: python-asn1crypto: Please enable tests for asn1crypto once they are provided in released tarballs

[Corey Bryant]

Package: python-asn1crypto
Version: 0.22.0-1
Severity: normal

Dear Maintainer,

I know you want to enable tests for this package.

This is just a note that the following bug is tracking inclusion of the
upstream tests in the released tarballs.

https://github.com/wbond/asn1crypto/issues/59

Thanks,
Corey


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

Kernel: Linux 4.11.0-10-generic (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 python-asn1crypto depends on:
ii  python  2.7.13-2

python-asn1crypto recommends no packages.

python-asn1crypto suggests no packages.

-- no debconf information

Bug#873136: RFS: xmltoman/0.4-5 [ITP] -- simple XML to man converter

[Adam Bilbrough]

Package: sponsorship-requests

Severity: normal


Dear mentors,

I am looking for a sponsor for my package "xmltoman":


Package name: xmltoman

Version: 0.4-5

Upstream Author: Adam Bilbrough 

URL: https://gitlab.com/atsb/xmltoman

License: GPL-2+

Section: devel


It builds these binary packages:

  xmltoman - simple XML to man converter

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xmltoman/xmltoman_0.4-5.dsc

More information about xmltoman can be obtained from:

  https://gitlab.com/atsb/xmltoman


Changes since the last upload:

* New maintainer. (Closes: #647716).
* Added Multi-Arch: foreign to debian/control. (Closes: #862196).
* Updated debian/watch to point to new upstream location.
* Updated debian/control with maintainer information.
* Updated debian/copyright with new maintainer and date.
* Added strict and warnings to Perl files.
* Fixed code for strict and warnings.


Regards,

Adam

Bug#726731: #726731: dump: Huge RAM usage on restore

[Elliott Mitchell]

On Thu, Aug 24, 2017 at 11:52:26PM +1000, Alexander Zangerl wrote:
> On Mon, 17 Jul 2017 20:55:04 -0700, Elliott Mitchell writes:
> >I should mention a reasonable alternative method.
> 
> i'm not sure i'd want to go to a dir tree for this; if
> one just wants to handle level 0 backups then my understanding
> is that the restoresymtable could be skipped completely.
> 
> there's no code for such a skip at this time, but i suspect that
> that would be a cheap remedy - at least for full backups.

That would be mode -x or -X which extracts files, rather than than
attempting to do a full restore.  That certainly has benefits if you're
merely trying to retrieve copies of file from a dump.  Since the original
bug specifically mentioned "restore", implying mode -r that doesn't sound
like an acceptable resolution (though possibly acceptable to the original
reporter).


> >I /think/ it should be reasonable to replace restoresymtable with a
> >small directory tree.
> 
> right now i don't see why the symtable cannot be dumped incrementally
> instead of being held in memory. 

If the i-nodes in a dump can be *guaranteed* to be in-order then such
should be possible.  I'm guessing right now either hash table(s) or a
tree is being used, since an old i-node number needs to be mapped to a
new i-node number/file.  If they're guaranteed in-order then that can be
optimized to a list-type structure with a provision for skipping ahead
quickly.

I'm pretty sure e2dumpfs upholds this guarantee, but do *all* dump
implementations uphold this guarantee? (ideally `restore` would be able
to handle foreign dumps)

Speaking of which, I'm inclined to suggest `dump` should have a -t option
similar to the -t option of `mount`.  Alas -t for `restore` has already
been allocated for a behavior like `tar`'s -t behavior.


-- 
(\___(\___(\__  --=> 8-) EHM <=--  __/)___/)___/)
 \BS (| ehem+sig...@m5p.com  PGP 87145445 |)   /
  \_CS\   |  _  -O #include  O-   _  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445

Bug#873135: ITP: node-log-driver -- log-driver is a simple logging framework for logging to stdout

[Bastien ROUCARIES]

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

* Package name: node-log-driver
  Version : 1.2.5
  Upstream Author : Gregg Caines 
* URL : https://github.com/cainus/logdriver
* License : ISC
  Programming Lang: JavaScript
  Description : log-driver is a simple logging framework

 This module implement logging to stdout and concatenate before every message
 the log level severity (configurable) and date, time and local time
zone. This modules
 ones to easilly trace log event even.
 .
 In all the cases log are redirected to stdout in order to allows one
to pipe output to irc or logger  program
 .
 This modules is needed by tools like coveralls a coverage tools for javascript
 program.
 .
 Node.js is an event-based server-side JavaScript engine.

Bug#873134: imagemagick: CVE-2017-12983

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-11
Severity: important
Tags: security patch upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/682

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-12983[0]:
| Heap-based buffer overflow in the ReadSFWImage function in coders/sfw.c
| in ImageMagick 7.0.6-8 allows remote attackers to cause a denial of
| service (application crash) or possibly have unspecified other impact
| via a crafted file.

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-2017-12983
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12983
[1] https://github.com/ImageMagick/ImageMagick/issues/682

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#873133: isc-dhcp-client: dhclient-scripts executes dhclient-{enter,exit}-hooks when it should not

[Timo Sigurdsson]

Package: isc-dhcp-client
Version: 4.3.5-3
Severity: normal

Dear Maintainer,

I noticed that dhclient-script does not honor the executability flag of
either /etc/dhcp/dhclient-{enter,exit}-hooks or files inside the directories
/etc/dhcp/dhclient-{enter,exit}-hooks.d/ and will execute even non-executable
files by sourcing them. This is not supposed to happen according to the
dhclient-script man page.

Quote from the man page:
  [dhclient-script] checks for the presence of an executable
  /etc/dhcp/dhclient-enter-hooks script, and if present, it invokes the
  script inline, using the Bourne shell '.' command. It also invokes all
  executable scripts in /etc/dhcp/dhclient-enter-hooks.d/* in the same way.

The passage on the exit-hooks reads likewise.

However, dhclient-script does not actually check the executability of any of
these files. The run-hook function in dhclient-script only checks whether the
argument is a file and then sources it, see lines 144-145 of dhclient-script:
  if [ -f $script ]; then
. $script

In addition, the run-hookdir function also iterates over files that are not
executable, see line 162:
  for script in $(run-parts --list $dir); do

The problem here is the list switch of run-parts. Quote from the run-parts
man page:
  --list print the names of the all matching files (not limited to
 executables), but don't actually run them.

It would be better to use the --test switch here instead which will only
print the names of executable files in the folder without actually running
them.

Thus, a fix should be rather trivial to get dhclient-script to actually
invoke executables only.

On a sidenote, though, on my rather fresh installation of Debian Stretch, I
have several files inside /etc/dhcp/dhclient-exit-hooks.d/ that are not
executable by default such as
  debug
  timesyncd
  rfc3442-classless-routes
So, I'm wondering whether their respective authors actually meant them to be
run by default or not.

Regards,

Timo

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

Kernel: Linux 4.9.0-3-amd64 (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: systemd (via /run/systemd/system)

Versions of packages isc-dhcp-client depends on:
ii  debianutils   4.8.1.1
ii  iproute2  4.9.0-1
ii  libc6 2.24-11+deb9u1
ii  libdns-export162  1:9.10.3.dfsg.P4-12.3+deb9u2
ii  libisc-export160  1:9.10.3.dfsg.P4-12.3+deb9u2

Versions of packages isc-dhcp-client recommends:
ii  isc-dhcp-common  4.3.5-3

Versions of packages isc-dhcp-client suggests:
ii  avahi-autoipd 0.6.32-2
pn  isc-dhcp-client-ddns  
pn  resolvconf

-- no debconf information

Bug#868905: [htcondor-debian] Bug#868905:

[Tim Theisen]

Hi Michael,

I incorporated your patch into the Debian build. I am currently waiting
for my upload to be accepted into sid.

Thank you, ...Tim


On 07/25/2017 08:48 PM, Michael Hudson-Doyle wrote:
> I fixed this in Ubuntu with this patch:
>
>
>
> ___
> htcondor-debian mailing list
> htcondor-deb...@cs.wisc.edu
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-debian

-- 
Tim Theisen
Release Manager
HTCondor & Open Science Grid
Center for High Throughput Computing
Department of Computer Sciences
University of Wisconsin - Madison
4261 Computer Sciences and Statistics
1210 W Dayton St
Madison, WI 53706-1685
+1 608 265 5736

Bug#873132: RFS: dav-text/0.8.6-2 [ITA] -- minimal ncurses-based text editor

[Adam Bilbrough]

Package: sponsorship-requests

Severity: normal


Dear mentors,

I am looking for a sponsor for my package "dav-text":


Package name: dav-text

Version: 0.8.6-2

Upstream Author: Adam Bilbrough 

URL: https://gitlab.com/atsb/dav-text

License: GPLv2

Section: text


It builds these binary packages:

  dav-text - minimal ncurses based text editor

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

  https://mentors.debian.net/package/dav-text

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dav-text/dav-text_0.8.6-2.dsc

More information about dav-text can be obtained from:

  https://gitlab.com/atsb/dav-text


Changes since the last upload:

* Wishlist bug implemented (closes: #872848)


Regards,

Adam

Bug#872828: RFS: node-regjsgen/0.3.0-1 ITP

[Bastien ROUCARIES]

example.js should not be installed with dh_installdoc but with
dh_installexample thus supply a file debian/examples with
debian/example.js.

This is the last remark

On Wed, Aug 23, 2017 at 9:29 PM, Bastien ROUCARIES
 wrote:
> Any news of dfsg version ?

Bug#865502: Patch created

[Matijs van Zuijlen]

This patch has now been accepted and is part of pre-release 4.0.3rc5.
Please consider applying this patch to the version in Debian.

Regards,
Matijs

On Fri, 7 Jul 2017 14:52:04 +0200 Matijs van Zuijlen 
wrote:
> I created a minimal patch and submitted it upstream here:
> https://github.com/JoeDog/siege/pull/107
> 
> Regards,
> Matijs
> 



signature.asc
Description: OpenPGP digital signature

Bug#873131: imagemagick: CVE-2017-13061

[Salvatore Bonaccorso]

Source: imagemagick
Version: 8:6.9.7.4+dfsg-11
Severity: important
Tags: patch security upstream
Forwarded: https://github.com/ImageMagick/ImageMagick/issues/645

Hi,

the following vulnerability was published for imagemagick.

CVE-2017-13061[0]:
| In ImageMagick 7.0.6-5, a length-validation vulnerability was found in
| the function ReadPSDLayersInternal in coders/psd.c, which allows
| attackers to cause a denial of service (ReadPSDImage memory exhaustion)
| via a crafted file.

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-2017-13061
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13061
[1] https://github.com/ImageMagick/ImageMagick/issues/645

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#873130: graphicsmagick: CVE-2017-13063

[Salvatore Bonaccorso]

Source: graphicsmagick
Version: 1.3.26-5
Severity: important
Tags: upstream patch security
Forwarded: https://sourceforge.net/p/graphicsmagick/bugs/434/

Hi,

the following vulnerability was published for graphicsmagick.

CVE-2017-13063[0]:
| GraphicsMagick 1.3.26 has a heap-based buffer overflow vulnerability in
| the function GetStyleTokens in coders/svg.c:314:12.

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-2017-13063
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13063
[1] https://sourceforge.net/p/graphicsmagick/bugs/434/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#873129: graphicsmagick: CVE-2017-13064

[Salvatore Bonaccorso]

Source: graphicsmagick
Version: 1.3.26-5
Severity: important
Tags: upstream patch security
Forwarded: https://sourceforge.net/p/graphicsmagick/bugs/436/

Hi,

the following vulnerability was published for graphicsmagick.

Remark, I know CVE-2017-13063, CVE-2017-13064, CVE-2017-13065 have the
same fixing commit upstream. I though not verfied if common set goes
back to oldstable, so decided to fill the isuses individually. If you
disagree, please merge those three reports.

CVE-2017-13064[0]:
| GraphicsMagick 1.3.26 has a heap-based buffer overflow vulnerability in
| the function GetStyleTokens in coders/svg.c:311:12.

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-2017-13064
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-13064
[1] https://sourceforge.net/p/graphicsmagick/bugs/436/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#873055: libgnutls30: Safe renegotiation breaks on session resumption with OpenSSL client

[Andreas Metzler]

Control; forwarded -1 https://gitlab.com/gnutls/gnutls/issues/259

On 2017-08-24 Thomas Klute  wrote:
> Package: libgnutls30
> Version: 3.5.14-3
> Severity: normal

> If the %SAFE_RENEGOTIATION flag is enabled in the priorities string of
> a GnuTLS server, Client Hellos from OpenSSL clients attempting session
> resumption are rejected with a "safe renegotiation failed" error, even
> though the client does support safe renegotiation. Note that the
> handshake works as expected if the session cache entry or ticket has
> expired (without resumption, of course), so the bug only affects
> otherwise successful resumption.

> I have initially observed this bug using mod_gnutls (package
> libapache2-mod-gnutls), but it is fully reproducible using only the
> GnuTLS and OpenSSL command line tools. The logs below have been
> produced by running a gnutls-serv server and connecting using openssl
> s_client and gnutls-cli (separated by three pings for clarity in
> client logs and packet capture), both set to immediately disconnect
> and resume after the initial handshake. The GnuTLS client can resume
> the TLS session as expected, while the OpenSSL client is rejected.

> Commands to reproduce:
> (server)$ gnutls-serv --priority="NORMAL:%SAFE_RENEGOTIATION"
> --x509keyfile=server/secret.key --x509certfile=server/x509-chain.pem -p 4433
> (OpenSSL client)$ openssl s_client -connect localhost:4433 -reconnect
> (GnuTLS client)$ gnutls-cli -p 4433 --x509cafile=authority/x509.pem
> --resume localhost

> A packet capture taken during this process shows a difference in how
> GnuTLS and OpenSSL signal safe renegotiation support in the Client
> Hello: GnuTLS sends the renegotiation_info extension, OpenSSL includes
> the TLS_EMPTY_RENEGOTIATION_INFO_SCSV in the list of cipher suites.
> According to RFC 5746 both are equally valid for both full and
> session-resumption handshakes, but the GnuTLS server appears to ignore
> the SCSV during session resumption.
[...]


Hello,

thank you, I have forwarded the issue upstream after verifying that it
still applies to 3.6.0.

cu Andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#873127: tor FTCBFS: binutils dependency unsatisfiable

[Helmut Grohne]

Source: tor
Version: 0.3.0.10-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

tor fails to cross build from source, because its build dependency on
binutils is unsatisfiable. The build architecture binutils is requested
via build-essential and Build-Depends request a host architecture
binutils while binutils is not Multi-Arch: foreign. In theory we'd need
"toolchain dependency cross translation" here, but the dependency is so
outdated that it is always satisfied even in wheezy. A simpler way is to
drop it. After doing so, tor cross builds successfully. Please consider
applying the attached patch.

Helmut
diff -u tor-0.3.0.10/debian/changelog tor-0.3.0.10/debian/changelog
--- tor-0.3.0.10/debian/changelog
+++ tor-0.3.0.10/debian/changelog
@@ -1,3 +1,11 @@
+tor (0.3.0.10-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop obsolete binutils satisfied in wheezy from Build-Depends. (closes:
+#-1)
+
+ -- Helmut Grohne   Thu, 24 Aug 2017 20:22:35 +0200
+
 tor (0.3.0.10-1) unstable; urgency=medium
 
   * New upstream version.
diff -u tor-0.3.0.10/debian/control tor-0.3.0.10/debian/control
--- tor-0.3.0.10/debian/control
+++ tor-0.3.0.10/debian/control
@@ -2,7 +2,7 @@
 Section: net
 Priority: optional
 Maintainer: Peter Palfrader 
-Build-Depends: debhelper (>= 9.20160114), quilt, libssl-dev, zlib1g-dev, 
libevent-dev (>= 1.1), binutils (>= 2.14.90.0.7), asciidoc (>= 8.2), 
docbook-xml, docbook-xsl, xmlto, dh-apparmor, libseccomp-dev [amd64 i386], 
dh-systemd [linux-any], libsystemd-dev [linux-any], pkg-config [linux-any], 
dh-autoreconf
+Build-Depends: debhelper (>= 9.20160114), quilt, libssl-dev, zlib1g-dev, 
libevent-dev (>= 1.1), asciidoc (>= 8.2), docbook-xml, docbook-xsl, xmlto, 
dh-apparmor, libseccomp-dev [amd64 i386], dh-systemd [linux-any], 
libsystemd-dev [linux-any], pkg-config [linux-any], dh-autoreconf
 Build-Conflicts: libnacl-dev, libseccomp-dev [!amd64 !i386]
 Standards-Version: 3.9.8
 Homepage: https://www.torproject.org/

Bug#873128: texlive-lang-arabic: XEPERSIAN PROBLEM WITH FONTSPEC ON DEBIAN STABLE

[Hassan Abedi]

Package: texlive-lang-arabic
Version: 2016.20170123-5
Severity: important



-- Package-specific info:
IMPORTANT INFORMATION: We will only consider bug reports concerning
the packaging of TeX Live as relevant. If you have problems with
combination of packages in a LaTeX document, please consult your
local TeX User Group, the comp.text.tex user group, the author of
the original .sty file, or any other help resource. 

In particular, bugs that are related to up-upstream, i.e., neither
Debian nor TeX Live (upstream), but the original package authors,
will be closed immediately.

   *** The Debian TeX Team is *not* a LaTeX Help Desk ***

If you report an error when running one of the TeX-related binaries 
(latex, pdftex, metafont,...), or if the bug is related to bad or wrong
output, please include a MINIMAL example input file that produces the
error in your report.

Please run your example with
(pdf)latex -recorder ...
(or any other program that supports -recorder) and send us the generated
file with the extension .fls, it lists all the files loaded during
the run and can easily explain problems induced by outdated files in
your home directory.

Don't forget to also include minimal examples of other files that are 
needed, e.g. bibtex databases. Often it also helps
to include the logfile. Please, never send included pictures!

If your example file isn't short or produces more than one page of
output (except when multiple pages are needed to show the problem),
you can probably minimize it further. Instructions on how to do that
can be found at

http://www.minimalbeispiel.de/mini-en.html (english)

or 

http://www.minimalbeispiel.de/mini.html (german)

##
minimal input file


##
other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2156 Aug 15 08:24 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Jan 17  2017 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Mar  4 10:23 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Mar  4 10:23 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Jun 22 11:04 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Mar  4 10:23 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Mar  4 10:23 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 2811 Aug 15 08:23 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Oct 21  2014 mktex.cnf
-rw-r--r-- 1 root root 475 Jun 22 11:04 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: 9.1
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable')
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.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages texlive-lang-arabic depends on:
ii  fonts-hosny-amiri  0.107-1
ii  tex-common 6.06
ii  texlive-base   2016.20170123-5
ii  texlive-generic-extra  2016.20170123-5

texlive-lang-arabic recommends no packages.

texlive-lang-arabic suggests no packages.

Versions of packages tex-common depends on:
ii  dpkg  1.18.24
ii  ucf   3.0036

Versions of packages tex-common suggests:
ii  debhelper  10.2.5

Versions of packages texlive-lang-arabic is related to:
ii  tex-common6.06
ii  texlive-binaries  2016.20160513.41080.dfsg-2

-- debconf information:
  tex-common/check_texmf_wrong:
  tex-common/check_texmf_missing:

Bug#869667: stretch-pu: package xkeyboard-config/2.19-1

[Pirate Praveen]

On വ്യാഴം 24 ആഗസ്റ്റ് 2017 11:36 വൈകു, Adam D. Barratt wrote:
> There appears to be some confusion here.
> 
> stretch/updates is in the security archive and therefore irrelevant to
> this discussion.
> 
> Before the point release, your upload will be in proposed-updates.
> Packages in proposed-updates are available once a member of the Release
> Team has accepted them from the stable-new queue. That still requires
> users consuming proposed-updates, which most don't.
> 
> Finally, stretch-updates is a special distribution which the Release
> Team can push packages from proposed-updates to under some
> circumstances. That still requires the package to have been accepted
> into proposed-updates first as per the above, and I'm not convinced that
> this upload would meet the criteria for such a release.

Sorry for the confusion and thanks for clarifying. I was hoping for
stretch-updates, but I'll have to live with a point release. In that
case, I understand the delay.



signature.asc
Description: OpenPGP digital signature

Bug#873126: keepass2: cannot enter characters with Alt-Gr modifier at startup

[Luc Maisonobe]

Package: keepass2
Version: 2.36+dfsg-1
Severity: normal

Dear Maintainer,

Since one or two weeks (i.e since about mid-august 2017), I cannot enter
any characters with Alt-Gr modifier in keepass2 text fields just after
login.

If I try to type such a character for example in the master password
textfield to unlock the master database, no '*' appear. The '*'
character does appear for all other characters (i.e. characters that
do not require the Alt-Gr modifier). This happens in gnome-shell with
a French setting and two keyboards configured: fr1 (named "Français
(variante)")
and fr2 (named "Français, Bépo, ergonomique, façon Dvorak)", where fr1
is the default setting selected at login.

When this happens (i.e. always just after login), I can workaround
by following the steps below:

 1) close the keepass2 application that failed
 2) in the desktop top gnome-shell bar, select
the other keyboard (i.e fr2, Bépo)
 3) in the desktop top gnome-shell bar, select
back the first keyboard (i.e fr1, Français variante)
 4) launch again Keepass2

With this procedure, which changes the keybord once and changes
it back immediately, the Alt-Gr characters can be typed into Keepass2
testfield.

When this started to happen, I checked for both Keepass2 and Mono
changes, but saw really nothing. I guess this is due to a change in a
deeper library. However, this wrong behaviour appears *only* with
Keepass2. For all other applications I checked, Alt-Gr characters
can be typed right after login without any problems.



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

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

Versions of packages keepass2 depends on:
ii  libmono-corlib4.5-cil4.6.2.7+dfsg-1
ii  libmono-system-drawing4.0-cil4.6.2.7+dfsg-1
ii  libmono-system-security4.0-cil   4.6.2.7+dfsg-1
ii  libmono-system-windows-forms4.0-cil  4.6.2.7+dfsg-1
ii  libmono-system-xml4.0-cil4.6.2.7+dfsg-1
ii  libmono-system4.0-cil4.6.2.7+dfsg-1
ii  libx11-6 2:1.6.4-3
ii  mono-runtime 4.6.2.7+dfsg-1

Versions of packages keepass2 recommends:
ii  xsel  1.2.0-3

Versions of packages keepass2 suggests:
pn  keepass2-doc  
pn  mono-dmcs 
pn  xdotool   

-- no debconf information

Bug#870909: RFS: cxlflash/4.3.2493-1 [ITP] -- IBM Data Engine for NoSQL Software Libraries

[Rodrigo]

Hi Andrey,


> There are a lot of errors in the install_root_man1 target.
> There are warnings about unused ${perl:Depends}.


We've made changes that should fix these errors. Could you check it, 
please? -> 
https://mentors.debian.net/debian/pool/non-free/c/cxlflash/cxlflash_4.3.2528-1.dsc


Thanks,
Rodrigo R. Galvao

Bug#873125: debian-policy: FTBFS with Sphinx 1.6: Needs build-dep on latexmk

[Dmitry Shachnev]

Source: debian-policy
Version: 4.1.0.0
Severity: important
User: python-modules-t...@lists.alioth.debian.org
Usertags: sphinx1.6

Dear maintainer,

debian-policy fails to build with Sphinx 1.6, currently available in
experimental:

  sphinx-build -M latexpdf policy policy/_build
  Running Sphinx v1.6.3
  [...]
  build succeeded.
  make[2]: Entering directory '/<>/policy/_build/latex'
  make[2]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
  latexmk -pdf -dvi- -ps-  'policy.tex'
  make[2]: latexmk: Command not found
  Makefile:33: recipe for target 'policy.pdf' failed
  make[2]: *** [policy.pdf] Error 127

Since Sphinx 1.6, latexmk is required to build the LaTeX documentation [1].
Adding a build-dependency on latexmk should help.

[1]: https://github.com/sphinx-doc/sphinx/pull/3082

--
Dmitry Shachnev


signature.asc
Description: PGP signature

Bug#872442: jessie-pu: package gsoap/2.8.17-1+deb8u1

[Martin Zobel-Helas]

Hi, 

On Thu Aug 24, 2017 at 15:51:30 +0200, Mattias Ellert wrote:
> fre 2017-08-18 klockan 13:47 +0200 skrev Mattias Ellert:
> > 
> > > No. You want to open a bug report against your own package, telling
> > > there is a security bug. and you want to refer that on in the closes
> > > statement.
> > > 
> > 
> > This contradicts what Adam said in bug #872441:
> > 
> > > If there is no bug filed against gsoap that relates to the issue, then 
> > > there should be no bug closed in the changelog.
> > 
> > Can you resolve your differences?
> > 
> > Mattias
> 
> Hi again.
> 
> Is there a resolution to this? Is a Closes statement mandatory or not?

Adam has the last word on this. If he says it is okay, that is fine with
me.

Cheers,
Martin
-- 
 Martin Zobel-Helas Debian System Administrator
 Debian & GNU/Linux Developer   Debian Listmaster
 http://about.me/zobel   Debian Webmaster
 GPG Fingerprint:  6B18 5642 8E41 EC89 3D5D  BDBB 53B1 AC6D B11B 627B 

Bug#868990: lazarus: FTBFS: Architecture mips(el) is not available for elf format

[Paul Gevers]

Hi

On 08/24/17 17:29, Peter Green wrote:
> Paul Gevers and I took at look at this while at Debconf.

And thanks again for helping.

> Fixing the resource conversionturned out to be pretty easy.
> Unfortunately after doing so the lazarus package still failed to build.
> There seems to be a linker issue with freepascal and qt on mips.

I updated the upstream bug with our findings.

> So we decided to disable qt lazarus and only enable gtk lazarus.
> Unfortunately it seems paul forgot to disable the lcl-qt packages so it
> currently fails to build in the packaging step. Hopefully this should
> get fixed soon.

Already committed locally. I was waiting for the
fpc/lazarus/castle-game-engine to migrate. Should happen in the next upload.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#869667: stretch-pu: package xkeyboard-config/2.19-1

[Adam D. Barratt]

On Thu, 2017-08-24 at 22:59 +0530, Pirate Praveen wrote:
> On വ്യാഴം 24 ആഗസ്റ്റ് 2017 09:46 വൈകു, Cyril Brulebois wrote:
> > Great thing that point releases usually happen once every 3 months, right?
> > 
> > Anyway: right now, D-I Buster Alpha 1 has the priority; point release
> > material can definitely wait.
> 
> But it is blocking everyone, as it can't go into updates without your
> ack. Packages in stretch/updates are available immediately to users once
> it enters the archive.

There appears to be some confusion here.

stretch/updates is in the security archive and therefore irrelevant to
this discussion.

Before the point release, your upload will be in proposed-updates.
Packages in proposed-updates are available once a member of the Release
Team has accepted them from the stable-new queue. That still requires
users consuming proposed-updates, which most don't.

Finally, stretch-updates is a special distribution which the Release
Team can push packages from proposed-updates to under some
circumstances. That still requires the package to have been accepted
into proposed-updates first as per the above, and I'm not convinced that
this upload would meet the criteria for such a release.

Regards,

Adam

Bug#873124: telepathy-gabble: Unable to add jabber/XMPP account

[kpp]

Package: telepathy-gabble
Version: 0.18.3-3
Severity: important

Dear Maintainer,

   * What led up to the situation?
Attempt to add xmpp account to KDE 5 telepathy

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Launch system settings of KDE5, choose Personalization, Online Accounts, 
Create


   * What was the outcome of this action?
I can see only Google and Twitter (see attachment)

   * What outcome did you expect instead?
Button to add Jabber/XMPP account


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

Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)

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

Versions of packages telepathy-gabble depends on:
ii  libc6   2.24-11+deb9u1
ii  libdbus-1-3 1.10.18-1
ii  libdbus-glib-1-20.108-2
ii  libglib2.0-02.50.3-2
ii  libgnutls30 3.5.8-5+deb9u2
ii  libnice10   0.1.13-2
ii  libsoup2.4-12.56.0-2
ii  libsqlite3-03.16.2-5
ii  libtelepathy-glib0  0.24.1-1.1
ii  libxml2 2.9.4+dfsg1-2.2

telepathy-gabble recommends no packages.

telepathy-gabble suggests no packages.

-- no debconf information

Bug#873032: findutils: find with -printf '%T+' crashes with buffer overflow detected message

[Andreas Metzler]

Control: forwarded -1 https://savannah.gnu.org/bugs/?51841

On 2017-08-23 Ryan  wrote:
> Package: findutils
> Version: 4.6.0+git+20170729-2
> Severity: normal

> Dear Maintainer,


> The findutils/find version now in buster 4.6.0+git+20170729-2 fails
> when I use find with -printf '%T+'.  If I change the time format away
> from + to @, it works fine.

> I then used find from findutils_4.6.0+git+20161106-2_amd64.deb and the
> expected functionality returned.
[...]

Hello Ryan,

thanks for the easy to reproduce bugreport. I have fordwarded the issue
after bisecting it.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Bug#873123: uim-xim segfaults with anthy

[Leonardo Boiko]

Package: uim-xim
Version: 1:1.8.6+gh20161003.0.d63dadd-4
Severity: important

$ uim-xim
uim <-> XIM bridge. Supporting multiple locales.
Using full-synchronous XIM event flow
Segmentation fault

$ uim-xim --list
uim <-> XIM bridge. Supporting multiple locales.
Segmentation fault

Last few interesting lines of strace:

open("/usr/share/anthy/anthy.dic", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=22093248, ...}) = 0
mmap(NULL, 22093248, PROT_READ, MAP_SHARED, 3, 0) = 0x7f3545cf9000
close(3)= 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR,
si_addr=0x7f3582ca1748} ---
+++ killed by SIGSEGV +++

And ltrace:

uim_init(0x556e0b944912, 0x7fff5b7f3de4, 0x7fff5b7f3ddd, 0)
= 0
uim_create_context(0, 0x556e0b946304, 0, 0 
--- SIGSEGV (Segmentation fault) ---

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

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

Versions of packages uim-xim depends on:
ii  libc62.24-15
ii  libgcc1  1:7.2.0-1
ii  libstdc++6   7.2.0-1
ii  libuim-data  1:1.8.6+gh20161003.0.d63dadd-4
ii  libuim-scm0  1:1.8.6+gh20161003.0.d63dadd-4
ii  libuim8  1:1.8.6+gh20161003.0.d63dadd-4
ii  libx11-6 2:1.6.4-3
ii  libxext6 2:1.3.3-1+b2
ii  libxft2  2.3.2-1+b2
ii  uim-common   1:1.8.6+gh20161003.0.d63dadd-4
ii  uim-utils1:1.8.6+gh20161003.0.d63dadd-4

uim-xim recommends no packages.

Versions of packages uim-xim suggests:
ii  uim-gtk2.0  1:1.8.6+gh20161003.0.d63dadd-4
ii  uim-gtk31:1.8.6+gh20161003.0.d63dadd-4
ii  uim-qt  1:1.8.6+gh20161003.0.d63dadd-4
ii  uim-qt5 1:1.8.6+gh20161003.0.d63dadd-4

-- no debconf information

Bug#869667: stretch-pu: package xkeyboard-config/2.19-1

[Cyril Brulebois]

Pirate Praveen  (2017-08-24):
> On വ്യാഴം 24 ആഗസ്റ്റ് 2017 09:46 വൈകു, Cyril Brulebois wrote:
> > Great thing that point releases usually happen once every 3 months, right?
> > 
> > Anyway: right now, D-I Buster Alpha 1 has the priority; point release
> > material can definitely wait.
> 
> But it is blocking everyone, as it can't go into updates without your
> ack. Packages in stretch/updates are available immediately to users once
> it enters the archive.

You seem to be confused:
 - stretch/updates is a security suite.
 - stretch-proposed-updates is what this stretch-pu request is about;
   the package is available in this extra suite which users may have
   configured, then merged during point releases into stretch.
 - stretch-updates is for immediate bug fixes, through an extra suite as
   well, even if it's more likely to be configured on user systems.

I haven't seen anything in the bug report that indicates you were
requesting that your package goes to stretch-updates as opposed to the
default stretch-proposed-updates, so your claim above seems rather
incorrect to me.


KiBi.


signature.asc
Description: Digital signature

Bug#873122: HTTP Link to Keyring

[Hanno Böck]

Package: www.debian.org

When downloading a Debian CD there's a webpage explaining how to verify
signatures:
https://www.debian.org/CD/verify

This recommends to check the signatures with the keys from the Debian
GPG keyring. However that link is HTTP, pointing to:
http://keyring.debian.org/

It will immediately redirect to HTTPS, but an attacker could intercept
that redirection and present a user with a malicious keyring instead.

This makes the verification kinda pointless, as the keyring is
delivered over a potentially insecure channel. The lack of HSTS on
debian.org makes this particularly worriesome. Please change that link
to HTTPS.

Bug#861101: Can't enter disk encryption password

[Sven Bartscher]

Hello Laurent,

On Thu, 24 Aug 2017 16:47:07 +0200
Laurent Bigonville  wrote:

> [snip]
> 
> On Mon, 24 Apr 2017 18:49:07 +0200 Sven Bartscher 
>  wrote:
> 
> [snip]
> 
> Are you still able to reproduce this?

Yes. The situation doesn't seem to be different from when I first
reported this bug.

> Are you using closed source drivers for your graphic card?

Yes, I am using the nvidia-driver package from Debian non-free.
Removing it (and related packages, apt remove '*nvidia*') didn't help
though.

Regards
Sven


pgpq6CeFsfGWx.pgp
Description: Digitale Signatur von OpenPGP

Bug#873108: xscreensaver does not trap errors from intltool-update

[Jamie Zawinski]

Well, on every system I've ever had access to, intltool rarely works, so I took 
to just ignoring it entirely. YMMV.

Bug#873121: fontconfig: French debconf translation update

[Alban Vidal]

Package: fontconfig
Version: 2.12.3-0.2
Severity: wishlist
Tags: patch l10n

Please find attached the French debconf templates update, proofread by the
debian-l10n-french mailing list contributors.

Best regards

Alban Vidal
# Translation of fontconfig debconf templates to French
# Copyright (C) 2007, 2012, 2017 Debian French l10n team 

# This file is distributed under the same license as the fontconfig package.
#
# translation of fr.po to French
#
#Translators, if you are not familiar with the PO format, gettext
#documentation is worth reading, especially sections dedicated to
#this format, e.g. by running:
# info -n '(gettext)PO Files'
# info -n '(gettext)Header Entry'
#
#Some information specific to po-debconf are available at
#/usr/share/doc/po-debconf/README-trans
# or http://www.debian.org/intl/l10n/po-debconf/README-trans
#
#Developers do not need to manually edit POT or PO files.
#
# Former translators: Philippe Batailler 
# Jean-Christophe Champarnaud 
# Thomas Huriaux 
#
# Translators:
# Christian Perrier , 2007, 2012.
# Alban Vidal , 2017.
msgid ""
msgstr ""
"Project-Id-Version: fontconfig 2.12.3-0.2\n"
"Report-Msgid-Bugs-To: fontcon...@packages.debian.org\n"
"POT-Creation-Date: 2017-07-05 11:29+0200\n"
"PO-Revision-Date: 2017-08-09 23:39+0200\n"
"Last-Translator: Alban Vidal \n"
"Language-Team: French \n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"X-Generator: Lokalize 2.0\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

#. Type: select
#. Choices
#: ../fontconfig-config.templates:2001
msgid "Native"
msgstr "Native"

#. Type: select
#. Choices
#: ../fontconfig-config.templates:2001
msgid "Autohinter"
msgstr "Automatique"

#. Type: select
#. Choices
#. Type: select
#. Choices
#: ../fontconfig-config.templates:2001 ../fontconfig-config.templates:3001
msgid "None"
msgstr "Aucune"

#. Type: select
#. Description
#: ../fontconfig-config.templates:2002
msgid "Font tuning method for screen (system default):"
msgstr ""
"Méthode d'amélioration de rendu des polices d'affichage par défaut du "
"système :"

#. Type: select
#. Description
#: ../fontconfig-config.templates:2002
msgid ""
"Please select the preferred method for tuning fonts for screen rendering."
msgstr ""
"Veuillez choisir la méthode que vous souhaitez utiliser pour l'amélioration "
"de l'affichage des polices à l'écran."

#. Type: select
#. Description
#: ../fontconfig-config.templates:2002
msgid ""
"Select 'Native' if you mostly use DejaVu (the default in Debian) or any of "
"the Microsoft fonts. Select 'Autohinter' if you mostly use other TrueType "
"fonts. Select 'None' if you want blurry text."
msgstr ""
"Choisissez :\n"
" « Native » si vous utilisez couramment DejaVu (par défaut dans Debian) ou "
"une police de Microsoft ;\n"
" « Automatique » si vous utilisez couramment d'autres polices "
"« TrueType » ;\n"
" « Aucune » si vous voulez du texte flou."

#. Type: select
#. Choices
#: ../fontconfig-config.templates:3001
msgid "Slight"
msgstr "Léger"

#. Type: select
#. Choices
#: ../fontconfig-config.templates:3001
msgid "Medium"
msgstr "Moyen"

#. Type: select
#. Choices
#: ../fontconfig-config.templates:3001
msgid "Full"
msgstr "Complet"

#. Type: select
#. Description
#: ../fontconfig-config.templates:3002
#| msgid "Font tuning method for screen (system default):"
msgid "Automatic font hinting style:"
msgstr "Méthode d'optimisation automatique des polices :"

#. Type: select
#. Description
#: ../fontconfig-config.templates:3002
#| msgid ""
#| "Please select the preferred method for tuning fonts for screen rendering."
msgid ""
"Please select the preferred automatic font hinting style to be used as the "
"system default."
msgstr ""
"Veuillez choisir la méthode d'optimisation automatique des polices que vous "
"souhaitez utiliser par défaut."

#. Type: select
#. Description
#: ../fontconfig-config.templates:3002
msgid ""
"The hinting style is the amount of font reshaping done to line up to the "
"grid. \"Slight\" will make the font more fuzzy to line up to the grid but "
"will be better in retaining font shape, while \"Full\" will be a crisp font "
"that aligns well to the pixel grid but will lose a greater amount of font "
"shape. \"Slight\" is the default setting."
msgstr ""
"La méthode d'optimisation est la quantité de remodelage exécutée pour un "
"alignement sur la grille. La méthode « Léger » rend l’alignement de la "
"police plus imprécis mais est meilleure pour conserver sa forme, tandis que "
"« Complet » donnera une police nette qui sera alignée sur la grille de "
"pixels mais perdra une plus grande partie de sa forme. « Léger » est la "

Bug#867660: ball: FTBFS with sip 4.19.x: sip: File::CannotWrite has not been defined

[Dmitry Shachnev]

Hi Andreas!

On Tue, Aug 22, 2017 at 03:53:05PM +0200, Andreas Tille wrote:
> Thanks for the hint.  I can confirm that the executable builds with this
> patch.  Unfortunately the package does not build due to test errors:
>
> ...
> 98% tests passed, 5 tests failed out of 333

Sorry, I was mostly testing on Ubuntu, and the tests passed fine there.

I don’t think I can help you here, maybe contacting upstream will be better.

--
Dmitry Shachnev


signature.asc
Description: PGP signature