Bug#910124: [Pkg-utopia-maintainers] Bug#910124: network-manager-gnome: option to import/export WiFi config as a QR code

2019-06-02 Thread Michael Biebl
Am 01.06.19 um 21:37 schrieb Salvatore Bonaccorso:

> On Fri, May 31, 2019 at 02:57:13PM +0200, Salvatore Bonaccorso wrote:

>> Is that the same as src:qr-code-generator as present in unstable, cf.
>> https://tracker.debian.org/pkg/qr-code-generator . 
>>
>> Is the network-manager-applet embedded copy unmodified? If so it would
>> be preferable if network-manager-applet could switch to the system
>> one.
> 
> So src/libnma/qrcodegen.c in src:network-manager-applet/1.8.22 is the
> same c/qrcodegen.c as in src:qr-code-generator/1.4.0 apart whitespace
> changes.

I've filed
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/issues/187

Regards,
Michael

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



signature.asc
Description: OpenPGP digital signature


Bug#926319: tomcat9: Variable expansion not supported in /etc/default/tomcat9

2019-06-02 Thread Christian Hänsel
Hi Emmanuel

Thank you for the feedback. This is beyond my expertise so feel free to
modify it so that it is a reliable solution.

Regards,
Christian

Am 02.06.19 um 23:45 schrieb Emmanuel Bourg:
> Le 23/05/2019 à 18:58, Christian Hänsel a écrit :
> 
>> I did the following changes to use /etc/default/tomcat9 to enable
>> debugging for tomcat9.
>>
>> 1. modify tomcat-start.sh to load /etc/default/tomcat9
>>
>> 2. removed environmentFiles from
>> /etc/systemd/system/multi-user.target.wants/tomcat9.service
> 
> Thank you for the patch Christian. I'm going to apply it with a minor
> difference, the default settings have to be loaded before the JVM is
> located, otherwise the service will fail to start when the detection
> fails, even if the JAVA_HOME variable is set in /etc/default/tomcat9.
> 
> Emmanuel Bourg
> 



signature.asc
Description: OpenPGP digital signature


Bug#929918: mirror submission for mirror.ipb.de

2019-06-02 Thread Stefan Funke
Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.ipb.de
Type: leaf
Archive-architecture: amd64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: Stefan Funke 
Country: DE Germany
Location: Berlin
Sponsor: IPB Internet Provider in Berlin https://www.ipb.de/




Trace Url: http://mirror.ipb.de/debian/project/trace/
Trace Url: http://mirror.ipb.de/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.ipb.de/debian/project/trace/mirror.ipb.de



Bug#928948: hostapd: syslog is spammed every two seconds

2019-06-02 Thread Andrej Shadura
Control: tags -1 pending

Hi,

On Mon, 3 Jun 2019 at 03:36, Reinhard Tartler  wrote:
> I'm trying to help out with remaining RC bugs for buster.
>
> > The postinst is set up in a way so that if /etc/hostapd/hostapd.conf
> > is not readable or missing, the hostapd.service is masked during the
> > package installation unless it was already running.
>
> I wonder if that is really necessary and couldn't be avoided by using the 
> following drectitve in hostapd.service:
>
> ConditionPathExists=/etc/hostapd/hostapd.conf
>
> If my understading of systemd.unit(5) is correct, I believe this might 
> simplify significantly simplify the postinst script.

Your understanding is correct, but, unfortunately, we cannot do that
for buster since there’s no guarantee users are going to have their
configuration file there. For bullseye, this is going to be the plan.

I will upload a fix later today.

-- 
Cheers,
  Andrej



Bug#929917: unblock: tt-rss/18.12+dfsg-1.1

2019-06-02 Thread Helmut Grohne
Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package tt-rss

The updated package fixes #923661, which practically breaks the default
installation (i.e. mysql, not postgresql). The actual failure is a
regression triggered by updating PHP to 7.3 in the sql logging backend.
The upload fixes the relevant php code and additionally defaults to
logging to syslog. Doing so is more in line with best practises and
avoids the previously problematic sql logging code. Sebastian Reichel
(maintainer) agreed with that change, but presently lacks time.

unblock tt-rss/18.12+dfsg-1.1

