Bug#897951: font-myanmar: sponsorship-requests

[kokoye2007]

Package: font-myanmar
Version: 1.0.1-1
Severity: normal

Dear Maintainer,

  Dear mentors,

  I am looking for a sponsor for my package "font-myanmar"

 * Package name: font-myanmar
   Version : 1.0.1-1
   Upstream Author : pkg-fonts-de...@lists.alioth.debian.org 
 * URL : https://salsa.debian.org/kokoye2007-guest/font-myanmar
 * License : gpl3
   Section : fonts

  It builds those binary packages:

font-myanmar - myanmar fonts:
 font-myanmar-ayar - myanmar fonts: ayar;
 font-myanmar-myanmar3 - myanmar fonts: Myanmar3;
 font-myanmar-myanmarcensus - myanmar fonts: MyanmarCensus;
 font-myanmar-pyidaungsu - myanmar fonts: Pyidaungsu;
 font-myanmar-unicode - myanmar unicode fonts
 font-myanmar-zawgyi - myanmar fonts: ZawgyiOne2008;

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

  https://mentors.debian.net/package/font-myanmar


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

dget -x 
https://mentors.debian.net/debian/pool/main/f/font-myanmar/font-myanmar_1.0.1-1.dsc

  More information about hello can be obtained from https://www.example.com.

  Changes since the last upload:

  i recent upload to https://mentors.debian.net/package/ttf-myanmar-fonts
  we got message bug 896...@bugs.debian.org

change ttf-myanmar-fonts to font-myanmar 

  Regards,
   kokoye2007

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

Kernel: Linux 4.15.0-20-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)
LSM: AppArmor: enabled

Bug#897950: [patch] curl: replace libssh to libssh

[Hideki Yamane]

package: curl
severity: wishlist
tags: patch

Hi,

 I've found Fedora28 introduced change in curl to use libssh, instead of
 libssh2. I thought it would be nice to change in Debian, too.
 See https://docs.fedoraproject.org/f28/release-notes/sysadmin/Security.html

 Patch attached.

-- 
Regards,

 Hideki Yamane henrich @ debian.org/iijmio-mail.jp
>From aef6f4a1762ca66e04736814132ab90dc8805bab Mon Sep 17 00:00:00 2001
From: Hideki Yamane 
Date: Sat, 5 May 2018 12:28:30 +0900
Subject: [PATCH] replace libssh2 to libssh

>From https://fedoraproject.org//wiki/Changes/libssh-in-libcurl

"libcurl currently uses libssh2 to implement the SSH layer of SCP
 and SFTP protocols. The libssh2 library uses outdated crypto algorithms
 and lacks important features like GSS-API authentication.
 After implementing this change, libcurl will use the libssh library
 instead, which is now more secure, feature-complete, and with more
 active upstream community."
---
 debian/control | 2 +-
 debian/rules   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/debian/control b/debian/control
index 1cfa7fcd..fd9219e9 100644
--- a/debian/control
+++ b/debian/control
@@ -18,7 +18,7 @@ Build-Depends: debhelper (>= 11),
  libnss3-dev,
  libpsl-dev,
  librtmp-dev (>= 2.4+20131018.git79459a2-3~),
- libssh2-1-dev,
+ libssh-dev,
  libssl-dev (>= 1.1),
  libtool,
  openssh-server ,
diff --git a/debian/rules b/debian/rules
index c205d4fd..8926c942 100755
--- a/debian/rules
+++ b/debian/rules
@@ -15,7 +15,7 @@ DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 CONFIGURE_ARGS = -- --disable-dependency-tracking		\
 	--disable-symbol-hiding --enable-versioned-symbols	\
 	--enable-threaded-resolver --with-lber-lib=lber		\
-	--with-gssapi=/usr --with-libssh2 --with-nghttp2	\
+	--with-gssapi=/usr --with-libssh --with-nghttp2	\
 	--includedir=/usr/include/$(DEB_HOST_MULTIARCH)		\
 	--with-zsh-functions-dir=/usr/share/zsh/vendor-completions
 
-- 
2.17.0

Bug#897949: debhelper: Clarify the order of packages returned from dh_listpackages

[Chris Lamb]

Source: debhelper
Version: 11.2.1
Severity: wishlist
Tags: patch

Hi,

Please clarify the order of packages returned from dh_listpackages.
Patch attached.


Regards,

