Bug#928418: unblock: preapproval: corekeeper/1.7

[Paul Wise]

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

I would like to fix some issues in corekeeper reported by Jakub Wilk.

unblock corekeeper/1.7

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

diff -Nru corekeeper-1.6/debian/changelog corekeeper-1.7/debian/changelog
--- corekeeper-1.6/debian/changelog	2015-11-12 00:44:29.0 +0800
+++ corekeeper-1.7/debian/changelog	2019-05-04 14:53:44.0 +0800
@@ -1,3 +1,16 @@
+corekeeper (1.7) unstable; urgency=medium
+
+  * Do not use a world-writable /var/crash with the dumper script
+and fix the permissions on upgrade as dpkg doesn't do that.
+(Closes: #924397) (See-also: #515211)
+  * Handle older versions of the Linux kernel in a safer way
+(Closes: #924398)
+  * Harden ownership determination and core file names
+  * Do not truncate core names for executables with spaces
+  * Update VCS URLs from alioth to salsa
+
+ -- Paul Wise   Sat, 04 May 2019 14:53:44 +0800
+
 corekeeper (1.6) unstable; urgency=medium
 
   * Prevent installation with other core dump handlers:
diff -Nru corekeeper-1.6/debian/control corekeeper-1.7/debian/control
--- corekeeper-1.6/debian/control	2015-11-11 22:19:31.0 +0800
+++ corekeeper-1.7/debian/control	2019-05-04 14:53:44.0 +0800
@@ -5,8 +5,8 @@
 Build-Depends:
  debhelper (>= 9)
 Standards-Version: 3.9.6
-Vcs-Git: git://anonscm.debian.org/collab-maint/corekeeper.git
-Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/corekeeper.git
+Vcs-Git: https://salsa.debian.org/debian/corekeeper.git
+Vcs-Browser: https://salsa.debian.org/debian/corekeeper
 
 Package: corekeeper
 Architecture: kfreebsd-any linux-any
diff -Nru corekeeper-1.6/debian/copyright corekeeper-1.7/debian/copyright
--- corekeeper-1.6/debian/copyright	2013-11-22 10:23:37.0 +0800
+++ corekeeper-1.7/debian/copyright	2019-05-04 14:53:44.0 +0800
@@ -1,7 +1,7 @@
 Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Upstream-Name: corekeeper
 Upstream-Contact: Paul Wise 
-Source: git://anonscm.debian.org/collab-maint/corekeeper.git
+Source: https://salsa.debian.org/debian/corekeeper.git
 Comment: original package by Ben Pfaff has been rewritten
 
 Files: *
diff -Nru corekeeper-1.6/debian/corekeeper.lintian-overrides corekeeper-1.7/debian/corekeeper.lintian-overrides
--- corekeeper-1.6/debian/corekeeper.lintian-overrides	2013-11-22 10:23:42.0 +0800
+++ corekeeper-1.7/debian/corekeeper.lintian-overrides	2019-05-04 13:57:59.0 +0800
@@ -1,6 +1,6 @@
 # /var/crash is intentionally world-writable to allow for
 # centralized core dumps.
-non-standard-dir-perm
+[kfreebsd-any]: non-standard-dir-perm
 
 # The postrm script checks if systemd is running before
 # using the systemctl command
diff -Nru corekeeper-1.6/debian/corekeeper.postinst.linux corekeeper-1.7/debian/corekeeper.postinst.linux
--- corekeeper-1.6/debian/corekeeper.postinst.linux	2013-04-25 14:49:30.0 +0800
+++ corekeeper-1.7/debian/corekeeper.postinst.linux	2019-05-04 14:53:44.0 +0800
@@ -4,4 +4,11 @@
 # Activate the sysctl settings
 [ $1 != configure ] || sysctl --quiet --load="/etc/sysctl.d/corekeeper.conf"
 
+# Set /var/crash to not be world writable
+# to prevent crashes being able to write arbitrary files
+[ "$1" = configure ] &&
+dpkg --compare-versions "$2" le-nl 1.6 &&
+! dpkg-statoverride --list /var/crash &&
+chmod 0755 /var/crash
+
 #DEBHELPER#
diff -Nru corekeeper-1.6/debian/dump corekeeper-1.7/debian/dump
--- corekeeper-1.6/debian/dump	2013-04-25 16:01:53.0 +0800
+++ corekeeper-1.7/debian/dump	2019-05-04 14:47:56.0 +0800
@@ -19,7 +19,9 @@
 # because Linux does not create directories when dumping core files
 # and it is apparently painful to do that from within Linux.
 #
-# Thanks for the security audit go to Kees Cook !
+# Thanks for the security audits go to:
+# Jakub Wilk 
+# Kees Cook 
 
 set -e
 
@@ -28,34 +30,77 @@
 	exit 1
 fi
 
-# Check how many arguments the kernel sent us.
-if [ $# -eq 2 ] ; then
-	# Awww, old kernel that does not support %d
-	# Cannot set the core file owner safely, use root
-	# See v3.6-6800-g12a2b4b in linux.git for more info
-	uid="$1"
-	core="$2"
-	owner="0"
-elif [ $# -eq 3 ] ; then
-	# Yay! A kernel that does support %d
-	uid="$2"
-	core="$3"
-	owner="$2"
-	# Set the core file owner safely
-	if [ $1 -eq 2 ] ; then
-		owner="0"
-	fi
-else
-	# Something is majorly broken.
-	echo "This script should be run with three arguments and a core file on stdin" 1>&2
-	exit 1
-fi
+case "$1" in
+	(--*)
+		# Option based command-line
+		while [ $# -gt 0 ] ; do
+			case "$1" in
+(--dumpable)
+	# Old Linux kernels do not support %d
+	# use the safest dumpable option there
+	case "$2" in
+		(--*) dumpable=2; shift;;
+		(*) dumpable="$2"; shift 2;;
+	esac
+;;
+(--owner) owner="$2"; shift 2;;
+(--limit) limit="$2"; shift 2;;
+# Use remaining arguments for core name
+		

Bug#924397: corekeeper: insecure use of world-writable /var/crash

[Paul Wise]

On Fri, 05 Apr 2019 11:58:24 +0800 Paul Wise wrote:

> I've done that in the attached patch.

I've now asked the release team for an unblock.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#925577: Intermediate fixup

[Jeroen Massar]

As an intermediary fix for those that just want to listen to their music...
(which does not fix the actual bug ;) )

Change the Service Type to 'simple' instead of forking and remove the 
'--daemon' argument from ExecStart, aka resulting file:

/lib/systemd/system/shairport-sync.service
```
[Unit]
Description=ShairportSync AirTunes receiver
Documentation=man:shairport-sync(7)
Documentation=file:///usr/share/doc/shairport-sync/README.md.gz
Documentation=https://github.com/mikebrady/shairport-sync
After=sound.target
Requires=avahi-daemon.service
After=avahi-daemon.service

[Service]
Type=simple
Restart=on-failure
EnvironmentFile=-/etc/default/shairport-sync
ExecStart=/usr/bin/shairport-sync $DAEMON_ARGS
User=shairport-sync
Group=shairport-sync
PIDFile=/run/shairport-sync/shairport-sync.pid

[Install]
WantedBy=multi-user.target
```


Then:
 systemctl daemon-reload
and:
 /etc/init.d/shairport-sync start

Voila, music works again ;)

This works as apparently only daemon mode is affected.

Greets,
 Jeroen

Bug#928419: ITP: golang-github-koofr-go-koofrclient -- Go Koofr client

[Drew Parsons]

Package: wnpp
Severity: wishlist
Owner: Drew Parsons 

* Package name: golang-github-koofr-go-koofrclient
  Version : 20190201.7f32759
  Upstream Author : Koofr
* URL : https://github.com/koofr/go-koofrclient
* License : MIT
  Programming Lang: Go
  Description : Go Koofr client

Provides a Go Client to access Koofr

Required by the latest version of rclone.

Will be managed by the Debian Go Team.

Bug#640150: Bug still exists

[Antoine Amarilli]

I had this bug occur today when trying to run evince after an upgrade. The
message told me to run the command:

  gdk-pixbuf-query-loaders > 
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache

But this doesn't work because it needs to be done as root and because
the full path to the command should be specified (it is even more
confusing as command-not-found gdk-pixbuf-query-loaders or apt-cache
search gdk-pixbuf-query-loaders return nothing). Specifically:

  sudo /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/gdk-pixbuf-query-loaders | sudo 
tee /usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders.cache

The error message should be clarified accordingly (and there's also a
question of why this command wasn't run during the upgrade process in
the first place).

-- 
Antoine Amarilli

Bug#914860: openjdk-11-jre-headless: fails to install in stretch-backports: ca-certificates-java.postinst: line 56: java: command not found

[Andreas Beckmann]

Control: found -1 11.0.3+1-1~bpo9+1
Control: affects -1 + openjdk-11-jre openjdk-11-dbg openjdk-11-jre-zero

On Wed, 28 Nov 2018 03:48:25 +0100 Andreas Beckmann  wrote:
> Does this require a newer version of ca-certificates-java (needs to
> be backported) and a corresponding versioned dependency to work properly?

which seems to be ca-certificates-java (>= 20180413)

ca-certificates-java (20180413) unstable; urgency=medium
...
  * Look for Java 10 and Java 11 when detecting the JRE

Please also fix this for sid/buster to prevent partial upgrade paths
that are not working.


Andreas

Bug#928420: php-imagick: CVE-2019-11037

[Salvatore Bonaccorso]

Source: php-imagick
Version: 3.4.3~rc2-2
Severity: grave
Tags: security upstream
Forwarded: https://bugs.php.net/bug.php?id=77791

Hi,

The following vulnerability was published for php-imagick.

CVE-2019-11037[0]:
| In PHP imagick extension in versions between 3.3.0 and 3.4.4, writing
| to an array of values in ImagickKernel::fromMatrix() function did not
| check that the address will be within the allocated array. This could
| lead to out of bounds write to memory if the function is called with
| the data controlled by untrusted party.


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-11037
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11037
[1] https://bugs.php.net/bug.php?id=77791

Regards,
Salvatore

Bug#928421: php7.3: CVE-2019-11036

[Salvatore Bonaccorso]

Source: php7.3
Version: 7.3.4-2
Severity: important
Tags: security upstream
Forwarded: https://bugs.php.net/bug.php?id=77950

Hi,

The following vulnerability was published for php7.3.

CVE-2019-11036[0]:
| When processing certain files, PHP EXIF extension in versions 7.1.x
| below 7.1.29, 7.2.x below 7.2.18 and 7.3.x below 7.3.5 can be caused
| to read past allocated buffer in exif_process_IFD_TAG function. This
| may lead to information disclosure or crash.


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-11036
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11036
[1] https://bugs.php.net/bug.php?id=77950

Regards,
Salvatore

Bug#928422: rust-doc: unsatisfiable Depends: fonts-open-sans in jessie

[Andreas Beckmann]

Package: rust-doc
Version: 1.24.1+dfsg1-1~deb8u4
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package is not
installable in jessie:

The following packages have unmet dependencies:
 rust-doc : Depends: fonts-open-sans but it is not installable
E: Unable to correct problems, you have held broken packages.


Cheers,

Andreas

Bug#928423: RM: rust-doc/1.14.0+dfsg1-3

[Andreas Beckmann]

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

rust-doc is a cruft binary:all package in stable, no longer built by the
new upstream version needed for modern firefox etc. that was introduced
via stretch/updates.

$ rmadison -s stable --source rustc
libstd-rust-1.24 | 1.24.1+dfsg1-1~deb9u4 | stable | amd64, arm64, armel, 
armhf, i386, ppc64el, s390x
libstd-rust-dev  | 1.24.1+dfsg1-1~deb9u4 | stable | amd64, arm64, armel, 
armhf, i386, ppc64el, s390x
rust-doc | 1.14.0+dfsg1-3| stable | all
rust-gdb | 1.24.1+dfsg1-1~deb9u4 | stable | all
rust-lldb| 1.24.1+dfsg1-1~deb9u4 | stable | all
rust-src | 1.24.1+dfsg1-1~deb9u4 | stable | all
rustc| 1.14.0+dfsg1-3| stable | source
rustc| 1.24.1+dfsg1-1~deb9u4 | stable | source, amd64, arm64, 
armel, armhf, i386, ppc64el, s390x


Andreas

Bug#928424: gcc-8-cross: Does not honor parallel=n properly in DEB_BUILD_OPTIONS

[Santiago Vila]

Package: gcc-8-cross
Version: 28

Dear Matthias:

I see this in debian/rules:

  ifeq ($(JOBS),1)
JOBS := 2
  endif

This was made in commit a4c6cdfc25368c1c86dfd215db99669f93f1f096
but the changelog does not say anything about it.

I believe this is related to the Makefile bug I reported in #924325,
but that will certainly not fix it, just hide it.

More to the point: If we know there is a Makefile bug and we don't
know why it does not show that way, we have no warranty at all that it
will work, it will do so by pure chance.

Thanks.

Bug#928425: upgrade-reports: Failed to fetch http://ftp.de.debian.org/debian/dists/jessie-updates/InRelease Unable to find expected entry 'main/source/Sources' in Releases file (Wrong sources.list ent

[jurek]

Package: upgrade-reports
Severity: important

Dear Maintainer,

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

   * What led up to the situation?
started apper to be up to date
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
repeated apper, looked into several sourceslistfiles but did not understand
   * What was the outcome of this action?
confusion about general system security
   * What outcome did you expect instead?
no error report from apper and the report 'you're up to date

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


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

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

Bug#926952: sa-exim: Unbuildable/uninstallable in sid

[Magnus Holmgren]

söndag 21 april 2019 kl. 19:55:10 CEST skrev  Magnus Holmgren:

> But now that I look closer, it looks like the "spool format error" message
> is only triggered by malformed header files, and Thomas in https://
> lists.exim.org/lurker/message/20180726.174108.0620f3c0.en.html had narrowed
> it down to multiple messages being received over the same connection. I
> still haven't been able to reproduce it though. It might be stochastic.

Okay, so as I reported on the exim-dev list, I figured out that  
primary_hostname, which has been being expanded once and the pointer kept in 
static memory since forever, is now being overwritten although allocated from 
the permanent pool. My plan is to change this to expand it anew for each run; 
that solved the problem when I tested. I'm also going to add an unrelated 
patch that disables body rewriting when the spool file is in wire format and 
which handles CRLF line endings when scanning headers. Do you think that you 
can then re-enable local_scan for the release?

-- 
Magnus Holmgrenholmg...@debian.org
Debian Developer 

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

Bug#928426: nmu: qtsvg-opensource-src etc. vs. qtbase-abi-5-12-3

[Andreas Beckmann]

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

nmu qtsvg-opensource-src_5.12.2-1 . ANY . experimental . -m "Rebuild against 
qtbase-abi-5-12-3."
nmu qtmultimedia-opensource-src_5.12.2-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qt3d-opensource-src_5.12.2i+dfsg-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtserialport-opensource-src_5.12.2-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtxmlpatterns-opensource-src_5.12.2-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtscript-opensource-src_5.12.2+dfsg-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtquickcontrols-opensource-src_5.12.2-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtvirtualkeyboard-opensource-src_5.12.2+dfsg-1 . ANY . experimental . -m 
"Rebuild against qtbase-abi-5-12-3."
nmu qtserialbus-everywhere-src_5.12.2-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtwayland-opensource-src_5.12.2-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtwebview-opensource-src_5.12.2-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtbase-opensource-src-gles_5.12.2+dfsg-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtgamepad-everywhere-src_5.12.2-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."
nmu qtnetworkauth-everywhere-src_5.12.2-1 . ANY . experimental . -m "Rebuild 
against qtbase-abi-5-12-3."


Andreas

Bug#928427: nageru: FTBFS in experimental: nageru/pbo_frame_allocator.h:36:8: error: ‘bmusb::FrameAllocator::Frame PBOFrameAllocator::create_frame(size_t, size_t, size_t)’ marked ‘override’, but does

[Andreas Beckmann]

Source: nageru
Version: 1.8.6-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Hi,

nageru/experimental FTBFS on all platforms:
https://buildd.debian.org/status/package.php?p=nageru&suite=experimental

[68/260] c++ -Istream@sta -I. -I.. -I../nageru -I../ 
-I/usr/include/i386-linux-gnu/qt5/QtOpenGLExtensions 
-I/usr/include/i386-linux-gnu/qt5/QtOpenGL 
-I/usr/include/i386-linux-gnu/qt5/QtWidgets 
-I/usr/include/i386-linux-gnu/qt5/QtGui 
-I/usr/include/i386-linux-gnu/qt5/QtNetwork 
-I/usr/include/i386-linux-gnu/qt5/QtCore -I/usr/include/i386-linux-gnu/qt5 
-I/usr/include/movit -I/usr/include/libdrm -I/usr/include/eigen3 
-I/usr/include/i386-linux-gnu -I/usr/include/libusb-1.0 
-I/usr/include/luajit-2.1 -I/usr/include/alsa -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 '-DMOVIT_SHADER_DIR="/usr/share/movit"' 
'-DNAGERU_VERSION="1.8.6"' '-DPREFIX="/usr"' -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
-DQT_OPENGLEXTENSIONS_LIB -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB 
-DQT_NETWORK_LIB -DQT_CORE_LIB  -MD -MQ 'stream@sta/nageru_print_latency.cpp.o' 
-MF 'stream@sta/nageru_print_latency.cpp.o.d' -o 
'stream@sta/nageru_print_latency.cpp.o' -c ../nageru/print_latency.cpp
FAILED: stream@sta/nageru_print_latency.cpp.o 
c++ -Istream@sta -I. -I.. -I../nageru -I../ 
-I/usr/include/i386-linux-gnu/qt5/QtOpenGLExtensions 
-I/usr/include/i386-linux-gnu/qt5/QtOpenGL 
-I/usr/include/i386-linux-gnu/qt5/QtWidgets 
-I/usr/include/i386-linux-gnu/qt5/QtGui 
-I/usr/include/i386-linux-gnu/qt5/QtNetwork 
-I/usr/include/i386-linux-gnu/qt5/QtCore -I/usr/include/i386-linux-gnu/qt5 
-I/usr/include/movit -I/usr/include/libdrm -I/usr/include/eigen3 
-I/usr/include/i386-linux-gnu -I/usr/include/libusb-1.0 
-I/usr/include/luajit-2.1 -I/usr/include/alsa -fdiagnostics-color=always -pipe 
-D_FILE_OFFSET_BITS=64 '-DMOVIT_SHADER_DIR="/usr/share/movit"' 
'-DNAGERU_VERSION="1.8.6"' '-DPREFIX="/usr"' -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -pthread 
-DQT_OPENGLEXTENSIONS_LIB -DQT_OPENGL_LIB -DQT_WIDGETS_LIB -DQT_GUI_LIB 
-DQT_NETWORK_LIB -DQT_CORE_LIB  -MD -MQ 'stream@sta/nageru_print_latency.cpp.o' 
-MF 'stream@sta/nageru_print_latency.cpp.o.d' -o 
'stream@sta/nageru_print_latency.cpp.o' -c ../nageru/print_latency.cpp
In file included from ../nageru/mixer.h:34,
 from ../nageru/print_latency.cpp:5:
../nageru/pbo_frame_allocator.h:36:8: error: ‘bmusb::FrameAllocator::Frame 
PBOFrameAllocator::create_frame(size_t, size_t, size_t)’ marked ‘override’, but 
does not override
  Frame create_frame(size_t width, size_t height, size_t stride) override;
^~~~
ninja: build stopped: subcommand failed.
dh_auto_build: cd obj-i686-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v returned 
exit code 1
make: *** [debian/rules:9: build-arch] Error 1


Andreas

Bug#928427: nageru: FTBFS in experimental: nageru/pbo_frame_allocator.h:36:8: error: ‘bmusb::FrameAllocator::Frame PBOFrameAllocator::create_frame(size_t, size_t, size_t)’ marked ‘override’, but does

[Steinar H. Gunderson]

On Sat, May 04, 2019 at 01:59:36PM +0200, Andreas Beckmann wrote:
> nageru/experimental FTBFS on all platforms:
> https://buildd.debian.org/status/package.php?p=nageru&suite=experimental

It depends on newer bmusb, currently in NEW. I should probably add a
Build-Depends.

/* Steinar */
-- 
Homepage: https://www.sesse.net/

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

[Alessandro Ghedini]

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
> 
> Hi!

Hello,

> 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.

Cheers


signature.asc
Description: PGP signature

Bug#928396: xfwm4: 'wmctrl -r ":ACTIVE:" -b add,hidden' does not minimize the active window

[Yves-Alexis Perez]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

control: forwarded -1 https://bugzilla.xfce.org/show_bug.cgi?id=15356

On Fri, 2019-05-03 at 19:43 +0200, pn...@telenet.be wrote:
> Hi Yves-Alexis,
> Thank you for your quick response.
> I've reported the issue at bugzilla.xfce.org (Bug #15356).

Many thanks, I'm marking the bug as forwarded. It seems that Olivier already
included your commit in the master branch, so it should be part of the next
release which should be part of 4.14 stable. This won't be for Buster though.

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

iQEzBAEBCAAdFiEE8vi34Qgfo83x35gF3rYcyPpXRFsFAlzNg0IACgkQ3rYcyPpX
RFs8QAf/div6i7SQ/tgnGKdCx+cLvntWq/LrxmLS7NorCTslvcqk9cYinYEn1zF5
g8GI/Is5s3lz+PwB8Rl3mA1kt4ujiyET3sJiOHQBHzGqF1N/H2ZAOzVDBwIsU4lE
hZiQShmczTac8RX9vij3TJxOYJJ3zss88FjHzXXyYPcHPhKJW3MDGFDdoWkvRKc+
yqNjEYOdVdakwn4D7ppRgRG6l8HED70imRZvxebD7H4+mIjwlJ6duGi83O4hUMWO
iLbtp4L0Dm56JjRzzyqNHsiT4kqULjZwl/C1/g/HDv6J1WgGb2n6mgugRjdeuf1b
4FUn7xeK9J2qWJzB2gX+rfNUKkGeqg==
=d5H3
-END PGP SIGNATURE-

Bug#928428: unblock: [pre-approval] wicd/1.7.4+tb2-7

[Axel Beckert]

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

In the light of dhcpcd5 automremoval (#928056, #928104, #928105), I'd
like to upload a wicd package which relies less on dhcpcd5. It
actually is already committed in Git, but the upload didn't happen due
to not having found the time to test it thoroughly on a machine which
only has dhcpcd5 installed. (Which I still plan to do, even iqn this
light.)

Currently the master branch of https://salsa.debian.org/debian/wicd
contains a bit more commits than useful at this stage of the release,
so I intent to cherry pick a bunch of these commits into a new branch
for buster/1.7.4+tb2-7 and then upload the remaining commits with
probably 1.7.4+tb2-8 after buster.

What I'd cherry-pick in any case:

  * Don't list dhcpcd5 as preferred DHCP client in the alternative
dependencies list. (Closes: #901592)

This should (hopefully) also make wicd no more affected by dhcpcd5's
autoremoval.

What I think should be done, too, but is probably less important when
dhcpcd5 is removed:

  * Look for "dhcpcd5" instead of "dhcpcd". (Closes: #852343)

This is currently of normal severity but in combination with an
unfixed #901592 it is actually grave as it doesn't find the default
DHCP client anymore. Then again, if dhcpcd5 is no more the default or
even removed, the current severity of normal is more than fitting.

I'd also include these purely documentational changes:

  * d/copyright: Change Format URL to correct one

I'll prepare a feature branch for this in git including a planned
debdiff and let you know once it's ready for review/upload. I though
would happy to receive feedback from the release team beforehand.

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

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

Bug#924283: jython: does not run with older Java versions

[Andreas Beckmann]

Followup-For: Bug #924283
Control: affects -1 + jython-stilts astro-all

Hi,

you need to bump the dependency to

default-jre-headless (>= 2:1.9) | java9-runtime-headless
 ^^

otherwise default-jre-headless allows incompatible versions.


Andreas

Bug#928430: mutt: should be able to decode headers using ks_c_5601-1987

[Uwe Kleine-Kønig]

Package: mutt
Version: 1.10.1-2
Severity: normal

Hello,

I recently got an email from a guy using Outlook and the mail's From
header was encoded using ks_c_5601-1987.

It looked as follows in raw:

From: =?ks_c_5601-1987?B?U6mqcmVuIExhc3RuYW1l?= 

and mutt failed to properly display it. It shows as as

S��ren Lastname

. Using Thunderbird the name is fine there.

I tried to do the same with this email encoding my name in
ks_c_5601-1987 to demonstrate the issue, I hope I didn't mess up.

Would be great if this could be fixed in mutt.

Not knowing how that decoding works, quick googling suggests that an
alternative name for "ks_c_5601-1987" is "uhc" and with this my system's
iconv can properly decode the name:

$ base64 -d <<< U6mqcmVuIExhc3RuYW1l | iconv -f uhc; echo
Søren Lastname

Best regards
Uwe

-- Package-specific info:
Mutt 1.10.1 (2018-07-13)
Copyright (C) 1996-2016 Michael R. Elkins and others.
Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'.
Mutt is free software, and you are welcome to redistribute it
under certain conditions; type `mutt -vv' for details.

System: Linux 4.19.0-4-amd64 (x86_64)
ncurses: ncurses 6.1.20181013 (compiled with 6.1)
libidn: 1.33 (compiled with 1.33)
hcache backend: tokyocabinet 1.4.48

Compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.2.0-3' 
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu 
--enable-libstdcxx-debug --enable-libstdcxx-time=yes 
--with-default-libstdcxx-abi=new --enable-gnu-unique-object 
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie 
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto 
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-3) 

Configure options: '--build=x86_64-linux-gnu' '--prefix=/usr' 
'--includedir=\${prefix}/include' '--mandir=\${prefix}/share/man' 
'--infodir=\${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
'--disable-silent-rules' '--libdir=\${prefix}/lib/x86_64-linux-gnu' 
'--libexecdir=\${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' 
'--disable-dependency-tracking' '--with-mailpath=/var/mail' 
'--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' 
'--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' 
'--enable-sidebar' '--enable-nntp' '--enable-dotlock' '--disable-fmemopen' 
'--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' 
'--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' 
'--with-tokyocabinet' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 
-fdebug-prefix-map=/build/mutt-XxBiSz/mutt-1.10.1=. -fstack-protector-strong 
-Wformat -Werror=format-security' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 
'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

Compilation CFLAGS: -Wall -pedantic -Wno-long-long -g -O2 
-fdebug-prefix-map=/build/mutt-XxBiSz/mutt-1.10.1=. -fstack-protector-strong 
-Wformat -Werror=format-security

Compile options:
-DOMAIN
+DEBUG
-HOMESPOOL  +USE_SETGID  +USE_DOTLOCK  +DL_STANDALONE  +USE_FCNTL  -USE_FLOCK   
+USE_POP  +USE_IMAP  +USE_SMTP  
-USE_SSL_OPENSSL  +USE_SSL_GNUTLS  +USE_SASL  +USE_GSS  +HAVE_GETADDRINFO  
+HAVE_REGCOMP  -USE_GNU_REGEX  
+HAVE_COLOR  +HAVE_START_COLOR  +HAVE_TYPEAHEAD  +HAVE_BKGDSET  
+HAVE_CURS_SET  +HAVE_META  +HAVE_RESIZETERM  +HAVE_FUTIMENS  
+CRYPT_BACKEND_CLASSIC_PGP  +CRYPT_BACKEND_CLASSIC_SMIME  +CRYPT_BACKEND_GPGME  
-EXACT_ADDRESS  -SUN_ATTACHMENT  
+ENABLE_NLS  -LOCALES_HACK  +HAVE_WC_FUNCS  +HAVE_LANGINFO_CODESET  
+HAVE_LANGINFO_YESEXPR  
+HAVE_ICONV  -ICONV_NONTRANS  +HAVE_LIBIDN  -HAVE_LIBIDN2  +HAVE_GETSID  
+USE_HCACHE  +USE_SIDEBAR  +USE_COMPRESSED  
-ISPELL
SENDMAIL="/usr/sbin/sendmail"
MAILPATH="/var/mail"
PKGDATADIR="/usr/share/mutt"
SYSCONFDIR="/etc"
EXECSHELL="/bin/sh"
MIXMASTER="mixmaster"

To contact the developers, please mail to .
To report a bug, please contact the Mutt maintainers via gitlab:
https://gitlab.com/muttmua/mutt/issues


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (700, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), 
(500, 'testing-debug'), (500, 'stable'), (499,

Bug#928417: Bug#928415,#928417: [firefox] All extensions are disabled

[Alexis Murzeau]

Hi,

This bug affect both firefox-esr in Stretch and firefox in
testing/unstable. Should they be kept separate ?

This bug does not affect packaged extensions within Debian despite some
of them having the expired certificate like webext-noscript 10.1.9.6-2
or webext-https-everywhere 2018.8.22-1~deb9u1.

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







signature.asc
Description: OpenPGP digital signature

Bug#928428: unblock: [pre-approval] wicd/1.7.4+tb2-7

[Axel Beckert]

Hi,

Axel Beckert wrote:
> I'll prepare a feature branch for this in git including a planned
> debdiff and let you know once it's ready for review/upload. I though
> would happy to receive feedback from the release team beforehand.

Preliminary (and obviously not yet finished) patch as of the branch
"buster" at https://salsa.debian.org/debian/wicd/tree/buster:

diff --git a/debian/changelog b/debian/changelog
index aa96f2b..0e00a8b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,17 @@
+wicd (1.7.4+tb2-7) UNRELEASED; urgency=medium
+
+  [ Axel Beckert ]
+  TODO: Test on a machine with dhcpcd5 only before uploading!
+
+  * Don't list dhcpcd5 as preferred DHCP client in the alternative
+dependencies list. (Closes: #901592)
+  * Look for "dhcpcd5" instead of "dhcpcd". (Closes: #852343)
+
+  [ Ondřej Nový ]
+  * d/copyright: Change Format URL to correct one
+
+ -- Axel Beckert   Fri, 15 Jun 2018 12:38:12 +0200
+
 wicd (1.7.4+tb2-6) unstable; urgency=low
 
   * Set "Rules-Requires-Root: no".
diff --git a/debian/control b/debian/control
index 9869ef6..6c5c4e8 100644
--- a/debian/control
+++ b/debian/control
@@ -42,7 +42,7 @@ Package: wicd-daemon
 Architecture: all
 Depends: adduser,
  dbus,
- dhcpcd5 | isc-dhcp-client | pump | udhcpc,
+ isc-dhcp-client | pump | udhcpc | dhcpcd5,
  iputils-ping | inetutils-ping,
  lsb-base (>= 3.2-13),
  psmisc,
diff --git a/debian/copyright b/debian/copyright
index 8f973c9..a6f30e0 100644
--- a/debian/copyright
+++ b/debian/copyright
@@ -1,4 +1,4 @@
-Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0
+Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
 Source: https://launchpad.net/wicd/+download
 
 Files: *
diff --git a/debian/patches/46-dhcpcd_is_now_dhcpcd5.patch 
b/debian/patches/46-dhcpcd_is_now_dhcpcd5.patch
new file mode 100644
index 000..71cfd2f
--- /dev/null
+++ b/debian/patches/46-dhcpcd_is_now_dhcpcd5.patch
@@ -0,0 +1,147 @@
+Description: Update binary names from dhcpcd to dhcpcd5
+Author: Axel Beckert 
+Bug-Debian: https://bugs.debian.org/852343
+Forwarded: no
+
+--- a/data/wicd.ui
 b/data/wicd.ui
+@@ -1226,7 +1226,7 @@
+ 
+ 
+   
+-dhcpcd
++dhcpcd5
+ True
+ True
+ False
+--- a/in/man=nl=wicd-manager-settings.conf.5.in
 b/in/man=nl=wicd-manager-settings.conf.5.in
+@@ -39,7 +39,7 @@
+ .br
+ 1 = dhclient
+ .br
+-2 = dhcpcd
++2 = dhcpcd5
+ .br
+ 3 = pump
+ .TP
+--- a/in/man=nl=wicd.8.in
 b/in/man=nl=wicd.8.in
+@@ -37,7 +37,7 @@
+ Wicd gebruikt ingebouwde Linux draadloze netwerktools, zoals ifconfig en
+ iwconfig, om netwerkinformatie te krijgen en in te stellen. Er is enige
+ flexibiliteit in het gebruik van DHCP, door het ondersteunen van dhclient,
+-dhcpcd en pump. Wicd gebruikt wpa_supplicant voor alle draadloze
++dhcpcd5 en pump. Wicd gebruikt wpa_supplicant voor alle draadloze
+ coderingsinstellingen, en gebruikt een sjabloongebaseert systeem om de
+ configuratiebestanden te maken die door wpa_supplicant worden gebruikt. Deze
+ sjablonen kunnen worden bewerkt, en nieuwe sjablonen kunnen worden gemaakt 
door
+@@ -153,7 +153,7 @@
+ .BR mii-tool (8),
+ .BR ethtool (8),
+ .BR dhclient (8),
+-.BR dhcpcd (8),
++.BR dhcpcd5 (8),
+ .BR pump (8).
+ 
+ 
+--- a/in/man=wicd-manager-settings.conf.5.in
 b/in/man=wicd-manager-settings.conf.5.in
+@@ -39,7 +39,7 @@
+ .br
+ 1 = dhclient
+ .br
+-2 = dhcpcd
++2 = dhcpcd5
+ .br
+ 3 = pump
+ .TP
+--- a/in/man=wicd.8.in
 b/in/man=wicd.8.in
+@@ -35,7 +35,7 @@
+ 
+ Wicd uses built-in linux wireless-tools, such as ifconfig and iwconfig, to
+ get and configure network info.  There is some flexibility in its use of DHCP,
+-providing support for dhclient, dhcpcd, and pump.  Wicd uses wpa_supplicant
++providing support for dhclient, dhcpcd5, and pump.  Wicd uses wpa_supplicant
+ to handle all wireless encryption settings, and uses a template-based system
+ to create the configuration files used by wpa_supplicant.  These templates
+ can be edited, and new templates can be created by the user and imported into
+@@ -178,7 +178,7 @@
+ .BR mii-tool (8),
+ .BR ethtool (8),
+ .BR dhclient (8),
+-.BR dhcpcd (8),
++.BR dhcpcd5 (8),
+ .BR pump (8).
+ 
+ 
+--- a/wicd/wnettools.py
 b/wicd/wnettools.py
+@@ -307,7 +307,7 @@
+ def get_client_name(cl):
+ """ Converts the integer value for a dhcp client to a string. """
+ if self.dhcpcd_cmd and cl in [misc.DHCPCD, misc.AUTO]:
+-client = "dhcpcd"
++client = "dhcpcd5"
+ cmd = self.dhcpcd_cmd
+ elif self.pump_cmd and cl in [misc.PUMP, misc.AUTO]: 
+ client = "pump"
+

Bug#928431: RFS: libsml/0.1.1+git20190410-1

[Andreas Moog]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: libsml
 Version : 0.1.1+git20190410-1
 Section : libs

It builds those binary packages:

  libsml-dev - Header files for libSML
  libsml1 - Library for the Smart Messaging Language (SML)

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/libs/libsml/libsml_0.1.1+git20190410-1.dsc

Changes since the last upload:

libsml (0.1.1+git20190410-1) unstable; urgency=medium

  * New upstream snapshot
  * Change to correct github upstream project in debian/copyright
  * Change homepage to volkszaehler/libsml
  * Update symbols file
  * Update copyright years
  * Update gitlab CI
  * Update standards version

Regards,
 Andreas Moog
-- 
PGP-encrypted mails preferred
PGP Fingerprint: 74CD D9FE 5BCB FE0D 13EE 8EEA 61F3 4426 74DE 6624


signature.asc
Description: PGP signature

Bug#928432: usage text and man page point at wrong location for rgb.txt

[Steve McIntyre]

Package: xcolorsel
Version: 1.1a-21
Severity: minor

Hi,

Both the usage text and the man page point to the wrong location for
rgb.txt:

$ xcolorsel --help 
xcolorsel: Invalid options/additional parameters
Offending arguments are:
xcolorsel --help
usage: xcolorsel [options] [RgbTxtFile]
displays contents of RgbTxtFile (default is
/usr/lib/X11/rgb.txt) together with color
samples.
...

$ man xcolorsel | grep -3 DESCR
SYNOPSIS
   xcolorsel [options] [RgbTxtFile]

DESCRIPTION
   This utility displays the contents of the rgb.txt file  (usually  found
   as  /usr/lib/X11/rgb.txt)  or  a file with this format specified as the
   optional [RgbTxtFile] parameter. Each line of this file consists  of  3

Please update these to point to the correct location for a Debian
system. That appears to be /etc/X11/rgb.txt, as listed in the
description for the package in debian/control.

Cheers,

Steve

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
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

Versions of packages xcolorsel depends on:
ii  libc6 2.28-8
ii  libx11-6  2:1.6.7-1
ii  libxt61:1.1.5-1+b3
ii  xaw3dg1.5+E-18.3

xcolorsel recommends no packages.

xcolorsel suggests no packages.

-- no debconf information

Bug#928433: firefox-esr: app.normandy.enabled should default to false

[Robert Lange]

Package: firefox-esr
Version: 60.6.1esr-1~deb9u1
Severity: important

In Preferences/Privacy & Security there are a pair of preferences "Allow
Firefox to send technical and interaction data to Mozilla" and "Allow Firefox
to install and run studies". These are both unchecked and greyed out by
default. They cannot be checked, and there is a line of text under them that
says "Data reporting is disabled for this build configuration". I vaguely
recall reading something about Debian disabling this around the time that the
Mr Robot "easter egg" came out.

Today in the wake of reading about the Mozilla certificate oops that broke
everyone's extensions, Mozilla announced that they used their studies system to
push out the fix without requiring a formal update. Given that my extensions
were in fact working, I was confused by this. I read that the config key for
studies was app.normandy.enabled, so I checked about:config and lo and behold,
that setting was defaulted to true. I would expect that it would be false,
given that the UI setting claims to be disabled.

I'd imagine that this might be a serious bug, but I'm not a lawyer and I don't
have hours of time to spend today, so I can't give you chapter and verse of the
policy to say what policy is violated by defaulting to allowing an app author
to remotely change settings on user's computers in the background.



-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u4
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.5-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libx11-xcb1   2:1.6.4-3+deb9u1
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.2.12-1~deb9u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libgtk2.0-02.24.31-2
ii  pulseaudio 10.0-1+deb9u1

-- no debconf information

Bug#915070: Re: Bug#915070: wodim ignores -dummy

[mdayq0]

I burn discs once a year. Next time I try I report here.

Отправлено из мобильной Рамблер/почты.

 10.3.2019, 13:21:14 пользователь Steve McIntyre (st...@einval.com) написал:


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

 Hi!

 On Fri, Nov 30, 2018 at 05:40:41AM +0300, Md Ayquassar wrote:
 >Package: wodim
 >Version: 9:1.1.11-3+b2
 >Severity: critical
 >
 >Starting with a blank 4.7 Gb DVD-R in the optical drive "HL-DT-ST DVD+-RW
 >GS30N", my_file.iso containing a freshly downloaded copy of Windows 10 (US
 >English, x64), and issuing
 >
 >$ sudo wodim -v driver=mmc_cd_dvd dev=/dev/sg1 -dummy -dao speed=1 fs=100m
 >driveropts=noburnfree -data my_file.iso
 >
 >twice, I discovered that the first dry run succeeded, but the second did
 not.
 >Upon ejecting the disc, I saw a differently colored ring on the disc. So,
 wodim
 >didn't turn off the laser completely and thus made the disc unusable.
 >
 >So, we can no more test wodim's features without destroying discs. In
 practical
 >terms, this makes wodim a harmful program. I suggest removing it from Debian
 >completely.

 I've never seen this happen at all, in many years of working with
 wodim. Can you reproduce and grab a log to show it happening please?

 --
 Steve McIntyre, Cambridge, UK. st...@einval.com
 Armed with "Valor": "Centurion" represents quality of Discipline,
 Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
 concord the digital world while feeling safe and proud.

Bug#928434: lists.debian.org: Request for a new mailing list: nim

[Steffen Moeller]

Package: lists.debian.org
Severity: wishlist

Dear Maintainer,

A fairly new programming language, nim, has surfaced with an increasing
number of adoptees of software, also in the sciences, that we would like
to package. We created https://salsa.debian.org/nim-team/ and for
team management we thought of a mailing list to place as a maintainer,
listing uploaders only as such.

Cheers,

Steffen 

Bug#928415: (no subject)

[Erik]

Official Mozilla response:

https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047

"Certificate issue causing add-ons to be disabled or fail to install:

10:50 a.m. UTC / 01:50 a.m. PDT: We rolled-out a fix for release, beta 
and nightly users on Desktop. The fix will be automatically applied in 
the background within the next few hours, you don’t need to take active 
steps.


In order to be able to provide this fix on short notice, we are using 
the Studies system. You can check if you have studies enabled by going 
to Firefox Preferences -> Privacy & Security -> Allow Firefox to install 
and run studies.


You can disable studies again after your add-ons have been re-enabled.

We are working on a general fix that doesn’t need to rely on this and 
will keep you updated.


See the latest updates here: 
https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/ 



"

Firefox from the Debian package has data reporting disabled so using 
studies is not possible.

Bug#928437: firefox: shield disabled

[Danny Fritz]

Package: firefox
Version: 66.0.1-1
Severity: normal

Firefox shield appears to be disabled in the Debian sid release of firefox in
66.0.1.
I've also seen this feature being called or related to "user studies" and
"normandy".

This is a feature that allows Firefox to push quick changes without a full
release.
It also allows firefox to do A/B studies on their users if they allow it.

This is a recent bug in Firefox that a shield fix could fix:
https://bugzilla.mozilla.org/show_bug.cgi?id=1548973
It appears Debian users will have to wait for a point release for the fix.



-- Package-specific info:


-- Addons package information

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

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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-8
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.12-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42.1-1
ii  libpango-1.0-01.42.4-6
ii  libsqlite3-0  3.27.2-2
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox recommends:
ii  libavcodec57  7:3.4.3-1
ii  libavcodec58  7:4.1.1-1

Versions of packages firefox suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-2
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-4

-- no debconf information

Bug#928436: cracklib2 should be explicit about disabling zlib support

[Helmut Grohne]

Source: cracklib2
Version: 2.9.6-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

When building cracklib2 in a dirty chroot (i.e. with extra packages),
the build result is not reproducible. The presence of zlib1g-dev adds
additional features. Moreover, when doing a cross build, the presence of
zlib1g-dev:$DEB_BUILD_ARCH can result in a build failure of
zlib1g-dev:$DEB_HOST_ARCH is missing. Please curse me for attempting to
do such things.

Anyway, cracklib2 could easily support this mode by being explicit about
its zlib integration. The status quo would be --without-zlib. Please
consider applying the attached patch.

Helmut
diff --minimal -Nru cracklib2-2.9.6/debian/changelog 
cracklib2-2.9.6/debian/changelog
--- cracklib2-2.9.6/debian/changelog2018-12-31 12:04:32.0 +0100
+++ cracklib2-2.9.6/debian/changelog2019-05-04 18:28:10.0 +0200
@@ -1,3 +1,10 @@
+cracklib2 (2.9.6-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Explicitly disable zlib support. (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 04 May 2019 18:28:10 +0200
+
 cracklib2 (2.9.6-2) unstable; urgency=medium
 
   * Add missing 2.9.6-1 changelog bug tracker references
diff --minimal -Nru cracklib2-2.9.6/debian/rules cracklib2-2.9.6/debian/rules
--- cracklib2-2.9.6/debian/rules2018-12-31 12:04:32.0 +0100
+++ cracklib2-2.9.6/debian/rules2019-05-04 18:28:09.0 +0200
@@ -38,6 +38,7 @@
--prefix=/usr --disable-rpath --without-python \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--with-default-dict=/var/cache/cracklib/cracklib_dict \
+   --without-zlib \
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" LDFLAGS="$(LDFLAGS)"
for i in $(PYVERS) $(PY3VERS); do \
mkdir -p $(CURDIR)/debian/buildtmp/python$$i; \
@@ -47,6 +48,7 @@
--prefix=/usr --disable-rpath \
--libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH) \
--with-default-dict=/var/cache/cracklib/cracklib_dict \
+   --without-zlib \
PYTHON_PREFIX=$(call py_builddir_sh,$$i) \
PYTHON=/usr/bin/python$$i \
CFLAGS="$(CFLAGS)" CPPFLAGS="$(CPPFLAGS)" 
LDFLAGS="$(LDFLAGS)"; \

Bug#920563: dracut: fails to boot with bash 5 as /bin/sh

[Lehel Bernadt]

I ran into the same problem. I have just one (root) filesystem, with ext4 on 
it. I think it's trivial to reproduce it with an install with ext* 
filesystems.
For inspiration on how to fix it you can look here: 
https://github.com/void-linux/void-packages/tree/master/srcpkgs/dracut/patches 
(I don't know why these aren't in upstream though)


signature.asc
Description: PGP signature

Bug#928415: Your mail

[Xavier Hourcade]

Hello,

On Sat, 4 May 2019 09:43:12 -0500 Erik  wrote:
> Firefox from the Debian package has data reporting disabled so using 
> studies is not possible.

Neither with Tor Browser, which is also affected.

Just tried some workaround, it seems to work with both Firefox ESR from
Debian stable, and Tor Browser from Tor Project :

Setting "xpinstall.signatures.required" to "false" in "about:config",
does instantly re-enable addons : they are working again, no browser
restart is even required, so the problem is gone the same way it came.
A warning is displayed for each addon in the list.

I'd suggest to *first* disable addon auto-updates and *until* this
problem is solved.

Xavier

Bug#928438: unblock: libfm-qt/0.14.1-8

[Alf Gaida]

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

Please unblock package libfm-qt

Problem: Recursive moving of folders is prohibited in some cases
New version fixes #927708 which renders pcmanfm-qt nearly unusable for basic 
tasks in file management.
Solution was to port back the upstream fix.


diff --git a/debian/changelog b/debian/changelog
index e5012f5..9bc9b25 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,15 @@
+libfm-qt (0.14.1-8) unstable; urgency=medium
+
+  * Removed the wrongly introduced build dependency on lxqt-qtplugin
+
+ -- Alf Gaida   Sat, 27 Apr 2019 18:40:25 +0200
+
+libfm-qt (0.14.1-7) unstable; urgency=medium
+
+  * Workaround for GLib's recursive moving error (Closes: #927708)
+
+ -- Alf Gaida   Sat, 27 Apr 2019 10:50:16 +0200
+
 libfm-qt (0.14.1-6) unstable; urgency=medium
 
   * Fixed ignored creation-deletion sequences (Closes: #927707)
diff --git a/debian/patches/series b/debian/patches/series
index 3a2195c..1a4dd71 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,3 +1,4 @@
 fix-smb-recursive-copy.patch
 fix-license-headers.patch
 dont-ignore-crea-del-sequences.patch
+workaround-glib-recursive-moving-error.patch
diff --git a/debian/patches/workaround-glib-recursive-moving-error.patch 
b/debian/patches/workaround-glib-recursive-moving-error.patch
new file mode 100644
index 000..838ff29
--- /dev/null
+++ b/debian/patches/workaround-glib-recursive-moving-error.patch
@@ -0,0 +1,33 @@
+From 476dded99de11a57c64103b4610f0de3dbdbc769 Mon Sep 17 00:00:00 2001
+From: Tsu Jan 
+Date: Mon, 22 Apr 2019 00:07:07 +0430
+Subject: [PATCH] Workaround for GLib's recursive moving error, e.g. with bound
+ mounts
+
+`g_file_move()` may not work recursively on the same filesystem, especially
+with bound mounts (to `/mnt`, for example) and give the 
`G_IO_ERROR_WOULD_RECURSE`
+error. This patch ignores the error and tries our 
`FileTransferJob::copyFile()`.
+
+Closes https://github.com/lxqt/pcmanfm-qt/issues/943
+---
+ src/core/filetransferjob.cpp | 7 +++
+ 1 file changed, 7 insertions(+)
+
+diff --git a/src/core/filetransferjob.cpp b/src/core/filetransferjob.cpp
+index c3d5851..32f0f89 100644
+--- a/src/core/filetransferjob.cpp
 b/src/core/filetransferjob.cpp
+@@ -83,6 +83,13 @@ bool FileTransferJob::moveFileSameFs(const FilePath& 
srcPath, const GFileInfoPtr
+ // do the file operation
+ if(!g_file_move(srcPath.gfile().get(), destPath.gfile().get(), 
GFileCopyFlags(flags), cancellable().get(),
+nullptr, this, &err)) {
++// Specially with mounts bound to /mnt, g_file_move() may give 
the recursive error
++// and fail, in which case, we ignore the error and try copying 
and deleting.
++if(err.code() == G_IO_ERROR_WOULD_RECURSE) {
++  if(auto parent = destPath.parent()) {
++  return copyFile(srcPath, srcInfo, parent, 
destPath.baseName().get());
++  }
++}
+ retry = handleError(err, srcPath, srcInfo, destPath, flags);
+ }
+ else {


unblock libfm-qt/0.14.1-8

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

Kernel: Linux 5.0.11-towo.2-siduction-amd64 (SMP w/8 CPU cores; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Bug#927409: [PATCH] render ' entity

[Eric Wong]

' is supported in XHTML and HTML5, so at least render it
properly when seen in HTML we encounter.

We don't start escaping "'", yet; but if we do, I suggest using
' to ensure compatibility with older w3m versions.
>From b557289dd4309b37a2d9710fa92c3d269ef67228 Mon Sep 17 00:00:00 2001
From: Eric Wong 
Date: Sat, 4 May 2019 17:21:48 +
Subject: [PATCH] render ' entity

' is supported in XHTML and HTML5, so at least render it
properly when seen in HTML we encounter.

We don't start escaping "'", yet; but if we do, I suggest using
' to ensure compatibility with older w3m versions.

cf. https://bugs.debian.org/927409
---
 entity.tab | 2 ++
 indep.c| 2 +-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/entity.tab b/entity.tab
index 130ae2d..c9f9391 100644
--- a/entity.tab
+++ b/entity.tab
@@ -9,6 +9,8 @@ quot	0x22
 QUOT	0x22
 nbsp	0xA0
 NBSP	0xA0
+apos	0x27
+APOS	0x27
 iexcl	0xA1
 cent	0xA2
 pound	0xA3
diff --git a/indep.c b/indep.c
index 5c5de06..386c7e5 100644
--- a/indep.c
+++ b/indep.c
@@ -462,7 +462,7 @@ getescapechar(char **str)
 q = p;
 for (p++; IS_ALNUM(*p); p++) ;
 q = allocStr(q, p - q);
-if (strcasestr("lt gt amp quot nbsp", q) && *p != '=') {
+if (strcasestr("lt gt amp quot nbsp apos", q) && *p != '=') {
 	/* a character entity MUST be terminated with ";". However,
 	 * there's MANY web pages which uses < , > or something
 	 * like them as <, >, etc. Therefore, we treat the most
-- 
EW

Bug#860482: Missing dependencies for *xinit* and *dbus-x11* used in systemd service unit

[Bálint Réczey]

Control: found -1 2:17.0+dfsg1-3
Control: fixed -1 2:17.6+dfsg1-2

Dear Paul and Johannes,


2017-12-25 23:52 GMT+01:00 Johannes Schauer :
> On Mon, 17 Apr 2017 18:39:24 +0200 Paul Menzel  
> wrote:
>> The systemd service unit file `/lib/systemd/system/kodi.service`
>> currently needs the binaries `/usr/bin/xinit` and `/usr/bin/dbus-
>> launch` [1].
>>
>> ```
>> ExecStart=/usr/bin/xinit /usr/bin/dbus-launch --exit-with-session 
>> /usr/bin/kodi-standalone -- :0 -nolisten tcp vt7
>> ```
>>
>> Both executables are currently not present as the packages providing
>> these files -- *xinit* and *dbus-x11* -- are not dependencies.
>>
>> As the service file is disabled by default, I am unsure what rule
>> applies here. I'd prefer a dependency over a recommendation. Currently,
>> the installed size of *xinit* is 80 kB, and of *dbus-x11* 140 kB.
>
> That is not entirely correct. You also have to consider the reverse
> dependencies here. If installing these packages on a minimal system, then
> including Recommends, apt reports that "334 MB of additional disk space will 
> be
> used."
>
> Without Recommends this goes down to 6354 kB but then you are also left 
> without
> xserver-xorg or x-session-manager/x-window-manager.
>
> But even when these packages are installed, the provided kodi.service is still
> not functional because:
>
> /usr/bin/Xorg.wrap: Only console users are allowed to run the X server
>
> So in addition to installing these packages, one also has to edit
> /etc/X11/Xwrapper.config and add:
>
> allowed_users = anybody
>
> But even then it is questionable whether starting kodi like this via systemd 
> is
> the right approach. Kodi is not a system-wide service. As it is implemented
> here, it is not possible to have a separate instance for each session. And
> according to FernetMenta, the author of Kodi's X11 windowing system kodi 
> should
> never be started without a window manager [1]. The article under [1] also
> includes the kodi.service file from the Debian package but is declared as
> outdated.
>
> On the other hand, I was also unable to find the "right" way to start kodi
> automatically on bootup as the only running graphical application. I would
> suspect that the right way involves crafting a custom session that start all
> the necessary programs? So like a .desktop file in /usr/share/xsessions/.

According to upstream's current recommendation I removed the .service
file and suggest starting Kodi from a user session, possibly with
auologin.

This makes the bug solved since there is no need for the extra
dependencies anymore.

Cheers,
Balint

>
> But I'm not an expert either. Just my 2c.
>
> Thanks!
>
> cheers, josch
>
>
> [1] http://kodi.wiki/view/Archive:HOW-TO:Autostart_Kodi_for_Linux

Bug#928417: studies disabled in debian

[Niv Sardi]

mozilla is roling out a fix 
https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/
that said they are using the 'studies' infrastructure to do so, and 
they seem to be disabled in the debian build.

Bug#928439: zram-tools: zramswap status - always reports nothing

[Jari Aalto]

Package: zram-tools
Version: 0.3.2.1-1
Severity: normal

Command:

$ zramswap status

compr_data_size: 0 KiB
orig_data_size:  0 KiB
compression-ratio: 0

This due to code /usr/sbin/zramswap

55  function status {
56  orig_data_size="0"
57  for file in /sys/block/zram*/*_data_size ; do
58  if [ $file = "/sys/block/zram*/*_data_size" ]; then
59  compress_ratio="0"
60  break
61  fi

Because of the for-loop uses non-existing file pattern:

   ls -l /sys/block/zram*/*_data_size

   ls: cannot access '/sys/block/zram*/*_data_size': No such file or directory

Compare to:

https://www.kernel.org/doc/Documentation/blockdev/zram.txt

# 1. orig_data_size
# 2. compr_data_size
# 3. mem_used_totalz

cat /sys/block/zram0/mm_stat
4096   7812288012288000

Jari

-- 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)
Kernel taint flags: TAINT_CRAP
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 zram-tools depends on:
ii  bc  1.07.1-2+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

-- debconf-show failed

Bug#919621: lvm2: Update unexpectedly activates system ID check, bypassing impossible

[Colin Watson]

On Fri, Jan 18, 2019 at 03:16:26AM +0100, Andreas Bombe wrote:
> This has worked for all these years until the update, which rejects the
> VG with system ID without advance warning during package upgrade. Systems
> may become unbootable after upgrade if these VGs contain filesystems
> that are mounted in /etc/fstab.
[...]
> The only way to get access was to set global/system_id_source =
> "lvmlocal" and set local/system_id to the affected VG's system ID.

I also ran into this on upgrading from stretch to buster.  Fortunately I
was keeping enough of an eye on console output from the upgrade that I
was able to find this bug and I worked around it as you describe here.

However, I forgot to update the initramfs after doing so, so I ended up
having to sed /etc/lvm/lvm.conf and /etc/lvm/lvmlocal.conf in the
initramfs anyway to get the system booting; once I got back into the
system and ran "update-initramfs -u", a reboot worked fine.  I mention
this mainly in case anyone in the same situation finds this bug and
might find it helpful.

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

Bug#928440: dhcpcd5: DHCPv6: Potential read overflow with D6_OPTION_PD_EXCLUDE

[Timo Sigurdsson]

Package: dhcpcd5
Version: 7.1.0-1
Severity: serious
Tags: security upstream fixed-upstream

Dear Maintainer,

another week - another bug ;) Upstream released version 7.2.2 of dhcpcd5 fixing 
another potential security issue in DHCPv6. All versions currently supported in 
Debian (jessie, stretch, buster, sid) seem to be vulnerable [1].

The following issue has been fixed (copied from upstream's announcement):
  *  DHCPv6: Fix a potential read overflow with D6_OPTION_PD_EXCLUDE


Upstream provides two patches for version 7 which would be relevant for buster 
and sid [2][3]. In addition, version 6.10.7 was released addressing the same 
issue. The patches from this release might be useful for backporting to stretch 
and jessie [4][5].

Please consider applying/backporting those patches in your next round of 
uploads.

Thanks and regards,

Timo

[1] https://roy.marples.name/archives/dhcpcd-discuss/0002428.html
[2] 
https://roy.marples.name/cgit/dhcpcd.git/commit/?h=dhcpcd-7&id=c1ebeaafeb324bac997984abdcee2d4e8b61a8a8
[3] 
https://roy.marples.name/cgit/dhcpcd.git/commit/?h=dhcpcd-7&id=896ef4a54b0578985e5e1360b141593f1d62837b
[4] 
https://roy.marples.name/cgit/dhcpcd.git/commit/?h=dhcpcd-6&id=c8887c666aacd01bc8f420d617d538cb9fef54f3
[5] 
https://roy.marples.name/cgit/dhcpcd.git/commit/?h=dhcpcd-6&id=eb7aee47581bea64a93080abbde06bd6714321e6

Bug#928422: [Pkg-rust-maintainers] Bug#928422: rust-doc: unsatisfiable Depends: fonts-open-sans in jessie

[Ximin Luo]

Control: tags + -1 jessie
Control: notfound -1 1.25

Please be a bit more careful filing bugs for old versions in future. Without 
the extra annotations I just added, this might have kicked rustc out of testing 
if nobody else was paying attention.

Judging from https://packages.debian.org/sid/fonts-open-sans all that's needed 
to fix this bug is to build and upload fonts-open-sans to jessie. Looks like 
whoever made the jessie upload of rustc failed to check this. Also it's funny 
that jessie contains rustc 1.24 but stretch contains 1.14. I was responsible 
for none of this stuff.

X

Andreas Beckmann:
> Package: rust-doc
> Version: 1.24.1+dfsg1-1~deb8u4
> Severity: serious
> User: debian...@lists.debian.org
> Usertags: piuparts
> 
> Hi,
> 
> during a test with piuparts I noticed your package is not
> installable in jessie:
> 
> The following packages have unmet dependencies:
>  rust-doc : Depends: fonts-open-sans but it is not installable
> E: Unable to correct problems, you have held broken packages.
> 
> 
> Cheers,
> 
> Andreas
> 
> ___
> Pkg-rust-maintainers mailing list
> pkg-rust-maintain...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-rust-maintainers
> 


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

Bug#928422: [Pkg-rust-maintainers] Bug#928422: rust-doc: unsatisfiable Depends: fonts-open-sans in jessie

[Ximin Luo]

Control: tags -1 + jessie
Control: notfound -1 1.32.0+dfsg1-3
Control: notfound -1 1.25.0+dfsg1-1

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

Bug#928441: db5.3 ships an unregistered, embedded copy of sqlite3

[Helmut Grohne]

Source: db5.3
Version: 5.3.28+dfsg1-0.6
Severity: important
Tags: security

I noticed that db5.3 builds an embedded copy of sqlite3, but it isn't
documented in the security tracker. This is troubling. Embedded code
copies are discouraged by the debian policy and sqlite3 has a history of
(few) vulnerabilities with CVEs. Please do one of the following:
A. Stop using the embedded sqlite3 in favour of the packaged one.
   (preferred)
B. Register your copy with the security tracker. Thus security updates
   of sqlite3 can include an upload of db5.3.

A quick glance suggests that A is impossible, because db5.3 uses a
modified copy (see lang/sql/README). If that assessment is correct,
you'll have to update
https://salsa.debian.org/security-tracker-team/security-tracker/raw/master/data/embedded-code-copies
and add a line below "sqlite3" stating:

- db5.3  (modified-embed)

Helmut

Bug#928442: clonezilla: debian-live clonezilla fails to infinate loop while scanning /tmp/ocs_bind_root

[Debian Live user]

Package: clonezilla
Version: 3.27.16-3
Severity: important

Dear Maintainer,

debian-live clonezilla fails to infinate loop while scanning /tmp/ocs_bind_root

reproduce,

boot debian-live-buster-DI-rc1-amd64-kde+nonfree.iso
sudo apt update
sudo apt install clonezilla

sudo clonezilla
>device-image
>local_dev
>Enter
>select drive for image repository
>clonezilla fails to infinate loop

I've tried various versions of the buster live-cd in Virtualbox and bare metal  
with the same results.


-- 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_US.UTF-8, LC_CTYPE=en_US.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

Versions of packages clonezilla depends on:
ii  bc  1.07.1-2+b1
ii  dialog  1.3-20190211-1
ii  drbl2.20.11-7
ii  e2fsprogs   1.44.5-1
ii  fdisk   2.33.1-0.1
ii  file1:5.35-4
ii  gdisk   1.0.3-1.1
ii  pigz2.4-1
ii  util-linux  2.33.1-0.1

Versions of packages clonezilla recommends:
ii  partclone  0.3.11-1+b3
pn  partimage  

Versions of packages clonezilla suggests:
pn  cifs-utils  
ii  openssh-client  1:7.9p1-10
ii  sshfs   2.10+repack-2
pn  udpcast 

-- no debconf information

Bug#928443: zram-tools: add user configurable comp_algorithm in /etc/default/zramswap

[Jari Aalto]

Package: zram-tools
Version: 0.3.2.1-1
Severity: wishlist

Dear Maintainer,

Please add selectable compression algorithm in in
/etc/default/zramswap as Kernel 4.19.0-4-amd64 there are several
choices:

 cat /sys/block/zram0/comp_algorithm
 [lzo] lz4 lz4hc

Note that in sript /usr/sbin/zramswap the "comp_algorithm" must be
set before "disksize" with:

echo ${ALGORITHM:-lzo} > /sys/block/zram${DEVNUMBER}/comp_algorithm

https://www.kernel.org/doc/Documentation/blockdev/zram.txt

-- 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)
Kernel taint flags: TAINT_CRAP
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 zram-tools depends on:
ii  bc  1.07.1-2+b1

zram-tools recommends no packages.

zram-tools suggests no packages.

-- debconf-show failed

Bug#928422: [Pkg-rust-maintainers] Bug#928422: Bug#928422: rust-doc: unsatisfiable Depends: fonts-open-sans in jessie

[Ximin Luo]

Control: fixed -1 1.32.0+dfsg1-3
Control: fixed -1 1.25.0+dfsg1-1

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

Bug#928444: jetty9: CVE-2019-10241 CVE-2019-10247

[Salvatore Bonaccorso]

Source: jetty9
Version: 9.4.15-1
Severity: important
Tags: security upstream fixed-upstream

Hi,

The following vulnerabilities were published for jetty9. Although they
are distinct issues, and one is adressed in 9.4.16 and the other in
4.9.17 I still opted to fill one single bug, assuming the next update
will move to at least 9.4.17.

CVE-2019-10241[0]:
| In Eclipse Jetty version 9.2.26 and older, 9.3.25 and older, and
| 9.4.15 and older, the server is vulnerable to XSS conditions if a
| remote client USES a specially formatted URL against the
| DefaultServlet or ResourceHandler that is configured for showing a
| Listing of directory contents.


CVE-2019-10247[1]:
| In Eclipse Jetty version 7.x, 8.x, 9.2.27 and older, 9.3.26 and older,
| and 9.4.16 and older, the server running on any OS and Jetty version
| combination will reveal the configured fully qualified directory base
| resource location on the output of the 404 error for not finding a
| Context that matches the requested path. The default server behavior
| on jetty-distribution and jetty-home will include at the end of the
| Handler tree a DefaultHandler, which is responsible for reporting this
| 404 error, it presents the various configured contexts as HTML for
| users to click through to. This produced HTML includes output that
| contains the configured fully qualified directory base resource
| location for each context.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-10241
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10241
https://bugs.eclipse.org/bugs/show_bug.cgi?id=546121
[1] https://security-tracker.debian.org/tracker/CVE-2019-10247
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-10247
https://bugs.eclipse.org/bugs/show_bug.cgi?id=546577

Regards,
Salvatore

Bug#928445: unblock: qtchooser/66-2

[Dmitry Shachnev]

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

Dear Release team,

Please unblock package qtchooser. It fixes bug #928344 which is of
severity: important. The debdiff is attached.

unblock qtchooser/66-2

--
Dmitry Shachnev
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+qtchooser (66-2) unstable; urgency=medium
+
+  [ Simon Quigley ]
+  * Change my email to tsimo...@debian.org now that I am a Debian Developer.
+  * Bump Standards-version to 4.3.0, no changes needed.
+
+  [ Dmitry Shachnev ]
+  * Build with large file support (closes: #928344).
+
+ -- Dmitry Shachnev   Fri, 03 May 2019 19:08:24 +0300
+
 qtchooser (66-1) unstable; urgency=medium
 
   [ Simon Quigley ]
--- a/debian/control
+++ b/debian/control
@@ -5,11 +5,11 @@
 Uploaders: Timo Jyrinki ,
Lisandro Damián Nicanor Pérez Meyer ,
Dmitry Shachnev ,
-   Simon Quigley 
+   Simon Quigley 
 Build-Depends: debhelper-compat (= 11),
dpkg-dev (>= 1.17.14),
qtbase5-dev (>= 5.9.2+dfsg-3~) 
-Standards-Version: 4.2.1
+Standards-Version: 4.3.0
 Homepage: https://qt-project.org/
 Vcs-Git: https://salsa.debian.org/qt-kde-team/qt/qtchooser.git
 Vcs-Browser: https://salsa.debian.org/qt-kde-team/qt/qtchooser
--- a/debian/rules
+++ b/debian/rules
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-export DEB_CXXFLAGS_MAINT_APPEND := $(shell dpkg-buildflags --get CPPFLAGS)
+export DEB_CXXFLAGS_MAINT_APPEND := $(shell DEB_BUILD_MAINT_OPTIONS=future=+lfs dpkg-buildflags --get CPPFLAGS)
 export LFLAGS := $(shell dpkg-buildflags --get LDFLAGS)
 
 include /usr/share/dpkg/architecture.mk


signature.asc
Description: PGP signature

Bug#928417: studies disabled in debian

[Tobias Frost]

On Sat, 04 May 2019 14:42:28 -0300 Niv Sardi  wrote:
> mozilla is roling out a fix 
> 
https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/
> that said they are using the 'studies' infrastructure to do so, and 
> they seem to be disabled in the debian build.

In that article there is a link to an add-on that seems to work without
studies:

https://news.ycombinator.com/item?id=19826903

Cheers,

tobi

Bug#928446: ITP: nulib2 -- NuFX and Binary II archive utility

[Stephen Kitt]

Package: wnpp
Severity: wishlist
Owner: Stephen Kitt 

* Package name: nulib2
  Version : 3.1.0
  Upstream Author : Andy McFadden
* URL : http://nulib.com
* License : BSD
  Programming Lang: C
  Description : NuFX and Binary II archive utility

 NuLib2 is a command-line archive utility for NuFX and Binary II
 archives, as commonly used on Apple II systems. It can handle files
 produced by ShrinkIt. Typical extensions for the files it supports
 are SHK, SDK, BXY, BSE, SEA, BNY, and BQY.
 .
 It can preserve file types, handles resource forks, comments, large
 archives, wrappers...

Bug#928447: patman FTCBFS: upstream Makefile hard codes tools

[Helmut Grohne]

Source: patman
Version: 1.2.2+dfsg-5
Tags: patch upstream
User: helm...@debian.org
Usertags: rebootstrap

patman fails to cross build from source, because the upstream Makefile
hard codes g++. It also hard codes "install -s", which breaks generation
of -dbgsym packages and DEB_BUILD_OPTIONS=nostrip in addition to
breaking cross compilation. Making these tools substitutable is enough
to fix all of these. Please consider applying the attached patch.

Helmut
--- patman-1.2.2+dfsg.orig/Makefile
+++ patman-1.2.2+dfsg/Makefile
@@ -9,6 +9,7 @@
 prefix := ${HOME}
 version := 1.2
 
+INSTALL ?= install
 TARGETS := patman
 OBJS := prefix_tree.o fasta.o main.o
 CXXFLAGS += -Wall
@@ -19,16 +20,16 @@
 all: $(TARGETS)
 
 patman:	$(OBJS)
-	g++ $(CXXFLAGS) -o $@ $(OBJS) $(LDFLAGS) $(LDLIBS)
+	$(CXX) $(CXXFLAGS) -o $@ $(OBJS) $(LDFLAGS) $(LDLIBS)
 
 %.o:	%.cpp
-	g++ -DVERSION="\"$(version)\"" $(CPPFLAGS) $(CXXFLAGS) -c -o $@ $<
+	$(CXX) -DVERSION="\"$(version)\"" $(CPPFLAGS) $(CXXFLAGS) -c -o $@ $<
 
 install: $(TARGETS)
-	install -d ${prefix}/bin
-	install -d ${prefix}/share/man/man1
-	install -s -m755 $^ ${prefix}/bin
-	install -m644 patman.1 ${prefix}/share/man/man1
+	$(INSTALL) -d ${prefix}/bin
+	$(INSTALL) -d ${prefix}/share/man/man1
+	$(INSTALL) -s -m755 $^ ${prefix}/bin
+	$(INSTALL) -m644 patman.1 ${prefix}/share/man/man1
 	
 fasta.o: fasta.h 
 prefix_tree.o: prefix_tree.h global.h

Bug#928417: Temporary fix: set xpinstall.signatures.required to false

[Felicia P]

An immediate fix is to set xpinstall.signatures.required to false in
about:config



0xCEC1B8C7E51FC983.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature

Bug#927888: Need to disable the devicetree command in Secure Boot mode

[Colin Watson]

On Fri, May 03, 2019 at 10:42:34PM +0100, Steve McIntyre wrote:
> diff --git a/grub-core/loader/efi/fdt.c b/grub-core/loader/efi/fdt.c
> index c9aee74ef..735c56e45 100644
> --- a/grub-core/loader/efi/fdt.c
> +++ b/grub-core/loader/efi/fdt.c
> @@ -123,6 +123,14 @@ grub_cmd_devicetree (grub_command_t cmd __attribute__ 
> ((unused)),
>return GRUB_ERR_NONE;
>  }
>  
> +#ifdef GRUB_MACHINE_EFI
> +  if (grub_efi_secure_boot ())
> +{
> +  return grub_error (GRUB_ERR_ACCESS_DENIED,
> +   "Secure Boot forbids loading devicetree from %s", argv[0]);
> +}
> +#endif
> +
>dtb = grub_file_open (argv[0]);
>if (!dtb)
>  goto out;

Thanks.  I've applied this and the rest of the patch as-is, but I'm
pretty sure that the #ifdef in this file is rather unnecessary - unlike
grub-core/loader/arm/linux.c, grub-core/loader/efi/fdt.c should only be
compiled if GRUB_MACHINE_EFI is defined.

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

Bug#922659: Workaround

[Tatsuya Kinoshita]

On March 4, 2019 at 11:25PM +, Peter.Chubb (at data61.csiro.au) wrote:
> I rebuilt emacs without the in-built GNUTLS --- and everything now
> works properly.
> 
> I added the line:
> confflags += --without-gnutls
> to debian/rules and rebuilt.

Rebuilding the emacs package may be unneeded.

Emacs 26's in-built gnutls.el with TLS 1.3 seems buggy.
cf. https://lists.gnu.org/archive/html/help-gnu-emacs/2019-02/msg00144.html
https://lists.gnu.org/archive/html/emacs-devel/2019-02/msg00393.html

So, adding "-VERS-TLS1.3" to gnutls-algorithm-priority might
prevent the problem.

(setq gnutls-verify-error t)
(setq gnutls-min-prime-bits 1024)
(setq gnutls-algorithm-priority "SECURE128:-VERS-SSL3.0:-VERS-TLS1.3")

For Wanderlust (>= 2018-03-31), to use tls.el instead of gnutls.el
anyway, set elmo-network-use-gnutls to nil.

(setq elmo-network-use-gnutls nil)
(setq tls-checktrust t)
(setq tls-program '("gnutls-cli --x509cafile 
/etc/ssl/certs/ca-certificates.crt --priority SECURE128:-VERS-SSL3.0 -p %p %h"))

Thanks,
-- 
Tatsuya Kinoshita

Bug#928448: unblock: mmdebstrap/0.4.1-3

[Johannes 'josch' Schauer]

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

Hello release team!

I'm here to talk about an eventual unblock request of my package
mmdebstrap. In this context I want to discuss with you, which changes
will still be permitted at this time of the freeze. It is very unlikely
that any of these changes will break anything because mmdebstrap is
intensively tested in 91 different scenarios, exercising all reasonably
testable code-paths according to the Devel::Cover Perl module.

If these patches cannot be part of the initial Buster release, they
should definitely go into the next point release.

I would not say that any of these are of RC severity but they they are
not less than important severity either. Each of these fixes is targeted
and minimal and does not break any interfaces.

mmdebstrap has no reverse-Depends (but some reverse-Recommends).

I find especially support for old apt versions and derivative
distributions important. If you tell me to go ahead, then I would need:

unblock mmdebstrap/0.4.1-3

All the patches I list in the following are attached to this mail as
part of a debdiff where I applied all of them.

1. 0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch

This closes #927151. The workaround is a manual rm of the auxfiles
directory. This problem only occurs when producing a Debian chroot with
an apt version before the auxfiles directory existed.

2. 0002-chdir-before-apt-get-update-to-accomodate-for-apt-1..patch

Another fix is for apt (<< 1.5) which will attempt to chdir() after an
"apt update" which might fail if that directory is not readable by the
user running apt (apt bug #860738). The workaround is to start
mmdebstrap from a world readable directory.

3. 0003-add-Dir-State-Status-to-apt-config-for-apt-1.3.patch

For apt apt (<< 1.3) it is necessary to explicitly set the
Dir::State::Status or otherwise, the dpkg status database outside the
chroot will be used. There exists no equivalent workaround.

4. 0004-chmod-0755-on-qemu-user-static-binary.patch

On Ubuntu, the binfmt mechanism seems to require that interpreters are
marked executable. This requirement does not seem to exist on Debian
which is why the executable bit was originally not set for the
qemu-user-static binary. There is no workaround.

5. 0005-chdir-to-parent-of-root-before-remove_tree-to-preven.patch

This is similar to (2.) because the function remove_tree of the perl
module File::Path also attempts to chdir to the current directory before
removing a completely different directory. This chdir will fail if the
current directory is not readable by the user running the function. The
workaround is to start mmdebstrap from a world readable directory.

6. 0006-Only-error-out-on-W-and-Err-lines-on-apt-get-update.patch

This closes #928079. Instead of using exit codes, apt communicates
failure using "W:" and "Err:" lines on standard output (apt bugs
#778357, #776152, #696335 and #745735). But sometimes, maintainer
scripts also emit non-fatal "W:" lines. The workaround is to install the
affected packages after mmdebstrap finished manually.
diff -Nru mmdebstrap-0.4.1/debian/changelog mmdebstrap-0.4.1/debian/changelog
--- mmdebstrap-0.4.1/debian/changelog   2019-03-18 14:46:01.0 +0100
+++ mmdebstrap-0.4.1/debian/changelog   2019-05-04 23:48:19.0 +0200
@@ -1,3 +1,15 @@
+mmdebstrap (0.4.1-3) unstable; urgency=medium
+
+  * Backport patches from upstream:
+ - cleanup auxfiles *after* running apt-get update (closes: #927151)
+ - chdir() before 'apt-get update' for apt (<< 1.5)
+ - chdir() before remove_tree()
+ - add Dir::State::Status to apt config for apt (<< 1.3)
+ - chmod 0755 on qemu-user-static binary for Ubuntu
+ - Only error out on W: and Err: lines (closes: #928079)
+
+ -- Johannes 'josch' Schauer   Sat, 04 May 2019 23:48:19 
+0200
+
 mmdebstrap (0.4.1-2) unstable; urgency=medium
 
   * Mark autopkgtest as flaky (closes: #924854)
diff -Nru 
mmdebstrap-0.4.1/debian/patches/0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch
 
mmdebstrap-0.4.1/debian/patches/0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch
--- 
mmdebstrap-0.4.1/debian/patches/0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch
 1970-01-01 01:00:00.0 +0100
+++ 
mmdebstrap-0.4.1/debian/patches/0001-cleanup-auxfiles-after-running-apt-get-update-or-oth.patch
 2019-05-04 23:44:01.0 +0200
@@ -0,0 +1,49 @@
+From b2d5a45932a303a65baa4ec5081c5fa1f4fa80a5 Mon Sep 17 00:00:00 2001
+From: Johannes 'josch' Schauer 
+Date: Tue, 23 Apr 2019 13:28:55 +0200
+Subject: [PATCH 1/6] cleanup auxfiles *after* running apt-get update or
+ otherwise it will be re-created
+
+---
+ coverage.sh |  2 --
+ mmdebstrap  | 12 ++--
+ 2 files changed, 6 insertions(+), 8 deletions(-)
+
+--- a/coverage.sh
 b/coverage.sh
+@@ -155,8 +155,6 @@ grep -v '^Priority: ' /tmp/debian-$dist-
+ diff -u status1 status2
+ rm

Bug#927888: Need to disable the devicetree command in Secure Boot mode

[Steve McIntyre]

On Sat, May 04, 2019 at 10:44:26PM +0100, Colin Watson wrote:
>On Fri, May 03, 2019 at 10:42:34PM +0100, Steve McIntyre wrote:
>> diff --git a/grub-core/loader/efi/fdt.c b/grub-core/loader/efi/fdt.c
>> index c9aee74ef..735c56e45 100644
>> --- a/grub-core/loader/efi/fdt.c
>> +++ b/grub-core/loader/efi/fdt.c
>> @@ -123,6 +123,14 @@ grub_cmd_devicetree (grub_command_t cmd __attribute__ 
>> ((unused)),
>>return GRUB_ERR_NONE;
>>  }
>>  
>> +#ifdef GRUB_MACHINE_EFI
>> +  if (grub_efi_secure_boot ())
>> +{
>> +  return grub_error (GRUB_ERR_ACCESS_DENIED,
>> +  "Secure Boot forbids loading devicetree from %s", argv[0]);
>> +}
>> +#endif
>> +
>>dtb = grub_file_open (argv[0]);
>>if (!dtb)
>>  goto out;
>
>Thanks.  I've applied this and the rest of the patch as-is, but I'm
>pretty sure that the #ifdef in this file is rather unnecessary - unlike
>grub-core/loader/arm/linux.c, grub-core/loader/efi/fdt.c should only be
>compiled if GRUB_MACHINE_EFI is defined.

True. Ah well. :-)

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
Can't keep my eyes from the circling sky,
Tongue-tied & twisted, Just an earth-bound misfit, I...

Bug#928415: armagadd-on-2.0

[Ángel]

Changing "xpinstall.signatures.required" to "false" will work on builds
without MOZ_REQUIRE_SIGNING.
This can be checking by going to resource://gre/modules/AppConstants.jsm
and checking the value of MOZ_REQUIRE_SIGNING, if it is false, the
signatures can be disabled with the above config.

Note it will not work on official mozilla builds. But it does on
Debian.¹


There were a couple of upstream commits for working around the bug:
https://hg.mozilla.org/releases/mozilla-beta/rev/d716b75b8ac3f4588061e720074c093dae08e43e
https://hg.mozilla.org/releases/mozilla-beta/rev/f272348572e8160a73001b85013f35db51397064

although they later reverted them.



The studies released by mozilla to fix this are:

* hotfix-update-xpi-signing-intermediate-bug-1548973:
https://storage.googleapis.com/moz-fx-normandy-prod-addons/extensions/hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi
(sha256 b25031ac78020aad3be1fb8144cacbcf4a9b2d866585f066a577c10b835cd800, it's 
signed by mozilla like other xpis)

* hotfix-reset-xpi-verification-timestamp-1548973
seems to be just a preference change for 
app.update.lastUpdateTime.xpi-signature-verification (in order to trigger a xpi 
recheck):
  "hotfix-reset-xpi-verification-timestamp-1548973": {
"name": "hotfix-reset-xpi-verification-timestamp-1548973",
"branch": "hotfix",
"expired": false,
"lastSeen": "2019-05-04T21:13:01.960Z",
"preferenceName":
"app.update.lastUpdateTime.xpi-signature-verification",
"preferenceValue": 1556945257,
"preferenceType": "integer",
"previousPreferenceValue": 0,
"preferenceBranchType": "user",
"experimentType": "exp"
  },



Installing hotfix-update-xpi-intermediate%40mozilla.com-1.0.2-signed.xpi
manually also makes extension work on Debian.
Disabled addons don't get reenabled, but resetting app.update.lastUpdateTime
.xpi-signature-verification to an older value also makes them work again a 
little after restart.




¹ Also on Ubuntu, and probably on the rest of distros using a derivative
package as well.

Bug#928415: tagging 928417

[Bill Allombert]

On Sat, May 04, 2019 at 08:54:27AM +0200, Salvatore Bonaccorso wrote:
> tags 928417 - security

The fact that this bug allows Mozilla to disable remotely security
extensions like noscript is a major security issue.

When noscript get deactivated, firefox should default to disabling
javascript completly rather than enabling it without restriction.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#928449: firefox-esr: Add-ons fail to install probably due to upstream certificate issue

[Matthew Toseland]

Package: firefox-esr
Version: 60.6.1esr-1
Severity: normal
Tags: upstream

Dear Maintainer,

Reinstalling add-ons is broken in Firefox. This appears to be an
upstream bug:
https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047

What I did:
- NoScript was installed. Broken due to recent policy changes requiring
  a newer version, attempt to reinstall.
- Reinstalling consistently fails claiming the plugin is corrupt.
- Googling shows it is likely to be the above bug.

I have reproduced this with my AppArmor rules turned off so that is not
the problem.

-- Package-specific info:


-- Addons package information

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/8 CPU cores)
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 /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.6.1
ii  fontconfig2.13.1-2
ii  libasound21.1.8-1
ii  libatk1.0-0   2.30.0-2
ii  libc6 2.28-8
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.12-1
ii  libdbus-glib-1-2  0.110-4
ii  libevent-2.1-62.1.8-stable-4
ii  libffi6   3.2.1-9
ii  libfontconfig12.13.1-2
ii  libfreetype6  2.9.1-3
ii  libgcc1   1:8.3.0-6
ii  libgdk-pixbuf2.0-02.38.1+dfsg-1
ii  libglib2.0-0  2.58.3-1
ii  libgtk-3-03.24.5-1
ii  libhunspell-1.7-0 1.7.0-2
ii  libjsoncpp1   1.7.4-3
ii  libnspr4  2:4.20-1
ii  libnss3   2:3.42.1-1
ii  libpango-1.0-01.42.4-6
ii  libsqlite3-0  3.27.2-2
ii  libstartup-notification0  0.12-6
ii  libstdc++68.3.0-6
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libx11-xcb1   2:1.6.7-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-3+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.1.1-1

Versions of packages firefox-esr suggests:
pn  fonts-lmodern  
pn  fonts-stix | otf-stix  
ii  libcanberra0   0.30-7
ii  libgssapi-krb5-2   1.17-2
ii  libgtk2.0-02.24.32-3
ii  pulseaudio 12.2-4

-- no debconf information

Bug#928449: firefox-esr: Add-ons fail to install probably due to upstream certificate issue

[Matthew Toseland]

Just to confirm, this does happen on a clean account, with AppArmor set 
to complain only for /usr/bin/firefox and 
/usr/lib/firefox-esr/firefox-esr. Any add-on fails to install; I've 
tried NoScript (one of the most popular ones), and To Google Translate 
(was on the home page).


So I assume it's the upstream issue.

On 04/05/2019 23:35, Matthew Toseland wrote:

Package: firefox-esr
Version: 60.6.1esr-1
Severity: normal
Tags: upstream

Dear Maintainer,

Reinstalling add-ons is broken in Firefox. This appears to be an
upstream bug:
https://discourse.mozilla.org/t/certificate-issue-causing-add-ons-to-be-disabled-or-fail-to-install/39047

What I did:
- NoScript was installed. Broken due to recent policy changes requiring
   a newer version, attempt to reinstall.
- Reinstalling consistently fails claiming the plugin is corrupt.
- Googling shows it is likely to be the above bug.

I have reproduced this with my AppArmor rules turned off so that is not
the problem.

Bug#407722: RE,

[Zeynep Aydin Demirkiran]

Hello I have been trying to contact you. Did you get my business proposal?

Bug#928415: disabling javascript

[Brad Barnett]

While I agree an unknown disabling of plugins, not just noscript (there
are others like noscript) is a security concern...

There is a big, yellow banner that appears and stays at the top of your
browser, informing you if any plugins/add-ons are disabled.

So for me, the 'big deal' is being informed.  Then the user can, at that
point, disable javascript manually if required.

After all, is noscript "special" in some way?  More special than another
add-on for blocking javascript?

Bug#928415: firefox-esr: All extensions are disabled

[Hartmut Buhrmester]

Hello,

I found a workaround for firefox-esr 60.6.1esr-1~deb9u1 from Debian 9.9 
Stretch/stable, and uBlock origin 1.18.16 from 
https://addons.mozilla.org (AMO).


When uBlock origin was suddenly disabled today, I first changed this 
setting on the configuration page about:config :


xpinstall.signatures.required = false

This did not immediately solve the problem: I got the warning "proceed 
with care", but the extension was still disabled, and there was no way 
to enable it again.


Then I also changed the settings:

app.shield.optoutstudies.enabled = true
app.normandy.run_interval_seconds = 5

The first option enables "studies", which are used to distribute the 
patch from Mozilla. On the Preferences page, the option "Allow Firefox 
to install and run studies" is now checked, although the user interface 
is still locked down. This setting also likes to disable itself on each 
restart. But if it is enabled on the page about:config, then it actually 
works until the next restart.


The setting app.normandy.run_interval_seconds determines, how often 
"studies" are updated. The default value is 86400 seconds = 24 hours, 
which is far too long for testing. I set it to 5 seconds, waited that 
long and reloaded the Add-ons page. Surely I found a new extension 
"hotfix-update-xpi-intermediate 1.0.2".


For some reason, uBlock origin was still disabled. I then toggled the 
setting xpinstall.signatures.required on and off, and reloaded the 
Add-ons page in-between. Then, at some point, uBlock origin was enabled 
again and working as before.


So I think, that the setting xpinstall.signatures.required = false is 
not really needed.


Enabling "studies" and using a short update interval of 5 seconds should 
do the trick.


Regards,
Hartmut Buhrmester

Bug#919621: lvm2: Update unexpectedly activates system ID check, bypassing impossible

[Colin Watson]

On Sat, May 04, 2019 at 06:59:22PM +0100, Colin Watson wrote:
> On Fri, Jan 18, 2019 at 03:16:26AM +0100, Andreas Bombe wrote:
> > This has worked for all these years until the update, which rejects the
> > VG with system ID without advance warning during package upgrade. Systems
> > may become unbootable after upgrade if these VGs contain filesystems
> > that are mounted in /etc/fstab.
> [...]
> > The only way to get access was to set global/system_id_source =
> > "lvmlocal" and set local/system_id to the affected VG's system ID.
> 
> I also ran into this on upgrading from stretch to buster.  Fortunately I
> was keeping enough of an eye on console output from the upgrade that I
> was able to find this bug and I worked around it as you describe here.

In case it's useful information to anyone, since the system ID appears
to contain a seconds-since-epoch value, I can deduce that I created the
VG on 2004-05-18, which makes sense given the sorts of things I was
doing at the time.  I would have been running either woody or the
current state of sarge in development at the time.

I added the VG to an existing system rather than installing a new one,
so the installer wasn't involved.  I suppose it's technically possible
that I set the system ID myself, but it's in the form
 which I don't *think* is a
format I would have used as my first pick (I'm sure I'd at least have
included some kind of separator); it seems much more likely that it was
the default for vgcreate at the time, although I haven't yet found
anything relevant in any changelogs.  I have a VG elsewhere created in
early 2013 that doesn't have a system ID, and friends report similar
things back as far as squeeze, so I guess that narrows it down a bit.

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

Bug#928450: RFS: megadown/0~20190502+git734e46f-1 [RC]

[Lev Lazinskiy]

Package: sponsorship-requests
  Severity: important

  Dear mentors,

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

 * Package name: megadown
   Version : 0~20190502+git734e46f-1
   Upstream Author : [fill in name and email of upstream]
 * URL : [fill in URL of upstream's web site]
 * License : [fill in]
   Section : misc

  It builds those binary packages:

megadown - Script for downloading files from mega.nz and megacrypter

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

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


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

dget -x 
https://mentors.debian.net/debian/pool/main/m/megadown/megadown_0~20190502+git734e46f-1.dsc

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

  Changes since the last upload:

  * New upstream release (Closes: #927462) which is an RC bug. 
  * Remove patch series. Upstream swapped out python for jq. Python is no longer
required
  * Add jq as dependency

--
Lev Lazinskiy
https://levlaz.org

e: l...@levlaz.org


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

Bug#928404: unblock: glibc/2.28-10

[Cyril Brulebois]

Hi,

Aurelien Jarno  (2019-05-03):
> The glibc package in version 2.28-10 currently in sid mostly updates the
> git-updates.diff patch to the latest upstream stable branch:
> - Fix security issue CVE-2019-9169.
> - Support for the new Reiwa era to the ja_JP which seems to be something
>   quite important for Japanese people. 
>   provide shared libraries (not) tuned for the corresponding platforms.
> - Fix for an infinite loop in the pldd binary, which makes it unusable
>   (regression from stretch).
> - Support for vector instructions related hwcap on s390x to allow one to
> - Fix for a riscv specific issue in a file which is not used on other
>   architectures, so with no risk for them.
> 
> In addition to that it includes a fix for a bug in dlopen introduced by
> an arm patch, but affecting all architectures.
> 
> I believe that all the above changes are suitable for buster. If you
> agree, could you please unblock package glibc:
> 
> unblock glibc/2.28-10

All tests look good, no objections.


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#916180: RFA: sketch -- 3D diagrams for TeX from scene description language

[Benedikt Häusele]

Hello,

I am basically interested in taking over the maintenance of the sketch package 
(in the long run).
However, I have to admit that I have not used the package myself up to now, 
still, it might be become quite useful for the upcoming downwriting of my 
thesis.
Nor I have ever done packaging for Debian before (as my currrent software 
project is way to specific to be included in any linux distribution).
So, I would suggest, that first, I will have a closer look at the code and try 
compiling packaging it on my own.
Is the code from souceforge the last version from the original author?

https://sourceforge.net/p/sketch4latex/wiki/Home/

Best wishes, Benedikt

--
Benedikt Häusele
PhD student
University of Konstanz
Physical Chemistry
Universitätsstraße 10 L1051
D-78457 Konstanz
Tel +49 (0) 7531 88-4808

Bug#916180: RFA: sketch -- 3D diagrams for TeX from scene description language

[Benedikt Häusele]

Hello,

I am basically interested in taking over the maintenance of the sketch 
package (in the long run).
However, I have to admit that I have not used the package myself up to 
now, still, it might be become quite useful for the upcoming downwriting 
of my thesis.
Nor I have ever done packaging for Debian before (as my currrent 
software project is way to specific to be included in any linux 
distribution).
So, I would suggest, that first, I will have a closer look at the code 
and try compiling packaging it on my own.

Is the code from souceforge the last version from the original author?

https://sourceforge.net/p/sketch4latex/wiki/Home/

Best wishes, Benedikt

--
Benedikt Häusele
PhD student
University of Konstanz
Physical Chemistry
Universitätsstraße 10 L1051
D-78457 Konstanz
Tel +49 (0) 7531 88-4808

Bug#923826: python-blessed: FTBFS randomly (failing tests)

[Pierre-Elliott Bécue]

Le mardi 05 mars 2019 à 19:09:54+, Santiago Vila a écrit :
> Package: src:python-blessed
> Version: 1.15.0-1
> Severity: important
> Tags: ftbfs
> 
> Dear maintainer:
> 
> I tried to build this package in buster but it failed:
> 
> 
> [...]
>  debian/rules binary-indep
> dh binary-indep --with python2,python3 --buildsystem=pybuild
>dh_update_autotools_config -i -O--buildsystem=pybuild
>dh_autoreconf -i -O--buildsystem=pybuild
>dh_auto_configure -i -O--buildsystem=pybuild
> I: pybuild base:217: python2.7 setup.py config 
> running config
> I: pybuild base:217: python3.7 setup.py config 
> running config
>dh_auto_build -i -O--buildsystem=pybuild
> I: pybuild base:217: /usr/bin/python setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython2_2.7_blessed/build/blessed
> copying blessed/terminal.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed
> copying blessed/keyboard.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed
> copying blessed/sequences.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed
> copying blessed/__init__.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed
> copying blessed/formatters.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed
> copying blessed/_capabilities.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed
> creating /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> copying blessed/tests/test_core.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> copying blessed/tests/accessories.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> copying blessed/tests/test_wrap.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> copying blessed/tests/__init__.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> copying blessed/tests/test_length_sequence.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> copying blessed/tests/test_formatters.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> copying blessed/tests/test_keyboard.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> copying blessed/tests/test_sequences.py -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> running egg_info
> writing requirements to blessed.egg-info/requires.txt
> writing blessed.egg-info/PKG-INFO
> writing top-level names to blessed.egg-info/top_level.txt
> writing dependency_links to blessed.egg-info/dependency_links.txt
> reading manifest file 'blessed.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> writing manifest file 'blessed.egg-info/SOURCES.txt'
> copying blessed/tests/wall.ans -> 
> /<>/.pybuild/cpython2_2.7_blessed/build/blessed/tests
> I: pybuild base:217: /usr/bin/python3 setup.py build 
> running build
> running build_py
> creating /<>/.pybuild/cpython3_3.7_blessed/build/blessed
> copying blessed/terminal.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed
> copying blessed/keyboard.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed
> copying blessed/sequences.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed
> copying blessed/__init__.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed
> copying blessed/formatters.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed
> copying blessed/_capabilities.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed
> creating /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
> copying blessed/tests/test_core.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
> copying blessed/tests/accessories.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
> copying blessed/tests/test_wrap.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
> copying blessed/tests/__init__.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
> copying blessed/tests/test_length_sequence.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
> copying blessed/tests/test_formatters.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
> copying blessed/tests/test_keyboard.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
> copying blessed/tests/test_sequences.py -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
> running egg_info
> writing blessed.egg-info/PKG-INFO
> writing dependency_links to blessed.egg-info/dependency_links.txt
> writing requirements to blessed.egg-info/requires.txt
> writing top-level names to blessed.egg-info/top_level.txt
> reading manifest file 'blessed.egg-info/SOURCES.txt'
> reading manifest template 'MANIFEST.in'
> writing manifest file 'blessed.egg-info/SOURCES.txt'
> copying blessed/tests/wall.ans -> 
> /<>/.pybuild/cpython3_3.7_blessed/build/blessed/tests
>dh_auto_test -i -O--buildsystem=pybuild
> I: pybuild base:217: cd /<>/.pybuild/cpython2_2.7_blessed/build; 
> python2.7 -m pytest 
> = test session starts 
> =

Bug#928415: firefox-esr: All extensions are disabled

[Teddy Hogeborn]

Hartmut Buhrmester  wrote:

> So I think, that the setting xpinstall.signatures.required = false is
> not really needed.
> 
> Enabling "studies" and using a short update interval of 5 seconds
> should do the trick.

I think the opposite is true.

I had xpinstall.signatures.required set to false before the certificate
expired, and no extensions were or are disabled for me.  The only effect
is the display of the text "[Extension] could not be verified for use in
Firefox.  Proceed with caution." displayed for every single extension in
the add-on page, and that was only after I had prodded it by clicking
"Check for updates".

My settings for app.shield.optoutstudies.enabled and
app.normandy.run_interval_seconds are the default values (false and
86400, respectively).

Do you have any information indicating that the "studies" can be
activated in any way in the Debian version of Firefox?  I tend to
believe the Preferences page text (right where the studies checkbox is
disabled): "Data reporting is disabled for this build configuration".
That is, the Debian version is compiled without this available.  Do you
have any reason to believe this to be false?

Your observed behavior could easily be explained by the fact that
Firefox doesn't check the signatures immediately, and it might have
happened to check them just as you were altering the "studies" settings,
which themselves did nothing.

My installed version is:

Package: firefox-esr
Version: 60.6.1esr-1~deb9u1

/Teddy Hogeborn

Bug#926547: insserv: tests/run-tests are not used

[Jesse Smith]

I went through the test suite and identified places where either the
test suite was probably out of date (or working with old documentation)
or insserv was giving improper results. Most of the test cases which
were failing can, I believe, be addressed by warnings rather than
outright failures or blocking. A missing virtually facility, for
example, could be provided by another script and results in a warning
rather than insserv refusing to add the script to a runlevel. I feel
this is the more kind approach.

The end result is running "make check" in the insserv source tree now
runs the test suite. If everything goes well (which is does on my
machine) the check completes successfully and prints a summary. If an
error is encountered, the test suite should bomb out with a warning and
leave the test data intact so it can be reviewed. (In the past test data
was erased, making it harder to investigate.)

The test suite now works with insserv's new output directory location
(/var/lib/insserv) so that's good news.

Running "make distclean" cleans up any test data.

I think this bug can probably be marked as fixed upstream. I hope to
publish a new beta around the end of May and a new stable release of
insserv in June. With that release of insserv-1.20.0 we should be able
to properly close this bug.

- Jesse

Bug#928451: linux: riscv64 updates (change kernel image type to flat image and enable vdso)

[Karsten Merker]

Source: linux
Version: 5.0.10-1~exp1
Severity: wishlist
Tags: patch

Hello,

the riscv64 architecture is changing its standard kernel image
format from ELF to a flat kernel image with a PE/COFF-compatible
header (similar to arm64) to make EFI stub support possible, so
we need to ship arch/riscv/boot/Image instead of an ELF vmlinux. 
This also enables us to get rid of BBL (the RISC-V Berkeley
BootLoader) and make the move to U-Boot/GRUB on riscv64.

With kernel 5.0 we can now also enable the vdso config option in
the package for riscv64 as the necessary infrastructure is now in
the upstream kernel (this wasn't the case when riscv64 support
was originally added to the Debian kernel package).

Attached are two corresponding patches; alternatively they are
available as a merge request on salsa at

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

The changes have been successfully tested on a qemu riscv64
"virt" system with OpenSBI and U-Boot.

Regards,
Karsten

Bootlog with the patches applied:
=

OpenSBI v0.3 (May  4 2019 20:32:00)
   _  _
  / __ \  / |  _ \_   _|
 | |  | |_ __   ___ _ __ | (___ | |_) || |
 | |  | | '_ \ / _ \ '_ \ \___ \|  _ < | |
 | |__| | |_) |  __/ | | |) | |_) || |_
  \/| .__/ \___|_| |_|_/|/_|
| |
|_|

Platform Name  : QEMU Virt Machine
Platform HART Features : RV64ACDFIMSU
Platform Max HARTs : 8
Current Hart   : 0
Firmware Base  : 0x8000
Firmware Size  : 100 KB
Runtime SBI Version: 0.1

PMP0: 0x8000-0x8001 (A)
PMP1: 0x-0x (A,R,W,X)


U-Boot 2019.07-rc1-1-g6b6a8d27ea-dirty (May 05 2019 - 01:05:15 +0200)

CPU:   rv64imafdcsu
Model: riscv-virtio,qemu
DRAM:  8 GiB
In:uart@1000
Out:   uart@1000
Err:   uart@1000
Net:   
Warning: virtio-net#2 using MAC address from ROM
eth0: virtio-net#2
Hit any key to stop autoboot:  0 

Device 0: QEMU VirtIO Block Device
Type: Hard Disk
Capacity: 204800.0 MB = 200.0 GB (419430400 x 512)
... is now current device
Scanning virtio 0:1...
Found U-Boot script /boot/boot.scr
281 bytes read in 1 ms (274.4 KiB/s)
## Executing script at 8210
9073676 bytes read in 3 ms (2.8 GiB/s)
45823535 bytes read in 13 ms (3.3 GiB/s)
## Flattened Device Tree blob at ff77bd30
   Booting using the fdt blob at 0xff77bd30
   Using Device Tree in place at ff77bd30, end ff77fda5

Starting kernel ...

[0.00] OF: fdt: Ignoring memory range 0x8000 - 0x8020
[0.00] No DTB passed to the kernel
[0.00] Linux version 5.0.0-trunk-riscv64 
(debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP 
Debian 5.0.10-1~exp1 (2019-03-22)
[0.00] Initial ramdisk at: 0x(ptrval) (45823535 bytes)
[0.00] Zone ranges:
[0.00]   DMA32[mem 0x8020-0x]
[0.00]   Normal   [mem 0x0001-0x00027fff]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x8020-0x00027fff]
[0.00] Initmem setup node 0 [mem 0x8020-0x00027fff]
[0.00] software IO TLB: mapped [mem 0xfb77b000-0xff77b000] (64MB)
[0.00] elf_hwcap is 0x112d
[0.00] percpu: Embedded 19 pages/cpu s39192 r8192 d30440 u77824
[0.00] Built 1 zonelists, mobility grouping on.  Total pages: 2063880
[0.00] Kernel command line: console=ttyS0 rw root=/dev/vda1
[0.00] Dentry cache hash table entries: 1048576 (order: 11, 8388608 
bytes)
[0.00] Inode-cache hash table entries: 524288 (order: 10, 4194304 bytes)
[0.00] Sorting __ex_table...
[0.00] Memory: 8123324K/8386560K available (5111K kernel code, 649K 
rwdata, 1688K rodata, 454K init, 938K bss, 263236K reserved, 0K cma-reserved)
[0.00] random: get_random_u64 called from 
__kmem_cache_create+0x46/0x556 with crng_init=0
[0.00] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=4, Nodes=1
[0.00] ftrace: allocating 21448 entries in 84 pages
[0.00] rcu: Hierarchical RCU implementation.
[0.00] rcu: RCU restricting CPUs from NR_CPUS=8 to nr_cpu_ids=4.
[0.00] rcu: RCU calculated value of scheduler-enlistment delay is 25 
jiffies.
[0.00] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[0.00] NR_IRQS: 0, nr_irqs: 0, preallocated irqs: 0
[0.00] plic: mapped 53 interrupts to 4 (out of 8) handlers.
[0.00] clocksource: riscv_clocksource: mask: 0x 
max_cycles: 0x24e6a1710, max_idle_ns: 440795202120 ns
[0.000153] sched_clock: 64 bits at 10MHz, resolution 100ns, wraps every 
4398046511100ns
[0.004429] Console: colour dummy device 80x25
[0.008666] Calibrating delay loop (skipped), value calculated using t

Bug#928452: POST-as-GET support needed in Buster

[Harlan Lieberman-Berg]

Source: python-certbot
Version: 0.31.0-1
Severity: serious
Tags: upstream

Because of changes to the ACME v2 standard, unauthenticated GET
requests to ACME compatible APIs must be performed as special
POST-as-GET requests to be valid.  The primary ACME API, Let's
Encrypt, has deprecated support for unauthenticated GET requests as of
October 2018, and plans on removing support for them entirely on
November 1, 2019.

To prevent the version being frozen into buster from becoming RC-buggy
on November 1, a backport is being prepared to add this functionality
before buster is released in coordination with upstream.

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

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

Bug#928453: unblock: python-acme/0.31.0-2

[Harlan Lieberman-Berg]

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

Please unblock package python-acme to fix RC bug #928452.

Because of changes to the ACME v2 standard, unauthenticated GET
requests to ACME compatible APIs must be performed as special
POST-as-GET requests to be valid.  The primary ACME API, Let's
Encrypt, has deprecated support for unauthenticated GET requests as of
October 2018, and plans on removing support for them entirely on
November 1, 2019.

To prevent the version being frozen into buster from becoming RC-buggy
on November 1, a backport is being prepared to add this functionality
before buster is released in coordination with upstream.

Debdiff is attached.

unblock python-acme/0.31.0-2

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
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
diff -Nru python-acme-0.31.0/debian/changelog 
python-acme-0.31.0/debian/changelog
--- python-acme-0.31.0/debian/changelog 2019-02-09 19:07:59.0 -0500
+++ python-acme-0.31.0/debian/changelog 2019-05-04 21:32:00.0 -0400
@@ -1,3 +1,9 @@
+python-acme (0.31.0-2) unstable; urgency=medium
+
+  * Backport POST-as-GET support (Closes: #928452)
+
+ -- Harlan Lieberman-Berg   Sat, 04 May 2019 21:32:00 
-0400
+
 python-acme (0.31.0-1) unstable; urgency=medium
 
   * Bump dependency on josepy to >= 1.1.0
diff -Nru python-acme-0.31.0/debian/patches/0001-post-as-get.patch 
python-acme-0.31.0/debian/patches/0001-post-as-get.patch
--- python-acme-0.31.0/debian/patches/0001-post-as-get.patch1969-12-31 
19:00:00.0 -0500
+++ python-acme-0.31.0/debian/patches/0001-post-as-get.patch2019-05-04 
21:32:00.0 -0400
@@ -0,0 +1,66 @@
+From b0d960f102c998d8231c0ee48952b488f10864ac Mon Sep 17 00:00:00 2001
+From: Adrien Ferrand 
+Date: Wed, 1 May 2019 00:37:23 +0200
+Subject: [PATCH] Send a POST-as-GET request to query registration in ACME v2
+ (#6993)
+
+* Send a post-as-get request to query registration
+
+* Add comments. Add again a line.
+
+* Prepare code for future PR about post-as-get
+---
+diff --git a/acme/client.py b/acme/client.py
+index a41787756f..5a8fd88ae9 100644
+--- a/acme/client.py
 b/acme/client.py
+@@ -123,15 +123,6 @@ def deactivate_registration(self, regr):
+ """
+ return self.update_registration(regr, update={'status': 
'deactivated'})
+
+-def query_registration(self, regr):
+-"""Query server about registration.
+-
+-:param messages.RegistrationResource: Existing Registration
+-Resource.
+-
+-"""
+-return self._send_recv_regr(regr, messages.UpdateRegistration())
+-
+ def _authzr_from_response(self, response, identifier=None, uri=None):
+ authzr = messages.AuthorizationResource(
+ body=messages.Authorization.from_json(response.json()),
+@@ -276,6 +267,15 @@ def register(self, new_reg=None):
+ # pylint: disable=no-member
+ return self._regr_from_response(response)
+
++def query_registration(self, regr):
++"""Query server about registration.
++
++:param messages.RegistrationResource: Existing Registration
++Resource.
++
++"""
++return self._send_recv_regr(regr, messages.UpdateRegistration())
++
+ def agree_to_tos(self, regr):
+ """Agree to the terms-of-service.
+
+@@ -603,10 +603,13 @@ def query_registration(self, regr):
+ Resource.
+
+ """
+-self.net.account = regr
+-updated_regr = super(ClientV2, self).query_registration(regr)
+-self.net.account = updated_regr
+-return updated_regr
++self.net.account = regr  # See certbot/certbot#6258
++# ACME v2 requires to use a POST-as-GET request (POST an empty JWS) 
here.
++# This is done by passing None instead of an empty UpdateRegistration 
to _post().
++response = self._post(regr.uri, None)
++self.net.account = self._regr_from_response(response, uri=regr.uri,
++
terms_of_service=regr.terms_of_service)
++return self.net.account
+
+ def update_registration(self, regr, update=None):
+ """Update registration.
diff -Nru python-acme-0.31.0/debian/patches/0002-post-as-get.patch 
python-acme-0.31.0/debian/patches/0002-post-as-get.patch
--- python-acme-0.31.0/debian/patches/0002-post-as-get.patch1969-12-31 
19:00:00.0 -0500
+++ python-acme-0.31.0/debian/patches/0002-post-as-get.patch2019-05-04 
21:32:00.0 -0400
@@ -0,0 +1,24 @@
+From a0a8292ff26a2d062e75b865d9b9b10977dc1f80 Mon Sep 17 00:00:00 2001
+From: Adrien 

Bug#928392: fzf: zsh integration doesn't work out of the box

[M. Zhou]

Hi Sean,

An official Debian package cannot edit your .zshrc file. A quick instruction for
zsh integration can be found here:

  /usr/share/doc/fzf/README.Debian

which is a standard location for notes. And the it is already pointed
out in fzf's description.
$ apt show fzf

Package: fzf
Version: 0.18.0-1
Built-Using: golang-1.11 (= 1.11.6-1), golang-github-mattn-go-isatty
(= 0.0.4-1), golang-github-mattn-go-runewidth (= 0.0.4-1),
golang-github-mattn-go-shellwords (= 1.0.3-1), golang-go.crypto (=
1:0.0~git20181203.505ab14-1), golang-golang-x-sys (=
0.0~git20181228.9a3f9b0-1)
Priority: optional
Section: utils
Maintainer: Mo Zhou 
Installed-Size: 3,031 kB
Depends: libc6 (>= 2.3.2)
Homepage: https://github.com/junegunn/fzf
Download-Size: 928 kB
APT-Manual-Installed: yes
APT-Sources: https://mirrors.ustc.edu.cn/debian experimental/main amd64 Packages
Description: general-purpose command-line fuzzy finder
 It's an interactive Unix filter for command-line that can be used with
 any list; files, command history, processes, hostnames, bookmarks, git
 commits, etc.
 .
 Refer /usr/share/doc/fzf/README.Debian for quick instructions on how to
 add keybindings for Bash, Zsh, Fish to call fzf.



On Fri, 3 May 2019 at 15:00, Sean Haugh  wrote:
>
> Package: fzf
> Version: 0.17.5-2+b10
> Severity: normal
>
> Hello,
>
> I can't seem to get fzf's zsh integration working. Namely, trying to
> fuzzily complete path names does not succeed. Are there additional steps
> to take to install the zsh integration?
>
-- 
Best,

Bug#928454: perl6-zef's p6c mirror URLs are outdated

[Mo Zhou]

Package: perl6-zef
Version: 0.6.2-1
Severity: serious
Clarification: renders zef nearly unusable

Dear maintainer,

The URL list for p6c mirrors has already outdated:

 53 "short-name" : "p6c",
 54 "enabled" : 1,
 55 "module" : "Zef::Repository::Ecosystems",
 56 "options" : {
 57 "name" : "p6c",
 58 "auto-update" : 1,
 59 "mirrors" : [
 60 "http://ecosystem-api.p6c.org/projects1.json";,
 61 "http://ecosystem-api.p6c.org/projects.json";,
 62 "git://github.com/ugexe/Perl6-ecosystems.git",
 63 
"https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json";

The outdated URL list makes zef fail twice on update. It only starts to
work with the 3rd URL. In order to make zef package easier to use, we
should update the p6c mirror URLs in resources/config.json to

  "https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json";,
  "git://github.com/ugexe/Perl6-ecosystems.git",
  "http://ecosystem-api.p6c.org/projects1.json";

https://github.com/ugexe/zef/blob/master/resources/config.json#L60-L62

in #perl6 channel, zef upstream said these URLs are not likely to be
changed recently:

 ugexe: How likely will zef change it's mirror URL again in the next one 
or two years? I'm going to update the zef package for Debian Buster
 i don't plan on changing it. someone whined about it not being hosted 
by p6c once before so i changed it back, but i guess thats what i get for being 
a push over

Bug#928455: [pre-a] unblock: perl6-zef/0.6.2-2

[Mo Zhou]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-CC: Robert Lemmen , Dominique Dumont 


Please unblock package perl6-zef

(explain the reason for the unblock here)

As I reported in #928454, the outdated mirror URL list renders zef,
the perl6 package manager nearly unusable:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928454

Luckily we can fix the package for Buster by simply updating the list:
https://github.com/ugexe/zef/blob/master/resources/config.json#L60-L62
I asked upstream author on IRC and they acked that the mirror list is
not likely to be changed for the Buster lifecycle.

(include/attach the debdiff against the package in testing)

```
--- config.json.orig2019-05-05 03:31:08.251673414 +
+++ config.json 2019-05-05 03:32:01.71262 +
@@ -57,10 +57,9 @@
 "name" : "p6c",
 "auto-update" : 1,
 "mirrors" : [
-"http://ecosystem-api.p6c.org/projects1.json";,
-"http://ecosystem-api.p6c.org/projects.json";,
+
"https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json";,
 "git://github.com/ugexe/Perl6-ecosystems.git",
-
"https://raw.githubusercontent.com/ugexe/Perl6-ecosystems/master/p6c1.json";
+"http://ecosystem-api.p6c.org/projects1.json";
 ]
 }
 },
```

unblock perl6-zef/0.6.2-2

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

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

Bug#928456: wget: enable parallel builds

[Steve Langasek]

Package: wget
Version: 1.20.1-1.1
Severity: wishlist
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Hi Noël,

In Ubuntu, we have patched the wget package to support parallel builds. 
This seems like a useful enhancement for Debian to include as well.  Please
find attached the patch to debian/rules that's used to enable this.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru wget-1.20.1/debian/rules wget-1.20.1/debian/rules
--- wget-1.20.1/debian/rules2019-04-05 06:36:38.0 -0700
+++ wget-1.20.1/debian/rules2019-04-11 09:21:20.0 -0700
@@ -3,6 +3,11 @@
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
+COMMA = ,
+ifneq (,$(filter parallel=%,$(subst $(COMMA), ,$(DEB_BUILD_OPTIONS
+  NJOBS := -j $(subst parallel=,,$(filter parallel=%,$(subst $(COMMA), 
,$(DEB_BUILD_OPTIONS
+endif
+
 DEB_HOST_GNU_TYPE ?=$(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
 DEB_BUILD_GNU_TYPE ?=$(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
 
@@ -59,7 +64,7 @@
dh_testdir
 
# Add here commands to compile the package.
-   cd build && $(MAKE)
+   cd build && $(MAKE) $(NJOBS)
#/usr/bin/docbook-to-man debian/wget.sgml > wget.1
 
cd po; make wget.pot
@@ -67,7 +72,7 @@
touch build-stamp
 
 build-udeb-stamp: configure-udeb-stamp
-   cd build-udeb && $(MAKE)
+   cd build-udeb && $(MAKE) $(NJOBS)
touch build-udeb-stamp
 
 clean:

Bug#928146: reported on freedesktop too

[Jérémy Viès]

Hi all,

it seems the issue is already reported and fixed in upstream repo:
https://bugs.freedesktop.org/show_bug.cgi?id=110509

Bug#928415: firefox-esr: Bugzilla 1548973 All extensions disabled due to expiration of intermediate signing cert

[Ben Wong]

Package: firefox-esr
Version: 60.6.1esr-1~deb9u1
Followup-For: Bug #928415

Dear Maintainer,

What is Debian's recommendation for users and administrators dealing
with this major snafu?

I've got a bunch of Debian Stable boxes with Firefox-esr and
installing the STUDIES "hotfix" from Mozilla by hand on each one is
not feasible. 

I'm okay with sitting tight while Debian's awesome maintainers fix
this correctly by bundling the new certificate — so we can just `apt
upgrade` and get on with life — but, it'd be nice to know if that's
even in the works.

I know you're probably super busy right now and I very much appreciate
your time. 

Thanks,

Ben



-- Package-specific info:


-- Addons package information

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

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

Versions of packages firefox-esr depends on:
ii  debianutils   4.8.1.1
ii  fontconfig2.11.0-6.7+b1
ii  libasound21.1.3-5
ii  libatk1.0-0   2.22.0-1
ii  libc6 2.24-11+deb9u4
ii  libcairo-gobject2 1.14.8-1
ii  libcairo2 1.14.8-1
ii  libdbus-1-3   1.10.26-0+deb9u1
ii  libdbus-glib-1-2  0.108-2
ii  libffi6   3.2.1-6
ii  libfontconfig12.11.0-6.7+b1
ii  libfreetype6  2.6.3-3.2
ii  libgcc1   1:6.3.0-18+deb9u1
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk-3-03.22.11-1
ii  libjsoncpp1   1.7.4-3
ii  libpango-1.0-01.40.5-1
ii  libstartup-notification0  0.12-4+b2
ii  libstdc++66.3.0-18+deb9u1
ii  libvpx4   1.6.1-3+deb9u1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libx11-xcb1   2:1.6.4-3+deb9u1
ii  libxcb-shm0   1.12-1
ii  libxcb1   1.12-1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1
ii  procps2:3.3.12-3+deb9u1
ii  zlib1g1:1.2.8.dfsg-5

Versions of packages firefox-esr recommends:
ii  libavcodec57  7:3.2.12-1~deb9u1

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.004.5-3
ii  fonts-stix [otf-stix]  1.1.1-4
ii  libcanberra0   0.30-3
ii  libgssapi-krb5-2   1.15-1+deb9u1
ii  libgtk2.0-02.24.31-2
ii  pulseaudio 10.0-1+deb9u1

-- no debconf information