Bug#929098: linux-image-4.19.0-5-amd64: No graphics with Radeon Vega 1.0

[Owen Riddy]

Package: src:linux
Version: 4.19.37-3
Severity: important

Dear Maintainer,

I upgraded to linux-image-4.19.0-5-amd64 from 4.19.0-4-amd64. Previously the 
system booted,
loaded the driver module (I think amdgpu) and everything was fine. After the 
upgrade the
boot process gets to about the point that the driver should be loaded and hangs 
with a
 blank black screen. I can't find any logging evidence of what is going wrong. 
The system
still boots fine if the old kernel is chosen in grub.

The first version with the problem was 4.19.37-1. I waited a few days and tried 
again
with 4.19.37-3 (currently in unstable). Now I've jumped ship to the 5.0.0 
kernel in  
experimental and filed this bug. I'm a bit stumped as to ow to gather useful 
information
for this style of kernel bug.

Cheers.

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

** Model information
sys_vendor: System manufacturer
product_name: System Product Name
product_version: System Version
chassis_vendor: Default string
chassis_version: Default string
bios_vendor: American Megatrends Inc.
bios_version: 0225
board_vendor: ASUSTeK COMPUTER INC.
board_name: ROG STRIX X470-F GAMING
board_version: Rev X.0x

** PCI devices:
00:00.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-0fh) Root Complex [1022:1450]
Subsystem: ASUSTeK Computer Inc. Family 17h (Models 00h-0fh) Root 
Complex [1043:8747]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- 

00:01.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:02.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:04.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:08.0 Host bridge [0600]: Advanced Micro Devices, Inc. [AMD] Family 17h 
(Models 00h-1fh) PCIe Dummy Host Bridge [1022:1452]
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 SMBus [0c05]: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller 
[1022:790b] (rev 59)
Subsystem: ASUSTeK Computer Inc. FCH SMBus Controller [1043:8747]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
SERR- TAbort- 
SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- TAbort- SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

01:00.1 SATA controller [0106]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset SATA Controller [1022:43c8] (rev 01) (prog-if 01 [AHCI 1.0])
Subsystem: ASMedia Technology Inc. 400 Series Chipset SATA Controller 
[1b21:1062]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: ahci
Kernel modules: ahci

01:00.2 PCI bridge [0604]: Advanced Micro Devices, Inc. [AMD] 400 Series 
Chipset PCIe Bridge [1022:43c6] (rev 01) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- 

Bug#929034: evolvotron: Evolvotron can't stat (segmentation fault)

[Saverio Brancaccio]

Hi Axel,

> Anyway, I already forwarded the issue to the upstream  developer in the
hope that he can shed some light on this issue.

Many thanks to have contacted the author, hoping he can give some info,
even though he's not maintainig Evolvotron anymore.
Thanks also for your patience and suggestions you given me to better
writing bug reports.
I'm going to follow this thread for any coming news...

Bug#926915: RFS: fossology/3.5.0-1 [ITP] -- OSS license compliance tool

[Paul Wise]

On Thu, Apr 25, 2019 at 5:18 PM Gaurav Mishra wrote:

> I have updated the dependencies and made them specific to Debian Stretch.

New and reintroduced packages enter Debian through unstable, so your
initial package should be built and tested on unstable. Once it
reaches testing after the buster freeze and release is done, then it
can be added to the buster and stretch backports.

https://backports.debian.org/Contribute/

PS: in case you haven't read it yet, the extra procedures for
reintroducing packages are here:

https://www.debian.org/doc/manuals/developers-reference/ch05.html#reintroducing-pkgs

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Paul Wise]

On Thu, 2019-05-16 at 19:57 +0530, Ritesh Raj Sarraf wrote:

> what is the best way to request a rebuild of the package ?

reportbug release.debian.org and select binnmu.

https://wiki.debian.org/binNMU
https://release.debian.org/wanna-build.txt
https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#binary-only-nmu

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#929097: unblock: u-boot/2019.01+dfsg-7

[Vagrant Cascadian]

Package: release.debian.org
User: release.debian@packages.debian.org
Usertags: unblock
Severity: normal
X-Debbugs-CC: debian-b...@lists.debian.org

Please unblock package u-boot

This u-boot update fixes two minor CVEs with backported patches, one
for ext4 support and one with insufficiently random GPT partition
table generation.

It also is enables support for three additional platforms, which should
have little impact on existing platforms. Two of these additional
platforms have been enabled in debian-installer using u-boot binaries.

The already backported support for Teres-I platform was synced with
upstream, fixing USB support.

Support for the PocketBeagle was backported from upstream, which is
the largest part of the diff as it contains the device-tree for the
platform.

A small clarification was added to the u-boot-omap README to reduce
the risk of accidentally overwriting the partition table on the
am335x_beagleboneblack platform.


diff -Nru u-boot-2019.01+dfsg/debian/bin/u-boot-install-sunxi64 
u-boot-2019.01+dfsg/debian/bin/u-boot-install-sunxi64
--- u-boot-2019.01+dfsg/debian/bin/u-boot-install-sunxi64   2019-04-19 
15:21:52.0 -0700
+++ u-boot-2019.01+dfsg/debian/bin/u-boot-install-sunxi64   2019-05-13 
18:03:24.0 -0700
@@ -6,9 +6,11 @@
case $(cat "${dtmodel}") in
Pinebook) TARGET="/usr/lib/u-boot/pinebook" ;;
Pine64+) TARGET="/usr/lib/u-boot/pine64_plus" ;;
+   "Pine64 LTS") TARGET="/usr/lib/u-boot/pine64-lts" ;;
"Olimex A64-Olinuxino") TARGET="/usr/lib/u-boot/a64-olinuxino/" 
;;
"Olimex A64 Teres-I") TARGET="/usr/lib/u-boot/teres_i/" ;;
"OrangePi Zero Plus2") 
TARGET="/usr/lib/u-boot/orangepi_zero_plus2/" ;;
+   "FriendlyARM NanoPi NEO 2") 
TARGET="/usr/lib/u-boot/nanopi_neo2/" ;;
esac
 fi
 