-- 
  ,''`.
 : :'  : Chris Lamb
 `. `'`  la...@debian.org / chris-lamb.co.uk
   `-
diff --git a/dh_listpackages b/dh_listpackages
index 170f16b..3ffbc5f 100755
--- a/dh_listpackages
+++ b/dh_listpackages
@@ -23,6 +23,8 @@ packages debhelper commands will act on. If you pass it some 
options, it
 will change the list to match the packages other debhelper commands would
 act on if passed the same options.
 
+Packages are returned in the order they appear in F.
+
 =cut
 
 $dh{BLOCK_NOOP_WARNINGS}=1;

Bug#458206: no playback

[Janusz S. Bień]

I'm not sure this is the same bug, but at least it is similar.

I've decided to copy some cassettes using an USB deck, so I try to use
Audacity without any previous experience with the program and generally
with no experience in sound processing.

Unfortunately I have no sound on the playback independently of the
playback device chosen.  I have 5 options:

HDA Intel HDMI: 0 (hw:0,3)
HDA Intel HDMI: 1 (hw:0,7)
HDA Intel PCH: AL270 Analog (hw:1,0)
HDA Intel PCH: AL270 Digital (hw:1,1)
hdmi
default

On the other hand the sound control panel shows:

HDMI / DisplayPort 2 - Build-in Audio
Digital Output (S/PDIF) - Built-in Audio
Speakers - Built-in Audio

For information, on the same computer on Windows 10 Audacity works
without problems, the playback choice are (in Polish):

Mapowanie dźwięku ... [Sound mapping?]
Głośniki (Realtek High ...) [build-in loudspeakers, this is ViVoPC)
Realtek Digital Output
BenQ... (my monitor on DP port)

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

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

Versions of packages audacity depends on:
ii  audacity-data   2.1.2-2
ii  libasound2  1.1.3-5
ii  libavcodec5710:3.3.7-dmo1+deb9u1
ii  libavformat57   10:3.3.7-dmo1+deb9u1
ii  libavutil55 10:3.3.7-dmo1+deb9u1
ii  libc6   2.24-11+deb9u3
ii  libexpat1   2.2.0-2+deb9u1
ii  libflac++6v51.3.2-1
ii  libflac81.3.2-1
ii  libgcc1 1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-0  2.36.5-2+deb9u2
ii  libglib2.0-02.50.3-2
ii  libgtk2.0-0 2.24.31-2
ii  libid3tag0  0.15.1b-12
ii  liblilv-0-0 0.24.2~dfsg0-1
ii  libmad0 0.15.1b-8
ii  libmp3lame0 1:3.99.5-dmo6
ii  libogg0 1.3.2-1
ii  libportaudio2   19.6.0-1
ii  libportsmf0 0.1~svn20101010-5
ii  libsbsms10  2.0.2-2
ii  libsndfile1 1.0.27-3
ii  libsoundtouch1  1.9.2-2+deb9u1
ii  libsoxr00.1.2-2
ii  libstdc++6  6.3.0-18+deb9u1
ii  libsuil-0-0 0.8.4~dfsg0-2
ii  libtwolame0 1:0.3.13-dmo3
ii  libvamp-hostsdk3v5  2.6~repack0-3
ii  libvorbis0a 1.3.5-4+deb9u2
ii  libvorbisenc2   1.3.5-4+deb9u2
ii  libvorbisfile3  1.3.5-4+deb9u2
ii  libwxbase3.0-0v53.0.2+dfsg-4
ii  libwxgtk3.0-0v5 3.0.2+dfsg-4

audacity recommends no packages.

Versions of packages audacity suggests:
pn  ladspa-plugin  

-- no debconf information


-- 
   ,   
Prof. dr hab. Janusz S. Bien -  Uniwersytet Warszawski (Katedra Lingwistyki 
Formalnej)
Prof. Janusz S. Bien - University of Warsaw (Formal Linguistics Department)
jsb...@uw.edu.pl, jsb...@mimuw.edu.pl, http://fleksem.klf.uw.edu.pl/~jsbien/

Bug#897948: approx: jessie approx no longer retrieves files from /var/cache/approx

[y]

Package: approx
Version: 5.5-1
Severity: important

Dear Maintainer,

I have used approx for years to service a variety of Debian and Ubuntu 
computers. Recently I was trying to upgrade several computers and I noticed 
that I was downloading the packages off the net repeatedly and my rather 
pathetic DSL speed instead of getting files from my local server's cache at 11+ 
MBps. apt seems to imply that approx is working properly, e.g.
Get:1 http://server:/security/ jessie/updates/main perl amd64 
5.20.2-3+deb8u10

I enabled verbose logging in /etc/approx/approx.conf  /var/log/syslog seems to 
report that some of the files are being delivered from the cache and some are 
not. My experience is that the vast majority are not being cached, while some 
packages download at normal fast LAN speed. Here is a snippet of the syslog:

May  4 20:41:22 server approx[28108]:   close cache 
debian/pool/main/l/linux/linux-image-4.9.0-0.bpo.6-amd64_4.9.82-1+deb9u3~bpo8+1_amd64.deb
May  4 20:41:22 server approx[28108]:   setting mtime to Tue, 17 Apr 2018 
15:28:42 GMT
May  4 20:41:22 server approx[28108]: 
http://mirrors.kernel.org/debian//pool/main/l/linux/linux-image-4.9.0-0.bpo.6-amd64_4.9.82-1+deb9u3~bpo8+1_amd64.deb:
 delivered
May  4 20:41:22 server approx[28108]: Connection from 192.168.1.101 port 34662
May  4 20:41:22 server approx[28108]: Request: GET 
/debian/pool/main/l/linux-latest/linux-image-amd64_4.9%2b80%2bdeb9u4%7ebpo8%2b1_amd64.deb
May  4 20:41:22 server approx[28108]:   Host: server:
May  4 20:41:22 server approx[28108]:   User-Agent: Debian APT-HTTP/1.3 
(1.0.9.8.4)
May  4 20:41:22 server approx[28108]:   => cache miss
May  4 20:41:22 server approx[28108]: Command: /usr/bin/curl --fail --silent 
--header "Pragma: no-cache"  --include 
"http://mirrors.kernel.org/debian//pool/main/l/linux-latest/linux-image-amd64_4.9+80+deb9u4~bpo8+1_amd64.deb;
May  4 20:41:23 server approx[28108]:   HTTP/1.1 200 OK
May  4 20:41:23 server approx[28108]:   Server: nginx
May  4 20:41:23 server approx[28108]:   Date: Sat, 05 May 2018 03:41:22 GMT
May  4 20:41:23 server approx[28108]:   Content-Type: application/octet-stream
May  4 20:41:23 server approx[28108]:   Content-Length: 7332
May  4 20:41:23 server approx[28108]:   Last-Modified: Sun, 22 Apr 2018 
14:59:59 GMT
May  4 20:41:23 server approx[28108]:   Accept-Ranges: bytes
May  4 20:41:23 server approx[28108]:   X-Frame-Options: DENY
May  4 20:41:23 server approx[28108]:   X-Content-Type-Options: nosniff
May  4 20:41:23 server approx[28108]:   open cache 
debian/pool/main/l/linux-latest/linux-image-amd64_4.9+80+deb9u4~bpo8+1_amd64.deb
May  4 20:41:23 server approx[28108]: Proxy response
May  4 20:41:23 server approx[28108]:   Content-Type: text/plain
May  4 20:41:23 server approx[28108]:   Status: 200
May  4 20:41:23 server approx[28108]:   Last-Modified: Sun, 22 Apr 2018 
14:59:59 GMT
May  4 20:41:23 server approx[28108]:   Content-Length: 7332
May  4 20:41:23 server approx[28108]:   close cache 
debian/pool/main/l/linux-latest/linux-image-amd64_4.9+80+deb9u4~bpo8+1_amd64.deb
May  4 20:41:23 server approx[28108]:   setting mtime to Sun, 22 Apr 2018 
14:59:59 GMT
May  4 20:41:23 server approx[28108]: 
http://mirrors.kernel.org/debian//pool/main/l/linux-latest/linux-image-amd64_4.9+80+deb9u4~bpo8+1_amd64.deb:
 delivered
May  4 20:41:23 server approx[28108]: Connection from 192.168.1.101 port 34662
May  4 20:41:23 server approx[28108]: Request: GET 
/security/pool/updates/main/l/linux/linux-libc-dev_3.16.56-1_amd64.deb
May  4 20:41:23 server approx[28108]:   Host: server:
May  4 20:41:23 server approx[28108]:   User-Agent: Debian APT-HTTP/1.3 
(1.0.9.8.4)
May  4 20:41:23 server approx[28108]:   => delivering from cache
May  4 20:41:23 server approx[28108]: Local response
May  4 20:41:23 server approx[28108]:   Last-Modified: Mon, 30 Apr 2018 
08:57:06 GMT
May  4 20:41:23 server approx[28108]:   Content-Type: text/plain
May  4 20:41:23 server approx[28108]:   Content-Length: 1096066
May  4 20:41:23 server approx[28108]: Connection from 192.168.1.101 port 34662
May  4 20:41:23 server approx[28108]: Request: GET 
/security/pool/updates/main/m/mysql-5.5/mysql-server-core-5.5_5.5.60-0%2bdeb8u1_amd64.deb
May  4 20:41:23 server approx[28108]:   Host: server:
May  4 20:41:23 server approx[28108]:   User-Agent: Debian APT-HTTP/1.3 
(1.0.9.8.4)
May  4 20:41:23 server approx[28108]:   => delivering from cache
May  4 20:41:23 server approx[28108]: Local response
May  4 20:41:23 server approx[28108]:   Last-Modified: Thu, 19 Apr 2018 
10:28:18 GMT
May  4 20:41:23 server approx[28108]:   Content-Type: text/plain
May  4 20:41:23 server approx[28108]:   Content-Length: 3416750
May  4 20:41:23 server approx[28108]: Connection from 192.168.1.101 port 34662
May  4 20:41:23 server approx[28108]: Request: GET 
/palemoon8/./amd64/palemoon_27.9.0%7erepack-1_amd64.deb
May  4 20:41:23 server approx[28108]:   Host: server:
May  4 20:41:23 server approx[28108]:   User-Agent: 

Bug#897947: mikutter: Twitter Consumer Key/Secret (CK/CS) suspended

[dai]

Package: mikutter
Version: 3.6.7+dfsg-1
Severity: grave

mikutter's Twitter Consumer Key/Secret (CK/CS) has been suspended since
2018/5/4 morning (JST). So mikutter cannot be authenticated by Twitter
and mikutter users cannot use Twitter by mikutter.

mikutter users can replace them with their own CK/CS by modifying code
( http://mikutter.hatenablog.com/entry/2017/11/19/202832 ),
but it is AT YOUR OWN RISK, I do not know what Twitter will do.
-- 
Regards,
dai

GPG Fingerprint = 0B29 D88E 42E6 B765 B8D8 EA50 7839 619D D439 668E


signature.asc
Description: PGP signature

Bug#897266: systemd: journalctl assertion failure

[Marc Lehmann]

On Sat, May 05, 2018 at 03:23:35AM +0200, Michael Biebl  
wrote:
> Is this problem reproducible?

Yes.

> If so, can you please install the dbgsym package for systemd/libsystemd0
> and get a backtrace from the crash [1].

Cool, I didn't know about the debug symbols repository. See below.

> Do you have persistent journal enabled?

Yes.

> What does journalctl --verify say?

A lot of pass, but also 27 FAIL and "File corruption" and similar messages
(as usual with systemd).

Example:

PASS: 
/var/log/journal/a1002e4c6eb50c7b5cdd5e004698a90b/user-65533@1614fbd80d4f42e8a21cc0a4825e4de1-00795bfa-00056a6baca9f49a.journal
12dddc8: Invalid object 
File corruption detected at 
/var/log/journal/a1002e4c6eb50c7b5cdd5e004698a90b/system@7ea033a201334367b130dd1201659ee1-0079ca96-00056a74a6a87814.journal:12dddc8
 (of 33554432 bytes, 58%).

Backtrace as follows:

(gdb) r -fu cron
Starting program: /usr/bin/journalctl -fu cron
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Assertion 'p > 0' failed at ../src/journal/journal-file.c:2280, function 
test_object_offset(). Aborting.

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x7fffefb3242a in __GI_abort () at abort.c:89
#2  0x7fffeff81a42 in log_assert_failed (text=, 
file=, line=, func=) at 
../src/basic/log.c:795
#3  0x7fffeffbe17f in test_object_offset (f=, p=, needle=) at ../src/journal/journal-file.c:2280
#4  0x7fffeffbfe13 in generic_array_bisect (f=f@entry=0x5557ad10, 
first=, first@entry=3739384, n=n@entry=2343, needle=11772088, 
test_object=0x7fffeffbe100 , 
direction=direction@entry=DIRECTION_UP, ret=0x0, offset=0x7fffdbd0, 
idx=0x0) at ../src/journal/journal-file.c:2019
#5  0x7fffeffc025c in generic_array_bisect_plus_one (f=, 
extra=, first=, n=, 
needle=, test_object=, direction=, 
ret=, offset=, idx=, 
idx=, offset=, ret=, 
direction=, test_object=, needle=, 
n=, first=, extra=, f=) at ../src/journal/journal-file.c:2251
#6  0x7fffeffc056e in journal_file_move_to_entry_by_offset_for_data 
(f=, data_offset=, p=, 
direction=, ret=, offset=) at 
../src/journal/journal-file.c:2688
#7  0x7fffefee310c in next_for_match (j=j@entry=0x55567050, 
m=m@entry=0x55569380, f=f@entry=0x5557ad10, 
after_offset=after_offset@entry=11772088, 
direction=direction@entry=DIRECTION_UP, ret=ret@entry=0x0, 
offset=0x7fffdbd0) at ../src/journal/sd-journal.c:524
#8  0x7fffefee3184 in next_for_match (j=0x55567050, m=, 
f=0x5557ad10, after_offset=11772088, direction=DIRECTION_UP, 
ret=ret@entry=0x0, offset=0x7fffdc58) at ../src/journal/sd-journal.c:534
#9  0x7fffefee31d4 in next_for_match (j=j@entry=0x55567050, 
m=m@entry=0x555692e0, f=f@entry=0x5557ad10, 
after_offset=after_offset@entry=11772088, 
direction=direction@entry=DIRECTION_UP, ret=ret@entry=0x0, 
offset=0x7fffdd88) at ../src/journal/sd-journal.c:556
#10 0x7fffefee361a in find_location_for_match (j=j@entry=0x55567050, 
m=m@entry=0x555692e0, f=f@entry=0x5557ad10, 
direction=direction@entry=DIRECTION_UP, ret=ret@entry=0x0, 
offset=offset@entry=0x7fffdd88) at ../src/journal/sd-journal.c:687
#11 0x7fffefee3758 in find_location_for_match (j=j@entry=0x55567050, 
m=m@entry=0x55569290, f=f@entry=0x5557ad10, 
direction=direction@entry=DIRECTION_UP, ret=ret@entry=0x0, 
offset=offset@entry=0x7fffde28) at ../src/journal/sd-journal.c:641
#12 0x7fffefee35d4 in find_location_for_match (j=j@entry=0x55567050, 
m=0x55569240, f=f@entry=0x5557ad10, 
direction=direction@entry=DIRECTION_UP, ret=ret@entry=0x7fffdf00, 
offset=offset@entry=0x7fffdf08) at ../src/journal/sd-journal.c:679
#13 0x7fffefee3a2a in find_location_with_matches (offset=0x7fffdf08, 
ret=0x7fffdf00, direction=DIRECTION_UP, f=0x5557ad10, j=0x55567050) 
at ../src/journal/sd-journal.c:724
#14 next_beyond_location (direction=DIRECTION_UP, f=0x5557ad10, 
j=0x55567050) at ../src/journal/sd-journal.c:784
#15 real_journal_next (j=j@entry=0x55567050, 
direction=direction@entry=DIRECTION_UP) at ../src/journal/sd-journal.c:832
#16 0x7fffefee42f6 in real_journal_next_skip (j=0x55567050, 
direction=DIRECTION_UP, skip=10) at ../src/journal/sd-journal.c:892
#17 0xba25 in main (argc=, argv=) at 
../src/journal/journalctl.c:2458

Additional info:

#4  0x7fffeffbfe13 in generic_array_bisect (f=f@entry=0x5557ad10, 
first=, first@entry=3739384, n=n@entry=2343, needle=11772088, 
test_object=0x7fffeffbe100 , 
direction=direction@entry=DIRECTION_UP, ret=0x0, offset=0x7fffdbd0, 
idx=0x0) at 

Bug#897114: ifrit FTBFS with cmake 3.11.1

[peter green]

Tags 897114 +patch
thanks

This was blocking a transition in raspbian, so I whipped up a fix. Debdiff at 
http://debdiffs.raspbian.org/main/i/ifrit/ifrit_4.1.2-5%2brpi1.debdiff , no 
intent to NMU in Debian.

The only tricky bit was that there seems to have been a typo in debian/rules, 
there was a target called override_dh_autoconfigure which I presume was a typo 
for override_dh_autoconfigure , I tried fixing said typo but that seemed to 
cause more problems than it solved, so I left it alone and added my own 
override target. You might want to consider either fixing or removing the dead 
code.

Bug#896396: python*-django-tables2: django_tables2 fails to import => usage problem???

[Joseph Herlant]

I just saw that that there was a discussin on #896429 (I was looking
at #896396).

> I wonder whether we can draw anything useful from these bugs before
> closing them.
>
> For one thing, you cannot use autopkgtest-pkg-python on these modules as is.
> So yeah, for django this may make sense, but this behaviour is still 
> unfortunate from a qa pov.
>
> I'd like to hear your opinion on this matter.

Well the one thing we could draw for that is that the django-related
packages need to have their own test suite like I'm doing for
django-tables (see
https://salsa.debian.org/python-team/modules/django-tables/tree/debian/master/debian/tests).

Joseph

Bug#897946: unrar.1: Make some typographic and formatting changes in the manual

[Bjarni Ingi Gislason]

Package: unrar
Version: 1:5.5.8-1
Severity: minor
Tags: patch

Dear Maintainer,

   * What led up to the situation?

Some warnings from "test-groff" (development version of "groff"):

:9 (macro BR): only 1 argument, but more are expected
:21 (macro BR): only 1 argument, but more are expected
:42 (macro BR): only 1 argument, but more are expected

  The patch is in the attachment.

  Summary:

  See the manual "man-pages.7" in the package "man-pages" (Debian)
about the use of bold and italic words.

Change ".BR " to ".B ..."

Protect a full stop (.) with '\&' if it begins or ends a string and does
not mean an end of a sentence.

Change '-' to '\-' if in front of an option.

Move a sentence to the next line, if only one space is in front of it.

###

DETAILS:

Input file is unrar.1

Test nr. 2:

Enable and fix warnings from 'test-groff'.

:9 (macro BR): only 1 argument, but more are expected
:21 (macro BR): only 1 argument, but more are expected
:42 (macro BR): only 1 argument, but more are expected

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

  and

Test nr. 15:

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

9:.BR unrar
21:.BR unrar
42:.BR NOTE:

#

Test nr. 8:

Protect a full stop (.) with "\&", if it has a blank (white-space) in
front of or (ignoring characters transparent to it) after it, and it
does not mean an end of a sentence.

6:.I " [- -] archive [files...] [path\...]"

#

Test nr. 24:

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

46:.B -av-
49:.B -c-
52:.B -f
55:.B -kb
58:.B -ierr
61:.B -inul
64:.B -o+
67:.B -o-
70:.B -p
73:.B -p-
76:.B -r
79:.B -u
82:.B -v
85:.B -x
88:.B -x@
91:.B -x@
94:.B -y

#

Test nr. 28:

Wrong distance between sentences or protect the indicator.

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

Or

2) Adjust space between sentences (two spaces),

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

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

43:Every switch must be separated by a whitespace. You cannot put them

#

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

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

Versions of packages unrar depends on:
ii  libc6   2.27-3
ii  libgcc1 1:8-20180425-1
ii  libstdc++6  8-20180425-1

unrar recommends no packages.

unrar suggests no packages.

-- no debconf information

-- 
Bjarni I. Gislason
--- unrar.1 2017-08-21 12:29:11.0 +
+++ unrar.1.new 2018-05-05 01:38:06.0 +
@@ -3,22 +3,23 @@
 unrar \- extract files from rar archives
 .SH SYNOPSIS
 .B unrar
-.I " [- -] archive [files...] [path\...]"
+.IR command " [" \-switch " \&...\&] " archive \
+" [" file " \&...\&] [" path " \&...\&]"
 .SH "DESCRIPTION"
 This manual page documents briefly the
-.BR unrar
+.B unrar
 command.
 .br
 This manual page was written for the Debian GNU/Linux distribution
 because the original program does not have a manual page.
 .br
 Commands and options described here are as of unrar 2.02.
-.SH OPTIONS
+.SH COMMANDS
 After the program name comes a command and then optional switches with
 dashes before them.
 A summary of commands is included below.
 For a complete description, run
-.BR unrar
+.B unrar
 without options.
 .TP
 .B e
@@ -39,59 +40,59 @@ Verbosely list archive.
 .B x
 Extract files with full path.
 .SH SWITCHES
-.BR NOTE:
-Every switch must be separated by a whitespace. You cannot put them
-together.
+.B NOTE:
+Every switch must be separated by a whitespace.
+You cannot put them together.
 .TP
-.B -av-
+.B \-av\-
 Disable Authenticity Verification check.
 .TP
-.B -c-
+.B \-c\-
 Disable comments show.
 .TP
-.B -f
+.B \-f
 Freshen files.
 .TP
-.B -kb
+.B \-kb
 Keep broken extracted files.
 .TP
-.B -ierr
+.B \-ierr
 Send all messages to stderr.
 .TP
-.B -inul
+.B \-inul
 Disable all messages.
 .TP
-.B -o+
+.B \-o+
 Overwrite existing files.
 .TP
-.B -o-
+.B \-o\-
 Do not overwrite existing files.
 .TP
-.B -p
+.BI \-p password
 Set password.
 .TP
-.B -p-
+.B \-p\-
 Do not query password.
 .TP
-.B -r
+.B \-r
 Recurse subdirectories.
 .TP
-.B -u
+.B \-u
 Update files.
 .TP
-.B -v
+.B \-v
 List all volumes.
 .TP
-.B -x
+.BI \-x file
 Exclude specified file.
 .TP
-.B -x@
+.BI \-x@ list
 Exclude files in specified list file.
 .TP
-.B -x@
+.B \-x@
 Read file names to exclude from stdin.
 .TP
-.B -y
+.B \-y
 Assume Yes on all queries.
 .SH AUTHOR
 This 

Bug#897667: qt4-x11: Please add support for new architecture "riscv64"

[Lisandro Damián Nicanor Pérez Meyer]

I was about to upload qt4 when I found:

-Q_GLOBAL_STATIC_WITH_ARGS(const QString, orgFreedesktopDBusString, 
(QLatin1String(DBUS_SERVICE_DBUS)))
+Q_GLOBAL_STATIC_WITH_ARGS(QString, orgFreedesktopDBusString, 
(QLatin1String(DBUS_SERVICE_DBUS)))

This clearly does not looks ok. Probably a mistake?

-- 
Background: talking about Nokia's aquisition of Trolltech.
 That's why there's the FreeQt agreement, a poison pill against
 just that sort of thing.
...
 mukidohime: agreements can be broken
 MoDaX: Yes, with a massive lawsuit following soon after.
 If Nokia pulled something like that, aseigo would entirely pull
 some sort of dragonball Z-esque maneuver, and it would probably
 be visible from the ISS.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#726003: udev: disks for multi-disk btrfs displayed few times in open dialog of applications

[Michael Biebl]

Control: tags -1 + moreinfo

On Fri, 11 Oct 2013 05:27:10 +0400 George Shuklin 
wrote:
> Package: udev
> Version: 204-5
> Severity: minor
> 
> Yves-Alexis Perez directed be to udev with this bug.
> 
> Bug description:
> 
> When multidisk btrfs volume is available in system, thunar (xfce filemanager) 
> display volume name many times (as many as number of disks in btrfs).
> Here small preview of thunar with 8 disk btrfs file system named 'JBOD': 
> http://s15.postimg.org/8nrgkzerf/thunar.png
> 
> Yves-Alexis response:
> 
> Actually, Thunar get the disks from udisks/udev so it might be worth
> checking what happens there, maybe those kind of disks need a
> UDISKS_IGNORE udev rule or something.


Is this still an issue on an up-to-date stretch or sid/buster system?

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#897266: systemd: journalctl assertion failure

[Michael Biebl]

Control: tags -1 + moreinfo

On Tue, 01 May 2018 05:29:49 +0200 Marc Lehmann
 wrote:
> Package: systemd
> Version: 232-25+deb9u2
> Severity: normal
> 
> Dear Maintainer,
> 
> I tried to see cron messages using:
> 
>journalctl -fu cron
> 
> but journalctl aborted with an assertion failure:
> 
>Assertion 'p > 0' failed at ../src/journal/journal-file.c:2280, function 
> test_object_offset(). Aborting.
>Aborted
>[Exit 134 (SIGABRT)]

Is this problem reproducible?
If so, can you please install the dbgsym package for systemd/libsystemd0
and get a backtrace from the crash [1].

Do you have persistent journal enabled?
What does journalctl --verify say?


[1] https://wiki.debian.org/HowToGetABacktrace
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#897070: udev: systemd-udevd exits with SIGABRT in __open_nocancel

[Michael Biebl]

Control: tags -1 + moreinfo

On Fri, 27 Apr 2018 18:06:15 -0500 Nathaniel Morck Beaver
 wrote:
> Package: udev
> Version: 232-25+deb9u3
> Severity: normal
> 
> Backtraces attached. I do not know how to reliably reproduce.
> 
> I cannot install debugging symbols because udeb-dbgsym is only available 
> for version 232-25+deb9u2, not stretch-updates version 232-25+deb9u3 
> (see policy.txt).


Unfortunately the provided backtrace is not particularly helpful.
Can you reliably reproduce the issue?
If so it would be great if you can install the dbgsym packages from
stretch-proposed-updates:

deb http://debug.mirrors.debian.org/debian-debug/
stretch-proposed-updates-debug main

and then get us another backtrace.

Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#897945: visualvm will not start since upgrade of libnb-*-java to 8.1+dfsg1-8

[Ben Caradoc-Davies]

Package: visualvm
Version: 1.3.9-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

visualvm will not start since upgrade of libnb-*-java to 8.1+dfsg1-8. It just
pauses at the splash screen for a while and then exits with code 2. strace
suggests it tries some sort of upgrade.

Workaround is to downgrade these dependencies to 8.1+dfsg1-7. These have
expired from the pool but can be found on snapshot.debian.org.

libnb-*-java dependencies:

libnb-org-openide-util-lookup-java
libnb-org-openide-util-java
libnb-org-openide-modules-java
libnb-platform18-java

Tested with OpenJDK 8, OpenJDK 9, and OpenJDK 10.

Kind regards,
Ben.



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

Kernel: Linux 4.16.0-1-amd64 (SMP w/8 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)

Versions of packages visualvm depends on:
pn  libnb-platform18-java   
ii  libvisualvm-jni 1.3.9-1
ii  openjdk-10-jdk [java7-sdk]  10.0.1+10-3
ii  openjdk-8-jdk [java7-sdk]   8u171-b11-1
ii  openjdk-9-jdk [java7-sdk]   9.0.4+12-4

visualvm recommends no packages.

visualvm suggests no packages.

-- no debconf information

Bug#897815: msgpack-c: ftbfs with GCC-8

[James McCoy]

Control: forwarded -1 https://github.com/msgpack/msgpack-c/pull/659
Control: tag -1 fixed-upstream

On Fri, May 04, 2018 at 12:22:47PM +, Matthias Klose wrote:
> [...]
>  from 
> /<>/example/cpp03/class_non_intrusive.cpp:16:
> /<>/include/msgpack/v1/object.hpp: In function 'void 
> msgpack::v1::operator<<(msgpack::v2::object&, const msgpack_object&)':
> /<>/include/msgpack/v1/object.hpp:652:34: error: 'void* 
> memcpy(void*, const void*, size_t)' copying an object of non-trivial type 
> 'struct msgpack::v2::object' from an array of 'const msgpack_object' {aka 
> 'const struct msgpack_object'} [-Werror=class-memaccess]
>  std::memcpy(, , sizeof(v));
>   ^

This was recently reported, and fixed, upstream.  I've asked them to
make a release with the fix, but if that doesn't happen soon I'll
backport the patch.

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

Bug#892304: lintian: Warn about "old" X-Python3-Version fields?

[Chris Lamb]

tags 892304 + pending
thanks

Hi Scott,

> old: =< lowest version supported in stable (for backports)
> ancient: =< lowest version supported in oldstable (for sloppy backports)

Perfect! I've implemented this in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/d1463b430e4aa71ee5f65ace237ec34bc14fc182


Regards,

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

Bug#865120: release-notes: document i386/amd64 kernel changes for jessie->stretch

[Masanori Goto]

Recently I encountered this amd64 kernel issue on my i386 architecture
machine.  I think this is useful to be mentioned. Why don't we want to
apply this proposed text?

> You're quite right, this should have been documented.  It might be
> worth mentioning linux-headers-amd64 as well.  Also, module-assistant
> doesn't support foreign architectures but DKMS is fine.

+1 to linux-headers-amd64. One tricky thing is, this is not officially
supported so module-assistant doesn't work, so that should be clearly
mentioned.  I also had some issues to install some kernel related
packages (e.g. virtualbox-dkms) so I'm not sure DKMS is fine or not -
I rather think DMKS also doesn't work but I'd like to hear your
feedback.  Should we also mention that?

Based on Justin's feedback, here's the change - who can pick up this
documentation updates?



 Users are advised that the -amd64 flavor of kernel
 is no longer provided for the i386 architecture.
 Instead, these kernels are available and installed directly from amd64
 architecture, using multiarch, the mechanism allowing the
 installation of foreign-architecture packages.



 
  
   To check if you are running i386 user space with
   amd64 kernel, run:
   dpkg --print-architecture; uname -r (would give
   i386 and a flavor ending in
   -amd64).
  
 

 
  
   To add amd64 as a foreign architecture, run:
   dpkg --add-architecture amd64; apt-get update
  
 
 
  
   (Install the appropriate kernel metapackage as described above.)
  
 



 Note that installing kernel modules are not officially supported
 through module-assistant.

Bug#897944: epiphany-browser: Crashes after editing preferences in Wayland

[John Scott]

Package: epiphany-browser
Version: 3.28.1-1
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

In specific circumstances, editing preferences and doing other
tasks in the menu will cause Epiphany to crash only in Wayland.
It is likely a problem in a library, but I've yet to narrow it
down, and I've reproduced it on both Buster and Sid.

Open Epiphany, open the Preferences, and close them again. It
will give output like the following, but still be running.

(epiphany:16845): GLib-GObject-WARNING **: 20:02:02.663: instance with invalid 
(NULL) class pointer
(epiphany:16845): GLib-GObject-CRITICAL **: 20:02:02.664: 
g_signal_emit_by_name: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed

After this, quickly opening the Preferences a second time is likely
to SIGSEGV. I've included the backtrace as epiphany-1.txt.

Epiphany crashes opening other menus, too. It took me a few tries,
but after opening Preferences once (producing the assertion failure)
and attempting to export my bookmarks, Epiphany crashes again. That
yielded a larger backtrace I've included as epiphany-2.txt.

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

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

Versions of packages epiphany-browser depends on:
ii  dbus-user-session [default-dbus-session-bus]  1.12.6-2
ii  dbus-x11 [dbus-session-bus]   1.12.6-2
ii  epiphany-browser-data 3.28.1-1
ii  gsettings-desktop-schemas 3.28.0-1
ii  iso-codes 3.79-1
ii  libc6 2.27-3
ii  libcairo2 1.15.10-3
ii  libgcr-base-3-1   3.28.0-1
ii  libgcr-ui-3-1 3.28.0-1
ii  libgdk-pixbuf2.0-02.36.11-2
ii  libglib2.0-0  2.56.1-2
ii  libgmp10  2:6.1.2+dfsg-3
ii  libgtk-3-03.22.29-3
ii  libhogweed4   3.4-1
ii  libicu57  57.1-9
ii  libjavascriptcoregtk-4.0-18   2.20.1-1
ii  libjson-glib-1.0-01.4.2-4
ii  libnettle63.4-1
ii  libnotify40.7.7-3
ii  libpango-1.0-01.42.0-1
ii  libsecret-1-0 0.18.6-1
ii  libsoup2.4-1  2.62.1-1
ii  libsqlite3-0  3.23.1-1
ii  libwebkit2gtk-4.0-37  2.20.1-1
ii  libxml2   2.9.4+dfsg1-6.1

Versions of packages epiphany-browser recommends:
ii  browser-plugin-evince  3.28.2-1
ii  ca-certificates20170717
ii  evince 3.28.2-1
ii  libwebkit2gtk-4.0-37-gtk2  2.20.1-1
ii  yelp   3.28.1-1

epiphany-browser suggests no packages.

- -- no debconf information

*** /home/john/epiphany-1.txt
#0  0x75de1bc1 in __GI___libc_free (mem=0x10040) at malloc.c:3103
#1  0x7fff89bf7e2a in reset_preedit (context=0x56e86b00) at 
../../../../../modules/input/imwayland.c:104
#2  0x70035fce in ffi_call_unix64 () at ../src/x86/unix64.S:76
#3  0x7003593f in ffi_call (cif=cif@entry=0x7fffde00, fn=, rvalue=, 
rvalue@entry=0x0, avalue=avalue@entry=0x7fffded0) at 
../src/x86/ffi64.c:525
#4  0x7fffed4d3d8b in wl_closure_invoke 
(closure=closure@entry=0x56e72ed0, flags=flags@entry=1, target=, 
target@entry=0x56ab0990, opcode=opcode@entry=1, data=) 
at ../src/connection.c:935
#5  0x7fffed4d0928 in dispatch_event (display=, 
queue=) at ../src/wayland-client.c:1310
#6  0x7fffed4d1be4 in dispatch_queue (queue=0x55797df8, 
display=0x55797d30) at ../src/wayland-client.c:1456
#7  0x7fffed4d1be4 in wl_display_dispatch_queue_pending 
(display=0x55797d30, queue=0x55797df8) at ../src/wayland-client.c:1698
#8  0x7fffed4d1c3c in wl_display_dispatch_pending (display=) 
at ../src/wayland-client.c:1761
#9  0x753955c4 in _gdk_wayland_display_queue_events (display=) at ../../../../../gdk/wayland/gdkeventsource.c:201
#10 0x75335fc0 in gdk_display_get_event 
(display=display@entry=0x5579d0e0 [GdkWaylandDisplay])
at ../../../../gdk/gdkdisplay.c:438
#11 0x753952f2 in gdk_event_source_dispatch 
(base=base@entry=0x557b7020, callback=, data=)
at ../../../../../gdk/wayland/gdkeventsource.c:120
#12 0x773d3287 in g_main_dispatch (context=0x557aa1f0) at 

Bug#896396: python*-django-tables2: django_tables2 fails to import => usage problem???

[Joseph Herlant]

Control: severity -1 minor
Control: tag -1 + moreinfo
Hi

The error message you posted seems pretty explicit: it seems you're
missing some configuration apparently:

django.core.exceptions.ImproperlyConfigured: Requested setting
DEFAULT_INDEX_TABLESPACE, but settings are not configured. You must
either define the environment variable DJANGO_SETTINGS_MODULE or call
settings.configure() before accessing settings.


If you want to understand how to use django-tables2, I encourage you to read:
https://github.com/jieter/django-tables2/blob/master/README.rst
and the tutorial:
https://django-tables2.readthedocs.io/en/latest/pages/tutorial.html
The mentioned tutorial is used in our autopkgtests too for the
upcoming version:
https://salsa.debian.org/python-team/modules/django-tables/blob/debian/master/debian/tests/test-run-py3

You must understand that this is is a django module, it's not
something to use outside of a properly configured django application.

Please let me know if you need more information.
If not, please close this bug.

Thanks
Joseph

Bug#897943: mkfs.ext4 gets stuck on getrandom() syscall

[Piotr Jurkiewicz]

Package: e2fsprogs
Version: 1.44.1-2

Trying to mkfs.ext4 from initramfs (so with klibc) inside QEMU, it gets 
stuck on getrandom syscall. Running it with strace:


uname({sysname="Linux", nodename="(none)", ...}) = 0
access("/sys/fs/ext4/features/lazy_itable_init", R_OK) = -1 ENOENT (No 
such file or directory)

openat(AT_FDCWD, "/dev/sda", O_RDONLY|O_EXCL) = 3
getuid()= 0
geteuid()   = 0
getgid()= 0
getegid()   = 0
prctl(PR_GET_DUMPABLE)  = 1 (SUID_DUMP_USER)
fstat(3, {st_mode=S_IFBLK|0600, st_rdev=makedev(8, 0), ...}) = 0
ioctl(3, BLKDISCARDZEROES, [0]) = 0
pread64(3, "\0\0\10\0\0\0 
\0\231\231\1\0q\33\37\0\365\377\7\0\0\0\0\0\2\0\0\0\2\0\0\0"..., 1024, 
1024) = 1024

close(3)= 0
access("/var/lib/e2fsprogs", W_OK)  = -1 ENOENT (No such file or 
directory)

openat(AT_FDCWD, "/dev/sda", O_RDWR|O_EXCL) = 3
getuid()= 0
geteuid()   = 0
getgid()= 0
getegid()   = 0
prctl(PR_GET_DUMPABLE)  = 1 (SUID_DUMP_USER)
fstat(3, {st_mode=S_IFBLK|0600, st_rdev=makedev(8, 0), ...}) = 0
ioctl(3, BLKDISCARDZEROES, [0]) = 0
ioctl(3, BLKROGET, [0]) = 0
uname({sysname="Linux", nodename="(none)", ...}) = 0
ioctl(3, BLKDISCARD, [0, 16777216]) = 0
write(1, "Discarding device blocks: ", 26Discarding device blocks: ) = 26
write(1, "   4096/2097152", 15   4096/2097152) = 15
write(1, "\10\10\10\10\10\10\10\10\10\10\10\1) = 150\10", 15
ioctl(3, BLKDISCARD, [16777216, 2147483648]) = 0
ioctl(3, BLKDISCARD, [2164260864, 2147483648]) = 0
ioctl(3, BLKDISCARD, [4311744512, 2147483648]) = 0
ioctl(3, BLKDISCARD, [6459228160, 2130706432]) = 0
write(1, "   ", 15   ) = 15
write(1, "\10\10\10\10\10\10\10\10\10\10\10\1) = 150\10", 15
write(1, "done"..., 33done
) = 33
pwrite64(3, 
"\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 
3072, 1024) = 3072

access("/dev/random", R_OK) = 0
getrandom(

I wasn't experiencing such a behavior one month before, but I don't know 
what caused it: kernel update from 4.15 to 4.16 or e2fsprogs update.


Workaround is to run mke2fs with explicitly specified uuid and hash seed:

mkfs.ext4 -U 08365ab2-bf18-43eb-9035-ce947f4a7565 -E hash_seed=08365a
b2-bf18-43eb-9035-ce947f4a7565 /dev/sda

I don't think mke2fs should do blocking random calls. /dev/urandom is 
present and works fine (I checked it).

Bug#897667: qt4-x11: Please add support for new architecture "riscv64"

[Manuel A. Fernandez Montecelo]

2018-05-05 1:17 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer
:
> El viernes, 4 de mayo de 2018 13:45:08 -03 Manuel A. Fernandez Montecelo
>>
>> 300 is a very low estimation/calculation, if you're using something
>> like "build-rdeps" it doesn't tell the whole picture at all, at least
>> for new ports.
> [snip explanation that rdeps != bootstrapping a new arch]
>> So in short, really, about half of Debian depends on qt4-x11 in one
>> way or another, including ironically KDE, that moved away from Qt4
>> long ago.
>
> ACK, and thanks a lot for the detailed explanation :-)

Hey, don't worry, it's also confusing for me.

Not long ago I thought that the new default method using "dose" would
print all the tree of dependencies, but although it prints a bit more
than the simple direct ones that build-depend on the package being
asked, it's not the full tree by any means.

It also surprised me that Qt4 would be so deep-rooted.  I though that
only packages depending directly on the toolkit and not ported would
be involved, and hoped to not have to deal with qt4-x11 at all for
this new port, but things turned to be otherwise :(


>> This is a chicken and egg problem though, because maintainers don't
>> want to remove support until Qt4 is really going away, and this kind
>> of migrations of "everything going together at once" is always
>> painful.  Two ones come to mind: IPv4/6 and Python2/3 :(
>
> Exactly.

As I said in the previous email and what another person wrote in
private related to this question, I think that removing it from
libffado, fcitx and phonon goes already a long way.

I also just noticed these that might be in your hand to remove soon-ish:

plasma-theme-oxygen depends upon kde-style-oxygen-qt4 (= 4:5.12.0-2)
kde-style-oxygen depends upon kde-style-oxygen-qt4
soprano-daemon depends upon libqt4-dbus (>= 4:4.5.3)

At least, when I remove libqt4* from my system, it's only libqt4* and
kde4 stuff (kamerka, katepart) , plus a few specific packages like
phonon and these 3 that I mention above.


> Given all the above I'll try to push Qt4 tonight. If in 24hs I do not get to
> do it please do no heasitate in NMUing (or waiting a little more until I or
> someone else in the team gets to it).

Don't worry, it's not that urgent, but I appreciate the effort.

Like for qtbase* in qt5, we can use "unreleased" suite, and the
buildds pick up the dependency for it.

It is a problem in the long term, thinking in months, because at some
point the packages need changes, get entangled in transitions, etc, so
the packages to "unreleased" sometimes have to be refreshed and it's a
hassle.  We have 40~80 there, while we solve problems with their
build-deps or send patches that need to be accepted, so sooner or
later some of them needs to be refreshed.

But I hope that it's not the case of Qt4, specially since it's not
supposed to change much :)


>> > By the way: in http://deb.li/qt5builds I noticed that most qt5 submodules
>> > have been built but not qtbase! How did you achieve that?
>>
>> Basically, we achieved it by disabling firebird3.0 and gdb as build
>> deps, and related packages, which are not yet ready, debdiff:
>>
>>   http://paste.debian.net/hidden/3fcebf14/
>
> gdb! That might be comming from the initial packaging and might be a leftover
> from qt4. I have already filed a bug against the source to check that, as I
> think it is not really used. See, something good might come out of all this
> after all :-)

Heh, good news :)

And don't worry really, I expect that people are reluctant to modify
packages that are obsolete long ago.

I co-maintain libsdl1.2 ones, which have the same problem, obsoleted
since 2012 but still more popular than libsdl2 :(

>> In that case we prefer to not submit these changes to you because we
>> hope to get them sorted out in a reasonable timeframe, so it would
>> mean extra work for you with little gain (to first add exceptions for
>> this arch, then remove them).
>
> Gracias for that Manuel!

De nada ;-)

I just sent a request to update symbols of kdeclarative, some packages
will need updates on the Debian side at least.

(I don't say this as a request to fast-track that change, I also added
it to "unreleased" so no rush, but I say this as an example that some
packages of Qt5/KDE5 will need modifications, even if some for some
changes we send directly upstream).


Cheers.
-- 
Manuel A. Fernandez Montecelo 

Bug#897566: freeplane freezes while entering text node under OpenJDK 10

[Ben Caradoc-Davies]

Felix,

the Freeplane process consumes 100% CPU while frozen. I have attached 
five successive jstack dumps of a single frozen process. Diffing these 
shows a lot of activity in marlin:



$ diff jstack.3.log jstack.4.log
1c1
< 2018-05-05 11:41:41
---
> 2018-05-05 11:42:14
134,140c134,140
< 	at 
sun.java2d.pipe.ShapeSpanIterator.closePath(java.desktop@10.0.1/Native 
Method)
< 	at 
sun.java2d.marlin.DRendererContext$PathConsumer2DAdapter.closePath(java.desktop@10.0.1/DRendererContext.java:240)
< 	at 
sun.java2d.marlin.DStroker.emitClose(java.desktop@10.0.1/DStroker.java:731)
< 	at 
sun.java2d.marlin.DStroker.finish(java.desktop@10.0.1/DStroker.java:667)
< 	at 
sun.java2d.marlin.DStroker.moveTo(java.desktop@10.0.1/DStroker.java:505)
< 	at 
sun.java2d.marlin.DStroker.moveTo(java.desktop@10.0.1/DStroker.java:481)

 	at 
sun.java2d.pipe.ShapeSpanIterator.lineTo(java.desktop@10.0.1/Native Method)
> 	at 
sun.java2d.marlin.DRendererContext$PathConsumer2DAdapter.lineTo(java.desktop@10.0.1/DRendererContext.java:235)
> 	at 
sun.java2d.marlin.DStroker.emitLineTo(java.desktop@10.0.1/DStroker.java:675)
> 	at 
sun.java2d.marlin.DStroker.lineTo(java.desktop@10.0.1/DStroker.java:548)
> 	at 
sun.java2d.marlin.DStroker.lineTo(java.desktop@10.0.1/DStroker.java:517)
> 	at 
sun.java2d.marlin.DDasher.emitSeg(java.desktop@10.0.1/DDasher.java:233)

>at sun.java2d.marlin.DDasher.goTo(java.desktop@10.0.1/DDasher.java:272)


$ diff jstack.4.log jstack.5.log
1c1
< 2018-05-05 11:42:14
---
> 2018-05-05 11:43:02
136,140c136,141
< 	at 
sun.java2d.marlin.DStroker.emitLineTo(java.desktop@10.0.1/DStroker.java:675)
< 	at 
sun.java2d.marlin.DStroker.lineTo(java.desktop@10.0.1/DStroker.java:548)
< 	at 
sun.java2d.marlin.DStroker.lineTo(java.desktop@10.0.1/DStroker.java:517)
< 	at 
sun.java2d.marlin.DDasher.emitSeg(java.desktop@10.0.1/DDasher.java:233)

 	at 
sun.java2d.marlin.DHelpers$PolyStack.popAll(java.desktop@10.0.1/DHelpers.java:650)
> 	at 
sun.java2d.marlin.DStroker.emitReverse(java.desktop@10.0.1/DStroker.java:615)
> 	at 
sun.java2d.marlin.DStroker.finish(java.desktop@10.0.1/DStroker.java:649)
> 	at 
sun.java2d.marlin.DStroker.moveTo(java.desktop@10.0.1/DStroker.java:505)
> 	at 
sun.java2d.marlin.DStroker.moveTo(java.desktop@10.0.1/DStroker.java:481)

>at sun.java2d.marlin.DDasher.goTo(java.desktop@10.0.1/DDasher.java:270)


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand
2018-05-05 11:38:53
Full thread dump OpenJDK 64-Bit Server VM (10.0.1+10-Debian-3 mixed mode):

Threads class SMR info:
_java_thread_list=0x7f391c000b20, length=24, elements={
0x7f39f4012000, 0x7f39f41bc000, 0x7f39f41be000, 0x7f39f41c7000,
0x7f39f41d1800, 0x7f39f41d3800, 0x7f39f41d5800, 0x7f39f41d7800,
0x7f39f41d9800, 0x7f39f4286000, 0x7f39f4295000, 0x7f39f4474800,
0x7f39f4478000, 0x7f39f451e800, 0x7f39f45ba000, 0x7f393005e800,
0x7f39305ac800, 0x7f39305ad800, 0x7f3930617000, 0x7f3930651800,
0x7f39307a2800, 0x7f39042fb800, 0x7f390402, 0x7f3978001000
}

"main" #1 prio=5 os_prio=0 tid=0x7f39f4012000 nid=0x4d6f in Object.wait()  [0x7f39fd3ea000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(java.base@10.0.1/Native Method)
	- waiting on 
	at org.knopflerfish.framework.SystemBundle.waitForStop(SystemBundle.java:252)
	- waiting to re-lock in wait() <0xe028> (a java.lang.Object)
	at org.knopflerfish.framework.Main.handleArgs(Main.java:731)
	at org.knopflerfish.framework.Main.start(Main.java:224)
	at org.knopflerfish.framework.Main.main(Main.java:156)
	at org.freeplane.launcher.Launcher.run(Launcher.java:127)
	at org.freeplane.launcher.Launcher.launch(Launcher.java:80)
	at org.freeplane.launcher.Launcher.main(Launcher.java:67)

"Reference Handler" #2 daemon prio=10 os_prio=0 tid=0x7f39f41bc000 nid=0x4d85 waiting on condition  [0x7f39a2f78000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.ref.Reference.waitForReferencePendingList(java.base@10.0.1/Native Method)
	at java.lang.ref.Reference.processPendingReferences(java.base@10.0.1/Reference.java:174)
	at java.lang.ref.Reference.access$000(java.base@10.0.1/Reference.java:44)
	at java.lang.ref.Reference$ReferenceHandler.run(java.base@10.0.1/Reference.java:138)

"Finalizer" #3 daemon prio=8 os_prio=0 tid=0x7f39f41be000 nid=0x4d86 in Object.wait()  [0x7f39a2e77000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(java.base@10.0.1/Native Method)
	- waiting on 
	at java.lang.ref.ReferenceQueue.remove(java.base@10.0.1/ReferenceQueue.java:151)
	- waiting to re-lock in wait() <0xe02d12b0> (a java.lang.ref.ReferenceQueue$Lock)
	at 

Bug#897942: Consent to use GPL-2+ required for past contributors to debian/*

[Nicholas D Steeves]

Package: yaml-mode
Version: 0.0.9-2
Severity: normal

Dear Vincent and Jari,

Thank you for your work on yaml-mode.  It made the process of learning
to write config files in yaml much less painful, and I expect to
continue to use it for the foreseeable future.

I've adopted yaml-mode under the umbrella of the Debian Emacsen Team,
and at this time I'd like to take the opportunity to modernise the
package in various ways.  Moving to machine-readable copyright-format
1.0 will require documentation of past contributors to debian/*'s
consent to license their work as GPL-2+ (preferred) or a license of
their choice.

Would you please reply to this bug, stating that you'd like your
contributions to yaml-mode/debian/* to be GPL-2+?

Sincerely,
Nicholas

Bug#892944: simple-scan: Please update to 3.28

[Jeremy Bicha]

Hi,

I saw that you updated your simple-scan packaging and uploaded to
mentors. Do you need a sponsor?

Please note that Alioth will become read-only very soon. I recommend
that you import to Salsa and update your Vcs fields now. [1]

I have several proposed packaging changes that I pushed to my
changes-from-Ubuntu branch at
https://salsa.debian.org/jbicha/simple-scan

[1] https://lists.debian.org/debian-devel-announce/2018/04/msg8.html

Thanks,
Jeremy Bicha

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

[Sean Whitton]

Hello,

On Fri, May 04 2018, Jeff Breidenbach wrote:

> Tesseract in Debian just added a build time smoke test AND Stefan
> fixed the big-endian problem. Should be live tomorrow in Sid. Assuming
> that works well, Graham should be able to re-activate the disabled
> OCRMyPDF tests. Note that this is Debian only; Ubuntu 18.04 is out the
> door so no longer pertinent.

They weren't ever deactivated in Debian.

Thank you to everyone who made this patch happen!  Great news!

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#897138: O: anacron -- cron-like program that doesn't go by time

[Sean Whitton]

Hello Peter,

On Sat, Apr 28, 2018 at 11:03:07PM +, Peter Eisentraut wrote:
> The package is no longer maintained upstream,

Oh dear :(

> and it doesn't interact well with systemd.

Could you expand/provide some bug numbers, please?  What exactly can go
wrong?

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#895816: Merge Request to upgrade to 1.0.1

[Julian Rüth]

I proposed an upgrade in this Merge Request 
https://salsa.debian.org/python-team/modules/html5lib/merge_requests/1

Unfortunately there has been no feedback yet.

Bug#897607: dbus: Please raise timeout for a few test cases (or disable) in riscv64

[Manuel A. Fernandez Montecelo]

2018-05-04 0:49 GMT+02:00 Manuel A. Fernandez Montecelo
:
> 2018-05-03 19:09 GMT+02:00 Simon McVittie :
>
>> Please could you try the build on a representative
>> riscv64 emulator with the attached hack, and send
>> the resulting debian/build-main/test/test-monitor.log and
>> debian/build-main/test/test-relay.log to this bug? If it fails, increase
>> the numbers as desired (they're an arbitrary number of minutes per
>> test-case), but either way I'd like to see the logs so that I can tell
>> how much margin of error we get.
>
> Thanks for the quick feedback, I'll try overnight.

So the build failed in other tests now.

==
ERROR: test-dbus-daemon
===
...
[many lines like these]
dbus-daemon[4174]: [session uid=1000 pid=4174] The maximum number of
pending replies for ":1.0" (uid=1000 pid=4094
comm="/<>/debian/build-debug/") has been reached
(max_replies_per_connection=128)
../../../build-aux/tap-driver.sh: line 639:  4094 Aborted "$@"
# random seed: R02Sf9146ddabfc9fd50b71fb474add3ca89
1..31
# Resetting test timeout (reference: 0x2cdcf0; factor: 1)
# ProcessID of this process is 4094
# UnixUserID of this process is 1000
# Time since timeout reset 0x2cdcf0: 1.157 seconds
ok 1 /creds
PASS: test-dbus-daemon 1 /creds
# Resetting test timeout (reference: 0x2cf1d0; factor: 1)
# GetConnectionUnixProcessID returned 4094
# Time since timeout reset 0x2cf1d0: 1.239 seconds
ok 2 /processid
PASS: test-dbus-daemon 2 /processid
# Resetting test timeout (reference: 0x2d5c50; factor: 1)
# Bug Reference: https://bugs.freedesktop.org/show_bug.cgi?id=61303
# max perf: 2000 messages / 15.252061 seconds
# Time since timeout reset 0x2d5c50: 16.087 seconds
ok 3 /unix-runtime-is-default
PASS: test-dbus-daemon 3 /unix-runtime-is-default
# Start of echo tests
# Resetting test timeout (reference: 0x2f48e0; factor: 1)
# max perf: 2000 messages / 14.492696 seconds
# Time since timeout reset 0x2f48e0: 15.351 seconds
ok 4 /echo/session
PASS: test-dbus-daemon 4 /echo/session
# Resetting test timeout (reference: 0x2aaac19cb0; factor: 1)
# Bug Reference: https://bugs.freedesktop.org/show_bug.cgi?id=34393

Bail out! Test timed out (SIGALRM received)
ERROR: test-dbus-daemon - Bail out! Test timed out (SIGALRM received)
==


==
ERROR: test-header-fields
=

../../../build-aux/tap-driver.sh: line 639:  4249 Aborted "$@"
# random seed: R02S1ae01519f2b8fdb3e66f5e49563999ed
1..5
# Start of message tests
# Start of weird-header-field tests
# Resetting test timeout (reference: 0x2cb070; factor: 1)
# Running "/message/weird-header-field/none" once to count mallocs
# "/message/weird-header-field/none" has about 604 mallocs in total
# testing "/message/weird-header-field/none" with up to 2 consecutive
malloc failures
# testing "/message/weird-header-field/none" with 2 consecutive malloc failures
# Time since timeout reset 0x2cb070: 41.593 seconds
ok 1 /message/weird-header-field/none
PASS: test-header-fields 1 /message/weird-header-field/none
# Resetting test timeout (reference: 0x2e5910; factor: 1)
# Running "/message/weird-header-field/append" once to count mallocs
# "/message/weird-header-field/append" has about 617 mallocs in total
# testing "/message/weird-header-field/append" with up to 2
consecutive malloc failures
# testing "/message/weird-header-field/append" with 2 consecutive
malloc failures
# Time since timeout reset 0x2e5910: 47.164 seconds
ok 2 /message/weird-header-field/append
PASS: test-header-fields 2 /message/weird-header-field/append
# Resetting test timeout (reference: 0x2cbf40; factor: 1)
# Running "/message/weird-header-field/change" once to count mallocs
# "/message/weird-header-field/change" has about 612 mallocs in total
# testing "/message/weird-header-field/change" with up to 2
consecutive malloc failures
# testing "/message/weird-header-field/change" with 2 consecutive
malloc failures

Bail out! Test timed out (SIGALRM received)
ERROR: test-header-fields - Bail out! Test timed out (SIGALRM received)
==


The log files of the previous ones that failed:

test-relay.log
===
# random seed: R02S48976acf87ad7a1d71e0cada0537b918
1..3
# Resetting test timeout (reference: 0x2c5760; factor: 10)
# Time since timeout reset 0x2c5760: 0.036 seconds
ok 1 /connect
PASS: test-relay 1 /connect
# Resetting test timeout (reference: 0x2c8d40; factor: 10)
# Time since timeout reset 0x2c8d40: 0.944 seconds
ok 2 /relay
PASS: test-relay 2 /relay
# Resetting test timeout (reference: 0x2c77b0; factor: 10)
# Bug Reference: https://bugs.freedesktop.org/show_bug.cgi?id=34393
# 

Bug#826890: closed by Jérémy Lal <kapo...@melix.org> (Bug#826890: fixed in nodejs 10.0.0~dfsg1-3)

[Thorsten Glaser]

reopen 826890
thanks

Hello Jérémy,

> + Multi-Arch: same on lib/dev packages (Closes: #826890)

this bugreport is about M-A:foreign on the nodejs binary package
(so I can use arch:all stuff like node-uglify which Depends on
nodejs, with a foreign-architecture nodejs).

M-A:same on lib/dev packages is also useful in general, and part
of the M-A release goal, but not enough in the scope of this issue.

bye,
//mirabilos
-- 
  "Using Lynx is like wearing a really good pair of shades: cuts out
   the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL."
 -- Henry Nelson, March 1999

Bug#897566: freeplane freezes while entering text node under OpenJDK 10

[Ben Caradoc-Davies]

On 04/05/18 06:09, Felix Natter wrote:

hello Ben,
thank you for the report. Could you please provide a sample map (without
confidential information ;-)) and instructions for reproducing (insert
child anywhere + type two letters?)
Also, is there anything suspicious in the log
(~/.config/freeplane/1.6.x/logs/log.0 or start from console)?
Thanks and Best Regards,


Felix,

please find attached a sample map test.mm. To reproduce, hover over the 
smaller (blue) Test node, press Insert to insert a new node, and start 
typing "Test". With OpenJDK 10, Freeplane hangs most of the time after 
typing "Te".


I have also attached the console and log.0 logs, and an OpenJDK 8 
console log for comparison (but I did not see any substantive differences).


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand















































































































org.knopflerfish.framework.readonly=true
org.knopflerfish.gosg.jars=reference:file:/usr/share/freeplane/core/
org.freeplane.user.dir=/home/ben/tmp/freeplane
org.freeplane.basedirectory=/usr/share/freeplane
java.security.policy=/usr/share/freeplane/freeplane.policy
org.osgi.framework.storage=/usr/share/freeplane/fwdir
Knopflerfish OSGi framework launcher, version 
Copyright 2003-2018 Knopflerfish. All Rights Reserved.
See http://www.knopflerfish.org for more information.

Created Framework: org.knopflerfish.framework, version=8.0.5.
Installed: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.latex (id#2)
Installed: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.script (id#3)
Installed: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.jsyntaxpane (id#4)
Installed: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.formula (id#5)
Installed: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.svg (id#6)
Installed: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.openmaps (id#7)
Installed: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.bugreport (id#8)
Started: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.latex (id#2)
Started: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.script (id#3)
Started: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.jsyntaxpane (id#4)
Started: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.formula (id#5)
Started: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.svg (id#6)
Started: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.openmaps (id#7)
Started: reference:file:/usr/share/freeplane/plugins/org.freeplane.plugin.bugreport (id#8)
May 05, 2018 11:15:13 AM org.freeplane.core.util.LogUtils info
INFO: language resources for en found
May 05, 2018 11:15:13 AM org.freeplane.core.util.LogUtils info
INFO: freeplane_version = 1.6.13; freeplane_xml_version = freeplane 1.6.0
git revision = 43c1334c1a7165c5bd0a8160033be57335ec80b8 Dimitry Polivaev 2018-02-04T18:40:26Z
java_version = 1.8.0_171; os_name = Linux; os_version = 4.16.0-1-amd64

STDERR: Error parsing gtk-icon-sizes string: ''May 05, 2018 11:15:14 AM org.freeplane.core.util.LogUtils info
INFO: added parsing support for standard date format dd/MM/yy
May 05, 2018 11:15:14 AM org.freeplane.core.util.LogUtils info
INFO: added parsing support for standard date time format dd/MM/yy HH:mm
May 05, 2018 11:15:14 AM org.freeplane.core.util.LogUtils info
INFO: available locales not found
May 05, 2018 11:15:14 AM org.freeplane.core.util.LogUtils info
INFO: available locales not found
May 05, 2018 11:15:15 AM org.freeplane.core.util.LogUtils info
INFO: extending script's classpath by [/home/ben/.config/freeplane/1.6.x/lib]
May 05, 2018 11:15:15 AM org.freeplane.core.util.LogUtils info
INFO: Loaded properties from bundle://3:1/org/freeplane/plugin/script/defaults.properties
May 05, 2018 11:15:15 AM org.freeplane.core.util.LogUtils info
INFO: looking for scripts with the following endings: [js, groovy]
May 05, 2018 11:15:15 AM org.freeplane.core.util.LogUtils info
INFO: Loaded properties from bundle://5:1/org/freeplane/plugin/formula/defaults.properties

STDOUT: Framework launchedMay 05, 2018 11:15:16 AM org.freeplane.core.util.LogUtils info
INFO: requesting mode: MindMap
May 05, 2018 11:15:17 AM org.freeplane.core.util.LogUtils info
INFO: menu items to execute: []
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.freeplane.launcher.Launcher (file:/usr/share/freeplane/freeplanelauncher.jar) to field sun.awt.X11.XToolkit.awtAppClassName
WARNING: Please consider reporting this to the maintainers of org.freeplane.launcher.Launcher
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

Bug#897941: kactivities-kf5: Please update symbols for riscv64

[Manuel A. Fernandez Montecelo]

Source: kactivities-kf5
Version: 5.42.0-2
Severity: normal
Tags: patch
User: debian-ri...@lists.debian.org
Usertags: riscv64

Hello,

We need support in this package for the riscv64 architecture.

I am attaching a patch that adds support for the architecture, just symbols
update, and that just built successfully.

It would be great if you could include these changes and release a new version
for unstable, at the moment it lives in "unreleased".


Thanks and cheers.
--
Manuel A. Fernandez Montecelo 
# SymbolsHelper-Confirmed: 5.25.0 amd64
libKF5Activities.so.5 libkf5activities5 #MINVER#
 _ZN11KActivities10Controller11addActivityERK7QString@Base 4.96.0
 _ZN11KActivities10Controller11qt_metacallEN11QMetaObject4CallEiPPv@Base 4.96.0
 _ZN11KActivities10Controller11qt_metacastEPKc@Base 4.96.0
 _ZN11KActivities10Controller12stopActivityERK7QString@Base 4.96.0
 _ZN11KActivities10Controller13startActivityERK7QString@Base 4.96.0
 _ZN11KActivities10Controller14removeActivityERK7QString@Base 4.96.0
 _ZN11KActivities10Controller15setActivityIconERK7QStringS3_@Base 4.96.0
 _ZN11KActivities10Controller15setActivityNameERK7QStringS3_@Base 4.96.0
 _ZN11KActivities10Controller16staticMetaObjectE@Base 4.96.0
 _ZN11KActivities10Controller18setCurrentActivityERK7QString@Base 4.96.0
 _ZN11KActivities10Controller22setActivityDescriptionERK7QStringS3_@Base 5.16.0
 _ZN11KActivities10ControllerC1EP7QObject@Base 4.96.0
 _ZN11KActivities10ControllerC2EP7QObject@Base 4.96.0
 _ZN11KActivities10ControllerD0Ev@Base 4.96.0
 _ZN11KActivities10ControllerD1Ev@Base 4.96.0
 _ZN11KActivities10ControllerD2Ev@Base 4.96.0
 _ZN11KActivities12versionMajorEv@Base 4.96.0
 _ZN11KActivities12versionMinorEv@Base 4.96.0
 _ZN11KActivities13versionStringEv@Base 4.96.0
 _ZN11KActivities14versionReleaseEv@Base 4.96.0
 _ZN11KActivities15ActivitiesModel11qt_metacallEN11QMetaObject4CallEiPPv@Base 
5.21.0
 _ZN11KActivities15ActivitiesModel11qt_metacastEPKc@Base 5.21.0
 
_ZN11KActivities15ActivitiesModel14setShownStatesERK7QVectorINS_4Info5StateEE@Base
 5.21.0
 _ZN11KActivities15ActivitiesModel16staticMetaObjectE@Base 5.21.0
 
_ZN11KActivities15ActivitiesModel18shownStatesChangedERK7QVectorINS_4Info5StateEE@Base
 5.21.0
 _ZN11KActivities15ActivitiesModelC1E7QVectorINS_4Info5StateEEP7QObject@Base 
5.21.0
 _ZN11KActivities15ActivitiesModelC1EP7QObject@Base 5.21.0
 _ZN11KActivities15ActivitiesModelC2E7QVectorINS_4Info5StateEEP7QObject@Base 
5.21.0
 _ZN11KActivities15ActivitiesModelC2EP7QObject@Base 5.21.0
 _ZN11KActivities15ActivitiesModelD0Ev@Base 5.21.0
 _ZN11KActivities15ActivitiesModelD1Ev@Base 5.21.0
 _ZN11KActivities15ActivitiesModelD2Ev@Base 5.21.0
 _ZN11KActivities16ResourceInstance11qt_metacallEN11QMetaObject4CallEiPPv@Base 
4.96.0
 _ZN11KActivities16ResourceInstance11qt_metacastEPKc@Base 4.96.0
 _ZN11KActivities16ResourceInstance11setMimetypeERK7QString@Base 4.96.0
 _ZN11KActivities16ResourceInstance13requestsFocusEv@Base 4.96.0
 _ZN11KActivities16ResourceInstance14notifyAccessedERK4QUrlRK7QString@Base 
4.96.0
 _ZN11KActivities16ResourceInstance14notifyModifiedEv@Base 4.96.0
 _ZN11KActivities16ResourceInstance15notifyFocusedInEv@Base 4.96.0
 _ZN11KActivities16ResourceInstance16notifyFocusedOutEv@Base 4.96.0
 _ZN11KActivities16ResourceInstance16staticMetaObjectE@Base 4.96.0
 _ZN11KActivities16ResourceInstance6setUriERK4QUrl@Base 4.96.0
 _ZN11KActivities16ResourceInstance8setTitleERK7QString@Base 4.96.0
 
(subst)_ZN11KActivities16ResourceInstanceC1E{quintptr}4QUrlRK7QStringS4_S4_P7QObject@Base
 4.96.0
 (subst)_ZN11KActivities16ResourceInstanceC1E{quintptr}P7QObject@Base 4.96.0
 (subst)_ZN11KActivities16ResourceInstanceC1E{quintptr}RK7QStringP7QObject@Base 
4.96.0
 
(subst)_ZN11KActivities16ResourceInstanceC2E{quintptr}4QUrlRK7QStringS4_S4_P7QObject@Base
 4.96.0
 (subst)_ZN11KActivities16ResourceInstanceC2E{quintptr}P7QObject@Base 4.96.0
 (subst)_ZN11KActivities16ResourceInstanceC2E{quintptr}RK7QStringP7QObject@Base 
4.96.0
 _ZN11KActivities16ResourceInstanceD0Ev@Base 4.96.0
 _ZN11KActivities16ResourceInstanceD1Ev@Base 4.96.0
 _ZN11KActivities16ResourceInstanceD2Ev@Base 4.96.0
 _ZN11KActivities4Info11iconChangedERK7QString@Base 4.96.0
 _ZN11KActivities4Info11infoChangedEv@Base 4.96.0
 _ZN11KActivities4Info11nameChangedERK7QString@Base 4.96.0
 _ZN11KActivities4Info11qt_metacallEN11QMetaObject4CallEiPPv@Base 4.96.0
 _ZN11KActivities4Info11qt_metacastEPKc@Base 4.96.0
 _ZN11KActivities4Info12stateChangedENS0_5StateE@Base 4.96.0
 _ZN11KActivities4Info16isCurrentChangedEb@Base 5.25.0
 _ZN11KActivities4Info16staticMetaObjectE@Base 4.96.0
 _ZN11KActivities4Info18descriptionChangedERK7QString@Base 5.16.0
 _ZN11KActivities4Info5addedEv@Base 4.96.0
 _ZN11KActivities4Info7removedEv@Base 4.96.0
 _ZN11KActivities4Info7startedEv@Base 4.96.0
 _ZN11KActivities4Info7stoppedEv@Base 4.96.0
 _ZN11KActivities4InfoC1ERK7QStringP7QObject@Base 4.96.0
 _ZN11KActivities4InfoC2ERK7QStringP7QObject@Base 4.96.0
 _ZN11KActivities4InfoD0Ev@Base 4.96.0
 

Bug#897939: network-manager-strongswan: clean up legacy conffiles

[Christoph Anton Mitterer]

btw: I'd guess it's not just enough to clean up the conffile itself
with the appropriate tools, but one likely needs to manually rmdir:
/etc/NetworkManager/VPN
as this is neither a conffile (as it's a dir) nor owned by any other
package (at least on my system)... so dpkg will not remember about it
and it would remain forever.

Chris.

Bug#897667: qt4-x11: Please add support for new architecture "riscv64"

[Lisandro Damián Nicanor Pérez Meyer]

El viernes, 4 de mayo de 2018 13:45:08 -03 Manuel A. Fernandez Montecelo 
escribió:
> Hola!
> 
> 2018-05-04 12:47 GMT+02:00 Lisandro Damián Nicanor Pérez Meyer
> 
> :
> > ¡Hola Manuel!
> > 
> >> We need support in this package to bootstrap the riscv64 architecture.
> >> 
> >> Yes, I know that you want to get rid of Qt4 once and for all and ASAP,
> >> and I fully agree with the goal.  However, a bazillion of packages
> >> depend on qt4-x11 indirectly,
> > 
> > A little less than 300 source packages.
> 
> 300 is a very low estimation/calculation, if you're using something
> like "build-rdeps" it doesn't tell the whole picture at all, at least
> for new ports.
[snip explanation that rdeps != bootstrapping a new arch] 
> So in short, really, about half of Debian depends on qt4-x11 in one
> way or another, including ironically KDE, that moved away from Qt4
> long ago.

ACK, and thanks a lot for the detailed explanation :-)

[snip]


> This is a chicken and egg problem though, because maintainers don't
> want to remove support until Qt4 is really going away, and this kind
> of migrations of "everything going together at once" is always
> painful.  Two ones come to mind: IPv4/6 and Python2/3 :(

Exactly.

Given all the above I'll try to push Qt4 tonight. If in 24hs I do not get to 
do it please do no heasitate in NMUing (or waiting a little more until I or 
someone else in the team gets to it).
 
> > By the way: in http://deb.li/qt5builds I noticed that most qt5 submodules
> > have been built but not qtbase! How did you achieve that?
> 
> Basically, we achieved it by disabling firebird3.0 and gdb as build
> deps, and related packages, which are not yet ready, debdiff:
> 
>   http://paste.debian.net/hidden/3fcebf14/

gdb! That might be comming from the initial packaging and might be a leftover 
from qt4. I have already filed a bug against the source to check that, as I 
think it is not really used. See, something good might come out of all this 
after all :-)


> I submitted a bug for firebird3.0, but still couldn't get it to build
> cleanly; and gdb still needs the port of RISC-V merged and then that
> version uploading to Debian.
> 
> Similar to qt4-x11, a version of qtbase is living in "unreleased".
> 
> In that case we prefer to not submit these changes to you because we
> hope to get them sorted out in a reasonable timeframe, so it would
> mean extra work for you with little gain (to first add exceptions for
> this arch, then remove them).

Gracias for that Manuel!



-- 
¿Qué vamos a hacer esta noche Cerebro?
-Lo mismo que todas las noches Pinky...
¡¡¡tratar de conquistar el mundo!!!
  Pinky y Cerebro. Narf.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


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

Bug#897940: qtbase-opensource-src: Check if we really need gdb as a B-D

[Lisandro Damián Nicanor Pérez Meyer]

Source: qtbase-opensource-src
Version: 5.10.1+dfsg-6
Severity: normal

qtbase currently build depends upon gdb. Check wether this is till needed.

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

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

Bug#897794: How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)

[Mattia Rizzolo]

On Sat, May 05, 2018 at 12:45:08AM +0200, Svante Signell wrote:
> But why log symbols at all? It
> seems to be very much not needed. If so tell me why it is!

Mainly I see two reasons:
 1. being able to use properly versioned dependencies on the library
 2. have a safety net against what are imho the most common ABI breaks

1: without symbols file you should take care of properly bumping the
shlibs version whenever you introduce a new symbols: in that case either
you don't know you are adding a new symbol, and so you won't bump the
shlibs version and you are going end up with a broken dependency (just
most of the times you are not going to notice it because just out of
luck you get a new enough version of the shared lib together of the
binary requiring the new symbol), or you use -V and force an overly
strict versioned dependency.  Please read:
 - dpkg-gensymbols(1)
 - dpkg-shlibdeps(1)
 - deb-shlibs(5)
 - deb-symbols(5)
 - dh_makeshlibs(1)
2: you'll notice ABI breaks whenever an under-diligent upstream drops a
public method —so dropping also the symbol— without changing SONAME


I personally find the second one particularly interesting: the amount of
upstreams who develop a library with the goal of providing a shared
library but nonetheless won't pose much interest and attention in proper
ABI (in particular symbols) handling is astonishing.
ABI breaks are awful to handle after they land in unstable, catching one
before can save the maintainer, release team and all the rdeps *a lot*
of otherwise wasted time and headaches.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#897689: python3-cclib: overly generic python module name: /usr/lib/python3/dist-packages/scripts/__init__.py

[Daniel Leidert]

Am Freitag, den 04.05.2018, 12:59 +0200 schrieb Andreas Beckmann:

> during a test with piuparts I noticed your package uses a very generic
> python module name that now clashes with other packages:
> 
> /usr/lib/python3/dist-packages/scripts/__init__.py

Thanks for the hint. I agree, that this needs to be changed, and
already informed upstream about it. However, there is currently only
one clash, so I will wait for a new upstream release.

Regards, Daniel

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

Bug#897939: network-manager-strongswan: clean up legacy conffiles

[Christoph Anton Mitterer]

Package: network-manager-strongswan
Version: 1.4.3-2
Severity: normal


Hi.

Apparently, the package used to contain 
/etc/NetworkManager/VPN/nm-strongswan-service.name
but no longer does.

So on upgrade the file isn't properly removed via the maintainer script helpers 
and remains
and the following error occurs as well:
dpkg: warning: unable to delete old directory '/etc/NetworkManager/VPN': 
Directory not empty
(Reading database ... 502817 files and directories currently installed.)


Please remove the config properly in an upcoming version.

Cheers,
Chris.


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

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

Versions of packages network-manager-strongswan depends on:
ii  libatk1.0-0  2.28.1-1
ii  libc62.27-3
ii  libcairo-gobject21.15.10-3
ii  libcairo21.15.10-3
ii  libfribidi0  0.19.7-2
ii  libgdk-pixbuf2.0-0   2.36.11-2
ii  libglib2.0-0 2.56.1-2
ii  libgtk-3-0   3.22.30-1
ii  libnm0   1.10.6-3
ii  libnma0  1.8.10-5
ii  libpango-1.0-0   1.42.1-1
ii  libpangocairo-1.0-0  1.42.1-1
ii  libsecret-1-00.18.6-2
ii  network-manager  1.10.6-3
ii  strongswan-nm5.6.2-2

network-manager-strongswan recommends no packages.

network-manager-strongswan suggests no packages.

-- no debconf information

Bug#897938: systemd-sysv: shutdown ignores --no-wall while canceling a pending shutdown

[Chris Soyars]

Package: systemd-sysv
Version: 232-25+deb9u3
Severity: normal

Dear Maintainer,

Executing /sbin/shutdown --no-wall -c sends a broadcast message.  I would 
expect the broadcast message to be skipped when passing --no-wall.

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

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

Versions of packages systemd-sysv depends on:
ii  systemd  232-25+deb9u3

systemd-sysv recommends no packages.

systemd-sysv suggests no packages.

-- no debconf information

Bug#897794: How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)

[Svante Signell]

On Fri, 2018-05-04 at 23:16 +0200, Mattia Rizzolo wrote:
> Yavor,
> 
> On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote:
> > Andreas Tille wrote:
> > > What's the correct way to fix the symbols file to work with both
> > > versions of gcc?

> Guess what, C++ is more complex than C.

Sorry for being uniformed/not knowing: But why log symbols at all? It
seems to be very much not needed. If so tell me why it is!

Bug#897937: debhelper: handle whitespace before debhelper-compat B-D

[Peter Pentchev]

Package: debhelper
Version: 11.2.1
Severity: minor
Tags: patch

Hi,

Thanks for maintaining and extending debhelper!

When trying to test the new B-D: debhelper-compat (= 11) mechanism on
my mdk and mdk-doc packages, I stumbled upon a minor issue: if this
dependency is the first one listed, and it's on a separate line (there
are no package names on the "Build-Depends:" line itself), then it is
not recognized because the regular expression used will not match
the whitespace before the "debhelper-compat" token.

Attached is a trivial patch.  Well, actually the trivial patch is in
the second commit; the first one adds some debhelper-compat tests and
the third one adds a test for the bug fixed by the second one.
Of course, if you feel that adding test-only functions to the Dh_Lib
module is not really proper, it's your call whether to accept just
the fix itself without the tests.

Thanks again for taking care of debhelper!

Best regards,
Peter

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

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

Versions of packages debhelper depends on:
ii  autotools-dev20180224.1
ii  dh-autoreconf17
ii  dh-strip-nondeterminism  0.041-1
ii  dpkg 1.19.0.5
ii  dpkg-dev 1.19.0.5
ii  file 1:5.32-2
ii  libdpkg-perl 1.19.0.5
ii  man-db   2.8.3-2
ii  perl 5.26.2-3
ii  po-debconf   1.0.20

debhelper recommends no packages.

Versions of packages debhelper suggests:
ii  dh-make  2.201701
pn  dwz  

-- no debconf information
From 4680d18a5125ce6a46afa846e9b4866df0ce7a72 Mon Sep 17 00:00:00 2001
From: Peter Pentchev 
Date: Fri, 4 May 2018 23:59:04 +0300
Subject: [PATCH 1/3] Lay the groundwork for testing debhelper-compat.

Move the enumeration of the supported compat levels from gen-provides to
the Dh_Lib module's compat_levels() function.
Add the resetcompat() and resetpackages() testing aids to Dh_Lib.
Silence the "debhelper-compat is experimental" warning during testing.
Add the debhelper-compat/syntax.t test.
---
 debian/gen-provides   |  6 +--
 lib/Debian/Debhelper/Dh_Lib.pm| 28 ++-
 t/debhelper-compat/debian/control | 12 +
 t/debhelper-compat/syntax.t   | 78 +++
 4 files changed, 117 insertions(+), 7 deletions(-)
 create mode 100644 t/debhelper-compat/debian/control
 create mode 100755 t/debhelper-compat/syntax.t

diff --git a/debian/gen-provides b/debian/gen-provides
index 5efd5a98..714401f1 100644
--- a/debian/gen-provides
+++ b/debian/gen-provides
@@ -2,14 +2,10 @@
 
 use strict;
 use warnings;
-use Debian::Debhelper::Dh_Version;
 use Debian::Debhelper::Dh_Lib ();
 
 my @provides;
-my $version = $Debian::Debhelper::Dh_Version::version;
-$version =~ s/~.*//; # Drop backports marker
-$version =~ s/^\d+\K\..*//;
-for (my $i = Debian::Debhelper::Dh_Lib::LOWEST_NON_DEPRECATED_COMPAT_LEVEL ; 
$i <= $version ; $i++) {
+for my $i (Debian::Debhelper::Dh_Lib::compat_levels) {
 push(@provides, "debhelper-compat (= $i)");
 }
 print "dh:CompatLevels=" . join(", ", @provides) . "\n";
diff --git a/lib/Debian/Debhelper/Dh_Lib.pm b/lib/Debian/Debhelper/Dh_Lib.pm
index 9c829f0f..9666b7ad 100644
--- a/lib/Debian/Debhelper/Dh_Lib.pm
+++ b/lib/Debian/Debhelper/Dh_Lib.pm
@@ -63,7 +63,7 @@ our (@EXPORT, %dh);
_doc_main_package _so_or_exec_elf_file 
_opt_is_known_package _tmpdir _hardlinks
_use_root _root_cmd DEFAULT_PACKAGE_TYPE
-   DBGSYM_PACKAGE_TYPE
+   DBGSYM_PACKAGE_TYPE _levels  
 );
 
 # The Makefile changes this if debhelper is installed in a PREFIX.
@@ -691,6 +691,12 @@ my $compat_from_bd;
my $warned_compat = $ENV{DH_INTERNAL_TESTSUITE_SILENT_WARNINGS} ? 1 : 0;
my $c;
 
+   # Used mainly for testing
+   sub resetcompat {
+   undef $c;
+   undef $compat_from_bd;
+   }
+
sub compat {
my $num=shift;
my $nowarn=shift;
@@ -1388,6 +1394,13 @@ sub is_cross_compiling {
 my (%package_types, %package_arches, %package_multiarches, %packages_by_type,
 %package_sections, $sourcepackage, %package_cross_type);
 
+# Resets the arrays; used mostly for testing
+sub resetpackages {
+   undef $sourcepackage;
+   %package_types = %package_arches = %package_multiarches =
+   %packages_by_type = %package_sections = %package_cross_type = ();
+}
+
 # Returns source package name
 sub sourcepackage {
getpackages() if not defined($sourcepackage);
@@ -1489,7 +1502,7 @@ sub getpackages {
}
  

Bug#897936: libvirt-daemon-system should not depend on policykit-1

[Ian Jackson]

Package: libvirt-daemon-system
Version: 3.0.0-4+deb9u2

Depends: ..., policykit-1

It works just fine without policykit-1.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#897934: bugs.d.o: don't inform maintainers about bugs in bpo versions if bpo-uploader not listed in maintainers or uploaders

[Holger Levsen]

On Fri, May 04, 2018 at 10:23:58PM +, Holger Levsen wrote:
> I've just checked and there's no bug against bugs.d.o with "backports"
> in it's title, thus filing one:

there are though, 

#397761 - bugs.debian.org: please forward bug reports to Uploaders also
#775797 - bugs.debian.org: BTS doesn't know about BPO versions; breaks 
apt-listbugs

and while I agree that the wontfix status of #397761 should be reconsidered,
this doesn't matter (or only makes it easier) for this bug, #897934 ;)


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#897935: libmath-mpfr-perl: mpfr_out_str and mpfr_inp_str are called on NULL

[Vincent Lefevre]

Package: libmath-mpfr-perl
Version: 4.03-1
Severity: normal
Tags: upstream fixed-upstream

mpfr_out_str and mpfr_inp_str are called on NULL, which is based
on a bug in the current MPFR version. This is fixed in git for
the coming Math::MPFR 4.04.

https://github.com/sisyphus/math-mpfr/commit/54e2485b8217861241961120c3518ce05154f941

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

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

Versions of packages libmath-mpfr-perl depends on:
ii  libc6   2.27-3
ii  libgmp102:6.1.2+dfsg-3
ii  libmpfr64.0.1-1
ii  libquadmath08.1.0-1
ii  perl5.26.2-3
ii  perl-base [perlapi-5.26.1]  5.26.2-3

libmath-mpfr-perl recommends no packages.

libmath-mpfr-perl suggests no packages.

-- no debconf information

Bug#897934: bugs.d.o: don't inform maintainers about bugs in bpo versions if bpo-uploader not listed in maintainers or uploaders

[Holger Levsen]

package: bugs.debian.org
severity: wishlist
x-debbugs-cc: debian-backpo...@lists.debian.org

hi bugs.d.o maintainers,

this thread (which now became this bug) started with wondering why bugs
in packages in $suite-backports should not be reported to the BTS. 

See message-ID <20180504210620.ga26...@gpm.stappers.nl> and follow-ups on
the backports list, it's a short thread :)

https://lists.debian.org/20180504210620.ga26...@gpm.stappers.nl for those
reading this online.

On Sat, May 05, 2018 at 12:08:32AM +0200, Alexander Wirt wrote:
> On Fri, 04 May 2018, Holger Levsen wrote:
> > On Fri, May 04, 2018 at 11:58:53PM +0200, Alexander Wirt wrote:
> > > This should either be part of the debian policy or being decided by the 
> > > GR.
> > > We/I decided that once, several years ago (after we got official) and
> > > received a lot complaints afterwards. We reverted the decision then until
> > > there is better support in the BTS.  
> > thanks for explaining. What's lacking in the BTS, version tracking is
> > not enough because? (& is there a bug about it, else we can maybe turn
> > this thread into one.)
> Several maintainers didn't wanted to receive reports for backports they don't
> maintain. I don't know if a bug exists about it. 

I've just checked and there's no bug against bugs.d.o with "backports"
in it's title, thus filing one:

bugs.d.o should not inform maintainers about bugs in bpo versions if the 
bpo-uploader is not listed in maintainers or uploaders. It should
however mail that uploader.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Bug#897933: libguestfs0 excessive dependencies

[Ian Jackson]

Package: libguestfs0
Version: 1:1.34.6-2

Depends: libacl1 (>= 2.2.51-8), libaugeas0 (>= 1.0.0), libc6 (>=
 2.17), libcap2 (>= 1:2.10), libfuse2 (>= 2.8), libhivex0 (>=
 1.2.2+git20100712), libmagic1 (>= 5.12), libpcre3, libselinux1 (>=
 1.32), libsystemd0, libtsk13 (>= 4.2.0), libvirt0 (>= 0.9.4~rc1),
 libxml2 (>= 2.8.0), libyajl2 (>= 2.0.4), supermin (>= 5),
 qemu-system-x86, sgabios, db-util, icoutils, netpbm, osinfo-db, acl,
 attr, binutils, bsdmainutils, btrfs-progs, btrfs-tools, bzip2, cpio,
 cryptsetup, curl, diffutils, dosfstools, extlinux, file, gawk, gdisk,
 genisoimage, grub2-common, iproute2 | iproute, isc-dhcp-client, kmod |
 module-init-tools, ldmtool, less, lsscsi, lvm2, lzop, mdadm, mtools,
 ntfs-3g, openssh-client, parted, procps, psmisc, qemu-utils, scrub,
 sleuthkit, syslinux, systemd | sysvinit, udev, xz-utils, zerofree

I can't imagine that libguestfs is completely broken without all of
that lot.  In fact, it can be loaded into programs which do not use
libguestfs facilities without any of them.

I suggest that everything which is not a library be removed.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#897932: libguestfs0 dependency on systemd | sysvinit is wrong

[Ian Jackson]

Package: libguestfs0
Version: 1:1.34.6-2

In stretch the sysvinit package is not called `sysvinit'; there is
`sysvinit-core' etc.  It's not clear what this dependency is for, but
I suspect it should be to `sysvinit-core' if it should exist at all.