Helmut
diff --minimal -Nru tt-rss-18.12+dfsg/debian/changelog 
tt-rss-18.12+dfsg/debian/changelog
--- tt-rss-18.12+dfsg/debian/changelog  2019-02-06 00:04:47.0 +0100
+++ tt-rss-18.12+dfsg/debian/changelog  2019-06-03 06:15:55.0 +0200
@@ -1,3 +1,11 @@
+tt-rss (18.12+dfsg-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload acknowledged by Sebastian Reichel.
+  * Cherry pick JShrink PHP 7.3 compatibility patch. (Closes: #923661)
+  * Default to using syslog as log backend rather than sql.
+
+ -- Helmut Grohne   Mon, 03 Jun 2019 06:15:55 +0200
+
 tt-rss (18.12+dfsg-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/config.php-dist.patch 
tt-rss-18.12+dfsg/debian/patches/config.php-dist.patch
--- tt-rss-18.12+dfsg/debian/patches/config.php-dist.patch  2019-02-06 
00:04:47.0 +0100
+++ tt-rss-18.12+dfsg/debian/patches/config.php-dist.patch  2019-06-03 
06:14:40.0 +0200
@@ -6,10 +6,8 @@
 Author: Sebastian Reichel 
 Last-Update: 2013-02-17
 
-Index: tt-rss/config.php-dist
-===
 tt-rss.orig/config.php-dist
-+++ tt-rss/config.php-dist
+--- tt-rss-18.12+dfsg.orig/config.php-dist
 tt-rss-18.12+dfsg/config.php-dist
 @@ -3,12 +3,13 @@
// *** Database configuration (important!) ***
// ***
@@ -44,3 +42,12 @@
// Local cache directory for RSS feed content.
  
define('ICONS_DIR', "feed-icons");
+@@ -165,7 +166,7 @@
+   // Disabling auth_internal in this list would automatically disable
+   // reset password link on the login form.
+ 
+-  define('LOG_DESTINATION', 'sql');
++  define('LOG_DESTINATION', 'syslog');
+   // Error log destination to use. Possible values: sql (uses internal 
logging
+   // you can read in Preferences -> System), syslog - logs to system log.
+   // Setting this to blank uses PHP logging (usually to http server
diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch 
tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch
--- tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch   1970-01-01 
01:00:00.0 +0100
+++ tt-rss-18.12+dfsg/debian/patches/jshrink_php7.3_fix.patch   2019-06-03 
06:15:08.0 +0200
@@ -0,0 +1,30 @@
+From 91105810dafedba0390608d7465abd602beb6410 Mon Sep 17 00:00:00 2001
+From: Sergei Morozov 
+Date: Fri, 14 Sep 2018 19:55:03 -0700
+Subject: [PATCH] Fixed test failures on PHP 7.3
+
+1. continue in break shoud target the while loop directly 
(php/php-src@04e3523).
+2. strpos() doesn't longer accept non-string needles 
(https://wiki.php.net/rfc/deprecations_php_7_3#string_search_functions_with_integer_needle).
+ src/JShrink/Minifier.php | 4 ++--
+ 2 files changed, 4 insertions(+), 3 deletions(-)
+
+--- tt-rss-18.12+dfsg.orig/vendor/JShrink/Minifier.php
 tt-rss-18.12+dfsg/vendor/JShrink/Minifier.php
+@@ -181,7 +181,7 @@
+ // new lines
+ case "\n":
+ // if the next line is something that can't stand alone 
preserve the newline
+-if (strpos('(-+{[@', $this->b) !== false) {
++if ($this->b !== false && strpos('(-+{[@', $this->b) !== 
false) {
+ echo $this->a;
+ $this->saveString();
+ break;
+@@ -224,7 +224,7 @@
+ // check for some regex that breaks stuff
+ if ($this->a === '/' && ($this->b === '\'' || 
$this->b === '"')) {
+ $this->saveRegex();
+-continue;
++continue 3;
+ }
+ 
+ echo $this->a;
diff --minimal -Nru tt-rss-18.12+dfsg/debian/patches/series 
tt-rss-18.12+dfsg/debian/patches/series
--- tt-rss-18.12+dfsg/debian/patches/series 2019-02-06 00:04:47.0 
+0100
+++ tt-rss-18.12+dfsg/debian/patches/series 2019-06-03 06:14:46.0 
+0200
@@ -1,3 +1,4 @@
 config.php-dist.patch
 remove-tt-rss-layer.patch
 fix-db-updater-script.patch
+jshrink_php7.3_fix.patch


Bug#929916: libreswan: CVE-2019-12312

2019-06-02 Thread Salvatore Bonaccorso
Source: libreswan
Version: 3.27-4
Severity: grave
Tags: patch security upstream fixed-upstream
Justification: user security hole
Forwarded: https://github.com/libreswan/libreswan/issues/246
Control: fixed -1 3.28-1

Hi,

The following vulnerability was published for libreswan.

CVE-2019-12312[0]:
| In Libreswan before 3.28, an assertion failure can lead to a pluto IKE
| daemon restart. An attacker can trigger a NULL pointer dereference by
| sending two IKEv2 packets (init_IKE and delete_IKE) in 3des_cbc mode
| to a Libreswan server. This affects send_v2N_spi_response_from_state
| in programs/pluto/ikev2_send.c when built with Network Security
| Services (NSS).


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-12312
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-12312
[1] https://github.com/libreswan/libreswan/issues/246
[2] 
https://github.com/libreswan/libreswan/commit/7142d2c37d58cf024595a7549f0fb0d3946682f8

Regards,
Salvatore



Bug#929915: vala: debian/rules: simplify parallel build

2019-06-02 Thread Helmut Grohne
Source: vala
Version: 0.42.5-1
Severity: wishlist
Tags: patch

While looking into the vala package, I noticed that it bears unnecessary
complexity for running the bootstrap build. Using dh_auto_* works there
and removes the need for computing DEB_MAKE_PARALLEL. I've attached a
patch to demonstrate that. If you don't like the patch, please close
this bug anyway.

Helmut
diff --minimal -Nru vala-0.42.5/debian/changelog vala-0.42.5/debian/changelog
--- vala-0.42.5/debian/changelog2019-01-22 18:07:20.0 +0100
+++ vala-0.42.5/debian/changelog2019-06-02 20:48:44.0 +0200
@@ -1,3 +1,10 @@
+vala (0.42.5-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Simplify parallelity using more dh_auto_*. (Closes: #-1)
+
+ -- Helmut Grohne   Sun, 02 Jun 2019 20:48:44 +0200
+
 vala (0.42.5-1) unstable; urgency=medium
 
   * New upstream release
diff --minimal -Nru vala-0.42.5/debian/rules vala-0.42.5/debian/rules
--- vala-0.42.5/debian/rules2019-01-22 18:07:20.0 +0100
+++ vala-0.42.5/debian/rules2019-06-02 20:48:44.0 +0200
@@ -4,13 +4,6 @@
 export DEB_LDFLAGS_MAINT_APPEND = -Wl,-O1 -Wl,-z,defs -Wl,--as-needed
 export DEB_CFLAGS_MAINT_APPEND = -Wall
 
-DEB_PARALLEL_JOBS = $(patsubst parallel=%,%,$(filter 
parallel=%,$(DEB_BUILD_OPTIONS)))
-ifneq (,$(DEB_PARALLEL_JOBS))
-DEB_MAKE_PARALLEL = -j$(DEB_PARALLEL_JOBS)
-else
-DEB_MAKE_PARALLEL =
-endif
-
 %:
dh $@ --with gnome
 
@@ -27,8 +20,8 @@
dh_auto_configure --builddirectory=bootstrap/build
 
 bootstrap: configure-bootstrap
-   make $(DEB_MAKE_PARALLEL) -C bootstrap/build
-   make $(DEB_MAKE_PARALLEL) -C bootstrap/build 
DESTDIR=$(CURDIR)/bootstrap/install install
+   dh_auto_build --builddirectory=bootstrap/build
+   dh_auto_install --builddirectory=bootstrap/build -- 
DESTDIR=$(CURDIR)/bootstrap/install
 
 override_dh_auto_configure: bootstrap
find -name '*.vala.stamp' -delete


Bug#929914: devscripts: 'bts bugs' has race condition with 'firefox'

2019-06-02 Thread laokz
Package: devscripts
Version: 2.19.5
Severity: normal

Dear Maintainer,

My box sensible-browser is firefox. When firefox already running, command
'bts bugs 652727' failed as firefox displaying 'page not
found'(file:///tmp/btsXXX.html), and file /tmp/btsXXX.html not exist indeed.

I tried:
* When firefox not already running, it worked fine.
* Modify bts by adding 'sleep(1)' before the end of function runbrowser,
it worked all fine.
* Set sensible-browser to 'firefox --browser', it worked but not good.
* Set sensible-browser to chromium, it worked all fine.

With Debian-devel IRC help, I am sure that 'bts bugs' has race condition
with running firefox.



-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
DEBUILD_DPKG_BUILDPACKAGE_OPTS="-i -I -us -uc"
DEBUILD_LINTIAN_OPTS="-IviL +certain --show-overrides"
DEBSIGN_KEYID="9B92840DF1C66F3A36DB91C606EDBEEBCBBE81B2"

-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable')
Architecture: amd64 (x86_64)

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

Versions of packages devscripts depends on:
ii  dpkg-dev  1.19.6
ii  fakeroot  1.23-1
ii  file  1:5.35-4
ii  gnupg 2.2.12-1
ii  gpgv  2.2.12-1
ii  libc6 2.28-10
ii  libfile-homedir-perl  1.004-1
ii  libfile-which-perl1.23-1
ii  libipc-run-perl   20180523.0-1
ii  libmoo-perl   2.003004-2
ii  libwww-perl   6.36-2
ii  patchutils0.3.4-2
ii  perl  5.28.1-6
ii  python3   3.7.3-1
ii  sensible-utils0.0.12
ii  wdiff 1.2.2-2+b1

Versions of packages devscripts recommends:
ii  apt 1.8.2
ii  at  3.1.23-1
ii  dctrl-tools 2.24-3
ii  debian-keyring  2019.02.25
ii  dput1.0.3
ii  equivs  2.2.0
ii  libdistro-info-perl 0.21
ii  libdpkg-perl1.19.6
ii  libencode-locale-perl   1.05-1
ii  libgit-wrapper-perl 0.048-1
ii  libgitlab-api-v4-perl   0.16-1
ii  liblist-compare-perl0.53-1
ii  liblwp-protocol-https-perl  6.07-2
ii  libsoap-lite-perl   1.27-1
ii  libstring-shellquote-perl   1.04-1
ii  libtry-tiny-perl0.30-1
ii  liburi-perl 1.76-1
ii  licensecheck3.0.31-3
ii  lintian 2.15.0
ii  man-db  2.8.5-2
ii  patch   2.7.6-3
ii  python3-apt 1.8.4
ii  python3-debian  0.1.34
ii  python3-magic   2:0.4.15-2
ii  python3-requests2.21.0-1
ii  python3-unidiff 0.5.4-1
ii  python3-xdg 0.25-5
ii  strace  4.26-0.2
ii  unzip   6.0-22
ii  wget1.20.1-1.1
ii  xz-utils5.2.4-1

Versions of packages devscripts suggests:
pn  adequate 
pn  autopkgtest  
pn  bls-standalone   
ii  build-essential  12.6
pn  check-all-the-things 
pn  cvs-buildpackage 
ii  debhelper12.1.1
pn  devscripts-el
pn  diffoscope   
pn  disorderfs   
pn  dose-extra   
pn  duck 
pn  faketime 
pn  gnuplot  
pn  how-can-i-help   
ii  libauthen-sasl-perl  2.1600-1
pn  libdbd-pg-perl   
ii  libfile-desktopentry-perl0.22-1
pn  libnet-smtps-perl
pn  libterm-size-perl
ii  libtimedate-perl 2.3000-2
pn  libyaml-syck-perl
ii  mailutils [mailx]1:3.5-3
pn  mozilla-devscripts   
pn  mutt 
ii  openssh-client [ssh-client]  1:7.9p1-10
pn  piuparts 
pn  postgresql-client
ii  quilt0.65-3
pn  ratt 
pn  reprotest
pn  svn-buildpackage 
pn  w3m  

-- no debconf information



Bug#929913: unblock: simple-cdd/0.6.7

2019-06-02 Thread Vagrant Cascadian
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: vagr...@debian.org, debian-b...@lists.debian.org

Please unblock package simple-cdd

This update fixes several release-critical and important bugs, as well
as documentation updates.

Several issues were reported with expired keys in the archive keyring
breaking builds with simple-cdd, even when the expired key was not
used to verify the repositories being checked. This was fixed by
allowing expired keys to be present in the keyring used by reprepro
(though are not treated as valid for verifying Release files).

A typo was fixed that caused a traceback in gpg verification, and now
reports the failing command.

The --batch argument was added to gpg calls, which are all
non-interactive, which allows it to work in docker environments.

Contact information in the README was no longer valid, and so it was removed.

Fix a number of issues with changes in qemu arguments, and re-add the
missing support to pass arbitrary qemu options.

Update example configuration files, removing obsolete options and
adjusting a syntax change in some options which no longer support
variables.

The ltsp profile was updated to use the defaults for
ltsp-client-builder, with commented examples for using the non-default
values. NFS is no longer used in LTSP by default, so is no longer
configured, and the example to configure DHCP was updated to use
dnsmasq.

The test profile was updated with new and changed preseeding options,
as well as options passed to qemu.

The default profile updated the example to avoid asking to set up
another CD.

The router profile example ethernet interface name was updated to be
consistant with current naming conventions.


diff -Nru simple-cdd-0.6.6/README simple-cdd-0.6.7/README
--- simple-cdd-0.6.6/README 2018-04-22 17:11:33.0 -0700
+++ simple-cdd-0.6.7/README 2019-05-27 15:48:46.0 -0700
@@ -1,10 +1,5 @@
 here's a quick guide to using simple-cdd... 
 
-if you have further questions, ask on the simple-cdd-devel mailing list:
-http://lists.alioth.debian.org/mailman/listinfo/simple-cdd-devel, or in the
-debian-custom channel on irc.debian.org.
-
-
 Quick Start (from http://wiki.debian.org/Simple-CDD/Howto)
 
 To try Simple-CDD, on a Debian system:
diff -Nru simple-cdd-0.6.6/build-simple-cdd simple-cdd-0.6.7/build-simple-cdd
--- simple-cdd-0.6.6/build-simple-cdd   2018-04-22 20:36:26.0 -0700
+++ simple-cdd-0.6.7/build-simple-cdd   2019-05-28 15:39:42.0 -0700
@@ -532,8 +532,9 @@
 if self.env.get("use_serial_console"):
 qemu_opts.append("-nographic")
 
-# if [ -n "$mem" ]; then
-# qemu_opts="$qemu_opts -m $mem"
+if self.env.get("qemu_opts"):
+for opt in self.env.get('qemu_opts').split():
+qemu_opts.append(opt)
 
 # Hard disk image
 hd_img = os.path.join(self.env.get("simple_cdd_dir"), 
"qemu-test.hd.img")
diff -Nru simple-cdd-0.6.6/debian/changelog simple-cdd-0.6.7/debian/changelog
--- simple-cdd-0.6.6/debian/changelog   2018-04-22 21:13:56.0 -0700
+++ simple-cdd-0.6.7/debian/changelog   2019-05-29 21:29:45.0 -0700
@@ -1,3 +1,41 @@
+simple-cdd (0.6.7) unstable; urgency=medium
+
+  [ Vagrant Cascadian ]
+  * Remove invalid contact information from README.
+  * Output command run on gpg verification failure rather than passing an
+undefined variable. (Closes: #919572, #929651).  Thanks to Vladislav
+Tsendrovskii and Marc Fargas for the reports.
+  * Do not fail when expired keys are present in the keyring.
+(Closes: #928703, #929193). Thanks to Sebastien Delafond and Pradeep
+Nambiar.
+
+  [ Vagrant Cascadian ]
+  * Add back support for qemu_opts (Closes: #929660, #929636).
+  * Update qemu configuration from -std-vga to -vga std.
+  * Update example simple-cdd.conf and simple-cdd.conf.detailed, removing
+obsolete options and adjusting options requiring variables.
+(Closes: #909561).
+
+  [ Dirk Mayer ]
+  * added --batch param to gpg calls (Closes: #918102).
+
+  [ Vagrant Cascadian ]
+  * Update ltsp profile:
+- Use defaults for ltsp-client-builder.
+- Do not configure NFS, no longer used by default.
+- Use "ltsp-config dnsmasq" as it is the preferred DHCP server.
+  * Update test profile:
+- Add preseeding to avoid asking to set up another CD.
+- Use preseeding to select default boot device.
+- Update arguments for non-graphical console.
+- Allow rebooting for initial boot test.
+  * Update default profile:
+- Update question to avoid asking to set up another CD.
+  * Update router profile:
+- Update default example ethernet interface.
+
+ -- Vagrant Cascadian   Wed, 29 May 2019 21:29:45 -0700
+
 simple-cdd (0.6.6) unstable; urgency=medium
 
   [ Jack Henschel ]
diff -Nru simple-cdd-0.6.6/profiles/default.preseed 
simple-cdd-0.6.7/profiles/default.preseed
--- simple-cdd-0.6.6/profile

Bug#929912: unblock: ltsp/5.18.12-3

2019-06-02 Thread Vagrant Cascadian
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: vagr...@debian.org, debian-b...@lists.debian.org

Please unblock package ltsp

This fixes two release-critical bugs, an important bug, and updates
the debconf translation for Dutch.

Builds from unsigned CDs failed due to changes in apt being more
strict regarding unsigned repositories. This is fixed by passing the
--trust-file-mirror option introduced in ltsp-build-client upstream,
but not added to the default arguments for the ltsp-client-builder
.udeb. This .udeb is not used in the default debian-installer images,
and thus should have no impact on them.

The tool to build an LTSP chroot environment failed to detect the
codename in buster now that /etc/debian_version contains a version,
instead passing the version of Debian "10" to debootstrap, resulting
in a failure to build. The upstream fix was to switch back to using
lsb_release, and the patch applied to this version.

An important issue in the arguments for mounting loopback images was
discovered and fixed upstream, ensuring read-only mounts which might
otherwise lead to filesystem inconsistancies with ext4 or other
writeable filesystems, and fixing a typo in the loop argument passed
to mount. The upstream patch is included in this version.

Additionally, the Dutch debconf message translation was included in
this version.

diff -Nru ltsp-5.18.12/debian/changelog ltsp-5.18.12/debian/changelog
--- ltsp-5.18.12/debian/changelog   2018-12-24 17:30:09.0 -0800
+++ ltsp-5.18.12/debian/changelog   2019-05-29 13:02:07.0 -0700
@@ -1,3 +1,23 @@
+ltsp (5.18.12-3) unstable; urgency=medium
+
+  * ltsp-client-builder: Add --trust-file-mirror to ltsp-build-client
+options to fix builds from unsigned CDs (Closes: #929735).
+
+ -- Vagrant Cascadian   Wed, 29 May 2019 13:02:07 -0700
+
+ltsp (5.18.12-2) unstable; urgency=medium
+
+  [ Frans Spiesschaert ]
+  * [INTL:nl] Dutch translation of debconf messages (Closes: #924103).
+
+  [ Vagrant Cascadian ]
+  * Add patch to fix loop mounting and ensure mount is read-only. Thanks
+to Alkis Georgopoulos.
+  * Add patch to fix codename detection (Closes: #925173). Thanks to
+Wolfgang Schweer.
+
+ -- Vagrant Cascadian   Mon, 27 May 2019 04:58:46 -0700
+
 ltsp (5.18.12-1) unstable; urgency=medium
 
   * New upstream version.
diff -Nru ltsp-5.18.12/debian/ltsp-client-builder.templates 
ltsp-5.18.12/debian/ltsp-client-builder.templates
--- ltsp-5.18.12/debian/ltsp-client-builder.templates   2018-12-24 
17:15:33.0 -0800
+++ ltsp-5.18.12/debian/ltsp-client-builder.templates   2019-05-29 
12:23:24.0 -0700
@@ -29,7 +29,7 @@
 
 Template: ltsp-client-builder/build-client-opts
 Type: string
-Default: --mirror file:///media/cdrom --security-mirror none --updates-mirror 
none --accept-unsigned-packages
+Default: --mirror file:///media/cdrom --security-mirror none --updates-mirror 
none --accept-unsigned-packages --trust-file-mirror
 # Only used for preseeding arguments to ltsp-client-builder.
 Description: for internal use: arguments for ltsp-build-client:
  this option is meant to be used with debconf preseeding.
diff -Nru 
ltsp-5.18.12/debian/patches/correct-typo-in-ltsploop-avoid-ext4-journal-p.patch 
ltsp-5.18.12/debian/patches/correct-typo-in-ltsploop-avoid-ext4-journal-p.patch
--- 
ltsp-5.18.12/debian/patches/correct-typo-in-ltsploop-avoid-ext4-journal-p.patch 
1969-12-31 16:00:00.0 -0800
+++ 
ltsp-5.18.12/debian/patches/correct-typo-in-ltsploop-avoid-ext4-journal-p.patch 
2019-05-27 04:55:58.0 -0700
@@ -0,0 +1,24 @@
+From 5dcca1e8dcd864669ffa1cb36d89f832077a7243 Mon Sep 17 00:00:00 2001
+From: Alkis Georgopoulos 
+Date: Sat, 25 May 2019 09:49:38 +0300
+Subject: Debian: correct typo in ltsploop, avoid ext4 journal
+ playback errors.
+
+---
+ client/Debian/share/initramfs-tools/scripts/nfs-bottom/ltsploop | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/client/Debian/share/initramfs-tools/scripts/nfs-bottom/ltsploop 
b/client/Debian/share/initramfs-tools/scripts/nfs-bottom/ltsploop
+index 595e56ba..12bc4601 100755
+--- a/client/Debian/share/initramfs-tools/scripts/nfs-bottom/ltsploop
 b/client/Debian/share/initramfs-tools/scripts/nfs-bottom/ltsploop
+@@ -45,5 +45,5 @@ if [ -f "${rootmnt}/${ltsploop}" ]; then
+mount -o move ${rootmnt} /ltsploop
+mkdir -p ${rootmnt}
+# TODO filesystem detection
+-   mount -o ltsploop -t ${ltsploopfs} /ltsploop/${ltsploop} ${rootmnt}
++   mount -o loop,ro -t ${ltsploopfs} /ltsploop/${ltsploop} ${rootmnt}
+ fi
+-- 
+2.20.1
+
diff -Nru ltsp-5.18.12/debian/patches/fix-codename-detection.patch 
ltsp-5.18.12/debian/patches/fix-codename-detection.patch
--- ltsp-5.18.12/debian/patches/fix-codename-detection.patch1969-12-31 
16:00:00.0 -0800
+++ ltsp-5.18.12/debian/patches/fix-codename-detection.patch2019-05-27 
04:54:47.0 -0700
@@ -0,0 +1,33 @@
+From e7c0

Bug#928931: debian-installer: apt-setup/local0/key fails on buster because gnupg is not installed

2019-06-02 Thread Cyril Brulebois
Hi Philipp,

Philipp Huebner  (2019-05-20):
> I just ran into this very same issue.
> 
> > I seem to remember having seen some discussion regarding how to detect
> > binary or armoured keys; maybe a cheap(er) fix would be to make sure we
> > install the needed gnupg bits into /target when such a setting 
> > (apt-setup/local*/key) is detected?
> > 
> > See generators/60local in apt-setup.
> 
> Sounds good to me, I would like to see this fixed soon and can offer to
> test fixed d-i images.

Please use reply-all on the BTS, otherwise people don't see your replies
unless they specifically keep track of a particular bug report… I would
have taken care of this 10+ days ago if I had seen your reply earlier.

For the record, I've received dozens of 451 notifications from the bug
submitter, which would usually make me close the bug report directly.
But given that's a well-known issue, I'll refrain from doing so…


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


signature.asc
Description: PGP signature


Bug#922346: Fix for this issue still not available in testing

2019-06-02 Thread Hideki Yamane
On Sun, 26 May 2019 12:41:39 +0200 Michel Le Bihan  wrote:
> I saw that Mesa 18.3.6-2 was accepted into unstable on 2019-05-11. That
> version still hasn't migrated to testing because of the freeze. Could
> you please contact the release team to get this release in testing ASAP
> as I (and probably other users) am still experiencing this issue and it
> is very critical because opening a media file can cause my DE to crash
> causing the loss of any unsaved work.

 However, it contains thousands of diffs that is unsuitable during
 full freeze period. It'd be better to provide patch that only dealing
 with this issue for testing-proposed-update suite.


-- 
Hideki Yamane 



Bug#926182: Patch: Use alternatives system for guile-2.2-dev binaries

2019-06-02 Thread Rob Browning
Rob Browning  writes:

> Rob Browning  writes:
>
>> Yep -- I'm not sure yet, but I may lean toward providing:
>>
>>   bin/guile -> ./guile-2.2  # or whatever the selected alternative is
>>   bin/guild -> ./guild-2.2  # or whatever the selected alternative is
>
> OK, I think I'll have an upload this weekend using the built in
> ./configure --program-suffix support.  That produces a nearly identical
> install tree (though I'll need to double check the debs), excepting
> changes that should solve our problems, i.e. it installs:


Uploaded 2.2.4+1-2 to sid:

  https://salsa.debian.org/rlb/deb-guile/commits/deb/guile-2.2/v/2.2.4+1-2

Which includes:

  commit 4885ac01ce33474021b51695ef896661f237bd40
  Author: Rob Browning 
  Date:   Sat Jun 1 13:20:41 2019 -0500

  Handle guile-config/guile-snarf/guild as alternatives

  Arrange for guile-config, guile-snarf, guild (and guile-tools) to be
  handled via update-alternatives with all of the other tools dependent on
  guile-config.

  Configure with "--program-suffix -2.2" which gives the binaries the
  correct names from the start, so that we don't have to manually change
  them in debian/rules.  This also arranges for guile-config, etc. to
  refer to the versioned guile in their #! lines, which is what we should
  have been doing all along.

  Thanks to Ahmed El-Mahmoudy and Norbert Preining for reporting the
  problem, Kari Pahula and Vagrant Cascadian for help devising the fix,
  and Thibaut Paumard for help testing.

  Closes: 926182

I also included an upstream fix for the popen.test failures which I'd
begun hitting on amd64 too.  I'll see about badgering the release team
if it the buildds like it, but feel free to ping me if I wander off.

Thanks for all the help
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org
GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A
GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4



Bug#929911: installation-reports: d-i rc1 - apt-setup: local repositories broken

2019-06-02 Thread Raphaël Halimi
Package: installation-reports
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I have a TFTP server that holds several releases of Debian, and preseed
files. It works well for current and past releases, but I noticed two
problems with the current Buster installer (RC1).

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

Since that for testing and unstable, booting from TFTP always fail at
some point of the installation (cannot find modules from the current
kernel), I booted the ISO installer from an USB stick.

   * What was the outcome of this action?

The preseed files set up local repositories (apt-setup/local0/repository
etc etc). With the current Buster installer (RC1), these local
repositories are never set.

The installer log says:

apt-setup: warning: /usr/lib/apt-setup/generators/60local returned error
code 255; discarding output

Despite my best efforts, I couldn't debug it any further.

I tried with several older Buster installer releases, and noticed that
it worked until alpha2. It stopped working starting with alpha3.

   * What outcome did you expect instead?

I expected the local repositories to be added to /etc/apt/sources.list.

-- Package-specific info:

Boot method: USB Stick
Image version:
https://cdimage.debian.org/cdimage/buster_di_rc1/multi-arch/iso-cd/debian-buster-DI-rc1-amd64-i386-netinst.iso
Date: 2019-06-02

Machine: Libvirt/QEMU virtual machine

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Apart of this problem (and another described in a different bug report),
the installation went well.

Regards,

-- 
Raphaël Halimi

-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190410"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux test 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation
82G33/G31/P35/P31 Express DRAM Controller [8086:29c0]
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:01.0 VGA compatible controller [0300]: Red Hat, Inc. QXL
paravirtual graphic card [1b36:0100] (rev 04)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:02.0 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.1 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.2 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.3 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.4 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.5 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.6 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9
Family) HD Audio Controller [8086:293e] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9)
LPC Interface Controller [8086:2918] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation
82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode]
[8086:2922] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family)
SMBus Controller [8086:2930] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 01:00.0 Ethernet controller [0200]: Red Hat, Inc Virtio
network device [1af4:1041] (rev 01)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kern

Bug#929910: installation-reports: d-i rc1 - wrong defaultroot

2019-06-02 Thread Raphaël Halimi
Package: installation-reports
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I have a TFTP server that holds several releases of Debian, and preseed
files. It works well for current and past releases, but I noticed two
problems with the current Buster installer (RC1).

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

Since that for testing and unstable, booting from TFTP always fail at
some point of the installation (cannot find modules from the current
kernel), I booted the ISO installer from an USB stick.

   * What was the outcome of this action?

Adding "url=tftp://autoserver"; on the "Automatic install" command line,
the installer built a wrong value for auto-install/defaultroot
(d-i/stretch/./preseed.cfg). It then downloaded the wrong preseed file,
and in turn, had a wrong value for mirror/suite (stable).

   * What outcome did you expect instead?

The installer should have built the right value for the default root
(d-i/buster/./preseed.cfg).

Feeding the whole URL to the file, including the default root
(url=tftp://autoserver/d-i/buster/./preseed.cfg) was not sufficient to
make it work. The value of mirror/suite was correct (testing),
indicating that it downloaded the right preseed file, but the default
root was still set to "d-i/stretch/./preseed.cfg".

To get it working as expected, I had to specify both the url and the
default root on the command line, like this:

url=tftp://autoserver auto-install/defaultroot=d-i/buster/./preseed.cfg

-- Package-specific info:

Boot method: USB Stick
Image version:
https://cdimage.debian.org/cdimage/buster_di_rc1/multi-arch/iso-cd/debian-buster-DI-rc1-amd64-i386-netinst.iso
Date: 2019-06-02

Machine: Libvirt/QEMU virtual machine

Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives:  [O]
Install base system:[O]
Install tasks:  [O]
Install boot loader:[O]
Overall install:[O]

Comments/Problems:

Apart of this problem (and another described in a different bug report),
the installation went well.

Regards,

-- 
Raphaël Halimi

-- 

==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="10 (buster) - installer build 20190410"
X_INSTALLATION_MEDIUM=cdrom

==
Installer hardware-summary:
==
uname -a: Linux test 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15)
x86_64 GNU/Linux
lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation
82G33/G31/P35/P31 Express DRAM Controller [8086:29c0]
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:01.0 VGA compatible controller [0300]: Red Hat, Inc. QXL
paravirtual graphic card [1b36:0100] (rev 04)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:02.0 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.1 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.2 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.3 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.4 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.5 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:02.6 PCI bridge [0604]: Red Hat, Inc. Device [1b36:000c]
lspci -knn: Kernel driver in use: pcieport
lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9
Family) HD Audio Controller [8086:293e] (rev 03)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9)
LPC Interface Controller [8086:2918] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 00:1f.2 SATA controller [0106]: Intel Corporation
82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode]
[8086:2922] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: Kernel driver in use: ahci
lspci -knn: Kernel modules: ahci
lspci -knn: 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family)
SMBus Controller [8086:2930] (rev 02)
lspci -knn: Subsystem: Red Hat, Inc Device [1af4:1100]
lspci -knn: 01:00.0 Ethernet controller [0200]: Red Hat, Inc Virtio
network device [1af4:1041] (rev 01)
lspci -knn: Subsystem: Re

Bug#928948: hostapd: syslog is spammed every two seconds

2019-06-02 Thread Reinhard Tartler
Hi,

I'm trying to help out with remaining RC bugs for buster.

> The postinst is set up in a way so that if /etc/hostapd/hostapd.conf
> is not readable or missing, the hostapd.service is masked during the
> package installation unless it was already running.

I wonder if that is really necessary and couldn't be avoided by using the
following drectitve in hostapd.service:

ConditionPathExists=/etc/hostapd/hostapd.conf

If my understading of systemd.unit(5) is correct, I believe this might
simplify significantly simplify the postinst script.

-- 
regards,
Reinhard


Bug#929909: dpkg: warning: while removing fonts-lyx, directory '/usr/share/fonts/truetype/lyx' not empty so not removed

2019-06-02 Thread 積丹尼 Dan Jacobson
Package: fonts-lyx
Version: 2.3.2-1

dpkg: warning: while removing fonts-lyx, directory 
'/usr/share/fonts/truetype/lyx' not empty so not removed

# rm -rv /usr/share/fonts/truetype/lyx
removed '/usr/share/fonts/truetype/lyx/.uuid'
removed directory '/usr/share/fonts/truetype/lyx'



Bug#929908: unblock: tomcat9/9.0.16-4

2019-06-02 Thread Emmanuel Bourg
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi,

This is a pre-upload request to unblock tomcat9/9.0.16-4.

This update fixes:
- a minor security issue (CVE-2019-0221, see #929895)
- a startup failure on the architectures supporting only the Zero VM (#925928)
- the variable enabling the security manager that wasn't properly
  renamed in the startup script
- a couple of regressions compared to the old tomcat8 package that were
  caused by the transition to systemd (variable expansion no longer working
  in /etc/default/tomcat9, wrong permissions on the log directory)

This update doesn't implement the sysvinit script that was discussed
in #925473, this may be reconsidered in a later point release after
sufficient testing in unstable.

Thank you,

Emmanuel Bourg


unblock tomcat9/9.0.16-4



diff -Nru tomcat9-9.0.16/debian/changelog tomcat9-9.0.16/debian/changelog
--- tomcat9-9.0.16/debian/changelog 2019-02-26 09:31:13.0 +0100
+++ tomcat9-9.0.16/debian/changelog 2019-06-03 00:44:27.0 +0200
@@ -1,3 +1,26 @@
+tomcat9 (9.0.16-4) unstable; urgency=medium
+
+  * Team upload.
+
+  [ Emmanuel Bourg ]
+  * Fixed CVE-2019-0221: The SSI printenv command echoes user provided data
+without escaping and is, therefore, vulnerable to XSS. SSI is disabled
+by default (Closes: #929895)
+
+  [ Thorsten Glaser ]
+  * Remove -XX:+UseG1GC from standard JAVA_OPTS; the JRE chooses
+a suitable GC automatically anyway (Closes: #925928)
+  * Correct the ownership and permissions on the log directory:
+group adm and setgid (Closes: #925929)
+  * Make the startup script honour the (renamed) $SECURITY_MANAGER
+  * debian/libexec/tomcat-locate-java.sh: Remove shebang and make
+not executable as this is only ever sourced (makes no sense otherwise)
+
+  [ Christian Hänsel ]
+  * Restored the variable expansion in /etc/default/tomcat9 (Closes: #926319)
+
+ -- Emmanuel Bourg   Mon, 03 Jun 2019 00:44:27 +0200
+
 tomcat9 (9.0.16-3) unstable; urgency=medium

   * Removed read/write access to /var/lib/solr (Closes: #923299)
diff -Nru tomcat9-9.0.16/debian/default.template 
tomcat9-9.0.16/debian/default.template
--- tomcat9-9.0.16/debian/default.template  2019-02-05 10:11:13.0 
+0100
+++ tomcat9-9.0.16/debian/default.template  2019-06-02 23:05:39.0 
+0200
@@ -3,9 +3,10 @@
 # OpenJDK and the Oracle JDK are tried.
 #JAVA_HOME=/usr/lib/jvm/java-8-openjdk

-# You may pass JVM startup parameters to Java here. If unset, the default
-# options will be: -Djava.awt.headless=true -XX:+UseG1GC
-JAVA_OPTS="-Djava.awt.headless=true -XX:+UseG1GC"
+# You may pass JVM startup parameters to Java here. If you run Tomcat with
+# Java 8 instead of 9 or newer, add "-XX:+UseG1GC" to select a suitable GC.
+# If unset, the default options will be: -Djava.awt.headless=true
+JAVA_OPTS="-Djava.awt.headless=true"

 # To enable remote debugging uncomment the following line.
 # You will then be able to use a Java debugger on port 8000.
diff -Nru tomcat9-9.0.16/debian/libexec/tomcat-locate-java.sh 
tomcat9-9.0.16/debian/libexec/tomcat-locate-java.sh
--- tomcat9-9.0.16/debian/libexec/tomcat-locate-java.sh 2019-02-05 
10:11:13.0 +0100
+++ tomcat9-9.0.16/debian/libexec/tomcat-locate-java.sh 2019-06-03 
00:44:27.0 +0200
@@ -1,4 +1,3 @@
-#!/bin/sh
 #
 # Script looking for a Java runtime suitable for running Tomcat
 #
diff -Nru tomcat9-9.0.16/debian/libexec/tomcat-start.sh 
tomcat9-9.0.16/debian/libexec/tomcat-start.sh
--- tomcat9-9.0.16/debian/libexec/tomcat-start.sh   2019-02-05 
10:11:13.0 +0100
+++ tomcat9-9.0.16/debian/libexec/tomcat-start.sh   2019-06-03 
00:44:27.0 +0200
@@ -5,6 +5,9 @@

 set -e

+# Load the service settings
+. /etc/default/tomcat9
+
 # Find the Java runtime and set JAVA_HOME
 . /usr/libexec/tomcat9/tomcat-locate-java.sh

@@ -15,7 +18,7 @@

 # Enable the Java security manager?
 SECURITY=""
-[ "$TOMCAT_SECURITY" = "yes" ] && SECURITY="-security"
+[ "$SECURITY_MANAGER" = "true" ] && SECURITY="-security"


 # Start Tomcat
diff -Nru tomcat9-9.0.16/debian/patches/CVE-2019-0221.patch 
tomcat9-9.0.16/debian/patches/CVE-2019-0221.patch
--- tomcat9-9.0.16/debian/patches/CVE-2019-0221.patch   1970-01-01 
01:00:00.0 +0100
+++ tomcat9-9.0.16/debian/patches/CVE-2019-0221.patch   2019-06-03 
00:44:27.0 +0200
@@ -0,0 +1,16 @@
+Description: Fixes CVE-2019-0221: The SSI printenv command echoes user provided
+ data without escaping and is, therefore, vulnerable to XSS. SSI is disabled by
+ default.
+Origin: upstream, https://github.com/apache/tomcat/commit/15fcd16
+--- a/java/org/apache/catalina/ssi/SSIPrintenv.java
 b/java/org/apache/catalina/ssi/SSIPrintenv.java
+@@ -41,8 +41,7 @@
+ } else {
+ Collection variableNames = ssiMediator.getVariableNames();
+ for (String variableName : variableNames) {
+-String variableValue = ssiMediator
+-   

Bug#929876: appdata.its not packaged

2019-06-02 Thread Matthias Klumpp
Am So., 2. Juni 2019 um 13:03 Uhr schrieb Michael Gratton :
>
> Package: appstream-util
> Version: 0.7.14-1
>
> appstream-util provides its own version of `appdata.its` that
> supersedes the one shipped by gettext, but this is not shipped by
> Debian. As a result, appstream files are not fully translatable (e.g.
> see )
>
> Please include appdata.its in either the lib or dev package so that
> applications can add a build depend on it and gence get their appstream
> files fully translated.

The problem is that these files are duplicates of the metainfo.its
files found in original AppStream:
https://github.com/ximion/appstream/tree/master/data/its
Those, at least currently, are even more up-to-date than the ones
shipped by appstream-glib, and I would like to keep the amount of
these files small. Ideally, Gettext would just ship the only canonical
version.

This could be solved by making appstream-util depend on the appstream
package, but that feels a bit excessive and would pull in more stuff
than necessary. Alternatively we could also split out the files into
their own package, which isn't ideal either. Or, of course, just
install the files appstream-glib ships (and then wonder why tools
translate files differently and which files are used when).

Since the appstream package provides a bunch of setup bits for
AppStream on Debian already, I am currently slightly favouring to make
appstream-util depend on it - those packages are installed alongside
each other pretty much all the time anyway on a Debian system. The
second best option I think would be to just have appstream-glib ship
the ITS files and maybe do some tricks to make appstream not conflict
with them.
tl;dr I need to think about it and maybe also test how Gettext
actually behaves if there are three ITS files providing the same thing
in multiple locations.

Cheers,
Matthias

-- 
I welcome VSRE emails. See http://vsre.info/



Bug#929907: libgnutls30: Connections to older GnUTLS servers break

2019-06-02 Thread Dominik George
Package: libgnutls30
Version: 3.6.7-3
Severity: grave
Justification: renders package unusable

The update to 3.6.7-3 reproducibly breaks ldap-utils (or, maybe,the ldap
client library) when connecting to a server with the previous 3.6.6-2
version.  I am afraid it breaks more than that.  GnuTLS-secured connections
are just closed with no visible reason.

Seen on more than 12 systems, then went to a system that had not got the
update yet.  An ldapsearch works with 3.6.6-2, and fails after updating to
3.6.7-3 with the connection just being closed after reading some data from
the LDAP server setill on 3.6.6-2.  Upgrading GnuTLS to 3.6.7-3 on the
server made the problem go away.

I am setting this critical as I cannot imagine it is expected that GnuTLS
clients require the server to be the exact same version.

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

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

Versions of packages libgnutls30 depends on:
ii  libc6  2.28-10
ii  libgmp10   2:6.1.2+dfsg-4
ii  libhogweed43.4.1-1
ii  libidn2-0  2.0.5-1
ii  libnettle6 3.4.1-1
ii  libp11-kit00.23.15-2
ii  libtasn1-6 4.13-3
ii  libunistring2  0.9.10-1

libgnutls30 recommends no packages.

Versions of packages libgnutls30 suggests:
pn  gnutls-bin  

-- no debconf information



Bug#927971: tomcat9: split policy files and libexec scripts so that pki-server can use them

2019-06-02 Thread Emmanuel Bourg
Hi Timo,

Le 25/04/2019 à 19:37, Timo Aaltonen a écrit :

> I'd like to use the libexec scripts and policy files from the pki-server 
> systemd service file, but installing 'tomcat9' will start an instance and 
> then 'pkispawn' would fail because the (default) port is already used. So I 
> can't just depend on tomcat9, but maybe these files could be moved to -common 
> or -user?

Did you consider calling /usr/share/tomcat9/bin/catalina.sh (installed
by tomcat9-common) instead of reusing the libexec script that's focused
on the tomcat9 package needs? That should allow you to start a Tomcat
instance with the settings you want.

Emmanuel Bourg



Bug#926319: tomcat9: Variable expansion not supported in /etc/default/tomcat9

2019-06-02 Thread Emmanuel Bourg
Le 23/05/2019 à 18:58, Christian Hänsel a écrit :

> I did the following changes to use /etc/default/tomcat9 to enable
> debugging for tomcat9.
> 
> 1. modify tomcat-start.sh to load /etc/default/tomcat9
> 
> 2. removed environmentFiles from
> /etc/systemd/system/multi-user.target.wants/tomcat9.service

Thank you for the patch Christian. I'm going to apply it with a minor
difference, the default settings have to be loaded before the JVM is
located, otherwise the service will fail to start when the detection
fails, even if the JAVA_HOME variable is set in /etc/default/tomcat9.

Emmanuel Bourg



Bug#929903: [Pkg-openssl-devel] Bug#929903: openssl: m2crypto test case regression

2019-06-02 Thread Kurt Roeckx
On Sun, Jun 02, 2019 at 11:00:28PM +0200, Sebastian Andrzej Siewior wrote:
> Package: openssl
> Version: 1.1.1c-1
> Severity: serious
> 
> The m2crypto test suite fails with c, passes with b. The error log
>   
> https://ci.debian.net/data/autopkgtest/testing/amd64/m/m2crypto/2436983/log.gz
> 
> The testsuite complains about a missing error / the exception is not
> raised. The bisect says, this happens since
> 
> |commit f61c68043d3bd2ad9718d356e7988ee2fdfc3621
> | Author: Bernd Edlinger 
> | Date:   Thu Feb 28 10:08:18 2019 +0100
> | 
> | Fix memory overrun in rsa padding check functions
> | 
> | Fixes #8364 and #8357
> | 
> | Reviewed-by: Kurt Roeckx 
> | (Merged from https://github.com/openssl/openssl/pull/8365)
> | 
> | (cherry picked from commit d7f5e5ae6d53f1387a42d210806cf5e9ed0882d6)
> 
> Kurt, can you check if this is an error in the testsuite or something
> legal?

Looking at the log, this is about SSLv23 padding.

>From the review, Bernd wrote:
> While doing that I found an issue in RSA_padding_check_SSLv23
> It does the 03 check the wrong way round. But there is no test coverage,
> so it was not noticed.
[...]
> So, I added a small test for RSA_SSLV23_PADDING, as an extra commit,
> since it will likely not cherry-pick in stable branches.

It's about this change:
-good &= constant_time_lt(threes_in_row, 8);
+good &= constant_time_ge(threes_in_row, 8);

(That should probably have been a separate commit.)

Can you confirm that that is the reason for the change in
behaviour?

I don't understand the m2crypto code, so I have no idea what it's
testing.


Kurt



Bug#926338: tomcat9: tomcat user's home folder is '/'

2019-06-02 Thread Emmanuel Bourg
Le 03/04/2019 à 18:40, Alex a écrit :

> A problem begins when some of Tomcat's webapps are trying to access $HOME for 
> writing. That's completely another question about _why_ they want to write to 
> $HOME. But the whole idea having `/` as home dir is definitely insecure.

The previous tomcat8 package created a 'tomcat8' user with
/var/libtomcat8/ as its home directory. /var/libtomcat8/ was chmod 755
root:root, so if I'm not mistaken tomcat8 couldn't write to its home
directory either.

The new tomcat9 package now creates a generic 'tomcat' user with no
version in the name. It's no longer possible to use /var/lib/tomcat9 as
home directory, that would be problematic when the tomcat9 package is
replaced by tomcat10.

I admit using / as home directory isn't perfect, but I fail to see how
this can be considered insecure.

What about setting the -Duser.home JVM parameter when Tomcat is started
instead of changing the system user home?

Emmanuel Bourg



Bug#929906: RFP: node-evacuated-event-kit -- Simple library for implementing and consuming evented APIs

2019-06-02 Thread Jeff Cliff
Package: wnpp
Severity: wishlist

* Package name: node-event-kit
  Version : 2.5.0
  Upstream Author : Microsoft Github
* URL : https://github.com/atom/event-kit
* License : MIT
  Programming Lang: coffeescript
  Description : Simple library for implementing and consuming evented APIs

Allows for registering callbacks with multiple subscribers.
Allows for convenient ways to represent a resource you will no longer need at 
some point.

node-event-kit is a dependency of meteor ( #842425 ).



Bug#929905: fdroidserver: Packaged version of fdroidserver incompatible with upstream's repository

2019-06-02 Thread Nicolas Braud-Santoni
Package: fdroidserver
Version: 1.1.1-1
Severity: important

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear maintainer,

I installed fdroidserver hoping to contribute new package definitions
to FDroid's upstream repository.

Unfortunately, the metadata schema evolved since v1.1.1-1, in particular the
validation for the `Bitcoin` field changed, making `fdroid readmeta` fail on
an unmodified copy of FDroid's repository.

The same command completes successfully with the version of fdroidserver from
https://gitlab.com/fdroid/fdroidserver


Considering that this makes the FDroid Debian package unsuitable for 
contributing
to that repository, I am marking this bug as important.


Best regards,

  nicoo

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

Kernel: Linux 4.19.0-5-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) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set 
to en_US.UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fdroidserver depends on:
pn  androguard 
pn  default-jdk-headless | default-jdk | openjdk-7-jdk | openjdk-  
ii  python33.7.2-1
pn  python3-clint  
pn  python3-defusedxml 
pn  python3-git
ii  python3-libcloud   2.4.0-1
pn  python3-mwclient   
ii  python3-paramiko   2.4.2-0.1
ii  python3-pil5.4.1-2
ii  python3-pyasn1 0.4.2-3
pn  python3-pyasn1-modules 
pn  python3-qrcode 
ii  python3-requests   2.21.0-1
ii  python3-ruamel.yaml0.15.34-1+b1
pn  python3-vagrant
ii  python3-yaml   3.13-2
ii  rsync  3.1.3-6

Versions of packages fdroidserver recommends:
pn  android-sdk 
ii  apksigner   0.8-2
ii  git 1:2.20.1-2
ii  gnupg   2.2.12-1
pn  opensc  
ii  openssh-client  1:7.9p1-10
pn  s3cmd   
ii  wget1.20.1-1.1
pn  zipalign

Versions of packages fdroidserver suggests:
pn  gradle   
ii  qemu-kvm 1:3.1+dfsg-7
ii  vagrant  2.2.3+dfsg-1
pn  vagrant-cachier  
ii  vagrant-libvirt  0.0.45-2

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEU7EqA8ZVHYoLJhPE5vmO4pLV7MsFAlz0PKQRHG5pY29vQGRl
Ymlhbi5vcmcACgkQ5vmO4pLV7MsFZw/+OxlRuAgPSMSs9RM4lVR2vkFX5OGvv/SX
boMClC5eLfxDlssPC8UZtXcTttyWuiD8DhEq+xicr3wUC7jrzEJk4wqrjHOgwAmh
rGhoqvIEOhsYPzuuDaf0n8LLAd74/QDqc6TMZEuH0vVqw2oPbik9enfZHDft/ken
+1Lhon6Qy+tr29wlQ0wlEpQNEvz+0++4r2lmKumf7SleVhg7GkvKJ3fWjrmaltEW
kZmx3jqOIkDvH8r21aGEH0+lIpNsZnd04+ZGVGXlIXZ3+qzGLjct3EFikvN9pvc4
HKx9iXPKnllNdqhFXci3SGATcnpELX8YD7NZ/OS45G5xt6zc4i0/9/Ao/q9gDSnH
YQ39L42W0KbotYBFlVFuC9fxXPA77Jzu9TgNWI5aOQ95yvk0vgFggl2pLqOWHsFn
5zKCkN4ZcKshsAH1ZRIwcL+fDqmlvefd9swlvrvauVx6Cm2WSmIpGWIpWASdX9lH
k27KZS9bsS0PEPfp0X8P1vbbm+AP6uVzNIPi3MmEPm+omY4HJBZlFY2qYS72N/Ci
7uHgWDb+Jk1gB8DH+iL5fx44sBjBR5sT3UgylQad3C+gT/m2zv5DqQnKzvm4xzfv
TowEx5UfmiaOuoZ5XxXmfJGin+AR4z8FsJh17xDolyrY64y3BFFnnAn2qNFIBPWv
uMWBAHfTGe0=
=EuRA
-END PGP SIGNATURE-



Bug#929904: unblock: golang-github-mattn-go-isatty/0.0.7+really0.0.4-1

2019-06-02 Thread Dr. Tobias Quathamer
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package golang-github-mattn-go-isatty

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock golang-github-mattn-go-isatty/0.0.7+really0.0.4-1

Regards,
Tobias
diff -Nru golang-github-mattn-go-isatty-0.0.4/debian/changelog golang-github-mattn-go-isatty-0.0.7+really0.0.4/debian/changelog
--- golang-github-mattn-go-isatty-0.0.4/debian/changelog	2018-12-20 17:50:17.0 +0100
+++ golang-github-mattn-go-isatty-0.0.7+really0.0.4/debian/changelog	2019-06-02 23:10:40.0 +0200
@@ -1,3 +1,18 @@
+golang-github-mattn-go-isatty (0.0.7+really0.0.4-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert all changes between 0.0.4-1 and 0.0.7-1.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Sun, 02 Jun 2019 23:10:40 +0200
+
+golang-github-mattn-go-isatty (0.0.7-1) unstable; urgency=medium
+
+  * New upstream version 0.0.7
+  * Bump Standards-Version to 4.3.0 (no change)
+
+ -- Anthony Fok   Sun, 14 Apr 2019 04:05:57 -0600
+
 golang-github-mattn-go-isatty (0.0.4-1) unstable; urgency=medium
 
   [ Alexandre Viau ]


signature.asc
Description: OpenPGP digital signature


Bug#929903: openssl: m2crypto test case regression

2019-06-02 Thread Sebastian Andrzej Siewior
Package: openssl
Version: 1.1.1c-1
Severity: serious

The m2crypto test suite fails with c, passes with b. The error log
  https://ci.debian.net/data/autopkgtest/testing/amd64/m/m2crypto/2436983/log.gz

The testsuite complains about a missing error / the exception is not
raised. The bisect says, this happens since

|commit f61c68043d3bd2ad9718d356e7988ee2fdfc3621
| Author: Bernd Edlinger 
| Date:   Thu Feb 28 10:08:18 2019 +0100
| 
| Fix memory overrun in rsa padding check functions
| 
| Fixes #8364 and #8357
| 
| Reviewed-by: Kurt Roeckx 
| (Merged from https://github.com/openssl/openssl/pull/8365)
| 
| (cherry picked from commit d7f5e5ae6d53f1387a42d210806cf5e9ed0882d6)

Kurt, can you check if this is an error in the testsuite or something
legal?

Sebastian



Bug#929467: RFS: tfortune-1.0.0 [ITP]

2019-06-02 Thread Adam Borowski
On Sat, Jun 01, 2019 at 11:17:53PM +0200, Andre Noll wrote:
> Adam, do you want me to provide v3 with debian/rules changed to
> something like the above?

v2 still suffers from the non-standard perms on usr/ and so on, thus I guess
it'd be simpler to move to the dh workflow rather than to fix what you
currently have.

It's by no means mandatory, but our newly elected Dear Leader is waging a
campaign to make it strongly recommended, especially for new packages.  I
quite see why.  And I for one prefer packages where a reviewer doesn't have
to fire up the brain to comprehend what's being done. :)

(But again, it's no cdbs nor waf -- I'd gladly review either approach.)

> Note, however, that building with the simple debian/rules file prints a
> warning because dh_auto_configure seems to add --disable-silent-rules,
> --disable-maintainer-mode and --disable-dependency-tracking to the
> configure command line, which tfortune's configure doesn't know.

Yeah, it assumes autotools' quirks.  If that's a concern, you do:

override_dh_auto_configure:
dh_auto_configure --some --params

or:
override_dh_auto_configure:
./configure --foo --bar

The man page says:

# This is intended to work for about 90% of packages.  If it doesn't work,
# you're encouraged to skip using dh_auto_configure at all, and just run
# ./configure or its equivalent manually.

> This seems to be a common problem. One solution is to call configure
> directly, as recommended in the dh_auto_configure man page. Another way
> to avoid the warning is to provide noop-stubs for the three options
> in configure.ac. I'd prefer to call configure directly because this
> is a bit simpler and touches only debian/rules. Opinions anybody?

Either way would work.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ Latin:   meow 4 characters, 4 columns,  4 bytes
⣾⠁⢠⠒⠀⣿⡁ Greek:   μεου 4 characters, 4 columns,  8 bytes
⢿⡄⠘⠷⠚⠋  Runes:   ᛗᛖᛟᚹ 4 characters, 4 columns, 12 bytes
⠈⠳⣄ Chinese: 喵   1 character,  2 columns,  3 bytes <-- best!



Bug#929902: unblock: golang-golang-x-sys/0.0~git20190412.9773273+really0.0~git20181228.9a3f9b0-1

2019-06-02 Thread Dr. Tobias Quathamer
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package golang-golang-x-sys

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock 
golang-golang-x-sys/0.0~git20190412.9773273+really0.0~git20181228.9a3f9b0-1

Regards,
Tobias
diff -Nru golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/changelog golang-golang-x-sys-0.0~git20190412.9773273+really0.0~git20181228.9a3f9b0/debian/changelog
--- golang-golang-x-sys-0.0~git20181228.9a3f9b0/debian/changelog	2018-12-31 10:40:44.0 +0100
+++ golang-golang-x-sys-0.0~git20190412.9773273+really0.0~git20181228.9a3f9b0/debian/changelog	2019-06-02 22:39:17.0 +0200
@@ -1,3 +1,18 @@
+golang-golang-x-sys (0.0~git20190412.9773273+really0.0~git20181228.9a3f9b0-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert all changes between 0.0~git20181228.9a3f9b0-1
+and 0.0~git20190412.9773273-1, resulting in an absurd version number.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Sun, 02 Jun 2019 22:39:17 +0200
+
+golang-golang-x-sys (0.0~git20190412.9773273-1) unstable; urgency=medium
+
+  * New upstream version 0.0~git20190412.9773273
+
+ -- Anthony Fok   Sun, 14 Apr 2019 03:43:01 -0600
+
 golang-golang-x-sys (0.0~git20181228.9a3f9b0-1) unstable; urgency=medium
 
   * New upstream version 0.0~git20181228.9a3f9b0


signature.asc
Description: OpenPGP digital signature


Bug#927126: Fwd: Bug#929342: unblock: aqemu/0.9.2-2.2

2019-06-02 Thread Alexis Murzeau
Le 28/05/2019 à 00:16, Alexis Murzeau a écrit :
> Le 27/05/2019 à 21:58, Alexis Murzeau a écrit :
>> Le 27/05/2019 à 08:02, Abhijith PA a écrit :
>>> On 26 May 2019 4:01:33 PM IST, Alexis Murzeau  wrote:

 Ok, I have changed them to use what's is in the qemu-system manpage.
 Here is the commit on salsa: [0]


 Also, while aqemu will be able to run qemu again, I think it won't be
 able to create multiple virtual hub as the command line option "-net
 nic" only use the default hub ID 0.

 I don't know if this a serious issue that should be fixed too.
 In the meanwhile, I guess aqemu will still be able to create multiple
 nic but all of them will be connected to the same default hub.

 What do you think of this ?
>>>
>>> What is the upstream preferred way of doing this ? 
>>>
 [0]
 https://salsa.debian.org/amurzeau-guest/aqemu/commit/26087ea3c3700bc5a019ae8cc0f84eb14954ef3d
>>>
>>
>> I didn't ask upstream about it but given the last commit is in 2017 and
>> the change I've backported was partly made by someone else in a fork, I
>> don't expect any response from upstream.
>>
>> I think updating aqemu to be able to create multiple virtual hub again
>> is possible but would require more changes than a small patch. I think
>> it would require to remove the use of old -net option of qemu to the
>> newer -netdev.
>>
> 
> For reference, the original issue about the vlan argument was also
> reported upstream in 09/2018 as:
> https://github.com/tobimensch/aqemu/issues/58
> 
> I'm not an aqemu user myself, but if you think that's ok anyway as at
> least configurations with single nic are working now, I've uploaded the
> package on mentors, here is the dsc link:
> 
> https://mentors.debian.net/debian/pool/main/a/aqemu/aqemu_0.9.2-2.3.dsc
> 

Hi,

Did you have any chance to look at this ? Is this upload ok ?

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



signature.asc
Description: OpenPGP digital signature


Bug#929901: unblock: golang-golang-x-image/0.0~git20190321.3fc05d4+really0.0~git20181116.cd38e80-1

2019-06-02 Thread Dr. Tobias Quathamer
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package golang-golang-x-image

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock 
golang-golang-x-image/0.0~git20190321.3fc05d4+really0.0~git20181116.cd38e80-1

Regards,
Tobias



signature.asc
Description: OpenPGP digital signature


Bug#929697: pyglet: diff for NMU version 1.3.0-2.1

2019-06-02 Thread Reinhard Tartler
Control: tags 929697 + patch
Control: tags 929697 + pending

Dear maintainer,

I've prepared an NMU for pyglet (versioned as 1.3.0-2.1) and uploaded
it to DELAYED/2-days. Please feel free to tell me if I should delay it
longer.

Please note that this upload is *not* suitable for buster, as there
are many changes from 1.3.0-1 to 1.3.0-2 (including a conversion from
CDBS to dh) that don't meet the release team's criteria for updates to
buster this late in the game. This patch may need to be uploaded to
testing-proposed-updates separately.

Regards,
-rt

diff -Nru pyglet-1.3.0/debian/changelog pyglet-1.3.0/debian/changelog
--- pyglet-1.3.0/debian/changelog   2019-03-01 22:45:26.0 -0500
+++ pyglet-1.3.0/debian/changelog   2019-06-02 15:17:34.0 -0400
@@ -1,3 +1,14 @@
+pyglet (1.3.0-2.1) unstable; urgency=medium
+
+  [ Yaroslav Halchenko ]
+  * No strings exceptions is allowed in Python2.6
+
+  [ Reinhard Tartler ]
+  * Non-Maintainer upload.
+  * Disable ClockTimingTestCase (Closes: #929697)
+
+ -- Reinhard Tartler   Sun, 02 Jun 2019 15:17:34 -0400
+
 pyglet (1.3.0-2) unstable; urgency=medium
 
   [ Scott Kitterman ]
diff -Nru pyglet-1.3.0/debian/rules pyglet-1.3.0/debian/rules
--- pyglet-1.3.0/debian/rules   2019-03-01 21:13:15.0 -0500
+++ pyglet-1.3.0/debian/rules   2019-06-02 15:17:34.0 -0400
@@ -20,6 +20,8 @@
 EXCLUDED_TESTS += and not test_issue429
 EXCLUDED_TESTS += and not test_issue241
 EXCLUDED_TESTS += and not test_issue471
+# cf. #929697
+EXCLUDED_TESTS += and not ClockTimingTestCase
 
 export PYBUILD_NAME=pyglet
 export PYBUILD_TEST_PYTEST=1



Bug#929900: unblock: golang-github-spf13-jwalterweatherman/1.1.0+really1.0.0+git20181028.94f6ae3-1

2019-06-02 Thread Dr. Tobias Quathamer
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package golang-github-spf13-jwalterweatherman

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock 
golang-github-spf13-jwalterweatherman/1.1.0+really1.0.0+git20181028.94f6ae3-1

Regards,
Tobias
diff -Nru golang-github-spf13-jwalterweatherman-1.0.0+git20181028.94f6ae3/debian/changelog golang-github-spf13-jwalterweatherman-1.1.0+really1.0.0+git20181028.94f6ae3/debian/changelog
--- golang-github-spf13-jwalterweatherman-1.0.0+git20181028.94f6ae3/debian/changelog	2018-12-20 07:44:44.0 +0100
+++ golang-github-spf13-jwalterweatherman-1.1.0+really1.0.0+git20181028.94f6ae3/debian/changelog	2019-06-02 22:15:50.0 +0200
@@ -1,3 +1,18 @@
+golang-github-spf13-jwalterweatherman (1.1.0+really1.0.0+git20181028.94f6ae3-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert all changes between 1.0.0+git20181028.94f6ae3-1 and 1.1.0-1.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Sun, 02 Jun 2019 22:15:50 +0200
+
+golang-github-spf13-jwalterweatherman (1.1.0-1) unstable; urgency=medium
+
+  * New upstream version 1.1.0
+  * Bump Standards-Version to 4.3.0 (no change)
+
+ -- Anthony Fok   Sun, 14 Apr 2019 03:37:34 -0600
+
 golang-github-spf13-jwalterweatherman (1.0.0+git20181028.94f6ae3-1) unstable; urgency=medium
 
   * New upstream version 1.0.0+git20181028.94f6ae3, required by hugo (>= 0.50)


signature.asc
Description: OpenPGP digital signature


Bug#929899: unblock: ruby2.5/2.5.5-3

2019-06-02 Thread Antonio Terceiro
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package ruby2.5

2.5.5-3 contains just a patch to make it build on ia64.

the diff against the package in testing is attached.

unblock ruby2.5/2.5.5-3

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=pt_BR.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), 
LANGUAGE=pt_BR:pt:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff --git a/debian/changelog b/debian/changelog
index 5cab009b..d6eaca0d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+ruby2.5 (2.5.5-3) unstable; urgency=medium
+
+  * ia64: Don't clear register_stack_start (Closes: #928068)
+
+ -- Antonio Terceiro   Sun, 02 Jun 2019 10:16:57 -0300
+
 ruby2.5 (2.5.5-2) unstable; urgency=medium
 
   * debian/tests/excludes/: fix exclusion of Rinda tests that depend on
diff --git a/debian/patches/0011-ia64-Don-t-clear-register_stack_start.patch b/debian/patches/0011-ia64-Don-t-clear-register_stack_start.patch
new file mode 100644
index ..ed43e467
--- /dev/null
+++ b/debian/patches/0011-ia64-Don-t-clear-register_stack_start.patch
@@ -0,0 +1,25 @@
+From: James Clarke 
+Date: Fri, 26 Apr 2019 23:32:46 +0100
+Subject: ia64: Don't clear register_stack_start
+
+r59829 stopped clearing stack_start and enabled the code for
+!FIBER_USE_NATIVE, but we need to do the same for register_stack_start
+on ia64, otherwise we end up with NULL in cont_save_machine_stack.
+
+Closes: https://github.com/ruby/ruby/pull/2155
+---
+ cont.c | 1 -
+ 1 file changed, 1 deletion(-)
+
+diff --git a/cont.c b/cont.c
+index 7b6864a..8ad8207 100644
+--- a/cont.c
 b/cont.c
+@@ -543,7 +543,6 @@ cont_save_thread(rb_context_t *cont, rb_thread_t *th)
+ sec->machine.stack_end = NULL;
+ 
+ #ifdef __ia64
+-sec->machine.register_stack_start = NULL;
+ sec->machine.register_stack_end = NULL;
+ #endif
+ }
diff --git a/debian/patches/series b/debian/patches/series
index e0cb0602..a6319c31 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@
 0008-Disable-tests-failing-on-Ubuntu-builders.patch
 0009-test-test_pair-fix-deadlock-in-test_connect_accept_n.patch
 0010-test-use-larger-keys-for-SSL-tests.patch
+0011-ia64-Don-t-clear-register_stack_start.patch


signature.asc
Description: PGP signature


Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Holger Wansing

Hi,

Am Sonntag, 2. Juni 2019 schrieb Samuel Thibault:
> ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit:
> > >> "لاحقاً"
> > 
> > This word means "later" and can be replaced by "لاحقا".
> 
> That avoids the issue here indeed. I however see it used in various

Hmm.
There has been no changing in the ar.po of partman-auto
for 3 years now (JFTR), thus the real problem seems to be
sitting somewhere else ...



Holger 

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#929898: unblock: golang-github-spf13-afero/1.2.2+really1.2.1-1

2019-06-02 Thread Dr. Tobias Quathamer
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package golang-github-spf13-afero

This is part of the effort to re-sync golang package versions in
unstable and testing, see https://bugs.debian.org/928227

unblock golang-github-spf13-afero/1.2.2+really1.2.1-1

Regards,
Tobias
diff -Nru golang-github-spf13-afero-1.2.1/debian/changelog golang-github-spf13-afero-1.2.2+really1.2.1/debian/changelog
--- golang-github-spf13-afero-1.2.1/debian/changelog	2019-02-01 19:08:02.0 +0100
+++ golang-github-spf13-afero-1.2.2+really1.2.1/debian/changelog	2019-06-02 22:02:04.0 +0200
@@ -1,3 +1,17 @@
+golang-github-spf13-afero (1.2.2+really1.2.1-1) unstable; urgency=medium
+
+  * Team upload.
+  * Revert all changes between 1.2.1-1 and 1.2.2-1.
+See https://bugs.debian.org/928227 for a rationale.
+
+ -- Dr. Tobias Quathamer   Sun, 02 Jun 2019 22:02:04 +0200
+
+golang-github-spf13-afero (1.2.2-1) unstable; urgency=medium
+
+  * New upstream version 1.2.2
+
+ -- Anthony Fok   Sun, 14 Apr 2019 03:20:52 -0600
+
 golang-github-spf13-afero (1.2.1-1) unstable; urgency=medium
 
   * New upstream version 1.2.1


signature.asc
Description: OpenPGP digital signature


Bug#929897: node-js-beautify: Missing dependency on node-lru-cache

2019-06-02 Thread Leandro Lisboa Penz
Package: node-js-beautify
Version: 1.7.5+dfsg-3
Severity: important

Dear Maintainer,

html-beautify was throwing because lru-cache was not found.

Installing node-lru-cache fixed the problem.


-- System Information:
Debian Release: 10.0
  APT prefers testing
  APT policy: (520, 'testing'), (510, 'stable'), (150, 'unstable'), (120, 
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages node-js-beautify depends on:
ii  node-config-chain  1.1.11-1
ii  node-mkdirp0.5.1-1
ii  node-nopt  3.0.6-3
ii  node-semver5.5.1-1
ii  node-sigmund   1.0.0-1
ii  nodejs 10.15.2~dfsg-2

Versions of packages node-js-beautify recommends:
ii  jsbeautifier  1.6.4-7

node-js-beautify suggests no packages.

-- no debconf information



Bug#929896: diffutils: diff -r found devnodes of same minor/major as different in some cases

2019-06-02 Thread Ludovic Pouzenc

Package: diffutils
Version: 1:3.7-3
Severity: minor

Dear Maintainer,

I found a diff strangeness by accident while diffing two chroot trees.
It seems to be always reproductible for me, at least on this example :

root@lud-mn1:~# mkdir a b c; mknod a/null c 1 3; sleep .1; mknod b/null 
c 1 3; sleep 1; mknod c/null c 1 3


diffing the files 2 by 2 on one side, and diffing the folders 2 by 2 on
other side give different results. I was expecting all following commands
to give a 0 return code and no output :

root@lud-mn1:~# LANG=C diff a/null b/null; echo $?
0
root@lud-mn1:~# LANG=C diff b/null c/null; echo $?
0
root@lud-mn1:~# LANG=C diff -r a b; echo $?
0
root@lud-mn1:~# LANG=C diff -r b c; echo $?
File b/null is a character special file while file c/null is a character 
special file

1

For completeness, stat output to show that all timestamps are different.
I am on a regular ext4 mountpoint.

root@lud-mn1:~# LANG=C stat ?/null
  File: a/null
  Size: 0     Blocks: 0  IO Block: 4096   character 
special file

Device: 807h/2055d    Inode: 522435  Links: 1 Device type: 1,3
Access: (0644/crw-r--r--)  Uid: (    0/    root)   Gid: (    0/ root)
Access: 2019-06-02 21:39:41.061736947 +0200
Modify: 2019-06-02 21:39:41.061736947 +0200
Change: 2019-06-02 21:39:41.061736947 +0200
 Birth: -
  File: b/null
  Size: 0     Blocks: 0  IO Block: 4096   character 
special file

Device: 807h/2055d    Inode: 547588  Links: 1 Device type: 1,3
Access: (0644/crw-r--r--)  Uid: (    0/    root)   Gid: (    0/ root)
Access: 2019-06-02 21:39:41.165737120 +0200
Modify: 2019-06-02 21:39:41.165737120 +0200
Change: 2019-06-02 21:39:41.165737120 +0200
 Birth: -
  File: c/null
  Size: 0     Blocks: 0  IO Block: 4096   character 
special file

Device: 807h/2055d    Inode: 547590  Links: 1 Device type: 1,3
Access: (0644/crw-r--r--)  Uid: (    0/    root)   Gid: (    0/ root)
Access: 2019-06-02 21:39:42.165738785 +0200
Modify: 2019-06-02 21:39:42.165738785 +0200
Change: 2019-06-02 21:39:42.165738785 +0200
 Birth: -
root@lud-mn1:~# LANG=C df -h .
Filesystem  Size  Used Avail Use% Mounted on
/dev/sda7    16G   14G  1.3G  92% /
root@lud-mn1:~# mount | grep ^/dev/sda7
/dev/sda7 on / type ext4 (rw,noatime,discard,errors=remount-ro)

This clearly do not cause real important troubles to me. But may be
nasty for containers fans.


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/6 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)

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

Versions of packages diffutils depends on:
ii  libc6  2.28-10

diffutils recommends no packages.

Versions of packages diffutils suggests:
pn  diffutils-doc  
pn  wdiff  

-- no debconf information



Bug#929172: Same issue as already reported, and partially fixed

2019-06-02 Thread Ludovic Pouzenc
I can confirm that packages landed in unstable solve the situation for 
me (libdebian-installer4 0.119, cdebootstrap 0.7.7+b12, 
cdebootstrap-static 0.7.7+b12).


At time if writing, it's seem not landed in testing yet.

Thanks to all involved people.

--
Ludovic Pouzenc
www.pouzenc.fr

This is GNU/Linux land. In silent nights you can hear the Windows machines 
rebooting.



Bug#916610: Upstream patch, NMU available

2019-06-02 Thread Jakob Haufe
Control: tags -1 + patch upstream

There's an upstream commit[1] fixing this issue. I've prepared an NMU
and uploaded it to mentors [2].

I would like to try and get it sponsored and uploaded to the DELaYED
queue and ideally get it unblocked for buster.

Cheers,
sur5r

[1] 
https://github.com/FreeSpacenav/spacenavd/commit/34ddda1246ad07e8ff2e6606224e710852e3e3d8
[2] https://mentors.debian.net/package/spacenavd


-- 
ceterum censeo microsoftem esse delendam.


pgpYEric3xNNj.pgp
Description: OpenPGP digital signature


Bug#929895: tomcat9: CVE-2019-0221

2019-06-02 Thread Salvatore Bonaccorso
Source: tomcat9
Version: 9.0.16-3
Severity: normal
Tags: security upstream

Hi,

The following vulnerability was published for tomcat9.

CVE-2019-0221[0]:
| The SSI printenv command in Apache Tomcat 9.0.0.M1 to 9.0.0.17, 8.5.0
| to 8.5.39 and 7.0.0 to 7.0.93 echoes user provided data without
| escaping and is, therefore, vulnerable to XSS. SSI is disabled by
| default. The printenv command is intended for debugging and is
| unlikely to be present in a production website.


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-0221
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-0221

Regards,
Salvatore



Bug#929894: firefox-esr: Does not work with basque eID

2019-06-02 Thread Roman Muñoz
Package: firefox-esr
Version: 60.6.3esr-1
Severity: normal

Dear Maintainer,

Firefox from mozilla.org works fine with basque eID (Izenpe, uses bit4id
propietary stuff) but firefox-esr from Debian repositories doesn't. This
affects at least Stretch and Buster amd64.

With firefox from mozilla.org, all I need is to install pcscd and bit4id stuff.
Then I need to create a new device in firefox's preferences, give the path to
/usr/lib/bit4id/libbit4xpki.so, then go to some website that requires a
certificate, the window to choose the cerificate appears, I accept and ...
then, I'm in.

With firefox from debian repositories, this is the same, but instead of getting
in, firefox hangs, proccesses have to be killed, and, some minutes after that,
crash report window could appear. I say "could" because, after installing a
second firefox, crash report window does not appear anymore. ?

Izenpe root certs are already on firefox-esr, there is a package with
additional certs that can be downloaded and installed, but thats not necessary
to get the basic functionality, just to make firefox able to verify our own
personal certificate.

To sign documents, emails, etc, there is a third package, idazki.desktop,
including his own java virtual machine; this does work with both firefoxes.

Best regards




-- Package-specific info:


-- Addons package information

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8), 
LANGUAGE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/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-10
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.3-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#929887: /usr/lib/qgis/crssync: error while loading shared libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such file or directory

2019-06-02 Thread 積丹尼 Dan Jacobson
All I know is e.g., with perl this bug would never happen.

# apt-cache policy perl
perl:
  Installed: 5.28.1-6
  Candidate: 5.30.0-1
  Version table:
 5.30.0-1 990
990 http://opensource.nchc.org.tw/debian experimental/main amd64 
Packages
 *** 5.28.1-6 500
500 http://opensource.nchc.org.tw/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status

That's because the perl team have got the dependencies all correct so
that apt(itude) won't let me upgrade it yet until all the pieces are
ready!



Bug#832980: related openbox and obsession are not in sync

2019-06-02 Thread PICCORO McKAY Lenz
package openbox (3.6.1-8) unstable; tries to fix and close the bug
#888254 but was incorrectly closed..

tested and try to set OnlyShowIn=Openbox; of OnlyShowIn=OPENBOX; does
not work due the vars environment are not set in nowhere..

why the Debian need so many burocratic things to property fix the things?



-- 
Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com



Bug#929892: vfat mounts are not protected

2019-06-02 Thread Dark Penguin
Package: bilibop-lockfs
Version: 0.5.6

In lockfs mode, if there are any vfat mounts to be protected, they are
ignored and simply mounted as read-write. Everything else is properly
protected with overlayfs.

Isn't it kind of dangerous?.. The user is expecting everything to be safe!

If it is not possible to protect a vfat filesystem due to overlayfs
limitations, then maybe it should be mounted read-only instead of
read-write? At least then the user will notice it before breaking
something, and add it to the whitelist if they want it read-write,
easily replicating the current behaviour. And currently, there is no way
to do the opposite - which is, "in lockfs mode, mount everything that
can not be properly protected as read-only".


This is reproducible on Debian Buster amd64 , and also on Raspbian
Stretch with bilibop 0.5.6 from Debian Buster armhf.


-- 
darkpenguin



Bug#929893: Emergency shell due to broken parsing

2019-06-02 Thread Dark Penguin
Package: bilibop-lockfs
Version: 0.5.6


Steps to reproduce:

# apt-get install bilibop --no-install-recommends

Now, add a single line to the bottom of /etc/bilibop/bilibop.conf :

BILIBOP_LOCKFS_WHITELIST=/anything

It does not matter if this directory exists or not. Now do an
"update-initramfs -u -k all", and reboot. You won't be able to boot,
because all mounts except "/" will fail, giving you an emergency shell.

Attempting to mount one of them manually (by "mount /mydir") gives me
the following result:

/sbin/mount.lockfs: 1: eval: net.ifnames=0: not found

This is apparently a part of my kernel command line. Here it is, just in
case:

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64
root=UUID=64e67ea6-1627-4258-9c70-8bcc120daf86 ro console=tty1
console=ttyS0 ipv6.disable=1 net.ifnames=0 consoleblank=0 lockfs


This is reproducible on Debian Buster amd64 and Raspbian Stretch with
bilibop 0.5.6 from Debian Buster armhf.

Other lines in bilibop.conf work fine, only the "whitelist" one seems to
break things. However, whitelisting other mounts or marking them
"noauto" in /etc/fstab seems to help, despite the option itself being
the source of the problem. %)


-- 
darkpenguin



Bug#929887: /usr/lib/qgis/crssync: error while loading shared libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such file or directory

2019-06-02 Thread Sebastiaan Couwenberg
On 6/2/19 8:32 PM, 積丹尼 Dan Jacobson wrote:
> SC> The order is irrelevant, you probably still have customized priories
> SC> where you prefer experimental over unstable like you did before.
> 
> Ah, yes, with
> APT::Default-Release "experimental"
> I bet you can reproduce it.

Probably, but that is nonsensical configuration. experimental is an
overlay of unstable and has NotAutomatic: yes for a reason. You need to
install packages from experimental on-demand only.

Set the default release to unstable to have a proper system.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#929891: Error message about udev rules not found

2019-06-02 Thread Dark Penguin
Package: bilibop-rules
Version: 0.5.6

After installing bilibop, even without enabling lockfs, I see this error
message during the boot process:

---
Begin: Running /scripts/local-bottom ... Warning: bilibop-lockfs:
Nothing to do.
ls: /root/etc/udev/rules.d/70-persistent-cd.rules: No such file or directory
ls: /root/etc/udev/rules.d/70-persistent-net.rules: No such file or
directory
done.
---


With lockfs enabled, it is still there:

---
Begin: Running /scripts/local-bottom ... Warning: bilibop-lockfs:
Locking files.
Begin: bilibop-lockfs: Setting up overlay branches ... done.
Success: bilibop-lockfs: Root filesystem is now locked (soft policy).
Warning: bilibop-lockfs: Modifying temporary static filesystem table
(fstab).
ls: /root/etc/udev/rules.d/70-persistent-cd.rules: No such file or directory
ls: /root/etc/udev/rules.d/70-persistent-net.rules: No such file or
directory
done.
---


This is reproducible on Debian Buster amd64, and I saw it on Raspbian
Stretch with bilibop 0.5.6 from Debian Buster armhf.

I don't see any negative consequence of this, other than making the user
scared a little, but it is still an error message meant to be noticed.
Maybe it will help find other bugs. :)


-- 
darkpenguin



Bug#929890: Error during installation and uninstallation

2019-06-02 Thread Dark Penguin
Package: bilibop-rules
Version: 0.5.6

During installation AND uninstallation, I see the following error message:

---
Setting up bilibop-rules (0.5.6) ...
dpkg: error: --compare-versions takes three arguments: 
 

Type dpkg --help for help about installing and deinstalling packages [*];
Use 'apt' or 'aptitude' for user-friendly package management;
Type dpkg -Dhelp for a list of dpkg debug flag values;
Type dpkg --force-help for a list of forcing options;
Type dpkg-deb --help for help about manipulating *.deb files;

Options marked [*] produce a lot of output - pipe it through 'less' or
'more' !
---

I don't see any other negative effect of this, but an error message is
there for someone to notice, so I noticed it. :)

This is reproducible on Debian Buster amd64 (debootstrapped installation
in qemu), and Raspbian Stretch with bilibop 0.5.6 from Debian Buster armhf.


-- 
darkpenguin



Bug#929887: /usr/lib/qgis/crssync: error while loading shared libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such file or directory

2019-06-02 Thread 積丹尼 Dan Jacobson
SC> The order is irrelevant, you probably still have customized priories
SC> where you prefer experimental over unstable like you did before.

Ah, yes, with
APT::Default-Release "experimental"
I bet you can reproduce it.

SC> Also disable all third-party repositories. If you are only using
SC> sid/experimental the issue you reported is not possible.

deb http://opensource.nchc.org.tw/debian/ experimental main contrib non-free
deb http://opensource.nchc.org.tw/debian/ unstable main contrib non-free



Bug#929887: /usr/lib/qgis/crssync: error while loading shared libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such file or directory

2019-06-02 Thread Sebastiaan Couwenberg
On 6/2/19 7:52 PM, 積丹尼 Dan Jacobson wrote:
> B> sid (with or without experimental).
>^^^  
> Yes, that was what I was using.
> And I had experimental first in sources.list.

The order is irrelevant, you probably still have customized priories
where you prefer experimental over unstable like you did before.

Also disable all third-party repositories. If you are only using
sid/experimental the issue you reported is not possible.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1



Bug#929889: debootstrap: Support unconventional PATH on foreign distros

2019-06-02 Thread Vagrant Cascadian
Package: debootstrap
Version: 1.0.114
Severity: normal

The following patch fixes issues when the hard-coded 
PATH=/sbin:/usr/sbin:/bin:/usr/bin does not contain chroot or other
commonly used utilities, by changing to PATH=$PATH:/sbin:...

live well,
  vagrant

From 05a3241df281608b710c71e41d9a03d99cc68109 Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Sun, 2 Jun 2019 10:57:29 -0700
Subject: [PATCH] Support distros with unconventional PATH values by adding
 $PATH to calls in in_target_failmsg and in_target_nofail.

Add the $PATH environment variable to the chroot call, otherwise this
fails on foreign distros where PATH=/sbin:/usr/sbin:/bin:/usr/bin does
not contain common utilities such as chroot and other used utilities.
---
 functions | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/functions b/functions
index 6b93617..ed3fc99 100644
--- a/functions
+++ b/functions
@@ -1041,7 +1041,7 @@ extract () { (
 ); }
 
 in_target_nofail () {
-	if ! PATH=/sbin:/usr/sbin:/bin:/usr/bin eval "$CHROOT_CMD \"\$@\"" 2>/dev/null; then
+	if ! PATH=$PATH:/sbin:/usr/sbin:/bin:/usr/bin eval "$CHROOT_CMD \"\$@\"" 2>/dev/null; then
 		true
 	fi
 	return 0
@@ -1053,7 +1053,7 @@ in_target_failmsg () {
 	msg="$2"
 	arg="$3"
 	shift; shift; shift
-	if ! PATH=/sbin:/usr/sbin:/bin:/usr/bin eval "$CHROOT_CMD \"\$@\""; then
+	if ! PATH=$PATH:/sbin:/usr/sbin:/bin:/usr/bin eval "$CHROOT_CMD \"\$@\""; then
 		warning "$code" "$msg" "$arg"
 		# Try to point user at actual failing package.
 		msg="See %s for details"
-- 
2.20.1



signature.asc
Description: PGP signature


Bug#929887: closed by Sebastiaan Couwenberg (Re: Bug#929887: /usr/lib/qgis/crssync: error while loading shared libraries: libhdf5_serial_hl.so.100: cannot open shared object file:

2019-06-02 Thread 積丹尼 Dan Jacobson
B> sid (with or without experimental).
   ^^^  
Yes, that was what I was using.
And I had experimental first in sources.list.

B> And purge packages not available in the archive of the chosen release.

# aptitude search ~o | wc -l
0



Bug#929888: unbound: Debian's unbound.conf doesn't behave predictably due to use of GLOB_NOSORT

2019-06-02 Thread maney
Package: unbound
Version: 1.6.0-3+deb9u2
Severity: important

tl;dr: unbound's include: path/*.conf does not use a stable, sorted
ordering of matching files, so Debian's /etc/unbound/unbound.conf does not
load parts from /etc/unbound/unbound.conf.d ditto.

tl;dr;workaround: flatten config parts with dependencies into the
depended-upon file, or use explicit include: statements to load them from
that file.  The latter seemed to require absolute paths when I tried it, but
maybe I was doing it rong.


Debian installs an /etc/unbound.conf which, in keeping with common Debian
practice, is designed to gather most of the configuration from conf files in
/etc/unbound.conf.d (this is not the setup that upstream teaches).  As a
long-time Debian user, I was pleased to see this, and proceeded to make use
of the facility, splitting the config for two local "zones" into separate
files, with some common local-zone config in a third one.  By luck, the
files happened to be loaded in the proper order when I tested all this on a
spare machine...  and I thought it was because the *.conf files were being
loaded in the usual sorted order that other Debian packages with a config.d
setup use.

When I copied (and modified) the local setup to another machine for actual
use, however, I learned that unbound does NOT process included files in this
sensible, predictable order.  Instead, they take the trouble to apply the
GLOB_UNSORTED flag to the glob() call, resulting in behavior which is
surprising for parts in a config.d in Debian.

Since (as best I can make out), the whole unbound.conf.d is entirely a
Debian addition, to make unbound fit better into Debian conventions, I think
it's important to make it work consistently with Debian conventions, or at
least to add a warning about the unexpected random loading order that the
current [stable/stretch] unbound.conf has for those conf files.

The unwanted flag is set in unbind's util/config_file.c, and that was as
deep as I dug into this before flattening the config to get it going.

Thanks!


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

Kernel: Linux 4.19.0-0.bpo.5-amd64 (SMP w/12 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 unbound depends on:
ii  adduser  3.115
ii  dns-root-data2019031302~deb9u1
ii  init-system-helpers  1.48
ii  libc62.24-11+deb9u4
ii  libevent-2.0-5   2.0.21-stable-3
ii  libfstrm00.3.0-1
ii  libprotobuf-c1   1.2.1-2
ii  libpython3.5 3.5.3-1+deb9u1
ii  libssl1.11.1.0j-1~deb9u1
ii  openssl  1.1.0j-1~deb9u1
ii  unbound-anchor   1.6.0-3+deb9u2

unbound recommends no packages.

Versions of packages unbound suggests:
ii  apparmor  2.11.0-3+deb9u2

-- no debconf information



Bug#929887: Dependencies not tightened up

2019-06-02 Thread 積丹尼 Dan Jacobson
OK,
# aptitude -t sid install qgis
fixed it. That means there are dependency issues.

Reproduce with
# cat /etc/apt/sources.list
deb ... experimental ...
deb ... unstable ...



Bug#921688: Updates

2019-06-02 Thread Antoine Amarilli
Hi,

Are there any updates on packaging a new version of electrum in Debian?

Many thanks for your work on this!

Best,

-- 
Antoine Amarilli



Bug#929887: /usr/lib/qgis/crssync: error while loading shared libraries: libhdf5_serial_hl.so.100: cannot open shared object file: No such file or directory

2019-06-02 Thread 積丹尼 Dan Jacobson
Package: qgis-providers
Version: 3.4.8+dfsg-1
Severity: critical

Setting up qgis-providers (3.4.8+dfsg-1) ...
/usr/lib/qgis/crssync: error while loading shared libraries: 
libhdf5_serial_hl.so.100: cannot open shared object file: No such file or 
directory
dpkg: error processing package qgis-providers (--configure):
 installed qgis-providers package post-installation script subprocess returned 
error exit status 127
dpkg: dependency problems prevent configuration of qgis:
 qgis depends on qgis-providers (= 3.4.8+dfsg-1); however:
  Package qgis-providers is not configured yet.



Bug#929828: unblock: cryptsetup/2:2.1.0-4

2019-06-02 Thread Cyril Brulebois
Paul Gevers  (2019-06-02):
> Control: tags -1 confirmed
> 
> On 01-06-2019 12:10, Guilhem Moulin wrote:
> > Debdiff between 2:2.1.0-3 and 2:2.1.0-4 attached.  This also includes a
> > patch by jmtd fixing the long description of cryptsetup-{bin,run}.  The
> > diff doesn't touch our .udeb binary packages, but X-Debbugs-CC'ing kibi
> > anyway as cryptsetup is also under udeb-block.
> > 
> > unblock cryptsetup/2:2.1.0-4
> 
> I'm fine with this. I'll unblock after the ack of kibi as I am not sure
> about checking the udeb part myself (an area that I still have to learn).

The proposed change seems reasonable. And yeah, had it been impacting
MODULES=most, I would have seen this long ago, as encrypted LVM is one
of the basic scenarios I run on a regular basis and before all releases.

Regarding the udeb part, debdiffing udebs before/after the change is
usually sufficient to spot changes. I use DEBDIFF_CONTROLFILES=ALL in
~/.devscripts for all debdiff calls (udeb and non-udeb), to make sure I
notice all changes.


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


signature.asc
Description: PGP signature


Bug#765448: [Pkg-libvirt-maintainers] Bug#765448: libvirt-daemon-system is not installable on non-systemd system

2019-06-02 Thread sergio
On 01/06/2019 21:14, Guido Günther wrote:
> control tags -1 +wontfix

> For the record this is due to policykit-1 -> libpam-systemd ->
> systemd-shim | systemd-sysv dependency.

> So it *was* installable but isn't since nobody stepped up to maintain
> systemd-shim. Fix that and it will work.

It should not depend on policykit-1, as on gentoo libvirt works without
policykit or systemd.


-- 
sergio.



Bug#928807: unblock: mesa/18.3.6-2

2019-06-02 Thread Andreas Boll
Hi Paul,

On Thu, May 30, 2019 at 09:58:14PM +0200, Paul Gevers wrote:
> Control: tags -1 moreinfo
> 
> Hi Andreas,
> 
> On Sat, 11 May 2019 16:43:45 +0200 Andreas Boll  wrote:
> > This unblock request contains a stable upstream release with lots of
> > bug fixes for mesa's graphics drivers including fixes for driver
> > crashes and visual corruption. It fixes two RC bugs (#922346,
> > #926857).
> 
> How would a targeted fix look like? New upstream releases don't meet the
> freeze policy and the diff is way to big to properly review.
> 
> Paul
> 

Mesa upstream is very conservative in which patches it includes into
its stable releases. Those cherry-picked patches are all targeted
fixes. No new features and also no huge fixes are allowed. See also
[1]. They also do lots of regression testing on those stable releases.

I'd be in favor of taking all fixes from the upstream stable release
and not only just those which explicitly fix reported Debian RC bugs.

I'd recommend to review the git branch patch by patch instead of the
whole diff at once. Those patches have good commit messages which help
to review the patches.

E.g.
git clone https://salsa.debian.org/xorg-team/lib/mesa.git
cd mesa
gitk mesa-18.3.4-2..mesa-18.3.6-2

Does this help?

Thanks,
Andreas

[1] https://mesa3d.org/submittingpatches.html#criteria



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
ButterflyOfFire, le dim. 02 juin 2019 15:43:41 +, a ecrit:
> >> "لاحقاً"
> 
> This word means "later" and can be replaced by "لاحقا".

That avoids the issue here indeed. I however see it used in various
places, notably in the grub installer:

msgid ""
"Warning: If the installer failed to detect another operating system that is "
"present on your computer, modifying the master boot record will make that "
"operating system temporarily unbootable, though GRUB can be manually "
"configured later to boot it."
msgstr ""
"تحذير: إن كان برنامج التثبيت قد فشل باكتشاف نظام تشغيلٍ آخر موجودٍ على حاسوبك، 
"
"فإن تعديل سجلّ الإقلاع الرّئيسي سوف يجعل نظام التّشغيل ذاك غير قابلٍ للإقلاع "
"مؤقّتاً، إلّا أنّه من الممكن تهيئة GRUB يدويّاً لإقلاعه لاحقاً."

That one however shows up without any concern, that's odd...

Samuel



Bug#929622: linux-image-4.19.0-0.bpo.4-amd64: Interface names are changing with Kernelupgrade to 4.19-bpo

2019-06-02 Thread Ben Hutchings
Control: tag -1 upstream wontfix

On Mon, 2019-05-27 at 15:07 +0200, Stefan K wrote:
> Dear Maintainer,
> 
> I recently upgraded from 4.9 to the 4.19 backport kernel. I thought that
> we've predictable network interface names[1], but we don't.
> 
> With kernel 4.9 my network device is eno113, if I use kernel 4.19 its
> eno113np0. The OS is running on a Dell PowerEdge R840.
[...]

These names are generated by systemd-udevd, although they are based on
information from the kernel.

Looking at the system-udevd source code, it appears that the extra
"np0" is derived from a new "phys_port_name" attribute of the network
device, which the bnxt_en driver added support for in Linux 4.14.

It looks like this is required for switchdev functionality, so I don't
think this change is going to be reverted.

Ben.

-- 
Ben Hutchings
Unix is many things to many people,
but it's never been everything to anybody.




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


Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread ButterflyOfFire
Hi,

>> "لاحقاً"

This word means "later" and can be replaced by "لاحقا".



Bug#929886: unblock: marsshooter/0.7.6-4

2019-06-02 Thread Markus Koschany
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package marsshooter

A segmentation fault was discovered in marsshooter, that may crash the
game and make it unusable. This is Debian bug #929513. Bernhard
Übelacker provided a patch. Please find attached the debdiff.

Thanks,

Markus


unblock marsshooter/0.7.6-4

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

Kernel: Linux 4.9.0-9-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
diff -Nru marsshooter-0.7.6/debian/changelog marsshooter-0.7.6/debian/changelog
--- marsshooter-0.7.6/debian/changelog  2018-07-29 02:33:04.0 +0200
+++ marsshooter-0.7.6/debian/changelog  2019-05-29 14:55:09.0 +0200
@@ -1,3 +1,11 @@
+marsshooter (0.7.6-4) unstable; urgency=medium
+
+  * Add avoid-crash-because-of-missing-return-statement.patch.
+Fix potential crash by adding proper return statements.
+Thanks to Bernhard Übelacker for the patch (Closes: #929513)
+
+ -- Markus Koschany   Wed, 29 May 2019 14:55:09 +0200
+
 marsshooter (0.7.6-3) unstable; urgency=medium
 
   * Switch to compat level 11.
diff -Nru 
marsshooter-0.7.6/debian/patches/avoid-crash-because-of-missing-return-statement.patch
 
marsshooter-0.7.6/debian/patches/avoid-crash-because-of-missing-return-statement.patch
--- 
marsshooter-0.7.6/debian/patches/avoid-crash-because-of-missing-return-statement.patch
  1970-01-01 01:00:00.0 +0100
+++ 
marsshooter-0.7.6/debian/patches/avoid-crash-because-of-missing-return-statement.patch
  2019-05-29 14:55:09.0 +0200
@@ -0,0 +1,72 @@
+From 61b2f879bf460645faf39b4729e355ea13ee6eec Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
+Date: Tue, 28 May 2019 10:30:01 +0200
+Subject: Avoid crash because of missing return statement.
+
+warning: no return statement in function returning non-void [-Wreturn-type]
+warning: control reaches end of non-void function [-Wreturn-type]
+
+Debian-Bug: https://bugs.debian.org/929513
+---
+ include/Specials/NoSpecial.hpp | 2 +-
+ include/Weapons/NoWeapon.hpp   | 6 +++---
+ src/Interface/Tab.cpp  | 2 ++
+ 3 files changed, 6 insertions(+), 4 deletions(-)
+
+diff --git a/include/Specials/NoSpecial.hpp b/include/Specials/NoSpecial.hpp
+index 4c1c8d3..67c3fa4 100644
+--- a/include/Specials/NoSpecial.hpp
 b/include/Specials/NoSpecial.hpp
+@@ -32,7 +32,7 @@ class NoSpecial: public Special {
+ /// Does nothing.
+ void activate() const {}
+ 
+-float radius() const {}
++float radius() const { return 0.; }
+ 
+ /// Draws the special.
+ void draw(float alpha) const;
+diff --git a/include/Weapons/NoWeapon.hpp b/include/Weapons/NoWeapon.hpp
+index e739851..38c8b2c 100644
+--- a/include/Weapons/NoWeapon.hpp
 b/include/Weapons/NoWeapon.hpp
+@@ -35,13 +35,13 @@ class NoWeapon: public Weapon {
+ void draw(float alpha) const {}
+ 
+ /// Returns the maximum distance from which this weapon should be 
used.
+-float maxDistance() const {}
++float maxDistance() const { return 0.; }
+ 
+ /// Returns the minimum distance from which this weapon should be 
used.
+-float minDistance() const {}
++float minDistance() const { return 0.; }
+ 
+ /// Returns the maximum angle from which this weapon should be used.
+-float maxAngle()   const {}
++float maxAngle()   const { return 0.; }
+ };
+ 
+ # endif // NOWEAPON_HPP_INCLUDED
+diff --git a/src/Interface/Tab.cpp b/src/Interface/Tab.cpp
+index 19a7e26..e0dd57e 100644
+--- a/src/Interface/Tab.cpp
 b/src/Interface/Tab.cpp
+@@ -110,6 +110,7 @@ bool Tab::tabNext() {
+ return true;
+ }
+ }
++return false;
+ }
+ 
+ bool Tab::tabPrevious() {
+@@ -140,6 +141,7 @@ bool Tab::tabPrevious() {
+ return true;
+ }
+ }
++return false;
+ }
+ 
+ 
+-- 
+2.20.1
+
diff -Nru marsshooter-0.7.6/debian/patches/series 
marsshooter-0.7.6/debian/patches/series
--- marsshooter-0.7.6/debian/patches/series 2018-07-29 02:33:04.0 
+0200
+++ marsshooter-0.7.6/debian/patches/series 2019-05-29 14:55:09.0 
+0200
@@ -1,2 +1,3 @@
 man-page.patch
 desktop-file.patch
+avoid-crash-because-of-missing-return-statement.patch


Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 17:07:04 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 16:47:49 +0200, a ecrit:
> > But it's translated along the two other pieces "The installer can guide
> > you..." and "If you choose guided..." so the issue might be in those.
> 
> It's when I add this piece that gtk starts choking. Any idea?

More precisely, it's this bit:

> "لاحقاً"

Samuel



Bug#929885: Hangup log

2019-06-02 Thread Eric
Additionnaly, I attach here the log (dmesg) of the hangup (triggered by 
lauching xine-ui).




[0.00] Linux version 4.19.0-5-amd64 (debian-ker...@lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-7)) #1 SMP Debian 4.19.37-3 (2019-05-15)
[0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=UUID=f45bd6d5-429c-44ef-8981-6ab0feba8dfa ro quiet
[0.00] random: get_random_u32 called from bsp_init_amd+0x20b/0x2b0 with crng_init=0
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009e7ff] usable
[0.00] BIOS-e820: [mem 0x0009e800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xca867fff] usable
[0.00] BIOS-e820: [mem 0xca868000-0xcab43fff] reserved
[0.00] BIOS-e820: [mem 0xcab44000-0xcab53fff] ACPI data
[0.00] BIOS-e820: [mem 0xcab54000-0xcb959fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcb95a000-0xcca36fff] reserved
[0.00] BIOS-e820: [mem 0xcca37000-0xcca37fff] usable
[0.00] BIOS-e820: [mem 0xcca38000-0xccc3dfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xccc3e000-0xcd082fff] usable
[0.00] BIOS-e820: [mem 0xcd083000-0xcd7f3fff] reserved
[0.00] BIOS-e820: [mem 0xcd7f4000-0xcd7f] usable
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfec1-0xfec10fff] reserved
[0.00] BIOS-e820: [mem 0xfec2-0xfec20fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved
[0.00] BIOS-e820: [mem 0xfed61000-0xfed70fff] reserved
[0.00] BIOS-e820: [mem 0xfed8-0xfed8] reserved
[0.00] BIOS-e820: [mem 0xfef0-0x] reserved
[0.00] BIOS-e820: [mem 0x00011000-0x00012eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.7 present.
[0.00] DMI: To be filled by O.E.M. To be filled by O.E.M./M5A99FX PRO R2.0, BIOS 2201 11/22/2013
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 4013.276 MHz processor
[0.002933] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.002935] e820: remove [mem 0x000a-0x000f] usable
[0.010757] AGP: No AGP bridge found
[0.010827] last_pfn = 0x12f000 max_arch_pfn = 0x4
[0.010830] MTRR default type: uncachable
[0.010831] MTRR fixed ranges enabled:
[0.010832]   0-9 write-back
[0.010833]   A-B write-through
[0.010833]   C-CDFFF write-protect
[0.010834]   CE000-EBFFF uncachable
[0.010835]   EC000-F write-protect
[0.010835] MTRR variable ranges enabled:
[0.010836]   0 base  mask 8000 write-back
[0.010837]   1 base 8000 mask C000 write-back
[0.010838]   2 base C000 mask F000 write-back
[0.010839]   3 base CD80 mask FF80 uncachable
[0.010840]   4 base CE00 mask FE00 uncachable
[0.010840]   5 disabled
[0.010840]   6 disabled
[0.010841]   7 disabled
[0.010842] TOM2: 00012f00 aka 4848M
[0.011649] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.011715] e820: update [mem 0xcd80-0x] usable ==> reserved
[0.011720] last_pfn = 0xcd800 max_arch_pfn = 0x4
[0.048672] Base memory trampoline at [(ptrval)] 98000 size 24576
[0.048674] Using GB pages for direct mapping
[0.048676] BRK [0x5a201000, 0x5a201fff] PGTABLE
[0.048678] BRK [0x5a202000, 0x5a202fff] PGTABLE
[0.048679] BRK [0x5a203000, 0x5a203fff] PGTABLE
[0.048725] BRK [0x5a204000, 0x5a204fff] PGTABLE
[0.048726] BRK [0x5a205000, 0x5a205fff] PGTABLE
[0.048825] BRK [0x5a206000, 0x5a206fff] PGTABLE
[0.049269] BRK [0x5a207000, 0x5a207fff] PGTABLE
[0.049381] BRK [0x5a208000, 0x5a208fff] PGTABLE
[0.049541] BRK [0x5a209000, 0x5a209fff] PGTABLE
[0.049646] BRK [0x5a20a000, 0x5a20afff] PGTABLE
[0.049727] RAMDISK: [mem 0x337c9000-0x35bdbfff]
[0.049734] ACPI: Early table checksum verification disabled
[0.062929] ACPI: RSDP 0x000F0490 24 (v02 ALASKA)
[0.062932] ACPI: XSDT 0xCAB4B070 5

Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 16:47:49 +0200, a ecrit:
> But it's translated along the two other pieces "The installer can guide
> you..." and "If you choose guided..." so the issue might be in those.

It's when I add this piece that gtk starts choking. Any idea?

"الفرصة لاحقاً لرؤية النتائج و تخصيصها."

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 16:44:45 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 16:33:03 +0200, a ecrit:
> > Samuel Thibault, le dim. 02 juin 2019 16:06:50 +0200, a ecrit:
> > > Samuel Thibault, le dim. 02 juin 2019 15:56:31 +0200, a ecrit:
> > > > Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> > > > > Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > > > > > So, that would come down to this two commits
> > > > > > (if it's a matter of arabic translations):
> > > > > > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > > > > > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> > > > > 
> > > > > I tried to revert these two, but that didn't fix the issue.
> > > > 
> > > > The bug could be coming from another string, not showing up in beta5,
> > > > but showing up in rc1.
> > > 
> > > Dropping the translations of partman-auto does fix the issue for me.
> > 
> > It's this translation which breaks things up:
> > 
> > msgid "Partitioning method:"
> > msgstr "طريقة التجزئة:"
> > 
> > Any idea? :)
> 
> Mmm, putting
> 
> msgid "Partitioning method:"
> msgstr "foobar:"
> 
> there does get the issue as well...

But it's translated along the two other pieces "The installer can guide
you..." and "If you choose guided..." so the issue might be in those.

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 16:33:03 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 16:06:50 +0200, a ecrit:
> > Samuel Thibault, le dim. 02 juin 2019 15:56:31 +0200, a ecrit:
> > > Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> > > > Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > > > > So, that would come down to this two commits
> > > > > (if it's a matter of arabic translations):
> > > > > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > > > > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> > > > 
> > > > I tried to revert these two, but that didn't fix the issue.
> > > 
> > > The bug could be coming from another string, not showing up in beta5,
> > > but showing up in rc1.
> > 
> > Dropping the translations of partman-auto does fix the issue for me.
> 
> It's this translation which breaks things up:
> 
> msgid "Partitioning method:"
> msgstr "طريقة التجزئة:"
> 
> Any idea? :)

Mmm, putting

msgid "Partitioning method:"
msgstr "foobar:"

there does get the issue as well...

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 16:06:50 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 15:56:31 +0200, a ecrit:
> > Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> > > Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > > > So, that would come down to this two commits
> > > > (if it's a matter of arabic translations):
> > > > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > > > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> > > 
> > > I tried to revert these two, but that didn't fix the issue.
> > 
> > The bug could be coming from another string, not showing up in beta5,
> > but showing up in rc1.
> 
> Dropping the translations of partman-auto does fix the issue for me.

It's this translation which breaks things up:

msgid "Partitioning method:"
msgstr "طريقة التجزئة:"

Any idea? :)

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 15:56:31 +0200, a ecrit:
> Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> > Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > > So, that would come down to this two commits
> > > (if it's a matter of arabic translations):
> > > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> > 
> > I tried to revert these two, but that didn't fix the issue.
> 
> The bug could be coming from another string, not showing up in beta5,
> but showing up in rc1.

Dropping the translations of partman-auto does fix the issue for me.

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 15:47:28 +0200, a ecrit:
> Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> > So, that would come down to this two commits
> > (if it's a matter of arabic translations):
> > https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> > https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093
> 
> I tried to revert these two, but that didn't fix the issue.

The bug could be coming from another string, not showing up in beta5,
but showing up in rc1.

Samuel



Bug#927714: CVE-2019-3885 CVE-2018-16877 CVE-2018-16878

2019-06-02 Thread wferi
On Wed, 24 Apr 2019 17:50:02 +0200 wf...@niif.hu wrote:

> On Mon, 22 Apr 2019 09:07:04 +0200 Salvatore Bonaccorso  
> wrote:
> 
>>> Please see https://www.openwall.com/lists/oss-security/2019/04/17/1
>> 
>> Please note that when fixing the issues, in the original patchsets
>> there were some behaviour regressions, I think they should be adressed
>> in the followups as noted in
>> https://www.openwall.com/lists/oss-security/2019/04/18/2
> 
> After several readings of the followup you linked to I think those
> "prior behavioral changes" are the fixes themselves, that is, the more
> thorough authorization checks.  Don't you agree?

According to
https://github.com/ClusterLabs/pacemaker/pull/1750#issuecomment-494765240,
those behavioral changes are already addressed in the pull request.

> I proceeded to apply the patches in the pull request to the pacemaker
> quilt queue.  Unfortunately they introduce new symbols in libcrmcommon:
> crm_ipc_is_authentic_process and pcmk__ipc_is_authentic_process_active.
> Am I expected to update the libtool version info in light of this?

I left those internal symbols unaccounted for now, just tell if it needs
adjustment.

As per the previous comment CVE-2019-3885 does not affect 1.1.16 (the
version in stretch), so that patch was left out (you may want to
indicate this in the security tracker).  On the other hand three
followup patches fixing two bugs in the security fixes are included
based on
https://lists.clusterlabs.org/pipermail/users/2019-May/025822.html.

Here is the full glorious debdiff:

diff -Nru pacemaker-1.1.16/debian/changelog pacemaker-1.1.16/debian/changelog
--- pacemaker-1.1.16/debian/changelog   2016-12-01 14:15:23.0 +0100
+++ pacemaker-1.1.16/debian/changelog   2019-06-02 08:08:12.0 +0200
@@ -1,3 +1,35 @@
+pacemaker (1.1.16-1+deb9u1) stretch-security; urgency=high
+
+  [ Christoph Berg ]
+  * [d3d1561] Remove myself from Uploaders.
+
+  [ Ferenc Wágner ]
+  * [53a63fc] Backport upstream security fixes from pull request #1749.
+1. CVE-2018-16877: Insufficient local IPC client-server authentication
+   on the client's side can lead to local privesc.  A local attacker
+   could use this flaw, and combine it with other IPC weaknesses, to
+   achieve local privilege escalation.
+2. CVE-2018-16878: Insufficient verification inflicted preference of
+   uncontrolled processes can lead to DoS.
+The backported patch bundles were taken from
+
https://src.fedoraproject.org/rpms/pacemaker/c/f48a85ec68e299dfc53655b121e661b7c488ed71?branch=f28:
+- High-pacemakerd-vs.-IPC-procfs-confused-deputy-authentic.patch
+  (fixes CVE-2018-16877 and CVE-2018-16878)
+- Med-controld-fix-possible-NULL-pointer-dereference.patch
+  (fixes an additional problem which is more likely triggerable now that
+  the problems related to CVE-2018-16878 are avoided)
+CVE-2019-3885 does not affect Pacemaker 1.1.16, so
+High-libservices-fix-use-after-free-wrt.-alert-handl.patch is not
+included in this backport.
+Thanks to Jan Pokorný  (Closes: #927714)
+  * [fcbaaae] Acknowledge the new symbols
+  * [babde58] Backport three more patches from upstream fixing memory safety
+bugs.
+Clearing up fallout from the preceding security fixes.
+Thanks to Ken Gaillot 
+
+ -- Ferenc Wágner   Sun, 02 Jun 2019 08:08:12 +0200
+
 pacemaker (1.1.16-1) unstable; urgency=medium
 
   * [d90daf5] Refresh our patches
diff -Nru pacemaker-1.1.16/debian/control pacemaker-1.1.16/debian/control
--- pacemaker-1.1.16/debian/control 2016-12-01 14:14:42.0 +0100
+++ pacemaker-1.1.16/debian/control 2019-05-18 16:41:29.0 +0200
@@ -5,7 +5,6 @@
 Uploaders:
  Richard B Winters ,
  Ferenc Wágner ,
- Christoph Berg ,
  Adrian Vondendriesch ,
 Build-Depends:
  cluster-glue-dev,
diff -Nru pacemaker-1.1.16/debian/gbp.conf pacemaker-1.1.16/debian/gbp.conf
--- pacemaker-1.1.16/debian/gbp.conf2016-12-01 14:07:08.0 +0100
+++ pacemaker-1.1.16/debian/gbp.conf2019-05-22 11:01:26.0 +0200
@@ -1,15 +1,12 @@
 [DEFAULT]
-debian-branch = debian/master
+debian-branch = debian/stretch
 upstream-branch = upstream/latest
-debian-tag-msg = Debian release %(version)s
-
-[import-orig]
 pristine-tar = True
 
-[gbp-pq]
+[pq]
 patch-numbers = False
 
-[gbp-dch]
+[dch]
 full = True
 multimaint-merge = True
 id-length = 7
diff -Nru pacemaker-1.1.16/debian/libcrmcommon3.symbols 
pacemaker-1.1.16/debian/libcrmcommon3.symbols
--- pacemaker-1.1.16/debian/libcrmcommon3.symbols   2016-12-01 
14:14:42.0 +0100
+++ pacemaker-1.1.16/debian/libcrmcommon3.symbols   2019-05-22 
11:56:47.0 +0200
@@ -94,6 +94,7 @@
  crm_ipc_default_buffer_size@Base 1.1.11
  crm_ipc_destroy@Base 1.1.9
  crm_ipc_get_fd@Base 1.1.9
+ crm_ipc_is_authentic_process@Base 1.1.16-1+deb9u1~
  crm_ipc_name@Base 1.1.9
  crm_ipc_new@Base 1.1.9
  crm_ipc_prepare@Base 1.1.9
@@ -292,6 +293,7 @@
  parse_date@Base 1.1.9
  parse_op_key@Base 1.1.9
  patch

Bug#929885: linux-image-4.19.0-5-amd64: Graphics freezes (missing firmware nouveau/nvce_fuc084 in dmesg) when trying video replay.

2019-06-02 Thread Eric Degenetais
Package: src:linux
Version: 4.19.37-3
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Tried to replay a video (launching xine) on my bustre installation. I also 
tried VLC media player with the same result. 
I suspect anything using hardware acceleration (video, 3D...) will fail the 
same way.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Launched xine.
   * What was the outcome of this action?
Graphics freeze, the keyboard and mouse also freeze. I did not manage to get 
back to a tty using ctrl+Fn. I had to punch the powre button
(short press) to get the system to make an orderly shutdown.
   * What outcome did you expect instead?
Successfully playing videos (and anything using my Nvidia grphics board) 
without hanging the system up.
*** End of the template - remove these template lines ***


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

** Command line:
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 
root=UUID=f45bd6d5-429c-44ef-8981-6ab0feba8dfa ro quiet

** Not tainted

** Kernel log:
[9.380668] audit: type=1400 audit(1559481894.496:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-oopslash" 
pid=372 comm="apparmor_parser"
[9.403643] audit: type=1400 audit(1559481894.520:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=373 
comm="apparmor_parser"
[9.403646] audit: type=1400 audit(1559481894.520:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=373 comm="apparmor_parser"
[9.416604] audit: type=1400 audit(1559481894.532:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=371 
comm="apparmor_parser"
[9.416607] audit: type=1400 audit(1559481894.532:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=371 
comm="apparmor_parser"
[9.416609] audit: type=1400 audit(1559481894.532:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=371 
comm="apparmor_parser"
[9.438562] audit: type=1400 audit(1559481894.552:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="libreoffice-senddoc" 
pid=375 comm="apparmor_parser"
[9.438868] audit: type=1400 audit(1559481894.552:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" 
pid=379 comm="apparmor_parser"
[9.468868] audit: type=1400 audit(1559481894.584:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/cups/backend/cups-pdf" pid=381 comm="apparmor_parser"
[9.827914] acpi_cpufreq: overriding BIOS provided _PSD data
[   10.018596] sd 0:0:0:0: Attached scsi generic sg0 type 0
[   10.018634] sd 1:0:0:0: Attached scsi generic sg1 type 0
[   10.018671] sr 3:0:0:0: Attached scsi generic sg2 type 5
[   10.018708] sd 8:0:0:0: Attached scsi generic sg3 type 0
[   10.018743] sd 8:0:0:1: Attached scsi generic sg4 type 0
[   10.018779] sd 8:0:0:2: Attached scsi generic sg5 type 0
[   10.018813] sd 8:0:0:3: Attached scsi generic sg6 type 0
[   10.130139] input: PC Speaker as /devices/platform/pcspkr/input/input9
[   10.234598] sp5100_tco: SP5100/SB800 TCO WatchDog Timer Driver
[   10.234754] sp5100-tco sp5100-tco: Using 0xfed80b00 for watchdog MMIO address
[   10.234933] sp5100-tco sp5100-tco: initialized. heartbeat=60 sec (nowayout=0)
[   10.290702] asus_wmi: ASUS WMI generic driver loaded
[   10.406726] asus_wmi: Initialization: 0x0
[   10.406782] asus_wmi: BIOS WMI version: 0.9
[   10.406875] asus_wmi: SFUN value: 0x0
[   10.407684] input: Eee PC WMI hotkeys as 
/devices/platform/eeepc-wmi/input/input10
[   10.407865] asus_wmi: Number of fans: 1
[   10.492445] usblp 3-4:1.1: usblp1: USB Bidirectional printer dev 2 if 1 alt 
0 proto 2 vid 0x04E8 pid 0x343D
[   10.492485] usbcore: registered new interface driver usblp
[   10.896788] media: Linux media interface: v0.10
[   10.991137] snd_hda_intel :01:00.1: Disabling MSI
[   10.991159] snd_hda_intel :01:00.1: Handle vga_switcheroo audio client
[   11.037787] videodev: Linux video capture interface: v2.00
[   11.151464] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC892: 
line_outs=4 (0x14/0x15/0x16/0x17/0x0) type:line
[   11.151466] snd_hda_codec_realtek hdaudioC0D0:speaker_outs=0 
(0x0/0x0/0x0/0x0/0x0)
[   11.151467] snd_hda_codec_realtek hdaudioC0D0:hp_outs=1 
(0x1b/0x0/0x0/0x0/0x0)
[   11.151468] snd_hda_codec_realtek hdaudioC0D0:mono: mono_out=0x0
[   11.151469] snd_hda_codec_realtek hdaudioC0D0:dig-out=0x11/0x1e
[   11.151469] snd_hda_codec_realtek hdaudioC0D0:inputs:
[   11.151471] snd_hda_codec_realtek hdaudioC0D0:  Front Mic=0x19
[   11.151472

Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Holger Wansing, le dim. 02 juin 2019 15:00:09 +0200, a ecrit:
> So, that would come down to this two commits
> (if it's a matter of arabic translations):
> https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
> https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093

I tried to revert these two, but that didn't fix the issue.

Samuel



Bug#929884: dnsmasq: please provide runscript file

2019-06-02 Thread Dmitry Bogatov
Source: dnsmasq
Version: 2.80-1
Severity: wishlist
Tags: patch
User: ru...@packages.debian.org
Usertags: runscript

Dear maintainer,

please include native script for runit init system into 'dnsmasq'.
Below is diff aganist latest package release (2.80-1).

Here are some links:

 * http://smarden.org/runit -- more information about 'runit'
 * https://bugs.debian.org/746715 -- technical committe position
   on support of init systems, other then sysvinit.

From 3c516dde2b8dd552b141196ed98379800b3e0611 Mon Sep 17 00:00:00 2001
From: Dmitry Bogatov 
Date: Sun, 26 May 2019 18:54:36 +
Subject: [PATCH] Add integration script for runit init

---
 debian/control  |  5 ++--
 debian/dnsmasq.runit|  1 +
 debian/dnsmasq.runscript/finish |  5 
 debian/dnsmasq.runscript/run| 43 +
 debian/rules|  7 +-
 5 files changed, 58 insertions(+), 3 deletions(-)
 create mode 100644 debian/dnsmasq.runit
 create mode 100755 debian/dnsmasq.runscript/finish
 create mode 100755 debian/dnsmasq.runscript/run

diff --git a/debian/control b/debian/control
index 9d4d7e8..40ad6c6 100644
--- a/debian/control
+++ b/debian/control
@@ -4,7 +4,7 @@ Priority: optional
 Build-depends: gettext, libnetfilter-conntrack-dev [linux-any],
libidn11-dev, libdbus-1-dev (>=0.61), libgmp-dev, 
nettle-dev (>=2.4-3), libbsd-dev [!linux-any],
-  liblua5.2-dev
+  liblua5.2-dev, dh-runit, debhelper-compat (= 10)
 Maintainer: Simon Kelley 
 Homepage: http://www.thekelleys.org.uk/dnsmasq/doc.html
 Standards-Version: 3.9.8
@@ -12,8 +12,9 @@ Standards-Version: 3.9.8
 Package: dnsmasq
 Architecture: all
 Depends: netbase, dnsmasq-base,
- init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6)
+ init-system-helpers (>= 1.18~), lsb-base (>= 3.0-6), ${misc:Depends}
 Suggests: resolvconf
+Breaks: ${runit:Breaks}
 Conflicts: resolvconf (<<1.15)
 Description: Small caching DNS proxy and DHCP/TFTP server
  Dnsmasq is a lightweight, easy to configure, DNS forwarder and DHCP
diff --git a/debian/dnsmasq.runit b/debian/dnsmasq.runit
new file mode 100644
index 000..6a457f7
--- /dev/null
+++ b/debian/dnsmasq.runit
@@ -0,0 +1 @@
+debian/dnsmasq.runscript name=dnsmasq,logscript,since=2.80-1+runit
diff --git a/debian/dnsmasq.runscript/finish b/debian/dnsmasq.runscript/finish
new file mode 100755
index 000..cf35240
--- /dev/null
+++ b/debian/dnsmasq.runscript/finish
@@ -0,0 +1,5 @@
+#!/bin/sh -eu
+if [ -x /sbin/resolvconf ] ; then
+   /sbin/resolvconf -d lo.dnsmasq
+fi
+
diff --git a/debian/dnsmasq.runscript/run b/debian/dnsmasq.runscript/run
new file mode 100755
index 000..1a43393
--- /dev/null
+++ b/debian/dnsmasq.runscript/run
@@ -0,0 +1,43 @@
+#!/lib/runit/invoke-run
+
+readonly name=dnsmasq
+readonly daemon=/usr/sbin/dnsmasq
+readonly marker=/usr/share/dnsmasq/installed-marker
+
+test -e "${marker}" || exec sv down "${name}"
+test -x "${daemon}" || exec sv down "${name}"
+
+if [ ! "${RESOLV_CONF:-}" ] &&
+   [ "${IGNORE_RESOLVCONF:-}" != "yes" ] &&
+   [ -x /sbin/resolvconf ]
+then
+   RESOLV_CONF=/run/dnsmasq/resolv.conf
+fi
+
+# This tells dnsmasq to ignore DNS requests that don't come from a local 
network.
+# It's automatically ignored if  --interface --except-interface, 
--listen-address 
+# or --auth-server exist in the configuration, so for most installations, it 
will
+# have no effect, but for otherwise-unconfigured installations, it stops 
dnsmasq
+# from being vulnerable to DNS-reflection attacks.
+
+DNSMASQ_OPTS="${DNSMASQ_OPTS:-} --local-service"
+
+# If the dns-root-data package is installed, then the trust anchors will be 
+# available in $ROOT_DS, in BIND zone-file format. Reformat as dnsmasq
+# --trust-anchor options.
+
+ROOT_DS="/usr/share/dns/root.ds"
+
+if [ -f $ROOT_DS ]; then
+DNSMASQ_OPTS="$DNSMASQ_OPTS `env LC_ALL=C sed -rne 
"s/^([.a-zA-Z0-9]+)([[:space:]]+[0-9]+)*([[:space:]]+IN)*[[:space:]]+DS[[:space:]]+/--trust-anchor=\1,/;s/[[:space:]]+/,/gp"
 $ROOT_DS | tr '\n' ' '`"
+fi
+
+mkdir -p /run/dnsmasq
+chown dnsmasq:nogroup /run/dnsmasq
+[ -x /sbin/restorecon ] && /sbin/restorecon /run/dnsmasq
+exec "${daemon}" \
+   --keep-in-foreground \
+   --log-facility=/dev/stdout \
+   ${RESOLV_CONF:+ -r $RESOLV_CONF} \
+   ${DNSMASQ_OPTS} \
+   -u dnsmasq
diff --git a/debian/rules b/debian/rules
index b4ec4e9..f8d84fd 100755
--- a/debian/rules
+++ b/debian/rules
@@ -159,6 +159,9 @@ clean:
 binary-indep:  checkroot
$(checkdir)
rm -rf debian/trees/daemon
+   mkdir -p debian/trees
+   dh_runit -pdnsmasq
+   mv debian/dnsmasq/ debian/trees/daemon
install -m 755 \
-d debian/trees/daemon/DEBIAN \
-d debian/trees/daemon/usr/share/doc \
@@ -173,6 +176,8 @@ binary-indep:   checkroot
 -d debian/trees/daemon/etc/insserv.conf.d
install -m 644 debian/conffiles debian/trees/daemon/D

Bug#929883: RFP: geomyidae -- gopher server for Linux/BSD

2019-06-02 Thread Dmitry Bogatov

Package: wnpp
Severity: wishlist

Programming Language: C
Homepage: gopher://bitreich.org/1/scm/geomyidae

Features:
* gopher menus (see index.gph for an example)
* dir listings (if no index.gph was found)
* CGI support (.cgi files are executed)
* search support in CGI files
* logging (-l option) and loglevels (-v option)


pgp1u5ZLjf5ms.pgp
Description: PGP signature


Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
ButterflyOfFire, le dim. 02 juin 2019 12:12:04 +, a ecrit:
> Tested right now on my laptop, I cannot reproduce the bug. It seems working.
> 
> Tested with :
> kvm -cdrom /var/tmp/d-i/debian-buster-DI-rc1-amd64-netinst.iso -drive 
> file=blip -m 1G

Hum :/

I tried to rebuild partman-base without the arabic translation, and I'm
still getting the issue, so it's not something in there but somewhere
else.

Just to be sure, I put 4G of memory, with the same result.

I also tried two dozens other languages and scripts, only Arabic gave me
the issue.

Samuel



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Holger Wansing
While ButterflyOfFire reported to be unable to reproduce this, I can indeed
reproduce this with qemu here.
Looking more closely, that bug is there for me with the rc1 installer, however 
not with the alpha5 one.

So, that would come down to this two commits
(if it's a matter of arabic translations):
https://salsa.debian.org/installer-team/d-i/commit/1e16f41d79578a47a370c7a47ec49abdcfc7fb52
https://salsa.debian.org/installer-team/d-i/commit/5654defa9a4b75196e83e905465cd3aa8704c093


@ButterflyOfFire:
is there something eye-catching problematic with one of these changings?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076



Bug#897909: mypaint: Unable to install MyPaint when Gimp 2.10 is installed

2019-06-02 Thread Jacob Nevins
I wrote:
> There's a patch (to mypaint rather than libmypaint) to resolve the
> conflict without a new version of mypaint, by renaming mypaint's locale
> to 'mypaint12', in the upstream tracker at
> .
> 
> This is the approach previously suggested by Chris Waters in
> .
> 
> I haven't tested it myself, but it looks plausible.

I have now tested this patch on my Buster system. It appears to work.

What needs to happen next, to fix this in Buster? I probably won't be
able to upload to the Debian archive myself.

Now that we have a simple and apparently workable solution, should the
buster-ignore tag be removed from #906144, to make this an RC bug once
again?

=-=-=-=-=-
What I did, in detail:

Starting with buster's mypaint_1.2.0-4.1, I added the above patch
verbatim to the debian/patches stack, updated debian/changelog, and
built new binary packages. I didn't have to make any changes.

Starting with buster's libmypaint_1.3.0-2.1, I simply edited
debian/control to remove the Conflicts:

--- debian/control  2019-02-09 11:22:40.0 +
+++ ../../libmypaint-1.3.0/debian/control   2019-06-02 12:50:07.776325535 
+0100
@@ -59,7 +59,7 @@
 Architecture: all
 Multi-Arch: foreign
 Depends: ${misc:Depends},
-Conflicts: mypaint-data
+Conflicts: mypaint-data (<< 1.2.0-4.1jtn1)
 Description: brush library for mypaint - common files
  MyPaint is a pressure- and tilt-sensitive painting program which works well
  with Wacom graphics tablets and other similar devices. It comes with a large

(that version being the name I gave to my local mypaint build)
and updated debian/changelog and built new local binary packages.

Before installing, I verified that my mypaint-data and libmypaint-common
binary packages no longer had any files in common (where the buster
packages have a lot of .mo files in common).

Testing:

I started with GIMP (and hence buster's libmypaint_1.3.0-2.1) installed.
Before changing anything, I had a quick play with GIMP's "MyPaint
brushes" feature, which I'm not familiar with. (It doesn't seem to have
any brushes by default, but I was able to scribble.)

I installed my new local libmypaint and libmypaint-common packages (the
ones GIMP uses), and verified there was no change in GIMP's behaviour as
far as I could tell.

I installed my new local mypaint and mypaint-data packages. They
installed fine. MyPaint runs and appears functional.
I have an en_GB locale, and MyPaint talks about "colour" rather than
"color", so I infer that the .mo files are installed correctly.



Bug#929881: cdimage.debian.org: Unofficial non-free live images have 400+ MB bloat from extra firmware

2019-06-02 Thread Daniel Lewart
Package: cdimage.debian.org
Severity: important
Tags: patch

Debian Images Team,

Sizes of netinst images with and without firmware:
   375 MiB  firmware-testing-amd64-netinst.iso
   334 MiB  debian-testing-amd64-netinst.iso
   ---
41 MiB  difference

Sizes of Live Standard images with and without firmware:
  1285 MiB  debian-live-testing-amd64-standard+nonfree.iso
   824 MiB  debian-live-testing-amd64-standard.iso
  
   461 MiB  difference

debian-cd generates netinst images:
  * Only includes firmware|microcode packages that contain files
in /lib/firmware
  * 
https://salsa.debian.org/images-team/debian-cd/blob/master/tools/generate_firmware_task
  * 
https://salsa.debian.org/images-team/debian-cd/blob/master/tools/make-firmware-image

live-setup generates Live images:
  * Includes *all* firmware|microcode main|non-free packages
  * Also includes their massive dependencies
  * 
https://salsa.debian.org/images-team/live-setup/blob/master/available/run-30live-wrapper

I can think of three fixes for live-setup:
  1) Have live-setup use the firmware task generated by debian-cd
  2) Copy make-firmware-image to live-setup for use there
  3) Patch live-setup run-30live-wrapper with the **untested** patch below

By the way, this bug report supercedes my earlier #929790:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929790

Thank you!
Daniel Lewart
Urbana, IL
---
diff -ru a/available/run-30live-wrapper b/available/run-30live-wrapper
--- a/available/run-30live-wrapper  2019-05-01 08:24:07.0 -0500
+++ b/available/run-30live-wrapper  2019-06-02 00:00:00.0 -0500
@@ -98,12 +98,26 @@
 # Work out which packages to add for non-free firmware
 select_firmware_packages () {
 ARCH=$1
-SECTIONS="main non-free"
-PKGS=""
-for SECTION in ${SECTIONS}; do
-   PKGS="$PKGS "$(wget -q 
$MIRROR/dists/${CODENAME}/${SECTION}/binary-${ARCH}/Packages.gz -O- | gzip -cd 
- | \
- grep-dctrl -Pe '.*(firmware|microcode).*' -s Package -n | sort -u)
-done
+case "$ARCH" in
+   amd64|i386)
+   ;;
+   *)
+   echo "Unknown ARCH $ARCH; abort!"
+   exit 1
+   ;;
+esac
+
+# Q.v. debian-cd/tools generate_firmware_task & make-firmware-image
+PKGS="amd64-microcode atmel-firmware bluez-firmware
+dahdi-firmware-nonfree firmware-amd-graphics firmware-ath9k-htc
+firmware-atheros firmware-b43-installer firmware-b43legacy-installer
+firmware-bnx2 firmware-bnx2x firmware-brcm80211 firmware-cavium
+firmware-intel-sound firmware-intelwimax firmware-ipw2x00 firmware-ivtv
+firmware-iwlwifi firmware-libertas firmware-linux-nonfree
+firmware-misc-nonfree firmware-myricom firmware-netronome
+firmware-netxen firmware-qcom-media firmware-qlogic firmware-realtek
+firmware-samsung firmware-siano firmware-ti-connectivity firmware-zd1211
+hdmi2usb-fx2-firmware intel-microcode"
 echo $PKGS
 }



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Samuel Thibault, le dim. 02 juin 2019 13:00:51 +0200, a ecrit:
> Cc-ing debian-l10n-arabic because they can perhaps look at the partman
> translation files and check that there is nothing odd in the file (e.g.
> odd ligatures or such odd thing that might disturb gtk).

I forgot to mention that I tried in Persian and didn't have the issue,
so that confirms that there is probably something in the Arabic
translation which triggers a bug in gtk.

> While doing some tests, I noticed that when running the installer in
> arabic language, the hard disk detection step hangs. To reproduce:
> 
> - dd < /dev/zero > blip bs=1M count=1 seek=1
> - kvm -cdrom /var/tmp/d-i/debian-buster-DI-rc1-amd64-netinst.iso -drive 
> file=blip -m 2G
> - Select the graphical installer
> - Select the arabic language
> - Select that you don't care that not everything is translated
> - Select everything by default except typing non-empty passwords and
>   user name
> 
> The partman packages get loaded but the installer remains stuck at the
> attached screenshot. /var/log/syslog does not provide more information
> than what we get when doing all the same in English. The ongoing
> processes showing up in ps are
> 
> udpkg --configure --force-configure partman-base
> /var/lib/dpkg/info/partman-base.postinst configure
> /bin/partman
> parted_server
> /lib/partman/display.d/10initial_auto
> 
> Switching to VT4 to see the log then going back to VT5 shows a fully
> gray screen, so I guess it's the gtk frontend which is somehow stuck due
> to something in the arabic translation?
> 
> I tried today's weekly build, with the same result (the only difference
> being that it doesn't warn that not everything is translated).
> 
> Samuel
> 
> -- Package-specific info:
> 
> Boot method: CD
> Image version: debian-buster-DI-rc1-amd64-netinst.iso
> 
> Machine: kvm
> 
> 
> Base System Installation Checklist:
> [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
> 
> Initial boot:   [O]
> Detect network card:[O]
> Configure network:  [O]
> Detect CD:  [O]
> Load installer modules: [O]
> Clock/timezone setup:   [O]
> User/password setup:[O]
> Detect hard drives: [E]
> Partition hard drives:  [ ]
> Install base system:[ ]
> Install tasks:  [ ]
> Install boot loader:[ ]
> Overall install:[ ]
> 
> 
> -- 
> 
> Please make sure that the hardware-summary log file, and any other
> installation logs that you think would be useful are attached to this
> report. Please compress large files using gzip.
> 
> Once you have filled out this report, mail it to sub...@bugs.debian.org.



Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread ButterflyOfFire
Hi,
Tested right now on my laptop, I cannot reproduce the bug. It seems working.

Tested with :
kvm -cdrom /var/tmp/d-i/debian-buster-DI-rc1-amd64-netinst.iso -drive file=blip 
-m 1G

Salutations,



Bug#929880: screen: Screen consumes a huge amount of RAM when increasing the scrollback buffer to a large number

2019-06-02 Thread Alex
Package: screen
Version: 4.5.0-6
Severity: normal

Dear Maintainer,
when I set the screen scrollback buffer to a large number of lines,
screen instantly consumes a huge amount of RAM, even when there is no
program filling the buffer, yet.

I set the scrollback buffer to 1 using the :scrollback command
inside screen, assuming this is a good way to set "unlimited" scrollback.
The actual output would have been many less lines. Screen instantly
consumed more than 20 GB of RAM, causing the computer to hang for a long
time.

In the best case, screen should not instantly reserve the RAM at all.
When it does, it could at least add a warning "Do you really want to
increase the buffer, it will consume 20 GB of RAM". I think it is rather
unexpected for the average user, that you can shoot yourself into the
foot with such a harmless command.

with kind regards,
Alex


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

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

Versions of packages screen depends on:
ii  libc6  2.24-11+deb9u4
ii  libpam0g   1.1.8-3.6
ii  libtinfo5  6.0+20161126-1+deb9u2

screen recommends no packages.

Versions of packages screen suggests:
pn  byobu | screenie | iselect  
ii  ncurses-term6.0+20161126-1+deb9u2

-- no debconf information



Bug#929879: libidn2: Unused build-dependency on help2man

2019-06-02 Thread Andreas Metzler
Source: libidn2
Version: 2.0.5-1
Severity: minor
Tags: patch

Hello,

libidn2 still has a build-dependency on help2man although it has not been
used upstream since 2.0.0 [1] and the Debian package has also switched
to ronn in 2.0.3-1 [2].

cu Andreas

[1]
** The idn2 manual page is generated from markdown text instead of utilizing
   help2man on the generated tool.

[2]
  * Add ruby-ronn to Build-Depends to generate the idn2.1 man page



Bug#929876: appdata.its not packaged

2019-06-02 Thread Michael Gratton

Package: appstream-util
Version: 0.7.14-1

appstream-util provides its own version of `appdata.its` that 
supersedes the one shipped by gettext, but this is not shipped by 
Debian. As a result, appstream files are not fully translatable (e.g. 
see )


Please include appdata.its in either the lib or dev package so that 
applications can add a build depend on it and gence get their appstream 
files fully translated.


Thanks!
//Mike

--
⊨ Michael Gratton, Percept Wrangler.
⚙ 




Bug#929877: installation-reports: Buster installer hangs at hard disk step with arabic language

2019-06-02 Thread Samuel Thibault
Package: installation-reports
Severity: serious
Justification: prevents from installing at all in arabic language

Hello,

Cc-ing debian-l10n-arabic because they can perhaps look at the partman
translation files and check that there is nothing odd in the file (e.g.
odd ligatures or such odd thing that might disturb gtk).


While doing some tests, I noticed that when running the installer in
arabic language, the hard disk detection step hangs. To reproduce:

- dd < /dev/zero > blip bs=1M count=1 seek=1
- kvm -cdrom /var/tmp/d-i/debian-buster-DI-rc1-amd64-netinst.iso -drive 
file=blip -m 2G
- Select the graphical installer
- Select the arabic language
- Select that you don't care that not everything is translated
- Select everything by default except typing non-empty passwords and
  user name

The partman packages get loaded but the installer remains stuck at the
attached screenshot. /var/log/syslog does not provide more information
than what we get when doing all the same in English. The ongoing
processes showing up in ps are

udpkg --configure --force-configure partman-base
/var/lib/dpkg/info/partman-base.postinst configure
/bin/partman
parted_server
/lib/partman/display.d/10initial_auto

Switching to VT4 to see the log then going back to VT5 shows a fully
gray screen, so I guess it's the gtk frontend which is somehow stuck due
to something in the arabic translation?

I tried today's weekly build, with the same result (the only difference
being that it doesn't warn that not everything is translated).

Samuel

-- Package-specific info:

Boot method: CD
Image version: debian-buster-DI-rc1-amd64-netinst.iso

Machine: kvm


Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it

Initial boot:   [O]
Detect network card:[O]
Configure network:  [O]
Detect CD:  [O]
Load installer modules: [O]
Clock/timezone setup:   [O]
User/password setup:[O]
Detect hard drives: [E]
Partition hard drives:  [ ]
Install base system:[ ]
Install tasks:  [ ]
Install boot loader:[ ]
Overall install:[ ]


-- 

Please make sure that the hardware-summary log file, and any other
installation logs that you think would be useful are attached to this
report. Please compress large files using gzip.

Once you have filled out this report, mail it to sub...@bugs.debian.org.


Bug#928956: Document removal of ecryptfs-utils from Buster

2019-06-02 Thread Justin B Rye
Holger Wansing wrote:
>>> +The ecryptfs-utils 
>>> package
>>> +is not part of buster due to an unfixed serious bug (>> +url="&url-bts;765854">#765854). At the time of writing 
>>> this
>>   paragraph, there was no clear advice for users of encryptfs,
>>   except not to upgrade.
> 
> Maybe adding something like
> "or migrate to " 
> to the end would be helpfu?
>
> And also, I wonder if "ecryptfs-utils" (without n) and 
> encryptfs (with n) are both correct?

Oops!  Well, I can fix that bit.

And to make it easier to remember we can use the upstream "brand name"
spelling "eCryptfs".

(I wonder: is it "extended" Cryptfs?  "enterprisey" Cryptfs?)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index 481df49b..7165690e 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -333,8 +333,8 @@ $ sudo update-initramfs -u
 The ecryptfs-utils package
 is not part of buster due to an unfixed serious bug (#765854). At the time of writing this
-paragraph, there wasn't a clear advice to people with encryptfs,
-except not upgrading.
+paragraph, there was no clear advice for users of eCryptfs,
+except not to upgrade.
   
 
   


Bug#929846: firefox: Fails to load https sites after today's upgrade to 67.0-3

2019-06-02 Thread jim_p
Package: firefox
Version: 67.0-3
Followup-For: Bug #929846

I was expecting 67.0-4 to reach the repos soon, since the bug was closed
earlier today.
Instead, all I got was an upgrade to libnss3 which downgraded it from 3.44 to
3.42.1 as seen in apt's output

Unpacking libnss3:amd64 (2:3.44+really3.42.1-1) over (2:3.44-1) ...

And the issue on firefox has returned. So I have 2 options as it seems, while I
wait for 67.0-4 to finally reach the repos for amd64
a) use the forementioned config switch in firefox itself or
b) use libnss3 3.44, which is now on experimental

Why was libnss3 downgraded? All it did was to break a perfectrly working
package.

p.s. Please do not say "you use unstable, you should be familiar with
situations like these".


[/rant]



-- Package-specific info:

-- Extensions information
Name: Firefox Monitor
Location: /usr/lib/firefox/browser/features/fxmoni...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: Firefox Screenshots
Location: /usr/lib/firefox/browser/features/screensh...@mozilla.org.xpi
Package: firefox
Status: user-disabled

Name: Form Autofill
Location: /usr/lib/firefox/browser/features/formautof...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: uBlock Origin
Location: ${PROFILE_EXTENSIONS}/ublo...@raymondhill.net.xpi
Status: enabled

Name: Video DownloadHelper
Location: ${PROFILE_EXTENSIONS}/{b9db16a4-6edc-47ec-a1f4-b86292ed211d}.xpi
Status: enabled

Name: Web Compat
Location: /usr/lib/firefox/browser/features/webcom...@mozilla.org.xpi
Package: firefox
Status: enabled

Name: WebCompat Reporter
Location: /usr/lib/firefox/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox
Status: user-disabled

-- Plugins information
Name: Shockwave Flash (32.0.0.192)
Location: /usr/lib/flashplayer-mozilla/libflashplayer.so
Package: flashplayer-mozilla
Status: disabled


-- Addons package information
ii  firefox 67.0-3amd64Mozilla Firefox web 
browser
ii  flashplayer-mozilla 3:32.0.0.192-dmo2 amd64Adobe Flash Player

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 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:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

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-10
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.21-1
ii  libnss3   2:3.44+really3.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  libavcodec58  10:4.1.3-dmo1

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
pn  pulseaudio 

-- no debconf information



Bug#885818: alltray: Depends on gconf

2019-06-02 Thread pk
alltray works on openbox on Buster, as of June 2019.

The original issue was solved ("depends on gconf"). The severity
serious is inappropriate and should be lowered, even if this report
stays open for the unrelated, potential issues mentioned in message
#28 (gnome theme, exit code).

Thanks



Bug#928956: Document removal of ecryptfs-utils from Buster

2019-06-02 Thread Holger Wansing
Hi,

Am Sonntag, 2. Juni 2019 schrieb Justin B Rye:
> Paul Gevers wrote:
> > +The ecryptfs-utils 
> > package
> > +is not part of buster due to an unfixed serious bug ( > +url="&url-bts;765854">#765854). At the time of writing 
> > this
> > +paragraph, there wasn't a clear advice to people with 
> > encryptfs,
> > +except not upgrading.
> 
> Advice is a non-count noun, and "not upgrading" doesn't quite fit the
> grammar either.  Make it
> 
>paragraph, there was no clear advice for users of encryptfs,
>except not to upgrade.
> 
> And I'm not sure even the non-upgrade option counts as clear advice,
> but I suppose it's the nearest thing we've got.

Maybe adding something like
"or migrate to " 
to the end would be helpfu?

And also, I wonder if "ecryptfs-utils" (without n) and 
encryptfs (with n) are both correct?

Holger 
 

-- 
Sent from my Jolla phone
http://www.jolla.com/

Bug#929875: update

2019-06-02 Thread jnqnfe
I've switched to the version on experimental (2:3.44.0-1) and that
fixes the problem



Bug#929875: getting error on most HTTPS pages: NS_ERROR_NET_INADEQUATE_SECURITY

2019-06-02 Thread jnqnfe
Package: libnss3
Version: 2:3.44+really3.42.1-1
Severity: high

Just updated my Sid install, now most HTTPS pages in Firefox are giving
me the error NS_ERROR_NET_INADEQUATE_SECURITY :/



Bug#928956: Document removal of ecryptfs-utils from Buster

2019-06-02 Thread Justin B Rye
Paul Gevers wrote:
> +The ecryptfs-utils 
> package
> +is not part of buster due to an unfixed serious bug ( +url="&url-bts;765854">#765854). At the time of writing 
> this
> +paragraph, there wasn't a clear advice to people with encryptfs,
> +except not upgrading.

Advice is a non-count noun, and "not upgrading" doesn't quite fit the
grammar either.  Make it

   paragraph, there was no clear advice for users of encryptfs,
   except not to upgrade.

And I'm not sure even the non-upgrade option counts as clear advice,
but I suppose it's the nearest thing we've got.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff --git a/en/issues.dbk b/en/issues.dbk
index 481df49b..b713646c 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -333,8 +333,8 @@ $ sudo update-initramfs -u
 The ecryptfs-utils package
 is not part of buster due to an unfixed serious bug (#765854). At the time of writing this
-paragraph, there wasn't a clear advice to people with encryptfs,
-except not upgrading.
+paragraph, there was no clear advice for users of encryptfs,
+except not to upgrade.
   
 
   


Bug#929874: unblock: several autopkgtest fixes for node-*

2019-06-02 Thread Graham Inggs
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Hi Release Team

The upload of autopkgtest/5.2 in March 2018 included a fix for quoting
when printing the test command in the testbed (#893035).  This caused
autopkgtest regressions in at least 36 node-* packages.  At the time,
I filed bugs for these.  During the course of the year, most of these
were fixed.

I recently uploaded fixes for the last of these:
node-ansi
node-archy
node-bl
node-clarinet
node-content-disposition
node-cookies
node-entities
node-findit2
node-music-library-index
node-nwmatcher
node-parseurl
node-pend
node-stylus
node-yazl
node-ytdl-core

Thank you for already unblocking node-ansi and node-archy.  Please
consider unblocking the remaining packages as well.

Regards
Graham



Bug#929873: unblock: radicale/2.1.11-6

2019-06-02 Thread Jonas Smedegaard
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Please unblock package radicale

Compared to -4 now in buster, -6 now in sid contains a fix for bug#919339
which affects new installs (not upgrades) of Radicale.

This is the diff for the bugfix specifically:

- --- 
radicale-2.1.11_buster/debian/etc/uwsgi/apps-available/radicale.ini>2019-01-15 
02:40:10.0 +0100
+++ 
radicale-2.1.11/debian/etc/uwsgi/apps-available/radicale.ini<-->2019-04-08 
22:07:57.0 +0200
@@ -39,13 +39,15 @@
 module = radicale
 env = RADICALE_CONFIG=/etc/radicale/config
.
- -chdir = /var/lib/radicale/collections
+umask 027
.
- -if-not-exists = /var/lib/radicale
- -exec-as-root = mkdir -p /var/lib/radicale
+if-not-exists = /var/lib/radicale/collections
+exec-as-root = mkdir -p /var/lib/radicale/collections
 endif =
 if-not-exists = /var/log/radicale
- -exec-as-root = mkdir -p /var/log/radicale/collections
+exec-as-root = mkdir -p /var/lib/radicale
 endif =
- -exec-as-root = if ! dpkg-statoverride --list /var/lib/radicale >/dev/null 
2>&1; then chown radicale: /var/lib/radicale /var/lib/radicale/collections; 
chmod g-w,o-rwx /var/lib/radicale; fi
+exec-as-root = if ! dpkg-statoverride --list /var/lib/radicale >/dev/null 
2>&1; then chown radicale: /var/lib/radicale /var/lib/radicale/collections; 
chmod g-w,o-rwx /var/lib/radicale /var/lib/radicale/collections; fi
 exec-as-root = if ! dpkg-statoverride --list /var/log/radicale >/dev/null 
2>&1; then chown radicale:adm /var/log/radicale; chmod g-w,o-rwx 
/var/log/radicale; fi
+
+chdir2 = /var/lib/radicale/collections


Attached is the full debdiff, additionally fixing/improving documention
and example code, and adding a missing package suggestion.

unblock radicale/2.1.11-6

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAlzzl3kACgkQLHwxRsGg
ASFOqhAAgfaSAZNh2OzRAkbtU3j+63mDnsQoWcf2Rr4sVeG4Td+/qveDyNWD79w/
86OiQ9DwZQB4HnYSKTWJJCGgUFl+kHfokpB/vVM14hbvcp/nft2bbrbscxqScSro
PBUXi/aQrsnGru6bCp89yp3AG7cieBaa6RRBKanOsdeZSwmdksZAgM8QWTAs+YNn
efQe63AGDxlnAwweBUmR3dLzDZXLhVyrshgPoHBnAwZj07svsnek9pSQeYYrP+jR
t2P5I+0AyXyJQw922WNyRynl+PXFrMXPJevFMzwVuVAAxRGTWqTModPFr3CAdgF+
2WZnCHcc1xZa1TYoSLk8JYhEcpfc8Y9FuwE2AGhW8MBJ/VNJfHRUOinnBaNE66zV
6mnqbV3ba450+v1IqHGNLVSrRp8UpJZdkFpRJ+7hSM2dGK82ht0fEpTFPpZWsPxI
7UtpcVrDvlLPSH3QI4LLiq/Z9dafyE2v+Ur2v3tyZR4kqbcqJzoZ0EgfBO3jeAOc
L0Y2fRTN6ddiMj7pTFZlE8fo1ZG813CM8RgXGZQakZYeRJEFyfQ62qQK9NmTGJjo
1bU41JGqlnXq7039Pcj7iwftzkCnRJo11ZGpFkELMFVAhxiyqPTalloH8mHmmC3I
p5HfAChID8VkjpTa7Myvf6ZuN+uo7dJbJVI8ca8RE2NMdVfEwPk=
=r5Mo
-END PGP SIGNATURE-
diff -ruN radicale-2.1.11_buster/debian/changelog 
radicale-2.1.11/debian/changelog
--- radicale-2.1.11_buster/debian/changelog 2019-02-07 02:28:00.0 
+0100
+++ radicale-2.1.11/debian/changelog2019-04-08 22:11:56.0 +0200
@@ -1,3 +1,26 @@
+radicale (2.1.11-6) unstable; urgency=medium
+
+  * Really fix directory creation and access rights of /var/lib/radicale.
+Closes: Bug#919339. Thanks to Slavko.
+
+ -- Jonas Smedegaard   Mon, 08 Apr 2019 22:11:56 +0200
+
+radicale (2.1.11-5) unstable; urgency=medium
+
+  * Update watch file:
++ Rewrite usage comment.
++ Simplify regular expressions.
+  * Fix suggest uwsgi-plugin-python3,
+and adapt long description and README.Debian.
+Thanks to A. F. Cano.
+  * Fix typos DOMAIN → _DOMAIN in example vhost snippet.
+Thanks to A. F. Cano.
+  * Fix have uwsgi snippet create collections subdir below /var/lib
+(not bogusly below /var/log).
+Closes: Bug#919339.
+
+ -- Jonas Smedegaard   Mon, 08 Apr 2019 12:52:13 +0200
+
 radicale (2.1.11-4) unstable; urgency=medium
 
   * Add NEWS entry about incompatible changes to storage format.
diff -ruN radicale-2.1.11_buster/debian/control radicale-2.1.11/debian/control
--- radicale-2.1.11_buster/debian/control   2019-01-15 02:41:55.0 
+0100
+++ radicale-2.1.11/debian/control  2019-03-27 08:18:37.0 +0100
@@ -44,6 +44,7 @@
  python3-bcrypt,
  python3-passlib,
  uwsgi,
+ uwsgi-plugin-python3,
 Provides:
  ${python:Provides},
 Description: simple calendar and addressbook server - daemon
@@ -62,8 +63,8 @@
  python3-bcrypt.
  .
  Serving directly with uWSGI
-  requires the package uwsgi.
- Serving with Apache as front-end and uWSGI as middleware
+ requires the packages uwsgi and uwsgi-plugin-python3.
+ Serving with Apache as front-end and uWSGI only as middleware
  additionally requires the packages apache2 and libapache2-mod-proxy-uwsgi.
 
 Package: python3-radicale
diff -ruN radicale-2.1.11_buster/debian/etc/uwsgi/apps-available/radicale.ini 
radicale-2.1.11/debian/etc/uwsgi/apps-available/radicale.ini
--- radicale-2.1.11_buster/debian/etc/uwsgi/apps-available/radicale.ini 
2019-01-15 02:40:10.0 +0100
+++ radicale-2.1.11/debian/etc/uwsgi/apps-available/radicale.ini
2019-04-08 22:07:57.0 +0200
@@ -39,13 +39,15 @@

Bug#929820: nmu: cdebootstrap_0.7.7+b11

2019-06-02 Thread Paul Gevers
Grr.

On 02-06-2019 11:07, Paul Gevers wrote:
>> nmu cdebootstrap_0.7.7+b11 . ANY . buster . -m "Rebuild for change in 
>> libdebian-installer (v0.119)"
>  should not have been there.

And it should have been ". unstable ." i.s.o. buster.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#929820: nmu: cdebootstrap_0.7.7+b11

2019-06-02 Thread Paul Gevers
Control: tags -1 confirmed

On 31-05-2019 22:38, Diederik de Haas wrote:
> nmu cdebootstrap_0.7.7+b11 . ANY . buster . -m "Rebuild for change in 
> libdebian-installer (v0.119)"
 should not have been there.

> I don't know if this is the correct way, but cdebootstrap-static needs a
> rebuild to pick up the change in libdebian-installer (version 0.119,
> fixing #55) and this is my attempt to request it.

I scheduled the binNMU, but the new version can only migrate when
libdebian-installer migrates and it still needs a manual unblock. Hence,
not closing the bug yet.

Paul



signature.asc
Description: OpenPGP digital signature


Bug#929828: unblock: cryptsetup/2:2.1.0-4

2019-06-02 Thread Paul Gevers
Control: tags -1 confirmed

On 01-06-2019 12:10, Guilhem Moulin wrote:
> Debdiff between 2:2.1.0-3 and 2:2.1.0-4 attached.  This also includes a
> patch by jmtd fixing the long description of cryptsetup-{bin,run}.  The
> diff doesn't touch our .udeb binary packages, but X-Debbugs-CC'ing kibi
> anyway as cryptsetup is also under udeb-block.
> 
> unblock cryptsetup/2:2.1.0-4

I'm fine with this. I'll unblock after the ack of kibi as I am not sure
about checking the udeb part myself (an area that I still have to learn).

Paul



signature.asc
Description: OpenPGP digital signature


  1   2   >