Bug#928351: unblock dhcpcd5/7.1.0-2

[Scott Leggett]

Control: tags -1 - moreinfo

On 2019-05-06.22:23, Paul Gevers wrote:
> Please go ahead and upload. Remove the moreinfo tag when you package is
> available in unstable.

Hi Paul,

Package is in unstable.
Thanks for your help getting this resolved.

-- 
Regards,
Scott Leggett.


signature.asc
Description: PGP signature

Bug#928641: tiger: /usr/lib/tiger/systems/Linux/ will need symlink for kernel version 5

[tv.deb...@googlemail.com]

Package: tiger
Version: 1:3.2.4~rc1-1
Severity: wishlist

Dear Maintainer,

when linux-image is bumped to version 5+ Tiger will need a new symlink 
in /usr/lib/tiger/systems/Linux/.


This is to prevent bug #785589 "tiger: "Don't have required command 
DIFF" on Linux 4" to happen again for version 5 which I am running 
locally. The patch attached to #785589 modified for linux 5 works.


Thanks.


-- System Information:
Debian Release: 10.0
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.0-deb64 (SMP w/16 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US (charmap=UTF-8)

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

Versions of packages tiger depends on:
ii  binutils   2.31.1-16
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.72
ii  libc6  2.28-10
ii  net-tools  1.60+git20180626.aebd88e-1
ii  ucf3.0038+nmu1

Versions of packages tiger recommends:
ii  chkrootkit  0.52-3+b10
ii  john1.8.0-2+b1
ii  postfix [mail-transport-agent]  3.4.5-1
pn  tripwire | aide 

Versions of packages tiger suggests:
ii  lsof  4.91+dfsg-1

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/lib/tiger/systems/default/config (from tiger 
package)

Bug#928640: tiger: Typo in /usr/lib/tiger/systems/default/config line 127

[tv.deb...@googlemail.com]

Package: tiger
Version: 1:3.2.4~rc1-1
Severity: minor

Dear Maintainer,

 Hello,

there is a typo on line 127 in /usr/lib/tiger/systems/default/config, 
the line reads:


"expot  MAILE MD5SUM"

and should read:

"export  MAILE MD5SUM"

The "r" from "export" is missing.

Thanks.



-- System Information:
Debian Release: 10.0
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.1.0-deb64 (SMP w/16 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr:en_US (charmap=UTF-8)

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

Versions of packages tiger depends on:
ii  binutils   2.31.1-16
ii  bsdmainutils   11.1.2+b1
ii  debconf [debconf-2.0]  1.5.72
ii  libc6  2.28-10
ii  net-tools  1.60+git20180626.aebd88e-1
ii  ucf3.0038+nmu1

Versions of packages tiger recommends:
ii  chkrootkit  0.52-3+b10
ii  john1.8.0-2+b1
ii  postfix [mail-transport-agent]  3.4.5-1
pn  tripwire | aide 

Versions of packages tiger suggests:
ii  lsof  4.91+dfsg-1

-- debconf information excluded

-- debsums errors found:
debsums: changed file /usr/lib/tiger/systems/default/config (from tiger 
package)

Bug#670585: "ok hat location is writable"

[Dmitry Bogatov]

[2019-05-06 07:33] Tito 
> [ Dmitry Bogatov ]
> > -   log_success_msg "Done checking file systems.
> > -A log is being saved in ${FSCK_LOGFILE} if that location is writable."
> > +   log_success_msg 'Done checking file systems'
> > +   log_success_msg "Log is being saved in 
> > ${FSCK_LOGFILE} if that location is writable"
> > fi
> > fi

> Hi,
> maybe something like:
>
> if test -w ${FSCK_LOGFILE} ; then
>   log_success_msg "Log is saved in ${FSCK_LOGFILE}
> else
>   log_success_msg "Cannot save log in ${FSCK_LOGFILE}
> fi

Thank you, Tito. But I am not sure this is correct:

As I understand the whole point of "logsave" is that if directory of
logfile (/var/log/fsck) does not exist, "logsave" will wait till it
appears.

So, by the time we are logging this message, ${FSCK_LOGFILE} may not
exists yet, but its future content is hanging somewhere in memory of
"logsave" process.

Problem is that I do not understand, when /var/log/fsck exist for sure.

Collegues, I need help with evaluating proposed change.
-- 
Note, that I send and fetch email in batch, once every 24 hours.
 If matter is urgent, try https://t.me/kaction
 --

Bug#870152: nasm: Make source package bootstrappable

[Helmut Grohne]

Source: nasm
Version: 2.14-1
Followup-For: Bug #870152
Control: severity -1 important
Control: tags -1 + patch

In the mean time, nasm no longer installs the documentation from the
doc folder. This can be verified by dropping the separate make
invocation from debian/rules and using diffoscope to compare the
resulting binary packages. Thus we can drop the ghostscript dependency
at no loss of functionality resolving the bootstrap cycles. Please
consider applying the attached patch.

In case you have to add documentation built by ghostscript again.
Please consider adding an arch:all nasm-doc binary package and putting
the relevant dependencies into Build-Depends-Indep. Doing so avoids the
need for build profiles.

Helmut
diff --minimal -Nru nasm-2.14/debian/changelog nasm-2.14/debian/changelog
--- nasm-2.14/debian/changelog  2018-11-18 07:22:52.0 +0100
+++ nasm-2.14/debian/changelog  2019-05-08 06:02:02.0 +0200
@@ -1,3 +1,10 @@
+nasm (2.14-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Don't build documentation. Not shipped anymore. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 08 May 2019 06:02:02 +0200
+
 nasm (2.14-1) unstable; urgency=medium
 
   * d/patches: Rebase patches for 2.14
diff --minimal -Nru nasm-2.14/debian/control nasm-2.14/debian/control
--- nasm-2.14/debian/control2018-11-16 09:13:29.0 +0100
+++ nasm-2.14/debian/control2019-05-08 06:02:02.0 +0200
@@ -10,7 +10,6 @@
  dpkg-dev (>= 1.16.1~),
  fonts-liberation2,
  fontconfig,
- ghostscript,
  libfont-ttf-perl,
  libsort-versions-perl,
  texinfo,
diff --minimal -Nru nasm-2.14/debian/rules nasm-2.14/debian/rules
--- nasm-2.14/debian/rules  2018-05-20 03:24:05.0 +0200
+++ nasm-2.14/debian/rules  2019-05-08 06:02:02.0 +0200
@@ -9,10 +9,6 @@
 %:
dh $@
 
-override_dh_auto_build:
-   dh_auto_build
-   $(MAKE) doc
-
 # empty override, fills example directory with lots of files
 override_dh_auto_test:
 

Bug#855124: geis-tools: geisview segfaults when run

[Bernhard Übelacker]

Control: found 855124 2.2.17-1.1+b1
Control: fixed 855124 2.2.17-1.2+b1


Dear Maintainer,
this issue seems to be a problem with the default python
pointer/int sizes which seem to default
to 32 bit in stretch on amd64.
Attached patch tries to declare these to avoid the crashes.

For some reason this issue does not show up with a system
running with packages from unstable.

Kind regards,
Bernhard
From fb93de8120eafbe47e37038fbcdfb1232e8daee0 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Wed, 8 May 2019 05:19:11 +0200
Subject: [PATCH] Add parameter and return type sizes for 64 bit systems.

https://bugs.debian.org/855124
---
 python/geis/geis_v2.py | 39 ---
 1 file changed, 32 insertions(+), 7 deletions(-)

diff --git a/python/geis/geis_v2.py b/python/geis/geis_v2.py
index edd8063..793355f 100644
--- a/python/geis/geis_v2.py
+++ b/python/geis/geis_v2.py
@@ -62,24 +62,40 @@ try:
 _geis_new.errcheck = _check_null
 _geis_delete = _geis_lib.geis_delete
 _geis_get_configuration = _geis_lib.geis_get_configuration
+_geis_get_configuration.argtypes = [ ctypes.c_void_p, ctypes.c_char_p ]
 _geis_dispatch_events = _geis_lib.geis_dispatch_events
+_geis_dispatch_events.argtypes = [ ctypes.c_void_p ]
 _geis_register_class_callback = _geis_lib.geis_register_class_callback
 _geis_register_device_callback = _geis_lib.geis_register_device_callback
 _geis_register_event_callback = _geis_lib.geis_register_event_callback
 _geis_next_event = _geis_lib.geis_next_event
+_geis_next_event.argtypes = [ ctypes.c_void_p, ctypes.c_void_p ]
 
 _geis_subscription_new = _geis_lib.geis_subscription_new
 _geis_subscription_new.restype = ctypes.c_void_p
+_geis_subscription_new.argtypes = [ ctypes.c_void_p, ctypes.c_char_p, ctypes.c_int ]
 _geis_subscription_new.errcheck = _check_null
 _geis_subscription_delete = _geis_lib.geis_subscription_delete
 _geis_subscription_activate = _geis_lib.geis_subscription_activate
+_geis_subscription_activate.argtypes = [ ctypes.c_void_p ]
 _geis_subscription_deactivate = _geis_lib.geis_subscription_deactivate
 _geis_subscription_name = _geis_lib.geis_subscription_name
+_geis_subscription_add_filter = _geis_lib.geis_subscription_add_filter
+_geis_subscription_add_filter.argtypes = [ ctypes.c_void_p, ctypes.c_void_p ]
 
 _geis_attr_name = _geis_lib.geis_attr_name
 _geis_attr_name.restype = ctypes.c_char_p
+_geis_attr_name.argtypes = [ ctypes.c_void_p ]
 _geis_attr_type = _geis_lib.geis_attr_type
+_geis_attr_type.argtypes = [ ctypes.c_void_p ]
 _geis_attr_value_to_pointer = _geis_lib.geis_attr_value_to_pointer
+_geis_attr_value_to_pointer.restype = ctypes.c_void_p
+_geis_attr_value_to_pointer.argtypes = [ ctypes.c_void_p ]
+_geis_attr_value_to_string = _geis_lib.geis_attr_value_to_string
+_geis_attr_value_to_string.restype = ctypes.c_char_p
+_geis_attr_value_to_string.argtypes = [ ctypes.c_void_p ]
+_geis_attr_value_to_integer = _geis_lib.geis_attr_value_to_integer
+_geis_attr_value_to_integer.argtypes = [ ctypes.c_void_p ]
 
 _geis_event_type = _geis_lib.geis_event_type
 _geis_event_attr_count = _geis_lib.geis_event_attr_count
@@ -89,10 +105,14 @@ try:
 _geis_gesture_class_unref = _geis_lib.geis_gesture_class_unref
 _geis_gesture_class_name = _geis_lib.geis_gesture_class_name
 _geis_gesture_class_name.restype = ctypes.c_char_p
+_geis_gesture_class_name.argtypes = [ ctypes.c_void_p ]
 _geis_gesture_class_id = _geis_lib.geis_gesture_class_id
+_geis_gesture_class_id.argtypes = [ ctypes.c_void_p ]
 _geis_gesture_class_attr_count = _geis_lib.geis_gesture_class_attr_count
+_geis_gesture_class_attr_count.argtypes = [ ctypes.c_void_p ]
 _geis_gesture_class_attr = _geis_lib.geis_gesture_class_attr
 _geis_gesture_class_attr.restype = ctypes.c_void_p
+_geis_gesture_class_attr.argtypes = [ ctypes.c_void_p ]
 
 _geis_device_ref = _geis_lib.geis_device_ref
 _geis_device_unref = _geis_lib.geis_device_unref
@@ -125,6 +145,13 @@ try:
 _geis_frame_is_class = _geis_lib.geis_frame_is_class
 _geis_frame_touchid_count = _geis_lib.geis_frame_touchid_count
 _geis_frame_touchid = _geis_lib.geis_frame_touchid
+
+_geis_filter_new = _geis_lib.geis_filter_new
+_geis_filter_new.restype = ctypes.c_void_p
+_geis_filter_new.argtypes = [ ctypes.c_void_p, ctypes.c_char_p ]
+_geis_filter_add_term = _geis_lib.geis_filter_add_term
+_geis_filter_add_term.argtypes = [ ctypes.c_void_p, ctypes.c_int ]
+
 
 except AttributeError as ex:
 print(ex)
@@ -399,7 +426,7 @@ def _attr_type_float(attr):
 def _attr_type_integer(attr):
 """ Extracts an attribute value as a integer.
 """
-return _geis_lib.geis_attr_value_to_integer(attr)
+return _geis_attr_value_to_integer(attr)
 
 
 def _attr_type_pointer(attr):
@@ -412,9 +439,7 @@ def 

Bug#928304: groonga-httpd: Privilege escalation due to insecure use of logrotate

[Hideki Yamane]

Hi Salvatore,

 Can you follow his question? I guess debian revision should be
 6.1.5-1+deb9u1, but others are okay.


On Tue, 7 May 2019 23:15:58 +0900
Kentaro Hayashi  wrote:
> I maintain Groonga package as a DM, so I want to fix #928304.
> But I've never uploaded package to stable before, so I need help
>  to do it in a good manner.
> 
> I've attached debdiff against current version.
> Is it ok to upload stretch-security?



diff -Nru groonga-6.1.5/debian/changelog groonga-6.1.5/debian/changelog
--- groonga-6.1.5/debian/changelog  2017-01-23 19:14:09.0 +0900
+++ groonga-6.1.5/debian/changelog  2019-05-07 22:33:11.0 +0900
@@ -1,3 +1,13 @@
+groonga (6.1.5-2) stretch-security; urgency=medium
+
+  * debian/groonga-httpd.logrotate
+debian/groonga-server-gqtp.logrotate
+- Mitigate privilege escalation by changing the owner and group of logs
+  with "su" option. Reported by Wolfgang Hotwagner.
+  (Closes: #928304) (CVE-2019-11675)
+
+ -- Kentaro Hayashi   Tue, 07 May 2019 22:33:11 +0900
+
 groonga (6.1.5-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru groonga-6.1.5/debian/groonga-httpd.logrotate 
groonga-6.1.5/debian/groonga-httpd.logrotate
--- groonga-6.1.5/debian/groonga-httpd.logrotate2016-12-10 
15:18:50.0 +0900
+++ groonga-6.1.5/debian/groonga-httpd.logrotate2019-05-07 
22:33:11.0 +0900
@@ -1,11 +1,11 @@
 /var/log/groonga/httpd/*.log {
+su groonga groonga
 daily
 missingok
 rotate 30
 compress
 delaycompress
 notifempty
-create 640 groonga groonga
 sharedscripts
 postrotate
 . /etc/default/groonga-httpd
diff -Nru groonga-6.1.5/debian/groonga-server-gqtp.logrotate 
groonga-6.1.5/debian/groonga-server-gqtp.logrotate
--- groonga-6.1.5/debian/groonga-server-gqtp.logrotate  2016-12-10 
15:18:50.0 +0900
+++ groonga-6.1.5/debian/groonga-server-gqtp.logrotate  2019-05-07 
22:33:11.0 +0900
@@ -1,11 +1,11 @@
 /var/log/groonga/*-gqtp.log {
+su groonga groonga
 daily
 missingok
 rotate 30
 compress
 delaycompress
 notifempty
-create 640 groonga groonga
 sharedscripts
 postrotate
 . /etc/default/groonga-server-gqtp

Bug#928639: unblock: mecab-ipadic_2.7.0-20070801+main-2.1

[NOKUBI Takatsugu]

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

Unblock mecab-ipadic please.
New package contains Japanese new era "reiwa" entry,
and it is now in use.

(in particular, Japanese encoding is EUC-JP, not UTF-8)

diff --git a/debian/changelog b/debian/changelog
index 220ee59..0560459 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+mecab-ipadic (2.7.0-20070801+main-2.1) unstable; urgency=medium
+
+  * d/p/0001-new-Japanese-era-reiwa-entry.patch: Reiwa entry
+
+ -- NOKUBI Takatsugu   Sat, 20 Apr 2019 16:58:21 +0900
+
 mecab-ipadic (2.7.0-20070801+main-2) unstable; urgency=medium
 
   * Team upload.
diff --git a/debian/patches/0001-new-Japanese-era-reiwa-entry.patch 
b/debian/patches/0001-new-Japanese-era-reiwa-entry.patch
new file mode 100644
index 000..2391cb1
--- /dev/null
+++ b/debian/patches/0001-new-Japanese-era-reiwa-entry.patch
@@ -0,0 +1,17 @@
+From: NOKUBI Takatsugu 
+Date: Sat, 20 Apr 2019 16:57:44 +0900
+Subject: new Japanese era reiwa entry
+
+---
+ Noun.proper.csv | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/Noun.proper.csv b/Noun.proper.csv
+index c805de3..3581fd0 100644
+--- a/Noun.proper.csv
 b/Noun.proper.csv
+@@ -27325,3 +27325,4 @@
+ 桃ノ木鼻,1288,1288,8538,名詞,固有名詞,一般,*,*,*,桃ノ木鼻,モモノキハナ,モモノキハナ
+ ドウ坂,1288,1288,3765,名詞,固有名詞,一般,*,*,*,ドウ坂,ドウザカ,ドーザカ
+ 戸城山,1288,1288,8538,名詞,固有名詞,一般,*,*,*,戸城山,トシロヤマ,トシロヤマ
++令和,1288,1288,5904,名詞,固有名詞,一般,*,*,*,令和,レイワ,レイワ
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..7c4ad24
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+0001-new-Japanese-era-reiwa-entry.patch

Bug#928638: unblock: anthy 1:0.3-8.1

[NOKUBI Takatsugu]

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

Unblock anthy please.
New package contains Japanese new era "reiwa" entry,
and it is now in use.

diff --git a/debian/changelog b/debian/changelog
index b7b8f34..b6edd27 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+anthy (1:0.3-8.1) unstable; urgency=medium
+
+  * d/p/0002-new-Japanese-era-reiwa-entry.patch: Reiwa entry
+
+ -- NOKUBI Takatsugu   Sat, 20 Apr 2019 16:34:38 +0900
+
 anthy (1:0.3-8) unstable; urgency=medium
 
   * debian/patches/0001-work-with-emacs-24.3.1.patch: Re-add from
diff --git a/debian/patches/0002-new-Japanese-era-reiwa-entry.patch 
b/debian/patches/0002-new-Japanese-era-reiwa-entry.patch
new file mode 100644
index 000..86a2edb
--- /dev/null
+++ b/debian/patches/0002-new-Japanese-era-reiwa-entry.patch
@@ -0,0 +1,21 @@
+From: NOKUBI Takatsugu 
+Date: Sat, 20 Apr 2019 16:30:04 +0900
+Subject: new Japanese era reiwa entry
+
+---
+ alt-cannadic/gcanna.t | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/alt-cannadic/gcanna.t b/alt-cannadic/gcanna.t
+index 960ebb9..43927fc 100644
+--- a/alt-cannadic/gcanna.t
 b/alt-cannadic/gcanna.t
+@@ -134761,7 +134761,7 @@
+ れいれいしめ #T15*10 麗々しめ 麗麗しめ
+ れいれいしゅう #KYU*10 麗々しゅう 麗麗しゅう
+ れいろう #F02*200 玲瓏
+-れいわ #T35*150 例話
++れいわ #T35*200 令和 #T35*150 例話
+ れいをい #W5*200 礼を言
+ れいん #T35*300 レイン #JN*100 レイン
+ れいんうぇあ #T35*250 レインウェア
diff --git a/debian/patches/series b/debian/patches/series
index 0e2ff2a..1590384 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 0001-work-with-emacs-24.3.1.patch
+0002-new-Japanese-era-reiwa-entry.patch

Bug#928637: RFS: emacs-neotree/0.5.2-1 [ITP]

[Nicholas D Steeves]

Package: sponsorship-requests
Severity: wishlist
Control: block 872873 by -1

I am looking for a sponsor for my package "emacs-neotree".  Neotree is
a very popular Emacs addon on MELPA (Emacs addon repository), and is
at the 99th percentile for MELPA unstable, and the 98th for MELPA stable.

  https://melpa.org/#/neotree
  https://stable.melpa.org/#/neotree

Package name: emacs-neotree
Version : 0.5.2-1
Upstream Author : jaypei 
URL : https://github.com/jaypei/emacs-neotree
License : GPL-3+
Section : lisp

It builds this binary package:

elpa-neotree - directory tree sidebar for Emacs that is like NERDTree for 
Vim

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

  https://mentors.debian.net/package/emacs-neotree


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

dget -x 
https://mentors.debian.net/debian/pool/main/e/emacs-neotree/emacs-neotree_0.5.2-1.dsc


Regards,
Nicholas

Bug#928636: doc-base: add support for GNOME's yelp's "All Help" index

[Paul Wise]

Package: doc-base
Severity: wishlist

Please add support for registering documents in GNOME's yelp's
"All Help" index so that GNOME users can read all documents registered
in doc-base. It looks like yelp supports only DocBook, Mallard, HTML,
man and info, so other formats like PDF need to be converted.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#928635: doc-base: remove support for scrollkeeper/rarian

[Paul Wise]

Package: doc-base
Severity: normal

Both scrollkeeper and rarian have been removed from Debian, doc-base
should drop support for both of these and the package should clean up
any files related to them on upgrade.

-- System Information:
Debian Release: buster/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

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

Versions of packages doc-base depends on:
pn  libuuid-perl   
ii  libyaml-tiny-perl  1.73-1

doc-base recommends no packages.

Versions of packages doc-base suggests:
pn  rarian-compat  
ii  yelp   3.31.90-1

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#928634: nvidia-legacy-390xx-kernel-source: Fails to build with kernel 5.1

[Kevin Locke]

Package: nvidia-legacy-390xx-kernel-source
Version: 390.116-1
Severity: normal
Tags: patch

Dear Maintainer,

nvidia-legacy-390xx-kernel fails to build with Linux 5.1 due to errors
such as the following:

/usr/src/modass/usr_src/modules/nvidia-legacy-390xx-kernel/common/inc/nv-list-helpers.h:94:19:
 error: redefinition of ‘list_is_first’
 static inline int list_is_first(const struct list_head *list,
   ^
In file included from ./include/linux/preempt.h:11,
 from ./include/linux/spinlock.h:51,
 from 
/usr/src/modass/usr_src/modules/nvidia-legacy-390xx-kernel/common/inc/nv-lock.h:16,
 from 
/usr/src/modass/usr_src/modules/nvidia-legacy-390xx-kernel/common/inc/nv-linux.h:19,
 from 
/usr/src/modass/usr_src/modules/nvidia-legacy-390xx-kernel/nvidia/nv-frontend.c:13:
./include/linux/list.h:214:19: note: previous definition of ‘list_is_first’ was 
here
 static inline int list_is_first(const struct list_head *list,
   ^

Presumably this will be fixed by the next release in the 390 series.
Until then, I have attached a patch with the minimal necessary changes
backported from 418.74.  I compiled and tested (by running some
graphics-intensive workloads) the module on an amd64 system, but have
not tested on arm or i386.

Best,
Kevin


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

Kernel: Linux 5.1.0 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages nvidia-legacy-390xx-kernel-source depends on:
pn  debhelper-compat  
ii  make  4.2.1-1.2
ii  quilt 0.65-3
ii  xz-utils  5.2.4-1

Versions of packages nvidia-legacy-390xx-kernel-source recommends:
ii  module-assistant0.11.10
ii  nvidia-legacy-390xx-kernel-support  390.116-1

Versions of packages nvidia-legacy-390xx-kernel-source suggests:
ii  nvidia-legacy-390xx-driver  390.116-1

Versions of packages nvidia-legacy-390xx-driver depends on:
ii  nvidia-installer-cleanup 20151021+9
ii  nvidia-legacy-390xx-alternative  390.116-1
ii  nvidia-legacy-390xx-driver-bin   390.116-1
ii  nvidia-legacy-390xx-driver-libs  390.116-1
ii  nvidia-legacy-390xx-kernel-5.0.8 [nvidia-legacy-390xx-k  390.116-1+5.0.8-9
ii  nvidia-legacy-390xx-kernel-5.1.0 [nvidia-legacy-390xx-k  390.116-1+5.1.0-11
ii  nvidia-legacy-390xx-vdpau-driver 390.116-1
ii  nvidia-support   20151021+9
ii  xserver-xorg-video-nvidia-legacy-390xx   390.116-1

Versions of packages nvidia-legacy-390xx-driver recommends:
ii  libnvidia-legacy-390xx-cfg1   390.116-1
pn  nvidia-persistenced   
ii  nvidia-settings-legacy-390xx  390.116-1

nvidia-legacy-390xx-driver suggests no packages.

Versions of packages nvidia-legacy-390xx-driver-libs:amd64 depends on:
ii  libgl1-nvidia-legacy-390xx-glvnd-glx  390.116-1
ii  nvidia-legacy-390xx-egl-icd   390.116-1

Versions of packages nvidia-legacy-390xx-driver-libs:amd64 recommends:
ii  libgles-nvidia-legacy-390xx1  390.116-1
ii  libgles-nvidia-legacy-390xx2  390.116-1
ii  libglx-nvidia-legacy-390xx0   390.116-1
ii  libnvidia-legacy-390xx-cfg1   390.116-1
ii  libopengl01.1.0-1
pn  nvidia-legacy-390xx-driver-libs-i386  
ii  nvidia-legacy-390xx-vulkan-icd390.116-1

Versions of packages xserver-xorg-video-nvidia-legacy-390xx depends on:
ii  libc6  2.28-10
ii  libnvidia-legacy-390xx-glcore  390.116-1
ii  nvidia-installer-cleanup   20151021+9
ii  nvidia-legacy-390xx-alternative390.116-1
ii  nvidia-support 20151021+9
ii  xserver-xorg-core [xorg-video-abi-24]  2:1.20.3-1

Versions of packages xserver-xorg-video-nvidia-legacy-390xx recommends:
ii  nvidia-legacy-390xx-driver   390.116-1
ii  nvidia-legacy-390xx-kernel-5.0.8 [nvidia-legacy-390xx-k  390.116-1+5.0.8-9
ii  nvidia-legacy-390xx-kernel-5.1.0 [nvidia-legacy-390xx-k  390.116-1+5.1.0-11
ii  nvidia-legacy-390xx-vdpau-driver 390.116-1
ii  nvidia-settings-legacy-390xx 390.116-1

xserver-xorg-video-nvidia-legacy-390xx suggests no packages.

Versions of packages nvidia-legacy-390xx-alternative depends on:
ii  dpkg1.19.6
ii  glx-alternative-nvidia  1.0.0

Versions of packages glx-alternative-nvidia depends on:
ii  dpkg  1.19.6
ii  

Bug#928632: ITP: libdevel-findperl-perl -- Perl module to find the path to the currently running perl

[Joenio Costa]

Package: wnpp
Severity: wishlist
Owner: Joenio Costa 

* Package name: libdevel-findperl-perl
  Version : 0.015
  Upstream Author : Leon Timmermans , Randy Sims 

* URL : https://metacpan.org/release/Devel-FindPerl
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Perl module to find the path to the currently running perl

The Devel::FindPerl module tries to find the path to the currently running
perl. It implements a function to try (really really hard) to find the path to
the perl running your program and another function to test if the perl in
`$path` is the same perl as the currently running one.

SECURITY ALERT: This module by default does things that are not particularly
secure (run programs based on external input).

Bug#926326: elpa-elpy: configuration issues

[Nicholas D Steeves]

clone 926326 -1
retitle -1 elpa-elpy: please provide docs in html format
thanks

On Thu, Apr 25, 2019 at 01:04:18AM +0530, Faheem Mitha wrote:
> 
> Hi Nicholas,
> 
> On Sun, 14 Apr 2019, Nicholas D Steeves wrote:
> 
> > Dear Faheem,
> > 
> > Thank you for filing an excellent bug report that includes all
> > relevant information.  Reply follows in-line, but please take care to
> > reply to the appropriate sub-bugs that will be momentarily created:
> >  https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=elpa-elpy
> 
> Thank you for the kind words. I've noted the bug split. I'm not sure exactly
> what you want me to do regarding replying to the bugs, so I've CCed the
> original bug, as well as the three new sub-bugs that you created.
> 
> I could have split up my reply across the three different bugs, but that
> would be quite a lot of work, and might be confusing. I suggest followups
> for the relevant points from here on should just go to the relevant bugs.
>

In general (and especially during a freeze) it's better to do
one-issue-per-bug.  Please do not CC each bug...  The bts stores the
info for each cloned bug's common origin, which can be consulted
either using "bts show --mbox bug-number" or the link to a particular
bug's URL.  If using 'bts show --mbox' take care that replies go to
the cloned bug's email rather than to the common origin's email.


signature.asc
Description: PGP signature

Bug#928631: firmware-amd-graphics: Update to 20190502-1 causus hang of system directly after grub

[Diederik de Haas]

Package: firmware-amd-graphics
Version: 20190502-1
Severity: critical
Justification: breaks the whole system

Today's Sid update brought in new kernel and various firmware updates, 
after which I rebooted the system. Saw Grub loading, but after it 
started kernel 4.19.0-5-amd64, it stopped loading the system.

My Asus Crosshair VII system gave Q-code 8 as error, which stands for 
"System Agent initialization after microcode loading".
Also tried booting with 4.19.0-4-amd64, but got the same error

Started up my LiveRescueCD stick, downloaded 
firmware-amd-graphics_20190114-1_all.deb, copied it to /root/ of my
normal system, chrooted into it and did 
"dpkg -i firmware-amd-graphics_20190114-1_all.deb" and then rebooted my
system, which now did start as normally.

As this is the only change I did, I'm quite sure I'm reporting it
against the correct package (in contrast to what reportbug tried to tell
me).

I have reported another bug against amd64-microcode which may be
relevant: 924895. 
Slight addition: I do sometimes get the spontanous reboots.

System info:
MB: Asus ROG CROSSHAIR VII HERO (BIOS: 2203)
CPU: AMD Ryzen 7 1800X Eight-Core Processor (family: 0x17, model: 0x1, 
stepping: 0x1)
GPU: Asus ROG Strix RX VEGA64 OC edition 8GB
# lspci -vv -s 0c:00.0
0c:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Vega 
10 XL/XT [Radeon RX Vega 56/64] (rev c1) (prog-if 00 [VGA controller])
Subsystem: ASUSTeK Computer Inc. Vega 10 XL/XT [Radeon RX Vega 56/64]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [64] Express (v2) Legacy Endpoint, MSI 00
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 
unlimited
ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- 
Unsupported-
RlxdOrd+ ExtTag+ PhantFunc- AuxPwr- NoSnoop+
MaxPayload 256 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- 
TransPend-
LnkCap: Port #0, Speed 8GT/s, Width x16, ASPM L0s L1, Exit 
Latency L0s <64ns, L1 <1us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 8GT/s, Width x16, TrErr- Train- SlotClk+ 
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR+, 
OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, 
OBFF Disabled
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
 Transmit Margin: Normal Operating Range, 
EnterModifiedCompliance- ComplianceSOS-
 Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB, 
EqualizationComplete+, EqualizationPhase1+
 EqualizationPhase2+, EqualizationPhase3+, 
LinkEqualizationRequest-
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: fee0  Data: 
Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 
Len=010 
Capabilities: [150 v2] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- 
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [200 v1] #15
Capabilities: [270 v1] #19
Capabilities: [2a0 v1] Access Control Services
ACSCap: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- 
EgressCtrl- DirectTrans-
ACSCtl: SrcValid- TransBlk- ReqRedir- CmpltRedir- UpstreamFwd- 
EgressCtrl- DirectTrans-
Capabilities: [2b0 v1] Address Translation Service (ATS)
ATSCap: Invalidate Queue Depth: 00
ATSCtl: Enable+, Smallest Translation Unit: 00
Capabilities: [2c0 v1] Page Request Interface (PRI)
PRICtl: Enable- Reset-
PRISta: RF- UPRGI- Stopped+
   

Bug#907348: fixed in dateutils 0.4.5-1

[Bernhard Übelacker]

Control: tags 907348 + patch upstream


Dear Maintainer,
I tried to have a look and tracked it down into the file
lib/leap-seconds.def which is generated by ltrcc.

Unfortunately this generator seems not prepared for at least i386.

With attached patch the generated file is equal to one
generated at amd64, and the tests pass on both architectures.

Could not find an matching upstream bug.

Kind regards,
Bernhard
>From 6f653805ee528e9068d3108af7227dea685f88ed Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Tue, 7 May 2019 19:13:21 +0200
Subject: [PATCH] Use unsigned type for leap second conversion.

https://bugs.debian.org/907348
---
 lib/ltrcc.c | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/lib/ltrcc.c b/lib/ltrcc.c
index 20c0e38..11c8a74 100644
--- a/lib/ltrcc.c
+++ b/lib/ltrcc.c
@@ -55,10 +55,10 @@
 #include "version.c"
 
 
-static __attribute__((pure, const)) long int
-ntp_to_unix_epoch(long int x)
+static __attribute__((pure, const)) unsigned long int
+ntp_to_unix_epoch(unsigned long int x)
 {
-	return x - 25567L * 86400L;
+	return x - 25567U * 86400U;
 }
 
 
@@ -68,7 +68,7 @@ ntp_to_unix_epoch(long int x)
 static int
 pr_line_corr(const char *line, size_t llen, va_list UNUSED(vap))
 {
-	static long int cor;
+	static unsigned long int cor;
 	char *sp, *ep;
 
 	if (llen == PROLOGUE) {
@@ -96,7 +96,7 @@ const int32_t %s[] = {\n\
 	/* otherwise process */
 	if ((sp = memchr(line, '\t', llen)) == NULL) {
 		return -1;
-	} else if ((ep = NULL, cor = strtol(++sp, , 10), ep == NULL)) {
+	} else if ((ep = NULL, cor = strtoul(++sp, , 10), ep == NULL || cor == ULONG_MAX)) {
 		return -1;
 	}
 
@@ -108,10 +108,10 @@ const int32_t %s[] = {\n\
 static int
 pr_line_d(const char *line, size_t llen, va_list vap)
 {
-	static long int cor;
+	static unsigned long int cor;
 	struct dt_d_s d;
 	dt_dtyp_t typ;
-	long int val;
+	unsigned long int val;
 	int colp;
 	char *ep;
 
@@ -155,7 +155,7 @@ const uint32_t %s[] = {\n\
 		return 0;
 	}
 	/* otherwise process */
-	if ((ep = NULL, val = strtol(line, , 10), ep == NULL)) {
+	if ((ep = NULL, val = strtoul(line, , 10), ep == NULL || val == ULONG_MAX)) {
 		return -1;
 	}
 
@@ -164,7 +164,7 @@ const uint32_t %s[] = {\n\
 	d = dt_dconv(typ, d);
 
 	if (!colp) {
-		if ((cor = strtol(ep, , 10), ep == NULL)) {
+		if ((cor = strtoul(ep, , 10), ep == NULL || val == ULONG_MAX)) {
 			return -1;
 		}
 		/* just output the line then */
@@ -179,9 +179,9 @@ const uint32_t %s[] = {\n\
 static int
 pr_line_dt(const char *line, size_t llen, va_list vap)
 {
-	static long int cor;
+	static unsigned long int cor;
 	dt_dtyp_t __attribute__((unused)) typ;
-	long int val;
+	unsigned long int val;
 	int colp;
 	char *ep;
 
@@ -225,7 +225,7 @@ const int32_t %s[] = {\n\
 		return 0;
 	}
 	/* otherwise process */
-	if ((ep = NULL, val = strtol(line, , 10), ep == NULL)) {
+	if ((ep = NULL, val = strtoul(line, , 10), ep == NULL || val == ULONG_MAX)) {
 		return -1;
 	}
 
@@ -234,15 +234,15 @@ const int32_t %s[] = {\n\
 	val = ntp_to_unix_epoch(val);
 
 	if (!colp) {
-		if ((cor = strtol(ep, , 10), ep == NULL)) {
+		if ((cor = strtoul(ep, , 10), ep == NULL || cor == ULONG_MAX)) {
 			return -1;
 		}
 		/* just output the line then */
-		fprintf(stdout, "\t{0x%xU/* %li */, %li},\n",
-			(uint32_t)val, val, cor);
+		fprintf(stdout, "\t{0x%lxU/* %li */, %li},\n",
+			val, val, cor);
 	} else {
 		/* column-oriented mode */
-		fprintf(stdout, "\t0x%xU/* %li */,\n", (uint32_t)val, val);
+		fprintf(stdout, "\t0x%lxU/* %li */,\n", val, val);
 	}
 	return 0;
 }
@@ -250,12 +250,12 @@ const int32_t %s[] = {\n\
 static int
 pr_line_t(const char *line, size_t llen, va_list vap)
 {
-	static long int cor;
+	static unsigned long int cor;
 	struct dt_t_s t = dt_t_initialiser();
 	dt_dtyp_t typ;
 	int colp;
 	char *ep;
-	long int val;
+	unsigned long int val;
 
 	/* extract type from inner list */
 	typ = va_arg(vap, dt_dtyp_t);
@@ -292,7 +292,7 @@ const uint32_t %s[] = {\n\
 		return 0;
 	}
 	/* otherwise process */
-	if ((ep = NULL, val = strtol(line, , 10), ep == NULL)) {
+	if ((ep = NULL, val = strtoul(line, , 10), ep == NULL || val == ULONG_MAX)) {
 		return -1;
 	}
 	val--;
@@ -303,7 +303,7 @@ const uint32_t %s[] = {\n\
 	t.hms.h = val % 24L;
 
 	/* read correction */
-	if ((val = strtol(ep, , 10), ep == NULL)) {
+	if ((val = strtoul(ep, , 10), ep == NULL || val == ULONG_MAX)) {
 		return -1;
 	}
 
-- 
2.20.1



# Unstable i386 qemu VM 2019-05-07
# Unstable amd64 qemu VM 2019-05-07


apt update
apt dist-upgrade


apt install systemd-coredump fakeroot gdb git strace
apt build-dep dateutils


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


cd /home/benutzer/source/dateutils
cp orig try1 -a
cd try1/dateutils-0.4.5
dpkg-buildpackage


i386:
# TOTAL: 855
# PASS:  841
# SKIP:  0
# XFAIL: 0
# FAIL:  14
# XPASS: 0
  

Bug#926180: scilab: FTBFS on all - New trouble

[Alexis Murzeau]

Le 03/05/2019 à 18:39, Sylvestre Ledru a écrit :
> What about starting a xvfb during the build?
> 
> Does it fix the issue?
> 
> S
> 
> 
> Le 03/05/2019 à 16:50, Alexis Murzeau a écrit :
>> Hi,
>>
>> Indeed, I tried in a virtual machine:
>>   - install scilab
>>   - run `LANG=en_US.UTF-8 LC_ALL=C SCI_DISABLE_TK=1
>> SCI_JAVA_ENABLE_HEADLESS=1 _JAVA_OPTIONS='-Djava.awt.headless=true'
>> HOME=/tmp scilab-adv-cli -noatomsautoload -nb -l en_US -nouserstartup -e
>> "try xmltojar([],[],'en_US');catch disp(lasterror());
>> exit(-1);end;exit(0);"`
>>
>> And, while connected via ssh using Putty, I got this:
>> ```
>> [snip]
>>
>>  [6]:
>> jogamp.opengl.SharedResourceRunner.run(SharedResourceRunner.java:353)
>>  [7]: java.base/java.lang.Thread.run(Thread.java:834)
>> commons module not found.
>> graphic_objects module not found.
>> ui_data module not found.
>> graph module not found.
>> history_browser module not found.
>> slint module not found.
>> coverage module not found.
>> ```
>>
> 

Despite having *almost* the same output when calling manually the
command line outside of a build context, when I do a sbuild, I do not
have errors as x86-bm-01 have. So I think the manual run has unrelated
issues to this bug.

Actually, the build that doesn't fail (on x86-csail-02) also has the
GLException exception (search for "-- Building documentation (en_US) --"
in the logs).

The difference starts here:
```
A fatal error has been detected by Scilab.
Please check your user-defined functions (or external module ones)
should they appear in the stack trace.
Otherwise you can report a bug on http://bugzilla.scilab.org/ with:
 * a sample code which reproduces the issue
 * the result of [a, b] = getdebuginfo()
 * the following information:
[x86-bm-01:08312] Signal: Illegal instruction (4)
[x86-bm-01:08312] Signal code: Illegal operand (2)
[x86-bm-01:08312] Failing at address: 0x7ff0c87e3dcf

Call stack:
   1: 0xb2d791 
(/usr/lib/jvm/default-java/lib/server/libjvm.so)
   2: 0xb222b8 < >
(/usr/lib/jvm/default-java/lib/server/libjvm.so)
   3: 0x12730  < >
(/lib/x86_64-linux-gnu/libpthread.so.0)
   4: ??(?)
End of stack

```

Where the working log has a java.lang.IllegalStateException
 exception instead. Maybe there is a memory corruption somewhere in
native code that doesn't always cause a jvm crash.

I fear the crash happen in java code, this stacktrace is not very good :(

I'm trying to run that command with valgrind, but this is very slow.

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#928630: unblock: vim/2:8.1.0875-3

[James McCoy]

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

Please unblock package vim

This upload updates the Debian/Ubuntu release names in a couple syntax
highlighting files to include buster, bullseye, and bookworm (for
Debian) and eoan (for Ubuntu).

unblock vim/2:8.1.0875-3

-- System Information:
Debian Release: 10.0
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-4-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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diffstat for vim-8.1.0875 vim-8.1.0875

 changelog|7 +++
 patches/series   |1 
 patches/upstream/deb-release-names.patch |   58 +++
 3 files changed, 66 insertions(+)

diff -Nru vim-8.1.0875/debian/changelog vim-8.1.0875/debian/changelog
--- vim-8.1.0875/debian/changelog   2019-02-22 07:55:04.0 -0500
+++ vim-8.1.0875/debian/changelog   2019-05-05 23:41:10.0 -0400
@@ -1,3 +1,10 @@
+vim (2:8.1.0875-3) unstable; urgency=medium
+
+  * syntax/deb{changelog,sources}: Update release names for Debian/Ubuntu
+(Closes: #927167)
+
+ -- James McCoy   Sun, 05 May 2019 23:41:10 -0400
+
 vim (2:8.1.0875-2) unstable; urgency=medium
 
   * Backport 8.1.0878 and 8.1.0884 to fix test failures on kFreeBSD.
diff -Nru vim-8.1.0875/debian/patches/series vim-8.1.0875/debian/patches/series
--- vim-8.1.0875/debian/patches/series  2019-02-22 07:55:04.0 -0500
+++ vim-8.1.0875/debian/patches/series  2019-05-05 23:41:10.0 -0400
@@ -6,3 +6,4 @@
 patch-8.1.0878-test-for-has-bsd-fails-on-some-BSD-systems.patch
 patch-8.1.0884-double-check-for-bsd-systems.patch
 patch-8.1.0948-when-built-without-eval-Vim-clean-produces.patch
+upstream/deb-release-names.patch
diff -Nru vim-8.1.0875/debian/patches/upstream/deb-release-names.patch 
vim-8.1.0875/debian/patches/upstream/deb-release-names.patch
--- vim-8.1.0875/debian/patches/upstream/deb-release-names.patch
1969-12-31 19:00:00.0 -0500
+++ vim-8.1.0875/debian/patches/upstream/deb-release-names.patch
2019-05-05 23:41:10.0 -0400
@@ -0,0 +1,58 @@
+From: James McCoy 
+Date: Sun, 21 Apr 2019 23:12:18 -0400
+Subject: Add Ubuntu's eoan and Debian's buster, bullseye, bookworm releases
+
+Signed-off-by: James McCoy 
+---
+ runtime/syntax/debchangelog.vim | 4 ++--
+ runtime/syntax/debsources.vim   | 7 ---
+ 2 files changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/runtime/syntax/debchangelog.vim b/runtime/syntax/debchangelog.vim
+index 4ca4c29..9d6dfe9 100644
+--- a/runtime/syntax/debchangelog.vim
 b/runtime/syntax/debchangelog.vim
+@@ -3,7 +3,7 @@
+ " Maintainer:  Debian Vim Maintainers
+ " Former Maintainers: Gerfried Fuchs 
+ " Wichert Akkerman 
+-" Last Change: 2019 Jan 26
++" Last Change: 2019 Apr 21
+ " URL: 
https://salsa.debian.org/vim-team/vim-debian/blob/master/syntax/debchangelog.vim
+ 
+ " Standard syntax initialization
+@@ -21,7 +21,7 @@ let s:binNMU='binary-only=yes'
+ syn match debchangelogNamecontained "^[[:alnum:]][[:alnum:].+-]\+ "
+ exe 'syn match debchangelogFirstKVcontained "; 
\('.s:urgency.'\|'.s:binNMU.'\)"'
+ exe 'syn match debchangelogOtherKVcontained ", 
\('.s:urgency.'\|'.s:binNMU.'\)"'
+-syn match debchangelogTarget  contained "\v 
%(frozen|unstable|sid|%(testing|%(old)=stable)%(-proposed-updates|-security)=|experimental|squeeze-%(backports%(-sloppy)=|volatile|lts|security)|%(wheezy|jessie)%(-backports%(-sloppy)=|-security)=|stretch%(-backports|-security)=|%(devel|precise|trusty|vivid|wily|xenial|yakkety|zesty|artful|bionic|cosmic|disco)%(-%(security|proposed|updates|backports|commercial|partner))=)+"
++syn match debchangelogTarget  contained "\v 
%(frozen|unstable|sid|%(testing|%(old)=stable)%(-proposed-updates|-security)=|experimental|%(squeeze|wheezy|jessie)-%(backports%(-sloppy)=|lts|security)|stretch%(-backports%(-sloppy)=|-security)=|buster%(-backports|-security)=|bullseye|%(devel|precise|trusty|vivid|wily|xenial|yakkety|zesty|artful|bionic|cosmic|disco|eoan)%(-%(security|proposed|updates|backports|commercial|partner))=)+"
+ syn match debchangelogVersion contained "(.\{-})"
+ syn match debchangelogCloses  contained 
"closes:\_s*\(bug\)\=#\=\_s\=\d\+\(,\_s*\(bug\)\=#\=\_s\=\d\+\)*"
+ syn match debchangelogLP  contained "\clp:\s\+#\d\+\(,\s*#\d\+\)*"
+diff --git a/runtime/syntax/debsources.vim b/runtime/syntax/debsources.vim
+index 4b21941..f90476f 100644
+--- a/runtime/syntax/debsources.vim
 b/runtime/syntax/debsources.vim
+@@ -2,7 +2,7 @@
+ " Language: Debian sources.list
+ " Maintainer:   Debian Vim Maintainers
+ " Former Maintainer: Matthijs Mohlmann 
+-" Last Change: 2018 Oct 30
++" Last Change: 2019 Apr 21
+ " URL: 

Bug#915830: busybox: cp: failed to access '/var/tmp/mkinitramfs_h8da2B//usr/bin/busybox': Too many levels of symbolic links

[Axel Beckert]

Hi,

> cp: failed to access '/var/tmp/mkinitramfs_mSMoqa//usr/bin/busybox': Too many 
> levels of symbolic links
> E: /usr/share/initramfs-tools/hooks/zz-busybox failed with return 1.

I'm having a very similar issue which makes me think that this is a
more generic issue and not necessarily busybox-specific:

/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.19.0-4-686-pae
cp: failed to access '/var/tmp/mkinitramfs_URATxd//usr/bin/touch': Too many 
levels of symbolic links
E: /usr/share/initramfs-tools/hooks/fsprotect failed with return 1.
update-initramfs: failed for /boot/initrd.img-4.19.0-4-686-pae with 1.
run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
dpkg: error processing package linux-image-4.19.0-4-686-pae (--configure):
 installed linux-image-4.19.0-4-686-pae package post-installation script 
subprocess returned error exit status 1

Note that it's /usr/bin/touch and
/usr/share/initramfs-tools/hooks/fsprotect, but otherwise looks like
the same issue.

>From my point of view this looks like either an issue in
initramfs-tools or in both, busybox and fsprotect (and maybe more)
packages not having adapted to breaking changes in initramfs-tools.

Chris Lamb wrote:
> Whilst you could indeed change this, given that my attempt at usrmerge
> failed for reasons unrelated to busybox and/or initramfs generation

JFTR: My case is on a non-usrmerge i386 system running Sid. The issue
shows up for at least a few weeks now if not longer (hadn't touched
that system for a few weeks or so beforehand) and seemingly for all
kernels installed or upgraded since it appeared the first time.

> Thus, we should probably just close this bug.

Huh?

If I wouldn't have found this bug report, I'd have filed (and might
still file) the above as at least severity serious as it breaks the
installation/upgrade of more or less unrelated packages.

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

Bug#928497: nvidia-persistenced: Error in nvidia-persistenced source (postinst)

[Daniel Reichelt]

Hi Andreas,


> I can reproduce this (on a systemv system) with a (deliberately)
> mismatching kernel module loaded:

this also happens on systems w/o nvidia hardware, i.e. when the module
isn't loaded at all. That situation produces similar syslog entries than
yours, except the messages prefixed NVRM are missing, of course.

--8<--
May  7 23:37:08 testhost nvidia-persistenced: Started (19591)
May  7 23:37:08 testhost nvidia-persistenced: Failed to query NVIDIA
devices. Please ensure that the NVIDIA device files (/dev/nvidia*)
exist, and that user 145 has read and write permissions for those files.
May  7 23:37:08 testhost nvidia-persistenced: Shutdown (19591)
May  7 23:37:58 testhost nvidia-persistenced: Started (19744)
May  7 23:37:58 testhost nvidia-persistenced: Failed to query NVIDIA
devices. Please ensure that the NVIDIA device files (/dev/nvidia*)
exist, and that user 145 has read and write permissions for those files.
May  7 23:37:58 testhost nvidia-persistenced: Shutdown (19744)
May  7 23:38:04 testhost nvidia-persistenced: Started (19823)
May  7 23:38:04 testhost nvidia-persistenced: Failed to query NVIDIA
devices. Please ensure that the NVIDIA device files (/dev/nvidia*)
exist, and that user 145 has read and write permissions for those files.
May  7 23:38:04 testhost nvidia-persistenced: Shutdown (19823)
-->8--


Cheers
Daniel



signature.asc
Description: OpenPGP digital signature

Bug#928629: openvas: Certificate error while connecting to greenbone-security-assistant

[jors]

Package: openvas
Version: 9.0.3
Severity: important

Dear Maintainer,

   * What led up to the situation?
 Installed openvas and tried to access greenbone-security-assistant web 
interface (https://:9392/
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
 Open a browser with the mentioned URL.
   * What was the outcome of this action?
 Browser complained with NET::ERR_CERT_AUTHORITY_INVALID. Tried bypassing 
the error, but returned to same screen (loop).
   * What outcome did you expect instead?
 The greenbone-security-assistant web interface to be loaded.

Also tried regenerating the certificates with one of the provided scripts and 
restarting openvas services with no luck (same situation):

$ openvas-manage-certs -af

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

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

Versions of packages openvas depends on:
ii  greenbone-security-assistant  7.0.3+dfsg.1-1
ii  openvas-cli   1.4.5-2
ii  openvas-manager   7.0.3-1
ii  openvas-scanner   5.1.3-2

Versions of packages openvas recommends:
ii  rsync 3.1.3-6
ii  sqlite3   3.27.2-2
ii  xsltproc  1.1.32-2

openvas suggests no packages.

-- no debconf information

Bug#928628: grub-efi-amd64-signed: Add cpuid module to available modules

[adrian15]

Package: grub-efi-amd64-signed
Version: 1+2.02+dfsg1+16
Severity: wishlist

Dear Maintainer,


  live-build generated grub.cfg uses grub's cpuid command when
there are two or more kernel flavours.
  The final user thanks to the add auto option can choose either
the amd64 kernel or 686 kernel in an easy manner.

  Is it possible to add the cpuid module and command to the
secure boot based grub (both grub-efi-amd64-signed and
grub-efi-ia32-signed packages) ?

  Thank you very much!


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

Kernel: Linux 4.9.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_USER, TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect

Versions of packages grub-efi-amd64-signed depends on:
pn  grub-common  

Versions of packages grub-efi-amd64-signed recommends:
pn  shim-signed  

grub-efi-amd64-signed suggests no packages.

Bug#348991: What needs to be done to kernel to collect disk I/O statistics?

[Marcos Fouces]

Hello

I can confirm that the problem persists with the kernel i use(Linux 
4.19.0-4-amd64). I am inclined to close this bug because it has nothing
to do with acct but with the kernel.

Greetings,

Marcos

Bug#928627: ruby-ronn: Incompatible encoding regexp match when generating utf-8 roff

[Alexander Kulak]

Package: ruby-ronn
Version: 0.8.0-2
Severity: normal

Dear Maintainer,

ronn fails on processing my source file: 
https://raw.githubusercontent.com/sagb/alttab/master/doc/alttab.1.ronn
ronn --roff alttab.1.ronn
About a year ago it worked fine, as well as current version in stretch.
--html mode works too.

 roff: ./alttab.1 
/usr/lib/ruby/vendor_ruby/ronn/roff.rb:354:in `gsub': incompatible encoding 
regexp match (Windows-31J regexp with UTF-8 string) 
(Encoding::CompatibilityError)
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:354:in `write'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:247:in `inline_filter'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:243:in `block in 
inline_filter'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:204:in `block 
in each'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `upto'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `each'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:243:in `inline_filter'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:120:in `block_filter'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block in 
block_filter'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:204:in `block 
in each'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `upto'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `each'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block_filter'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:153:in `block_filter'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block in 
block_filter'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:204:in `block 
in each'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `upto'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `each'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block_filter'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:145:in `block_filter'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block in 
block_filter'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:204:in `block 
in each'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `upto'
from /usr/lib/ruby/vendor_ruby/nokogiri/xml/node_set.rb:203:in `each'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:88:in `block_filter'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:91:in `block_filter'
from /usr/lib/ruby/vendor_ruby/ronn/roff.rb:18:in `initialize'
from /usr/lib/ruby/vendor_ruby/ronn/document.rb:245:in `new'
from /usr/lib/ruby/vendor_ruby/ronn/document.rb:245:in `to_roff'
from /usr/lib/ruby/vendor_ruby/ronn/document.rb:240:in `convert'
from /usr/bin/ronn:209:in `block (2 levels) in '
from /usr/bin/ronn:199:in `each'
from /usr/bin/ronn:199:in `block in '
from /usr/bin/ronn:184:in `each'
from /usr/bin/ronn:184:in `'


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

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

Versions of packages ruby-ronn depends on:
ii  groff   1.22.4-3
ii  ruby1:2.5.1
ii  ruby-mustache   1.0.2-1
ii  ruby-nokogiri   1.10.0+dfsg1-2
ii  ruby-rdiscount  2.1.8-1+b5

ruby-ronn recommends no packages.

ruby-ronn suggests no packages.

-- no debconf information

Bug#907607: scilab-cli doesn't start

[Alexis Murzeau]

On Wed, 26 Sep 2018 11:12:36 +0200 Julien Puydt
 wrote:
> Hi,
> 
> Le 21/09/2018 à 14:51, Sylvestre Ledru a écrit :
> > Le 30/08/2018 à 09:07, Sylvestre Ledru a écrit :
> >> Package: scilab-cli
> >> Version: 6.0.1-5
> >> Severity: important
> >>
> >> Hello
> >>
> >> scilab-cli is failing on startup.
> >>
> >> STR:
> >> $ sudo apt-get install scilab-cli
> >> $ scilab-cli
> >> commons module not found.
> >> graphic_objects module not found.
> >> ui_data module not found.
> >> graph module not found.
> >> history_browser module not found.
> >> slint module not found.
> >> coverage module not found.
> >>
> >> installing the scilab pkg does not fix the issue.
> > Hello Julien,
> > 
> > Do you have an idea about that?
> >
> 
> I had a look, and indeed, warnings get spit out and scilab-cli is stuck. 
> Running "scilab" gives the same warnings, but works.

Hi,

I found the "module not found." message inside the file funcmanager.cpp
[0]. It does a verification which is a file existence check against the
start file of the module [1].

I found that the modules giving errors don't have start files in Debian.
For example,
"/usr/share/scilab/modules/graphic_objects/etc/graphic_objects.start"
doesn't exists in unstable but exists in stable.
As this start file is empty, I think the cause of this is the line in
debian/rules removing empty files [2] which was added in version 6.0.1-4
[3].

I tried to run scilab-cli after having manually created empty .start and
.stop files and the cli was working.

I've done this a root:
```
SCI_MODULE="graphic_objects" ; mkdir
/usr/share/scilab/modules/$SCI_MODULE/etc; touch
$_/$SCI_MODULE{.start,.quit}
SCI_MODULE="commons" ; mkdir /usr/share/scilab/modules/$SCI_MODULE/etc;
touch $_/$SCI_MODULE{.start,.quit}
SCI_MODULE="ui_data" ; mkdir /usr/share/scilab/modules/$SCI_MODULE/etc;
touch $_/$SCI_MODULE{.start,.quit}
SCI_MODULE="graph" ; mkdir /usr/share/scilab/modules/$SCI_MODULE/etc;
touch $_/$SCI_MODULE{.start,.quit}
SCI_MODULE="history_browser" ; mkdir
/usr/share/scilab/modules/$SCI_MODULE/etc; touch
$_/$SCI_MODULE{.start,.quit}
SCI_MODULE="slint" ; mkdir /usr/share/scilab/modules/$SCI_MODULE/etc;
touch $_/$SCI_MODULE{.start,.quit}
SCI_MODULE="coverage" ; mkdir /usr/share/scilab/modules/$SCI_MODULE/etc;
touch $_/$SCI_MODULE{.start,.quit}
touch /usr/share/scilab//modules/types/etc/types.quit
touch /usr/share/scilab//modules/preferences/etc/preferences.quit
```

And I'm not getting any error when starting scilab-cli nor any errors
when leaving the cli:
doc@debian64:~$ scilab-cli
Scilab 6.0.1 (Mar 31 2019, 13:13:06)

--> quit
doc@debian64:~$

So I think the line 62 in debian/rules [2] need to be reverted.


[0]
https://sources.debian.org/src/scilab/6.0.1-9/modules/functions_manager/src/cpp/funcmanager.cpp/#L192
[1]
https://sources.debian.org/src/scilab/6.0.1-9/modules/functions_manager/src/cpp/funcmanager.cpp/#L244

[2] https://sources.debian.org/src/scilab/6.0.1-9/debian/rules/#L62
[3]
https://salsa.debian.org/science-team/scilab/commit/46642e287b941f0a27fa2f7e25c47f2ababd9b28#8756c63497c8dc39f7773438edf53b220c773f67_57_56

-- 
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC  2787 E7BD 1904 F480 937F



signature.asc
Description: OpenPGP digital signature

Bug#928626: unblock: node-axios/0.17.1+dfsg-2

[Xavier Guimard]

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

Please unblock package node-axios

Hi all,

node-axios is vulnerable to CVE-2019-10742 (#928624). The fix is very
simple:
  --- a/lib/adapters/http.js
  +++ b/lib/adapters/http.js
  @@ -172,6 +172,7 @@
  
 // make sure the content length is not over the maxContentLength 
if specified
 if (config.maxContentLength > -1 && 
Buffer.concat(responseBuffer).length > config.maxContentLength) {
  +   stream.destroy();
   reject(createError('maxContentLength size of ' + 
config.maxContentLength + ' exceeded',
 config, null, lastRequest));
 }

Full changes:
  * Declare compliance with policy 4.3.0
  * Add upstream/metadata
  * Add patch to destroy stream on exceeding maxContentLength
(Closes: #928624, CVE-2019-10742)
  * Fix debian/copyright format URL

node-axios has no reverse dependencies.

I think it is low risky to upgrade node-axios in Buster.

Cheers,
Xavier

unblock node-axios/0.17.1+dfsg-2

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index b79d090..88ae229 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+node-axios (0.17.1+dfsg-2) unstable; urgency=medium
+
+  * Team upload
+  * Declare compliance with policy 4.3.0
+  * Add upstream/metadata
+  * Add patch to destroy stream on exceeding maxContentLength
+(Closes: #928624, CVE-2019-10742)
+  * Fix debian/copyright format URL
+
+ -- Xavier Guimard   Tue, 07 May 2019 22:59:58 +0200
+
 node-axios (0.17.1+dfsg-1) unstable; urgency=low
 
   * Initial release (Closes: #876067)
diff --git a/debian/control b/debian/control
index 808fda3..7090bf8 100644
--- a/debian/control
+++ b/debian/control
@@ -14,7 +14,7 @@ Build-Depends:
  , node-grunt-contrib-nodeunit 
  , node-follow-redirects (>= 1.2.3) 
  , node-is-buffer (>= 1.1.5) 
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Homepage: https://github.com/mzabriskie/axios
 Vcs-Git: https://salsa.debian.org/js-team/node-axios.git
 Vcs-Browser: https://salsa.debian.org/js-team/node-axios
diff --git a/debian/copyright b/debian/copyright
index 8f366c9..7098b5e 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,4 +1,4 @@
-Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: axios
 Upstream-Contact: https://github.com/mzabriskie/axios/issues
 Source: https://github.com/mzabriskie/axios
diff --git a/debian/patches/CVE-2019-10742.diff 
b/debian/patches/CVE-2019-10742.diff
new file mode 100644
index 000..3cb1a36
--- /dev/null
+++ b/debian/patches/CVE-2019-10742.diff
@@ -0,0 +1,18 @@
+Description: Destroy stream on exceeding maxContentLength
+Author: Xavier Guimard 
+Origin: upstream, 
https://github.com/axios/axios/commit/0d4fca085b9b44e110f4c5a3dd7384c31abaf756
+Bug: https://github.com/axios/axios/issues/1098
+Bug-Debian: https://bugs.debian.org/928624
+Forwarded: not-needed
+Last-Update: 2019-05-07
+
+--- a/lib/adapters/http.js
 b/lib/adapters/http.js
+@@ -172,6 +172,7 @@
+ 
+   // make sure the content length is not over the maxContentLength if 
specified
+   if (config.maxContentLength > -1 && 
Buffer.concat(responseBuffer).length > config.maxContentLength) {
++  stream.destroy();
+ reject(createError('maxContentLength size of ' + 
config.maxContentLength + ' exceeded',
+   config, null, lastRequest));
+   }
diff --git a/debian/patches/series b/debian/patches/series
index f9a8deb..877fd7a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 skip-unneeded-modules.patch
 use-webpack3.patch
+CVE-2019-10742.diff
diff --git a/debian/upstream/metadata b/debian/upstream/metadata
new file mode 100644
index 000..a885fe3
--- /dev/null
+++ b/debian/upstream/metadata
@@ -0,0 +1,7 @@
+---
+Archive: GitHub
+Bug-Database: https://github.com/mzabriskie/axios/issues
+Contact: https://github.com/mzabriskie/axios/issues
+Name: axios
+Repository: https://github.com/mzabriskie/axios.git
+Repository-Browse: https://github.com/mzabriskie/axios

Bug#928622: autodep8 integration with dh

[Paul Gevers]

Hi Daniel,

Thanks for your report.

On 07-05-2019 22:39, Daniel Kahn Gillmor wrote:
> It would be nice if debhelper noticed that when autodep8 was in the
> build-dependencies of a package, it autogenerated the test somehow.
> That way a developer could just declare the build-dependency and not
> worry about needing to re-run "autodep8 > debian/tests/control" to keep
> things updated.

This is not the recommended way of using autodep8, albeit it does fix an
issue that is worrying me a bit [1]. You are supposed to add a
"Testsuite: autopkgtest-pkg-" to the source stanza of your
package and never look back. See $(man autodep8).

> my debhelper skills and understanding of autopkgtest are not deep enough
> to know how to do that exactly, so i'm opening this feature request.

But I'll leave this bug open to think about it.

Paul

[1] currently the autopkgtest framework uses the version of autodep8
from the host, which is typically up-to-date. However the test may have
only been working with an older version of autodep8. E.g. package from
stable/stretch that pass with autodep8 from stable/stretch may fail with
autodep8 from buster.



signature.asc
Description: OpenPGP digital signature

Bug#928624: node-axios: CVE-2019-10742

[Salvatore Bonaccorso]

Source: node-axios
Version: 0.17.1+dfsg-1
Severity: grave
Tags: security upstream
Forwarded: https://github.com/axios/axios/issues/1098

Hi,

The following vulnerability was published for node-axios.

CVE-2019-10742[0]:
| Axios up to and including 0.18.0 allows attackers to cause a denial of
| service (application crash) by continuing to accepting content after
| maxContentLength is exceeded.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-10742
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10742
[1] https://github.com/axios/axios/issues/1098

Regards,
Salvatore

Bug#928625: RFP: node-evacuated-commonjs-everywhere -- browser bundler with source maps from the minified JS bundle to the original source

[Jeff Cliff]

Package: wnpp
Severity: wishlist

* Package name: node-evacuated-commonjs-everywhere
  Version : 0.9.7
  Upstream Author : Michael Ficarra 
* URL : 
http://rvqbgg7e5mjcdpplull5qaj6cqeyqcgudglhqcjl7kl25i2fvkkmm5ad.onion/
* License : 3-Clause-BSD
  Programming Lang: javascript
  Description : browser bundler with source maps from the minified JS 
bundle to the original source

CommonJS is a nodejs package ( node-commonjs )

nodejs-evacuated-commonjs-everywhere is evacuated from NSA/Microsoft github.

minified JS is a compiled form of javascript.  See 
https://wiki.debian.org/Javascript/Nodejs

nodejs-evacuated-commonjs-everywhere is a CommonJS browser bundler with source 
maps from the minified 
JS bundle to the original source, aliasing for browser overrides and 
extensibility for arbitrary 
compile-to-JS language support.

It is a prerequisite for node-esquery ( #901186 )

Bug#928623: unblock: node-regjsparser/0.6.0+ds-2

[Xavier Guimard]

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

Please unblock package node-regjsparser

Hi all,

following #928610 (unblock node-unicode-data), here is a rebuild of
node-regjsparser using unicode 12.0.0.

Full changes:
  * Add upstream/metadata
  * Build-depend on node-unicode-12.0.0
  * Declare compliance with policy 4.3.0

Reverse dependencies:
 - node-regexpu-core
   +-> node-babel-preset-es2015
   +-> node-babel-preset-latest
   +-> node-babel-preset-es2015-loose
   +-> node-css-selector-tokenizer
   +-> node-css-loader
   +-> node-buble
   +-> node-rollup-plugin-buble
   +-> rollup

The changes on installed files are related only to unicode update.

Cheers,
Xavier

unblock node-regjsparser/0.6.0+ds-2

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index df1d0d1..660b4a2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+node-regjsparser (0.6.0+ds-2) unstable; urgency=medium
+
+  * Team upload
+  * Add upstream/metadata
+  * Build-depend on node-unicode-12.0.0
+  * Declare compliance with policy 4.3.0
+
+ -- Xavier Guimard   Tue, 07 May 2019 18:25:20 +0200
+
 node-regjsparser (0.6.0+ds-1) unstable; urgency=medium
 
   * New upstream release.
@@ -22,9 +31,9 @@ node-regjsparser (0.4.0+ds-1) unstable; urgency=medium
   * New upstream release.
   * Refresh packaging:
 - Use my debian.org mail address.
-- Bump dh compat to 11. 
-- Point Vcs-* fields to salsa. 
-- Bump std-ver to 4.2.1. 
+- Bump dh compat to 11.
+- Point Vcs-* fields to salsa.
+- Bump std-ver to 4.2.1.
 
  -- Julien Puydt   Sat, 01 Sep 2018 07:25:56 +0200
 
diff --git a/debian/control b/debian/control
index b8610a4..86730df 100644
--- a/debian/control
+++ b/debian/control
@@ -3,8 +3,8 @@ Section: javascript
 Priority: optional
 Maintainer: Debian Javascript Maintainers 

 Uploaders: Julien Puydt 
-Build-Depends: debhelper (>= 11), nodejs (>= 6), node-regenerate, 
node-unicode-11.0.0
-Standards-Version: 4.2.1
+Build-Depends: debhelper (>= 11), nodejs (>= 6), node-regenerate, 
node-unicode-12.0.0
+Standards-Version: 4.3.0
 Homepage: https://github.com/jviereck/regjsparser
 Vcs-Git: https://salsa.debian.org/js-team/node-regjsparser.git
 Vcs-Browser: https://salsa.debian.org/js-team/node-regjsparser
diff --git a/debian/patches/series b/debian/patches/series
index 1585e6c..5b9ca50 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
 use_own_identifier_regex.patch
+unicode-12.diff
diff --git a/debian/patches/unicode-12.diff b/debian/patches/unicode-12.diff
new file mode 100644
index 000..2ecc6f3
--- /dev/null
+++ b/debian/patches/unicode-12.diff
@@ -0,0 +1,26 @@
+Description: Bump unicode version to 12
+Author: Xavier Guimard 
+Forwarded: no
+Last-Update: 2019-05-07
+
+--- a/package.json
 b/package.json
+@@ -24,6 +24,6 @@
+   },
+   "devDependencies": {
+ "regenerate": "~1.0.1",
+-"unicode-11.0.0": "^0.7.8"
++"unicode-12.0.0": "^0.7.8"
+   }
+ }
+--- a/tools/generate-identifier-regex.js
 b/tools/generate-identifier-regex.js
+@@ -3,7 +3,7 @@
+ var regenerate = require('regenerate');
+ 
+ // Which Unicode version should be used?
+-var version = '11.0.0'; // note: also update `package.json` when this changes
++var version = '12.0.0'; // note: also update `package.json` when this changes
+ 
+ // Shorthand function
+ var get = function(what) {
diff --git a/debian/upstream/metadata b/debian/upstream/metadata
new file mode 100644
index 000..cba4aa8
--- /dev/null
+++ b/debian/upstream/metadata
@@ -0,0 +1,7 @@
+---
+Archive: GitHub
+Bug-Database: https://github.com/jviereck/regjsparser/issues
+Contact: https://github.com/jviereck/regjsparser/issues
+Name: regjsparser
+Repository: https://github.com/jviereck/regjsparser.git
+Repository-Browse: https://github.com/jviereck/regjsparser

Bug#928621: ITP: xfce4-taskbar-plugin -- Windows 7 Taskbar Mimic for XFCE

[Null Nullington]

Package: wnpp
Severity: wishlist
Owner: Null Nullington 

* Package name: xfce4-taskbar-plugin
  Version : 1.0
  Upstream Author : Nick Schermer 
* URL : https://git.xfce.org/archive/xfce4-taskbar-plugin
* License : GPL2
  Programming Lang: C
  Description : Windows 7 Taskbar Mimic for XFCE

xfce4-taskbar-plugin is a Windows 7 like taskbar for the XFCE desktop
environment. It has the same functionality as the window list, which is
built in to the xfce4-panel, with the added functionality to pin
applications. These pinned applications behave like launchers, allowing
you to launch new instances of the application.

There is xfce4-dockbarx-plugin, which is not packaged for debian, but it
doesn't integrate well with GTK themes. So the Taskbar Plugin is better.

I do need a sponsor. I plan on porting it to other architectures, but as
of now, I only have access to an amd64 machine. I may have others help
out as well, as I am not that good at C, so I won't be able to fix bugs
myself. I have already built the package, both binary and source. All I
need is someone to add it to the archive.

Bug#928622: autodep8 integration with dh

[Daniel Kahn Gillmor]

Package: autodep8
Version: 0.18
Affects: -1 + debhelper
Severity: wishlist

It would be nice if debhelper noticed that when autodep8 was in the
build-dependencies of a package, it autogenerated the test somehow.
That way a developer could just declare the build-dependency and not
worry about needing to re-run "autodep8 > debian/tests/control" to keep
things updated.

my debhelper skills and understanding of autopkgtest are not deep enough
to know how to do that exactly, so i'm opening this feature request.

thanks for autodep8!

--dkg


signature.asc
Description: PGP signature

Bug#928614: ~/.xsession-errors verbosity

[Julien Aubin]

Hi,

Okay I've found the culprint in my case, which is Google Chrome. My
xsession-errors file is filled with lines like below :
[20640:20658:0507/223508.343544:ERROR:cache_util.cc(141)] Unable to
move cache folder
/home/julien/.cache/google-chrome/PnaclTranslationCac
he to /home/julien/.cache/google-chrome/old_PnaclTranslationCache_000
[20640:20658:0507/223508.343587:ERROR:disk_cache.cc(185)] Unable to create cache
[20640:20658:0507/223508.343602:ERROR:pnacl_translation_cache.cc(346)]
Backend init failed:net::ERR_FAILED

The problem is that the error output of Google Chrome is redirected to
xsession-errors while it should be redirected to something else. Is it
a KDE bug ? (I launch it Chrome and other apps using Alt+F2)

Bug#928620: totem: Bottom controls not working

[Donald Broatch]

Package: totem
Version: 3.30.0-4
Severity: normal

When opening Totem under Wayland, the bottom controls (progress bar, menu and
volume buttons) do not work.

They work under Xorg.

Looks like this bug in Redhat if it helps.

https://bugzilla.redhat.com/show_bug.cgi?id=1563826


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

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

Versions of packages totem depends on:
ii  grilo-plugins-0.3   0.3.8-2
ii  gsettings-desktop-schemas   3.28.1-1
ii  gstreamer1.0-clutter-3.03.0.26-2
ii  gstreamer1.0-plugins-base   1.14.4-1
ii  gstreamer1.0-plugins-good   1.14.4-1
ii  gstreamer1.0-x  1.14.4-1
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-1
ii  libgstreamer-plugins-base1.0-0  1.14.4-1
ii  libgstreamer1.0-0   1.14.4-1
ii  libgtk-3-0  3.24.5-1
ii  libnautilus-extension1a 3.30.5-1
ii  libpango-1.0-0  1.42.4-6
ii  libpangocairo-1.0-0 1.42.4-6
ii  libtotem-plparser18 3.26.2-1
ii  libtotem0   3.30.0-4
ii  libx11-62:1.6.7-1
ii  totem-common3.30.0-4

Versions of packages totem recommends:
ii  gstreamer1.0-libav 1.15.0.1+git20180723+db823502-2
ii  gstreamer1.0-plugins-bad   1.14.4-1+b1
ii  gstreamer1.0-plugins-ugly  1.14.4-1
ii  gstreamer1.0-pulseaudio1.14.4-1
ii  totem-plugins  3.30.0-4

Versions of packages totem suggests:
pn  gnome-codec-install  

Bug#919632: closed by Ben Hutchings (Bug#919632: fixed in firmware-nonfree 20190502-1)

[Ben Hutchings]

Control: tag -1 upstream

On Tue, 2019-05-07 at 22:10 +0200, k...@osnanet.de wrote:
> tags 919632 - upstream
> thanks
> 
> Dear Ben, thanks a lot for all your time and effort!
> 
> tl;dr: Please don't revert. I've found the culprit. See my recommended  
> bug fixing procedure near the bottom of this message.
> 
> Zitat von Ben Hutchings :
> > It looked like the problem in these three bugs was that
> > newer versions of the driver that preferred firmware-6.bin were
> > incompatible with firmware-5.bin even though they tried to use it.
> 
> Very close. This bug is in fact dependent on the driver version. I'm  
> very sorry for not having picked up that clue before, and instead  
> havin tried the stretch linux-image 4.9.0 all the time. Your latest  
> E-Mail led me to the correct hunch. I'm not certain about the other  
> bug reports right now, but your bugfix might take care of all of them.
> 
> > Since the older driver version also fails, I suppose I should revert
> > the previous upstream change to firmware-5.bin.
> 
> No, please don't do that (quite yet), for three reasons:
> 
> 1. This very change might well have solved some of the other bugs you  
> tagged solved.
> 
> 2. The mere addition of ath10k/QCA9377/hw1.0/firmware-6.bin definitely  
> didn't worsen (at least) my situation.

I wasn't proposing to revert that.  Only the earlier change in
firmware-5.bin.

[...]
> * Leave the firmware blobs the way they are in 20190502-1.
> * Find out their required minimum driver/kernel version. (possibly  
> with my future help)
> * Add the missing dependency firmware-atheros -> linux-image  
> ${version}, and maybe document that in the package description, and/or  
> in firmware-.*/README.Debian, and/or wherever you deem appropriate. At  
> least the dependency seems important to me for all the present and  
> future backports users.
[...]

No, that's not the correct approach.  Whenever there is an incompatible
change in a firmware blob, the filename must be changed as well. 
That's why the latest version is called firmware-6.bin.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.




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

Bug#928619: ijs: transition Build-Depends devscripts to licensecheck

[Helmut Grohne]

Source: ijs
Version: 0.35-13
Severity: important
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ijs Build-Depends on devscripts. Thats normal, but unfortunately
devscripts depends on a package built from gnupg2 and gnupg2
Build-Depends on transfig, which is provided by fig2dev and which
depends on libijs-0.35 via ghostscript. This is a cycle and hampers
bootstrapping.

So I started looking why it has this devscripts dependency. The build
log shows that it tries running licensecheck, which is missing. At the
time of adding the devscripts dependency (according to git) licensecheck
was contained in devscripts. It was later moved to its own package. I
guess the dependency should simply be updated to licensecheck. In doing
so, we break the cycle. Please consider applying the attached patch.

Helmut
diff --minimal -Nru ijs-0.35/debian/changelog ijs-0.35/debian/changelog
--- ijs-0.35/debian/changelog   2018-02-10 16:11:57.0 +0100
+++ ijs-0.35/debian/changelog   2019-05-07 22:15:45.0 +0200
@@ -1,3 +1,10 @@
+ijs (0.35-13.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Transition devscripts Build-Depends to licensecheck. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 07 May 2019 22:15:45 +0200
+
 ijs (0.35-13) unstable; urgency=medium
 
   * Bump Standards-Version to 4.1.3 without changes needed
diff --minimal -Nru ijs-0.35/debian/control ijs-0.35/debian/control
--- ijs-0.35/debian/control 2018-02-10 16:11:57.0 +0100
+++ ijs-0.35/debian/control 2019-05-07 22:15:44.0 +0200
@@ -10,7 +10,7 @@
autoconf,
debhelper (>= 9~),
dh-buildinfo,
-   devscripts
+   licensecheck
 Build-Depends-Indep: docbook,
  docbook-utils,
  ghostscript

Bug#928546: replies by upstream util-linux and systemd

[Patrick Schleizer]

util-linux Karel Zak @karelzak replied:

https://github.com/karelzak/util-linux/issues/790

> The libmount allows to read fstab stuff from directory, for example
>
> ```
>  mount --fstab /etc/fstab.d/
> ```
>
> but this feature is not enabled by default and it does not check for
fstab.d/ by default. (see "man mount" for more details).
>
> The problem is that /etc/fstab is de-facto standard and on many places
(in linux ecosystem) we do not expect this feature. The nice example is
libc getmntent() API, another important is consumer systemd,
/sbin/mount. helpers, many 3rd party scripts etc ... so it's not about
util-linux.
>
> This is reason why libmount does not support it natively (although I
agree that /etc/fstab.d/ itself is a good idea).


systemd Lennart Poettering @poettering replied:

https://github.com/systemd/systemd/issues/12506#issuecomment-490227369

> We don't define the /etc/fstab format, util-linux does that and we
noawadays use util-linux' apis to parse it. Hence if you want soething
like that, you'd have to work with the util-linux folks, and then ths
would magically just work in systemd.
>
> That said, if I were you I'd just write a generator that looks at
/etc/fstab and creates drop-ins for the .mount units
systemd-fstab-generator generates that override the Option= line. i.e.
let systemd-fstab-generator do its thing as it currently does (meaning:
translating fstab into native systemd .mount unit files), but then have
your own generator that tweak some of these mount units with additional
generated drop-ins as you need.
>
> Anyway, let's close this, as I don't think we should change this in
systemd upstream. I hope that makes sense.

Bug#919632: closed by Ben Hutchings (Bug#919632: fixed in firmware-nonfree 20190502-1)

[kp]

tags 919632 - upstream
thanks

Dear Ben, thanks a lot for all your time and effort!

tl;dr: Please don't revert. I've found the culprit. See my recommended  
bug fixing procedure near the bottom of this message.


Zitat von Ben Hutchings :

It looked like the problem in these three bugs was that
newer versions of the driver that preferred firmware-6.bin were
incompatible with firmware-5.bin even though they tried to use it.


Very close. This bug is in fact dependent on the driver version. I'm  
very sorry for not having picked up that clue before, and instead  
havin tried the stretch linux-image 4.9.0 all the time. Your latest  
E-Mail led me to the correct hunch. I'm not certain about the other  
bug reports right now, but your bugfix might take care of all of them.



Since the older driver version also fails, I suppose I should revert
the previous upstream change to firmware-5.bin.


No, please don't do that (quite yet), for three reasons:

1. This very change might well have solved some of the other bugs you  
tagged solved.


2. The mere addition of ath10k/QCA9377/hw1.0/firmware-6.bin definitely  
didn't worsen (at least) my situation.


3. But it improved it quite a lot: I just switched linux-image from  
stretch 4.9.0-9-amd64 to stretch-backports 4.19.0-0.bpo.4-amd64, and  
*snap* that made firmware-atheros_20190502-1 work for me, (like a  
charm IDK quite yet, but at least it doesn't instantly crash any more)  
successfully using firmware-6.bin. \o/ Would you like to see my now  
working dmesg, or any other test results? (I'll need a few days before  
I return to broadband land, :-/ and also I've got a lot of AppArmor  
mess to clear up.)


My '3.' makes it look to me like the bug is really a missing  
dependency in firmware-atheros (since 20180518-1) on the specific  
kernel version when the firmware API or the ath10k_pci driver changed;  
somewhere >> 4.9.0 and <= 4.19.0. (Which one, and exactly for which  
drivers IDK, and I won't be able to run a lot of tests on that for a  
few days from now, so please bear with me.)


I strongly recommend the following procedure to fix this bug:

* Leave this bug open for now.
* Leave its severity and title (at least somewhat) the way they are,  
so that other users can easily find the cause.

* Remove its 'upstream' tag. (hereby done, I hope)
* Leave the firmware blobs the way they are in 20190502-1.
* Find out their required minimum driver/kernel version. (possibly  
with my future help)
* Add the missing dependency firmware-atheros -> linux-image  
${version}, and maybe document that in the package description, and/or  
in firmware-.*/README.Debian, and/or wherever you deem appropriate. At  
least the dependency seems important to me for all the present and  
future backports users.

* Close this bug :D

(BTW: Although ath10k_pci is compiled as a module rather than as a  
built-in, reading  
https://www.kernel.org/doc/html/latest/driver-api/firmware/direct-fs-lookup.html#firmware-and-initramfs leads me to believe that it might make sense to include the firmware blob(s) into the initrd along with the module(s). That's not the default behavior at the moment. I strongly expect this to have already been discussed somewhere within debian. @all: Would somebody please point me anywhere near that  
reasoning?)


Again, thanks a lot Ben for all your time and effort! Cheers
Kevin

Bug#910381: non-NSA/Microsoft upstream available

[Jeffrey Cliff]

an alternative upstream is available at
https://notabug.org/themusicgod1/chai-as-promised

Hopefully this helps,
Jeff Cliff

Bug#928401: [pre-approval] unblock: manpages/4.16-2

[Dr. Tobias Quathamer]

control: tag -1 - moreinfo

Am 06.05.19 um 22:27 schrieb Paul Gevers:
> Please continue with the upload and remove the moreinfo tag once the
> package is available in unstable.
> 
> Paul

Hi Paul,

the package is now uploaded.

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature

Bug#928615: Please switch to libidn2

[Michael Biebl]

Am 07.05.19 um 18:56 schrieb Laurent Bigonville:
> Source: systemd
> Version: 241-3
> Severity: wishlist
> 
> Hi,
> 
> It might be intresting to switch from libidn11 to libidn2
> 
> On a freshly debootstrapped chroot, libidn2 is already installed:
> 
> # apt-cache rdepends --installed libidn2-0
> libidn2-0
> Reverse Depends:
>   libc6
>   iputils-ping
>   libgnutls30
> 
> While libidn11 is only used by systemd:
> 
> # apt-cache rdepends --installed libidn11
> libidn11
> Reverse Depends:
>   systemd

Sure, fine with me.


Does
https://salsa.debian.org/systemd-team/systemd/commit/4338e49e744376d2b47afb14f85d944f0e871a89
look to you?
-- 
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#928618: linux: autopkgtest regression

[Paul Gevers]

Source: linux
Version: 4.19.37-1
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: regression

Dear maintainers,

With a recent upload of linux the autopkgtest of linux fails in testing
when that autopkgtest is run with the binary packages of linux from
unstable. It passes when run with only packages from testing. In tabular
form:
   passfail
linux  from testing4.19.37-1
versioned deps [0] from testingfrom unstable
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is a reason for blocking the migration to
testing [1]. Can you please investigate the situation and fix it?

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

Paul

[0] You can see what packages were added from the second line of the log
file quoted below. The migration software adds source package from
unstable to the list if they are needed to install packages from
linux/4.19.37-1. I.e. due to versioned dependencies or breaks/conflicts.
[1] https://qa.debian.org/excuses.php?package=linux

https://ci.debian.net/data/autopkgtest/testing/amd64/l/linux/2340029/log.gz

autopkgtest [03:11:55]: test python: [---
I: Running pycodestyle...
debian/bin/gencontrol_signed.py:303:30: E131 continuation line unaligned
for hanging indent
debian/bin/gencontrol_signed.py:308:36: E202 whitespace before '}'
E: pycodestyle detected problems
I: Running pyflakes...
debian/bin/abiupdate.py:139: local variable 'e' is assigned to but never
used
E: pyflakes detected problems
I: Running debian_linux.debian unit tests...
.
--
Ran 21 tests in 0.002s

OK
autopkgtest [03:11:57]: test python: ---]



signature.asc
Description: OpenPGP digital signature

Bug#928547: mailscripts: notmuch utilities should be better integrated into notmuch

[Sean Whitton]

Hello,

On Mon 06 May 2019 at 05:35PM -04, Daniel Kahn Gillmor wrote:

> notmuch-{import-patch,extract-patch,slurpdebbug} could all be "notmuch"
> subcommands, similar to the way that notmuch-emacs-mua is.  their
> configuration could also be stored in notmuch's own configuration,
> rather than in ~/.config/mailscripts.  that would make them nicer for
> folks already using notmuch. (and for folks not using notmuch, those
> tools aren't very useful ;) )
>
> Making this a tighter integration would mean maybe fixing up "notmuch
> help" (so that it learns about any installed subcommand extensions and
> at least tries their manual pages), and maybe fixing the notmuch bash
> tab completion as well.

Could you explain how this would be beneficial?  I don't really see
what's gained.

> also, it's not clear whether the configuration should be stored in the
> config file for notmuch, or in the database.  I still believe we should
> be getting rid of the config file if possible and storing most config in
> the database, so i'd prefer to not store anything in the config file.

As an aside, I hope this does not happen.

I consider my notmuch database just a cache; I do not store any
nonreproducible data in it.  I hope this usecase will continue to be
supported.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#928617: package-contains-python-header-in-incorrect-directory should be adjusted for python 3.8

[Matthias Klose]

Package: lintian
Version: 2.13.0
Severity: important

Python 3.8 alpha4 dropped the `m' modifier, so /usr/include/python3.8 is not the
correct include dir.  Please reflect that change in lintian.

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Guilhem Moulin]

Hi Dimitri,

On Tue, 07 May 2019 at 15:46:25 +0100, Dimitri John Ledkov wrote:
> On Tue, 7 May 2019 14:16:43 +0100 Dimitri John Ledkov  wrote:
>> This issue concerns me a lot at the moment. I am currently trying to
>> upgrade OpenSSL from 1.1.0 to 1.1.1 in Ubuntu 18.04 LTS (bionic). And
>> as far as I understand all the comment on this debian bug report,
>> current application are potentially broken and brokeness happens more
>> often with TLSv1.3 and the new OpenSSL 1.1.1 defaults
>> (SSL_MODE_AUTO_RETRY).
>>
>> As far as I understand we do not have a fixed LWP that works correctly
>> in blocking, non-blocking, tls 1.2 and tls 1.3. To prevent regressing
>> existing users further, does it make sense for me to make updates in
>> bionic that:
>>
>> 1) limit SSL_new and SSL_CTX_new to TLS v1.2 max
>> and
>> 2) disable SSL_MODE_AUTO_RETRY by default for TLS v1.2 connections?
>>
>> My goal is to keep existing breakages as is, without introducing new
>> ones, whilst getting OpenSSL 1.1.1 into bionic. Granted this will not
>> get TLS v1.3 enabled for perl server/clients without code changes, but
>> oh well. Those who want it, will be able to force / start using it.

It's IMHO unfortunate to change the default in Net::SSLeay, as TLSv1.3
brings quite a few improvements (in terms of security as well as
performance).  OpenSSL 1.1.1 was released on 11 Sep 2018 and uploaded to
sid the day after, breaking programs using select()/poll() with blocking
I/O; this is not specific to Perl bindings — other languages are also
affected — yet no one is suggesting to disable TLSv1.3 globally in
libssl :-)

If TLSv1.3 should be disabled (and the SSL_MODE_AUTO_RETRY flag cleared)
then IMHO I think it should be done as close at possible to the leaf
application (LWP in this case), not in the library itself.  After all we
have only one RC bug about this, so I guess other programs (in any
language) 1/ have workarounds; 2/ aren't using select()/poll() with
blocking I/O; or 3/ aren't affected because they never used SSL_read()
as documented.  IHMO the libssl change shouldn't be reason to penalize
all applications, given most seems unaffected.

I still think the right fix is to make SSL_MODE_AUTO_RETRY (or even the
whole mode bitmask mode?) configurable in IO::Socket::SSL, and clear it
in programs and libraries using select()/poll() with blocking I/O, such
as LWP in this case.  AFAICT that follows the intention of OpenSSL's
development team, unlike global library changes.  AFAICT the attached
patch (to sid's IO::Socket::SSL and LWP::Protocol::https, respectively
2.060-3 and 6.36-1) fixes the problem for me, while preserving TLSv1.3
support and default.
 
> I proposed the following patch upstream / request for comments
> https://github.com/radiator-software/p5-net-ssleay/pull/139

I personally don't like this change as I hope Buster's Net::SSLeay and
other SSL libraries will default to TLSv1.3 on capable servers :-)  2
comments anyway:

  * OpenSSL <1.1.0 has no SSL_CTX_set_max_proto_version(), so an OpenSSL
version test is lacking (nothing more as <1.1.0 has no TLSv1.3
support and SSL_MODE_AUTO_RETRY is unset by default).
 
  * Disabling TLSv1.3 won't always prevent hangs, you also need to clear
SSL_MODE_AUTO_RETRY to revert to the pre-1.1.1 defaults.  With
TLSv1.2, SSL_read() returns SSL_ERROR_WANT_READ upon renegotiation,
causing applications using select()/poll() with blocking I/O to hang
if SSL_MODE_AUTO_RETRY is set.

Cheers,
-- 
Guilhem, who isn't not in the Debian Perl team, but who would be quite
sad to have to wait one full release cycle for out-of-the-box TLSv1.3
support.
--- a/IO/Socket/SSL.pm
+++ b/IO/Socket/SSL.pm
@@ -260,6 +260,14 @@
 	INIT { init() }
 	init();
 }
+
+if (!defined ::SSLeay::CTX_clear_mode) {
+	# assume SSL_CTRL_CLEAR_MODE being 78 since it was always this way
+	*Net::SSLeay::CTX_clear_mode = sub {
+	my ($ctx,$opt) = @_;
+	Net::SSLeay::CTX_ctrl($ctx,78,$opt,0);
+	};
+}
 }
 
 # global defaults which can be changed using set_defaults
@@ -2433,6 +2441,11 @@
 	# cannot guarantee, that the location of the buffer stays constant
 	Net::SSLeay::CTX_set_mode( $ctx,
 	SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER|SSL_MODE_ENABLE_PARTIAL_WRITE);
+	# Clear SSL_MODE_AUTO_RETRY on request; useful for applications using select/poll
+	# with blocking I/O. (Since OpenSSL 1.1.1 SSL_MODE_AUTO_RETRY is enabled by
+	# default, making such applications hang.)
+	Net::SSLeay::CTX_clear_mode( $ctx, Net::SSLeay::MODE_AUTO_RETRY() )
+		if $arg_hash->{SSL_mode_auto_no_retry};
 
 	if ( my $proto_list = $arg_hash->{SSL_npn_protocols} ) {
 	return IO::Socket::SSL->_internal_error("NPN not supported in Net::SSLeay",9)
--- a/LWP/Protocol/https.pm
+++ b/LWP/Protocol/https.pm
@@ -32,6 +32,11 @@
 $ssl_opts{SSL_ca_file} = '/etc/ssl/certs/ca-certificates.crt';
 	}
 }
+# Clear SSL_MODE_AUTO_RETRY as LWP uses select with blocking I/O.
+# (Since OpenSSL 1.1.1 SSL_MODE_AUTO_RETRY is enabled 

Bug#928616: FTBFS: cpl-plugin-fors has tests failing in parallel builds

[Frédéric Bonnard]

Package: src:cpl-plugin-fors
Version: 5.3.32+dfsg-1
Control: tags -1 patch ftbfs

--

Dear maintainer,

cpl-plugin-fors has a failing test and thus FTBFS when I run a parallel
build :

---
PASS: hdrl_buffer-test
PASS: hdrl_bpm_3d-test
PASS: hdrl_multiiter-test
../admin/test-driver: line 107: 55895 Segmentation fault  "$@" > $log_file 
2>&1
FAIL: hdrl_frameiter-test
PASS: hdrl_flat-test
PASS: hdrl_strehl-test
...

[ ERROR ] Test 116 failed at hdrl_frameiter-test.c:83: (cpl_image_get(h->image, 
1, 1, )) = -2; (values[cnt]) = 2. CPL error(s) set prior to and during this 
test. Prior to this test errno=2: No such file or directory.
[ ERROR ] Dumping all 6 error(s):
[ ERROR ]   [1/6] 'File not found: "could not open the named file" from CFITSIO 
(ver. 3.45) ffdkopn()=104. filename='frameiter0_55895.fits', mode=0' (9) at 
cpl_io_fits_open_diskfile:cpl_io_fits.c:489
[ ERROR ]   [2/6] 'File read/write error: "could not open the named file" from 
CFITSIO (ver. 3.45) ffdkopn()=104. filename='frameiter0_55895.fits', 
im_type=1048576, pnum=0, xtnum=2' (5) at cpl_image_load_one:cpl_image_io.c:435
[ ERROR ]   [3/6] 'File read/write error' (5) at 
cpl_image_load:cpl_image_io.c:380
[ ERROR ]   [4/6] 'File not found: "could not open the named file" from CFITSIO 
(ver. 3.45) ffdkopn()=104. filename='frameiter0_55895.fits', mode=0' (9) at 
cpl_io_fits_open_diskfile:cpl_io_fits.c:489
...

---

This is due to the fact that hdrl_frameiter-test and hdrl_multiiter-test
use a too large wildcard to delete files they used.
Here is a merge request with a patch that I tested successfully with
some more detailed explanations :

https://salsa.debian.org/debian-astro-team/cpl-plugin-fors/merge_requests/1

Regards,


F.


pgpiOQit7GqqR.pgp
Description: PGP signature

Bug#928612: u-boot-sunxi: enable support for nanopi_neo2 board

[Vagrant Cascadian]

On 2019-05-07, Domenico Andreoli wrote:
>   Salsa MR #5 enables support for NanoPi NEO 2. I tested it with Buster
> RC1 installer, althought it resulted in a non-bootable system u-boot
> worked well enough.

Just for clarity, you're saying the non-bootability was unrelated to
u-boot, but u-boot was able to boot a kernel + initrd + dtb?

I made some comments on the merge request to reduce the diff so it would
be possible to get into buster.

Thanks!

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#928615: Please switch to libidn2

[Laurent Bigonville]

Source: systemd
Version: 241-3
Severity: wishlist

Hi,

It might be intresting to switch from libidn11 to libidn2

On a freshly debootstrapped chroot, libidn2 is already installed:

# apt-cache rdepends --installed libidn2-0
libidn2-0
Reverse Depends:
  libc6
  iputils-ping
  libgnutls30

While libidn11 is only used by systemd:

# apt-cache rdepends --installed libidn11
libidn11
Reverse Depends:
  systemd

Kind regards,
Laurent Bigonville

-- Package-specific info:

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

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

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.133
ii  udev 241-3

-- no debconf information

Bug#922659: emacs-lucid: wanderlust with ssl fails without gnutls-log-level non-zero

[Tatsuya Kinoshita]

On February 19, 2019 at 12:04PM +1100, peter.chubb (at data61.csiro.au) wrote:
> Package: emacs-lucid
> Version: 1:26.1+1-3.2
> Severity: normal
> 
> If I do
>   (setq gnutls-log-level 1)
> to try to debug the problem, the connection works perfectly,

Seems to be the same issue of the upstream bug#34341.

  - 26.1; url-retrieve-synchronously returns blank buffer
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=34341

Thanks,
-- 
Tatsuya Kinoshita

Bug#928613: anonymous users get error on timeline when selecting to see sensitive tickets

[Jamie McClelland]

Package: trac-sensitivetickets
Version: 0.21-1

When an anonymous user selects the option to see: Activity on sensitive
tickets I expect them to get a list of rows saying "Redacted".

Instead, they get an error:

Event provider SensitiveTicketsPolicy failed for filters "Activity on
sensitive tickets": AttributeError: 'Environment' object has no
attribute 'get_db_cnx'

The fix seems to be:

--- sensitivetickets.py.orig2019-05-07 12:23:55.990149044 -0400
+++ sensitivetickets.py 2019-05-07 12:24:36.477117871 -0400
@@ -176,7 +176,7 @@
 ts_start = to_utimestamp(start)
 ts_stop = to_utimestamp(stop)

-db = self.env.get_db_cnx()
+db = self.env.get_read_db()
 cursor = db.cursor()

 if 'ticket_details' in filters:


Thank you!

jamie



-- 
May First/People Link
Growing networks to build a just world
https://mayfirst.org
https://support.mayfirst.org

OpenPGP Key: http://current.workingdirectory.net/pages/identity/
xmpp: ja...@mayfirst.org



signature.asc
Description: OpenPGP digital signature

Bug#928610: unblock: node-unicode-data/0~20190414+gitbf518e99-2

[Xavier]

Le 07/05/2019 à 17:20, Xavier Guimard a écrit :
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: unblock
> 
> Please unblock package node-unicode-data
> 
> Hi all,
> 
> Julien pushed a new version of node-unicode-data that fixes #927944
> (FTBFS). Changes are only related to unicode-12 support.
> 
> Cheers,
> Xavier
> 
> unblock node-unicode-data/0~20190414+gitbf518e99-2

node-unicode-data has one (build) reverse dependency: node-regjsparser.
This package has these reverse dependencies:
 - node-regexpu-core
   +-> node-babel-preset-es2015
   +-> node-babel-preset-latest
   +-> node-babel-preset-es2015-loose
   +-> node-css-selector-tokenizer
   +-> node-css-loader
   +-> node-buble
   +-> node-rollup-plugin-buble
   +-> rollup

So this unblock will require also an upgrade of node-regjsparser

Bug#928609: [Pkg-utopia-maintainers] Bug#928609: network-manager: Invalid system-connections configuration during preseeding

[Michael Biebl]

Am 07.05.19 um 17:12 schrieb Yannick Schinko:
> Package: network-manager
> Version: 1.14.6-2
> Severity: normal
> Tags: d-i
> 
> I'm currently trying to install network-manager during a preseeded 
> installation on a SBC (sing board computer) (It's an APU.2D4) with multiple 
> network interfaces.
> I added the package to the `d-i pkgsel/include string` option. It installs 
> just fine and network access during the installation works fine.
> However after the installation finishes and the system boots, there is single 
> file under `/etc/NetworkManager/system-connections` called `Wired Connection 
> 1`. This file won't get created when I install the package on a live system.
> The huge issue with the file is that all 3 network interfaces are now 
> considered "Wired Connection 1" and cannot be controlled seperately. Running 
> the commands `nmcli con delete $(nmcli -g uuid con); systemctl restart 
> NetworkManager.service` fixes the issue permanetly. (Meaning all 3 interfaces 
> now are named `Wired Connection 1-3` and can be conttrolled independetly. Or 
> the package behaves as it would if it was installed on a live system) 
> (Alternatively the file can be removed while network-manager is off)
> 
> The only way I was able to fix this issue was by disabling the NetworkManager 
> service during the late_command script, adding a first boot script and first 
> removing the file then restarting and reenabling the service.

I assume this file is created by the debian installer, so you should
probably talk to them. See

https://qa.debian.org/developer.php?email=debian-boot%40lists.debian.org

I would guess that the netcfg part is the most likely package.
-- 
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#928612: u-boot-sunxi: enable support for nanopi_neo2 board

[Domenico Andreoli]

Package: u-boot-sunxi
Version: 2019.01+dfsg-5
Severity: wishlist

Hi,

  Salsa MR #5 enables support for NanoPi NEO 2. I tested it with Buster
RC1 installer, althought it resulted in a non-bootable system u-boot
worked well enough.

Regards,
Domenico

-- 
3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13

Bug#919486: Please support Debian Buster

[Laurent Bigonville]

FTR, this bug was set to serious as I think this _must_ be fixed before 
buster is released


IMVHO, buster _needs_ to be able to detect the iso from itself to allow 
users to have a correct experience with virt-manager/virt-install and such

Bug#928604: sosreport explanation

[Eric Desrochers]

sosreport is a unified tool for collecting system logs and other debug
information on a given system. Its collecting the data and then prepare a
tarball ready to be send to outside parties for support.

Reference:
https://sos.readthedocs.io/en/latest/
https://github.com/sosreport/sos

Bug#928604: ITP: soscleaner -- Python application to clean sensitive and un-wanted data from an existing sosreport

[Chris Lamb]

Hi Eric,

> ITP: soscleaner -- Python application to clean sensitive and un-
> wanted data from an existing sosreport

Please excuse this drive-thru comment but I think this description
etc.  could be dramatically improved if it mentioned what a "sos"
report is. :)


Best wishes,

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

Bug#928604: ITP: soscleaner -- Python application to clean sensitive and un-wanted data from an existing sosreport

[Chris Lamb]

Chris Lamb wrote:

> […]

FYI, eric.desroc...@canonical.com (removed from CC in this message)
bounces for me.


Regards,

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

Bug#928611: ITP: r-cran-diffobj -- diffs for GNU R objects

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-diffobj -- diffs for GNU R objects
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-diffobj
  Version : 0.2.2
  Upstream Author : Brodie Gaslam,
* URL : https://cran.r-project.org/package=diffobj
* License : GPL-2+
  Programming Lang: GNU R
  Description : diffs for GNU R objects
 This GNU R package generates a colorized diff of two R objects for
 an intuitive visualization of their differences.  It is helpful in
 some test suite packages (mainly vdiffr).

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-diffobj

Bug#919632: closed by Ben Hutchings (Bug#919632: fixed in firmware-nonfree 20190502-1)

[Ben Hutchings]

Control: reopen -1

On Tue, 2019-05-07 at 13:44 +0200, Kevin Price wrote:
> Dear maintainer,
> 
> This didn't fix this bug.
> 
> Am 06.05.19 um 23:36 schrieb Debian Bug Tracking System:
> > #919632: "New" firmware instantly crashes on QCA9377
> > 
> > If this explanation is unsatisfactory and you have not received a
> > better one in a separate message then please contact Ben Hutchings 
> >  by
> > replying to this email.
> > 
> > If you
> > have further comments please address them to 919...@bugs.debian.org,
> > and the maintainer will reopen the bug report if appropriate.
> > 
> > Changes:
> >  firmware-nonfree (20190502-1) unstable; urgency=medium
> >[ Ben Hutchings ]
> >* atheros: Add Qualcomm Atheros QCA9377 rev 1.0 firmware version
> >  WLAN.TF.2.1-00021-QCARMSWP-1 (Closes: #903437, #919632, #927917)
> 
> I'm not affected by the only change in
> 
>   /lib/firmware/updates/ath10k/QCA9377/hw1.0 ,
> 
> which is the addition of
> 
>   firmware-6.bin . My QCA9377 loads firmware-5.bin, which has not been
> changed since 2018-02-15 (upstream), so it still instantly crashes.
> dmesg attached.

OK, sorry.  It looked like the problem in these three bugs was that
newer versions of the driver that preferred firmware-6.bin were
incompatible with firmware-5.bin even though they tried to use it.

Since the older driver version also fails, I suppose I should revert
the previous upstream change to firmware-5.bin.

Ben.

-- 
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.




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

Bug#928609: network-manager: Invalid system-connections configuration during preseeding

[Yannick Schinko]

Package: network-manager
Version: 1.14.6-2
Severity: normal
Tags: d-i

I'm currently trying to install network-manager during a preseeded installation 
on a SBC (sing board computer) (It's an APU.2D4) with multiple network 
interfaces.
I added the package to the `d-i pkgsel/include string` option. It installs just 
fine and network access during the installation works fine.
However after the installation finishes and the system boots, there is single 
file under `/etc/NetworkManager/system-connections` called `Wired Connection 
1`. This file won't get created when I install the package on a live system.
The huge issue with the file is that all 3 network interfaces are now 
considered "Wired Connection 1" and cannot be controlled seperately. Running 
the commands `nmcli con delete $(nmcli -g uuid con); systemctl restart 
NetworkManager.service` fixes the issue permanetly. (Meaning all 3 interfaces 
now are named `Wired Connection 1-3` and can be conttrolled independetly. Or 
the package behaves as it would if it was installed on a live system) 
(Alternatively the file can be removed while network-manager is off)

The only way I was able to fix this issue was by disabling the NetworkManager 
service during the late_command script, adding a first boot script and first 
removing the file then restarting and reenabling the service.

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 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 /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.12-1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-3
ii  libbluetooth3  5.50-1
ii  libc6  2.28-10
ii  libcurl3-gnutls7.64.0-2
ii  libglib2.0-0   2.58.3-1
ii  libgnutls303.6.6-2
ii  libjansson42.12-1
ii  libmm-glib01.10.0-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.20-8
ii  libnm0 1.14.6-2
ii  libpam-systemd 241-3
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0241-3
ii  libteamdctl0   1.28-1
ii  libudev1   241-3
ii  libuuid1   2.33.1-0.1
ii  lsb-base   10.2019031300
ii  policykit-10.105-25
ii  udev   241-3
ii  wpasupplicant  2:2.7+git20190128+0c1e29f-5

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iptables 1.8.2-4
ii  isc-dhcp-client  4.4.1-2
ii  modemmanager 1.10.0-1
ii  ppp  2.4.7-2+4.1

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#928610: unblock: node-unicode-data/0~20190414+gitbf518e99-2

[Xavier Guimard]

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

Please unblock package node-unicode-data

Hi all,

Julien pushed a new version of node-unicode-data that fixes #927944
(FTBFS). Changes are only related to unicode-12 support.

Cheers,
Xavier

unblock node-unicode-data/0~20190414+gitbf518e99-2

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/README.md b/README.md
index c66e41d..e1837f1 100644
--- a/README.md
+++ b/README.md
@@ -56,6 +56,7 @@ For more information, see the README for the package you’re 
interested in. [He
 * [_unicode-9.0.0_](https://npmjs.org/package/unicode-9.0.0#readme) 
([repository](https://github.com/mathiasbynens/unicode-9.0.0#readme))
 * [_unicode-10.0.0_](https://npmjs.org/package/unicode-10.0.0#readme) 
([repository](https://github.com/mathiasbynens/unicode-10.0.0#readme))
 * [_unicode-11.0.0_](https://npmjs.org/package/unicode-11.0.0#readme) 
([repository](https://github.com/mathiasbynens/unicode-11.0.0#readme))
+* [_unicode-12.0.0_](https://npmjs.org/package/unicode-12.0.0#readme) 
([repository](https://github.com/mathiasbynens/unicode-12.0.0#readme))
 
 Note that these READMEs are auto-generated by this script, too – they describe 
all the data that is available for that particular Unicode version. To 
programmatically get this list of available categories, scripts, script 
extensions, blocks, and properties for a given Unicode version, just `require` 
the main module for that version:
 
diff --git a/debian/changelog b/debian/changelog
index d1c41be..eb09837 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,16 @@
+node-unicode-data (0~20190414+gitbf518e99-2) unstable; urgency=medium
+
+  * Make the package really work with unicode 12.
+
+ -- Julien Puydt   Mon, 15 Apr 2019 19:12:53 +0200
+
+node-unicode-data (0~20190414+gitbf518e99-1) unstable; urgency=medium
+
+  * New upstream release.
+  * Bump std-ver to 4.3.0.
+
+ -- Julien Puydt   Sun, 14 Apr 2019 00:51:30 +0200
+
 node-unicode-data (0~20181101+gitaddfb440-1) unstable; urgency=medium
 
   * Mention unicode 11 in package description (Closes: #908212).
diff --git a/debian/control b/debian/control
index 440e198..1cf0484 100644
--- a/debian/control
+++ b/debian/control
@@ -15,18 +15,18 @@ Build-Depends: debhelper (>= 11),
node-unicode-property-value-aliases (>= 3.3~),
node-when (>= 3.7.8),
nodejs,
-   unicode-data (>= 11.0.0)
-Standards-Version: 4.2.1
+   unicode-data (>= 12.0.0)
+Standards-Version: 4.3.0
 Homepage: https://github.com/mathiasbynens/node-unicode-data
 Vcs-Git: https://salsa.debian.org/js-team/node-unicode-data.git
 Vcs-Browser: https://salsa.debian.org/js-team/node-unicode-data
 
-Package: node-unicode-11.0.0
+Package: node-unicode-12.0.0
 Architecture: all
 Depends: nodejs, ${misc:Depends}
-Description: Unicode 11.0.0 data for Node.js
+Description: Unicode 12.0.0 data for Node.js
  JavaScript-compatible Unicode data. Arrays of code points, arrays of symbols,
- and regular expressions for Unicode v11.0.0’s categories, scripts, blocks,
+ and regular expressions for Unicode v12.0.0’s categories, scripts, blocks,
  bidi, and other properties.
  .
  Node.js is an event-based server-side JavaScript engine.
diff --git a/debian/resources.js b/debian/resources.js
index ad85789..79cfef5 100644
--- a/debian/resources.js
+++ b/debian/resources.js
@@ -1,6 +1,6 @@
 var resources = [
 {
-   'version': '11.0.0',
+   'version': '12.0.0',
'main': '/usr/share/unicode/UnicodeData.txt',
'scripts': '/usr/share/unicode/Scripts.txt',
'script-extensions': '/usr/share/unicode/ScriptExtensions.txt',
diff --git a/debian/rules b/debian/rules
index 0a8b449..2beb97f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -1,7 +1,7 @@
 #!/usr/bin/make -f
 
 UNICODE = /usr/share/unicode
-VERSION = 11.0.0
+VERSION = 12.0.0
 
 %:
dh $@
diff --git a/debian/tests/control b/debian/tests/control
index e7f0022..c107051 100644
--- a/debian/tests/control
+++ b/debian/tests/control
@@ -1,2 +1,2 @@
 Tests: require
-Depends: node-unicode-11.0.0
+Depends: node-unicode-12.0.0
diff --git a/debian/tests/require b/debian/tests/require
index e7cd5d1..b872af1 100644
--- a/debian/tests/require
+++ b/debian/tests/require
@@ -1,3 +1,3 @@
 #!/bin/sh
 set -e
-node -e "require('unicode-11.0.0');"
+node -e "require('unicode-12.0.0');"
diff --git a/package.json b/package.json
index 7b2fc9f..e3be398 100644
--- a/package.json
+++ b/package.json
@@ -41,17 +41,17 @@
   },
   "dependencies": {
 "cp": "^0.2.0",
-

Bug#928608: unblock: matrix-synapse/0.99.2-5

[Andrej Shadura]

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

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Please unblock package matrix-synapse.

This upload backports two security updates from 0.99.3.

unblock matrix-synapse/0.99.2-5

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQJTBAEBCAA9FiEE47V74F4CWMP6ghzXtke0/0DsYwMFAlzRoQ8fHGFuZHJldy5z
aGFkdXJhQGNvbGxhYm9yYS5jby51awAKCRC2R7T/QOxjAyrQEACo2di2PSfR7NbF
evPJxSV1iD83rZZf19ACH39XYR/rSAGOM2ypeEy6jpDSv4sRwYkB7ag85ns9OoTp
41F29yXL8ZdPVvlM7ThPvVZj3Fi9fp1zu8VfVxqZR0nglvA/6X+oiaNz5Xb3Sd8m
kh6Gld68k+6r4JDgR5IU7tuWabfMOU+lKPa6jMRQU25T6TCyc0qkNJiMgGTYba33
b9PWmTrhFL7+5Xt+u9YaaAPtC7zDU/8CkuPMEiZcsvdCwK7P2bcpc/il+TfM2f8n
s4OpFGT/dZC5TBW9rQnvXIinei9l33lf3yG2MWsibEIxwaJ8yySSb8jjr29tXNK6
wJqa+itgJLLI7IcYaFe/ndKBqhNN7XnP6QyWdFAsUdC9Ha4AbLRWvA9VEPFMT0tY
1xeeGn2UmNcoOFlwZ7Kr24yhk1xjK8twbOcubeyIXD7HkQ5FTbTkYSL0DP3vZl14
ZsnaYbElRsplpCSnpAqclAYEkpfL3CM4rrdALgk/3mxEgNcKUAzu6BwPVNfYcmsz
irUfTHgbJJug7HgGf8R8Q6qa0JcL8DyqUvtOZodQo//0BuI2dEuzc898WiaxyjVr
rUWzT7UmyB51ijDRPKc36hGIZwCXdnLmX2HCF9O2i3fGnXGkV/PkMIu4F7bN/3tW
lv0lsvm4A9rYJ7HuTscz1hKfOvNSig==
=23ET
-END PGP SIGNATURE-
diff --git a/debian/changelog b/debian/changelog
index 0dfdb8d..a786521 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+matrix-synapse (0.99.2-5) unstable; urgency=high
+
+  * Security updates backported from 0.99.3:
+- Use SystemRandom for token generation
+- Blacklist 0.0.0.0 and :: by default for URL previews
+
+ -- Andrej Shadura   Fri, 03 May 2019 22:26:41 +0200
+
 matrix-synapse (0.99.2-4) unstable; urgency=medium
 
   [ Antoine Beaupré ]
diff --git 
a/debian/patches/blacklist-localhost-by-default-for-URL-previews.patch 
b/debian/patches/blacklist-localhost-by-default-for-URL-previews.patch
new file mode 100644
index 000..21853e9
--- /dev/null
+++ b/debian/patches/blacklist-localhost-by-default-for-URL-previews.patch
@@ -0,0 +1,85 @@
+From 1a7104fde3abc5392b90ca084efa896d46e24f91 Mon Sep 17 00:00:00 2001
+From: Richard van der Hoff 
+Date: Fri, 3 May 2019 13:46:50 +0100
+Subject: [PATCH] Blacklist 0.0.0.0 and :: by default for URL previews
+
+---
+ changelog.d/5134.bugfix  |  1 +
+ docs/sample_config.yaml  | 14 +-
+ synapse/config/repository.py | 28 ++--
+ 3 files changed, 28 insertions(+), 15 deletions(-)
+ create mode 100644 changelog.d/5134.bugfix
+
+diff --git a/changelog.d/5134.bugfix b/changelog.d/5134.bugfix
+new file mode 100644
+index 00..684d48c53a
+--- /dev/null
 b/changelog.d/5134.bugfix
+@@ -0,0 +1 @@
++Blacklist 0.0.0.0 and :: by default for URL previews. Thanks to @opnsec for 
identifying and responsibly disclosing this issue too!
+diff --git a/synapse/config/repository.py b/synapse/config/repository.py
+index 3f34ad9b2a..d155d69d8a 100644
+--- a/synapse/config/repository.py
 b/synapse/config/repository.py
+@@ -154,17 +154,21 @@ def read_config(self, config):
+ except ImportError:
+ raise ConfigError(MISSING_NETADDR)
+ 
+-if "url_preview_ip_range_blacklist" in config:
+-self.url_preview_ip_range_blacklist = IPSet(
+-config["url_preview_ip_range_blacklist"]
+-)
+-else:
++if "url_preview_ip_range_blacklist" not in config:
+ raise ConfigError(
+ "For security, you must specify an explicit target IP 
address "
+ "blacklist in url_preview_ip_range_blacklist for url 
previewing "
+ "to work"
+ )
+ 
++self.url_preview_ip_range_blacklist = IPSet(
++config["url_preview_ip_range_blacklist"]
++)
++
++# we always blacklist '0.0.0.0' and '::', which are supposed to be
++# unroutable addresses.
++self.url_preview_ip_range_blacklist.update(['0.0.0.0', '::'])
++
+ self.url_preview_ip_range_whitelist = IPSet(
+ config.get("url_preview_ip_range_whitelist", ())
+ )
+@@ -235,11 +239,11 @@ def default_config(self, data_dir_path, **kwargs):
+   height: 600
+   method: scale
+ 
+-# Is the preview URL API enabled?  If enabled, you *must* specify
+-# an explicit url_preview_ip_range_blacklist of IPs that the spider is
+-# denied from accessing.
++# Is the preview URL API enabled?
++# 'False' by default: uncomment the following to enable it (and 
specify a
++# url_preview_ip_range_blacklist blacklist).
+ #
+-url_preview_enabled: False
++#url_preview_enabled: True
+ 
+ # List of IP address CIDR ranges that the URL preview spider is denied
+ # from accessing.  There are no defaults: you must explicitly
+@@ -249,6 +253,9 @@ def default_config(self, data_dir_path, **kwargs):
+ # synapse to issue arbitrary GET requests to your 

Bug#837093: edk2: Please build an EFI shell package

[dann frazier]

On Tue, May 7, 2019 at 4:03 AM Yves-Alexis Perez  wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Thu, 8 Sep 2016 20:28:36 +0200 Julian Andres Klode  wrote:
> > Source: edk2
> > Severity: wishlist
> >
> > Having an EFI shell on a real host is quite useful, it would be nice
> > to have one packaged so bootloader(s/configuration tools) can install
> > them to the ESP(s).
>
> Hi,
>
> is there any news on this? I'd be interested as well (in my case because I'm
> setting up a repository with scripts to build a bootable EFI key and would
> rather add build-dependencies rather than shipping the efi shell binary
> inside).

Hi Yves-Alexis,

  I think it is a reasonable request - happy to consider patches :)

 -dann

Bug#928473: dgit: not clear what to do when earlier uploads used dgit but intermediate ones didn't

[Colin Watson]

On Mon, May 06, 2019 at 04:44:43PM +0100, Ian Jackson wrote:
> Colin Watson writes ("Bug#928473: dgit: not clear what to do when earlier 
> uploads used dgit but intermediate ones didn't"):
> > I'd been hoping to avoid the pseudomerge and have the histories be
> > exactly identical, but I probably shouldn't be too precious about that,
> > and you make a good point about allowing people with existing dgit
> > clones to fast-forward.
> 
> Other than in split-brain quilt modes (which don't apply in this
> case), the pseudomerge will appears on the branch you run `dgit push'
> from.  So the histories will be identical because the pseudomerge will
> be in your master.  Is that a problem ?  I thought I should mention
> it...

Oh, so it did.  Well, it's too late now in any case, but I think on
balance I prefer having it there in both master and dgit/dgit/sid rather
than just the latter.  Thanks for the note.

-- 
Colin Watson   [cjwat...@debian.org]

Bug#891954: ibus-libpinyin can't select character candidate except the first one.

[Ola Rende]

I feel this is a bug deserving more than "severity: normal", given that it 
almost completely destroys the OS's ability to input chinese characters. The 
fact that the workaround also destroys the cache of input training data is not 
great either.

Furthermore, the fact that the only mention of the workaround is in this thread 
and an AskUbuntu page, laypeople are going to need quite a bit of luck to find 
this.

On Fri, 02 Mar 2018 22:41:40 -0500 Bo Lan 
 wrote:

> Package: ibus-libpinyin
> Version: 1.9.2-2
> Severity: normal
>
> Dear Maintainer,
>
> The ibus-libpinyin (Intelligent Pinyin) is not be able to select character
> candidate other than the first one.
>
> Once I input a pinyin for a Chinese character, by default, there are 5
> candidates can be selected. If I need the first candidate, I can press 1 or
> space on the keyboard to select it. It works. If I need one of the 2nd to 5th
> candidates, however, I need to press 2 to 5 to select, and it doesn't work.
>
> One pinyin can have many of characters, if we can select only one, the program
> is not usable.
>
>
>
> -- System Information:
> Debian Release: buster/sid
> APT prefers testing
> APT policy: (500, 'testing'), (100, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.14.0-3-amd64 (SMP w/8 CPU cores)
> Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), 
> LANGUAGE=en_CA.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages ibus-libpinyin depends on:
> ii ibus 1.5.17-3
> ii libc6 2.26-6
> ii libgcc1 1:8-20180218-1
> ii libglib2.0-0 2.54.3-2
> ii libibus-1.0-5 1.5.17-3
> ii libpinyin13 2.1.91-1
> ii libsqlite3-0 3.22.0-1
> ii libstdc++6 8-20180218-1
> ii python3 3.6.4-1
> ii python3-gi 3.26.1-2
>
> ibus-libpinyin recommends no packages.
>
> ibus-libpinyin suggests no packages.
>
> -- no debconf information
>
>

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Dimitri John Ledkov]

On Tue, 7 May 2019 14:16:43 +0100 Dimitri John Ledkov  wrote:
> Hi,
>
> On Wed, 10 Apr 2019 15:22:09 +0200 Guilhem Moulin  wrote:
> >
> > Not setting the SSL_MODE_AUTO_RETRY flag back after removing O_NONBLOCK
> > (ie commenting out `Net::SSLeay::set_mode($ssl, $mode_auto_retry);` in
> > the patch) solves the problem with blocking I/O and select/poll, but
> > breaks programs expecting SSL_read() to block until application data
> > comes in.  (That is, programs not conforming to SSL_read()'s documented
> > behavior — hence which would break on renegotiation with TLS <1.3; or
> > programs relying on SSL_MODE_AUTO_RETRY being set, as in OpenSSL ≥1.1.1's
> > default context flags.)
> >
>
> This issue concerns me a lot at the moment. I am currently trying to
> upgrade OpenSSL from 1.1.0 to 1.1.1 in Ubuntu 18.04 LTS (bionic). And
> as far as I understand all the comment on this debian bug report,
> current application are potentially broken and brokeness happens more
> often with TLSv1.3 and the new OpenSSL 1.1.1 defaults
> (SSL_MODE_AUTO_RETRY).
>
> As far as I understand we do not have a fixed LWP that works correctly
> in blocking, non-blocking, tls 1.2 and tls 1.3. To prevent regressing
> existing users further, does it make sense for me to make updates in
> bionic that:
>
> 1) limit SSL_new and SSL_CTX_new to TLS v1.2 max
> and
> 2) disable SSL_MODE_AUTO_RETRY by default for TLS v1.2 connections?
>
> My goal is to keep existing breakages as is, without introducing new
> ones, whilst getting OpenSSL 1.1.1 into bionic. Granted this will not
> get TLS v1.3 enabled for perl server/clients without code changes, but
> oh well. Those who want it, will be able to force / start using it.

I proposed the following patch upstream / request for comments
https://github.com/radiator-software/p5-net-ssleay/pull/139

Regards,

Dimitri.

Bug#928304: groonga-httpd: Privilege escalation due to insecure use of logrotate

[Kentaro Hayashi]

Hi, 

I maintain Groonga package as a DM, so I want to fix #928304.
But I've never uploaded package to stable before, so I need help
 to do it in a good manner.

I've attached debdiff against current version.
Is it ok to upload stretch-security?
diff -Nru groonga-6.1.5/debian/changelog groonga-6.1.5/debian/changelog
--- groonga-6.1.5/debian/changelog	2017-01-23 19:14:09.0 +0900
+++ groonga-6.1.5/debian/changelog	2019-05-07 22:33:11.0 +0900
@@ -1,3 +1,13 @@
+groonga (6.1.5-2) stretch-security; urgency=medium
+
+  * debian/groonga-httpd.logrotate
+debian/groonga-server-gqtp.logrotate
+- Mitigate privilege escalation by changing the owner and group of logs
+  with "su" option. Reported by Wolfgang Hotwagner.
+  (Closes: #928304) (CVE-2019-11675)
+
+ -- Kentaro Hayashi   Tue, 07 May 2019 22:33:11 +0900
+
 groonga (6.1.5-1) unstable; urgency=medium
 
   * New upstream release.
diff -Nru groonga-6.1.5/debian/groonga-httpd.logrotate groonga-6.1.5/debian/groonga-httpd.logrotate
--- groonga-6.1.5/debian/groonga-httpd.logrotate	2016-12-10 15:18:50.0 +0900
+++ groonga-6.1.5/debian/groonga-httpd.logrotate	2019-05-07 22:33:11.0 +0900
@@ -1,11 +1,11 @@
 /var/log/groonga/httpd/*.log {
+su groonga groonga
 daily
 missingok
 rotate 30
 compress
 delaycompress
 notifempty
-create 640 groonga groonga
 sharedscripts
 postrotate
 . /etc/default/groonga-httpd
diff -Nru groonga-6.1.5/debian/groonga-server-gqtp.logrotate groonga-6.1.5/debian/groonga-server-gqtp.logrotate
--- groonga-6.1.5/debian/groonga-server-gqtp.logrotate	2016-12-10 15:18:50.0 +0900
+++ groonga-6.1.5/debian/groonga-server-gqtp.logrotate	2019-05-07 22:33:11.0 +0900
@@ -1,11 +1,11 @@
 /var/log/groonga/*-gqtp.log {
+su groonga groonga
 daily
 missingok
 rotate 30
 compress
 delaycompress
 notifempty
-create 640 groonga groonga
 sharedscripts
 postrotate
 . /etc/default/groonga-server-gqtp

Bug#926843: debci - environment.sh should point to /usr/share/debci if debci_base_dir not set

[Thierry fa...@linux.ibm.com]

On Fri, 19 Apr 2019 11:31:35 +0200 "Thierry fa...@linux.ibm.com"
 wrote:
> Hello,
> 
> Here is a patch for a more complete set of changes.
> Regards
> 
Hi,

Please discard my previous patch as it was solving issues running
directly the debci-* commands - I understand all commands should be run
through the 'wrapper' command debci which properly set the environment.

However I got some issues related to schroot use (test-package doesn't
allow --output-dir passed)

I am currently trying to understand why make check doesn't work on
ppc64el ... start of rabbitmq-server fails within test when using
service command it starts properly. - mopre later

-- 
Thierry Fauck @ fr.ibm.com

Bug#174424: Greeting

[Mr.Peter Sina]

Greeting, Did you received my message? please let me know.Thanks.Mr.Peter Sina.

Bug#928546: /etc/fstab.d

[Phillip Susi]

Don't forget that these days most distros are using systemd, in which
case it is in charge of boot time mounts instead of util-linux's mount
-a.  Thus any attempt to add /etc/fstab.d would require modifying
systemd, and probably udisks and probably plenty of other utilities,
which is probably why it was abandoned.

On the other hand, maybe something similar to what happend with
/etc/resolv.conf may be a solution: replace /etc/fstab with a symlink to
/run/fstab, and let systemd dynamically genereate that file based on its
view of mounts.  Then you'd control mount options with systemd units and
/etc/fstab would just be a compatability file for other utilities like
mount and udisks.

john.pseudonym1 writes:

> Package: util-linux
> Version: 2.29.2-1
> Severity: normal
>
> Hi,
>
> As part of the hardening of an anonymity focused operating system called 
> Whonix, we need to add different mount options for different filesystems e.g. 
> hidepid=2 on /proc or noexec on /home. To make sure that a user's own fstab 
> configurations are not messed up, we cannot use /etc/fstab for this. 
> /etc/fstab.d would be the perfect thing for this but it seems that support 
> for it has been 
> [abandoned](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=663623). Will 
> support for this ever be brought back? If not, are there any good 
> alternatives?
>
> Best regards.

Bug#926872: evolution: Spaces in mail view disappeared with recent updates

[Alberto Garcia]

On Thu, Apr 11, 2019 at 11:22:46AM -0400, Boyuan Yang wrote:

> I'm using the broken evolution to report bugs to you now. With the
> updates recently (within 1 week), evolution no longer shows spaces
> when displaying email.

I cannot confirm it 100%, but it seems that this is a bug in
WebKitGTK. I reported it upstream here:

   https://bugs.webkit.org/show_bug.cgi?id=197658

And there's also Debian #928399, which should probably be merged with
this one once we confirm that this is indeed the root cause.

Berto

Bug#928399: libwebkit2gtk-4.0-37: White spaces are always skipped in redinering of text plain.

[Alberto Garcia]

Control: forwarded -1 https://bugs.webkit.org/show_bug.cgi?id=197658

On Sat, May 04, 2019 at 02:03:22AM +0900, nozzy123no...@gmail.com wrote:

>  I find a problem of libwebkit2gtk-4.0-37, which doesn't show all white
> spaces in rendering text plain document under the locales except for
> "C" locale. 

Thanks, I cannot reproduce this with the Spanish locale (es_ES.UTF-8)
but it does happen with ja_JP.UTF-8 and the fonts-noto-cjk package
installed.

I reported it upstream.

Berto

Bug#928607: W: Possible missing firmware /lib/firmware/amdgpu/vega20_ta.bin for module amdgpu

[thinkpade485]

Package: firmware-amd-graphics
Version: 20190502-1
Severity: important

Dear Maintainer,

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

   * What led up to the situation? Just upgrading
   * What exactly did you do (or not do) that was effective (or
 ineffective)? Just Reporting
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

Kernel: Linux 5.1.0-rc3 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

firmware-amd-graphics depends on no packages.

firmware-amd-graphics recommends no packages.

Versions of packages firmware-amd-graphics suggests:
ii  initramfs-tools  0.133

-- no debconf information

Bug#914034: Bug#911938: libhttp-daemon-ssl-perl FTBFS: tests fail: Connection refused

[Dimitri John Ledkov]

Hi,

On Wed, 10 Apr 2019 15:22:09 +0200 Guilhem Moulin  wrote:
>
> Not setting the SSL_MODE_AUTO_RETRY flag back after removing O_NONBLOCK
> (ie commenting out `Net::SSLeay::set_mode($ssl, $mode_auto_retry);` in
> the patch) solves the problem with blocking I/O and select/poll, but
> breaks programs expecting SSL_read() to block until application data
> comes in.  (That is, programs not conforming to SSL_read()'s documented
> behavior — hence which would break on renegotiation with TLS <1.3; or
> programs relying on SSL_MODE_AUTO_RETRY being set, as in OpenSSL ≥1.1.1's
> default context flags.)
>

This issue concerns me a lot at the moment. I am currently trying to
upgrade OpenSSL from 1.1.0 to 1.1.1 in Ubuntu 18.04 LTS (bionic). And
as far as I understand all the comment on this debian bug report,
current application are potentially broken and brokeness happens more
often with TLSv1.3 and the new OpenSSL 1.1.1 defaults
(SSL_MODE_AUTO_RETRY).

As far as I understand we do not have a fixed LWP that works correctly
in blocking, non-blocking, tls 1.2 and tls 1.3. To prevent regressing
existing users further, does it make sense for me to make updates in
bionic that:

1) limit SSL_new and SSL_CTX_new to TLS v1.2 max
and
2) disable SSL_MODE_AUTO_RETRY by default for TLS v1.2 connections?

My goal is to keep existing breakages as is, without introducing new
ones, whilst getting OpenSSL 1.1.1 into bionic. Granted this will not
get TLS v1.3 enabled for perl server/clients without code changes, but
oh well. Those who want it, will be able to force / start using it.

Regards,

Dimitri.

Bug#928597: should support syntax for license exceptions in license short names

[Dominique Dumont]

On Tuesday, 7 May 2019 11:28:31 CEST you wrote:
> Configuration item 'Files:"etc/fonts/*" License short_name' has a wrong
> value: value 'GPL-3+ with Font-exception-2.0' does not match grammar from
> model

On the other hand, this error message is lackluster. I'll try to
improve it.

All the best

Bug#928606: ITP: r-cran-ggthemes -- extra themes, scales and geoms for r-cran-ggplot2

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-ggthemes -- extra themes, scales and geoms for 
r-cran-ggplot2
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-ggthemes
  Version : 4.1.1
  Upstream Author : Jeffrey B. Arnold,
* URL : https://cran.r-project.org/package=ggthemes
* License : GPL-2
  Programming Lang: GNU R
  Description : extra themes, scales and geoms for r-cran-ggplot2
 Some extra themes, geoms, and scales for 'ggplot2'.
 Provides 'ggplot2' themes and scales that replicate the look of plots
 by Edward Tufte, Stephen Few, 'Fivethirtyeight', 'The Economist', 'Stata',
 'Excel', and 'The Wall Street Journal', among others.
 Provides 'geoms' for Tufte's box plot and range frame.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-ggthemes

Bug#927471: curl: Regression that fails to exhaust socket data

[Guillem Jover]

Hi!

On Sat, 2019-05-04 at 13:02:13 +0100, Alessandro Ghedini wrote:
> On Sat, Apr 20, 2019 at 01:39:36PM +0200, Guillem Jover wrote:
> > Source: curl
> > Source-Version: 7.64.0-2
> > Severity: serious
> > Control: affects -1 rtorrent

> > I've started noticing rtorrent busy-looping at some points after
> > finishing a torrent. stracing and gdb'ing the process it was doing
> > that in its main loop, spamming on gettimeofday() and epoll_wait().
> > 
> > Checking the rtorrent dependencies I've not seen much suspicious
> > updated recently, except for curl. I checked then the upstream bug
> > trackers and noticed quite many instances of "100% cpu usage" reports,
> > such as . And that
> > one points to old and new curl issue. The last instance of it appears
> > to have been fixed with 
> > in 7.64.1.
> > 
> > So I think curl should be either upgraded to that release, or the
> > relevant commits cherry-picked.
> 
> I prepared an update for the curl package with the two upstream patches 
> applied
> (38d8e1b and 4015fae), and uploaded the result for amd64 at:
> https://people.debian.org/~ghedo/libcurl4_7.64.0-3_amd64.deb
> 
> Guillem, could you try this version of the package and see if it fixes the
> issue for you? Once that's confirmed I'll upload to sid and ask for unblock.

Thanks! I tried yesterday and today to get a deterministic reproducer
with the version from unstable, but I'm not sure what's the trigger,
perhaps the torrent peers or the chunk arrival order or something. In
any case I was able to get the problem while redownloading some torrents
I had around. Installed the new package, and redownloaded several old
torrents and several new ones, and none have shown the problem since.

But even though I was getting that pretty often before, that does not
mean I might have been lucky until now! So, while it does look like the
issue is gone, I cannot say that with 100% assurance. :)

Will keep checking and report again in a day or two.

Thanks,
Guillem

Bug#928605: do_IRQ: 2.34 No irq handler for vector

[Dmitry Mikhirev]

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

Hello!

After upgrade from stretch to buster, broadcast messages are continously
printed to the console:

do_IRQ: 2.34 No irq handler for vector

In dmesg this message first appears after network initialization:

[   54.659046] r8169 :06:00.0: firmware: direct-loading firmware 
rtl_nic/rtl8168e-2.fw
[   54.659353] RTL8211DN Gigabit Ethernet r8169-600:00: attached PHY driver 
[RTL8211DN Gigabit Ethernet] (mii_bus:phy_addr=r8169-600:00, irq=IGNORE)
[   54.890416] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   54.891124] r8169 :06:00.0 eth0: Link is Down
[   57.257454] r8169 :06:00.0 eth0: Link is Up - 1Gbps/Full - flow 
control rx/tx
[   57.257464] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[   60.12] do_IRQ: 2.34 No irq handler for vector

I'm reporting this bug after reboot to old 4.9 kernel, because
continuous flood makes the console almost unusable, so some information
below can be irrelevant.

I also found the similar bug reported in Fedora: 
https://bugzilla.redhat.com/show_bug.cgi?id=1551605

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

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Chassis Manufacture
chassis_version: Chassis Version
bios_vendor: American Megatrends Inc.
bios_version: 3801
board_vendor: ASUSTeK COMPUTER INC.
board_name: P8H67
board_version: Rev X.0x

** Network interface configuration:

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor 
Family DRAM Controller [8086:0100] (rev 09)
Subsystem: ASUSTeK Computer Inc. P8P67/P8H67 Series Motherboard 
[1043:844d]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snb_uncore

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd Generation Core 
Processor Family PCI Express Root Port [8086:0101] (rev 09) (prog-if 00 [Normal 
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport
Kernel modules: shpchp

00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series 
Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
Subsystem: ASUSTeK Computer Inc. P8 series motherboard [1043:844d]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset 
Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 05) (prog-if 20 [EHCI])
Subsystem: ASUSTeK Computer Inc. P8 series motherboard [1043:844d]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: ehci-pci
Kernel modules: ehci_pci

00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset 
Family High Definition Audio Controller [8086:1c20] (rev 05)
Subsystem: ASUSTeK Computer Inc. 6 Series/C200 Series Chipset Family 
High Definition Audio Controller [1043:8444]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel

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

00:1c.4 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev 
b5) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- 

Bug#928604: ITP: soscleaner -- Python application to clean sensitive and un-wanted data from an existing sosreport

[Eric Desrochers]

Package: wnpp
Severity: wishlist
Owner: Eric Desrochers 

* Package name: soscleaner
  Version : v0.4.3
  Upstream Author : jduncan 
* URL : https://github.com/jduncan-rva/soscleaner
* License : GPL-2+
  Programming Lang: Python
  Description : Python application to clean sensitive and un-wanted data 
from an existing sosreport

Soscleaner is an open-source tool to take an sosreport, or any arbitrary 
dataset, and sanely obfuscate
potentially sensitive information so it can be shared with outside parties for 
support. An unaltered
copy of the data is maintained by the user so data can be mapped and 
suggestions supplied by a support
team can still be actionable, even without the sensitive information.

https://soscleaner.readthedocs.io/


* Why is this pacakge useful/relevant ?
This tool allow users to sanitise a sosreport before sharing it with  outside 
parties for support by
obfuscating every occurences of a hostname, ip, mac address and user. This is 
relevant for users who
doesn't want to share such sensible information and are concern about 
confidentiality.

* Is it a dependency for another package ?
The goal is to have soscleaner sanitizing existing sosreport collection, so 
soscleaner will depend on
sosreport which is already found in the archive.

* Do you use it ?
Yes, I've been testing it and used it, and I know that others will be 
interested to use it also.

* If there are other packages providing similar function
No, this package is very specific to sosreport, maybe other tool can do 
something similar but most
likely not as good as soscleaner does. Its main focus is sanitizing sosreport. 
It's also made by the same
upstream group.

* How do you plan to maintain it ?
I'm planning to maintain and/or co-maintain it. I'm already an uploader for 
sosreport, and planning to
maintain sosreport as well to make the release of both package smooth.

* Do you need a sponsor ?
Yes, until I get my DM permissions.

Bug#928597: should support syntax for license exceptions in license short names

[Dominique Dumont]

On Tuesday, 7 May 2019 11:28:31 CEST you wrote:
> If I use "GPL-3+ with Font-exception-2.0" as a license short name in my
> debian/copyright file, I get:
> 
> $ cme update dpkg-copyright
> Updating data...
> Configuration item 'Files:"etc/fonts/*" License short_name' has a wrong
> value: value 'GPL-3+ with Font-exception-2.0' does not match grammar from
> model
> 
> But this is a perfectly valid syntax for a license short name, see:
>  https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-> 
> short-name

If I interpret correctly the spec, the exception should be in the form
"with keywords exception", where keywords can be "Font" and "OpenSSL"
or any other keyword if new permissions are granted.

cme will allow any keyword to be used, but requires the "exception"
word at the end of the sentence.

In your case, you can try 'GPL-3+ with Font-exception-2.0 exception'.

All the best

Dod

Bug#928603: libdebian-installer - parser_rfc822: remove limitation on line length

[Asbjørn Sloth Tønnesen]

Package: libdebian-installer
Severity: wishlist

As debated in #55 and #904699, the READSIZE limit is arbitrary,
parser_rfc822 should be rewritten to remove READSIZE, so that it
does't have to be increased again.

--
Best regards
Asbjørn Sloth Tønnesen

Bug#928602: unblock: golang-gopkg-sourcemap.v1/1.0.5-2

[Jongmin Kim]

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

Please unblock package golang-gopkg-sourcemap.v1

Fixes accessing the Internet during testing, with a patch does:
  * disables the jQuery downloading (Internet access).
  * use Debian package jQuery (libjs-jquery).
  * disable jQuery version-specific integrity tests.

More info in RC bug: #927227

unblock golang-gopkg-sourcemap.v1/1.0.5-2

Thanks!

--
Jongmin Kim

OpenPGP key located at https://jongmin.dev/pgp
OpenPGP fingerprint: 012E 4A06 79E1 4EFC DAAE  9472 D39D 8D29 BAF3 6DF8


diff -Nru golang-gopkg-sourcemap.v1-1.0.5/debian/changelog 
golang-gopkg-sourcemap.v1-1.0.5/debian/changelog
--- golang-gopkg-sourcemap.v1-1.0.5/debian/changelog2019-01-25 
20:17:13.0 +0900
+++ golang-gopkg-sourcemap.v1-1.0.5/debian/changelog2019-05-06 
17:16:33.0 +0900
@@ -1,3 +1,16 @@
+golang-gopkg-sourcemap.v1 (1.0.5-2) unstable; urgency=medium
+
+  * Team upload
+  * d/gbp.conf:
+- Set pristine-tar = False to override any global configs
+- Set debian/sid as a debian branch
+- Set upstream as an upstream branch
+  * d/patches:
+- Use local jQuery artifacts (Closes: #927227)
+- Disable jQuery version-specific integrity tests
+
+ -- Jongmin Kim   Mon, 06 May 2019 17:16:33 +0900
+
 golang-gopkg-sourcemap.v1 (1.0.5-1) unstable; urgency=medium

   * Initial release (Closes: #895216)
diff -Nru golang-gopkg-sourcemap.v1-1.0.5/debian/control 
golang-gopkg-sourcemap.v1-1.0.5/debian/control
--- golang-gopkg-sourcemap.v1-1.0.5/debian/control  2019-01-25 
20:17:13.0 +0900
+++ golang-gopkg-sourcemap.v1-1.0.5/debian/control  2019-05-06 
17:16:33.0 +0900
@@ -5,7 +5,8 @@
 Uploaders: Raju Devidas ,
 Build-Depends: debhelper (>= 11),
dh-golang,
-   golang-any
+   golang-any,
+   libjs-jquery
 Standards-Version: 4.3.0
 Homepage: https://github.com/go-sourcemap/sourcemap
 Vcs-Browser: 
https://salsa.debian.org/go-team/packages/golang-gopkg-sourcemap.v1.git
@@ -15,7 +16,8 @@

 Package: golang-gopkg-sourcemap.v1-dev
 Architecture: all
-Depends: ${misc:Depends}
+Depends: ${misc:Depends},
+ libjs-jquery
 Description: Source Maps consumer for Golang
  This package provides the source map consumer functions for Golang.
  You need to provide the sourcemapURL in your program, and afterwards you
diff -Nru golang-gopkg-sourcemap.v1-1.0.5/debian/gbp.conf 
golang-gopkg-sourcemap.v1-1.0.5/debian/gbp.conf
--- golang-gopkg-sourcemap.v1-1.0.5/debian/gbp.conf 2019-01-25 
20:17:13.0 +0900
+++ golang-gopkg-sourcemap.v1-1.0.5/debian/gbp.conf 2019-05-06 
17:16:33.0 +0900
@@ -1,2 +1,7 @@
+[DEFAULT]
+pristine-tar = False
+debian-branch = debian/sid
+upstream-branch = upstream
+
 [clone]
 postclone=origtargz
diff -Nru golang-gopkg-sourcemap.v1-1.0.5/debian/patches/series 
golang-gopkg-sourcemap.v1-1.0.5/debian/patches/series
--- golang-gopkg-sourcemap.v1-1.0.5/debian/patches/series   1970-01-01 
09:00:00.0 +0900
+++ golang-gopkg-sourcemap.v1-1.0.5/debian/patches/series   2019-05-06 
17:16:33.0 +0900
@@ -0,0 +1 @@
+use-local-jquery.patch
diff -Nru golang-gopkg-sourcemap.v1-1.0.5/debian/patches/use-local-jquery.patch 
golang-gopkg-sourcemap.v1-1.0.5/debian/patches/use-local-jquery.patch
--- golang-gopkg-sourcemap.v1-1.0.5/debian/patches/use-local-jquery.patch   
1970-01-01 09:00:00.0 +0900
+++ golang-gopkg-sourcemap.v1-1.0.5/debian/patches/use-local-jquery.patch   
2019-05-06 17:16:33.0 +0900
@@ -0,0 +1,80 @@
+Description: Use local jQuery artifacts
+ The upstream source downloads jQuery 2.0.3 during testing.
+ .
+ The Debian package should never assume that Internet access is available
+ during building. Also, the Debian policy does not allow the embedded
+ code copies.
+ .
+ This patch does:
+  * disables the jQuery downloading (Internet access).
+  * use Debian package jQuery (libjs-jquery).
+  * disable jQuery version-specific integrity tests.
+Bug-Debian: https://bugs.debian.org/927227
+Author: Jongmin Kim 
+---
+ consumer_test.go |   10 --
+ example_test.go  |   10 +++---
+ 2 files changed, 15 insertions(+), 5 deletions(-)
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/consumer_test.go
 b/consumer_test.go
+@@ -10,12 +10,16 @@
+   "gopkg.in/sourcemap.v1"
+ )
+
+-const jqSourceMapURL = "http://code.jquery.com/jquery-2.0.3.min.map;
++const jqSourceMapURL = "file:///usr/share/javascript/jquery/jquery.min.map"
+
+ var jqSourceMapBytes []byte
+
+ func init() {
+-  resp, err := http.Get(jqSourceMapURL)
++  trans := {}
++  trans.RegisterProtocol("file", http.NewFileTransport(http.Dir("/")))
++
++  cli := {Transport: trans}
++  resp, err := cli.Get(jqSourceMapURL)
+   if err != nil {
+   panic(err)
+   }
+@@ -165,6 +169,7 @@
+   }
+ }
+
++/*
+ func TestJQuerySourceMap(t 

Bug#919632: closed by Ben Hutchings (Bug#919632: fixed in firmware-nonfree 20190502-1)

[Kevin Price]

Dear maintainer,

This didn't fix this bug.

Am 06.05.19 um 23:36 schrieb Debian Bug Tracking System:
> #919632: "New" firmware instantly crashes on QCA9377
> 
> If this explanation is unsatisfactory and you have not received a
> better one in a separate message then please contact Ben Hutchings 
>  by
> replying to this email.
>
> If you
> have further comments please address them to 919...@bugs.debian.org,
> and the maintainer will reopen the bug report if appropriate.
>
> Changes:
>  firmware-nonfree (20190502-1) unstable; urgency=medium
>[ Ben Hutchings ]
>* atheros: Add Qualcomm Atheros QCA9377 rev 1.0 firmware version
>  WLAN.TF.2.1-00021-QCARMSWP-1 (Closes: #903437, #919632, #927917)

I'm not affected by the only change in

  /lib/firmware/updates/ath10k/QCA9377/hw1.0 ,

which is the addition of

  firmware-6.bin . My QCA9377 loads firmware-5.bin, which has not been
changed since 2018-02-15 (upstream), so it still instantly crashes.
dmesg attached.

best
Kevin
ath10k_pci :05:00.0: pci irq msi oper_irq_mode 2 irq_mode 0 reset_mode 0
ath10k_pci :05:00.0: firmware: failed to load 
ath10k/pre-cal-pci-:05:00.0.bin (-2)
ath10k_pci :05:00.0: Direct firmware load for 
ath10k/pre-cal-pci-:05:00.0.bin failed with error -2
ath10k_pci :05:00.0: firmware: failed to load 
ath10k/cal-pci-:05:00.0.bin (-2)
ath10k_pci :05:00.0: Direct firmware load for 
ath10k/cal-pci-:05:00.0.bin failed with error -2
ath10k_pci :05:00.0: firmware: direct-loading firmware 
ath10k/QCA9377/hw1.0/firmware-5.bin
ath10k_pci :05:00.0: qca9377 hw1.1 target 0x05020001 chip_id 0x003821ff sub 
17aa:0901
ath10k_pci :05:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
ath10k_pci :05:00.0: firmware ver WLAN.TF.1.0-2-QCATFSWPZ-5 api 5 
features ignore-otp crc32 c3e0d04f
ath10k_pci :05:00.0: board_file api 2 bmi_id N/A crc32 8aedfa4a
ath10k_pci :05:00.0: firmware crashed! (uuid n/a)
ath10k_pci :05:00.0: qca9377 hw1.1 target 0x05020001 chip_id 0x003821ff sub 
17aa:0901
ath10k_pci :05:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0 testmode 0
ath10k_pci :05:00.0: firmware ver WLAN.TF.1.0-2-QCATFSWPZ-5 api 5 
features ignore-otp crc32 c3e0d04f
ath10k_pci :05:00.0: board_file api 2 bmi_id N/A crc32 8aedfa4a
ath10k_pci :05:00.0: htt-ver 0.0 wmi-op 4 htt-op 3 cal otp max-sta 32 raw 0 
hwcrypto 1
ath10k_pci :05:00.0: firmware register dump:
ath10k_pci :05:00.0: [00]: 0x05020001 0x 0x00A0F774 0x
ath10k_pci :05:00.0: [04]: 0x00A0F774 0x00060130 0x0010 0xE000
ath10k_pci :05:00.0: [08]: 0x0042136C 0x00420660 0x0040 0x0040
ath10k_pci :05:00.0: [12]: 0x 0x 0x00952CD0 0x00952CE6
ath10k_pci :05:00.0: [16]: 0x0002 0x01010101 0x0003 0x000A
ath10k_pci :05:00.0: [20]: 0x0328 0x00429880 0x009A37AC 0x0032
ath10k_pci :05:00.0: [24]: 0x800A0D0A 0x0040EA88 0x00420170 0x004173B0
ath10k_pci :05:00.0: [28]: 0x00401F64 0x00401F68 0x 0x00417550
ath10k_pci :05:00.0: [32]: 0x00401FC0 0xC4E30058 0x00406B1D 0x0003
ath10k_pci :05:00.0: [36]: 0x800A0907 0x0001 0x085B 0x339011B2
ath10k_pci :05:00.0: [40]: 0xFFFE 0x000A 0x009BFE28 0x009BE0DC
ath10k_pci :05:00.0: [44]: 0x800A0D0A 0x0040EA88 0x00420170 0x004173B0
ath10k_pci :05:00.0: [48]: 0x0040 0x0040 0x0001 0x
ath10k_pci :05:00.0: [52]: 0x800A0614 0x0040EAA8 0x0041FA10 0x00420170
ath10k_pci :05:00.0: [56]: 0x0040 0x00421370 0x00419980 0x004212E8
ath10k_pci :05:00.0: failed to receive control response completion, 
polling..
ath10k_pci :05:00.0: ctl_resp never came in (-110)
ath10k_pci :05:00.0: failed to connect to HTC: -110
ath10k_pci :05:00.0: could not init core (-110)
ath10k_pci :05:00.0: could not probe fw (-110)
ath10k_pci :05:00.0: cannot restart a device that hasn't been started

Bug#928601: unattended-upgrades: manpage refers to wrong logfile location

[Martin Schwarz]

Package: unattended-upgrades
Version: 1.11
Severity: minor

Dear Maintainer,

the information for the "-d" or "--debug" option in the
unattended-upgrade(8) manpage refers to a non-existent logfile:

Instead of "/var/log/unattended-upgrades.log" this should probably read
"/var/log/unattended-upgrades/unattended-upgrades.log".

Another wrong logfile in the manpage has already been fixed in #817974
but this one seems to have slipped through or perhaps has been
introduced later.

Not critical, but should be fixed anyway ... thanks!

Martin

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/1 CPU core)
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 unattended-upgrades depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  lsb-base   10.2019031300
ii  lsb-release10.2019031300
ii  python33.7.2-1
ii  python3-apt1.8.4
ii  python3-dbus   1.2.8-3
ii  python3-distro-info0.21
ii  ucf3.0038+nmu1
ii  xz-utils   5.2.4-1

Versions of packages unattended-upgrades recommends:
ii  cron [cron-daemon]  3.0pl1-133
ii  systemd-sysv241-3

Versions of packages unattended-upgrades suggests:
ii  bsd-mailx  8.1.2-0.20180807cvs-1
ii  needrestart3.4-3
ii  nullmailer [mail-transport-agent]  1:2.2-3
ii  powermgmt-base 1.34
ii  python3-gi 3.30.4-1

-- debconf information excluded

Bug#928554: dgit-nmu-simple should give an example of generating a patches-unapplied nmudiff

[Sam Hartman]

I agree that only diffing the debian directory should work for quilt
packages without a new upstream to give a patches unapplied nmudiff as
new debian/patches.

Bug#928546: [feature request] /etc/fstab.d

[Patrick Schleizer]

Asked upstream about it.

[feature request] /etc/fstab.d

https://github.com/karelzak/util-linux/issues/790

Bug#928554: dgit-nmu-simple should give an example of generating a patches-unapplied nmudiff

[Ian Jackson]

Sam Hartman writes ("Bug#928554: dgit-nmu-simple should give an example of 
generating a patches-unapplied nmudiff"):
> The dgit-nmu-simple man page doesn't give any explicit examples of
> generating an nmudiff.

Thanks for bringing this up.  See also #850560 "Want `dgit nmudiff`".

> It's unclear that we actually have a standard on whether an nmudiff
> should be patches-applied or patches-unapplied.
> I find that I typically get patches-unapplied nmudiffs, that if you use
> a standard dpkg workflow without dgit they are easier, and having the
> patch duplicated is harder to review.

There are at least *three* possible formats:

 * git diff dgit/dgit/sid..dgit/sid  # after quilt fixup
 diff of whole package, patches applied
 upstream changes present as diff and as interdiff in debian/patches
 rune will work fine on non-quilt package

 * git-format-patch dgit/dgit/sid   # before quilt fixup [1]
   (or git diff dgit/dgit/sid..dgit/sid # before quilt fixup [1])
 diff of whole package, no patches generated
 upstream changes present as diff to upstream files, only
 diff contains no changes to debian/patches
 rune will work fine on non-quilt package
 if git-format-patch is used, maintainer can git-am in their
 gbp pq patch queue branch or equivalent.

 * git diff dgit/dgit/sid..dgit/sid :!/ :/debian # after quilt fixup
 diff of only packaging including any patches
 upstream changes present as interdiff in debian/patches, only
 rune will NOT work on non-quilt package
 rune will NOT work for new upstream version

[1] Or with appropriate restrictions to show only "real" changes.

Maybe we should do whatever debdiff does.

> I find it's unintuitive how exactly you generate a good
> patches-unapplied nmudiff, so I looked for guidance in the man page and
> didn't find any.

Mmm.  My 3rd rune above will do this, I think.  (Untested.)

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#850560: Want `dgit nmudiff`

[Ian Jackson]

See also #928554, "dgit-nmu-simple should give an example of
generating a patches-unapplied nmudiff"

-- 
Ian JacksonThese opinions are my own.

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

Bug#928600: byobu: Please suggests fonts-ubuntu

[Hideki Yamane]

package: byobu
severity: minor
tags: patch

Hi,

 byobu package suggests ttf-ubuntu-font-family but it's transitional
 one. Please update its dependency as below.


diff -Nru byobu-5.127/debian/control byobu-5.127/debian/control
--- byobu-5.127/debian/control  2019-04-11 11:07:52.0 +0900
+++ byobu-5.127/debian/control  2019-05-07 19:12:34.0 +0900
@@ -33,7 +33,7 @@
  po-debconf,
  screen,
  speedometer,
- ttf-ubuntu-font-family (>= 0.80-0ubuntu1~medium),
+ fonts-ubuntu,
  update-notifier-common,
  vim,
  wireless-tools

Bug#928509: Firefox extensions can be used again

[Sylvain Beucler]

Hi,

On 07/05/2019 11:25, Karsten wrote:
> I upgraded the Firefox packages for Debian 8 (Jessie) and Debian 9 (Stretch) 
> now
> and in both Releases Firefox can use the extensions again.
>
> Thanks for your great work!
>
> Besides - Debian 8 is used for desktop use, because it is running with less 
> problems.
> Like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926066
> or https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910494

Thanks for the report!

- Sylvain

Bug#837093: edk2: Please build an EFI shell package

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, 8 Sep 2016 20:28:36 +0200 Julian Andres Klode  wrote:
> Source: edk2
> Severity: wishlist
> 
> Having an EFI shell on a real host is quite useful, it would be nice 
> to have one packaged so bootloader(s/configuration tools) can install
> them to the ESP(s).

Hi,

is there any news on this? I'd be interested as well (in my case because I'm
setting up a repository with scripts to build a bootable EFI key and would
rather add build-dependencies rather than shipping the efi shell binary
inside).

Regards,
- -- 
Yves-Alexis
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlzRVvMACgkQ3rYcyPpX
RFvCtgf/VCT89fDzf17HRkZmcYQe62ix5PAPHnTMyKDSl2ebv5wb7dovAoSHzjx+
EVdQ3/6xG2hhdHosaTLcBILEyFNQbfj4R0xsAe5zbM33qNHAiIjNUkfp55k+fGNY
Y1f1i1Js9IwhpPH9fMOG5r7sN3GJ/q8GdTlOUznJIU8UKcgUh8/iOCuE6jI/FT5F
bpd5JFwdVcNBUKET4EdUWqj6rLr/GnnNmjKwiInYjizkb0thUCwh2yrYeodvkiEO
UW0U6hZ+iz1nVmBxpF98xIfFGoNyXORiAM2jV8Aq6CBEgcrSQs76NsNSPXfgDwNq
vKYOG7ludoeeexw0wmPbnekbWgD6sA==
=Vznl
-END PGP SIGNATURE-

Bug#865879: calibre: Bug still present in buster (3.39.1+dfsg-2)

[Marco Maisenhelder]

Hi Norbert!

On 05/05/2019 15.47, Norbert Preining wrote:
> Hi
> 
>> The bug is sadly still present in Buster:
> 
> I cannot reproduce this. Can you please provide a way how to reproduce
> this!

Sorry, the bug appeared after an upgrade from Stretch to Buster. It would be 
kind of difficult to reproduce the environment I started from ;)

I did do more tests though:

I removed the /usr/lib/calibre/regex/ dir since it seemed odd to me to have the 
debian pkg installed for that and have a local version in calibre that seemed 
kind of incomplete. And voila: it worked. Looking into the calibre .deb this 
seems to me to be a left-over from a previous version.

Marco

Bug#928599: linux-image-4.19.0-5-amd64-unsigned: WARNING... dcn_bw_update_from_pplib+0x171/0x290 [amdgpu] , full call trace in syslog, system still usable

[Jarek Slosarczyk]

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

Dear Maintainer,

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

this happens on every boot.
full call trace in kernel log.

i can't abandon the use of amdgpu module as it's required by the raven ridge 
gpu to work.

i have tried to use different linux kernel boot options related to amdgpu and 
amd iommu modules, but this did not have any effect on this issue.

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


-- Package-specific info:
** Version:
Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-1 (2019-05-05)

** Command line:
BOOT_IMAGE=/root/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=5a5510bf-4225-4c1f-96b8-5ea9b7f93f34 ro rootflags=subvol=root quiet 
iommu=off

** Tainted: WE (8704)
 * Taint on warning.
 * Unsigned module has been loaded.

** Kernel log:
-- Logs begin at Wed 2019-05-01 10:56:11 CEST, end at Tue 2019-05-07 11:35:01 
CEST. --
Mai 07 10:43:38 xtra kernel: Linux version 4.19.0-5-amd64 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP 
Debian 4.19.37-1 (2019-05-05)
Mai 07 10:43:38 xtra kernel: Command line: 
BOOT_IMAGE=/root/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=5a5510bf-4225-4c1f-96b8-5ea9b7f93f34 ro rootflags=subvol=root quiet 
iommu=off
Mai 07 10:43:38 xtra kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 
floating point registers'
Mai 07 10:43:38 xtra kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE 
registers'
Mai 07 10:43:38 xtra kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX 
registers'
Mai 07 10:43:38 xtra kernel: x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  
256
Mai 07 10:43:38 xtra kernel: x86/fpu: Enabled xstate features 0x7, context size 
is 832 bytes, using 'compacted' format.
Mai 07 10:43:38 xtra kernel: BIOS-provided physical RAM map:
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x-0x0fff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x1000-0x0008] usable
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x0009-0x00090fff] type 20
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x00091000-0x0009] usable
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x000a-0x000f] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x0010-0x09e0] usable
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x09e1-0x09ff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x0a00-0x0a1f] usable
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x0a20-0x0a20afff] ACPI NVS
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x0a20b000-0x0aff] usable
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x0b00-0x0b01] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0x0b02-0xd1923fff] usable
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xd1924000-0xd194bfff] ACPI data
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xd194c000-0xda798fff] usable
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xda799000-0xda8aefff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xda8af000-0xda8cdfff] ACPI data
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xda8ce000-0xdacd0fff] usable
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xdacd1000-0xdad8cfff] ACPI NVS
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xdad8d000-0xdbaa] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xdbab-0xdbb50fff] type 20
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xdbb51000-0xddff] usable
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xde00-0xdfff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xf800-0xfbff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfd10-0xfd1f] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfea0-0xfea0] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfeb8-0xfec01fff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfec1-0xfec10fff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfec3-0xfec30fff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfed0-0xfed00fff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfed4-0xfed44fff] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfed8-0xfed8] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfedc2000-0xfedc] reserved
Mai 07 10:43:38 xtra kernel: BIOS-e820: [mem 
0xfedd4000-0xfedd5fff] reserved

Bug#928509: Firefox extensions can be used again

[Karsten Malcher]

I upgraded the Firefox packages for Debian 8 (Jessie) and Debian 9 (Stretch) now
and in both Releases Firefox can use the extensions again.

Thanks for your great work!

Besides - Debian 8 is used for desktop use, because it is running with less 
problems.
Like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926066
or https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910494

Bug#928598: browserpass: FTBFS (cannot find package "github.com/sirupsen/logrus/hooks/syslog")

[Santiago Vila]

Package: src:browserpass
Version: 3.1.1-1
Severity: serious
Tags: ftbfs

Dear maintainer:

I tried to build this package in sid but it failed:


[...]
 debian/rules build-arch
dh build-arch --buildsystem=golang --with=golang
   dh_update_autotools_config -a -O--buildsystem=golang
   dh_autoreconf -a -O--buildsystem=golang
   dh_auto_configure -a -O--buildsystem=golang
   debian/rules override_dh_auto_build
make[1]: Entering directory '/<>'
dh_auto_build -O--buildsystem=golang -- -buildmode=pie -ldflags 
"-extldflags=-Wl,-z,now,-z,relro"
cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\" 
-asmflags=all=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\" -v -p 1 
-buildmode=pie -ldflags -extldflags=-Wl,-z,now,-z,relro 
github.com/browserpass/browserpass-native 
github.com/browserpass/browserpass-native/errors 
github.com/browserpass/browserpass-native/openbsd 
github.com/browserpass/browserpass-native/persistentlog 
github.com/browserpass/browserpass-native/request 
github.com/browserpass/browserpass-native/response 
github.com/browserpass/browserpass-native/version
src/github.com/browserpass/browserpass-native/persistentlog/syslog.go:8:2: 
cannot find package "github.com/sirupsen/logrus" in any of:
/usr/lib/go-1.11/src/github.com/sirupsen/logrus (from $GOROOT)
/<>/obj-x86_64-linux-gnu/src/github.com/sirupsen/logrus 
(from $GOPATH)
src/github.com/browserpass/browserpass-native/persistentlog/syslog.go:9:2: 
cannot find package "github.com/sirupsen/logrus/hooks/syslog" in any of:
/usr/lib/go-1.11/src/github.com/sirupsen/logrus/hooks/syslog (from 
$GOROOT)

/<>/obj-x86_64-linux-gnu/src/github.com/sirupsen/logrus/hooks/syslog
 (from $GOPATH)
dh_auto_build: cd obj-x86_64-linux-gnu && go install 
-gcflags=all=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\" 
-asmflags=all=\"-trimpath=/<>/obj-x86_64-linux-gnu/src\" -v -p 1 
-buildmode=pie -ldflags -extldflags=-Wl,-z,now,-z,relro 
github.com/browserpass/browserpass-native 
github.com/browserpass/browserpass-native/errors 
github.com/browserpass/browserpass-native/openbsd 
github.com/browserpass/browserpass-native/persistentlog 
github.com/browserpass/browserpass-native/request 
github.com/browserpass/browserpass-native/response 
github.com/browserpass/browserpass-native/version returned exit code 1
make[1]: *** [debian/rules:11: override_dh_auto_build] Error 1
make[1]: Leaving directory '/<>'
make: *** [debian/rules:8: build-arch] Error 2
dpkg-buildpackage: error: debian/rules build-arch subprocess returned exit 
status 2


See also:

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

Seems like a missing build-dependency.

Thanks.

Bug#928597: should support syntax for license exceptions in license short names

[Sébastien Villemot]

Package: libconfig-model-dpkg-perl
Version: 2.122
Severity: normal

Dear Mantainer,

If I use "GPL-3+ with Font-exception-2.0" as a license short name in my
debian/copyright file, I get:

$ cme update dpkg-copyright 

  
Updating data...
Configuration item 'Files:"etc/fonts/*" License short_name' has a wrong value:
value 'GPL-3+ with Font-exception-2.0' does not match grammar from model

But this is a perfectly valid syntax for a license short name, see:
 
https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#license-short-name

Cheers,

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

Bug#928509: Firefox extensions can be used again

[Karsten]

I upgraded the Firefox packages for Debian 8 (Jessie) and Debian 9 (Stretch) now
and in both Releases Firefox can use the extensions again.

Thanks for your great work!

Besides - Debian 8 is used for desktop use, because it is running with less 
problems.
Like https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926066
or https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=910494

Bug#927781: linux-image-3.16.0-8-amd64: Kernel Oops - unable to handle kernel paging request

[Salvatore Bonaccorso]

Hi Nik,

On Tue, May 07, 2019 at 10:45:33AM +0200, Nik Wrt wrote:
> I am experiencing the same identical problem. Running debian jessie on a Dell 
> D430. I can reproducibly trigger this by doing
> 
> python -c "import numpy"
> 
> It does not happen if I roll back to linux-image-3.16.0-7-amd64
> 
> [ 1043.203200] BUG: unable to handle kernel paging request at 8820426d6138
> [ 1043.203306] IP: [] put_pid+0x12/0x50
> [ 1043.203376] PGD 1b11067 PUD 0
> [ 1043.203428] Oops:  [#1] SMP
> [ 1043.203484] Modules linked in: btrfs xor raid6_pq ufs qnx4 hfsplus hfs 
> minix ntfs vfat msdos fat jfs xfs libcrc32c crc32c_generic cpuid rfcomm ctr 
> ccm pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep 
> cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_conservative 
> binfmt_misc uinput i8k fuse lp iTCO_wdt iTCO_vendor_support dell_wmi 
> sparse_keymap ppdev dell_laptop dcdbas ecb arc4 coretemp iwl4965 kvm_intel 
> kvm iwl3945 iwlegacy btusb mac80211 bluetooth pcmcia 6lowpan_iphc cfg80211 
> evdev joydev serio_raw rfkill yenta_socket lpc_ich pcmcia_rsrc mfd_core 
> pcmcia_core i915 snd_hda_codec_idt snd_hda_codec_generic rng_core 
> snd_hda_intel snd_hda_controller wmi snd_hda_codec snd_hwdep button battery 
> parport_pc drm_kms_helper snd_pcm parport tpm_tis drm snd_timer tpm 
> i2c_algo_bit acpi_cpufreq
> [ 1043.204628]  snd soundcore ac video processor shpchp ext4 crc16 mbcache 
> jbd2 xts gf128mul algif_skcipher af_alg dm_crypt dm_mod sg sd_mod crc_t10dif 
> crct10dif_generic crct10dif_common ata_generic mmc_block ata_piix 
> firewire_ohci libata psmouse sdhci_pci sdhci mmc_core firewire_core crc_itu_t 
> i2c_i801 scsi_mod i2c_core tg3 ptp pps_core libphy ehci_pci uhci_hcd ehci_hcd 
> thermal thermal_sys usbcore usb_common
> [ 1043.205206] CPU: 0 PID: 12771 Comm: python Tainted: G   O  
> 3.16.0-8-amd64 #1 Debian 3.16.64-2
> [ 1043.205281] Hardware name: Dell Inc. Latitude D430   
> /0XW631, BIOS A09 01/04/2010
> [ 1043.205352] task: 88007840a970 ti: 88003620c000 task.ti: 
> 88003620c000
> [ 1043.205414] RIP: 0010:[]  [] 
> put_pid+0x12/0x50
> [ 1043.205485] RSP: 0018:88003620fea8  EFLAGS: 00010206
> [ 1043.205532] RAX: 0011 RBX: 880078f4dd40 RCX: 
> 000e
> [ 1043.205591] RDX:  RSI: 81848780 RDI: 
> 8800427c6100
> [ 1043.205649] RBP: 2000 R08: 81848780 R09: 
> 
> [ 1043.205707] R10:  R11: 0206 R12: 
> 81889a40
> [ 1043.205766] R13: 0200 R14:  R15: 
> 
> [ 1043.205827] FS:  7f1e69ef3700() GS:88007f40() 
> knlGS:
> [ 1043.205894] CS:  0010 DS:  ES:  CR0: 80050033
> [ 1043.205943] CR2: 8820426d6138 CR3: 426e CR4: 
> 0770
> [ 1043.206001] Stack:
> [ 1043.206023]  880078f4dd40 8123cfb2 7f1e6d7deec0 
> 3056535953ef2d20
> [ 1043.207072]  0030303030303030 a5aa303d  
> 81889b10
> [ 1043.207072]  88003620ff70 7f1e6a1ef7c0  
> 7f1e6bd8f680
> [ 1043.207072] Call Trace:
> [ 1043.207072]  [] ? newseg+0x2b2/0x370
> [ 1043.207072]  [] ? ipcget+0xd9/0x1d0
> [ 1043.207072]  [] ? SyS_shmget+0x42/0x50
> [ 1043.207072]  [] ? system_call_fast_compare_end+0x1c/0x21
> [ 1043.207072] Code: 48 c1 e2 05 48 85 c9 48 8b 54 10 38 75 85 0f 1f 00 31 c0 
> c3 0f 1f 44 00 00 66 66 66 66 90 48 85 ff 74 1a 53 8b 47 04 48 c1 e0 05 <48> 
> 8b 5c 07 38 8b 07 83 f8 01 74 12 f0 ff 0f 74 0d 5b f3 c3 66
> [ 1043.207072] RIP  [] put_pid+0x12/0x50
> [ 1043.207072]  RSP 
> [ 1043.207072] CR2: 8820426d6138
> [ 1043.207072] ---[ end trace 1ddd197bcce6a7ce ]---

The pending update to 3.16.66 should fix this issue. If you can/want
to pretest the packages for checking for further regression, see
https://lists.debian.org/debian-lts/2019/05/msg00014.html .

Hope this helps!

Regards,
Salvatore

Bug#927781: linux-image-3.16.0-8-amd64: Kernel Oops - unable to handle kernel paging request

[Nik Wrt]

I am experiencing the same identical problem. Running debian jessie on a Dell 
D430. I can reproducibly trigger this by doing

python -c "import numpy"

It does not happen if I roll back to linux-image-3.16.0-7-amd64

[ 1043.203200] BUG: unable to handle kernel paging request at 8820426d6138
[ 1043.203306] IP: [] put_pid+0x12/0x50
[ 1043.203376] PGD 1b11067 PUD 0
[ 1043.203428] Oops:  [#1] SMP
[ 1043.203484] Modules linked in: btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix 
ntfs vfat msdos fat jfs xfs libcrc32c crc32c_generic cpuid rfcomm ctr ccm 
pci_stub vboxpci(O) vboxnetadp(O) vboxnetflt(O) vboxdrv(O) bnep 
cpufreq_userspace cpufreq_stats cpufreq_powersave cpufreq_conservative 
binfmt_misc uinput i8k fuse lp iTCO_wdt iTCO_vendor_support dell_wmi 
sparse_keymap ppdev dell_laptop dcdbas ecb arc4 coretemp iwl4965 kvm_intel kvm 
iwl3945 iwlegacy btusb mac80211 bluetooth pcmcia 6lowpan_iphc cfg80211 evdev 
joydev serio_raw rfkill yenta_socket lpc_ich pcmcia_rsrc mfd_core pcmcia_core 
i915 snd_hda_codec_idt snd_hda_codec_generic rng_core snd_hda_intel 
snd_hda_controller wmi snd_hda_codec snd_hwdep button battery parport_pc 
drm_kms_helper snd_pcm parport tpm_tis drm snd_timer tpm i2c_algo_bit 
acpi_cpufreq
[ 1043.204628]  snd soundcore ac video processor shpchp ext4 crc16 mbcache jbd2 
xts gf128mul algif_skcipher af_alg dm_crypt dm_mod sg sd_mod crc_t10dif 
crct10dif_generic crct10dif_common ata_generic mmc_block ata_piix firewire_ohci 
libata psmouse sdhci_pci sdhci mmc_core firewire_core crc_itu_t i2c_i801 
scsi_mod i2c_core tg3 ptp pps_core libphy ehci_pci uhci_hcd ehci_hcd thermal 
thermal_sys usbcore usb_common
[ 1043.205206] CPU: 0 PID: 12771 Comm: python Tainted: G   O  
3.16.0-8-amd64 #1 Debian 3.16.64-2
[ 1043.205281] Hardware name: Dell Inc. Latitude D430   
/0XW631, BIOS A09 01/04/2010
[ 1043.205352] task: 88007840a970 ti: 88003620c000 task.ti: 
88003620c000
[ 1043.205414] RIP: 0010:[]  [] 
put_pid+0x12/0x50
[ 1043.205485] RSP: 0018:88003620fea8  EFLAGS: 00010206
[ 1043.205532] RAX: 0011 RBX: 880078f4dd40 RCX: 000e
[ 1043.205591] RDX:  RSI: 81848780 RDI: 8800427c6100
[ 1043.205649] RBP: 2000 R08: 81848780 R09: 
[ 1043.205707] R10:  R11: 0206 R12: 81889a40
[ 1043.205766] R13: 0200 R14:  R15: 
[ 1043.205827] FS:  7f1e69ef3700() GS:88007f40() 
knlGS:
[ 1043.205894] CS:  0010 DS:  ES:  CR0: 80050033
[ 1043.205943] CR2: 8820426d6138 CR3: 426e CR4: 0770
[ 1043.206001] Stack:
[ 1043.206023]  880078f4dd40 8123cfb2 7f1e6d7deec0 
3056535953ef2d20
[ 1043.207072]  0030303030303030 a5aa303d  
81889b10
[ 1043.207072]  88003620ff70 7f1e6a1ef7c0  
7f1e6bd8f680
[ 1043.207072] Call Trace:
[ 1043.207072]  [] ? newseg+0x2b2/0x370
[ 1043.207072]  [] ? ipcget+0xd9/0x1d0
[ 1043.207072]  [] ? SyS_shmget+0x42/0x50
[ 1043.207072]  [] ? system_call_fast_compare_end+0x1c/0x21
[ 1043.207072] Code: 48 c1 e2 05 48 85 c9 48 8b 54 10 38 75 85 0f 1f 00 31 c0 
c3 0f 1f 44 00 00 66 66 66 66 90 48 85 ff 74 1a 53 8b 47 04 48 c1 e0 05 <48> 8b 
5c 07 38 8b 07 83 f8 01 74 12 f0 ff 0f 74 0d 5b f3 c3 66
[ 1043.207072] RIP  [] put_pid+0x12/0x50
[ 1043.207072]  RSP 
[ 1043.207072] CR2: 8820426d6138
[ 1043.207072] ---[ end trace 1ddd197bcce6a7ce ]---