diff -Nru u-boot-2019.01+dfsg/debian/changelog 
u-boot-2019.01+dfsg/debian/changelog
--- u-boot-2019.01+dfsg/debian/changelog2019-04-19 16:43:08.0 
-0700
+++ u-boot-2019.01+dfsg/debian/changelog2019-05-13 19:07:44.0 
-0700
@@ -1,3 +1,32 @@
+u-boot (2019.01+dfsg-7) unstable; urgency=medium
+
+  [ Sunil Mohan Adapa ]
+  * Enable pine64-lts target in u-boot-sunxi (Closes: #928947).
+
+  [ Vagrant Cascadian ]
+  * u-boot-omap: Enable am335x_evm target.
+  * Add patches to enable PocketBeagle in am335x_evm target.
+  * u-boot-omap: Fix instructions for installing beaglebone black.
+
+ -- Vagrant Cascadian   Mon, 13 May 2019 19:07:44 -0700
+
+u-boot (2019.01+dfsg-6) unstable; urgency=medium
+
+  [ Domenico Andreoli ]
+  * Enable support for NanoPi NEO 2 in u-boot-sunxi (Closes: #928612).
+
+  [ Jonas Smedegaard ]
+  * Sync sunxi teres-i patch with mainline u-boot, enabling USB
+support (Closes: #928815).
+
+  [ Vagrant Cascadian ]
+  * Apply patch from upstream fixing buffer overflow with ext4 filesystems
+(CVE-2019-11059, Closes: #928800).
+  * Apply patch from upstream fixing randomly generated
+UUIDs. (CVE-2019-11690, Closes: #928557).
+
+ -- Vagrant Cascadian   Sat, 11 May 2019 18:20:19 -0700
+
 u-boot (2019.01+dfsg-5) unstable; urgency=medium
 
   [ Jonas Smedegaard ]
diff -Nru 
u-boot-2019.01+dfsg/debian/patches/pocketbeagle/0001-ti-Add-device-tree-for-am335x-pocketbeagle.patch
 
u-boot-2019.01+dfsg/debian/patches/pocketbeagle/0001-ti-Add-device-tree-for-am335x-pocketbeagle.patch
--- 
u-boot-2019.01+dfsg/debian/patches/pocketbeagle/0001-ti-Add-device-tree-for-am335x-pocketbeagle.patch
   1969-12-31 16:00:00.0 -0800
+++ 
u-boot-2019.01+dfsg/debian/patches/pocketbeagle/0001-ti-Add-device-tree-for-am335x-pocketbeagle.patch
   2019-05-13 18:47:19.0 -0700
@@ -0,0 +1,401 @@
+From 59a1df084f4a47e98d31cdc483a514575d8ff676 Mon Sep 17 00:00:00 2001
+From: Vagrant Cascadian 
+Date: Mon, 29 Apr 2019 16:12:29 -0700
+Subject: [PATCH 1/2] ti: Add device-tree for am335x-pocketbeagle.
+
+Add device-tree files from linux 5.1-rc7 needed to complete support
+for PocketBeagle.
+
+Signed-off-by: Vagrant Cascadian 
+Reviewed-by: Tom Rini 
+---
+ arch/arm/dts/Makefile   |   1 +
+ arch/arm/dts/am335x-osd335x-common.dtsi | 124 +
+ arch/arm/dts/am335x-pocketbeagle.dts| 237 
+ 3 files changed, 362 insertions(+)
+ create mode 100644 arch/arm/dts/am335x-osd335x-common.dtsi
+ create mode 100644 arch/arm/dts/am335x-pocketbeagle.dts
+
+Index: u-boot/arch/arm/dts/Makefile
+===
+--- u-boot.orig/arch/arm/dts/Makefile
 u-boot/arch/arm/dts/Makefile
+@@ -190,6 +190,7 @@ dtb-$(CONFIG_AM33XX) += am335x-boneblack
+   am335x-evmsk.dtb \
+   am335x-bonegreen.dtb \
+   am335x-icev2.dtb \
++  am335x-pocketbeagle.dtb \
+   am335x-pxm50.dtb \
+   am335x-rut.dtb \
+   am335x-pdu001.dtb \
+Index: u-boot/arch/arm/dts/am335x-osd335x-common.dtsi

Bug#929096: unattended-upgrades: defaults change to upgrade stable suite

[Sean Whitton]

Package: unattended-upgrades, release-notes
Version: 1.11

Hello,

The version of unattended-upgrades in stretch defaulted to not upgrading
the stable suite.  It would install only security updates.

The version of unattended-upgrades in buster upgrades both the stable
suite and security upgrades.  I.e. it will pull in point releases too.

There are probably good reasons for this defaults change, but I think it
needs to be documented, either in NEWS.Debian for unattended-upgrades,
and/or (since the package is very widely installed) in the buster
release notes.

Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#929095: ITP: scheme-bytestructures -- Structured access to bytevector contents

[Vagrant Cascadian]

Package: wnpp
Owner: Vagrant Cascadian 
Severity: wishlist

* Package name: scheme-bytestructures or guile-bytestructures
  Version : 1.0.5
  Upstream Author : Taylan Ulrich Bayırlı/Kammer
* URL or Web page : https://github.com/TaylanUB/scheme-bytestructures/
* License : GPL-3+, LGPL-3+
  Description : Structured access to bytevector contents
  
  This library offers a system imitating the type system of the C
  programming language, to be used on bytevectors.  C's type system
  works on raw memory, and ours works on bytevectors which are an
  abstraction over raw memory in Scheme.  The system is in fact more
  powerful than the C type system, elevating types to first-class
  status.

First draft of packaging: https://salsa.debian.org/vagrant/scheme-bytestructures

This is a dependency to package guile-git: https://bugs.debian.org/929094


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#929094: ITP: guile-git -- guile bindings for git

[Vagrant Cascadian]

Package: wnpp
Owner: Vagrant Cascadian 
Severity: wishlist

* Package name: guile-git
  Version : 0.2.0
  Upstream Author : Amirouche Boubekki
* URL or Web page : https://gitlab.com/guile-git/guile-git/
* License : GPL-3+, LGPL-3+, GFDL-1.3+ (with exceptions), others
  Description : guile bindings for git

 Guile-Git is a GNU Guile library providing bindings to
 libgit2.

First draft of packaging: https://salsa.debian.org/vagrant/guile-git

This is a dependency to package GNU Guix: https://bugs.debian.org/850644

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#929093: ITP: guile-ssh -- guile bindings to ssh

[Vagrant Cascadian]

Package: wnpp
Owner: Vagrant Cascadian 
Severity: wishlist

* Package name: guile-ssh
  Version : 0.11.3
  Upstream Author : Artyom V. Poptsov
* URL or Web page : https://github.com/artyom-poptsov/guile-ssh/
* License : GPL-3+, Expat, LGPL-3+, and more!
  Description : guile bindings to ssh

 Guile-SSH is a library that provides access to the SSH protocol for programs
 written in GNU Guile interpreter.  It is built upon the libssh library.


First draft of packaging: https://salsa.debian.org/vagrant/guile-ssh

This is a dependency to package GNU Guix: https://bugs.debian.org/850644


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#929092: ITP: guile-sqlite3 -- guile bindings for sqlite3

[Vagrant Cascadian]

Package: wnpp
Owner: Vagrant Cascadian 
Severity: wishlist

* Package name: guile-sqlite3
  Version : 0.1.0
  Upstream Author : Andy Wingo
* URL or Web page : https://notabug.org/guile-sqlite3/guile-sqlite3
* License : LGPL-3+, GPL-3+
  Description : guile bindings for sqlite3

 Guile bindings for the SQLite3 database engine.


First draft of packaging: https://salsa.debian.org/vagrant/guile-sqlite3

This is a dependency to package GNU Guix: https://bugs.debian.org/850644


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#929034: evolvotron: Evolvotron can't stat (segmentation fault)

[Axel Beckert]

Control: forwarded -1 tim...@timday.com

Hi Saverio,

Saverio Brancaccio wrote:
> considering that Evolvotron (the version in subject) was working before, it
> seems that the cause of the bug is related to some library like Qt5 or
> Boost that has been updated,

Correct.

> so the application can't find the correct calls downside,

That's usually cared about by doing a rebuild against the newer
library version where necessary and the according versioned library
package names.

> leading to segmentation fault...

But since we still have a segfault rather often (but still not
always), it's either a bug in evolvotron which only surfaced with
newer library versions or a bug in one of these libraries which only
shows up in evolvotron - of which I kinda doubt the latter as both
libraries are used by many more popular packages in Debian and we're
very deep in the freeze now, so such issues should have surfaced
elsewhere, too.

> Is there any possibility to fix the bug considering some change in the
> building configuration (pointing to the wanted version of Qt5 or Boost) and
> recompile again Evolvotron from sources?

I doubt that for the same reasons as above. But to be sure, I just
build the package again on an up to date Debian Sid: No change in
behaviour, still segfaults most of the time.

Saverio Brancaccio wrote:
> I checked in other distribution (e.g. ubuntu LTS)

I think you mean Ubuntu 18.04 LTS. There is also Ubuntu 16.04 LTS and
until recently there was also Ubuntu 14.04 LTS.

> and the Evolvotron (v.7.1) works...

I think you mean 0.7.1.

> the difference I noticed in lib versions is that libboost used there
> is 1.65.1 and not the recent one like in debian (1.67 ?)

Sure, things evolve and evolvotron got rebuilt against Boost 1.67 with
the 0.7.1-2+b1 binary upload in November 2018.

> Could it be possible to statically link the 1.65 lib to this app,
> build it and try a run?

Not that easily. And I must admit, I rather suspect changes in Qt than
in Boost, because (a) usually, incompatible changes in Boost usually
result in build failures and those would have been detect since Debian
tries to build every package every few weeks again to detect such
issues. And (b) the backtrace shows tons of Qt library calls shortly
before the crash.

Anyway, I already forwarded the issue to the upstream developer in the
hope that he can shed some light on this issue.

P.S.: Please don't send full quotes of backtraces to the Debian bug
tracking system. Just quote those sections you explicitly reply to.
See yourself how much completely redundant information has to be
scrolled over when reading your replies there:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929034#19
Thanks in advance!

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

Bug#929091: ITP: guile-gcrypt -- gcrypt bindings for guile

[Vagrant Cascadian]

Package: wnpp
Owner: Vagrant Cascadian 
Severity: wishlist

* Package name: guile-gcrypt
  Version : 0.1.0
  Upstream Author : Christopher Allan Webber and others
* URL or Web page : https://notabug.org/cwebber/guile-gcrypt
* License : GPL-3+, Expat, GFDL-1.3+ (with exceptions)
  Description : gcrypt bindings for guile

 Guile-Gcrypt provides a Guile 2.x interface to a subset of the GNU
 Libgcrypt crytographic library, which is itself used by the GNU Privacy
 Guard (GPG).

 Guile-Gcrypt provides modules for cryptographic hash functions, message
 authentication codes (MAC), public-key crytography, strong randomness,
 and more.  It is implemented using the foreign function interface (FFI)
 of Guile.

First draft of packaging: https://salsa.debian.org/vagrant/guile-gcrypt


This is a dependency to package GNU Guix: https://bugs.debian.org/850644

live well,
  vagrant


signature.asc
Description: PGP signature

Bug#918854: segfault updating crates.io index

[Antoine Beaupre]

Package: cargo
Version: 0.33.0-1
Followup-For: Bug #918854

I'm seeing the same thing in buster right now. It's intermittent, and
the build eventually finishes if retried.

It's especially annoying when building Docker containers, which do not
afford the luxury of retries. A reliable way to trigger it is to set
the `http_proxy` environment (even if to the empty string).

The following Dockerfile (when ran inside
https://gitlab.com/sequoia-pgp/sequoia) reproduces this reliably for
me:

# we do not use the rust image because it's based on Debian stretch
# where nettle and rustc are too old
FROM debian:buster AS build

COPY . /home/builder/sequoia

# create a sandbox user for the build (in ~builder) and install (in /opt)
# give it permissions to the build dir and home
# upgrade everything
# add dependencies, as specified by the Sequoia README.md file
RUN groupadd -r builder && \
useradd --no-log-init -r -g builder builder && \
chown -R builder:builder /home/builder /opt && \
apt update && apt upgrade -yy && \
apt install -y --no-install-recommends \
ca-certificates \
capnproto \
cargo \
clang \
git \
libsqlite3-dev \
libssl-dev \
make \
nettle-dev \
pkg-config \
python3-dev \
python3-setuptools \
python3-cffi \
python3-pytest \
rustc

# switch to the sandbox user
USER builder

RUN make -C /home/builder/sequoia

I since then changed the dockerfile to build the project three times
in an attempt to work around the issue, which more or less works
reliably. Here are two segfaults that were triggered in the last
build:

mai 16 18:12:28 curie kernel: cargo[25318] segfault at 5562b ip 
0005562b sp 7fff0d0e8678 error 14 in cargo[562b40957000+5c000] 
mai 16 18:12:28 curie kernel: Code: Bad RIP value. 
mai 16 18:12:33 curie kernel: cargo[25346] segfault at 60228 ip 
7f87ec5ba407 sp 7ffdc3227c90 error 4 in 
libcurl-gnutls.so.4.5.0[7f87ec572000+61000] 
mai 16 18:12:33 curie kernel: Code: 48 39 c2 75 10 48 8b 87 d8 16 00 00 48 39 
87 c0 0f 00 00 74 26 48 8d 6c 24 0c 48 89 ee e8 31 ff ff ff 31 f6 48 89 e9 48 
89 df <41> 8b 94 24 28 02 00 00 e8 8c 81 fb ff 85 c0 75 08 48 89 df e8 e0 

This command is a reliable reproducer:

env http_proxy= cargo build

mai 16 18:16:12 curie kernel: cargo[499] segfault at 0 ip 7f9d47cb8181 sp 
7ffe8d0dbd58 error 4 in libc-2.28.so[7f9d47b7e000+148000] 
mai 16 18:16:12 curie kernel: Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 
c3 66 2e 0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 
77 1f  fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1 

... but could be unrelated.

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

Kernel: Linux 4.19.0-4-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.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 cargo depends on:
ii  binutils  2.31.1-16
ii  clang 1:7.0-47
ii  clang-7 [c-compiler]  1:7.0.1-8
ii  gcc   4:8.3.0-1
ii  gcc-8 [c-compiler]8.3.0-6
ii  libc6 2.28-10
ii  libcurl3-gnutls   7.64.0-2
ii  libgcc1   1:8.3.0-6
ii  libgit2-270.27.7+dfsg.1-0.1
ii  libssh2-1 1.8.0-2.1
ii  libssl1.1 1.1.1b-2
ii  rustc 1.32.0+dfsg1-3
ii  zlib1g1:1.2.11.dfsg-1

cargo recommends no packages.

Versions of packages cargo suggests:
pn  cargo-doc  
ii  python33.7.2-1

-- debconf-show failed

Bug#850644: #850644: RFP: guix -- A functional package manager based on Scheme

[Vagrant Cascadian]

Control: block 850644 by 863147

On 2019-05-16, Vagrant Cascadian wrote:
> * guile-gnutls needs to be (re)enabled in libgnutls*:
>
>   https://salsa.debian.org/vagrant/gnutls

This is apparently marked as wontfix back in 2016 due to intermittant
test failues:

  https://bugs.debian.org/863147

Though at the time it was using guile-2.0; maybe guile-2.2 passes the
tests more reliably? Ask nicely to enable in experimental? Hrm.


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#929090: xfwm4: ButtonPress event from Tk triggers Enter and Leave events

[Michael Lange]

Package: xfwm4
Version: 4.12.4-1
Severity: normal

Dear Maintainer,

in applications using the Tk toolkit each time a mouse button is pressed
additional Enter and Leave events are triggered for no apparent reason. A
minimal wish script that illustrates this:

#!/usr/bin/env wish
frame .f -bg yellow -width 400 -height 300
pack .f -fill both -expand 1
bind .f  {puts "Button-1 event"}
bind .f  {puts "Enter event"}
bind .f  {puts "Leave event"}

I admit I am not really sure to which package this bug report should be
addressed.
These "bogus" Enter and Leave events do not occur with Gnome, KDE or Mate or
some older light-weight WMs like WindowMaker, FvWm or IceWm, so I believe it is
unlikely that it is a Tk bug. Otoh the same or similar behavior has also been
observed with Openbox/Lxde and awesome.
This behavior does still persist in the versions of Xfce/xfwm currently in
debian Sid (tested yesterday).
The bug was first reported on the tkinter-discuss mailing list and has been
discussed here:

https://mail.python.org/pipermail/tkinter-discuss/2019-May/004082.html

and on debian-user here:

https://lists.debian.org/debian-user/2019/05/msg00668.html

Best regards

Michael



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

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

Versions of packages xfwm4 depends on:
ii  libc6 2.24-11+deb9u4
ii  libcairo2 1.14.8-1
ii  libdbus-glib-1-2  0.108-2
ii  libgdk-pixbuf2.0-02.36.5-2+deb9u2
ii  libglib2.0-0  2.50.3-2
ii  libgtk2.0-0   2.24.31-2
ii  libpango-1.0-01.40.5-1
ii  libstartup-notification0  0.12-4+b2
ii  libwnck22 2.30.7-5.1
ii  libx11-6  2:1.6.4-3+deb9u1
ii  libxcomposite11:0.4.4-2
ii  libxdamage1   1:1.1.4-2+b3
ii  libxext6  2:1.3.3-1+b2
ii  libxfce4ui-1-04.12.1-2
ii  libxfce4util7 4.12.1-3
ii  libxfconf-0-2 4.12.1-1
ii  libxfixes31:5.0.3-1
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1

Versions of packages xfwm4 recommends:
ii  librsvg2-common  2.40.16-1+b1

Versions of packages xfwm4 suggests:
ii  xfce4 4.12.3
ii  xfwm4-themes  4.10.0-2

-- no debconf information

Bug#927036: set disable_random_resource = 0 has wrong effect

[Marriott NZ]

Seems fixed upstream:
https://bitbucket.org/McKael/mcabber-crew/commits/3385a4bb62efa71bb522ebd6e5f57c49e22a72e4

It doesn't really matter now, but I said that the empty string can deactivate 
the option and that is not true. It must be *unset* (never set or explicitly 
unset).

set disable_random_resource = "" # set to the empty string; "settings_opt_get" 
returns non-null pointer
set disable_random_resource =# unset; "settings_opt_get" returns null

Bug#929052: sffview FTCBFS: non-standard compiler variable

[Olly Betts]

Control: forwarded -1 https://sourceforge.net/p/sfftools/tickets/1/

On Thu, May 16, 2019 at 10:23:40PM +0200, Helmut Grohne wrote:
> On Thu, May 16, 2019 at 09:09:10PM +0100, Olly Betts wrote:
> > I think it makes more sense to patch the upstream Makefile to use CXX
> > instead of CC (we already patch it to support CXXFLAGS, etc).  I should
> > probably try to push that patch upstream, though upstream isn't very
> > active.
> 
> I concur that renaming the variable is a better solution. It would help
> other distributions as well.

Now filed upstream.

> > This doesn't seem suitable for unstable during the freeze, but I'll
> > upload to experimental.  Feel free to NMU to unstable once we're
> > unfrozen if I don't get to it.
> 
> I concur that this is not freeze material (and that should be obvious
> from the chosen severity). I don't think an experimental upload is
> necessary here. Just make sure that you close this bug if you make
> progress. Doing so will trigger a retest on my end (once it reaches
> unstable) and I can reopen in case it still doesn't work.

I've already uploaded.  I wanted to test the amended patch built before
pushing it upstream, so it was almost no extra work to make an upload
of the build.

Cheers,
Olly

Bug#929052: sffview FTCBFS: non-standard compiler variable

[Olly Betts]

On Thu, May 16, 2019 at 06:07:26AM +0200, Helmut Grohne wrote:
> sffview fails to cross build from source, because it uses a non-standard
> compiler variable CC for the C++ compiler. dh_auto_build passes a C
> compiler there and that does not work well. The attached patch renames
> the C++ compiler. Please consider applying it or using CXX in the
> upstream build system.

I think it makes more sense to patch the upstream Makefile to use CXX
instead of CC (we already patch it to support CXXFLAGS, etc).  I should
probably try to push that patch upstream, though upstream isn't very
active.

This doesn't seem suitable for unstable during the freeze, but I'll
upload to experimental.  Feel free to NMU to unstable once we're
unfrozen if I don't get to it.

Cheers,
Olly

Bug#924548: bug 924548: gnome-core: does not actually install a desktop environment on s390x

[Simon McVittie]

On Thu, 16 May 2019 at 20:10:19 +0200, Paul Gevers wrote:
> On Thu, 14 Mar 2019 10:29:06 + Simon McVittie  wrote:
> > I recently changed gnome-core to install gnome-flashback instead of
> > GNOME Shell on s390x, because: GNOME Shell is uninstallable on s390x, due
> > to mozjs60 not being functional there; testing migration requires task
> > packages to be installable; and the release team were not willing to waive
> > that requirement for s390x, because d-i maintainers were concerned that
> > d-i might do the wrong thing if asked to install an uninstallable task.
> 
> mozjs60 has been fixed (and uploaded by you to unstable), if I am
> correct to actually enable this bug to be fixed.

Unfortunately not. mozjs60 was believed to have been fixed (jcristau
NMU'd it to experimental, and I re-uploaded to unstable), but gnome-shell
still FTBFS on s390x because all of its unit tests segfault. This reduces
my already low level of confidence that gnome-shell can be usable on s390x.

Sorry, I have had limited time for Debian recently due to IRL commitments,
and couldn't justify spending any more of that time on debugging s390x
issues.

As it stands at the moment, GNOME Shell failing its tests and suffering
FTBFS on s390x is not RC; and I would prefer not to take action to ignore
the test failures and let it build anyway, because if we did that and it
was later discovered not to *work* on s390x (which I suspect is the case),
my understanding is that it would be considered a grave bug.

I would feel a lot more confident about (a) mozjs working, and (b)
this series of bugs not being entirely a waste of time and motivation,
if someone with an interest in s390x had been involved somewhere along
the way.

smcv

Bug#929088: sratom FTCBFS: Build-Depends: python not installable

[Helmut Grohne]

Source: sratom
Version: 0.6.0~dfsg0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

sratom fails to cross build from source, because its dependency on a
host architecture python is not installable. It really wants a build
architecture python to run waf though, so the dependency should be
annotated with :native or :any. For cross building with waf, one should
set up variables CC and PKGCONFIG (not PKG_CONFIG). The attached patch
makes sratom cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru sratom-0.6.0~dfsg0/debian/changelog 
sratom-0.6.0~dfsg0/debian/changelog
--- sratom-0.6.0~dfsg0/debian/changelog 2016-09-23 02:47:37.0 +0200
+++ sratom-0.6.0~dfsg0/debian/changelog 2019-05-16 22:17:47.0 +0200
@@ -1,3 +1,12 @@
+sratom (0.6.0~dfsg0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate Build-Depends: python with :native.
++ Pass cross tools to waf.
+
+ -- Helmut Grohne   Thu, 16 May 2019 22:17:47 +0200
+
 sratom (0.6.0~dfsg0-1) unstable; urgency=medium
 
   * New upstream version 0.6.0~dfsg0
diff --minimal -Nru sratom-0.6.0~dfsg0/debian/control 
sratom-0.6.0~dfsg0/debian/control
--- sratom-0.6.0~dfsg0/debian/control   2016-09-23 02:47:37.0 +0200
+++ sratom-0.6.0~dfsg0/debian/control   2019-05-16 22:17:12.0 +0200
@@ -11,7 +11,7 @@
  libsord-dev (>= 0.12.0~dfsg0),
  lv2-dev,
  pkg-config,
- python
+ python:native,
 Build-Depends-Indep:
  doxygen,
  graphviz
diff --minimal -Nru sratom-0.6.0~dfsg0/debian/rules 
sratom-0.6.0~dfsg0/debian/rules
--- sratom-0.6.0~dfsg0/debian/rules 2016-09-23 02:47:37.0 +0200
+++ sratom-0.6.0~dfsg0/debian/rules 2019-05-16 22:17:41.0 +0200
@@ -6,7 +6,9 @@
 
 export DEB_BUILD_MAINT_OPTIONS = hardening=+bindnow
 
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
+PKG_CONFIG ?= pkg-config
 LDFLAGS+=-Wl,--as-needed
 WAF = ./waf
 
@@ -18,6 +20,7 @@
dh $@ --parallel
 
 override_dh_auto_configure:
+   CC=$(CC) PKGCONFIG=$(PKG_CONFIG) \
$(WAF) configure \
--prefix=/usr \
--mandir=/usr/share/man \

Bug#929089: sord FTCBFS: Build-Depends: python not installable

[Helmut Grohne]

Source: sord
Version: 0.16.0~dfsg0-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

sord fails to cross build from source, because its dependency on a host
architecture python is not installable. It really wants a build
architecture python to run waf though, so the dependency should be
annotated with :native or :any. For cross building with waf, one should
set up variables CC and PKGCONFIG (not PKG_CONFIG). The attached patch
makes sord cross buildable. Please consider applying it.

Helmut
diff --minimal -Nru sord-0.16.0~dfsg0/debian/changelog 
sord-0.16.0~dfsg0/debian/changelog
--- sord-0.16.0~dfsg0/debian/changelog  2016-09-22 20:33:50.0 +0200
+++ sord-0.16.0~dfsg0/debian/changelog  2019-05-16 22:08:44.0 +0200
@@ -1,3 +1,12 @@
+sord (0.16.0~dfsg0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate Build-Depends: python with :native.
++ Pass cross tools to waf.
+
+ -- Helmut Grohne   Thu, 16 May 2019 22:08:44 +0200
+
 sord (0.16.0~dfsg0-1) unstable; urgency=medium
 
   * New upstream version 0.16.0~dfsg0
diff --minimal -Nru sord-0.16.0~dfsg0/debian/control 
sord-0.16.0~dfsg0/debian/control
--- sord-0.16.0~dfsg0/debian/control2016-09-22 20:33:50.0 +0200
+++ sord-0.16.0~dfsg0/debian/control2019-05-16 22:08:42.0 +0200
@@ -12,7 +12,7 @@
  libserd-dev (>= 0.24.0~dfsg0),
  libpcre++-dev,
  pkg-config,
- python
+ python:native,
 Standards-Version: 3.9.8
 Homepage: http://drobilla.net/software/sord/
 Vcs-Git: https://anonscm.debian.org/git/pkg-multimedia/sord.git
diff --minimal -Nru sord-0.16.0~dfsg0/debian/rules 
sord-0.16.0~dfsg0/debian/rules
--- sord-0.16.0~dfsg0/debian/rules  2016-09-22 20:33:50.0 +0200
+++ sord-0.16.0~dfsg0/debian/rules  2019-05-16 22:08:44.0 +0200
@@ -6,7 +6,9 @@
 dfsg_version = $(upstream_version)~dfsg0
 pkg = $(shell dpkg-parsechangelog | sed -ne 's/^Source: //p')
 
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
+include /usr/share/dpkg/architecture.mk
+-include /usr/share/dpkg/buildtools.mk
+PKG_CONFIG ?= pkg-config
 LDFLAGS+=-Wl,--as-needed
 WAF = ./waf
 
@@ -14,6 +16,7 @@
dh $@ --parallel
 
 override_dh_auto_configure:
+   CC=$(CC) PKGCONFIG=$(PKG_CONFIG) \
$(WAF) configure \
--prefix=/usr \
--mandir=/usr/share/man \

Bug#929052: sffview FTCBFS: non-standard compiler variable

[Helmut Grohne]

On Thu, May 16, 2019 at 09:09:10PM +0100, Olly Betts wrote:
> I think it makes more sense to patch the upstream Makefile to use CXX
> instead of CC (we already patch it to support CXXFLAGS, etc).  I should
> probably try to push that patch upstream, though upstream isn't very
> active.

I concur that renaming the variable is a better solution. It would help
other distributions as well.

> This doesn't seem suitable for unstable during the freeze, but I'll
> upload to experimental.  Feel free to NMU to unstable once we're
> unfrozen if I don't get to it.

I concur that this is not freeze material (and that should be obvious
from the chosen severity). I don't think an experimental upload is
necessary here. Just make sure that you close this bug if you make
progress. Doing so will trigger a retest on my end (once it reaches
unstable) and I can reopen in case it still doesn't work.

Helmut

Bug#929087: Priority information in packages file is not reliable

[Joerg Jaspert]

On 15404 March 1977, s3v wrote:


there is some divergence between priority information in Packages.xz file
and priority field in binary .deb file.


The Package file generated by the archive is correct, whatever is
written there has higher priority than whatever is in a .deb.


I think content of Packages.xz file does need to be fully reliable because
this file is parsed by DDTP [2] for:


Contents of the Packages file *is* what you should trust, do not parse
.debs for such information.

Not a bug, closing.

--
bye, Joerg

Bug#929042: singularity-container: CVE-2019-11328)

[Salvatore Bonaccorso]

Hi Afif,

On Thu, May 16, 2019 at 12:59:55PM -0400, Afif Elghraoui wrote:
> 
> 
> On May 15, 2019 5:13:24 PM EDT, Salvatore Bonaccorso  
> wrote:
> >Hi Afif,
> >
> >On Wed, May 15, 2019 at 10:57:49PM +0200, Salvatore Bonaccorso wrote:
> >> Then there is nothing further to be done.
> >
> >Oh, actually there is an open point: Is it confirmed that 3.0.3 is not
> >affected by the CVE? Did you got any information why this is only
> >introduced in 3.1.0?
> >
> 
> Ok, I asked upstream and the answer is that the commit that
> introduced the bug came after 3.0.3.

Thanks a lot for confirming!

This post to oss-security confirms it: 
https://www.openwall.com/lists/oss-security/2019/05/16/1

The security-tracker now will mark as well the buster version then as
not-affected.

Thanks for your work!

Regards,
Salvatore

Bug#850644: #850644: RFP: guix -- A functional package manager based on Scheme

[Vagrant Cascadian]

On 2018-05-16, Vagrant Cascadian wrote:
> The main build/runtime dependencies missing from Debian appear to be
> guile-git, and possibly a recommends on guile-ssh:
>
>   https://www.gnu.org/software/guix/manual/html_node/Building-from-Git.html
>   https://www.gnu.org/software/guix/manual/html_node/Requirements.html

Apparently, guix has grown a few additional dependencies since then...

So in a bit of a focused run of packaging, I've been chasing the
dependency chain necessary to get guix building on Debian:

* guile-gnutls needs to be (re)enabled in libgnutls*:

  https://salsa.debian.org/vagrant/gnutls

* guile-json needs to be updated to version 1.2.0 (3.x is incompatible),
  and I've pushed wip branches updating packaging for new upstream
  versions:

  https://salsa.debian.org/debian/guile-json

* I've gotten some packaging for guile-git, guile-gcrypt, guile-ssh and
  guile-sqlite3 which need some more polish and then uploading to
  Debian:

  https://salsa.debian.org/vagrant/guile-git
  https://salsa.debian.org/vagrant/guile-gcrypt
  https://salsa.debian.org/vagrant/guile-ssh
  https://salsa.debian.org/vagrant/guile-sqlite3

* guile-git required scheme-bytestructures, which I've packaged, and
  needs to be uploaded before guile-git can be:

  https://salsa.debian.org/vagrant/scheme-bytestructures


After all that, I did get to the point where I could at least try to
compile guix:

  https://salsa.debian.org/vagrant/guix

But no successful build just yet.


Whew!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#929082: unblock: razor/1:2.85-4.2

[Holger Levsen]

On Thu, May 16, 2019 at 09:52:45PM +0200, Paul Gevers wrote:
> Well, if they are maintained by the QA group, there are at least around
> 90 people notified of stuff.

no. noone is notified about bugs in packages maintained by the QA group.
(or maybe some poor soul is, but noone is reading those notices *if*
someone receives them.)


-- 
tschau,
Holger, member of the qa group

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature

Bug#929082: unblock: razor/1:2.85-4.2

[Paul Gevers]

Hi Santiago,

On 16-05-2019 20:24, Santiago Vila wrote:
> On Thu, May 16, 2019 at 07:43:09PM +0200, Paul Gevers wrote:
> 
>> The reason why it got removed, is that nobody was looking after razor.
>> Otherwise, preventing removal would have been easy.
> 
> Indeed. If I had known that it was going to be removed, I would have
> downgraded the severity of the bug before the autoremoval happened.

After the fact, I had the same idea.

> We have a lot of packages maintained by "Debian QA" and we don't
> remove them from Debian just because they don't have a proper
> maintainer. We just keep them because they are useful.
>
> So, if it helps, I would be willing to make an upload to officially
> orphan it (using "Debian QA" as the Maintainer field) to be on par
> with every other QA-maintained package. Personally, I don't think it
> would change things a lot but if it's the difference between keeping
> razor in or out of buster, I will be happy to make an upload for that.

Well, if they are maintained by the QA group, there are at least around
90 people notified of stuff.

> (And if that's not enough, I would even be willing to put my name in
> the maintainer field, only until we find another maintainer, but in
> such case I would feel that we are being more strict with this package
> than any other QA-maintained package).

Let me sleep another night on this unblock request (and give other RT
members a chance to chime in). But even if we go this way I don't see it
that we are more strict. razor got unlucky timing, but we're in a freeze
and you're asking for an exception. Every exception has it's own
argumentation and reasons.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#928992: priority-extra-is-replaced-by-priority-optional doesn't catch some packages

[s3v]

Thanks a lot for explaining Lintian's behavior.
I thought priority information come from package file...

I've opened another bug report for (hopefully) solving
this issue.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=929087

Thanks again for your work and yourtime.

Kind regards.



Il 14/05/19 22:24, Adam D. Barratt ha scritto:
> This is due to the fact that the priority fields in the packages files
> come from the archive's override lists, which may well not match the
> values present in the binary packages.
> 
> If you check the latter, you will find that they are expected and in
> line with Lintian's output:
> 
> adsb@coccia:~$ dpkg-deb -I 
> /srv/mirrors/debian/pool/main/a/allure/allure_0.8.3.0-3_amd64.deb | grep 
> Priority
>  Priority: optional
> adsb@coccia:~$ dpkg-deb -I 
> /srv/mirrors/debian/pool/main/b/binutils/binutils-i686-gnu_2.31.1-16_amd64.deb
>  | grep Priority
>  Priority: optional
> 
> Regards,
> 
> Adam
> 
> 

Bug#929087: Priority information in packages file is not reliable

[s3v]

Package: ftp.debian.org


Dear developer,
there is some divergence between priority information in Packages.xz file
and priority field in binary .deb file.

E.g.

(from Packages.xz)

Package: allure
Version: 0.8.3.0-3
Installed-Size: 36600
Maintainer: Debian Haskell Group 

[...]
Section: games
Priority: extra
^^^

(from binary package)

$ dpkg-deb -I allure_0.8.3.0-3_amd64.deb | grep Priority
Priority: optional
^^

(from Packages.xz)

Package: 4digits
Source: 4digits (1.1.4-1)
Version: 1.1.4-1+b1
Installed-Size: 679
Maintainer: Yongzhi Pan 
[...]
Section: games
Priority: optional
^^

(from binary package)

$ dpkg -I 4digits_1.1.4-1+b1_amd64.deb | grep Priority
Priority: extra
^^^

more context at #928992 [1].

I think content of Packages.xz file does need to be fully reliable because
this file is parsed by DDTP [2] for:
- obtaining the priority of Debian packages
- creating a numeric priority on a basis of "official" priority and some
  other internal criteria
- populating his database with this information
- automatically fetching package descriptions with highest priority
- providing these descriptions to translators

Currently, results presented at the end of this workflow are not what they
seem and translators spend their time to translate descriptions that do
actually have priority lower than what DDTP says.
Please, can you provide a Packages.xz file that rightly reflects the binary
package priority?

I hope this is the proper place for reporting this issue; if not, please
redirect me on the right way.
Moreover, I have no idea about the process that does build packages file, maybe
this behaviour is expected?
If so, please adjust the severity or close this bug as well.

Thanks a lot for your work.

Kind regards.


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928992
[2] http://ddtp2.debian.net/stats/stats-sid.html

Bug#929086: Say which package has the Invalid archive member

[積丹尼 Dan Jacobson]

Package: apt
Version: 1.8.1

Here it says Invalid archive member.

But it doesn't say what package has the Invalid archive member.

It says three packages have the Invalid archive member?

# aptitude ...
Do you want to continue? [Y/n/?]
E: Invalid archive member header 9Ls--[BINARY MESS --Dan]
E: Prior errors apply to /var/cache/apt/archives/gcc-9-base_9.1.0-2_amd64.deb
E: Prior errors apply to /var/cache/apt/archives/curl_7.64.0-3_amd64.deb
E: Prior errors apply to /var/cache/apt/archives/libcurl4_7.64.0-3_amd64.deb
debconf: apt-extracttemplates failed:
dpkg: warning: downgrading libobjc4:amd64 from 9.1.0-2 to 9-20190428-1
(Reading database ... 150517 files and directories currently installed.)
Preparing to unpack .../gcc-9-base_9.1.0-2_amd64.deb ...
Unpacking libobjc4:amd64 (9-20190428-1) over (9.1.0-2) ...
dpkg-deb (subprocess): decompressing archive member: lzma error: compressed 
data is corrupt
dpkg-deb: error:  subprocess returned error exit status 2
dpkg: error processing archive 
/var/cache/apt/archives/gcc-9-base_9.1.0-2_amd64.deb (--unpack):
 cannot copy extracted data for './usr/lib/x86_64-linux-gnu/libobjc.so.4.0.0' 
to '/usr/lib/x86_64-linux-gnu/libobjc.so.4.0.0.dpkg-new': unexpected end of 
file or stream
Errors were encountered while processing:
 /var/cache/apt/archives/gcc-9-base_9.1.0-2_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
dpkg: dependency problems prevent configuration of gcc-9:
 gcc-9 depends on gcc-9-base (= 9.1.0-2); however:
  Version of gcc-9-base:amd64 on system is 9.1.0-1

Bug#929085: thunar: Thunar and firefox crshe in the xorg, make it freeze the display.

[Rodrigo Lima de Souto Leandro]

Package: thunar
Version: 1.8.4-1
Severity: normal

Dear Maintainer,

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

   * What led up to the situation?
Open the app, thunar, firefox and others
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Only open the apps.
   * What was the outcome of this action?
Open the apps but I correct when Restart the lightdm or ctrl+alt+f2 and 
return for X with alt+f7 that the X show next display freeze.
   * What outcome did you expect instead?

My notebook is Acer Aspire A515-41G-1480 (AMD A12, Radeon RX 540 and memory 
DDR4)

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


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

Kernel: Linux 4.19.0-4-rt-amd64 (SMP w/4 CPU cores; PREEMPT)
Kernel taint flags: TAINT_WARN
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

Versions of packages thunar depends on:
ii  desktop-file-utils  0.23-4
ii  exo-utils   0.12.4-1
ii  libatk1.0-0 2.30.0-2
ii  libc6   2.28-10
ii  libcairo2   1.16.0-4
ii  libexo-2-0  0.12.4-1
ii  libgdk-pixbuf2.0-0  2.38.1+dfsg-1
ii  libglib2.0-02.58.3-1
ii  libgtk-3-0  3.24.5-1
ii  libgudev-1.0-0  232-2
ii  libice6 2:1.0.9-2
ii  libnotify4  0.7.7-4
ii  libpango-1.0-0  1.42.4-6
ii  libsm6  2:1.2.3-1
ii  libthunarx-3-0  1.8.4-1
ii  libxfce4ui-2-0  4.12.1-3
ii  libxfce4util7   4.12.1-3
ii  libxfconf-0-2   4.12.1-1
ii  shared-mime-info1.10-1
ii  thunar-data 1.8.4-1

Versions of packages thunar recommends:
ii  dbus-user-session [default-dbus-session-bus]  1.12.12-1
ii  dbus-x11 [dbus-session-bus]   1.12.12-1
ii  gvfs  1.38.1-3
ii  libcairo-gobject2 1.16.0-4
ii  libpangocairo-1.0-0   1.42.4-6
ii  libxfce4panel-2.0-4   4.12.2-1
ii  policykit-1-gnome [polkit-1-auth-agent]   0.105-7
ii  thunar-volman 0.9.1-1
ii  tumbler   0.2.3-1
ii  udisks2   2.8.1-4
ii  xdg-user-dirs 0.17-2

Versions of packages thunar suggests:
ii  thunar-archive-plugin 0.4.0-2
ii  thunar-media-tags-plugin  0.3.0-2

-- no debconf information

Bug#928977: patch

[Theodore Ts'o]

On Thu, May 16, 2019 at 02:47:06PM -0400, Theodore Ts'o wrote:
> Control: tags -1 +pending
> 
> On Thu, May 16, 2019 at 05:17:10PM +0200, Adam Borowski wrote:
> > Cron spam from a Priority:Required package is not something I'd consider
> > fit for Buster.  Thus, could you please apply this patch?
> 
> Thanks for the patch, applied!

Actually, looking at this more closely, I think this might be a better
way to address things, since I need to deal with both the systemd and
cron cases:

commit ec23e6820b64509a4640c61ec94febdd7efd2905
Author: Theodore Ts'o 
Date:   Thu May 16 14:56:37 2019 -0400

e2scrub: stop cron spam if lvm2 is not installed.

Addresses-Debian-Bug: #928977

Signed-off-by: Theodore Ts'o 

diff --git a/scrub/e2scrub_all.cron.in b/scrub/e2scrub_all.cron.in
index 7d42c3f2e..5bf83ec97 100644
--- a/scrub/e2scrub_all.cron.in
+++ b/scrub/e2scrub_all.cron.in
@@ -1,2 +1,2 @@
 30 3 * * 0 root test -e /run/systemd/system || @pkglibdir@/e2scrub_all_cron
-10 3 * * * root test -e /run/systemd/system || @root_sbindir@/e2scrub_all -A -r
+10 3 * * * root test -e /run/systemd/system || @root_sbindir@/e2scrub_all -C 
-A -r
diff --git a/scrub/e2scrub_all.in b/scrub/e2scrub_all.in
index 31ebc7970..eb7b55bee 100644
--- a/scrub/e2scrub_all.in
+++ b/scrub/e2scrub_all.in
@@ -26,6 +26,7 @@ if (( $EUID != 0 )); then
 fi
 
 scrub_all=0
+run_from_cron=0
 snap_size_mb=256
 reap=0
 conffile="@root_sysconfdir@/e2scrub.conf"
@@ -73,6 +74,7 @@ while getopts "nrAV" opt; do
"n") DBG="echo Would execute: " ;;
"r") scrub_args="${scrub_args} -r"; reap=1;;
"A") scrub_all=1;;
+   "C") run_from_cron=1;
"V") print_version; exitcode 0;;
*) print_help; exitcode 2;;
esac
@@ -84,13 +86,19 @@ shift "$((OPTIND - 1))"
 # when e2scrub_all is run out of cron or a systemd timer.
 
 if ! type lsblk >& /dev/null ; then
+if [ "${run_from_cron}" -eq 1 ] ; then
+   exitcode 0
+fi
 echo "e2scrub_all: can't find lsblk --- is util-linux installed?"
-exitcode 0
+exitcode 1
 fi
 
 if ! type lvcreate >& /dev/null ; then
+if [ "${run_from_cron}" -eq 1 ] ; then
+   exitcode 0
+fi
 echo "e2scrub_all: can't find lvcreate --- is lvm2 installed?"
-exitcode 0
+exitcode 1
 fi
 
 # Find scrub targets, make sure we only do this once.
diff --git a/scrub/e2scrub_all.service.in b/scrub/e2scrub_all.service.in
index 20f42bfe3..77b6ad599 100644
--- a/scrub/e2scrub_all.service.in
+++ b/scrub/e2scrub_all.service.in
@@ -8,5 +8,5 @@ Documentation=man:e2scrub_all(8)
 [Service]
 Type=oneshot
 Environment=SERVICE_MODE=1
-ExecStart=@root_sbindir@/e2scrub_all
+ExecStart=@root_sbindir@/e2scrub_all -C
 SyslogIdentifier=e2scrub_all
diff --git a/scrub/e2scrub_all_cron.in b/scrub/e2scrub_all_cron.in
index f9cff878c..bc26fee3d 100644
--- a/scrub/e2scrub_all_cron.in
+++ b/scrub/e2scrub_all_cron.in
@@ -65,4 +65,4 @@ on_ac_power() {
 test -e /run/systemd/system && exit 0
 on_ac_power || exit 0
 
-exec @root_sbindir@/e2scrub_all
+exec @root_sbindir@/e2scrub_all -C
diff --git a/scrub/e2scrub_reap.service.in b/scrub/e2scrub_reap.service.in
index cf26437cd..40511f735 100644
--- a/scrub/e2scrub_reap.service.in
+++ b/scrub/e2scrub_reap.service.in
@@ -16,7 +16,7 @@ NoNewPrivileges=yes
 User=root
 IOSchedulingClass=idle
 CPUSchedulingPolicy=idle
-ExecStart=@root_sbindir@/e2scrub_all -A -r
+ExecStart=@root_sbindir@/e2scrub_all -C -A -r
 SyslogIdentifier=%N
 RemainAfterExit=no
 

Bug#891931: Info received ()

[Georgina B Solari]

https://www.google.com/search?q=No%20ninguno%20provando=es

El jue., 16 de may. de 2019 2:12 p. m., Debian Bug Tracking System <
ow...@bugs.debian.org> escribió:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian GnuPG Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 891...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 891931: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891931
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#891931:

[Georgina B Solari]

Bug#891931: Info received (Bug#891931: Info received (Tls))

[Georgina B Solari]

Graciad

El jue., 16 de may. de 2019 10:03 a. m., Debian Bug Tracking System <
ow...@bugs.debian.org> escribió:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian GnuPG Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 891...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 891931: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891931
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#891931: Info received (Bug#891931: Info received (Tls))

[Georgina B Solari]

El jue., 16 de may. de 2019 10:03 a. m., Debian Bug Tracking System <
ow...@bugs.debian.org> escribió:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian GnuPG Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 891...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 891931: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891931
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#928977: patch

[Theodore Ts'o]

Control: tags -1 +pending

On Thu, May 16, 2019 at 05:17:10PM +0200, Adam Borowski wrote:
> Cron spam from a Priority:Required package is not something I'd consider
> fit for Buster.  Thus, could you please apply this patch?

Thanks for the patch, applied!

- Ted

Bug#929082: unblock: razor/1:2.85-4.2

[Santiago Vila]

On Thu, May 16, 2019 at 07:43:09PM +0200, Paul Gevers wrote:

> The reason why it got removed, is that nobody was looking after razor.
> Otherwise, preventing removal would have been easy.

Indeed. If I had known that it was going to be removed, I would have
downgraded the severity of the bug before the autoremoval happened.

> > I'm filing this only as a DD and long-time user of razor because the
> > package is currently orphaned (#866833). IMO dropping razor from
> > buster does not really help our users.
> 
> So my concern here is the lack of maintainers. Who will step up to
> maintain razor?

I don't know. It's currently orphaned, so someone will pick it
sooner or later, as it happens with every other orphaned package.

In my opinion, the software is useful "as is" even if the last
maintainer is not active anymore.

We have a lot of packages maintained by "Debian QA" and we don't
remove them from Debian just because they don't have a proper
maintainer. We just keep them because they are useful.

So, if it helps, I would be willing to make an upload to officially
orphan it (using "Debian QA" as the Maintainer field) to be on par
with every other QA-maintained package. Personally, I don't think it
would change things a lot but if it's the difference between keeping
razor in or out of buster, I will be happy to make an upload for that.

(And if that's not enough, I would even be willing to put my name in
the maintainer field, only until we find another maintainer, but in
such case I would feel that we are being more strict with this package
than any other QA-maintained package).

Thanks.

Bug#926009: Re bug 926009: java.vendor change breaks applications checking java.vendor (like LibreOffice)

[Paul Gevers]

Hi doko,

On 09-05-2019 09:46, Paul Gevers wrote:
>> On 02.05.19 10:30, Julien Cristau wrote:
>>> From what I understand bug#926009 is a regression in that version.
>>> There's no explanation that I can see for that change, no associated
>>> bug, and it doesn't look appropriate.  Please revert it.
>>
>> No. The issue is in the LibreOffice package, which already has this fixed in
>> testing. The openjdk package also has an appropriate Breaks.
> 
> We are aware that LO is fixed for this change. What we are still missing
> is the rationale for why this is needed. We fear that this may break
> more things than LO, especially things outside of Debian control. Please
> help us understand why you think this is important and why you don't
> want to revert it.

Any comment, please?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#908451: Patch

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 patch

Just for the record: I've been able to solve it with the attached patch.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
--- multistrap	2018-11-21 11:00:46.0 -0300
+++ multistrap_mod	2019-05-16 15:11:44.15764 -0300
@@ -320,7 +320,8 @@
 $config_str .= " -o Apt::Get::AllowUnauthenticated=true"
 	if (defined $noauth);
 $config_str .= " -o Apt::Get::Download-Only=true";
-$config_str .= " -o Apt::Install-Recommends=false"
+$config_str .= " -o Apt::Install-Recommends=false";
+$config_str .= " -o Acquire::AllowInsecureRepositories=yes"
 	if (not defined $allow_recommends);
 $config_str .= " -o Dir=" . shellescape($dir);
 $config_str .= " -o Dir::Etc=" . shellescape("${dir}${etcdir}");

Bug#913978: Maybe at least document those keystrokes?

[Paul Gevers]

Control: clone -1 -2
Control: reassign -2 release-notes
Control: retitle -2 document g-c-c a11y workaround
Control: severity -2 normal

On Sat, 27 Apr 2019 13:16:05 -0700 Tassia Camoes Araujo
 wrote:
> From what I could understand, it is unlikely this will be fixed before
> Buster release. So how should we proceed about his bug?
> Even if a backport can possibly be provided later, would it be possible
> to just document the keystrokes "workaround" mentioned by Jeremy Bicha
> in the package shipped with Buster?
> It might be a big difference for users in need of this accessibility
> feature.

Although I rather have the bug fixed (who doesn't) I think documenting
is the least that can be done. @a11y team, anybody willing to update the
Wiki? I'll make sure the release notes have something.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#928770: sqlite3: CVE-2019-5018: Window Function Remote Code Execution Vulnerability

[GCS]

Hi,

On Thu, May 16, 2019 at 11:57 AM Pirate Praveen
 wrote:
> On Fri, 10 May 2019 21:04:33 +0200 Salvatore Bonaccorso
>  wrote:
> > Source: sqlite3
> > The following vulnerability was published for sqlite3.
> > CVE-2019-5018[0]:
> > Window Function Remote Code Execution Vulnerability
> Could this be that commit? I have not checked thoroughly only looked at
> the commit message.
>
> "Prevent aliases of window functions expressions from being used as
> arguments to aggregate or other window functions."
>
> https://sqlite.org/src/info/1e16d3e8fc60d39c
 Can be, but not sure. At least four sqlite 3.x issues reported
recently and as I know, usually upstream is not informed about these.
:-/

> > [1] https://www.talosintelligence.com/vulnerability_reports/TALOS-2019-0777

Regards,
Laszlo/GCS

Bug#924548: bug 924548: gnome-core: does not actually install a desktop environment on s390x

[Paul Gevers]

Hi Simon, all,

On Thu, 14 Mar 2019 10:29:06 + Simon McVittie  wrote:
> I recently changed gnome-core to install gnome-flashback instead of
> GNOME Shell on s390x, because: GNOME Shell is uninstallable on s390x, due
> to mozjs60 not being functional there; testing migration requires task
> packages to be installable; and the release team were not willing to waive
> that requirement for s390x, because d-i maintainers were concerned that
> d-i might do the wrong thing if asked to install an uninstallable task.

mozjs60 has been fixed (and uploaded by you to unstable), if I am
correct to actually enable this bug to be fixed. What is the status of
this bug?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#927567: Delays

[Sharon Dvir]

I was too optimistic regarding how much time I have.
This package might take me a while to complete.
If needed, feel free to close it and I will only reopen once I have
uploaded a package.
Apologies.

Bug#871401: bug 871401: debian-i18n: russian-spanish cant change in display manager

[Paul Gevers]

Control: severity -1 important
Control: reassign -1 gdm3
Control: retitle -1 gdm3: doesn't offer all languages on the system
Control: found -1 3.14.1-7

Hi PICCORO,

On Mon, 7 Aug 2017 13:24:17 -0400 PICCORO McKAY Lenz
 wrote:
> Package: debian-i18n

I seriously doubt that this is the right (pseudo) package for your
problem. It is probably the reason it didn't get the attention it
deserves. I'll reassign it to gdm3, I hope it is still valuable.

> Severity: grave

You haven't convinced me it is grave, I am lowering the severity for now.

> Tags: l10n
> Justification: causes non-serious data loss

I don't see any data loss.

> Dear Maintainer,
> 
> Install debian in spanish and added optionally russian and english as
> alternate languajes..
> When try to access in GDM3 login screen, only Spanish and english are 
> available
> NOTE: all the es_XX, ru_XX and en_XX locales where are generated correctly
> 
> I Regenerate all the locales again, and remove the stupid gnome-puach dm
> install the lightdm (due now debians only offerts nothing about
> display managers)
> then now russian are available in languaje choices
> but are not saved for specific users as defaul languje
> and if does not choose for fist time, next time are not set correctly
> 
> In resume:
> 
> 1) the stupid GDM3 does not offer russian languaje option if spanish are 
> default

If you want people to look at your problems, please refrain from using
this kind of language. You may need the help of people that care a lot
about the package in question and this isn't going to do your cause any
good.

> 2) lightdm offers russian laguaje option but are not saved for users
> that choose it
> 3) if user forgot to use russian, when logout and choose it, no
> russian are showed
> 4) if spanish are default or english, missing russian entries are in desktop
> 5) only gonmepuach desktop use complete russian translations, Xfce4
> and LXDE does not .
> 6) russian translations appears only when are set by default, and then
> spanish are missing
> 
> 
> -- System Information:
> Debian Release: 8.5
>   APT prefers oldstable-updates
>   APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
> Architecture: i386 (i686)
> 
> Kernel: Linux 3.16.0-4-586
> Locale: LANG=es_VE.UTF-8, LC_CTYPE=es_VE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)




signature.asc
Description: OpenPGP digital signature

Bug#929083: unblock: live-tasks/0.7

[jonathan]

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

Please consider unblocking live-tasks (0.7).

This upload adds ibus-m17n to the live images, adding support for entering
Indian language characters (Closes RC bug #866391).

thanks,

-Jonathan

Bug#929082: unblock: razor/1:2.85-4.2

[Paul Gevers]

Control: tags -1 moreinfo

Hi Santiago,

On 16-05-2019 17:52, Santiago Vila wrote:
> Please allow razor back in testing, as a freeze exception.

razor was already on my radar, and I already have considered an exception.

> It was autoremoved because there was a RC bug in the BTS, but the
> real problem was not in the package itself but in the razor servers
> by cloudmark (for which the razor package acts as a client).
> 
> The problem is already solved. Details about this in Bug #924583.

The reason why it got removed, is that nobody was looking after razor.
Otherwise, preventing removal would have been easy.

> I'm filing this only as a DD and long-time user of razor because the
> package is currently orphaned (#866833). IMO dropping razor from
> buster does not really help our users.

So my concern here is the lack of maintainers. Who will step up to
maintain razor?

Paul



signature.asc
Description: OpenPGP digital signature

Bug#929013: closed by Mattia Rizzolo (Bug#929013 fixed in jenkins.debian.org)

[Bastian Blank]

Hi Mattia

On Thu, May 16, 2019 at 09:50:50AM +0200, Mattia Rizzolo wrote:
> On Wed, May 15, 2019 at 08:51:14PM +0200, Bastian Blank wrote:
> > Please add the word "Bot" in it and add contact information.
> I can do that, but could you please explain why you find the word "Bot"
> so important?

It should trigger the automatic process detection of our log checker.
"Bot" is one of the trigger words.

Bastian

-- 
The best diplomat I know is a fully activated phaser bank.
-- Scotty

Bug#929042: singularity-container: CVE-2019-11328)

[Afif Elghraoui]

On May 15, 2019 5:13:24 PM EDT, Salvatore Bonaccorso  wrote:
>Hi Afif,
>
>On Wed, May 15, 2019 at 10:57:49PM +0200, Salvatore Bonaccorso wrote:
>> Then there is nothing further to be done.
>
>Oh, actually there is an open point: Is it confirmed that 3.0.3 is not
>affected by the CVE? Did you got any information why this is only
>introduced in 3.1.0?
>

Ok, I asked upstream and the answer is that the commit that introduced the bug 
came after 3.0.3.

regards
Afif

Bug#927142: Sieve/calendar problem solved

[Xavier]

Hi all,

Cyrus-info mailing list give us the answer : "addresses" parameter in
vacation scripts is mandatory to make cyrus to react and sends
notifications back.

We checked that and yes it works.

So there is no issue with vacation and sieve scripts pass the upgrade.

Cheers,
Xavier

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Michael Biebl]

Am 16.05.19 um 18:17 schrieb Vincent Lefevre:
> On 2019-05-16 17:52:03 +0200, Michael Biebl wrote:
>> I would suggest the following: If there is a local nameserver but no
>> network connectivity, query the local nameserver only.
> 
> OK, I can do that. Indeed, the default behavior of "host" is to try
> every server in /etc/resolv.conf until it succeeds. I suppose that
> the solution would be to use this option:
> 
>   -s
>   Do not send the query to the next nameserver if any server responds
>   with a SERVFAIL response, which is the reverse of normal stub
>   resolver behavior.

If the remote server would be ordered first in resolv.conf, I assume
this would still block? I assume you are making the assumption here that
the local server will always be listed first? Is that a safe assumption?

> I have another question: in
> 
>   if ! $(egrep -q "nameserver 127.0.0.1|::1" /etc/resolv.conf); then 
> 
> why testing 127.0.0.1 only, and not all local nameservers?
> For instance, 127.0.1.1 is used by NetworkManager:
> 
> https://askubuntu.com/questions/627899/nameserver-127-0-1-1-in-resolv-conf-wont-go-away
> 
> Also, the regexp should be something like "^ *nameserver +(127.0.0.1|::1)"
> or "^ *nameserver +(127\.|::1)", i.e.
>   * one should make sure that it is a nameserver line (in particular,
> not a comment);
>   * several space characters should match;
>   * one should make sure that ::1 is preceded by "nameserver"
> (the parentheses are missing).

Good question. I don't know why the script only checks for 127.0.0.1 and
not 127.0.1.1

Sjoerd, looking through the history of the package, it seems you are
most likely to be able to answer that.


-- 
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#929077: linux-image-4.19.0-4-amd64: cannot successfully resume from hibernate with nouveau driver unless I pass 'nomodeset'

[Chris Danis]

Oh, and, for clarity: this did not happen before installing the non-free
nouveau firmware.

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Vincent Lefevre]

On 2019-05-16 17:52:03 +0200, Michael Biebl wrote:
> I would suggest the following: If there is a local nameserver but no
> network connectivity, query the local nameserver only.

OK, I can do that. Indeed, the default behavior of "host" is to try
every server in /etc/resolv.conf until it succeeds. I suppose that
the solution would be to use this option:

  -s
  Do not send the query to the next nameserver if any server responds
  with a SERVFAIL response, which is the reverse of normal stub
  resolver behavior.

I have another question: in

  if ! $(egrep -q "nameserver 127.0.0.1|::1" /etc/resolv.conf); then 

why testing 127.0.0.1 only, and not all local nameservers?
For instance, 127.0.1.1 is used by NetworkManager:

https://askubuntu.com/questions/627899/nameserver-127-0-1-1-in-resolv-conf-wont-go-away

Also, the regexp should be something like "^ *nameserver +(127.0.0.1|::1)"
or "^ *nameserver +(127\.|::1)", i.e.
  * one should make sure that it is a nameserver line (in particular,
not a comment);
  * several space characters should match;
  * one should make sure that ::1 is preceded by "nameserver"
(the parentheses are missing).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Michael Biebl]