But really, does libguestfs not work with runit or openrc or
whatever ?  I suspect this dependency should simply be dropped.

Ian.

-- 
Ian Jackson    These opinions are my own.

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

Bug#895736: Should Gnash be removed?

[Moritz Mühlenhoff]

retitle 895736 RM: gnash - unmaintained, deprecated, RC-buggy, depends on 
legacy libs
reassign 895736 ftp.debian.org
severity 895736 normal
thanks

On Sun, Apr 15, 2018 at 12:43:52PM +0200, Moritz Muehlenhoff wrote:
> Source: gnash
> Severity: important
> 
> Should Gnash be removed?
> 
> - Doesn't have any active uploaders any more
> - Upstream seems mostly dead, last commits over a year ago
> - Mozilla plugin broken as of Firefox 57 (so soon also for firefox-esr)
>  (Konqeror plugin seems broken for longer even according to #655839 and 
> #549669
> - Incompatible with upcoming ffmpeg 4.0 (888337)
> - Blocks mtasc removal (831549)
> - Uses legacy libs (874890, 885374)
> 
> Unless anyone steps forward and takes up maintenance, I'll file a removal
> bug in the next weeks.

No objections in three weeks, reassigning for removal.

Cheers,
Moritz
 

Bug#897931: preseed: add tests for additional url= bare host cases

[Matt Taggart]

Package: preseed
Version: 20180504
Severity: wishlist

The preseed file I have been using (for quite a few releases now) relies
on the behavior documented at

 https://www.debian.org/releases/stable/i386/apbs02.html.en#preseed-auto

where if url= does not list a protocol then http is assumed, and does
not end in / then default path is added.

I was trying to debug something and was looking through the preseed
source and realized that package/preseed/01-auto-install.t could use a
couple more test cases:

1) url= with a bare hostname like "url=server.example.org"
2) url= with a bare IP like "url=10.0.0.5"
3) I guess IPv6 is possible too? "url=fd00:9:152:48:1822::162:199"
(or maybe it's "url=[fd00:9:152:48:1822::162:199]"?)

Thanks,

-- 
Matt Taggart
tagg...@debian.org

Bug#897930: linux-image-4.9.0-6-686-pae: Random hard lockups (no panic message) on Via C7 system

[Ben Elliston]

Package: src:linux
Version: 4.9.88-1
Severity: normal

Dear Maintainer,

For several weeks I have been experiencing hard lockups of my system (running a 
Via C7 CPU).
When the system locks up, there is no panic message on the console, 
numlock/caps lock are
inoperative, and a hard reset is the only thing that can be done.  In recent 
days, these 
lockups have been happening on a near daily basis.

The motherboard and RAM have been replaced, thinking it was a hardware fault, 
but the 
problem continues.


-- Package-specific info:
** Version:
Linux version 4.9.0-6-686-pae (debian-ker...@lists.debian.org) (gcc version 
6.3.0 20170516 (Debian 6.3.0-18+deb9u1) ) #1 SMP Debian 4.9.88-1 (2018-04-29)

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.9.0-6-686-pae root=/dev/mapper/vg0-root ro quiet

** Not tainted

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

** Model information

** Loaded modules:
sit
tunnel4
ip_tunnel
ip6t_REJECT
nf_reject_ipv6
nf_conntrack_ipv6
nf_defrag_ipv6
ip6table_filter
ip6_tables
xt_multiport
ipt_REJECT
nf_reject_ipv4
xt_tcpudp
xt_conntrack
iptable_nat
nf_conntrack_ipv4
nf_defrag_ipv4
nf_nat_ipv4
nf_nat
nf_conntrack
iptable_filter
padlock_sha
via_cputemp
hwmon_vid
via_rng
rng_core
evdev
serio_raw
pcspkr
snd_hda_codec_via
snd_hda_codec_generic
snd_hda_intel
snd_hda_codec
snd_hda_core
snd_hwdep
sg
snd_pcm
shpchp
snd_timer
snd
soundcore
button
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
jbd2
crc32c_generic
fscrypto
ecb
xts
lrw
gf128mul
ablk_helper
cryptd
aes_i586
mbcache
hid_generic
usbhid
hid
dm_mod
sd_mod
ata_generic
padlock_aes
pata_via
libata
ehci_pci
uhci_hcd
ehci_hcd
i2c_viapro
scsi_mod
usbcore
usb_common
via_velocity
crc_ccitt
thermal
fan

** PCI devices:
not available

** USB devices:
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 005 Device 002: ID 17f6:0802 Unicomp, Inc 
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 003 Device 002: ID 051d:0002 American Power Conversion Uninterruptible 
Power Supply
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub


-- System Information:
Debian Release: 9.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=en_AU, LC_CTYPE=en_AU (charmap=ISO-8859-1), 
LANGUAGE=en_AU:en_US:en_GB:en (charmap=ISO-8859-1)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages linux-image-4.9.0-6-686-pae depends on:
ii  initramfs-tools [linux-initramfs-tool]  0.130
ii  kmod23-2
ii  linux-base  4.5

Versions of packages linux-image-4.9.0-6-686-pae recommends:
ii  firmware-linux-free  3.4
ii  irqbalance   1.1.0-2.3

Versions of packages linux-image-4.9.0-6-686-pae suggests:
pn  debian-kernel-handbook  
ii  grub-pc 2.02~beta3-5
pn  linux-doc-4.9   

Versions of packages linux-image-4.9.0-6-686-pae is related to:
pn  firmware-amd-graphics 
pn  firmware-atheros  
pn  firmware-bnx2 
pn  firmware-bnx2x
pn  firmware-brcm80211
pn  firmware-cavium   
pn  firmware-intel-sound  
pn  firmware-intelwimax   
pn  firmware-ipw2x00  
pn  firmware-ivtv 
pn  firmware-iwlwifi  
pn  firmware-libertas 
pn  firmware-linux-nonfree
pn  firmware-misc-nonfree 
pn  firmware-myricom  
pn  firmware-netxen   
pn  firmware-qlogic   
pn  firmware-realtek  
pn  firmware-samsung  
pn  firmware-siano
pn  firmware-ti-connectivity  
pn  xen-hypervisor

-- no debconf information

Bug#897598: cln: Please add support for new architecture "riscv64" (RISC-V 64 bits little-endian)

[Manuel A. Fernandez Montecelo]

2018-05-03 23:40 Richard B. Kreckel:

On 05/03/2018 02:39 PM, Manuel A. Fernandez Montecelo wrote:

I am attaching a patch that adds support for the arquitecture.  I don't know if
you will send upstream yourself or if you prefer that we send it.


Pushed patch upstream:
https://www.ginac.de/CLN/cln.git/?p=cln.git;a=commit;h=26aaf349a1fb3879274090d9e1c8f86da4a0a585


Thanks for this and for pushing also a release to unstable so quickly!


Cheers.
--
Manuel A. Fernandez Montecelo 

Bug#897911: jessie-pu: package libdatetime-timezone-perl/1:1.75-2+2018e

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2018-05-04 at 19:06 +0200, gregor herrmann wrote:
> I've uploaded libdatetime-timezone-perl/1:1.75-2+2018e for
> jessie(-updates). It contains a new patch which updates the data
> files to the Olson db release 2018e, which contains changes for North
> Korea effective tomorrow.
> 

Thanks; flagged for acceptance.

Regards,

Adam

Bug#897912: stretch-pu: package libdatetime-timezone-perl/1:2.09-1+2018e

[Adam D. Barratt]

Control: tags -1 + pending

On Fri, 2018-05-04 at 19:06 +0200, gregor herrmann wrote:
> I've uploaded libdatetime-timezone-perl/1:2.09-1+2018e for
> strech(-updates). It contains a new patch which updates the data
> files to the Olson db release 2018e, which contains changes for North
> Korea effective tomorrow.
> 

Thanks. Flagged for acceptance.

Regards,

Adam

Bug#849094: liblept5: Broken on s390x (+ other big endian archs)

[Jeff Breidenbach]

Tesseract  in Debian just added a build time smoke test AND Stefan fixed
the big-endian
problem. Should be live tomorrow in Sid. Assuming that works well, Graham
should be
able to re-activate the disabled OCRMyPDF tests. Note that this is Debian
only; Ubuntu
18.04 is out the door so no longer pertinent.

Bug#897794: How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)

[Mattia Rizzolo]

On Fri, May 04, 2018 at 02:52:30PM +0200, Andreas Tille wrote:
> there are several bugs filed against packages of the Debian Med
> team.

Well, it's not really only about Debian Med...

> What's the correct way to fix the symbols file to work
> with both versions of gcc?

As usual.
Investigate why symbols disappear and decide what to do.
In case of symbols disappearing after changing the compiler, most likely
those symbols were weak and only leaked an implementation detail, and so
they need to be marked as "optional".
For example:

[ #897794 ]
> > [...]
> > - (optional)_ZN5QListI16QuaZipFileInfo64ED1Ev@Base 0.7.3
> > - (optional)_ZN5QListI16QuaZipFileInfo64ED2Ev@Base 0.7.3
> > +#MISSING: 0.7.3-6# (optional)_ZN5QListI16QuaZipFileInfo64ED1Ev@Base 0.7.3
> > +#MISSING: 0.7.3-6# (optional)_ZN5QListI16QuaZipFileInfo64ED2Ev@Base 0.7.3

These are fine, dpkg-gensymbols is only being noisy here.

> > - (optional)_ZN5QListI7QStringED1Ev@Base 0.7.3
> > - (optional)_ZN5QListI7QStringED2Ev@Base 0.7.3
> > +#MISSING: 0.7.3-6# (optional)_ZN5QListI7QStringED1Ev@Base 0.7.3
> > +#MISSING: 0.7.3-6# (optional)_ZN5QListI7QStringED2Ev@Base 0.7.3
> >   _ZN5QListI9QFileInfoE13detach_helperEi@Base 0.7.3
> > - (optional)_ZN5QListI9QFileInfoED1Ev@Base 0.7.3
> > - (optional)_ZN5QListI9QFileInfoED2Ev@Base 0.7.3
> > +#MISSING: 0.7.3-6# (optional)_ZN5QListI9QFileInfoED1Ev@Base 0.7.3
> > +#MISSING: 0.7.3-6# (optional)_ZN5QListI9QFileInfoED2Ev@Base 0.7.3

same.

> > - (optional)_ZN7QStringD1Ev@Base 0.7.3
> > - (optional)_ZN7QStringD2Ev@Base 0.7.3
> > +#MISSING: 0.7.3-6# (optional)_ZN7QStringD1Ev@Base 0.7.3
> > +#MISSING: 0.7.3-6# (optional)_ZN7QStringD2Ev@Base 0.7.3

same.

Those ones probably come from a previous iteration, like gcc5→gcc6 or
gcc6→gcc7.

> > dpkg-gensymbols: warning: some symbols or patterns disappeared in the 
> > symbols file: see diff output below
> > dpkg-gensymbols: warning: debian/libquazip5-1/DEBIAN/symbols doesn't match 
> > completely debian/libquazip5-1.symbols
> > --- debian/libquazip5-1.symbols (libquazip5-1_0.7.3-6_amd64)
> > +++ dpkg-gensymbolsslI1lw   2018-05-02 13:22:04.076864552 +
> > @@ -74,8 +74,8 @@
> >   _ZN10QuaZipFileD0Ev@Base 0.7.3
> >   _ZN10QuaZipFileD1Ev@Base 0.7.3
> >   _ZN10QuaZipFileD2Ev@Base 0.7.3
> > - _ZN11QStringListC1ERK7QString@Base 0.7.3
> > - _ZN11QStringListC2ERK7QString@Base 0.7.3
> > +#MISSING: 0.7.3-6# _ZN11QStringListC1ERK7QString@Base 0.7.3
> > +#MISSING: 0.7.3-6# _ZN11QStringListC2ERK7QString@Base 0.7.3

This is the actual error.

|mattia@warren ~ % echo "
|dquote> > - _ZN11QStringListC1ERK7QString@Base 0.7.3
|dquote> > - _ZN11QStringListC2ERK7QString@Base 0.7.3
|dquote> " | c++filt
|> - QStringList::QStringList(QString const&)@Base 0.7.3
|> - QStringList::QStringList(QString const&)@Base 0.7.3

Yes, these are symbols that leaked through, so they can (and should) be
marked as "optional".

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#897923: stretch-pu: package tclreadline/2.1.0-15+deb9u1 pre-approval

[Breno Leitao]

On Fri, 04 May 2018 23:22:15 +0300 Sergei Golovan  wrote:

> I would like to upload the tclreadline package to stretch. The package
> currently in stable misses a shared library for the ppc64el architecture,
> as indicated in [1]. I'm attaching the package diff for review. It's
> tested using he ppc64el QEMU installation, and it builds fine now.

I also tested on a real ppc64el machine and this debdiff fixes the problem.

Thanks Sergei!

Bug#897928: virtualbox-guest-dkms: vboxvideo module fails to build with 4.16 kernel

[James McCoy]

Package: virtualbox-guest-dkms
Version: 5.2.10-dfsg-6
Severity: important

Dear Maintainer,

Upon installation of the recent 4.16 kernel, this module failed to
build:

DKMS make.log for virtualbox-guest-5.2.10 for kernel 4.16.0-1-amd64 (x86_64)
Fri May  4 17:01:28 EDT 2018
make: Entering directory '/usr/src/linux-headers-4.16.0-1-amd64'
...
  CC [M]  /var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.o
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c: In function 
‘vbox_bo_move’:
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:207:29: error: 
incompatible type for argument 2 of ‘ttm_bo_move_memcpy’
  r = ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
 ^
In file included from 
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_drv.h:65:0,
 from 
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:30:
/usr/src/linux-headers-4.16.0-1-common/include/drm/ttm/ttm_bo_driver.h:1001:5: 
note: expected ‘struct ttm_operation_ctx *’ but argument is of type ‘bool {aka 
_Bool}’
 int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
 ^~
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:207:44: error: 
incompatible type for argument 3 of ‘ttm_bo_move_memcpy’
  r = ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
^~~
In file included from 
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_drv.h:65:0,
 from 
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:30:
/usr/src/linux-headers-4.16.0-1-common/include/drm/ttm/ttm_bo_driver.h:1001:5: 
note: expected ‘struct ttm_mem_reg *’ but argument is of type ‘bool {aka _Bool}’
 int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
 ^~
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:207:6: error: 
too many arguments to function ‘ttm_bo_move_memcpy’
  r = ttm_bo_move_memcpy(bo, interruptible, no_wait_gpu, new_mem);
  ^~
In file included from 
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_drv.h:65:0,
 from 
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:30:
/usr/src/linux-headers-4.16.0-1-common/include/drm/ttm/ttm_bo_driver.h:1001:5: 
note: declared here
 int ttm_bo_move_memcpy(struct ttm_buffer_object *bo,
 ^~
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c: In function 
‘vbox_ttm_tt_populate’:
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:244:9: error: 
too few arguments to function ‘ttm_pool_populate’
  return ttm_pool_populate(ttm);
 ^
In file included from 
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:31:0:
/usr/src/linux-headers-4.16.0-1-common/include/drm/ttm/ttm_page_alloc.h:50:5: 
note: declared here
 int ttm_pool_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx);
 ^
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c: At top level:
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:254:21: error: 
initialization from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  .ttm_tt_populate = vbox_ttm_tt_populate,
 ^~~~
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:254:21: note: 
(near initialization for ‘vbox_bo_driver.ttm_tt_populate’)
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:261:10: error: 
initialization from incompatible pointer type 
[-Werror=incompatible-pointer-types]
  .move = vbox_bo_move,
  ^~~~
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:261:10: note: 
(near initialization for ‘vbox_bo_driver.move’)
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:266:16: error: 
‘ttm_bo_default_io_mem_pfn’ undeclared here (not in a function); did you mean 
‘ttm_bo_del_from_lru’?
  .io_mem_pfn = ttm_bo_default_io_mem_pfn,
^
ttm_bo_del_from_lru
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c: In function 
‘vbox_bo_pin’:
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:435:8: error: 
too many arguments to function ‘ttm_bo_validate’
  ret = ttm_bo_validate(>bo, >placement, false, false);
^~~
In file included from 
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_drv.h:64:0,
 from 
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:30:
/usr/src/linux-headers-4.16.0-1-common/include/drm/ttm/ttm_bo_api.h:338:5: 
note: declared here
 int ttm_bo_validate(struct ttm_buffer_object *bo,
 ^~~
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c: In function 
‘vbox_bo_unpin’:
/var/lib/dkms/virtualbox-guest/5.2.10/build/vboxvideo/vbox_ttm.c:462:8: error: 

Bug#897794: How to fix symbols files to work with gcc-7 and gcc-8 (Was: Bug#897794: libquazip: ftbfs with GCC-8)

[Mattia Rizzolo]

Yavor,

On Fri, May 04, 2018 at 04:06:05PM +0300, Yavor Doganov wrote:
> Andreas Tille wrote:
> > What's the correct way to fix the symbols file to work with both
> > versions of gcc?
> 
> Don't use symbols files for C++ libraries?

Please do not advocate nor recommend such pointless stands.

Yes, C++ symbols are harder to track than C symbols.
Yes, C++ symbols handling requires more work than doing C symbols.
Yes, many C++ libraries do a very horrible job at ABI maintenance that
for them maintaining a symbols file is impossible.
No, it's not impossible to maintain a symbols file for a C++ library.
Yes, for decent libraries it's totally feasible also for mere humans.

Guess what, C++ is more complex than C.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#897927: equivs builds packages in surprising location

[Marten van Kerkwijk]

Package: equivs
Version: 2.1.0

When I previously used equivs-build, the .deb file was generated in the
current working directory, but with version 2.1.0 it preferentially uses
$TMPDIR.  In principle, this is a good change, but it would be helpful
if the man page states where the package ends up.  (I spent about an
hours trying to debug, until I finally thought to look at the source
code...)

Thanks!

Marten

Bug#897608: lintian: warn that debug symbol migration is complete

[Mattia Rizzolo]

Hi,

On Fri, May 04, 2018 at 08:47:13PM +0200, Graham Inggs wrote:
> On 4 May 2018 at 01:16, Chris Lamb  wrote:
> > Could you have an initial stab at the description for this tag and,
> > perhaps, a suggested severity level? :-)
> 
> I: auto-dbgsym-migration-possibly-complete
> 
> debian/rules contains 'dh_strip --dbgsym-migration' (formerly
> '--ddeb-migration')
> 
> Automatic debug symbol packages first became available in December 2015.
> 
> If the dh_strip command migrating manual '-dbg' packages to '-dbgsym'
> was added to debian/rules and the package was included in Stretch,
> then the command, and possibly 'override_dh_strip', may now be
> removed.  If the command was only added later, and/or the package was
> not included in Stretch, please wait until it has been included in a
> stable release before removing it.
> 
> Further information:
> https://wiki.debian.org/AutomaticDebugPackages

I advise against such tag.

Whilst true that several packages could potentially remove the
"migration" path, and IMHO even for most of the ones that added it it
wouldn't have been necessary, packages that today migrate from a manual
dbg to an automatic dbgsym and have any likelyhood of file clashing due
to the built binaries having the same build-id would have to use that
flag.  Doing something recommended (moving to dbgsym) and have that
trigger a lintian tag —even if it is not a warning— would be very
annoying.

Graham: what is your reasoning for pushing toward what feels like a
deprecation of --dbgsym-migration?  I've never heard any deprecation
plan from Niels, and surely a versioned Breaks+Replaces in dbgsyms are
not causing any issues.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#897921: Please package virtualbox-guest-additions-iso

[Geert Stappers]

On Fri, May 04, 2018 at 11:52:58PM +0300, Evgeny Kapun wrote:
> On 04.05.2018 23:14, Geert Stappers wrote:
> >On Fri, May 04, 2018 at 10:38:57PM +0300, Evgeny Kapun wrote:
> >>Hi!
> >>
> >>While most VirtualBox packages are available in stretch-backports,
> >>virtualbox-guest-additions-iso is missing for some reason.
> >>Please package it as well.
> >>
> >
> >Filed as bugreport #897921: 
> >https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897921
> >
> 
> Should bug reports concerning packages in backports be posted to Debian
> BTS? Backports.debian.org FAQ page [1] says that they should be posted
> to this mailing list instead:
> 
> >Q: Where shall I report bugs I found in packages from backports to?
> >
> >A: Please report them to the debian-backports mailing list. The Debian
> bugtracking system doesn't know anything about backports versions,
> and sometimes the backporter isn't in the Debian packaging team so
> they might miss the report.
> 
> If this FAQ entry is outdated, perhaps it should be amended.
> 
> [1] https://backports.debian.org/FAQ/

Maybe is the FAQ "outdated". 

My idea about reporting through the BTS is to contact
the maintainer of the package. Because the package maintainer
might not be on this mailinglist, but is the person who
wants to known that there is a backport.


Groeten
Geert Stappers

P.S.
If I Recall Correct:
There was first backports.org and later Debian backports ...
-- 
Leven en laten leven

Bug#823590: ca-certificates: Having changed the keystore password (for server's security reaosons), update crashes

[Emmanuel Bourg]

Hi Guillaume,

Why are you changing the password of a keystore holding the public keys
of the certification authorities? There is nothing secret inside.

Emmanuel Bourg

Bug#897925: Web browsers do not work with armhf

[eHenry Berg]

Package: libgles2-mesa-dev
Version: 18.0.2-2

Hardware: Raspberry Pi 2 and 3.
I use vc4 kernel module.
I use Debian release "sid" in both arm64 and armhf.
Packages installed in both arm64 and and armhf: kde-full, calligra,
ktorrent, mesa-utils, falkon

My 64-bit enviroment "arm64" works!

My 32-bit enviroment "armhf" does not work:
32-bit worked fine before December 2017, then I got ssl problem.
After that I got libGLESv2.so problem. I had a litte mix in my 32-bit
installation with Raspbian.
One week ago, I made a clean Debian installation and I got the same
problem with libGLESv2.so.

Konqueror error message:
$ konqueror
Illegal icon group:  7
.
kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find ""
KonqFrame(0x26647a0) QObject(0x0)
[1687:1710:0501/131308.998611:ERROR:gl_implementation.cc(246)] Failed
to load /usr/bin/libGLESv2.so: /usr/bin/libGLESv2.so: cannot open
shared object file: No such file or directory

Falkon error message:
$ falkon %u
[1621:1643:0501/130116.880980:ERROR:gl_implementation.cc(246)] Failed
to load /usr/bin/libGLESv2.so: /usr/bin/libGLESv2.so: cannot open
shared object file: No such file or directory
Falkon: 1 extensions loaded
[1621:1643:0501/130121.49:ERROR:gl_surface_qt.cpp(701)] Requested
OpenGL implementation is not supported. Implementation: 0
*** stack smashing detected ***:  terminated
Received signal 6
#0 0xb450f11e 
#1 0xb450ef9a 
#2 0xb383e300 
#3 0xb450f396 
#4 0xb1d966e0 
#5 0xb1d88206 
[end of stack trace]
Calling _exit(1). Core file will not be generated.
$


Best Regards,
Evald

Bug#897926: Enable --with-compat configure argument

[Thomas Ward]

Source: nginx
Severity: wishlist

I have received multiple requests in downstream PPAs and repositories to
enable the `--with-compat` configuration option.

This would allow for users to build additional dynamic modules with
binary module compatibility.

It was stated in an October 12, 2016 email on the nginx mailing
list/forums by Maxim Dounin that from a package maintenance point of
view, it would be a good idea to add this option to NGINX builds.

I don't see this being done in the current rules.  Would it be possible
to add --with-compat to the debian/rules file for future package versions?

Bug#887135: manpage-pt: Is package unmaintained?

[Tobias Frost]

Followup-For: Bug #887135
Control: reassign -1 wnpp
Control: retitle -1 O: manpages-pt -- Portuguese Versions of the Manual Pages
Control: severity -1 normal

more than 3 months have passed without reaction to this bug,
therefore orphaning it now on behalf of the MIA team.

--
tobi

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

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

Bug#897924: RM: sphinxbase [mips s390x hppa m68k powerpc powerpcspe ppc64 sparc64] -- ROM; buggy packages on big-endian archs

[Samuel Thibault]

Package: ftp.debian.org
Severity: normal

Hello,

The sphinxbase has actually always been buggy on big-endian
architectures, and the testsuite actually event has bad effects on
buildds, so I have recently made it to just not run and fail, instead of
ignoring its result.

For that version of sphinxbase to reach testing, I'd however need to
have the old binaries removed for big-endian archs.

Thanks
Samuel

Bug#892304: lintian: Warn about "old" X-Python3-Version fields?

[Scott Kitterman]

On Friday, May 04, 2018 04:17:37 PM Nicholas D Steeves wrote:
> I remember this   Thanks for mentioning this bug in
> #debian-python.  I followed
> https://wiki.debian.org/Python/LibraryStyleGuide#Python_versions and
> it would seem it also needs to be updated.
...
> 
> Should articles in the wiki be updated before or after lintian?

Before is fine.  I've done it.  We should also update Python policy to get rid 
of X-Python-Version, but that's a different day.

Scott K

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

Bug#897615: please add an option '--version' to arch-test

[Adam Borowski]

On Thu, May 03, 2018 at 05:15:25PM +0200, jhcha54008 wrote:
> An option '--version' in arch-test would be helpful. It 
> would make easier to determine which options 
> /usr/bin/arch-test supports.
> 
> (e.g., debootstrap 1.97 makes use of option '-c' of 
> arch-test that the version 0.7-1 doesn't support)

I guess what you really want is sane handling of unknown options.
Added both.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ 
⣾⠁⢰⠒⠀⣿⡁ 
⢿⡄⠘⠷⠚⠋⠀ Certified airhead; got the CT scan to prove that!
⠈⠳⣄ 

Bug#897251: pdf2djvu: FAIL: test-1px-font.test.test

[Daniel Stender]

On 05/04/2018 10:08 PM, Jakub Wilk wrote:
> OK, I think I know what's going on.
> 
> The bug triggers when all the following conditions are met:
> 
> * /usr/local/share exists prior to installation of the "fontconfig-config" 
> package. (It's supposed to be created by base-files, but it didn't exist in 
> my chroot for some reason...)
> 
> * The building user belongs to the "staff" group.
> 
> * No other program created the UUID file for /usr/local/share/fonts yet.
> 
> This is what happens:
> 
> 1. fontconfig-config.postist creates /usr/local/share/fonts/, owned by 
> root:staff, mode 2775. (This is violation of Policy §9.1.2: unless
> /etc/staff-group-for-usr-local exists, directories in /usr/local should be 
> root:root 0755.)
> 
> 2. pdf2djvu (indirectly) calls the FcDirCacheCreateUUID() function...
> 
> 2.1. FcDirCacheCreateUUID creates an UUID file in /usr/local/share/fonts/. 
> This succeeds, because the user has write access to the directory.
> 
> 2.2. FcDirCacheCreateUUID tries to change mtime of /usr/local/share/fonts/. 
> But, as documented in the utimes(2) manpage, write access is not enough to do 
> that: you need to be either the file owner, or root (or have root-like 
> capabilities). So this fails, and a warning is issued.
> 
> 
> Easy work-around for pdf2djvu: add the "fontconfig" package to Build-Depends. 
> It will take care take of creating the UUID file for /usr/local/share/fonts/, 
> and then FcDirCacheCreateUUID() will be mostly no-op.

Great, thanks! I'll take care of this shortly.

Daniel

-- 
4096R/DF5182C8 (sten...@debian.org)
http://www.danielstender.com/

Bug#897923: stretch-pu: package tclreadline/2.1.0-15+deb9u1 pre-approval

[Sergei Golovan]

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

Hi!

I would like to upload the tclreadline package to stretch. The package
currently in stable misses a shared library for the ppc64el architecture,
as indicated in [1]. I'm attaching the package diff for review. It's
tested using he ppc64el QEMU installation, and it builds fine now.

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

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

Kernel: Linux 4.15.0-0.bpo.2-amd64 (SMP w/12 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru tclreadline-2.1.0/debian/changelog tclreadline-2.1.0/debian/changelog
--- tclreadline-2.1.0/debian/changelog  2016-10-08 12:04:28.0 +0300
+++ tclreadline-2.1.0/debian/changelog  2016-10-08 12:04:28.0 +0300
@@ -1,3 +1,10 @@
+tclreadline (2.1.0-15+deb9u1) stretch; urgency=medium
+
+  * Add a patch by Breno Leitao which fixes building the shared library for
+   the ppc64el architecture (closes: #897429).
+
+ -- Sergei Golovan   Sat, 08 Oct 2016 12:04:28 +0300
+
 tclreadline (2.1.0-15) unstable; urgency=low
 
   * Fixed implicit function declararion warning (replaced the deprecated
diff -Nru tclreadline-2.1.0/debian/patches/ppc64el.patch 
tclreadline-2.1.0/debian/patches/ppc64el.patch
--- tclreadline-2.1.0/debian/patches/ppc64el.patch  1970-01-01 
03:00:00.0 +0300
+++ tclreadline-2.1.0/debian/patches/ppc64el.patch  2016-10-08 
12:04:28.0 +0300
@@ -0,0 +1,15 @@
+Author: Breno Leitao
+Description: Patch fixes building the shared library for ppc64el.
+Last-Modified: Wed, 02 May 2018 21:11:16 +0300
+Debian-Bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897429
+
+--- a/aux/ltconfig
 b/aux/ltconfig
+@@ -2000,7 +2000,6 @@
+   else
+ # Only the GNU ld.so supports shared libraries on MkLinux.
+ case "$host_cpu" in
+-powerpc*) dynamic_linker=no ;;
+ *) dynamic_linker='Linux ld.so' ;;
+ esac
+   fi
diff -Nru tclreadline-2.1.0/debian/patches/series 
tclreadline-2.1.0/debian/patches/series
--- tclreadline-2.1.0/debian/patches/series 2016-10-08 12:04:28.0 
+0300
+++ tclreadline-2.1.0/debian/patches/series 2016-10-08 12:04:28.0 
+0300
@@ -12,3 +12,4 @@
 functions.patch
 ding.patch
 stubs.patch
+ppc64el.patch

Bug#892304: lintian: Warn about "old" X-Python3-Version fields?

[Nicholas D Steeves]

Hello,

On Fri, May 04, 2018 at 03:53:31PM -0400, Scott Kitterman wrote:
> On Thu, 08 Mar 2018 02:07:36 + Chris Lamb  wrote:
> > Package: lintian
> > Version: 2.5.77
> > Severity: wishlist
> > 
> > Hi,
> > 
> > Should we warn about "old" X-Python3-Version fields? For example, I
> > just saw a new package from a sponsee with:
> > 
> >   X-Python3-Version: >= 3.2
> > 
> > This seems a little silly given that 3.2 is only in wheezy, jessie has
> > 3.4 and stretch has 3.5.
> >

I remember this ;-)  Thanks for mentioning this bug in
#debian-python.  I followed
https://wiki.debian.org/Python/LibraryStyleGuide#Python_versions and
it would seem it also needs to be updated.
 
> > If the idea is fundamentally sound, we could even avoid most of the
> > "What versions should we I: or P: at..." bikeshedding by having an
> > "ancient" and "old" tags with differing severities.  :)
> > 
> > Thoughts?
> 
> I also applies to X-Python-Version (even more so - I didn't check if this is 
> already covered in another test).
> 
> Here's a rule of thumb I would suggest:
> 
> old: =< lowest version supported in stable (for backports)
> ancient: =< lowest version supported in oldstable (for sloppy backports)
> 
> Currently that would be:
> 
> Python:
> 
> old: Presence of any X-Python-Version as there's only Python2.7 in stable
> ancient: Same.  Even though oldstable shipped the python2.6 interpreter, it 
> was not a supported version for module building.
> 
> Python3:
> 
> old: X-Python3-Version: >= 3.5
> ancient: X-Python3-Version: >= 3.4
> 
> Backport no longer remains open for LTS, so there's no need to consider 
> backports to oldoldstable.

Should articles in the wiki be updated before or after lintian?

Cheers,
Nicholas


signature.asc
Description: PGP signature

Bug#897429: [Pkg-tcltk-devel] Bug#897429: ppc64el: Shared Object not available in the platform

[Breno Leitao]

Hi Sergei,

On Wed, May 02, 2018 at 06:25:55PM +, Sergei Golovan wrote:
> Hi Bruno,
> 
> If you have access to the ppc64el hardware, could you test the fix (I've
> attached a diff, which is to be applied to the 2.1.0-15 sources)? If it's
> okay, I'll ask the release team about a stable update.

Yes, I was able to test it and it is working as expected:

➜  dpkg -c tcl-tclreadline_2.1.0-15+deb9u1_ppc64el.deb | grep so
-rw-r--r-- root/root 67664 2016-10-08 05:04 
./usr/lib/powerpc64le-linux-gnu/libtclreadline-2.1.0.so
lrwxrwxrwx root/root 0 2016-10-08 05:04 
./usr/lib/powerpc64le-linux-gnu/libtclreadline.so -> libtclreadline-2.1.0.so

Thanks for working on it,
Breno

Bug#897251: pdf2djvu: FAIL: test-1px-font.test.test

[Jakub Wilk]

OK, I think I know what's going on.

The bug triggers when all the following conditions are met:

* /usr/local/share exists prior to installation of the 
"fontconfig-config" package. (It's supposed to be created by base-files, 
but it didn't exist in my chroot for some reason...)


* The building user belongs to the "staff" group.

* No other program created the UUID file for /usr/local/share/fonts 
yet.


This is what happens:

1. fontconfig-config.postist creates /usr/local/share/fonts/, owned by 
root:staff, mode 2775. (This is violation of Policy §9.1.2: unless
/etc/staff-group-for-usr-local exists, directories in /usr/local should 
be root:root 0755.)


2. pdf2djvu (indirectly) calls the FcDirCacheCreateUUID() function...

2.1. FcDirCacheCreateUUID creates an UUID file in 
/usr/local/share/fonts/. This succeeds, because the user has write 
access to the directory.


2.2. FcDirCacheCreateUUID tries to change mtime of 
/usr/local/share/fonts/. But, as documented in the utimes(2) manpage, 
write access is not enough to do that: you need to be either the file 
owner, or root (or have root-like capabilities). So this fails, and a 
warning is issued.



Easy work-around for pdf2djvu: add the "fontconfig" package to 
Build-Depends. It will take care take of creating the UUID file for 
/usr/local/share/fonts/, and then FcDirCacheCreateUUID() will be mostly 
no-op.


--
Jakub Wilk

Bug#897605: How to deal with non-functional package in stretch? (Was: Bug#897605: profphd failure in stretch)

[Andreas Tille]

Hi Tanya,

thanks for your comments.

On Fri, May 04, 2018 at 07:11:22PM +0300, merlettaia wrote:
> This is fixed in version 1.0.42-2, and not present in version 1.0.42-1,
> which seems to be latest in stretch (both with tests).
> At patches dir:
> 
>   https://salsa.debian.org/med-team/profphd/blob/master/
> debian/patches/2_remove_perlbrew_usage.patch
> - this disables perlbrew usage (this was temporary, it would be wiser to
> replace this patch with the one which removes if-then-statement completely,
> because this "temporary" fix just confuses and intricates code logic in
> long-term perspective),
> 
>   https://salsa.debian.org/med-team/profphd/blob/master/
> debian/patches/3_fix_indexing.patch - and as far as I remember this fixes
> actual erratic behavior with latest versions of perl, which was the reason
> why that if-then-else statement appeared in profphd code (the main problem
> here is the "$["-magic in perl).
> 
> Other patches fix error or warning messages, which appeared in almost all
> rostlab packages and were not as tricky as this one.

If you ask me the most sensible approach would be to use exactly
1.0.42-2 since this is solidly tested.

> P.S. - I could work on fixing this bug late at the evening or tomorrow,
> because at this moment I have no Debian distribution or VM somewhere
> nearby, and I could check that everything works after I come home. In case
> if Liubov has time for solving this before that and she is not working on
> something else I've added her to CC.

Before you spent some time on removing sensible patches I'd first like
to hear the opinion of the release team whether my argument to use
something tested is better as the minimum diff to the current package
in Stretch.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#897922: RFS: scons-doc/3.0.0+repack-2 [RC]

[Jörg Frings-Fürst]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Package: sponsorship-requests
Severity: important

Dear mentors,

  I am looking for a sponsor for my package "scons-doc"

   Package name: scons-doc
   Version : 3.0.0+repack-2
   Upstream Author : Steven Knight 
   URL : http://www.scons.org
   License : Expat, CC-BY-SA-3.0, GPL-3+
   Section : doc

  It builds those binary packages:

scons-doc  - Documentation for SCons, a replacement for Make

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

  https://mentors.debian.net/package/scons-doc


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

dget -x 
https://mentors.debian.net/debian/pool/main/s/scons-doc/scons-doc_3.0.0+repack-2.dsc


  Changes since the last upload:

  * Switch from openjdk-8-jre to default-jre (Closes: #894355).
  * Migrate to debhelper 11:
- Change debian/compat to 11.
- Bump minimum debhelper version in debian/control to >= 11.
  * Declare compliance with Debian Policy 4.1.4 (No changes needed).
  * Change to my new email address:
- debian/control
- debian/copyright
  * debian/copyright:
- Add year 2018 to debian/*.
- Use secure URI for copyright format.



  Regards,
   Jörg Frings-Fürst



- -- 
New:
GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB  30EE 09F8 9F3C 8CA1 D25D
GPG key (long) : 09F89F3C8CA1D25D
GPG Key: 8CA1D25D
CAcert Key S/N : 0E:D4:56

Old pgp Key: BE581B6E (revoked since 2014-12-31).

Jörg Frings-Fürst
D-54470 Lieser

Threema:  SYR8SJXB
Wire: @joergfringsfuerst
Skype:joergpenguin
Ring: jff
Telegram: @joergfringsfuerst

IRC: j_...@freenode.net
 j_...@oftc.net

My wish list: 
 - Please send me a picture from the nature at your home.
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAlrsuygACgkQCfifPIyh
0l2Myw//Qf7uSlgkIjqveLAlEIgYL0+tmkFDtZyAFVbET96Npk5vGXo+sjFQ6yfd
v5BCIuDac/Qa3Cu2ffcEHKrCWftmx3NRSv059biwJQ9Nbdcqz1w0bKbRI17/GvnZ
OnR6xRUCMacVXzvELPnIJIsZ0MjyU0mLywahdXhldfKw7VmR1xCt8MrNoB8ysBib
kbxrHtDpGWD+RWOxmwwCb9vadnNVZcY0XMounnzv/o1mkW5yb3ZCSu2VEG7Y86bd
KVVOrxKBsPcfsWvFsnyF9o1SqGtIeHJuDWwbWA2xvXmP/16pHsJKtZqeABPdZcbR
l1DEn7VgnPTCqZBjQoKS1kLJadoctrvunD/CNYlvRL5b7KqSVsOVm40UE/VDDK98
QF4ui3YJayL2iKQA0t2CxmouyUlUHYyhF9O88hk/4MWnLkoVUFo+bQcP5npq7sXy
GKpB3rbT8USxciBCst+DvIyu4NdiieCEHuKxFs0uM63wNuzGaq8M8j6eFHmTMCYk
kxJNwRSC9JR7NGmEFnSeHKZPNXzY0RgDhRt5/17HItueX5BSqkI1ZZacXL+TsmZZ
QxwegX4ngAbwFPbnc3jW/qMjX1N4s/3OHAjD4jE7Xv8daClDXFL1QNXLw3p0m7mT
pJXuqaOAbU9ve3yYpslghpi1oE8WM+YSRX8TRogYb3zecnF2048=
=TlnF
-END PGP SIGNATURE-

Bug#892304: lintian: Warn about "old" X-Python3-Version fields?

[Scott Kitterman]

On Thu, 08 Mar 2018 02:07:36 + Chris Lamb  wrote:
> Package: lintian
> Version: 2.5.77
> Severity: wishlist
> 
> Hi,
> 
> Should we warn about "old" X-Python3-Version fields? For example, I
> just saw a new package from a sponsee with:
> 
>   X-Python3-Version: >= 3.2
> 
> This seems a little silly given that 3.2 is only in wheezy, jessie has
> 3.4 and stretch has 3.5.
> 
> If the idea is fundamentally sound, we could even avoid most of the
> "What versions should we I: or P: at..." bikeshedding by having an
> "ancient" and "old" tags with differing severities.  :)
> 
> Thoughts?

I also applies to X-Python-Version (even more so - I didn't check if this is 
already covered in another test).

Here's a rule of thumb I would suggest:

old: =< lowest version supported in stable (for backports)
ancient: =< lowest version supported in oldstable (for sloppy backports)

Currently that would be:

Python:

old: Presence of any X-Python-Version as there's only Python2.7 in stable
ancient: Same.  Even though oldstable shipped the python2.6 interpreter, it 
was not a supported version for module building.

Python3:

old: X-Python3-Version: >= 3.5
ancient: X-Python3-Version: >= 3.4

Backport no longer remains open for LTS, so there's no need to consider 
backports to oldoldstable.

Scott K

Bug#897921: Please backport virtualbox-guest-additions-iso

[Geert Stappers]

Package: virtualbox-guest-additions-iso 
Severity: wishlist

- Forwarded message from Evgeny Kapun  -

Date: Fri, 4 May 2018 22:38:57 +0300
From: Evgeny Kapun 
To: debian-backpo...@lists.debian.org
Subject: Please package virtualbox-guest-additions-iso
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 
Thunderbird/52.7.0

Hi!

While most VirtualBox packages are available in stretch-backports,
virtualbox-guest-additions-iso is missing for some reason.
Please package it as well.


- End forwarded message -


Groeten
Geert Stappers
-- 
Leven en laten leven

Bug#897920: Description is misleading

[Roman Lebedev]

Package: libgtest-dev
Version: 1.8.0-10
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The package's description says:
Google's framework for writing C++ tests [source code] 
But this isn't the sources, the sources are in googletest package.
This package contains prebuilt version of the library.

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

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

Versions of packages libgtest-dev depends on:
ii  googletest  1.8.0-10

libgtest-dev recommends no packages.

libgtest-dev suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEjkF6151RK40WXe2HCDw+u0oWieAFAlrst1IACgkQCDw+u0oW
ieBJRw/+JF5ryRCvxjcvCCVKLX789L95GF548T7MSCqILt+tbN63trq4/L1oL/q4
kHFbTKP7+CRv8jH+dyENQN4G858FUbnULEa7HPTXWUQU7Arbt1UkYlCrQeV6Jpy0
F5kU7q/g5tGRG9keXL49bHsHS52KADh5tsR5Msdktf1umU/8NvaGho1zzm4ZzR/q
FORQDslsl3WsgwMGTSCndKbB1x1z3St21GbKFdywbmKTVOHTI4ZH5yKwUVPxk42h
0xmWM030c8RZC+SQYLor5PzBRVbAsp/ZbkcwojQiDWb7BQLXme6JgP7dQscE+O5q
UTNy9FcLTfzJnqgqxChaUZcxNj920LQzviTkeR+uxDepiBXxL/2+uBHjuAZV/H8F
BWP+UH21N+zfN6mJiUkailvozm2C1WR8d3keyxrulOYj/mm0FtAD5yeUJXn9SOfn
6BUfbIppyuUn9SHA57mqpMg/NwptNogaIACZNurXIbPLQeqiLq+2/tkCzaOH4EIa
wLRaR5CxBJeUrzNfQxL1eVtZXyqmeP+VOGsOXHRVTC7HE6c/5M5aEoHd8b3t78fl
evMXWhiuqHUC8eTq69iwaNeZ7Yt03CEt453S+F9VAnpvDYTBTjAUouKRZudCnlLs
ULbwYnZaXmV0/j/Ukch1szJGrc12wNfo4aA5oSxpwaV0Zi0fb6A=
=t4Y6
-END PGP SIGNATURE-

Bug#897570: budgie-desktop: Cannot open additional windows for term apps

[Alexandre Paradis]

Opened issue upstream:
https://github.com/budgie-desktop/budgie-desktop/issues/1417

On Thu, May 3, 2018 at 1:38 PM, David Mohammed  wrote:
> Yes please with the upstream report and link back here. Cheers.
>
> On Thu, 3 May 2018, 18:25 Alexandre Paradis,  wrote:
>>
>> Hi David,
>>
>> The issue you linked is quite old, and I think it's not exactly the same
>> problem, as other applications I tried do have a "New Window" menu item to
>> open a separate instance.
>>
>> However, I can take a look at their other open issues if one matches.
>>
>> If I can't find one, should I just open a bug report upstream and link it
>> back here?
>>
>> Thanks!
>>
>> Alex
>>
>> PS:. Yes, it is gnome-terminal but also most terminal apps I tried
>> (xfce-terminal and mate-terminal)
>>
>> On Thu, May 3, 2018, 5:26 AM David Mohammed 
>> wrote:
>>>
>>> Sounds like an upstream issue  - not Debian specific
>>>
>>> There are various reports upstream such as this
>>> https://github.com/budgie-desktop/budgie-desktop/issues/232
>>>
>>> and this PR which has been merged apparently allows you to shift-click
>>> on an icon to launch a new instance
>>>
>>> https://github.com/budgie-desktop/budgie-desktop/pull/1364
>>>
>>> Going to mark this as a wishlist item.
>>>
>>> Once v10.4.1 of budgie-desktop is released we can check then if the
>>> shift-click method resolves this launch of a new instance issue with
>>> gnome-terminal (I am guessing that is the terminal you are using)
>>>
>>> On 3 May 2018 at 02:37, Alexandre Paradis 
>>> wrote:
>>> > Package: budgie-desktop
>>> > Version: 10.4+git20171031.10.g9f71bb8-1.2
>>> > Severity: important
>>> >
>>> > Dear Maintainer,
>>> >
>>> > When pinning a terminal application to the taskbar, I cannot spawn
>>> > additonal instances of this application use right-click -> New Window, as
>>> > the menu is missing
>>> >
>>> >* What led up to the situation?
>>> >  Pin gnome-terminal, or xfce4-terminal, right-click the icon and
>>> > look for New Window
>>> >* What exactly did you do (or not do) that was effective (or
>>> >  ineffective)?
>>> >  Same steps work as expected for other programs (Chrome, File
>>> > manager)
>>> >* What was the outcome of this action?
>>> >  Cant find the menu item to open a second terminal instance
>>> >* What outcome did you expect instead?
>>> >  New window menu item present
>>> >
>>> >
>>> >
>>> > -- System Information:
>>> > Debian Release: buster/sid
>>> >   APT prefers testing
>>> >   APT policy: (500, 'testing')
>>> > Architecture: amd64 (x86_64)
>>> > Foreign Architectures: i386
>>> >
>>> > Kernel: Linux 4.15.0-3-amd64 (SMP w/4 CPU cores)
>>> > Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
>>> > LANGUAGE=en_CA:en (charmap=UTF-8)
>>> > Shell: /bin/sh linked to /bin/dash
>>> > Init: systemd (via /run/systemd/system)
>>> > LSM: AppArmor: enabled
>>> >
>>> > Versions of packages budgie-desktop depends on:
>>> > ii  budgie-core
>>> > 10.4+git20171031.10.g9f71bb8-1.2
>>> > ii  dconf-gsettings-backend [gsettings-backen  0.28.0-2
>>> > ii  gir1.2-budgie-1.0
>>> > 10.4+git20171031.10.g9f71bb8-1.2
>>> > ii  gnome-control-center   1:3.28.1-1
>>> > ii  gnome-menus3.13.3-11
>>> > ii  gnome-screensaver  3.6.1-8+b1
>>> > ii  gnome-session-bin  3.28.1-1
>>> > ii  gnome-session-common   3.28.1-1
>>> > ii  gnome-settings-daemon  3.28.1-1
>>> > ii  network-manager-gnome  1.8.10-5
>>> >
>>> > budgie-desktop recommends no packages.
>>> >
>>> > budgie-desktop suggests no packages.
>>> >
>>> > -- no debconf information

Bug#897608: lintian: warn that debug symbol migration is complete

[Graham Inggs]

On 4 May 2018 at 21:01, Chris Lamb  wrote:
>> debian/rules contains 'dh_strip --dbgsym-migration' (formerly
>> '--ddeb-migration')
>
>
>  Don't you mean "or" here..?

debian/rules contains 'dh_strip --dbgsym-migration' or
'--ddeb-migration' (as it was formerly known)

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Just thinking: Maybe it does indeed have something to do with the size 
of u-boot. The one from bodhi is 524 KB, whereas the Debian one is 599 KB.



Am 04.05.2018 um 20:40 schrieb Markus Krebs:
Interesting thoughts, but: I tried again flashing both from within 
Debian and from u-boot (using ${filesize}). $filesize is accepted and 
flashing works, but the plug doesn't boot.
Flashing (again with $filesize, just to confirm it works) the u-boot 
from bodhi-linux (the one I was referring to) works, so it must be the 
u-boot.kwb in Debian which is broken.



Am 04.05.2018 um 19:11 schrieb Martin Michlmayr:

* Vagrant Cascadian  [2018-05-04 08:40]:

I do recall that there was some incompatible change regarding the
environment size on some of the marvell platforms, as u-boot.kwb grew
large enough to overwrite the environment section.

Uh, this might not be an u-boot issue then but a problem with my
upgrade instructions (although Markus said he tried to do the update
from within Debian too, so maybe not).

https://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/ says:
nand write 0x080 0x0 0x8

0x8 = 524288

but:
-rw-r--r-- 1 tbm tbm 599684 Apr  2 03:20 
usr/lib/u-boot/sheevaplug/u-boot.kwb


so we're not writing the whole binary to flash.

The reason I used 0x8 instead of ${filesize} is because very old
u-boot versions (as originally shipped on the SheevaPlug) have
problems with ${filesize}:

 NAND write: device 0 offset 0x0, size 0x68ab0
 nand_write_ecc: Attempt to write not page aligned data
  0 bytes written: ERROR

Bug#897671: u-boot does not work on sheevaplug

[Martin Michlmayr]

* Markus Krebs  [2018-05-04 20:40]:
> Interesting thoughts, but: I tried again flashing both from within Debian
> and from u-boot (using ${filesize}). $filesize is accepted and flashing
> works, but the plug doesn't boot.
> Flashing (again with $filesize, just to confirm it works) the u-boot from
> bodhi-linux (the one I was referring to) works, so it must be the u-boot.kwb
> in Debian which is broken.

In this case, I guess the u-boot binary plus my instructions are
broken. ;)

Maybe you can find out which versions work / do not work.

-- 
Martin Michlmayr
http://www.cyrius.com/

Bug#897608: lintian: warn that debug symbol migration is complete

[Chris Lamb]

Hi Graham,

Thanks for this!

> > Could you have an initial stab at the description for this tag and,
> > perhaps, a suggested severity level? :-) 
[…]
> debian/rules contains 'dh_strip --dbgsym-migration' (formerly
> '--ddeb-migration')
   

 Don't you mean "or" here..?


Best wishes,

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

Bug#897545: node-bluebird: FTBFS: cp: cannot stat '/<>/node-bluebird-3.5.1+dfsg2/js/release/*': No such file or directory

[Hubert Chathi]

It looks like the relevant part of the log is:

,
| nodejs tools/build.js --release --no-minify
| module.js:549
| throw err;
| ^
| 
| Error: Cannot find module 'acorn/walk'
| ...
`

It looks like acorn moved some things around, and acorn/walk is now
acorn/dist/walk.  It seems to work fine after updating the
debian/patches/walk.patch to point to the new location.

-- 
Hubert Chathi  -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Bug#895949: lintian: warn about packages with udebs but no udeb line in shlibs

[Chris Lamb]

tags 895949 + moreinfo
thanks

Emilio wrote:

> I'd approach this in this way (in pseudocode):
> […]
> Hope that's clear. If not, please let me know.

Thanks!

Like the other outstanding Lintian wishlist issue regarding shlibs,
I was wondering if you could provide "good" and "bad" testcases for
this?

Again, I'm fairly sure I know what you are after but seeing some
concrete examples would be absolutely ideal.


Best wishes,

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

Bug#897919: manpages-de: Missing attribution in systemd-socket-activate(1)

[Helge Kreutzmann]

Package: manpages-de
Version: 2.5-1~bpo9+1
Severity: minor

When looking at systemd-socket-activate(1) the page is clearly
localized, however looking at the attribution I see:

   Die deutsche Übersetzung dieser Handbuchseite wurde von

   erstellt.

For other pages, the entry is filled in. Here I actually would 
expect my name to be stated :-))

-- 
  Dr. Helge Kreutzmann deb...@helgefjell.de
   Dipl.-Phys.   http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
   Help keep free software "libre": http://www.ffii.de/


signature.asc
Description: Digital signature

Bug#894870: lintian could ask maintainers to use dh_auto_*

[Chris Lamb]

tags 894870 + moreinfo
thanks

Hi Helmut,

> > Now it reads more like this mail should have gone to d-devel.
>
> Hmm, yes I think that would be the best "next step" at this point.

How did you get on with this? :)


Regards,

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

Bug#889816: lintian: Complain when epoch has been bumped but upstream version did not go backwards

[Chris Lamb]

tags 889816 + moreinfo
thanks

Hi Raphaël,

> lintian: Complain when epoch has been bumped but upstream version did not go 
> backwards

Could you provide some concrete "good" and "bad" cases? I'm pretty
sure I know what you're after here but want to be 100% certain,
especially if we want this to be an "error". :)


Best wishes,

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

Bug#897608: lintian: warn that debug symbol migration is complete

[Graham Inggs]

On 4 May 2018 at 01:16, Chris Lamb  wrote:
> Could you have an initial stab at the description for this tag and,
> perhaps, a suggested severity level? :-)

I: auto-dbgsym-migration-possibly-complete

debian/rules contains 'dh_strip --dbgsym-migration' (formerly
'--ddeb-migration')

Automatic debug symbol packages first became available in December 2015.

If the dh_strip command migrating manual '-dbg' packages to '-dbgsym'
was added to debian/rules and the package was included in Stretch,
then the command, and possibly 'override_dh_strip', may now be
removed.  If the command was only added later, and/or the package was
not included in Stretch, please wait until it has been included in a
stable release before removing it.

Further information:
https://wiki.debian.org/AutomaticDebugPackages

Bug#896840: lintian: testsuite failures with file 5.33

[Chris Lamb]

tags 896840 + pending
thanks

Hi all,

> lintian: testsuite failures with file 5.33

Just went to look into this further and realised that I had lost:

  < dwfreed>  lamby: "pie executable" did not exist as a possible output
  of file before this release
< lamby>  dwfreed: Can you followup to the bug? Head is elsewhere and
  not caffeinated enough for context switching yet


Anyway, with this, I've fixed this in git, now pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/3c6c2f2d7c0598f6b1b7ed937b8d29d49f0e502c

  checks/binaries.pm  |  4 ++--
  checks/shared-libs.pm   |  3 ++-
  debian/changelog| 10 +-
  t/tests/binaries-libc-link/desc |  1 -
  t/tests/legacy-libbaz/desc  |  2 +-
  5 files changed, 10 insertions(+), 10 deletions(-)


Regards,

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

Bug#897671: u-boot does not work on sheevaplug

[Markus Krebs]

Interesting thoughts, but: I tried again flashing both from within 
Debian and from u-boot (using ${filesize}). $filesize is accepted and 
flashing works, but the plug doesn't boot.
Flashing (again with $filesize, just to confirm it works) the u-boot 
from bodhi-linux (the one I was referring to) works, so it must be the 
u-boot.kwb in Debian which is broken.



Am 04.05.2018 um 19:11 schrieb Martin Michlmayr:

* Vagrant Cascadian  [2018-05-04 08:40]:

I do recall that there was some incompatible change regarding the
environment size on some of the marvell platforms, as u-boot.kwb grew
large enough to overwrite the environment section.

Uh, this might not be an u-boot issue then but a problem with my
upgrade instructions (although Markus said he tried to do the update
from within Debian too, so maybe not).

https://www.cyrius.com/debian/kirkwood/sheevaplug/uboot-upgrade/ says:
nand write 0x080 0x0 0x8

0x8 = 524288

but:
-rw-r--r-- 1 tbm tbm 599684 Apr  2 03:20 usr/lib/u-boot/sheevaplug/u-boot.kwb

so we're not writing the whole binary to flash.

The reason I used 0x8 instead of ${filesize} is because very old
u-boot versions (as originally shipped on the SheevaPlug) have
problems with ${filesize}:

 NAND write: device 0 offset 0x0, size 0x68ab0
 nand_write_ecc: Attempt to write not page aligned data
  0 bytes written: ERROR

Bug#897627: tex: please support SOURCE_DATE_EPOCH for dvi too

[Hilmar Preuße]

On 04.05.2018 13:38, Bill Allombert wrote:

Hi Bill,

> Maybe this could be documented in the manpage ? There is already:
> 
> BUGS
>This version of TeX implements a number of optional extensions.
>   In fact, many of these extensions  conflict  to  a  greater or lesser
>   extent with the definition of TeX.  When such extensions are enabled,
>   the banner printed when TeX starts is  changed  to  print TeXk instead
>   of TeX.
> 
> I think it is likely that if this bug is closed without changes, someone
> else will open it again.
> 
How about the attached patch for tex.1?

Hilmar
-- 
#206401 http://counter.li.org
--- tex.1	2017-03-30 03:02:29.0 +0200
+++ tex.2	2018-05-04 20:25:46.053590373 +0200
@@ -474,6 +474,14 @@
 but when it does the generated
 .I DVI
 file will be invalid.
+.PP
+Notes for Debian developers: please keep in mind, that this version of
+the \*(TX interpreter ignores the
+.B SOURCE_DATE_EPOCH
+variable. Instead the current timestamp is written into the
+.I DVI
+file. If you need a reproducible time stamp, please use the pdf\*(TX
+interpreter, which is used e.g. by \*(LX.
 .\"=
 .SH "SEE ALSO"
 .BR mf (1),

Bug#859213: x11vnc: stack smashing detected: x11vnc terminated

[Alkis Georgopoulos]

I too tested the patch that changes the following 3 lines, and I no 
longer have x11vnc crashes. Please release that! :)



-   if (num > stack_list_len + blackouts) {
-   int n = 2*num;
+   if (num + blackouts > stack_list_len) {
+   int n = 2 * (num + blackouts);



-   for (i=0; ilength; i++) {
+   for (i = 0; i < req->length - sz_xConfigureWindowReq / 4 && i < 4; i++) 
{

Bug#888677: pdf-presenter-console: [regression] raster image rendering is really poor

[Andreas Bilke]

> Perhaps as an interrim measure, maybe a command line option and/or hot
> key to switch between modes would make sense?

I implemented https://github.com/pdfpc/pdfpc/pull/342. Could you have a
look if it satisfies your needs?

If a page has annotations, it is rendered without visible icons of the
annotations, in all other cases it uses the old way.


signature.asc
Description: PGP signature

Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

[Michael J. Redd]

Package: linux-image-4.9.0-6-amd64
Version: 4.9.88-1

Issue:
==

Kernel "linux-image-4.9.0-6-amd64," version 4.9.88-1, breaks systemd
startup of RPC, Kerberos KDC services. 

Description:


After upgrading to the latest Stretch kernel (4.9.88-1), RPC and KDC
services time out during the boot process. This issue is being seen on
a Kerberos KDC that is also an NFS client. Kerberos auth. and
encryption are being used with NFS in this environment, and this KDC
provides the Kerberos services for that to work.

Network is functional prior to these services starting, which is
proper.

After the server has booted completely, I can issue `service krb5-kdc
restart` and, after a short delay, the KDC service starts normally.

Not sure if this is a kernel bug, a systemd bug, or something else.
Since the kernel package was the only thing that was upgraded before
the issue started, I'm leaning toward the kernel.

Relevant output from /var/log/syslog:
-

May  4 09:03:17  systemd[1]: rpc-svcgssd.service: Start
operation timed out. Terminating.
May  4 09:03:17  systemd[1]: Failed to start RPC security
service for NFS server.
May  4 09:03:17  systemd[1]: rpc-svcgssd.service: Unit
entered failed state.
May  4 09:03:17  systemd[1]: rpc-svcgssd.service: Failed with
result 'timeout'.
May  4 09:03:17  systemd[1]: rpc-gssd.service: Start
operation timed out. Terminating.
May  4 09:03:17  systemd[1]: Failed to start RPC security
service for NFS client and server.
May  4 09:03:17  systemd[1]: rpc-gssd.service: Unit entered
failed state.
May  4 09:03:17  systemd[1]: rpc-gssd.service: Failed with
result 'timeout'.
May  4 09:03:20  systemd[1]: krb5-kdc.service: Start
operation timed out. Terminating.
May  4 09:03:20  systemd[1]: Failed to start Kerberos 5 Key
Distribution Center.
May  4 09:03:20  systemd[1]: krb5-kdc.service: Unit entered
failed state.29s random time.
May  4 09:03:20  systemd[1]: krb5-kdc.service: Failed with
result 'timeout'. random time.

Workaround:
===

Rolling back to Stretch kernel 4.9.82-1+deb9u3 fixes the issue.

Setup:
==

1. KDC package: krb5-kdc 1.15-1+deb9u1
2. NFS package: nfs-common 1:1.3.4-2.1
3. Kernel: linux-image-4.9.0-6-amd64 4.9.88-1
4. Systemd version: 232-25+deb9u3
5. Server is a 64-bit Xen PV domU

Bug#897449: django-allauth: Invalid character reference 138 in "Last Translator" field in some .po files (Bug#881727 reappeared when uploading 0.35 version)

[Pierre-Elliott Bécue]

Le 4 mai 2018 20:05:52 GMT+02:00, Laura Arjona Reina  a 
écrit :
>Hello again
>I have sent a Pull Request (#2017) to the upstream project fixing the
>string of the translator name:
>https://github.com/pennersr/django-allauth/pull/2017
>
>Cheers

I referenced the issue I opened months ago in your MR.

You can close the bug as soon as you wish.

Sorry for all this.

Cheers ! 
-- 
PEB

Bug#897915: lintian -- False positive on orphaned-package-not-maintained-in-debian-infrastructure

[Chris Lamb]

tags 897915 + pending
thanks

Fixed in Git, pending upload:

  
https://salsa.debian.org/lintian/lintian/commit/999a659122e2b328fb6823978640e3a7d5f91f7e

  checks/fields.pm   |  4 ++--
  debian/changelog   |  3 +++
  .../debian/debian/changelog.in |  7 +++
  .../debian/debian/control.in   | 18 ++
  .../desc   |  6 ++
  .../tags   |  0
  6 files changed, 36 insertions(+), 2 deletions(-)


Regards,

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

Bug#897449: django-allauth: Invalid character reference 138 in "Last Translator" field in some .po files (Bug#881727 reappeared when uploading 0.35 version)

[Laura Arjona Reina]

Hello again
I have sent a Pull Request (#2017) to the upstream project fixing the
string of the translator name:
https://github.com/pennersr/django-allauth/pull/2017

Cheers

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

Bug#897449: django-allauth: Invalid character reference 138 in "Last Translator" field in some .po files (Bug#881727 reappeared when uploading 0.35 version)

[Laura Arjona Reina]

Hello Pierre-Elliot

El 04/05/18 a las 13:52, Pierre-Elliott Bécue escribió:
> So, I wonder, maybe this error is triggered because the *source* actually
> still contains this wrongfully encoded character? But theoretically I'm not
> supposed to alter upstream's source.
>
Yes, that seems to be the case: I think our gen-material scripts don't
handle well the application of patches for packages with format 3.0 (quilt).
This is reported in bug #748716.

I'm excluding django-allauth from the l10n stats generation until
#748716 is solved, or upstream fixes the bad-encoded string.

Should I close this bug?

Thanks for your help

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

Bug#897916: group plugdev is deprecated

[Michael Biebl]

Package: base-passwd
Version: 3.5.45
Severity: normal

base-passwd contains this about group plugdev:

plugdev

Members of this group can access removable devices in limited ways without
explicit configuration in /etc/fstab. This is useful for local users who
expect to be able to insert and use CDs, USB drives, and so on.

Since pmount (the original implementor of group plugdev) always mounts with
the nodev and nosuid options and applies other checks, this group is not
intended to be root-equivalent in the ways that the ability to mount
filesystems might ordinarily allow. Implementors of semantics involving
this group should be careful not to allow root-equivalence.

This is outdated information, I'd argue.
Desktops nowadays use udisks to mount removable media and udisks does
not use group plugdev anymore (it uses PolicyKit and the concept of
local users instead, as determined by logind).

I wonder if we shouldn't just drop group plugdev altogether and no
longer create it by default, although this is probably going to be
tricky. At the very least, we should mention that it is deprecated and
no longer actively used.
I mostly see group plugdev being used in a couple of udev rules files. I
wonder if we shouldn't advocate the usage of udev/loginds "uaccess".

CCed Martin, as original author of pmount.

Regards,
Michael

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

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

Versions of packages base-passwd depends on:
ii  libc6  2.27-3
ii  libdebconfclient0  0.243

Versions of packages base-passwd recommends:
ii  debconf [debconf-2.0]  1.5.66

base-passwd suggests no packages.

-- debconf information excluded