Am 16.05.19 um 17:44 schrieb Vincent Lefevre:
> On 2019-05-16 16:54:26 +0200, Michael Biebl wrote:
>> I'm happy to review a tested patch, which considers your specific use case.
> 
> Would one of the following behaviors be OK?
> 
> 1. If there is no default route, then assume that we can't reach any
> nameservers (there's potentially a local nameserver, but I don't think
> it would be any use here).
> 
> 2. If (1) alone is not OK for some reason, do (1) only if there's
> at least a non-local nameserver in /etc/resolv.conf (this could be
> regarded as some compromise).
> 
> If one of them is OK, I can provide a patch.
> 

I would suggest the following: If there is a local nameserver but no
network connectivity, query the local nameserver only.

-- 
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#929082: unblock: razor/1:2.85-4.2

[Santiago Vila]

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

Please allow razor back in testing, as a freeze exception.

It was autoremoved because there was a RC bug in the BTS, but the
real problem was not in the package itself but in the razor servers
by cloudmark (for which the razor package acts as a client).

The problem is already solved. Details about this in Bug #924583.

I'm filing this only as a DD and long-time user of razor because the
package is currently orphaned (#866833). IMO dropping razor from
buster does not really help our users.

(No debdiff to attach because the problem was solved in the razor
servers, not in the razor package).

Thanks.

Bug#929081: Sosreport installs without compiling the .py files

[Thomas Goirand]

Package: sosreport
Version: 3.6-1
Severity: important

Hi,

Could you please add this to your packaging:

override_dh_python3:
dh_python3 /usr

otherwise, the python files aren't being built.

Cheers,

Thomas Goirand (zigo)

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Vincent Lefevre]

On 2019-05-16 16:54:26 +0200, Michael Biebl wrote:
> I'm happy to review a tested patch, which considers your specific use case.

Would one of the following behaviors be OK?

1. If there is no default route, then assume that we can't reach any
nameservers (there's potentially a local nameserver, but I don't think
it would be any use here).

2. If (1) alone is not OK for some reason, do (1) only if there's
at least a non-local nameserver in /etc/resolv.conf (this could be
regarded as some compromise).

If one of them is OK, I can provide a patch.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#929065: php-parser: autopkgtest failure in experimental: must be compatible with PHPUnit\Framework\TestCase::setUp()

[David Prévot]

Hi Paul,

Le 15/05/2019 à 23:39, Paul Gevers a écrit :

> This is a heads up in case all php* uploads in experimental go to
> unstable after the release of buster.

Thanks, but…

> […] the failure I tested is with phpunit from experimental.

It’s already known that very few packages are PHPUnit 8 compatible yet,
please refrain from mass bug filing (in case you are testing every
package the same way ;).

Regards

David



signature.asc
Description: OpenPGP digital signature

Bug#928977: patch

[Adam Borowski]

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

Hi!
Cron spam from a Priority:Required package is not something I'd consider
fit for Buster.  Thus, could you please apply this patch?


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!
>From ebe01be7ccb62c2c76f4036d103c77c82eecd166 Mon Sep 17 00:00:00 2001
From: Adam Borowski 
Date: Thu, 16 May 2019 17:10:35 +0200
Subject: [PATCH] Stop cron spam if lvm2 is not installed.

Signed-off-by: Adam Borowski 
---
 scrub/e2scrub_all.cron.in | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/scrub/e2scrub_all.cron.in b/scrub/e2scrub_all.cron.in
index 7d42c3f2..e0e5addc 100644
--- a/scrub/e2scrub_all.cron.in
+++ b/scrub/e2scrub_all.cron.in
@@ -1,2 +1,2 @@
-30 3 * * 0 root test -e /run/systemd/system || @pkglibdir@/e2scrub_all_cron
-10 3 * * * root test -e /run/systemd/system || @root_sbindir@/e2scrub_all -A -r
+30 3 * * 0 root test -e /run/systemd/system || test ! -x /sbin/lvcreate || @pkglibdir@/e2scrub_all_cron
+10 3 * * * root test -e /run/systemd/system || test ! -x /sbin/lvcreate || @root_sbindir@/e2scrub_all -A -r
-- 
2.20.1

Bug#929014: Stop polling salsa.d.o

[Mattia Rizzolo]

On Wed, May 15, 2019 at 08:48:32PM +0200, Bastian Blank wrote:
> I see from 46.16.76.207 every minute git-upload-pack, aka fetch, for:
> - https://salsa.debian.org/perl-team/modules/packages/debsums.git
> - https://salsa.debian.org/release-team/debian-archive-keyring.git

lowered the level of polling, will work on getting pushes on these (it
was meant to be "every half hour" but instead was on "every half
minute", now it's "every 2 hours" instead…)

> Every six minutes for:
> - https://salsa.debian.org/haskell-team/package-plan.git

webhook set up.

> Some are erratic, but not synchronized with repo activity:
> - https://salsa.debian.org/helmutg/rebootstrap.git

This is already set up to do so, the jobs are set to poll only once per
day as a backup the push is missed, nothing more.  just there are many
jobs slowly chrunching hitting that repository.  how many hits are we
talking about here?  I suppose if they are really that many that you
noticed them we should look into this further, but please share some
numbers first.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#891931: Info received (Tls)

[Georgina B Solari]

No puedo mandar nada con Tls hay gente re Google que we gente para
Darla Los codigos a mi expose para mandate spam y boy Google search
Busch una cosa y me sale otta my different tienen 4 anos haciendo dank
a mi reputation y sicologicamente. Ok pair que la policies of free a
esta pedazo we missed we expose controls for y biracho. No an replace
me quisieron aceptar. Porque com am so hablar singles moments but
none. La Encarta am luego y a poster imagines our no ha dicho conmigo
ok pair que despues we 20 ando apenas have 4 me to cuenta y todos me
Felton la replace. Nadie me ayuda

2019-05-16 4:45 GMT-05:00, Debian Bug Tracking System :
> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian GnuPG Maintainers 
>
> If you wish to submit further information on this problem, please
> send it to 891...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 891931: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891931
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#928170: chrony: Apparmor profile contains wrong path for samba sntp

[L. van Belle]

Hai Vincent, 

Yes, that is correct. 

/var/lib/samba/ntp_signd/socket rw,

Is sufficient. 

Greetz, 

Louis


> -Oorspronkelijk bericht-
> Van: Vincent Blut [mailto:vincent.deb...@free.fr] 
> Verzonden: dinsdag 14 mei 2019 15:54
> Aan: Louis van Belle; 928...@bugs.debian.org
> CC: Debian Bug Tracking System
> Onderwerp: Re: Bug#928170: chrony: Apparmor profile contains 
> wrong path for samba sntp
> 
> Hi Louis,
> 
> So According to the information gleaned in #928168¹, adding a rule to 
> allow read access to winbindd pipe doesn’t seem necessary‽
> As far as I can see from my local tests, only read/write access to 
> /var/lib/samba/ntp_signd/socket is needed. Could you please confirm?
> 
> If so, chronyd’s Apparmor profile should just include (for samba ofc):
> /var/lib/samba/ntp_signd/socket rw,
> 
> Cheers,
> Vincent
> 
> 
> ¹ https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928168
> 

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Michael Biebl]

Am 16.05.19 um 16:37 schrieb Vincent Lefevre:
> On 2019-05-16 16:25:01 +0200, Michael Biebl wrote:
>> What happens, if you only list your local 127.0.0.1 in /etc/resolv.conf?
> 
> See my other mail, i.e. no problems. FYI, I use 192.168.1.1 just
> as a fallback.
> 
>> Well, the assumption that /usr/lib/avahi/avahi-daemon-check-dns.sh makes
>> is, that if a local resolver is configured in /etc/resolv.conf, then it
>> is safe to assume that host lookup can be done, even if there is not
>> default route (== network access).
> 
> This assumption is not correct. One can use a local resolver for
> plenty of reasons.

Sure. The problem is, that you list a fallback server which is not
reachable.

> If you assume that this is safe because the local resolver will
> not hang with a timeout (which is the case with unbound), then
> you should make sure that *only* the local resolver will be used.
> 

Well, if you list a non-reachable server in resolv.conf as fallback,
then the behaviour you see is expected.

I'm happy to review a tested patch, which considers your specific use case.

-- 
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#929010: [Pkg-utopia-maintainers] Bug#929010: Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Vincent Lefevre]

On 2019-05-16 16:25:01 +0200, Michael Biebl wrote:
> What happens, if you only list your local 127.0.0.1 in /etc/resolv.conf?

See my other mail, i.e. no problems. FYI, I use 192.168.1.1 just
as a fallback.

> Well, the assumption that /usr/lib/avahi/avahi-daemon-check-dns.sh makes
> is, that if a local resolver is configured in /etc/resolv.conf, then it
> is safe to assume that host lookup can be done, even if there is not
> default route (== network access).

This assumption is not correct. One can use a local resolver for
plenty of reasons.

If you assume that this is safe because the local resolver will
not hang with a timeout (which is the case with unbound), then
you should make sure that *only* the local resolver will be used.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#929055: virtualbox-source: Build failed due to dh_clean -k with dh compat 12

[YOSHINO Yoshihito]

Package: virtualbox-source
Version: 6.0.8-dfsg-2
Followup-For: Bug #929055
Control: tags -1 + patch

Dear Maintainer,

The attached patch replaces `dh_clean -k' with `dh_prep', which should
fix this problem.

Thanks in advance,

-- 
YOSHINO Yoshihito 

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

Kernel: Linux 4.19.0-5-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8),
LANGUAGE=ja_JP.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages virtualbox-source depends on:
ii  build-essential   12.6
ii  bzip2 1.0.6-9
pn  debhelper-compat  
ii  kbuild1:0.1.9998svn3293+dfsg-2
ii  module-assistant  0.11.10

Versions of packages virtualbox-source recommends:
ii  virtualbox  6.0.8-dfsg-2

virtualbox-source suggests no packages.

-- no debconf information
diff -Nru virtualbox-6.0.8-dfsg/debian/virtualbox-guest-source.files/rules virtualbox-6.0.8-dfsg/debian/virtualbox-guest-source.files/rules
--- virtualbox-6.0.8-dfsg/debian/virtualbox-guest-source.files/rules	2019-01-16 19:27:20.0 +0900
+++ virtualbox-6.0.8-dfsg/debian/virtualbox-guest-source.files/rules	2019-05-16 21:22:11.0 +0900
@@ -48,7 +48,7 @@
 
 binary-modules: prep-deb-files
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	# Build the modules
 	$(MAKE) -C $(KSRC) M=$(CURDIR)
 	# Install the modules
@@ -65,6 +65,6 @@
 	dh_gencontrol -- -v$(VERSION)
 	dh_md5sums
 	dh_builddeb --destdir=$(DEB_DESTDIR)
-	dh_clean -k
+	dh_prep
 
 .PHONY: build clean binary-arch binary-indep binary install binary-modules kdist kdist_configure kdist_image kdist_clean
diff -Nru virtualbox-6.0.8-dfsg/debian/virtualbox-source.files/rules virtualbox-6.0.8-dfsg/debian/virtualbox-source.files/rules
--- virtualbox-6.0.8-dfsg/debian/virtualbox-source.files/rules	2019-01-16 19:27:20.0 +0900
+++ virtualbox-6.0.8-dfsg/debian/virtualbox-source.files/rules	2019-05-16 21:21:50.0 +0900
@@ -56,7 +56,7 @@
 
 binary-modules: prep-deb-files
 	dh_testroot
-	dh_clean -k
+	dh_prep
 	# Build the module
 	$(MAKE) -C $(KSRC) M=$(CURDIR)
 	# Install the module
@@ -74,6 +74,6 @@
 	dh_gencontrol -- -v$(VERSION)
 	dh_md5sums
 	dh_builddeb --destdir=$(DEB_DESTDIR)
-	dh_clean -k
+	dh_prep
 
 .PHONY: build clean binary-arch binary-indep binary install binary-modules kdist kdist_configure kdist_image kdist_clean

Bug#867822: /usr/bin/pdebuild: Re: pbuilder: pdebuild cannot build source-only packages

[James Clarke]

Control: retitle -1 pbuilder: Breaks with --debbuildopts -S
Control: tags -1 wontfix

On 16 May 2019, at 15:18, Ritesh Raj Sarraf  wrote:
> 
> Package: pbuilder
> Version: 0.230.4
> Followup-For: Bug #867822
> 
> I have run into the same problem and would appreciate if this issue was
> resolved. For one, there's always a (good) reason for people to be doing
> source-only uploads. There are many Debian derivaties.
> 
> Secondly, there's a large number of packages I'd love to see only be
> uploaded through source-only uploads. Especially the ones like node-*,
> and the Java ones.
> 
> Third, like many others have said, for many packages it is a complete
> waste of resources. For example, I had the same problem when maintaining
> Virtualbox. And, as you see below, the same problem with my current
> package: user-mode-linux
> 
> And then, in DBug #928924, you could see another good reason why some
> want source only uploads.
> 
> So please, it'd really help a good many DDs, who have reasons to prefer
> source-only uploads.

Please read the entire thread, in particular [1]. If you want to do a
source-only upload without building binaries at the same time, just use
`dpkg-buildpackage -S`. I really don't think `pdebuild --debbuildopts -S` is a
useful thing to be doing; it's a waste of time with added complexity. We
support source-only uploads using pdebuild/pbuilder with --source-only-changes,
so please do not erroneously assert that we do not support source-only uploads.
We do. But using a chroot to just build a source package is, in my opinion,
pointless (unless using something like --use-pdebuild-internal, but that's
fairly obscure and not so well maintained).

Regards,
James

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

Bug#928924: user-mode-linux: xterm functionality broken due to wrong path to port-helper

[Ritesh Raj Sarraf]

On Tue, 2019-05-14 at 21:00 +0800, Paul Wise wrote:
> BTW, is it possible to do source-only uploads so that the build logs
> are available on amd64, or do the versioned binaries mean no logs? If
> so I think it would be good to only upload i386 binary packages so
> that
> we get the build logs for the most used architecture.

I will keep this in mind for the next upload. Meanwhile, what is the
best way to request a rebuild of the package ?


-- 
Given the large number of mailing lists I follow, I request you to CC
me in replies for quicker response


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

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Vincent Lefevre]

On 2019-05-16 16:09:04 +0200, Vincent Lefevre wrote:
> On 2019-05-16 15:59:09 +0200, Vincent Lefevre wrote:
> > On 2019-05-16 14:41:44 +0200, Michael Biebl wrote:
> > > Am 16.05.19 um 14:22 schrieb Vincent Lefevre:
> > > > On 2019-05-16 14:15:37 +0200, Michael Biebl wrote:
> > > >> Looks like you have a local resolver configured in /etc/resolv.conf
> > > >> (which should be reachable via lo, even if eth0 is down).
> > > > 
> > > > Yes, /etc/resolv.conf contains
> > > > 
> > > > nameserver 127.0.0.1
> > > > nameserver 192.168.1.1
> > > > 
> > > > as I use "unbound".
> > > 
> > > So host talks to unbound, which apparently takes those 12s to answer.
> > > Not sure what can be done about this in avahi-daemon. Ideas?
> > 
> > Should this be regarded as a bug in unbound, then?
> 
> Actually, no, unbound is not the problem:
> 
> Whether I have
> 
> nameserver 127.0.0.1
> nameserver 192.168.1.1
> 
> or just
> 
> nameserver 192.168.1.1
> 
> in /etc/resolv.conf, "time host -t soa local." shows a 10-second
> timeout.
> 
> Or would the old /etc/resolv.conf (with 127.0.0.1) be cached somewhere
> on the system?

According to strace (see attached output), even though /etc/resolv.conf
is read, there is a connection to 127.0.0.1, though this may not be
related. But... unbound is still not the issue. The strace output shows
that it is not 127.0.0.1 (unbound) that times out, but 192.168.1.1.

And indeed, with only

nameserver 127.0.0.1

in /etc/resolv.conf, "host -t soa local." immediately gives

Host local not found: 2(SERVFAIL)

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


str1.out.xz
Description: Binary data

Bug#929080: lvm2: lvm2-lvmetad.service is left running on upgrade

[Mattia Rizzolo]

Package: lvm2
Version: 2.03.02-2
Severity: serious

Hi,

today I upgraded a host from stretch to buster, and I noticed that lvm2
dropped the lvm2-lvmetad.service service.

However, after the upgrade `needsrestart` kept complaining that it could
restart that service that is left running, it completely removed the
files and the service and everything, but nothing stops the actual
process.

Of course a subsequent restart of the whole host would take care of
this, but I am of the opionion that the deamon should^Wmust be properly
stopped on package upgrade.

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Michael Biebl]

Am 16.05.19 um 16:09 schrieb Vincent Lefevre:
> On 2019-05-16 15:59:09 +0200, Vincent Lefevre wrote:
>> On 2019-05-16 14:41:44 +0200, Michael Biebl wrote:
>>> Am 16.05.19 um 14:22 schrieb Vincent Lefevre:
 On 2019-05-16 14:15:37 +0200, Michael Biebl wrote:
> Looks like you have a local resolver configured in /etc/resolv.conf
> (which should be reachable via lo, even if eth0 is down).

 Yes, /etc/resolv.conf contains

 nameserver 127.0.0.1
 nameserver 192.168.1.1

 as I use "unbound".
>>>
>>> So host talks to unbound, which apparently takes those 12s to answer.
>>> Not sure what can be done about this in avahi-daemon. Ideas?
>>
>> Should this be regarded as a bug in unbound, then?
> 
> Actually, no, unbound is not the problem:
> 
> Whether I have
> 
> nameserver 127.0.0.1
> nameserver 192.168.1.1
> 
> or just
> 
> nameserver 192.168.1.1
> 
> in /etc/resolv.conf, "time host -t soa local." shows a 10-second
> timeout.

If you don't have network access, then this is expected, I'd say.

What happens, if you only list your local 127.0.0.1 in /etc/resolv.conf?

> Or would the old /etc/resolv.conf (with 127.0.0.1) be cached somewhere
> on the system?
> 

Well, the assumption that /usr/lib/avahi/avahi-daemon-check-dns.sh makes
is, that if a local resolver is configured in /etc/resolv.conf, then it
is safe to assume that host lookup can be done, even if there is not
default route (== network access).




-- 
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#867822: /usr/bin/pdebuild: Re: pbuilder: pdebuild cannot build source-only packages

[Ritesh Raj Sarraf]

Package: pbuilder
Version: 0.230.4
Followup-For: Bug #867822

I have run into the same problem and would appreciate if this issue was
resolved. For one, there's always a (good) reason for people to be doing
source-only uploads. There are many Debian derivaties.

Secondly, there's a large number of packages I'd love to see only be
uploaded through source-only uploads. Especially the ones like node-*,
and the Java ones.

Third, like many others have said, for many packages it is a complete
waste of resources. For example, I had the same problem when maintaining
Virtualbox. And, as you see below, the same problem with my current
package: user-mode-linux

And then, in DBug #928924, you could see another good reason why some
want source only uploads.

So please, it'd really help a good many DDs, who have reasons to prefer
source-only uploads.


Thanks,
Ritesh


Setting up fakeroot (1.23-1) ...
update-alternatives: using /usr/bin/fakeroot-sysv to provide /usr/bin/fakeroot 
(fakeroot) in auto mode
Processing triggers for man-db (2.8.5-2) ...
Not building database; man-db/auto-update is not 'true'.
Processing triggers for libc-bin (2.28-10) ...
I: Building the package
I: Running cd /build/user-mode-linux-4.19-1um/ && env 
PATH="/usr/lib/ccache:/usr/sbin:/usr/bin:/sbin:/bin" HOME="/nonexistent" 
dpkg-buildpackage -us -uc  -S
dpkg-buildpackage: info: source package user-mode-linux
dpkg-buildpackage: info: source version 4.19-1um-1
dpkg-buildpackage: info: source distribution unstable
dpkg-buildpackage: info: source changed by Ritesh Raj Sarraf 
 dpkg-source --before-build .
 fakeroot debian/rules clean
(cd linux-source-4.19 && 
QUILT_PATCHES=/build/user-mode-linux-4.19-1um/debian/patches quilt pop -a || 
/bin/true)
/bin/sh: 1: cd: can't cd to linux-source-4.19
rm -rf patch-stamp linux-source-4.19/.pc
dh_testdir
dh_testroot
rm -f unpack-stamp build-stamp configure-stamp
rm -rf linux-source-4.19 linux.uml.1 
/build/user-mode-linux-4.19-1um/debian/uml-modules changelog
dh_clean
 dpkg-source -b .
dpkg-source: warning: no source format specified in debian/source/format, see 
dpkg-source(1)
dpkg-source: info: using source format '1.0'
dpkg-source: info: building user-mode-linux in user-mode-linux_4.19-1um-1.tar.gz
dpkg-source: info: building user-mode-linux in user-mode-linux_4.19-1um-1.dsc
 dpkg-genbuildinfo --build=source
 dpkg-genchanges --build=source >../user-mode-linux_4.19-1um-1_source.changes
dpkg-genchanges: info: including full source code in upload
 dpkg-source --after-build .
dpkg-buildpackage: info: source-only upload: Debian-native package
I: copying local configuration
E: Missing changes file: 
/tmp//13390/build/user-mode-linux_4.19-1um-1_amd64.changes
I: unmounting /var/cache/apt/archives/ filesystem


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

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

Versions of packages pbuilder depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  debootstrap1.0.114
ii  dpkg-dev   1.19.6

Versions of packages pbuilder recommends:
ii  devscripts  2.19.5
ii  eatmydata   105-7
ii  fakeroot1.23-1
ii  iproute24.20.0-2
ii  net-tools   1.60+git20180626.aebd88e-1
ii  sudo1.8.27-1

Versions of packages pbuilder suggests:
pn  cowdancer   
ii  gdebi-core  0.9.5.7+nmu3

-- debconf information:
* pbuilder/rewrite: false
  pbuilder/nomirror:
* pbuilder/mirrorsite: http://deb.debian.org/debian

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Vincent Lefevre]

On 2019-05-16 15:59:09 +0200, Vincent Lefevre wrote:
> On 2019-05-16 14:41:44 +0200, Michael Biebl wrote:
> > Am 16.05.19 um 14:22 schrieb Vincent Lefevre:
> > > On 2019-05-16 14:15:37 +0200, Michael Biebl wrote:
> > >> Looks like you have a local resolver configured in /etc/resolv.conf
> > >> (which should be reachable via lo, even if eth0 is down).
> > > 
> > > Yes, /etc/resolv.conf contains
> > > 
> > > nameserver 127.0.0.1
> > > nameserver 192.168.1.1
> > > 
> > > as I use "unbound".
> > 
> > So host talks to unbound, which apparently takes those 12s to answer.
> > Not sure what can be done about this in avahi-daemon. Ideas?
> 
> Should this be regarded as a bug in unbound, then?

Actually, no, unbound is not the problem:

Whether I have

nameserver 127.0.0.1
nameserver 192.168.1.1

or just

nameserver 192.168.1.1

in /etc/resolv.conf, "time host -t soa local." shows a 10-second
timeout.

Or would the old /etc/resolv.conf (with 127.0.0.1) be cached somewhere
on the system?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#929078: ibus-sunpinyin: can't save settings

[Gedalya]

Package: ibus-sunpinyin
Version: 2.0.3+git20181120-1

In sunpinyin setup (/usr/lib/ibus/ibus-setup-sunpinyin), when clicking apply or 
OK, I get this:

Traceback (most recent call last):
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 603, in 
on_main_ok_clicked
    self.__write_config()
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 559, in __write_config
    opt.write_config()
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 118, in write_config
    self.write(v)
  File "/usr/share//ibus-sunpinyin/setup/main.py", line 83, in write
    return self.config.set_value(section, key, type(self.default)(v))
  File "/usr/lib/python3/dist-packages/gi/overrides/IBus.py", line 87, in 
set_value
    super(Config, self).set_value(section, name, value)
TypeError: argument value: Expected GLib.Variant, but got int

Thanks,

Gedalya


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

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

Versions of packages ibus-sunpinyin depends on:
ii  gir1.2-gtk-3.0   3.24.5-1
ii  libc6    2.28-10
ii  libgcc1  1:8.3.0-6
ii  libglib2.0-0 2.58.3-1
ii  libibus-1.0-5    1.5.19-4
ii  libstdc++6   8.3.0-6
ii  libsunpinyin3v5  3.0.0~rc1+ds1-2
ii  python3  3.7.2-1
ii  sunpinyin-data   0.1.22+20170109-2

ibus-sunpinyin recommends no packages.

ibus-sunpinyin suggests no packages.

-- no debconf information

Bug#929079: nextcloud-desktop: Subfolders of moved folders not synced

[Sandro Knauß]

Package: nextcloud-desktop
Version: 2.5.1-2
Severity: important
Control: Forwarded -1 https://github.com/nextcloud/desktop/issues/1000

When moving a folder into your Nextcloud folder, Nextcloud desktop do
synchronize all directories recursively.

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

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

Versions of packages nextcloud-desktop depends on:
ii  libc6 2.28-10
ii  libgcc1   1:8.3.0-7
ii  libnextcloudsync0 2.5.1-2
ii  libqt5concurrent5 5.11.3+dfsg1-1
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5dbus5   5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5keychain1   0.9.1-2
ii  libqt5network55.11.3+dfsg1-1
ii  libqt5positioning55.11.3+dfsg-2
ii  libqt5printsupport5   5.11.3+dfsg1-1
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5sql5-sqlite 5.11.3+dfsg1-1
ii  libqt5webchannel5 5.11.3-2
ii  libqt5webenginecore5  5.11.3+dfsg-2+b1
ii  libqt5webenginewidgets5   5.11.3+dfsg-2+b1
ii  libqt5webkit5 5.212.0~alpha2-21
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5xml55.11.3+dfsg1-1
ii  libsqlite3-0  3.27.2-2
ii  libssl1.1 1.1.1b-2
ii  libstdc++68.3.0-7
ii  nextcloud-desktop-common  2.5.1-2
ii  nextcloud-desktop-l10n2.5.1-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages nextcloud-desktop recommends:
ii  nextcloud-desktop-doc  2.5.1-2

nextcloud-desktop suggests no packages.

-- no debconf information

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Michael Biebl]

Am 16.05.19 um 15:59 schrieb Vincent Lefevre:
> On 2019-05-16 14:41:44 +0200, Michael Biebl wrote:
>> Am 16.05.19 um 14:22 schrieb Vincent Lefevre:
>>> On 2019-05-16 14:15:37 +0200, Michael Biebl wrote:
 Looks like you have a local resolver configured in /etc/resolv.conf
 (which should be reachable via lo, even if eth0 is down).
>>>
>>> Yes, /etc/resolv.conf contains
>>>
>>> nameserver 127.0.0.1
>>> nameserver 192.168.1.1
>>>
>>> as I use "unbound".
>>
>> So host talks to unbound, which apparently takes those 12s to answer.
>> Not sure what can be done about this in avahi-daemon. Ideas?
> 
> Should this be regarded as a bug in unbound, then?
> 

No idea. I don't use nor know anything about unbound and if what you are
seeing is expected behaviour or not.

-- 
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#929010: [Pkg-utopia-maintainers] Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Vincent Lefevre]

On 2019-05-16 14:41:44 +0200, Michael Biebl wrote:
> Am 16.05.19 um 14:22 schrieb Vincent Lefevre:
> > On 2019-05-16 14:15:37 +0200, Michael Biebl wrote:
> >> Looks like you have a local resolver configured in /etc/resolv.conf
> >> (which should be reachable via lo, even if eth0 is down).
> > 
> > Yes, /etc/resolv.conf contains
> > 
> > nameserver 127.0.0.1
> > nameserver 192.168.1.1
> > 
> > as I use "unbound".
> 
> So host talks to unbound, which apparently takes those 12s to answer.
> Not sure what can be done about this in avahi-daemon. Ideas?

Should this be regarded as a bug in unbound, then?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#927726: wlroots: Please upload new upstream version

[iskrenx2]

Hello again, 
Please point me to te documentation on how a package goes 
from: "Debian NEW and BYHAND Packages" (
https://ftp-master.debian.org/new.html ) 
to: the experimental repository. (
https://packages.debian.org/experimental/ )
What is blocking it ? 
What is the meaning of the "black" vs "red" font color ? 
Thank you very much. Best Regards.


-

П.П. Виж как една учителка по китайски реши да си направи сайт. А ти искаш ли 
да те намират лесно в интернет? Направи си сайт! Научи повече на 
www.superhosting.bg.
 
https://www.superhosting.bg/?utm_source=mbg_medium=cpm_content=mail_footer_campaign=newuser_campaign2019

Bug#929072: systemd: Dependency propagation on units inconsistent during start

[Drexl, Johannes]

Hi Michael,
sure, I'll post that on GitHub too...

I've added the files I used on my test system to reproduce it. Have
fun!
-- 
Viele Grüße
Jo


--
Drexl Johannes

Leibniz-Rechenzentrum
der Bayerischen Akademie der Wissenschaften
Boltzmannstraße 1
85748 Garching

Benutzersekretariat-Tel.:   089-35831-8000
Servicedesk-Tel.:   089-35831-8800

Am Donnerstag, den 16.05.2019, 14:06 +0200 schrieb Michael Biebl:
> Am 16.05.19 um 13:21 schrieb Drexl Johannes:
> > during a more complicated setup of different services we found
> > something
> > odd when starting single branches. Minimal setup to reproduce:
> 
> Thanks for your bug report.
> To make it easier to reproduce, can you please attach the (dummy)
> services to illustrate the problem and also explicitly list the
> commands
> you used.
> Also, as you mentioned that this is not a Debian specific problem,
> it's
> usually best to file such issues upstream at
> https://github.com/systemd/systemd/issues
> Can you do that?
> 
> Regards,
> Michael

systemd_propagation.tar.gz
Description: application/compressed-tar


smime.p7s
Description: S/MIME cryptographic signature

Bug#929077: linux-image-4.19.0-4-amd64: cannot successfully resume from hibernate with nouveau driver unless I pass 'nomodeset'

[Chris Danis]

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

I'm running an x86_64 PC with an Nvidia GTX 960 (aka GM206).  Using the nouveau
driver.  Running fully up-to-date buster.

If I hibernate, on an attempted resume the system hangs up with black monitors.
I can ping it, but I can not ssh in (the port is open, but sshd never
responds).  Using SysRq keystrokes to reboot does work.

If I pass 'nomodeset' to the kernel when booting into the hibernated image, the
resume is successful.  (And then of course, the resumed-from-image kernel loads
its console framebuffer, thus why nomodeset is not shown in my command line in
this bug report.)

Please let me know whatever other details would be helpful!



-- Package-specific info:
** Version:
Linux version 4.19.0-4-amd64 (debian-ker...@lists.debian.org) (gcc version 
8.3.0 (Debian 8.3.0-2)) #1 SMP Debian 4.19.28-2 (2019-03-15)

** Command line:
BOOT_IMAGE=/vmlinuz-4.19.0-4-amd64 root=/dev/mapper/root-rootlv ro quiet

** Not tainted

** Kernel log:
[222765.418715] done.
[222765.418726] video LNXVIDEO:00: Restoring backlight state
[222765.418728] PM: hibernation exit
[222765.515010] pl2303 1-4.1:1.0: pl2303 converter detected
[222765.515909] usb 1-4.1: pl2303 converter now attached to ttyUSB0
[222766.573041] rtl8192se: Set FW Cmd fail!!
[222766.693488] rtl8192se: Set FW Cmd fail!!
[222766.814417] rtl8192se: Set FW Cmd fail!!
[222766.825123] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[222766.827650] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
[222766.983841] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
[222766.985676] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[222767.437561] rtl8192se: Set FW Cmd fail!!
[222767.558274] rtl8192se: Set FW Cmd fail!!
[222767.678984] rtl8192se: Set FW Cmd fail!!
[222767.689702] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[222767.765568] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[222767.886872] rtl8192se: Set FW Cmd fail!!
[222768.989074] rtl8192se: Set FW Cmd fail!!
[222769.720812] tg3 :03:00.0 enp3s0: Link is up at 1000 Mbps, full duplex
[222769.720822] tg3 :03:00.0 enp3s0: Flow control is on for TX and on for RX
[222769.720826] tg3 :03:00.0 enp3s0: EEE is enabled
[222769.720843] IPv6: ADDRCONF(NETDEV_CHANGE): enp3s0: link becomes ready
[222770.864722] rtl8192se: Set FW Cmd fail!!
[222771.937586] rtl8192se: Set FW Cmd fail!!
[222781.914683] rtl8192se: Set FW Cmd fail!!
[222793.874514] rtl8192se: Set FW Cmd fail!!
[222794.942285] rtl8192se: Set FW Cmd fail!!
[222798.042735] rtl8192se: Set FW Cmd fail!!
[222814.176041] rtl8192se: Set FW Cmd fail!!
[222826.897101] rtl8192se: Set FW Cmd fail!!
[222827.964980] rtl8192se: Set FW Cmd fail!!
[222830.306141] rtl8192se: Set FW Cmd fail!!
[222846.435005] rtl8192se: Set FW Cmd fail!!
[222862.564100] rtl8192se: Set FW Cmd fail!!
[222869.913444] rtl8192se: Set FW Cmd fail!!
[222870.995790] rtl8192se: Set FW Cmd fail!!
[222878.692325] rtl8192se: Set FW Cmd fail!!
[222894.823403] rtl8192se: Set FW Cmd fail!!
[222910.949588] rtl8192se: Set FW Cmd fail!!
[222922.879613] rtl8192se: Set FW Cmd fail!!
[222923.949027] rtl8192se: Set FW Cmd fail!!
[222927.078096] rtl8192se: Set FW Cmd fail!!
[222943.209407] rtl8192se: Set FW Cmd fail!!
[222959.335810] rtl8192se: Set FW Cmd fail!!
[222975.468837] rtl8192se: Set FW Cmd fail!!
[222985.936603] rtl8192se: Set FW Cmd fail!!
[222987.013713] rtl8192se: Set FW Cmd fail!!
[222991.590259] rtl8192se: Set FW Cmd fail!!
[223007.717996] rtl8192se: Set FW Cmd fail!!
[223023.846041] rtl8192se: Set FW Cmd fail!!
[223039.974196] rtl8192se: Set FW Cmd fail!!
[223048.915341] rtl8192se: Set FW Cmd fail!!
[223049.981070] rtl8192se: Set FW Cmd fail!!
[223056.102109] rtl8192se: Set FW Cmd fail!!
[223072.234060] rtl8192se: Set FW Cmd fail!!
[223088.358081] rtl8192se: Set FW Cmd fail!!
[223104.486303] rtl8192se: Set FW Cmd fail!!
[223112.118734] rtl8192se: Set FW Cmd fail!!
[223112.239961] rtl8192se: Set FW Cmd fail!!
[223112.361353] rtl8192se: Set FW Cmd fail!!
[223112.372021] IPv6: ADDRCONF(NETDEV_UP): wlp4s0: link is not ready
[223112.527974] rtl8192se: Set FW Cmd fail!!
[223113.597846] rtl8192se: Set FW Cmd fail!!
[223126.598963] rtl8192se: Set FW Cmd fail!!
[223142.726646] rtl8192se: Set FW Cmd fail!!
[223158.855295] rtl8192se: Set FW Cmd fail!!
[223167.243681] SGI XFS with ACLs, security attributes, realtime, no debug 
enabled
[223167.254833] JFS: nTxBlock = 8192, nTxLock = 65536
[223167.274091] ntfs: driver 2.1.32 [Flags: R/O MODULE].
[223167.294873] QNX4 filesystem 0.2.3 registered.
[223167.374903] raid6: sse2x1   gen() 11020 MB/s
[223167.442905] raid6: sse2x1   xor()  8114 MB/s
[223167.510907] raid6: sse2x2   gen() 12693 MB/s
[223167.578913] raid6: sse2x2   xor()  9067 MB/s
[223167.646907] raid6: sse2x4   gen() 15949 MB/s
[223167.714902] raid6: sse2x4   xor() 10486 MB/s
[223167.714904] raid6: using algorithm sse2x4 gen() 15949 MB/s
[223167.714905] raid6:  xor() 10486 MB/s, rmw enabled
[223167.714906] 

Bug#929076: kded5: many KDE processes have rwx memory mappings

[Laurent Bonnaud]

Package: kded5
Version: 5.54.0-1
Severity: important


Dear Maintainer,

As a defense against machine code injection attacks made possible by buffer 
overflow bugs, most Linux distributions have worked over the years to remove as 
many rwx memory mappings as possible in processes.

I checked this on several of my systems and unfortunately I found that many KDE 
processes do have rwx memory mappings.

I chose to report this bug against the kded package because it is one of the 
most fundamental affected KDE process I found. However, the problem seems to be 
more general in KDE. I apologize in advance for not finding a better software 
package to report this problem.


STEPS TO REPRODUCE
1. Log in Plasma
2. Run the following command:

$ grep rwx /proc/$(pidof kded5)/maps

OBSERVED RESULT

$ grep rwx /proc/$(pidof kded5)/maps
7f68d7c2a000-7f68d7c3a000 rwxp  00:00 0

EXPECTED RESULT

No output


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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
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>
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages kded5 depends on:
ii  libc6  2.28-10
ii  libkf5configcore5  5.54.0-1
ii  libkf5coreaddons5  5.54.0-1
ii  libkf5crash5   5.54.0-1
ii  libkf5dbusaddons5  5.54.0-1
ii  libkf5service-bin  5.54.0-1
ii  libkf5service5 5.54.0-1
ii  libqt5core5a   5.11.3+dfsg1-1
ii  libqt5dbus55.11.3+dfsg1-1
ii  libqt5gui5 5.11.3+dfsg1-1
ii  libqt5widgets5 5.11.3+dfsg1-1
ii  libstdc++6 9.1.0-2

kded5 recommends no packages.

kded5 suggests no packages.

-- no debconf information

-- 
Laurent.

Bug#929020: SFTP ProFTPD session terminating after 'mkdir /' after upgrade to 1.3.5e+r1.3.5-2+deb8u1

[Markus Koschany]

On Wed, 15 May 2019 13:36:31 +0200 Julian Schustereit
 wrote:
> Package: proftpd-basic
> Version: 1.3.5e+r1.3.5-2+deb8u1
> 
> After the upgrade from version '1.3.5e-0+deb8u1' to '1.3.5e+r1.3.5-2+deb8u1' 
> the sftp session is being terminated when using the command 'mkdir /'.
> 
> Before the upgrade following error message got displayed: 'Couldn't create 
> directory: Failure' and the session stayed active.
> 
> After the upgrade we get the following message from our syslogd displayed in 
> our terminal:
> MKDIR / type=unknown;UNIX.mode=0777;: symbol lookup error: 
> /usr/lib/proftpd/mod_sftp.so: undefined symbol: pr_gid2str

Hello,

thanks for the report. I believe the session is terminating because of
the symbol lookup error. The function pr_gid2str was not backported and
the compiler was happy to accept that. I have changed the log message to
not use this function. The message in general is correct though.

Could you try the new package uploaded to


https://people.debian.org/~apo/proftpd/

and report back, if it fixes your problem?

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Bug#929075: golang-github-jacobsa-crypto: Salsa CI failure

[Dave Steele]

Package: golang-github-jacobsa-crypto
Severity: minor
thanks

The golang-github-jacobsa-crypto package is currently failing the Salsa CI
test [1]. This happens
because uscan on Salsa is returning a different derived latest (git)
version tag than the one on my
build system [2]. This appears to be due to #910762 [3].

Issue logged with the go-team [4].


[1] -
https://salsa.debian.org/go-team/packages/golang-github-jacobsa-crypto/pipelines
[2] -
https://salsa.debian.org/go-team/packages/golang-github-jacobsa-crypto/-/jobs/173319
[3] - https://bugs.debian.org/910762
[4] - https://salsa.debian.org/go-team/ci/issues/2

Bug#929074: virtualbox: Guest additions ISO image fails to download

[Ralf Jung]

Package: virtualbox
Version: 6.0.8-dfsg-2
Severity: normal

Dear Maintainer,

I have now repeatedly (on several days) tried to download the latest Windows
Guest Additions ISO file (by clicking "Devices - Insert Guest Additions CD
image"). Every time, the download seems to complete but then finally shows an
error:

> The network operation failed with the following error: 
> During network request: Unknown reason.

My network is otherwise working fine, this seems to be an issue with VirtualBox
or the server it is fetching this from.

Kind regards,
Ralf

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

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

Versions of packages virtualbox depends on:
ii  adduser   3.118
ii  iproute2  4.20.0-2
ii  libc6 2.28-10
ii  libcurl3-gnutls   7.64.0-2
ii  libdevmapper1.02.12:1.02.155-2
ii  libgcc1   1:8.3.0-6
ii  libgl11.1.0-1
ii  libgsoap-2.8.75   2.8.75-1
ii  libopus0  1.3-1
ii  libpng16-16   1.6.36-5
ii  libpython3.7  3.7.3~rc1-1
ii  libqt5core5a  5.11.3+dfsg1-1
ii  libqt5gui55.11.3+dfsg1-1
ii  libqt5opengl5 5.11.3+dfsg1-1
ii  libqt5widgets55.11.3+dfsg1-1
ii  libqt5x11extras5  5.11.3-2
ii  libsdl1.2debian   1.2.15+dfsg2-4
ii  libssl1.1 1.1.1b-2
ii  libstdc++68.3.0-6
ii  libvncserver1 0.9.11+dfsg-1.3
ii  libvpx5   1.7.0-3
ii  libx11-6  2:1.6.7-1
ii  libxcursor1   1:1.1.15-2
ii  libxext6  2:1.3.3-1+b2
ii  libxml2   2.9.4+dfsg1-7+b3
ii  libxmu6   2:1.1.2-2+b3
ii  libxt61:1.1.5-1+b3
ii  procps2:3.3.15-2
ii  python3   3.7.2-1
ii  python3.7 3.7.3~rc1-1
ii  virtualbox-dkms [virtualbox-modules]  6.0.8-dfsg-2
ii  zlib1g1:1.2.11.dfsg-1

Versions of packages virtualbox recommends:
ii  libxcb11.13.1-2
ii  virtualbox-qt  6.0.8-dfsg-2

Versions of packages virtualbox suggests:
pn  vde2
pn  virtualbox-guest-additions-iso  

-- no debconf information

Bug#928919: patch: Do not hide errors from initscripts

[Thorsten Glaser]

On Thu, 16 May 2019, Dmitry Bogatov wrote:

> Having trailing ":" would result of ignoring result these "do_*" functions.

This is normally right. Initscripts must return 0 in most cases,
and only explicitly exit with a nonzero errorlevel when needed.

> Exit status of initscript does not affect boot process: see "startup()"
> from /etc/init.d/rc (no set -e):

Hmm, what was it then... this is from Policy §9.3.2...
but it can make package installation fail, that much is sure.

bye,
//m.

Bug#929073: intel-microcode: Missing MDS mitigations for some Intel CPUs

[Moritz Muehlenhoff]

Package: intel-microcode
Severity: important

I noticed that on some of our servers (using a E5-2470 Sandy Bridge
CPU), the MDS mitigations were not picked up and after some digging
I found
https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance_05132019.pdf
which lists all the CPU revisions for which updated microcode is not
yet available, but "Planned". It's obviously not actionable on the
Debian side, but I thought it's worth tracking nonetheless in the BTS
for the benefit of others wondering about missing microcode updates.

Cheers,
Moritz

Bug#929063: init: delegate selinux operation to separate binary

[Thorsten Glaser]

On Thu, 16 May 2019, Dmitry Bogatov wrote:

> + if (fork() == 0) { /* child */
if ((ret = fork()) == 0) { /* child */
> + execl(SELINUX_CHECK, SELINUX_CHECK, NULL);
> + fprintf(stderr, "Failed to execute helper to init SELinux\n");
> + exit(SELINUX_CHECK_HALT);
> + }
} else if (ret == -1) { /* fork failed */
fprintf(stderr, "Failed to fork to execute helper to init 
SELinux\n");
ret = SELINUX_CHECK_HALT;
} else { /* parent */
+   wait();
+   ret = WIFEXITED(wstatus) ? WEXITSTATUS(wstatus) : 
SELINUX_CHECK_HALT;
}
> + switch (ret) {
> + case SELINUX_CHECK_CONTINUE: return;
[...]

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Michael Biebl]

Am 16.05.19 um 14:22 schrieb Vincent Lefevre:
> On 2019-05-16 14:15:37 +0200, Michael Biebl wrote:
>> Looks like you have a local resolver configured in /etc/resolv.conf
>> (which should be reachable via lo, even if eth0 is down).
> 
> Yes, /etc/resolv.conf contains
> 
> nameserver 127.0.0.1
> nameserver 192.168.1.1
> 
> as I use "unbound".

So host talks to unbound, which apparently takes those 12s to answer.
Not sure what can be done about this in avahi-daemon. Ideas?


-- 
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#929010: [Pkg-utopia-maintainers] Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Vincent Lefevre]

On 2019-05-16 14:15:37 +0200, Michael Biebl wrote:
> Looks like you have a local resolver configured in /etc/resolv.conf
> (which should be reachable via lo, even if eth0 is down).

Yes, /etc/resolv.conf contains

nameserver 127.0.0.1
nameserver 192.168.1.1

as I use "unbound".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bug#896101: Please switch Suggests from libvte9 to libvte-2.91-0

[Egmont Koblinger]

Hi,

Friendly ping – dear developers, could you please address this trivial issue?

This is the only thing that prevents Ubuntu from removing the obsolete
libvte9 package, see
https://bugs.launchpad.net/ubuntu/+source/vte/+bug/1829377 .

(By the way, Debian should also aim to remove libvte9, but that's for
another bug...)

cheers,
egmont

Bug#929010: [Pkg-utopia-maintainers] Bug#929010: avahi-daemon: /etc/network/if-post-down.d/avahi-daemon is slow on eth0

[Michael Biebl]

Am 16.05.19 um 00:27 schrieb Vincent Lefevre:
> On 2019-05-15 12:50:49 +0200, Michael Biebl wrote:
>> Which part of /usr/lib/avahi/avahi-daemon-check-dns.sh is taking so long?
>> Can you add a "set -x" and then manually invoke "ifdown eth0"
> 
> I get:
> 
> + PATH=/bin:/usr/bin:/sbin:/usr/sbin
> + RUNDIR=/var/run/avahi-daemon/
> + DISABLE_TAG=/var/run/avahi-daemon//disabled-for-unicast-local
> + NS_CACHE=/var/run/avahi-daemon//checked_nameservers
> + AVAHI_DAEMON_DETECT_LOCAL=1
> + test -f /etc/default/avahi-daemon
> + . /etc/default/avahi-daemon
> + AVAHI_DAEMON_DETECT_LOCAL=1
> + [ 1 != 1 ]
> + dns_reachable
> + grep -q nameserver /etc/resolv.conf
> + 
> + egrep -q nameserver 127.0.0.1|::1 /etc/resolv.conf
> + 
> + return 0
> + dns_needs_check
> + TMP_CACHE=/var/run/avahi-daemon//checked_nameservers.8379
> + RET=0
> + ensure_rundir
> + [ ! -d /var/run/avahi-daemon/ ]
> + cat /etc/resolv.conf
> + grep nameserver
> + sort
> + [ -e /var/run/avahi-daemon//checked_nameservers ]
> + mv /var/run/avahi-daemon//checked_nameservers.8379 
> /var/run/avahi-daemon//checked_nameservers
> + return 0
> + dns_has_local
> + [ -n  ]
> + LC_ALL=C host -t soa local.
> + OUT=;; connection timed out; no servers could be reached
> + [ 1 -eq 0 ]
> + rm -f /var/run/avahi-daemon//checked_nameservers
> + return 1
> + enable_avahi
> + [ -e /var/run/avahi-daemon//disabled-for-unicast-local ]
> + exit 0
> 
> with several seconds between
> 
> + LC_ALL=C host -t soa local.
> 
> and
> 
> + OUT=;; connection timed out; no servers could be reached
> 
> At least, this is consistent with the timeout.
> 
> Moreover, I don't understand why it tries to reach servers as eth0
> is down (this is called in an if-post-down.d script).
> 

Looks like you have a local resolver configured in /etc/resolv.conf
(which should be reachable via lo, even if eth0 is down).

-- 
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#929072: systemd: Dependency propagation on units inconsistent during start

[Michael Biebl]

Am 16.05.19 um 13:21 schrieb Drexl Johannes:
> during a more complicated setup of different services we found something
> odd when starting single branches. Minimal setup to reproduce:

Thanks for your bug report.
To make it easier to reproduce, can you please attach the (dummy)
services to illustrate the problem and also explicitly list the commands
you used.
Also, as you mentioned that this is not a Debian specific problem, it's
usually best to file such issues upstream at
https://github.com/systemd/systemd/issues
Can you do that?

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#927876: zsh: Does not print 'command not found' message if handler does not match

[Joel Cross]

I have added a patch to the Ubuntu version of the bug (I believe Ubuntu is 
considered the upstream for this package). Hopefully they'll merge it soon, 
then we can pull the changes into Debian.

Bug#928477: librecad: denial-of-service CVE-2018-19105

[Markus Koschany]

Control: tags -1 pending patch

On Sun, 5 May 2019 16:55:54 +0200 Markus Koschany  wrote:
> Package: librecad
> X-Debbugs-CC: t...@security.debian.org
> Severity: important
> Tags: security
> 
> Hi,
> 
> The following vulnerability was published for librecad.
> 
> CVE-2018-19105[0]:
> | LibreCAD 2.1.3 allows remote attackers to cause a denial of service
> | (0x89C04589 write access violation and application crash) or possibly
> | have unspecified other impact via a crafted file.

Dear maintainer,

I have uploaded a new revision of librecad to fix CVE-2018-19105. I
intend to file an unblock request as well.

Regards,

Markus
diff -Nru librecad-2.1.3/debian/changelog librecad-2.1.3/debian/changelog
--- librecad-2.1.3/debian/changelog 2018-09-17 19:23:30.0 +0200
+++ librecad-2.1.3/debian/changelog 2019-05-16 13:11:05.0 +0200
@@ -1,3 +1,13 @@
+librecad (2.1.3-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix CVE-2018-19105:
+A vulnerability was found in LibreCAD, a computer-aided design system,
+which could be exploited to crash the application or cause other
+unspecified impact when opening a specially crafted file. (Closes: #928477)
+
+ -- Markus Koschany   Thu, 16 May 2019 13:11:05 +0200
+
 librecad (2.1.3-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru librecad-2.1.3/debian/patches/CVE-2018-19105.patch 
librecad-2.1.3/debian/patches/CVE-2018-19105.patch
--- librecad-2.1.3/debian/patches/CVE-2018-19105.patch  1970-01-01 
01:00:00.0 +0100
+++ librecad-2.1.3/debian/patches/CVE-2018-19105.patch  2019-05-16 
13:11:05.0 +0200
@@ -0,0 +1,92 @@
+From: Markus Koschany 
+Date: Thu, 16 May 2019 13:08:48 +0200
+Subject: CVE-2018-19105
+
+Bug-Upstream: https://github.com/LibreCAD/LibreCAD/issues/1038
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928477
+Origin: 
https://github.com/LibreCAD/LibreCAD/commit/6da7cc5f7f31afb008f03dbd11e07207ccd82085
+Origin: 
https://github.com/LibreCAD/LibreCAD/commit/8604f171ee380f294102da6154adf77ab754d403
+---
+ libraries/libdxfrw/src/drw_header.cpp |  8 
+ libraries/libdxfrw/src/libdxfrw.cpp   | 29 +++--
+ 2 files changed, 31 insertions(+), 6 deletions(-)
+
+diff --git a/libraries/libdxfrw/src/drw_header.cpp 
b/libraries/libdxfrw/src/drw_header.cpp
+index 1e0530d..6465669 100644
+--- a/libraries/libdxfrw/src/drw_header.cpp
 b/libraries/libdxfrw/src/drw_header.cpp
+@@ -20,6 +20,7 @@ DRW_Header::DRW_Header() {
+ linetypeCtrl = layerCtrl = styleCtrl = dimstyleCtrl = appidCtrl = 0;
+ blockCtrl = viewCtrl = ucsCtrl = vportCtrl = vpEntHeaderCtrl = 0;
+ version = DRW::AC1021;
++curr = NULL;
+ }
+ 
+ void DRW_Header::addComment(std::string c){
+@@ -29,6 +30,13 @@ void DRW_Header::addComment(std::string c){
+ }
+ 
+ void DRW_Header::parseCode(int code, dxfReader *reader){
++if (NULL == curr && 9 != code) {
++DRW_DBG("invalid header code: ");
++DRW_DBG(code);
++DRW_DBG("\n");
++return;
++}
++
+ switch (code) {
+ case 9:
+ curr = new DRW_Variant();
+diff --git a/libraries/libdxfrw/src/libdxfrw.cpp 
b/libraries/libdxfrw/src/libdxfrw.cpp
+index 60d6b74..03da2a6 100644
+--- a/libraries/libdxfrw/src/libdxfrw.cpp
 b/libraries/libdxfrw/src/libdxfrw.cpp
+@@ -1839,17 +1839,27 @@ bool dxfRW::processDxf() {
+ DRW_DBG(sectionstr); DRW_DBG("  processDxf\n");
+ //found section, process it
+ if (sectionstr == "HEADER") {
+-processHeader();
++if (!processHeader()) {
++return false;
++}
+ } else if (sectionstr == "CLASSES") {
+ //processClasses();
+ } else if (sectionstr == "TABLES") {
+-processTables();
++if (!processTables()) {
++return false;
++}
+ } else if (sectionstr == "BLOCKS") {
+-processBlocks();
++if (!processBlocks()) {
++return false;
++}
+ } else if (sectionstr == "ENTITIES") {
+-processEntities(false);
++if (!processEntities(false)) {
++return false;
++}
+ } else if (sectionstr == "OBJECTS") {
+-processObjects();
++if (!processObjects()) {
++return false;
++}
+ }
+ }
+ }
+@@ -1875,7 +1885,14 @@ bool dxfRW::processHeader() {
+ iface->addHeader();
+ return true;  //found ENDSEC terminate
+ }
+-} else 

Bug#929037: mathicgb FTCBFS: abuses AC_CHECK_FILE

[Torrance, Douglas]

Control: forwarded -1 https://github.com/Macaulay2/mathicgb/pull/14

On Wed, May 15, 2019 at 4:18 PM Helmut Grohne 
mailto:hel...@subdivi.de>> wrote:
mathicgb fails to cross build from source, because it abuses
AC_CHECK_FILE to discover source files on the build machine. The macro
is meant to check for files on the host. Please use simple "test -f"
here. The attached patch makes mathicgb cross buildable. Please consider
applying it.

Thanks for the report and patch!  I've forwarded it upstream [1].

Doug

[1] https://github.com/Macaulay2/mathicgb/pull/14

Bug#929072: systemd: Dependency propagation on units inconsistent during start

[Drexl Johannes]

Package: systemd
Version: 232-25+deb9u11
Severity: normal

Dear Maintainer,

during a more complicated setup of different services we found something
odd when starting single branches. Minimal setup to reproduce:

Service 0 is the root service (Wants services 1, 2, 3)
Services 1, 2 and 3 are services that depend on service 0 (Requires) and
will start after service 0
Service 1 wants service 10
Service 10 depends on service 1 (Requires) and starts after service 1.

Starting service 0 will start all services up as expected. Stopping
service 0 will stop all services accordingly. Everything works fine so
far.

Now stop all services except service 0. Then start service 1. It will
start up, with service 10 after it. Services 2 and 3 will stay down.
This is expected behavior. 

Once again stop all services except service 0, and then start service 2.
One would now expect two running services: service 0 and service 2. But
you will find that service 1 was also started, as well as its child
service 10. Only service 3 remains down. 
You may as well try starting service 3 instead of service 2, which will
yield a similar result, i. e. only service 2 stays down; services 1 and
10 will be up again.

We tried that on SLES 12.4 as well as Debian Buster, this behavior
sticks through all versions and is consistent throughout our 20+
services setup: All branches with further branches down the line are 
getting started, all dead-end branches will remain down. It doesn't 
really break anything on our end, it's just unexpected.

My proposal: Unless the root service is (re-) started, don't propagate
through its 'Wants' statements (I expect the error there). Only start up 
the affected services and their wanted children. 

-- Package-specific info:

-- System Information:
Debian Release: 9.9
  APT prefers stable
  APT policy: (500, '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: systemd (via /run/systemd/system)

Versions of packages systemd depends on:
ii  adduser 3.115
ii  libacl1 2.2.52-3+b1
ii  libapparmor12.11.0-3+deb9u2
ii  libaudit1   1:2.6.7-2
ii  libblkid1   2.29.2-1+deb9u1
ii  libc6   2.24-11+deb9u4
ii  libcap2 1:2.25-1
ii  libcryptsetup4  2:1.7.3-4
ii  libgcrypt20 1.7.6-2+deb9u3
ii  libgpg-error0   1.26-2
ii  libidn111.33-1
ii  libip4tc0   1.6.0+snapshot20161117-6
ii  libkmod223-2
ii  liblz4-10.0~r131-2+b1
ii  liblzma55.2.2-1.2+b1
ii  libmount1   2.29.2-1+deb9u1
ii  libpam0g1.1.8-3.6
ii  libseccomp2 2.3.1-2.1+deb9u1
ii  libselinux1 2.6-3+b3
ii  libsystemd0 232-25+deb9u11
ii  mount   2.29.2-1+deb9u1
ii  procps  2:3.3.12-3+deb9u1
ii  util-linux  2.29.2-1+deb9u1

Versions of packages systemd recommends:
ii  dbus1.10.26-0+deb9u1
ii  libpam-systemd  232-25+deb9u11

Versions of packages systemd suggests:
ii  policykit-10.105-18+deb9u1
pn  systemd-container  
pn  systemd-ui 

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.130
ii  udev 232-25+deb9u11

-- Configuration Files:
/etc/systemd/timesyncd.conf changed [not included]

-- no debconf information

Bug#929071: nvidia-glx,nvidia-glx-legacy-96xx: fails to remove: dpkg-divert: error checking `/usr/lib/xorg/modules/extensions/libGLcore.a': No such file or directory

[Andreas Beckmann]

Package: nvidia-glx,nvidia-glx-legacy-96xx
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts
Control: found -1 nvidia-graphics-drivers/173.14.09-5
Control: found -1 nvidia-graphics-drivers-legacy-96xx/96.43.07-2
Control: close -1 195.36.24-1

Hi,

during a test with piuparts I noticed your package fails to remove.

>From the attached log (scroll to the bottom...):

  Removing nvidia-glx ...
  rm: cannot remove `/usr/lib/libGL.so': No such file or directory
  dpkg-divert: error checking `/usr/lib/xorg/modules/extensions/libGLcore.a': 
No such file or directory
  dpkg: error processing nvidia-glx (--remove):
   subprocess post-removal script returned error exit status 2

  Removing nvidia-glx-legacy-96xx ...
  rm: cannot remove `/usr/lib/libGL.so': No such file or directory
  dpkg-divert: error checking `/usr/lib/xorg/modules/extensions/libGLcore.a': 
No such file or directory
  dpkg: error processing nvidia-glx-legacy-96xx (--remove):
   subprocess post-removal script returned error exit status 2


cheers,

Andreas

Bug#929070: ITP: ruby-discourse-diff -- Discourse Diff provides inline HTML diffing for markdown blobs

[Samyak Jain]

Package: wnpp
Severity: wishlist
Owner: Samyak Jain 

* Package name: ruby-discourse-diff
  Version : 0.1.0
  Upstream Author : James Kiesel
* URL : https://github.com/gdpelican/discourse-diff
* License : Expat
  Programming Lang: Ruby
  Description : Discourse Diff provides inline HTML diffing for
markdown blobs

 This library has been extracted from [Discourse core]
 (https://www.github.com/discourse/discourse)
 This is a inline HTML diffing engine forked off of Discourse.
 It includes various usage such as Inline diff for single paragraph text,
 HTML markdown of HTML differences, HTML markdown of markdown differences.

It is a dependency for loomio and hence needs to be packaged.

Thanks,
Samyak Jain

Bug#929069: rename: description references rename in perl package, which has gone

[Jonathan Dowland]

Package: rename
Version: 1.10-1
Severity: minor

Quoting description

> Description: Perl extension for renaming multiple files
>  This package provides both a perl interface for renaming files
>  (File::Rename) and a command line tool 'rename' which is intended to
>  replace the version currently supplied by the perl package.

perl 5.28.1-6 (Buster) does not include rename any more.

(I installed this package hoping it was a drop-in replacement but
"rename -nv" does not work :/)

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB.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 rename depends on:
ii  perl  5.28.1-6

rename recommends no packages.

rename suggests no packages.

-- no debconf information

Bug#927142: unblock sent

[Xavier]

unblock for cyrus-imapd_3.0.8-5 sent: https://bugs.debian.org/929068

Bug#929067: Support for MDS

[Moritz Muehlenhoff]

Package: qemu-system-x86
Severity: grave
Tags: security

These are not upstreamed due to the embargo period, but I'm attaching
the 3.1 patches from Ubuntu 19.04.

Cheers,
Moritz
>From a57fa50701c6a0fbe5ac7dbcc314c3c970bff899 Mon Sep 17 00:00:00 2001
From: Paolo Bonzini 
Date: Fri, 1 Mar 2019 21:40:52 +0100
Subject: [qemu PATCH] target/i386: define md-clear bit

md-clear is a new CPUID bit which is set when microcode provides the
mechanism to invoke a flush of various exploitable CPU buffers by invoking
the VERW instruction.  Add the new feature, and pass it down to
Hypervisor.framework guests.

Signed-off-by: Paolo Bonzini 

[Backported to qemu 3.1 - sbeattie]

---
The last hunk is only needed for OS X, but anyway this is going
to be the patch that will be committed upstream.

CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091

 target/i386/cpu.c   | 2 +-
 target/i386/cpu.h   | 1 +
 target/i386/hvf/x86_cpuid.c | 3 ++-
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index d990070c59..16da90562c 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1075,7 +1075,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
{
 .feat_names = {
 NULL, NULL, "avx512-4vnniw", "avx512-4fmaps",
 NULL, NULL, NULL, NULL,
-NULL, NULL, NULL, NULL,
+NULL, NULL, "md-clear", NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, "pconfig", NULL,
 NULL, NULL, NULL, NULL,
diff --git a/target/i386/cpu.h b/target/i386/cpu.h
index 26412f15eb..cbfab1a421 100644
--- a/target/i386/cpu.h
+++ b/target/i386/cpu.h
@@ -692,6 +692,7 @@ typedef uint32_t FeatureWordArray[FEATURE_WORDS];
 
 #define CPUID_7_0_EDX_AVX512_4VNNIW (1U << 2) /* AVX512 Neural Network 
Instructions */
 #define CPUID_7_0_EDX_AVX512_4FMAPS (1U << 3) /* AVX512 Multiply Accumulation 
Single Precision */
+#define CPUID_7_0_EDX_MD_CLEAR  (1U << 10) /* Microarchitectural Data 
Clear */
 #define CPUID_7_0_EDX_PCONFIG (1U << 18)   /* Platform Configuration */
 #define CPUID_7_0_EDX_SPEC_CTRL (1U << 26) /* Speculation Control */
 #define CPUID_7_0_EDX_ARCH_CAPABILITIES (1U << 29)  /*Arch Capabilities*/
diff --git a/target/i386/hvf/x86_cpuid.c b/target/i386/hvf/x86_cpuid.c
index 9874a46e92..f76ba50424 100644
--- a/target/i386/hvf/x86_cpuid.c
+++ b/target/i386/hvf/x86_cpuid.c
@@ -103,7 +103,8 @@ uint32_t hvf_get_supported_cpuid(uint32_t func, uint32_t 
idx,
 }
 
 ecx &= CPUID_7_0_ECX_AVX512BMI | CPUID_7_0_ECX_AVX512_VPOPCNTDQ;
-edx &= CPUID_7_0_EDX_AVX512_4VNNIW | CPUID_7_0_EDX_AVX512_4FMAPS;
+edx &= CPUID_7_0_EDX_AVX512_4VNNIW | CPUID_7_0_EDX_AVX512_4FMAPS | 
\
+   CPUID_7_0_EDX_MD_CLEAR;
 } else {
 ebx = 0;
 ecx = 0;
-- 
2.20.1

From: Paolo Bonzini 
Subject: [PATCH] target/i386: add MDS-NO feature

Microarchitectural Data Sampling is a hardware vulnerability which allows
unprivileged speculative access to data which is available in various CPU
internal buffers.

Some Intel processors use the ARCH_CAP_MDS_NO bit in the IA32_ARCH_CAPABILITIES
MSR to report that they are not vulnerable, make it available to guests.

Signed-off-by: Paolo Bonzini 
--
CVE-2018-12126, CVE-2018-12127, CVE-2018-12130, CVE-2019-11091

diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 722c5514d4..558347e6c3 100644
--- a/target/i386/cpu.c
+++ b/target/i386/cpu.c
@@ -1184,7 +1184,7 @@ static FeatureWordInfo feature_word_info[FEATURE_WORDS] = 
{
 .type = MSR_FEATURE_WORD,
 .feat_names = {
 "rdctl-no", "ibrs-all", "rsba", "skip-l1dfl-vmentry",
-"ssb-no", NULL, NULL, NULL,
+"ssb-no", "mds-no", NULL, NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,
 NULL, NULL, NULL, NULL,