Bug#928746: unblock: zfs-linux/0.7.13-1

[Mo Zhou]

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

Please unblock package zfs-linux

zfs-linux (= 0.7.13-1) is 66 days in unstable and there is no new bug
for it.
Compared to (0.7.12-2), the (0.7.13-1) version in unstable only
introduces
bug fixes. Aron has already applied for an unblock but it was rejected.
Here I'm requesting for unblock again.

The difference between upstream 0.7.12 and 0.7.13 includes
linux 5.0 compat fixes, and a series of bug fixes. I can revert
the linux 5.0 compat fixes if you think that's irrelated to
the Buster release with the 0.7.13-2 upload. I can also revert
some enhancement patches if release team doesn't like them. Even
if we reverted the linux 5.0 compat and some enhancements, it
is still better than letting 0.7.12-2 stay in Buster, because
in that way we still have bug fixes.

On the debian packaging side, the difference between 0.7.12-2
(testing) and 0.7.13-1 (unstable) includes manually cherry-picked
patches (by Colin Ian King(ubuntu diff), Aron Xu, and Me), fixes
for the problematic autopkgtest script I wrote, and a small update
for the Debian+OpenRC support patch. Most of the newly added patches
were already shipped by the ubuntu package more than 3 months ago.

zfs (0.7.12-5) was uploaded to unstable before (hardfreeze - 12 days).
zfs (0.7.13-1) was uploaded to unstable on (hardfreeze - 8 days).
I should have waited for some time for the 0.7.12-5 migration...

Anyway let's see the diffstat and I'll comment every bit of change in
detail.  Please at least accept some bug fixes for Buster. And tell
me which of the enhancements (incl. linux 5.0 compat) are
not acceptible so that I can revert them.

(explain the reason for the unblock here)

```
~/D/z/zfs ❯❯❯ git diff debian/0.7.12-2 debian/0.7.13-1 --stat | cat
 META   |   2 +-
 Makefile.in|   2 +
 aclocal.m4 |   2 +
 cmd/Makefile.in|   2 +
 cmd/arc_summary/Makefile.in|   2 +
 cmd/arcstat/Makefile.in|   2 +
 cmd/dbufstat/Makefile.in   |   2 +
 cmd/fsck_zfs/Makefile.in   |   2 +
 cmd/mount_zfs/Makefile.am  |   2 +
 cmd/mount_zfs/Makefile.in  |   4 +
 cmd/raidz_test/Makefile.in |   2 +
 cmd/vdev_id/Makefile.in|   2 +

[linux 5.0 compat]
*.am and *.in was updated for linux 5.0

 cmd/vdev_id/vdev_id| 209 -

[enhancements]

2b8c3cb0c83681d7425fa5bf567e726b7ba975e9
vdev_id: extension for new scsi topology

41f7723e9cb260f313f99d667142e37617812fca
vdev_id: new slot type ses

c32c2f17d06cea5dc298b404fad7696921e490e0
Add enclosure_symlinks option to vdev_id

 cmd/zdb/Makefile.in|   2 +
 cmd/zed/Makefile.in|   2 +
 cmd/zfs/Makefile.in|   2 +
 cmd/zgenhostid/Makefile.in |   2 +
 cmd/zhack/Makefile.in  |   2 +
 cmd/zinject/Makefile.in|   2 +
 cmd/zpios/Makefile.in  |   2 +
 cmd/zpool/Makefile.in  |   2 +
 cmd/zstreamdump/Makefile.in|   2 +
 cmd/ztest/Makefile.in  |   2 +

[linux 5.0 compat]
all the *.in files above

 cmd/ztest/ztest.c  |   4 +-

[trivial C code change]
-   .zo_pool = { 'z', 't', 'e', 's', 't', '\0' },
-   .zo_dir = { '/', 't', 'm', 'p', '\0' },
+   .zo_pool = "ztest",
+   .zo_dir = "/tmp",

 cmd/zvol_id/Makefile.in|   2 +
 config/kernel-access-ok-type.m4|  21 +
 config/kernel-bio_set_dev.m4   |  35 +-
 config/kernel-fpu.m4   |  41 +-
 config/kernel-misc-minor.m4|  26 +
 config/kernel.m4   |   4 +-

[linux 5.0 compat]
the above several files were changed due to linux compat fix

 configure  | 599
++-

Mostly due to newly added kernel feature checks.
Deleted lines are due to version number bump.

 configure.ac   |   3 +
 contrib/Makefile.in|   2 +
 contrib/bash_completion.d/Makefile.in  |   2 +
 contrib/dracut/02zfsexpandknowledge/Makefile.in|   2 +
 contrib/dracut/90zfs/Makefile.am   |   1 +
 contrib/dracut/90zfs/Makefile.in   |   3 +
 contrib/dracut/90zfs/module-setup.sh.in|   4 +-
 contrib/dracut/Makefile.in   

Bug#928745: mirror submission for debian.uz

[debian.uz]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: debian.uz
Type: leaf
Archive-architecture: amd64 arm64 i386
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: debian.uz 
Country: UZ Uzbekistan




Trace Url: http://debian.uz/debian/project/trace/
Trace Url: http://debian.uz/debian/project/trace/ftp-master.debian.org
Trace Url: http://debian.uz/debian/project/trace/debian.uz

Bug#928744: u-boot: add support for the Turris Omnia and other OpenSSL reqiring hardware

[Paul Wise]

Source: u-boot
Severity: wishlist

Please add support to the u-boot source package for building u-boot
binary packages for the Turris Omnia and other hardware where u-boot requires 
OpenSSL. As I understand it, these binary packages are not redistributable by 
Debian but folks could build or cross-build them
themselves for deployment on their own hardware. By using dpkg's build
profiles support, those packages could be added to the u-boot source
package, not be built by default but still be able to be manually buildable 
using the dpkg-buildpackage --build-profiles option.

https://wiki.debian.org/BuildProfileSpec

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



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

Bug#928743: wordpress: packaging of "wordpress" breaks page builder plugins

[nbi]

Source: wordpress
Version: 5.04
Severity: normal

Dear Maintainer,

   * What led up to the situation?
Installation of Wordpress 5.04 followed by attempted use of a page builder
plugin.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Installation of a page builder plugin (pick one, same failure mode for all
plugins that I tried) suceeded, but any attempt to edit failed to bring up the
graphical editor.

   * What was the outcome of this action?
   * What outcome did you expect instead?
Sucessful drag-and-drop visual editing.

Problem was solved by completely removing the Wordpress 5.04 package and
installing Wordpress 5.2 via the tarball from wordpress.org. This demonstrates
that something is wrong with the Debian packaging of 5.04.




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

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

Bug#928742: unworkable FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: unworkable
Version: 0.53-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

unworkable fails to cross build from source, because it uses the build
architecture pkg-config for discovering libbsd-overlay and thus fails
finding it. Making pkg-config substitutable is enough to make unworkable
cross buildable. Please consider applying the attached patch.

Helmut
--- unworkable-0.53.orig/GNUmakefile
+++ unworkable-0.53/GNUmakefile
@@ -30,8 +30,9 @@
 UNAME=$(shell uname)
 ifneq (, $(filter Linux GNU GNU/%, $(UNAME)))
 SRCS+=openbsd-compat/sha1.c
-LIBS+=$(shell pkg-config --libs libbsd-overlay)
-CFLAGS+=$(shell pkg-config --cflags libbsd-overlay)
+PKG_CONFIG?= pkg-config
+LIBS+=$(shell $(PKG_CONFIG) --libs libbsd-overlay)
+CFLAGS+=$(shell $(PKG_CONFIG) --cflags libbsd-overlay)
 else
 ifeq ($(UNAME),sunos)
 SRCS+=openbsd-compat/err.c

Bug#928026: security support for golang packages in Buster

[Shengjing Zhu]

Hi the security team,

On Thu, May 9, 2019 at 1:53 AM Moritz Muehlenhoff  wrote:
[...]
>
> There's the additional issue that ftp-master and security-master don't
> share tarballs; binNMUs are only possible for packages which are on
> security-master, so we'd need to do manual source uploads for every
> affected go package.
>

I probably lack of some historical background, have you ever think of
merging ftp-master and security-master?

-- 
Shengjing Zhu

Bug#928741: [pre-a] unblock: julia/1.0.4+dfsg-1

[Mo Zhou]

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

Please unblock package julia

(explain the reason for the unblock here)

The current version in testing is 1.0.3, I'm requesting
unblock for 1.0.4 (not-yet-released) because Julia's
1.0.X series is strictly a bug-fix-only branch. As per
upstream's call-for-community-testing announcement:

```
The release-1.0 branch on the Julia repository now contains the set of
commits we’re planning to tag as v1.0.4, the fourth patch release in the
1.0 series, which has long-term support. The list of commits included
since v1.0.3 is available here 7. As a patch release, it should be
strictly non-breaking for existing code and introduce no new features at
all, just bug fixes, documentation improvements, and performance
enhancements.
```
https://discourse.julialang.org/t/julia-1-0-4-testing-period/24051

This change is really only fixing bugs according to upstream commits:
```
| | Merge pull request #30954 from JuliaLang/backport-1.0.4
| * e5de4590bf fix #30679, call correct method for `invoke` calls in
`jl_invoke` fallback (#31845)
| * ef22206b0a Update Mozilla CA certificate store to latest
(01-23-2019) for libgit2 SSL. (#31029)
| * c1e1824327 Fix `-`, `conj`, and `conj!` for sparse matrices with
invalid entries in `nzval` (#31187)
| * 11b8f5991a fix #31758: out of bounds write in sparse broadcast
(#31763)
| * fa220625b7 minor fixes in multiplication with Diagonals (#31443)
| * 639de07d43 fix parse(ComplexF64, "inf")
| * a92bfbed6b inf or nan parsing should ignore leading spaces
| * 07279a357d Upgrade `libssh2` version to `1.8.2` (#31775)
| * 1d7087db99 Fix 29545: Implement unaliascopy for ReinterpretArray
(#30296)
| * 7fb55412bb Fix #30006, getindex accessing fields that might not
exist (#30405)
| * ec0cf97571 Pkg resolver update.
| * 5313c54fae Don't modify existing MDNodes in SIMDloop pass.
| * 707fdda67e Fix show_vector for long offset arrays with :limit=true
(#31642)
| * 9072796d61 Improve REPL completions (#30569)
| * ce6b3cb3d2 build: LDFLAGS needed for FreeBSD build (#31586)
| * a8758c48ef allow chop to take an empty string (#31312)
| * fc773de17a bump MPFR to 4.0.2 (#31041)
| * 65a22aa428 fix #29936, precompile should not assume UnionAlls have
stable addresses (#31047)
| * 0b651e0b77 Use XCode 8.3 for macOS on Travis (#30599)
| * 2cb487a5f3 Bump Pkg to 1.0.4.
| * 54a71f6e2b fix #30643, correctly propagate iterator traits through
Stateful (#30644)
| * 8ec20f467a Defensively fix patterns similar to #29983
| * fd1f187609 Fix SROA confusing new and old nodes
| * 63414f7038 Fix #30006, getindex accessing fields that might not
exist (#30405)
| * 92ecdfdbbc Fix use counts for mutable struct SROA
| * af03147f5d llvm: fix target triple (#30554)
| * 347bca30d9 fix #30394, an unsoundness in ml_matches (#30396)
| * ceccebd99b fix #30911, bug in `deepcopy` of `UnionAll` (#30930)
| * f24bf8b471 fix `at-everywhere using` in Distributed stdlib (#30804)
| * f9dddf8470 fix #30792, static param constraints between positional
and kw args (#30798)
| * 48f6ea7b2d update macOS icons to be less transparent (#30773)
| * 083bc82ce3 Handle :error and :invalid expressions gracefully in REPL
helpmode, (#30754)
| * b6b74132a8 SHA,tests: cleanup tempdir (#30655)
| * 2dc20f78af Add the scaled identity matrix to a random matrix to
avoid getting a singular matrix (#30576)
| * 7786f7856c fix `lambda-optimize-vars!` with complex assignment RHSs
(#30564)
| * bca2f420ad Add custom deserialize method for UmfpackLU to avoid
memory leak (#30425)
| * 4148b76322 generalize sparse matrix slicing to integer types
(#30319)
| * 0073e42fbc stacktrace: prevent OOB-error in sysimage lookup (#30369)
| * 7e8d9b2c34 fix reinterpret for 0-dimensional arrays (#30376)
| * 9d63c0f23c fix bug with max_values in union! (#30315)
| * 97add1c3d5 Use `JL_AArch64_crc` instead of `HWCAP_CRC32` (#30324)
|/  
* 5b7e8d9d4e Set VERSION to 1.0.4-pre (#30440)
* 099e826241 (tag: v1.0.3) Revert "Add test for llvmcall Function*
interface"
```

Full git diff-stat between 1.0.3 and 1.0.4 (proposed), plus my comments:
```
 .travis.yml|   2 +-
 VERSION|   2 +-
 base/abstractset.jl|   6 +-
 base/arrayshow.jl  |   7 +-
 base/compiler/ssair/passes.jl  |  30 +-
 base/deepcopy.jl   |   2 +-
 base/iterators.jl  |   5 +-
 base/parse.jl  |   2 +-
 base/range.jl  |   4 +-
 base/reinterpretarray.jl   |   5 +-
 base/strings/util.jl   |   3 +

base/* are important files implementing basic language
functionalities.
They received bug fixes.

 contrib/mac/app/julia.icns | Bin 122007 ->
226356 bytes
 

Bug#903635: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Arnaud Rebillout]

On Mon, 29 Apr 2019 07:46:22 +0700 Arnaud Rebillout
 wrote:
> Actually this was fixed upstream lately, and the fix is in Debian
> testing already. See
> https://github.com/docker/libnetwork/pull/2339#issuecomment-487207550
>
> There's still other iptables related bugs, the most outstanding being
> #903635. If this bug could be solved, then users could just run docker
> with `--iptables=false`. This is discussed upstream in the link above.
>
> In any case I will close this bug in the next changelog entry.
>

Hey, this message was intended for bug #921600, sorry for the confusion!

So, let's get back on the track: this very bug, #903635.

As I mentioned above, there's a discussion with a work in progress to
fix that upstream: https://github.com/docker/libnetwork/pull/2339

I don't think it will be ready in time for buster though. So I see two
solutions going forward:

- 1 Jonathan lower the severity of the bug so that it's not RC.

- 2 I import the patch from github, even though it's work in progress. I
will follow up and update the patch as soon as upstream release a proper
fix, and it will be included in a point release of buster.

If I don't get any feedback from you Jonathan in the following days,
I'll go for solution number 2 then.

Cheers

Bug#928371:

[Fabián Inostroza]

Please note that this issue is also present in evince 3.30.2 from the
testing repository.

Bug#921600: docker.io: use of iptables-legacy is incompatible with nftables-based iptables

[Arnaud Rebillout]

Actually this was fixed upstream lately, and the fix is in Debian testing 
already. See 
https://github.com/docker/libnetwork/pull/2339#issuecomment-487207550

There's still other iptables related bugs, the most outstanding being #903635. 
If this bug could be solved, then users could just run docker
with `--iptables=false`. This is discussed upstream in the link above.

Bug#928680: [openfortivpn] Since switching to buster openfortivpn can't connect to vpn anymore

[Michael Meier]

ok. I will upgrade my system, but it could take a bit. I'm on an island 
right now with internet connections of about 10kB/s...


meanwhile I managed to convince openfortivpn that the tunnel is working.

While it was waiting for ppp0 to become up, I configured ppp0 manually 
by executing:


ip addr add 192.168.0.231/24 peer 192.0.2.1/32 dev ppp0
ip link set up ppp0

openfortivpn afterwards set the routes correctly. And as least as far as 
I can see, then ppp0 and the routes are
configured exactly the same, as on the machine where it is working. But 
unfortunately no data goes through the tunnel.


But I'll try with an update (my last system update was about one week ago).

Log would look like that:

INFO:   Connected to gateway.
INFO:   Authenticated.
INFO:   Remote gateway has allocated a VPN.
INFO:   Got addresses: [192.168.0.231], ns [0.0.0.0, 0.0.0.0]
INFO:   negotiation complete
INFO:   Got addresses: [192.168.0.231], ns [0.0.0.0, 0.0.0.0]
INFO:   negotiation complete
INFO:   Got addresses: [192.168.0.231], ns [0.0.0.0, 0.0.0.0]
INFO:   negotiation complete
INFO:   Got addresses: [192.168.0.231], ns [0.0.0.0, 0.0.0.0]
INFO:   negotiation complete
INFO:   Got addresses: [192.168.0.231], ns [0.0.0.0, 0.0.0.0]
INFO:   negotiation complete
< at that moment I configured ppp0 manually >
INFO:   Interface ppp0 is UP.
INFO:   Setting new routes...
INFO:   Tunnel is up and running.


On 08.05.19 22:05, Daniel Echeverry wrote:

tags 928680 + moreinfo unreproducible
severity 928680 normal
thanks

Hi!

El mié., 8 de may. de 2019 a la(s) 14:15, Michael Meier (c...@rmm.li 
) escribió:


Package: openfortivpn
Version: 1.8.1-1
Severity: normal

I've installed the fortivpn package in debian stable (stretch), and
managed to get it working with a vpn connection.
Somewhen I updated my System to buster and now realized that
openfortivpn can't connect to the vpn anymore. While another computer
which is still running on stretch connects to the same vpn without
any
problems with exactly the same config parameters. Also
openfortivpn and
ppp are the same version on both systems.
As it seems it doesn't manage to configure the ppp interface
correctly.
Maybe in buster something changed the way interfaces are
configured? No
idea.

Thanks for your report!! Unfortunately, I can't reproduce this bug, I 
tried openfortivpn package in 2 differents machines with buster and 
works fine, Could you upgrade your system? I think that you dont have 
the last versions of dependencies.


Regards

--
Daniel Echeverry
Debian Developer
https://wiki.debian.org/DanielEcheverry
Linux user: #477840
GPG Fingerprint:
D0D0 85B1 69C3 BFD9 4048 58FA 21FC 2950 4B52 30DB

Bug#928740: unblock: libqtxdg/3.3.1-2

[Alf Gaida]

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

Please unblock package libqtxdg

Avoid freeze for DBusActivatable apps, this is mostly visable for the panel
at startup and applications started from menu, pcmanfm-qt application folder 
or lxqt-runner. Without the patch the application in charge is frosen up to
25-30s. 

>From 6a5d3c26c583613e5c861ab4fafbb418ce82a138 Mon Sep 17 00:00:00 2001
From: Alf Gaida 
Date: Thu, 9 May 2019 17:57:24 +0200
Subject: [PATCH] Upstream patch: Avoid freeze for DBusActivatable apps
 (Closes: #928721)

---
 debian/changelog   |   6 +
 debian/patches/avoid-dbus-freeze.patch | 164 +
 debian/patches/series  |   1 +
 3 files changed, 171 insertions(+)
 create mode 100644 debian/patches/avoid-dbus-freeze.patch
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index 86b2be2..41a9c2f 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+libqtxdg (3.3.1-2) unstable; urgency=medium
+
+  * Upstream patch: Avoid freeze for DBusActivatable apps (Closes: #928721)
+
+ -- Alf Gaida   Thu, 09 May 2019 17:57:01 +0200
+
 libqtxdg (3.3.1-1) unstable; urgency=medium
 
   * Cherry-picked new upstream-release 3.3.1.
diff --git a/debian/patches/avoid-dbus-freeze.patch 
b/debian/patches/avoid-dbus-freeze.patch
new file mode 100644
index 000..e90e67b
--- /dev/null
+++ b/debian/patches/avoid-dbus-freeze.patch
@@ -0,0 +1,164 @@
+From bccc6c4030a601892847e9a1495142a1938d1a58 Mon Sep 17 00:00:00 2001
+From: Palo Kisa 
+Date: Tue, 9 Apr 2019 12:36:11 +0200
+Subject: [PATCH] xdgdesktopfile: Avoid freeze for DBusActivatable apps
+
+For case when the DBusActivatable application is unresponsive the
+startDetached() can block for a long time (the Qt default 25s DBus
+timeout). Blocking can't be avoided while using QDBusInterface, because
+the object can block directly in its constructor.
+
+So we use the generated interface class and set the timeout for the DBus
+call to 1500ms (can be overridden env variable QTXDG_DBUSACTIVATE_TIMEOUT).
+
+See also: https://bugreports.qt.io/browse/QTBUG-75016
+---
+ src/qtxdg/CMakeLists.txt  | 10 +
+ .../dbus/org.freedesktop.Application.xml  | 25 +++
+ src/qtxdg/xdgdesktopfile.cpp  | 43 ---
+ 3 files changed, 72 insertions(+), 6 deletions(-)
+ create mode 100644 src/qtxdg/dbus/org.freedesktop.Application.xml
+
+diff --git a/src/qtxdg/CMakeLists.txt b/src/qtxdg/CMakeLists.txt
+index f75b5a5..60ba48b 100644
+--- a/src/qtxdg/CMakeLists.txt
 b/src/qtxdg/CMakeLists.txt
+@@ -1,3 +1,5 @@
++set(CMAKE_INCLUDE_CURRENT_DIR ON)
++
+ set(QTX_LIBRARIES Qt5::Widgets Qt5::Xml Qt5::DBus)
+ 
+ set(libqtxdg_PUBLIC_H_FILES
+@@ -50,10 +52,18 @@ set(libqtxdg_CPP_FILES
+ xdgmimetype.cpp
+ )
+ 
++QT5_ADD_DBUS_INTERFACE(DBUS_INTERFACE_SRCS
++dbus/org.freedesktop.Application.xml
++application_interface
++)
++
++set_property(SOURCE ${DBUS_INTERFACE_SRCS} PROPERTY SKIP_AUTOGEN ON)
++
+ add_library(${QTXDGX_LIBRARY_NAME} SHARED
+ ${libqtxdg_PUBLIC_H_FILES}
+ ${libqtxdg_PRIVATE_H_FILES}
+ ${libqtxdg_CPP_FILES}
++${DBUS_INTERFACE_SRCS}
+ )
+ 
+ target_link_libraries(${QTXDGX_LIBRARY_NAME}
+diff --git a/src/qtxdg/dbus/org.freedesktop.Application.xml 
b/src/qtxdg/dbus/org.freedesktop.Application.xml
+new file mode 100644
+index 000..945ba9e
+--- /dev/null
 b/src/qtxdg/dbus/org.freedesktop.Application.xml
+@@ -0,0 +1,25 @@
++http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd;>
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
++
+diff --git a/src/qtxdg/xdgdesktopfile.cpp b/src/qtxdg/xdgdesktopfile.cpp
+index c22d57d..5fa7604 100644
+--- a/src/qtxdg/xdgdesktopfile.cpp
 b/src/qtxdg/xdgdesktopfile.cpp
+@@ -30,6 +30,7 @@
+ #include "xdgdesktopfile_p.h"
+ #include "xdgdirs.h"
+ #include "xdgicon.h"
++#include "application_interface.h"
+ 
+ #include 
+ #include 
+@@ -100,6 +101,27 @@ QString (QString& str);
+ QString (QString& str);
+ void loadMimeCacheDir(const QString& dirName, QHash > & cache);
+ 
++namespace
++{
++//! Simple helper for getting timeout for starting of DBus activatable 
applications
++class DBusActivateTimeout
++{
++private:
++int mTimeoutMs;
++DBusActivateTimeout()
++{
++bool ok;
++mTimeoutMs = qgetenv("QTXDG_DBUSACTIVATE_TIMEOUT").toInt();
++if (!ok)
++mTimeoutMs = 1500;
++}
++static DBusActivateTimeout msInstance;
++public:
++static const DBusActivateTimeout & instance() { return msInstance; }
++operator int() const { return mTimeoutMs; }
++};
++DBusActivateTimeout 

Bug#928739: geogebra: poor integration with KDE

[gcab_dzan]

Package: geogebra
Version: 4.0.34.0+dfsg1-7
Severity: normal

Dear Maintainer,

   I installed Geogebra on Buster with KDE and just at opening  I noticed that
 characters and graphics display was not up to that of previous versions (I am 
using
Geogebra since long).
   Then on the Algebra pane the properties of the objects are not accessible 
with the right
   click, but only with the double click (but not the Free Objects) or from the 
Edit menu, which presents the full list
   of objects.
   There might be other inconvenients I did not went through yet.
   Thanks for uor attention and work
   Giuliano Cabrele


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

Kernel: Linux 4.19.0-4-amd64 (SMP w/12 CPU cores)
Kernel taint flags: TAINT_CRAP, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages geogebra depends on:
ii  default-jre [java9-runtime] 2:1.11-71
ii  libcommons-collections3-java3.2.2-2
ii  libcommons-math-java2.2-7
ii  libfreehep-graphics2d-java  2.1.1-6
ii  libfreehep-graphicsio-emf-java  2.1.1-emfplus+dfsg1-4
ii  libfreehep-graphicsio-java  2.1.1-5
ii  libfreehep-graphicsio-pdf-java  2.1.1+dfsg-3
ii  libfreehep-graphicsio-svg-java  2.1.1-5
ii  libfreehep-io-java  2.0.2-6
ii  libfreehep-util-java2.0.2-7
ii  libfreehep-xml-java 2.1.2+dfsg1-5
ii  libjfugue-java  4.0.3-4
ii  libjlatexmath-java  1.0.7-3
ii  librhino-java   1.7.7.1-1
ii  mathpiper   0.81f+svn4469+dfsg3-3
ii  openjdk-11-jre [java9-runtime]  11.0.3+1-1

geogebra recommends no packages.

Versions of packages geogebra suggests:
ii  cups  2.2.10-6

-- no debconf information

Bug#920374: affects 920374

[Holly McCoy]

0 Adrian Bunk On Wed, 30 Jan 2019 13:05:56 +020 wrote:
> affects 920374 python-openssl
> thanks
> 
> 
> 

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

[Nicholas D Steeves]

On Thu, May 09, 2019 at 07:35:20AM +, Dmitry Bogatov wrote:
> 
> [2019-05-07 22:48] Nicholas D Steeves 
> > Package: sponsorship-requests
> > Severity: wishlist
> > Control: block 872873 by -1
> >
> > I am looking for a sponsor for my package "emacs-neotree".  Neotree is
> > a very popular Emacs addon on MELPA (Emacs addon repository), and is
> > at the 99th percentile for MELPA unstable, and the 98th for MELPA stable.
> >
> 
> Everything super-nice, just uploaded. One minor request: on next upload,
> add field "Upstream-Contact" into debian/copyright.

Thank you Dmitry! Wow that was fast :-)

Done, I've identified the maintainer apparent and have added him as
Upstream-Contact.  Also, I realised that the long description was
missing this useful bit of info:

  NeoTree shows a file system tree relative to the users' $HOME, where
  both Dired and Speedbar default to showing the contents of the
  current directory.  Thus it provides a hierarchical rather than a
  modal view.

Previously I had been assuming that hierarchical was an assumption of
the target audience, but that doesn't answer the question "how is this
different?" for long-time Emacs users ;-)  Thanks to Anarcat for
asking something along the lines of "but how is neotree different?"

Cheers,
Nicholas


signature.asc
Description: PGP signature

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

[Michael Biebl]

Am 10.05.19 um 00:55 schrieb Cyril Brulebois:
> Hi,
> 
> Michael Biebl  (2019-05-08):
>> Control: reassign -1 netcfg
> 
> Thanks for forwarding this.
> 
>> Am 08.05.19 um 14:12 schrieb Yannick Schinko:
 I assume this file is created by the debian installer, so you
 should probably talk to them. See

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

 I would guess that the netcfg part is the most likely package.
>>>
>>> So you suggest to recreate this report on the netcfg package instead?
>>
>> If netcfg is the component responsible for creating that file, yes.
>> I'm not sure though, which is why I suggested to contact the
>> debian-b...@lists.debian.org first.
>>
>> You don't need to file or recreate the bug report btw, we can just
>> re-assign it.
>>
>> Thinking about it, I'll just do this now and let the debian-installer
>> maintainers re-assign as needed.
> 
> netcfg looks like a good candidate indeed.
> 
> Yannick, it'd be great to see the installer's syslog, that should have
> been stored under /var/log/installer.

It would probably also be a good idea to share the "Wired connection 1"
config file.
I'm only guessing here, but I assume Yannick wants the connection
profile to be bound to a certain interface. Connection profiles can
apply to multiple  interfaces given the conditions in the connection
profile are met.

If you want to bind a connection profile to a certain hardware
interface, you can e.g. use mac-address=.
For a wifi interface, this would be:

[wifi]
mac-address=00:23:5a:47:1f:71

for an ethernet connection:

[802-3-ethernet]
mac-address=00:23:5a:47:1f:71


See nm-settings-keyfile and nm-settings.

I'm undecided whether setting mac-address= by default is a good idea 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#928738: printer-driver-cups-pdf Still Produces PDF Files that Lack Searchable Text and are Unusable with pdftotext

[Neil Ormos]

Package: printer-driver-cups-pdf
Version: 3.0.1-5
Severity: important

Dear Maintainer,

In prior bug reports, users complained that CUPS-PDF or printer-driver-cups-pdf 
produced PDF files in which text was represented in image format, or was not 
searchable.

In a message posted

  "Thu, 09 Mar 2017 13:40:21 +", 

closing bugs 658004, 813618, 847462, and 857165, there was a reference to 
printer-driver-cups-pdf_3.0.1-3, and in another message there was a suggestion 
that the problem is fixed in that version.

I have installed printer-driver-cups-pdf_3.0.1-5 (the current version 
distributed in Buster), and it appears that *whatever* is stored in the PDF 
files produced by printer-driver-cups-pdf, it's not searchable text.  Also, 
when these files are processed by pdftotext, the results do not contain 
recognizable text.

This was not a problem with the cups-pdf version 2.5.0-16 in Squeeze.

I tested using Firefox 44.0b3 to print an extremely simple HTML page to the 
CUPS PDF "driver".  (That particular ancient version of Firefox runs in both 
Squeeze and Stretch.)

Can this be fixed, short of installing a non-Debian version of CUPS-PDF-to-PDF 
or the like, such as that advertised at

  https://github.com/alexivkin/CUPS-PDF-to-PDF

?

Thank you.


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

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

Versions of packages printer-driver-cups-pdf depends on:
ii  cups2.2.1-8+deb9u2
ii  cups-client 2.2.1-8+deb9u2
ii  ghostscript 9.26a~dfsg-0+deb9u1
ii  libc6   2.24-11+deb9u3
ii  libcups22.2.1-8+deb9u2
ii  libpaper-utils  1.1.24+nmu5

printer-driver-cups-pdf recommends no packages.

Versions of packages printer-driver-cups-pdf suggests:
ii  system-config-printer  1.5.7-3

-- no debconf information

Bug#928737: RFS: libetpan/1.9.3-2~bpo9+1 [NMU] -- Backport of libetpan for Debian 9 Stretch

[Shaun Johnson]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my backport package "libetpan"

 * Package name: libetpan
   Version : 1.9.3-2~bpo9+1
   Upstream Author : Ricardo Mones 
 * URL : https://github.com/dinhviethoa/libetpan
 * License : BSD-3-Clause
   Section : mail

It builds those binary packages:

  libetpan17 - mail handling library
  libetpan-dev - mail handling library - development files
  libetpan-doc - mail handling library - API documentation
  libetpan-dbg - debugging symbols for libetpan

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

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


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

dget -x \

https://mentors.debian.net/debian/pool/main/libe/libetpan/libetpan_1.9.3-2~bpo9+1.dsc

More information about libetpan can be obtained from

  https://github.com/dinhviethoa/libetpan

Changes since the last upload:

  Update for new upstream version 1.9.3-2 with new patch for critical
  SSL timeout issue (Closes: #927709). 

  NOTE: same bug (#927709) appears to exist in current 'stable' version
  of libetpan (1.6-3)


Regards,

   Shaun A. Johnson

-- 
"Catch the Magic of Linux..."
www.linuxmagic.com

Shaun Johnson
Development Services - LinuxMagic Inc.

A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" is a Registered TradeMark of Wizard Tower TechnoServices
Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential 
and intended solely for the use of the individual or entity 
to which they are addressed. Please note that any views or 
opinions presented in this email are solely those of the author 
and are not intended to  represent those of the company.

Bug#928736: initramfs-tools: With plymouth print misleading resuming from hibernation

[Cesare Leonardi]

Package: initramfs-tools
Version: 0.133
Severity: normal

When plymouth is installed, every time I power on my notebook the following
message is printed on the screen:
Resuming from hibernation

But I'm not resuming from hibernation, I'm doing a regular boot from power
off.
Is it possible to show that message only when actually resuming? Or, if it
not feaseable, perhaps it's better to remove it completely.

I've verified that this message appears when RESUME=auto (my current
setup) or when a swap device is specified. It goes away with "none".

Cesare.


-- Package-specific info:
-- initramfs sizes
-rw-r--r-- 1 root root 28M Sep  1  2018 /boot/initrd.img-4.17.0-3-amd64
-rw-r--r-- 1 root root 29M Dec 16 14:29 /boot/initrd.img-4.18.0-3-amd64
-rw-r--r-- 1 root root 49M Apr 16 06:15 /boot/initrd.img-4.19.0-4-amd64
-rw-r--r-- 1 root root 50M May  9 11:17 /boot/initrd.img-4.19.0-5-amd64
-- /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-4.19.0-5-amd64 root=/dev/mapper/etna2014-root ro quiet 
splash i915.fastboot=1

-- /proc/filesystems
btrfs
ext3
ext2
ext4
vfat
fuseblk

-- lsmod
Module  Size  Used by
fuse  122880  1
uas28672  0
usb_storage73728  1 uas
rfcomm 86016  4
cls_u3224576  10
sch_htb24576  1
ifb16384  0
cmac   16384  1
bnep   24576  2
ctr16384  6
ccm20480  9
ip6t_rpfilter  16384  1
nls_ascii  16384  1
nls_cp437  20480  1
vfat   20480  1
fat86016  1 vfat
nft_chain_nat_ipv6 16384  4
nf_nat_ipv616384  1 nft_chain_nat_ipv6
nft_chain_route_ipv616384  1
ath3k  20480  0
btusb  53248  0
ip6t_REJECT16384  1
intel_rapl 24576  0
nf_reject_ipv6 16384  1 ip6t_REJECT
x86_pkg_temp_thermal16384  0
intel_powerclamp   16384  0
btrtl  16384  1 btusb
coretemp   16384  0
arc4   16384  2
btbcm  16384  1 btusb
mei_wdt16384  0
btintel24576  1 btusb
kvm_intel 245760  0
ath9k 135168  0
ath9k_common   20480  1 ath9k
bluetooth 643072  32 btrtl,btintel,btbcm,bnep,ath3k,btusb,rfcomm
ipt_rpfilter   16384  1
ath9k_hw  483328  2 ath9k_common,ath9k
snd_hda_codec_hdmi 57344  1
snd_hda_codec_conexant24576  1
uvcvideo  118784  0
kvm   724992  1 kvm_intel
videobuf2_vmalloc  16384  1 uvcvideo
snd_hda_codec_generic86016  1 snd_hda_codec_conexant
ath36864  3 ath9k_common,ath9k,ath9k_hw
mac80211  815104  1 ath9k
videobuf2_memops   16384  1 videobuf2_vmalloc
videobuf2_v4l2 28672  1 uvcvideo
irqbypass  16384  1 kvm
crct10dif_pclmul   16384  0
videobuf2_common   53248  2 videobuf2_v4l2,uvcvideo
nft_chain_nat_ipv4 16384  4
nf_nat_ipv416384  1 nft_chain_nat_ipv4
crc32_pclmul   16384  0
nf_nat 36864  2 nf_nat_ipv6,nf_nat_ipv4
videodev  212992  3 videobuf2_v4l2,uvcvideo,videobuf2_common
ghash_clmulni_intel16384  0
snd_hda_intel  45056  8
media  45056  2 videodev,uvcvideo
snd_hda_codec 151552  4 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel
efi_pstore 16384  0
intel_cstate   16384  0
drbg   28672  1
asus_nb_wmi28672  0
snd_hda_core   94208  5 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec
intel_uncore  135168  0
ansi_cprng 16384  0
cfg80211  761856  4 ath9k_common,ath9k,ath,mac80211
joydev 24576  0
asus_wmi   32768  1 asus_nb_wmi
intel_rapl_perf16384  0
snd_hwdep  16384  1 snd_hda_codec
sparse_keymap  16384  1 asus_wmi
snd_pcm   114688  5 
snd_hda_codec_hdmi,snd_hda_intel,snd_hda_codec,snd_hda_core
nft_chain_route_ipv416384  1
efivars20480  1 efi_pstore
serio_raw  16384  0
pcspkr 16384  0
ecdh_generic   24576  2 bluetooth
intel_pch_thermal  16384  0
sg 36864  0
snd_timer  36864  1 snd_pcm
iTCO_wdt   16384  0
iTCO_vendor_support16384  1 iTCO_wdt
mei_me 45056  1
mei   118784  3 mei_wdt,mei_me
snd94208  23 
snd_hda_codec_generic,snd_hda_codec_conexant,snd_hda_codec_hdmi,snd_hwdep,snd_hda_intel,snd_hda_codec,snd_timer,snd_pcm
processor_thermal_device16384  0
rfkill 28672  6 asus_wmi,bluetooth,cfg80211
soundcore  16384  1 snd
intel_soc_dts_iosf 16384  1 processor_thermal_device
battery   

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

[Cyril Brulebois]

Hi,

Michael Biebl  (2019-05-08):
> Control: reassign -1 netcfg

Thanks for forwarding this.

> Am 08.05.19 um 14:12 schrieb Yannick Schinko:
> >> I assume this file is created by the debian installer, so you
> >> should probably talk to them. See
> >>
> >> https://qa.debian.org/developer.php?email=debian-boot%40lists.debian.org
> >>
> >> I would guess that the netcfg part is the most likely package.
> > 
> > So you suggest to recreate this report on the netcfg package instead?
> 
> If netcfg is the component responsible for creating that file, yes.
> I'm not sure though, which is why I suggested to contact the
> debian-b...@lists.debian.org first.
> 
> You don't need to file or recreate the bug report btw, we can just
> re-assign it.
> 
> Thinking about it, I'll just do this now and let the debian-installer
> maintainers re-assign as needed.

netcfg looks like a good candidate indeed.

Yannick, it'd be great to see the installer's syslog, that should have
been stored under /var/log/installer.

(Please compress it.)


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


signature.asc
Description: PGP signature

Bug#928735: u-boot-menu: Avoid hard-coding "vmlinuz"

[Vagrant Cascadian]

Package: u-boot-menu
Severity: normal
Version: 3
Tags: patch

Some architectures which might make use of u-boot-menu do not have
kernel files matching "vmlinuz" (e.g. riscv64 has "vmlinux").

The attached patch uses "linux-version list --paths" to output the path
of each versioned kernel, which outputs the matching kernel filenames.

live well,
  vagrant

From f33424de3c643127d4f41284f9516ed7a54846af Mon Sep 17 00:00:00 2001
From: Vagrant Cascadian 
Date: Thu, 9 May 2019 14:53:04 -0700
Subject: [PATCH] Use "linux-version list --paths" to avoid hard-coding
 "vmlinuz" kernels.

---
 u-boot-update | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/u-boot-update b/u-boot-update
index 9dd8b0e..bd4ccd2 100755
--- a/u-boot-update
+++ b/u-boot-update
@@ -132,7 +132,7 @@ timeout ${U_BOOT_TIMEOUT}
 "
 
 # Find linux versions
-_VERSIONS="$(linux-version list | linux-version sort --reverse)"
+_VERSIONS=$(linux-version list --paths | linux-version sort --reverse | sed -e 's,.*/boot/,,g')
 
 # Find boot directory as seen in u-boot, and path prefix while in linux
 if [ "$(stat --printf %d /)" = "$(stat --printf %d /boot)" ]
@@ -147,9 +147,11 @@ else
 fi
 
 
-for _VERSION in ${_VERSIONS}
+for _KERNEL in ${_VERSIONS}
 do
-	echo "P: Writing config for /boot/vmlinuz-${_VERSION}..."
+	# Strip kernel prefix to derive version.
+	_VERSION=${_KERNEL#*-}
+	echo "P: Writing config for ${_KERNEL}..."
 
 	_NUMBER="${_NUMBER:-0}"
 	_ENTRY="${_ENTRY:-1}"
@@ -181,7 +183,7 @@ do
 
 label l${_NUMBER}
 	menu label ${U_BOOT_MENU_LABEL} ${_VERSION}
-	linux ${_BOOT_DIRECTORY}/vmlinuz-${_VERSION}
+	linux ${_BOOT_DIRECTORY}/${_KERNEL}
 	${_INITRD}
 	${_FDT}
 	append ${U_BOOT_ROOT} ${U_BOOT_PARAMETERS}"
@@ -196,7 +198,7 @@ label l${_NUMBER}
 
 label l${_NUMBER}r
 	menu label ${U_BOOT_MENU_LABEL} ${_VERSION} (rescue target)
-	linux ${_BOOT_DIRECTORY}/vmlinuz-${_VERSION}
+	linux ${_BOOT_DIRECTORY}/${_KERNEL}
 	${_INITRD}
 	${_FDT}
 	append ${U_BOOT_ROOT} $(echo ${U_BOOT_PARAMETERS} | sed -e 's| quiet||') single
-- 
2.20.1



signature.asc
Description: PGP signature

Bug#925941: nvenc not in ffmpeg

[Chris]

On Thu, 28 Mar 2019 16:16:32 -0600 miltonshane...@gmail.com wrote:
> Package: FFMPEG
> Version: 4.1.1-1 and others
> 
> When running command ffmpeg -codecs nvenc is not showing in h264  or
> nvenc_hevc.  This is supported in Debian 9 but not Buster/Testing.
> 
> I suggest enabling this duing build as it is a widly used feature
> along with vaapi
> 
> I am using Debian Linux Buster/Testing with nvidia driver stack in
> Testing.

This is also the case in Sid. Would be extremely helpful to have this
built with nvenc support.
The version in Sid seems to have VAAPI support, though.

Bug#928734: u-boot-menu: Vcs-* does not contain current version

[Vagrant Cascadian]

Package: u-boot-menu
Version: 3
Severity: normal

In debian/control:

  Vcs-Git: https://salsa.debian.org/debian/u-boot-menu.git
  Vcs-Browser: https://salsa.debian.org/debian/u-boot-menu

But that only contains commits from version 2.

Please update the git repository or the Vcs-* headers to match current
status.

Thanks!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#916594: [Pkg-mozext-maintainers] Bug#916594: Bug#916594: Bug#916594: Bug#916594: webext-umatrix: Can not load configuration from backup

[Antoine Beaupré]

On 2019-02-23 15:20:14, Antoine Beaupré wrote:
> On 2019-02-23 20:04:00, Ximin Luo wrote:
>> Antoine Beaupré:
>>> [..]
>>> To reproduce the problem, I do the following:
>>> 
>>>  1. uninstall ("remove" in the addons menu) uMatrix
>>>  2. quit Firefox
>>>  3. apt install webext-umatrix
>>
>> Did you do the workaround for 919557 that I mentioned?
>
> I did and, as I said earlier, it had no effect.

So I could reproduce this again in my normal profile, but an important
data point is that I can't reproduce in a *clean* profile. So I suspect
it's something to do with my configuration.

I've tried to bisect my extension list to figure out where the problem
was, suspectig there was an incompatibility with some other extension. I
was happy and surprised to find out that I could actually use the debian
packaged extension when all my extensions were disabled... and when I
re-enabled them all back again, things still worked!

So TL;DR: there's a workaround, which is to:

 1. disable all extensions
 2. backup the umatrix extension
 3. remove it from the add-ons
 4. install the `webext-umatrix` package
 5. restore the umatrix settings
 6. re-enable all extensions

Maybe this will blow up in my face soon, but so far so good! ;)

a.

-- 
Your injured body has become the burden of your digital soul.
- Yin Aiwen, 2013, The Massage is the Medium

Bug#911884: Info received (Atril fail to zoom for large pdf)

[Richard Eliáš]

Hi vangelis,
But bug stays unresolved - zooming more than 175% fails, but there are more 
zoom levels - 200, 300, 400, 800%.

Bug#928733: RFS: pysword/0.2.6-1 [ITP]

[Bastian Germann]

Package: sponsorship-requests
Severity: wishlist

Hi,

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

 * Package name: pysword
   Version : 0.2.6-1
   Upstream Author : Tomas Groth
 * URL : https://gitlab.com/tgc-dk/pysword/
 * License : Expat
   Section : python

It builds those binary packages:

  python3-pysword - A Python library for reading SWORD Bibles

If it is sponsored the Debian package openlp will depend on
python3-pysword in its next major version.

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

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


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

  dget -x
https://mentors.debian.net/debian/pool/main/p/pysword/pysword_0.2.6-1.dsc

More information about pysword can be obtained from:
https://gitlab.com/tgc-dk/pysword/

Regards,
Bastian Germann

Bug#928465: stretch-pu: package linux/4.9.168-1

[Adam D. Barratt]

Control: tags -1 + confirmed

Hi,

Sorry for not picking this up sooner.

On Sun, 2019-05-05 at 11:28 +0200, Salvatore Bonaccorso wrote:
> The last linux upload via the stretch point release unfortunately
> uncovered #928125, easily triggerble when forcing the kernel to scan
> the partition table on a newly created loop device.
> 
> In the upstream development of the 4.9 series between the 4.9.140
> upload in the previous stretch point release, some backports to
> changes related to the loopback were  again later reverted due to
> regressions.
> 
> One commit though was keept up to 4.9.168, which relates to the
> thread
> in 
> https://lore.kernel.org/stable/20190320125806.gd9...@quack2.suse.cz/
> .
> 
> I seek input/advice/opinion from you stable release managers: Do you
> want to issue a SUA and fast-track a fix for this issue via
> stretch-updates?
> 
> For completeness, the isolated revert is at
> https://salsa.debian.org/kernel-team/linux/commit/5f66def673547b7d1e7
> a841937fbd0ab10a925a0

Let's go with the quicker fix - hopefully the SUA can get released over
the weekend.

Regards,

Adam

Bug#928014: nmu: wine-development_4.2-4

[Jens Reyer]

Hi Paul, hi wine-team

On 09.05.19 12:26, Paul Gevers wrote:
> retitle 928014 please rebuild against unicode-data 12.1.0~pre1-2
> reassign 928014 wine-development
> usertag 928014 unicode-data-12
> thanks
> 
> On Fri, 26 Apr 2019 10:23:17 +0100 Alastair McKinstry
>  wrote:
>> Package: release.debian.org
>> Severity: normal
>> User: release.debian@packages.debian.org
>> Usertags: binnmu
>>
>> nmu wine-development_4.2-4 . ANY . unstable . -m "rebuild against 
>> unicode-data 12.1.0~pre1-2"
> 
> This package is arch:all. Somebody needs to do a source upload.

The files built with unicode-data are in arch-specific packages, so a
binnmu should work.

However this would be the first binnmu for the current package layout
(Wine's package relationships are a bit tricky with its internal
versioned cross-architecture relationships).  So although back then I
took great care to get it right and successfully tested a binnmu
locally, it was never verified for real.

On the other side binnmu version numbers are ugly ;)

So what do you think, binnmu or new source upload?

Greets
jre

Bug#420152: texlive-base-bin: texdoc: Problems displaying files without extension

[Hilmar Preuße]

On 20.04.07 13:19, Frank Küster wrote:

Hi Frank,

> $ texdoc pstricks-add/Changes
> Can't find documentation for `pstricks-add/Changes'
> $ texdoc -s pstricks-add/Changes.gz
> /usr/share/texmf-texlive/doc/generic/pstricks-add/Changes.gz
> 
> aha
> 
> $ texdoc pstricks-add/Changes.gz
> /usr/bin/texdoc: line 214: 
> cleanup/usr/share/texmf-texlive/doc/generic/pstricks-add/Changes: No such 
> file or directory
> 
I'm failing to reproduce this bug. Can we close it?

Hilmar
-- 
sigfault
#206401 http://counter.li.org



signature.asc
Description: OpenPGP digital signature

Bug#927711: CVE-2019-10044

[Moritz Mühlenhoff]

On Sun, Apr 21, 2019 at 10:18:12PM +0200, Moritz Muehlenhoff wrote:
> Package: telegram-desktop
> Severity: grave
> Tags: security
> 
> This was assigned CVE-2019-10044 and is claimed to be fixed in 1.5.12:
> https://github.com/blazeinfosec/advisories/blob/master/telegram-advisory.txt

What's the status? Has upstream been contacted for an isolated fix, are
you planning to address this for buster?

Cheers,
   Moritz
> 

Bug#670585: "ok hat location is writable"

[Tito]

On 5/9/19 9:35 AM, Dmitry Bogatov wrote:


[2019-05-08 14:57] Tito 

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

Collegues, I need help with evaluating proposed change.


Hi,
I guess if it is a one partition only setup /var/log will
exist as soon as as root is switched from initrd and/or
remounted read-write, if it is a multi-partition setup
with separated partitions for /tmp, /home and /var,
/var will exist as soon as root is switched from
initrd but /var/log will exist only after /var is mounted.


So it means, that check 'test -w "${FSCK_LOGFILE}"' that you proposed is
only meaningful after 'mountall', but not in 'checkfs'. So I have to
keep more vague

"Log is being saved in ${FSCK_LOGFILE} if that location is writable"

Did I miss something?


Hi,
No you didn't. An alternative approach could be:

test if we are in a single-partition environment
and /var/log/ exists, maybe it is not writable yet
but we are optimistic that we can write to it

if test -d `dirname ${FSCK_LOGFILE}` ; then
"Log is being saved in ${FSCK_LOGFILE}"
else
/var/log doesnt' exist yet and we really cannot say
if it ever will, stay more vague
"Trying to save log to ${FSCK_LOGFILE}"
fi

but that is only cosmetic.

The KISS solution would be to use always

"Trying to save log to ${FSCK_LOGFILE}"

and so if the user really needs to read the file
he will go to see if it is there, if the user
doesn't care it makes no difference if it was
"being saved" or "Trying to be saved".

Ciao,
Tito






 



  

Bug#928732: CVE-2019-11460

[Moritz Muehlenhoff]

Source: gnome-desktop3
Severity: important
Tags: security

This was assigned CVE-2019-11460:
https://gitlab.gnome.org/GNOME/gnome-desktop/issues/112

Cheers,
Moritz
 

Bug#928394: RFS: freetype-py/2.1.0.post1-1 [ITP]

[Bastian Germann]

Hi Dmitry,

I have changed that and also made the smoke test run.

Cheers,
Bastian

Am 09.05.19 um 09:35 schrieb Dmitry Bogatov:
> [2019-05-06 01:31] Bastian Germann 
> 
>> Thanks for coming back to me. I have fixed the things you pointed out.
> 
> In debian/rules you write ${DEB_VERSION_UPSTREAM} -- note "{", not "(".
> Make uses $(foo) syntax for variable access. Build still successfull,
> but, well, please double check this moment.
> 
> Also, you have no autopkgtest. I heard, default one for python could be
> added with following in "debian/control".
> 
>   Testsuite: autopkgtest-pkg-python
> 

Bug#921952: [Pkg-sass-devel] Bug#921952: Don't include in buster without proper commitment to update in stable

[Moritz Mühlenhoff]

Hi Aljoscha,

On Wed, Apr 17, 2019 at 12:23:54PM +0200, Jonas Smedegaard wrote:
> Quoting Aljoscha Lautenbach (2019-04-16 22:27:47)
> > > @Aljoscha: Thanks for your initial work and - more so - for 
> > > committing to help generally looking after these security issues in 
> > > libsaass.
> > 
> > > Due to the expansion of the libsass team with Aljoscha, I am 
> > > lowering severity of this bugreport.
> > 
> > Just in case that was not clear in my initial message, that is indeed 
> > the intention. On any given week I can spend 0.5 to 4 hours on this, 
> > so this will not be an instantaneous change, but a slow and steady 
> > effort.
> > 
> > I have continued to update the little CVE table I sent earlier, and I 
> > will start to update and file bugs accordingly soon (where "soon" ~= 3 
> > weeks, due to upcoming vacation).

Please work through the security tracker, at least for several of the
2017 they are probably already fixed in buster's version.
https://security-tracker.debian.org/tracker/source-package/libsass 

You can also submit updates yourself via
https://security-tracker.debian.org/tracker/data/report 

Cheers,
Moritz

Bug#928390: Acknowledgement (unable to upgrade if previous version was not operational)

[Eduard Bloch]

On Fri, 3 May 2019 18:27:30 +0200 Gianfranco Costamagna 
 wrote:
> control: severity -1 important
>
> On Fri, 3 May 2019 16:12:40 +0200 Eduard Bloch  wrote:
> > Control: retitle 928390 unable to remove/upgrade where installed version is 
> > not operational
> > Control: severity 928390 grave
>
> please don't play the severity game, thanks.

Ok. But still, a package with such unreliable purge function is IMHO just 
broken.

> VBoxManage: error: The installer failed with exit code 1: 
> VBoxExtPackHelperApp: error: The owner is not root: '/usr/lib'
>
> did you read the error message?

Yes. But I forgot it when the upgrade problem has driven me mad.

> please tell me the output of
> ls -l /usr/

I guess you mean ls -ld. And yes, that message was correct, it
suddenly belonged to a local user (apparently a gift from an incorrect
installation script, and I found more stuff in /usr with similar wrong
permissions which is fixed now).

Best regards,
Eduard.

Bug#879721: debian-handbook: missing link in 5.2.1.1. Dependencies: the Depends Field

[Raphael Hertzog]

Hello,

On Wed, 25 Oct 2017, Xiao Shengwen wrote:
> Package: debian-handbook
> Version: 8.20170125
> Severity: normal
> 
> 5.2.1.1. Dependencies: the Depends Field
> 
> http://www.debian.org/doc/debian-policy/ch-relationships.html
> 
> This link is missing.

What do you mean by "this link is missing" ?

I see the link in
https://www.debian.org/doc/manuals/debian-handbook/sect.package-meta-information.en.html#sect.control
and also in
https://debian-handbook.info/browse/stable/sect.package-meta-information.html#sect.control

And it points to an existing webpage.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#928731: ITP: ruby-has-secure-token -- provides an easy way to generate uniques random tokens for any model in ruby on rails

[Manas Kashyap]

Package: wnpp
Severity: wishlist
Owner: Manas Kashyap 
X-Debbugs-CC: debian-de...@lists.debian.org, debian-r...@lists.debian.org

* Package name: ruby-has-secure-token
  Version : 1.0.0
 Upstream Author : Roberto Miranda
* URL : https://github.com/robertomiranda/has_secure_token
* License : MIT
  Programming Lang: Ruby
  Description : It provides an easy way to generate uniques random
tokens for any model in ruby on rails
  .
SecureRandom::base58 is used to generate the 24-character unique tokens, so
collisions are highly unlikely.

Bug#928730: advancecomp: CVE-2019-8383

[Salvatore Bonaccorso]

Source: advancecomp
Version: 2.1-2
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/advancemame/bugs/272/

Hi,

The following vulnerability was published for advancecomp.

CVE-2019-8383[0]:
| An issue was discovered in AdvanceCOMP through 2.1. An invalid memory
| address occurs in the function adv_png_unfilter_8 in lib/png.c. It can
| be triggered by sending a crafted file to a binary. It allows an
| attacker to cause a Denial of Service (Segmentation fault) or possibly
| have unspecified other impact when a victim opens a specially crafted
| file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-8383
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8383
[1] https://sourceforge.net/p/advancemame/bugs/272/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#928729: advancecomp: CVE-2019-8379

[Salvatore Bonaccorso]

Source: advancecomp
Version: 2.1-2
Severity: important
Tags: security upstream
Forwarded: https://sourceforge.net/p/advancemame/bugs/271/

Hi,

The following vulnerability was published for advancecomp.

CVE-2019-8379[0]:
| An issue was discovered in AdvanceCOMP through 2.1. A NULL pointer
| dereference exists in the function be_uint32_read() located in
| endianrw.h. It can be triggered by sending a crafted file to a binary.
| It allows an attacker to cause a Denial of Service (Segmentation
| fault) or possibly have unspecified other impact when a victim opens a
| specially crafted file.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-8379
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8379
[1] https://sourceforge.net/p/advancemame/bugs/271/

Please adjust the affected versions in the BTS as needed.

Regards,
Salvatore

Bug#928728: testssl.sh: missing dependencies

[Lee Garrett]

Package: testssl.sh
Version: 2.9.5-7+dfsg1-1
Severity: serious
Justification: Policy 3.5

Hi,

on a minimal Debian installation testssl fails to work. It's missing at least
these dependencies (package name in brackets):

- dig (dnsutils)
- host (bind9-host)
- ps (procps)
- hexdump (bsdmainutils)

Thanks in advance,
Lee

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

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

Versions of packages testssl.sh depends on:
ii  openssl  1.1.1b-2

testssl.sh recommends no packages.

testssl.sh suggests no packages.

-- no debconf information

Bug#928727: FTBFS: ImportError: No module named twisted.python.failure

[Hans Joachim Desserud]

Source: python-tblib
Version: 1.4.0-1
Severity: serious
Tags: ftbfs

Dear Maintainer,

python-tblib currently fails to build from source with the following 
error message:


 ERRORS 

___ ERROR collecting 
.pybuild/cpython2_2.7_tblib/build/tests/test_issue30.py ___

tests/test_issue30.py:5: in 
from twisted.python.failure import Failure
E   ImportError: No module named twisted.python.failure
___ ERROR collecting 
.pybuild/cpython2_2.7_tblib/build/tests/test_issue30.py ___
ImportError while importing test module 
'/build/1st/python-tblib-1.4.0/.pybuild/cpython2_2.7_tblib/build/tests/test_issue30.py'.

Hint: make sure your test modules/packages have valid Python names.
Traceback:
/usr/lib/python2.7/dist-packages/_pytest/python.py:450: in 
_importtestmodule

mod = self.fspath.pyimport(ensuresyspath=importmode)
/usr/lib/python2.7/dist-packages/py/_path/local.py:668: in pyimport
__import__(modname)
/usr/lib/python2.7/dist-packages/_pytest/assertion/rewrite.py:294: in 
load_module

six.exec_(co, mod.__dict__)
/usr/lib/python2.7/dist-packages/six.py:709: in exec_
exec("""exec _code_ in _globs_, _locs_""")
:1: in 
???
tests/test_issue30.py:5: in 
from twisted.python.failure import Failure
E   ImportError: No module named twisted.python.failure

(see 
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/python-tblib.html

for more details)

I got the same error message when attempting to build it on my Sid 
system.



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

Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)

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


--
mvh / best regards
Hans Joachim Desserud
http://desserud.org

Bug#923684: nmu: galax_1.1-15

[Paul Gevers]

Control: tags -1 moreinfo

Hi Kyle,

Is this still relevant?

On Sun, 03 Mar 2019 22:04:35 +0200 Kyle Robbertze 
wrote:
> There was a bug in how camomile < 1.0.1-3 was packaged that prevented
> packages from building against it. This has been fixed, but requires
> r-deps to be rebuilt using the fixed version.
> 
> Thanks
> 
> nmu galax_1.1-15 . ANY . unstable . -m "Rebuild against fixed camomile"

Without checking too carefully, I went ahead with this one today, but
all builds failed very similar to the original problem:
Checking for Camomile...ERROR: unable to find camomileLibrary.cmi in
/usr/lib/ocaml/camomile

> nmu ocaml-gettext_0.3.7-1 . ANY . unstable . -m "Rebuild against fixed 
> camomile"

This one has all builds done successfully.

> nmu lambda-term_1.10.1-2 . ANY . unstable . -m "Rebuild against fixed 
> camomile"

Either successful builds or BD-Uninstallable.

> nmu utop_1.19.3-2 . ANY . unstable . -m "Rebuild against fixed camomile"

Either successful builds or BD-Uninstallable.

> nmu zed_1.4-3 . ANY . unstable . -m "Rebuild against fixed camomile"

...

Paul

Bug#928725: muttprint: Missing cups-bsd dependency

[Rene Engelhard]

Hi,

On Thu, May 09, 2019 at 10:36:06AM -0700, Francois Marier wrote:
> I was unable to print using CUPS before installing cups-bsd.

And how did you print from other stuff? That also needs lpr. Especially
on text-console machines, which is this is for.

> Since muttprint requires lpr to print emails, it should depend on:
^^

Uhm, no?

$ cat /etc/Muttprintrc 
# MUTTPRINT configuration file
#
# ~/.muttprintrc or /etc/Muttprintrc

#
# Here you can configure your printer
# To print in a file, use the following entry:
# PRINTER="TO_FILE:/home/berwal/test.ps"
#PRINTER="lp"

#
# Here you can set the print command
# $PRINTER is substituted by the PRINTER
# variable
#PRINT_COMMAND="lpr -P$PRINTER"
PRINT_COMMAND="lpr"
[...]

so you easily can define my_print_command.sh which does something, not
requiring "lpr" :-)

>   cups-bsd | lpr | lprng

But yeah, that probably should be added nevertheless, maybe as
Recommends:...

Regards,

Rene

Bug#928711: unblock: [pre-approval] cyrus-imapd/3.0.8-5

[Paul Gevers]

Control: tags -1 moreinfo

On 09-05-2019 15:53, Xavier Guimard wrote:
> we are going to fix #927142 (Cyrus-Imapd RC bug). I noticed also that
> there are many spelling errors in this package. Do you think I can add a
> this spelling error patch (joined) or upload a minimal change?

Please make sure you send the changes upstream. Are you sure that none
of these strings are checked/processed anywhere, maybe outside of the
package? E.g. in logcheck or other parsing code?

I'll accept it when you can add the documentation corrections in ./doc/
./docsrc/ ./man and the README.

Please remove the moreinfo tag once there is more to review.

Paul

Bug#921447: Please confirm subscription to 921...@bugs.debian.org (etckeeper: Unnecessary dependency on python2)

[Antoine Beaupré]

On 2019-05-09 19:36:46, Varac wrote:
> Quoting Antoine Beaupré (2019-04-21 23:05:35)
>> I'm not sure I can get away with this one during the freeze,
>> unfortunately. :/
>>
>> But as soon as buster-backports opens, this will be a distinct
>> possibility. Remind me then if I forget...
>
> Can't it be uploaded already to unstable and later migrated to 
> buster-backports
> ? That would allow an installation from unstable until buster-backports is
> there.
>
> I don't want to push on this but possibly unblock it from the buster release
> process, if possible.

I don't usually upload to unstable during the freeze, as it can block
possible fixes for problems that could be discovered.

If I say, upload 1.18.12-1 now to unstable and a release critical bug
appears in 1.18.11-1 in buster, there's no easy way to fix it in buster
because that needs an update to unstable. I would need to *revert* the
1.18.12-1 upload and that would mean messing around with version numbers
in a bad way.

The proper way to upload a new version now is to send it to
experimental.

But anyways buster-backports won't be open until after the buster
release, so it won't help you getting it there.

BTW, the Ubuntu folks sent a patch that fixes this problem in #928177 as
well, you might want to check it out. And I do need help with the
maintenance on this package, as you might have noticed from the bug
report count... any little bit helps! :)

A.

-- 
I'm sorry if any of you are catholic. I'm not sorry if you're
offended, I'm actually just sorry by the fact that you're catholic
 - Bill Hicks

Bug#928726: json: CVE-2019-11834 CVE-2019-11835

[Salvatore Bonaccorso]

Source: cjson
Version: 1.7.10-1
Severity: grave
Tags: security upstream fixed-upstream

Hi,

The following vulnerabilities were published for cjson.

CVE-2019-11834[0]:
| cJSON before 1.7.11 allows out-of-bounds access, related to \x00 in a
| string literal.


CVE-2019-11835[1]:
| cJSON before 1.7.11 allows out-of-bounds access, related to multiline
| comments.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2019-11834
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11834
https://github.com/DaveGamble/cJSON/issues/337
[1] https://security-tracker.debian.org/tracker/CVE-2019-11835
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-11835
https://github.com/DaveGamble/cJSON/issues/338

Regards,
Salvatore

Bug#921447: Please confirm subscription to 921...@bugs.debian.org (etckeeper: Unnecessary dependency on python2)

[Varac]

Quoting Antoine Beaupré (2019-04-21 23:05:35)
> I'm not sure I can get away with this one during the freeze,
> unfortunately. :/
>
> But as soon as buster-backports opens, this will be a distinct
> possibility. Remind me then if I forget...

Can't it be uploaded already to unstable and later migrated to buster-backports
? That would allow an installation from unstable until buster-backports is
there.

I don't want to push on this but possibly unblock it from the buster release
process, if possible.

Greetings, Varac


signature.asc
Description: signature

Bug#928725: muttprint: Missing cups-bsd dependency

[Francois Marier]

Package: muttprint
Version: 0.73-8
Severity: important

I was unable to print using CUPS before installing cups-bsd.

Since muttprint requires lpr to print emails, it should depend on:

  cups-bsd | lpr | lprng

Francois

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

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

Versions of packages muttprint depends on:
ii  libtext-iconv-perl 1.7-5+b7
ii  perl   5.28.1-6
ii  texlive-fonts-recommended  2018.20190227-2
ii  texlive-latex-extra2018.20190227-2
ii  texlive-latex-recommended  2018.20190227-2

Versions of packages muttprint recommends:
ii  bsd-mailx [mail-reader]  8.1.2-0.20180807cvs-1
ii  emacs-gtk [mail-reader]  1:26.1+1-3.2
ii  libtimedate-perl 2.3000-2
ii  mailutils [mail-reader]  1:3.5-3
ii  mutt [mail-reader]   1.10.1-2

Versions of packages muttprint suggests:
pn  compface 
ii  dialog   1.3-20190211-1
ii  emacs-gtk [news-reader]  1:26.1+1-3.2
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  lynx [news-reader]   2.8.9rel.1-3
pn  muttprint-manual 
pn  ospics   
pn  psutils  
pn  texlive-fonts-extra  

-- no debconf information

Bug#928688: drupal7: Insecure deserialization on bundled third-party library "Phar Stream Wrapper" (SA-CORE-2019-007)

[Salvatore Bonaccorso]

Control: retitle -1 drupal7: Insecure deserialization on bundled third-party 
library "Phar Stream Wrapper" (SA-CORE-2019-007) (CVE-2019-11831)

On Wed, May 08, 2019 at 04:13:30PM -0500, Gunnar Wolf wrote:
> Package: drupal7
> Version: 7.52-2+deb9u8
> Severity: grave
> Tags: security upstream
> Justification: user security hole
> 
> Drupal security advisory SA-CORE-2019-007 was issued today:
> 
> https://www.drupal.org/SA-CORE-2019-007
> 
> It refers to the following advisory in a bundled third-party library:
> 
> https://typo3.org/security/advisory/typo3-psa-2019-007/
> 
> It refers to an incorrectly verified deserialization issue that can
> lead at least to insecure deserialization issues.
> 
> No CVE has yet been issued, TTBOMK.

CVE-2019-11831 is used by the Drupal advisory now, but not the related
CVE-2019-11830.

Regards,
Salvatore

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

[nozzy123nozzy]

Hi Berto,

 I applied upstream's patch 
   https://bug-197658-attachments.webkit.org/attachment.cgi?id=369368
to the sources of webkit2gtk_2.24.1-1 in my debian box, and installed
them.Then I surely confired to fix problems reported by debian bug
#926872 and #928399.

 Thank you for all things. I'm looking forward to releasing  newer
version of libwebkit2gtk  in debian.

Takahide Nojima


 

Bug#905720: acme-tiny: Please follow upstream versioning instead of date-based versions

[Jean-Marc]

On Sat, 6 Apr 2019 14:28:22 +0100 Samuel Henrique  wrote:
> Control: tags -1 patch
> 
> Fix available on https://salsa.debian.org/samueloph/acme-tiny
> 
> Discussion about the epoch bump:
> https://lists.debian.org/debian-devel/2019/04/msg00052.html
> 
> -- 
> Samuel Henrique 

Hi Samuel,

I have a question about bugs 905720 and 924393.

For both, you said there is a fix ([0]) and you mentionned the discution on 
debian-devel list ([1]) related the first epoch for acme-tiny.


My question: do you think bug 905720 should be merged into bug 924393 ?

I looked at them but (maybe I am wrong) I did not see any merge indication.

Secondary question : what is blocking the fix ?  You dropped this mail in 
April, the 6th.

Regards,

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt

[0] https://salsa.debian.org/samueloph/acme-tiny
[1] https://lists.debian.org/debian-devel/2019/04/msg00052.html


pgpD5M7o4pjHS.pgp
Description: PGP signature

Bug#869184: dpkg: source uploads including _amd64.buildinfo cause problems

[Salvatore Bonaccorso]

Hi,

On Sat, Mar 09, 2019 at 03:00:10PM +0100, Salvatore Bonaccorso wrote:
> Hi
> 
> The following question goes maybe specifically to Ansgar, from
> dak/ftp-master perspective:
> 
> On Sun, Nov 11, 2018 at 08:38:36AM +0100, Salvatore Bonaccorso wrote:
> > Hi Guillem!
> > 
> > On Fri, Nov 09, 2018 at 11:48:27AM +0100, Guillem Jover wrote:
> > > Hi!
> > > 
> > > On Thu, 2018-11-08 at 20:28:57 +, Holger Levsen wrote:
> > > > On Thu, Nov 08, 2018 at 09:24:01PM +0100, Salvatore Bonaccorso wrote:
> > > > > We were again biten by this issue for some security-updates (most
> > > > > recent one nginx). Do any involved parties know, was there any
> > > > > progress in adressing this problem? 
> > > 
> > > Sorry, had your earlier mail from July marked for reply, but it seems
> > > I missed that. :/
> > > 
> > > > in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=869184#40 Guillem
> > > > wrote:
> > > > 
> > > >Perhaps the simplest and more correct might be to name it using
> > > >something like source+amd64 as the arch name, which seems like a
> > > >dubious arch, but at least is accurate and might be trivial to
> > > >implement, taking care of not ending up with such fake arch in
> > > >unexpected places…
> > > > 
> > > > and I cannot find anything wrong with this simple solution and have
> > > > already asked Guillem in August to implement this ;)
> > > 
> > > So, as I mentioned at the time this would require modifing the internal
> > > filtering of the debian/files entries to cover this case in several of
> > > the tools. It also modifies the documented filename pattern in
> > > deb-buildinfo(5). This is all solvable and I should probably just do it.
> > > But this breaks previous public filename "interfaces", seems rather
> > > intrusive, and entirely inappropriate for a stable update, which means
> > > it would not fix your immediate problems anyway, only starting with
> > > Buster. :/
> > 
> > Although this would not help us for stretch-security uploads, such a
> > move starting from buster would be very appreciated!
> > 
> > Thanks a lot for your time investing in it, very much appreicated.
> 
> We regularly get issue still with that given one easily forgets about
> the issue (the last occurence whas the php7.0 upload for
> stretch-security as of yesterday). I wonder thus: would it be easily
> workaroundable on ftp-master/dak's side to perform some additional
> checks in that direction and reject such uploads wich would contain a
> _${arch}.buildinfo file?
> 
> Any help in this regard would be very welcome from security team's
> perspective, as we -- although an easy step -- need to fetch rejected
> packages, rename files, resign and upload.
> 
> Sorry for always returning with this issue to both you and dpkg
> maintainers.

We regularly get biten by this issue when contributors to security
uploads, most recently with the bind9 upload but as well others.

Would it be possible to at least workaround this on dak's side?
Disabling source-only uploads completely would seem to be a step back
on that regards.

Though if that's the only way  out of having to regularly fetch the
rejected builds, do manual renamings and resigning and reuploading of
files, then we should then just disable source-only uploads for the
security suites again.

So I think we pretty much would prefer to be able to continue so.

Just to be clear, thanks a lot for your work, this is not meant as
critique, just hilighting that we have recurring issues due to this
bug when people perform uploads for security.

Regards,
Salvatore

Bug#924843: Any chance for some target fix for msxpertsuite

[Filippo Rusconi]

Greetings, Andreas,

thank you for your message. Sorry for the late answer, I was abroad with no
easy internet connectivity.

On Mon, May 06, 2019 at 07:52:24AM +0200, Andreas Tille wrote:

Hi Filippo,

as far as I understood Debian Release team your last fix is not accepted
for Buster.  Do you plan to fix this in a testing-proposed-updates
upload following release policy or will we see Buster without
msxpertsuite?


Well, as explained elsewhere, the fix needs the daps package to be accepted in
testing. And it looks like this is not going to happen. I had a pretty clear
message by the release team about this. Which is fine.

Cheers,
Filippo

--

⢀⣴⠾⠻⢶⣦⠀  Filippo Rusconi, PhD
⣾⠁⢠⠒⠀⣿⡁   Scientist at CNRS
⢿⡄⠘⠷⠚⠋⠀   Debian Developer
⠈⠳⣄  http://msxpertsuite.org
 http://www.debian.org

Bug#928724: ITP: opensbi -- RISC-V Open Source Supervisor Binary Interface

[Vagrant Cascadian]

Package: wnpp
Severity: wishlist
Owner: Vagrant Cascadian 
X-Debbugs-Cc: debian-de...@lists.debian.org, mer...@debian.org, 
debian-ri...@lists.debian.org

* Package name: opensbi
  Version : 0.3+
  Upstream Author : Anup Patel/Western Digital, other contributors
* URL : https://github.com/riscv/opensbi
* License : BSD-2, Apache 2.0, GPL-2+
  Programming Lang: C
  Description : RISC-V Open Source Supervisor Binary Interface

The **RISC-V Supervisor Binary Interface (SBI)** is the recommended interface
between:

1. A platform-specific firmware running in M-mode and a bootloader, a
   hypervisor or a general-purpose OS executing in S-mode or HS-mode.
2. A hypervisor running in HS-mode and a bootloader or a general-purpose OS
   executing in VS-mode.

The *RISC-V SBI specification* is maintained as an independent project by the
RISC-V Foundation on [Github] (https://github.com/riscv/riscv-sbi-doc).

The goal of the OpenSBI project is to provide an open-source reference
implementation of the RISC-V SBI specifications for platform-specific firmwares
executing in M-mode (case 1 mentioned above). An OpenSBI implementation can be
easily extended by RISC-V platform and system-on-chip vendors to fit a
particular hardware configuration.

...

An SBI implementation is needed in order to boot RISC-V systems. This
package initially will at least enable loading u-boot in qemu
sufficient to boot a linux kernel and initramfs.


A similar project is the RISC-V Proxy Kernel and Boot Loader
(a.k.a. BBL):

  https://github.com/riscv/riscv-pk

But BBL requires a compilation step to embed the bootloader and/or
kernel into a payload every time you upgrade the kernel and/or
bootloader. It is possible with OpenSBI to load an arbitrary payload
without requiring a compilation step in some cases (e.g. qemu).


Karsten Merker has offered to co-maintain (who has also been
contributing upstream); not sure if we'll need a team just yet.


Initial rough cut of packaging:

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

It cross-compiles an arch:all firmware image usable with qemu+u-boot.

Help with improving the package description and a few remaining
lintian issues would be great!


live well,
  vagrant


signature.asc
Description: PGP signature

Bug#894569: [Letsencrypt-devel] Bug#894569: acme-tiny: compatibility issues

[Jean-Marc]

On Thu, 5 Apr 2018 22:23:43 +0300 sergio  wrote:
> On 03/04/18 20:30, Sebastien Badia wrote:
> 
> > The actual version in Debian stable (stretch) is 20160801-3+deb9u1.
> > Could you please, tell us more about your problem ?
> 
> Unfortunately I can't reproduce it more! But a week ago I had to
> download the latest version from github (that successfully works) as
> 20160801-3+deb9u1 produced some python Traceback. May be it were some
> letsencrypt issues?
> 
> 
> -- 
> sergio

Hi Sergio,

Any information to add to this bug report ?

Can you reproduce it ?

In case you cannot reproduce the issue, can this bug be closed ?

Thanks in advance.

Regards,

Jean-Marc 
https://6jf.be/keys/ED863AD1.txt


pgpBMNwuU5m2C.pgp
Description: PGP signature

Bug#928723: deepin-picker: does not start when compositing is disabled

[Juhani Numminen]

Package: deepin-picker
Version: 1.6.4-1
Severity: important

Dear Maintainer,

When I unselect "Enable software compositing window manager" in
"Window preferences" when using the MATE desktop,
or unselect "Enable display compositing" in "Window Manager Tweaks"
when using the LXQt desktop with xfwm4,
deepin-picker cannot be used.

When I start deepin-picker in terminal, the executable returns with exit
code 0 and does not give any warning or other message.

If I enable the compositing in MATE & LXQt, or swith to GNOME,
deepin-picker works: it displays a magnifying glass and
a color can be selected.

I think there should be a warning if the program can't work due to a
WM configuration option. Otherwise the user or administrator has no
idea of what went wrong. I was led to the window compositing and
effects settings by a bug report:
https://github.com/linuxdeepin/deepin-picker/issues/2
and I started looking at deepin-picker due to a recent Ubuntu bug:
https://bugs.launchpad.net/ubuntu/+source/deepin-picker/+bug/1828314


Regards,
Juhani Numminen


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

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

Versions of packages deepin-picker depends on:
ii  dde-qt5integration  0.3.7.2-1
ii  libc6   2.28-10
ii  libdtkcore2 2.0.9.17-1
ii  libdtkwidget2   2.0.9.17-1
ii  libgcc1 1:8.3.0-6
ii  libqt5core5a5.11.3+dfsg1-1
ii  libqt5dbus5 5.11.3+dfsg1-1
ii  libqt5gui5  5.11.3+dfsg1-1
ii  libqt5widgets5  5.11.3+dfsg1-1
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1
ii  libxtst62:1.2.3-1

deepin-picker recommends no packages.

deepin-picker suggests no packages.

-- no debconf information

Bug#928722: libdpdk-dev: missing dependencies on libelf-dev and libjansson-dev

[Luca Boccassi]

Package: libdpdk-dev
Version: 18.11-1
Severity: important
Fixed: 18.11.1-3

libdpdk-dev is missing a dependency on libelf-dev and libjansson-dev,
and as a consequence pkg-config --cflags libdpdk will wail. The
workaround is to install those two packages manually. It will be fixed
in buster's first point release, and is already fixed in experimental.


-- 
Kind regards,
Luca Boccassi


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

Bug#928717: in normal builds local urresponsive flas are parsed to build process

[PICCORO McKAY Lenz]

Cited from upstream For a native x86_64 build, you need to REMOVE {{-fPIE}}
from the CFLAGS and {{-fPIE -pie}} from LDFLAGS.

Seems dpkg-buildflags are passed that arguments to build processs in 64bits
amd64,

due in i386 builds compiles fine!


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

Bug#923605: ITP: dhcpoptinj -- DHCP option injector (updated: 0.5.2-1)

[Andreas Misje]

The package now contains latest upstream (0.5.2) as well as fixes to
debian/copyright (typo in GPL version, include "+", rename "MIT" to
"Expat" and remove copyright lines from Expat licence text).


Best regards
-- 
Andreas Misje

Bug#918988: Maybe I can help with this issue

[codiflow]

Hey together,

I also have this issue and maybe I can get you some more infos to debug
it.

First of all some infos on my system:

OS Name: Linux x86_64
Version: 4.9.0-9-amd64
Distribution: Debian GNU/Linux 9 (stretch) [Note: Was upgraded from 8
to 9 with dist-upgrade]
PHP Version: 5.6.39
Web Server: Apache/2.4.25 (Debian) [Note: Using nginx with reverse
proxy to redirect to the Apache server]
Database Server: Debian 9.8 version 10.1.38-MariaDB-0+deb9u1
Version OCSReports: 2.6RC

After updating the package libmariadbclient18 to a version greater than
10.1.26-0+deb9u1 every inventory request to the ocsinventory server
fails.

Downgrading the package is not working anymore - it was a dirty
workaround for about two months:
apt-get install libmariadbclient18=10.1.26-0+deb9u1
apt-mark hold libmariadbclient18

---

In the nginx log I get this followed by an 502 Bad Gateway error:
2019/05/09 17:30:10 [error] 24057#24057: *1 upstream prematurely closed
connection while reading response header from upstream, client:
X.X.X.X, server: XXX.de, request: "GET /ocsinventory HTTP/1.1",
upstream: "http://127.0.0.1:8080/ocsinventory;, host: "XXX.de"

In the apache log I get this error:
[Thu May 09 17:30:10.968682 2019] [core:notice] [pid 1403] AH00052:
child pid 5479 exit signal Segmentation fault (11)

Running `dpkg -S /usr/lib/x86_64-linux-gnu/libmys*` returns:
libmysqlclient18:amd64: /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18
libmysqlclient18:amd64: /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18.0.0
libmysqlclient18:amd64: /usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18
libmysqlclient18:amd64: /usr/lib/x86_64-linux-gnu/libmysqlclient_r.so.18.0.0

Running `dpkg -S /usr/lib/x86_64-linux-gnu/libmaria*` returns:
libmariadbclient18:amd64: /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18
libmariadbclient18:amd64: /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18.0.0

Running `nm -D /usr/lib/x86_64-linux-gnu/libmariadbclient.so.18 | egrep
'lib(mariadb|mysql)client_18'` returns:
 A libmariadbclient_18
 A libmysqlclient_18

Running `nm -D /usr/lib/x86_64-linux-gnu/libmysqlclient.so.18 | egrep
'lib(mariadb|mysql)client_18'` returns:
 A libmysqlclient_18

Removing of libmysqlclient18 would also remove php5-mysql* which is not
what I want.

Removing of libmariadbclient18 would also remove dovecot-mysql*
libdbd-mysql-perl* libsasl2-modules-sql* postfix-mysql*
proftpd-mod-mysql* sysbench* which is not what I want.

I don't know what I can try to get some new results with this issue -
but maybe I can help with my system do debug it further.

If you need more information just tell me.

Regards
codiflow

Bug#928721: Avoid freeze for DBusActivatable apps

[Alf Gaida]

Package: libqt5xdg3
Version: 3.4.0~13-ga0c8e32-1
Severity: important
Tags: patch

For case when the DBusActivatable application is unresponsive the
startDetached() can block for a long time (the Qt default 25s DBus
timeout). Blocking can't be avoided while using QDBusInterface, because
the object can block directly in its contructor.

So we use the generated interface class and set the timeout for the DBus
call to 1500ms (can be overriden env variable QTXDG_DBUSACTIVATE_TIMEOUT).

See also: https://bugreports.qt.io/browse/QTBUG-75016

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

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

Versions of packages libqt5xdg3 depends on:
ii  file   1:5.35-4
ii  libc6  2.28-10
ii  libfile-mimeinfo-perl  0.29-1
ii  libglib2.0-bin 2.60.0-1.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  libqt5xdgiconloader3   3.4.0~13-ga0c8e32-1
ii  libqt5xml5 5.11.3+dfsg1-1
ii  libstdc++6 8.3.0-7
ii  shared-mime-info   1.10-1

Versions of packages libqt5xdg3 recommends:
ii  qttranslations5-l10n  5.11.3-2

libqt5xdg3 suggests no packages.

-- no debconf information

Bug#927142: Cyrus-Imapd expel from Buster?

[Xavier]

Le 09/05/2019 à 16:34, Kim-Alexander Brodowski a écrit :
> Sorry for the late response. It's been a couple of busy days.
> 
> I'll test the changes on monday, but it looks good at first glance.

Thanks, we are going to test here too. I filed also a
pre-approval-unblock to ask if I can add a spelling error patch
(https://bugs.debian.org/928711)

Bug#928720: unblock: devscripts/2.19.5

[Mattia Rizzolo]

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

Hi,

please unblock devscripts/2.19.5 - debdiff (filtering out the po files)
is attached.

Changes are:
 * typos in documentation
 * small fixes in salsa(1) and a tiny one in uscan(1)
 * important fixes in mk-origtargz(1) - see the recent post on d-d@ from
   guillem

Thanks for considering.

-- 
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  `-
 debian/changelog|   34 ++-
 lib/Devscripts/MkOrigtargz.pm   |   42 +---
 lib/Devscripts/Salsa/Config.pm  |4 +-
 lib/Devscripts/Salsa/check_repo.pm  |1 
 lib/Devscripts/Salsa/update_repo.pm |6 +++
 lib/Devscripts/Uscan/WatchFile.pm   |2 -
 scripts/hardening-check.pl  |   10 ++---
 scripts/salsa.pl|6 ++-
 scripts/uscan.pl|3 +
 test/lib_test_uscan |2 -
 test/test_mk-origtargz  |   63 ++--
 11 files changed, 147 insertions(+), 26 deletions(-)
diffstat for devscripts-2.19.4 devscripts-2.19.5

diff -Nru devscripts-2.19.4/debian/changelog devscripts-2.19.5/debian/changelog
--- devscripts-2.19.4/debian/changelog	2019-03-20 16:57:59.0 +0100
+++ devscripts-2.19.5/debian/changelog	2019-05-09 17:01:29.0 +0200
@@ -1,3 +1,35 @@
+devscripts (2.19.5) unstable; urgency=medium
+
+  [ Topi Miettinen ]
+  * hardening-check:
++ Fix some typos in the documentation.  MR: !118
+
+  [ Xavier Guimard ]
+  * Update French translation.
+  * uscan:
++ Don't fail on first error when using multiple watch files.
+  Closes: #927864; MR: !119
+  * salsa:  MR: !117
++ Fix token regexp to allow "-" in GitLab tokens.
++ Fix useless warnings when old description is null.  Closes: #927367
++ Accept sub-groups in --group parameter.  Closes: #927350
++ Fix bad warning if user is an inherited member of a subgroup.
+  Closes: #927373
+
+  [ Edward Betts ]
+  * Correct some spelling errors in documentation.  MR: !116
+
+  [ Guillem Jover ]
+  * mk-origtargz:  MR: !120
++ Do not enarmor already armored OpenPGP signatures.  This actively caused
+  broken .asc files to be uploaded to the archive.
++ Pass --no-options to gpg.
++ Prevent duplicating the signature in case mk-origtargz is called twice.
++ Fix OpenPGP signature ASCII enarmor normalization.
++ Minore code improvements.
+
+ -- Mattia Rizzolo   Thu, 09 May 2019 17:01:29 +0200
+
 devscripts (2.19.4) unstable; urgency=medium
 
   [ Antonio Terceiro ]
@@ -41,7 +73,7 @@
 + Add KGB options configuration.  Closes: #921641; MR: !115
   * uscan:
 + Fix bad check for "verbose" in Config.pm.  Closes: #923441; MR: !111
-  * Update French translation
+  * Update French translation.
 
   [ Reiner Herrmann ]
   * Update German translation.
diff -Nru devscripts-2.19.4/lib/Devscripts/MkOrigtargz.pm devscripts-2.19.5/lib/Devscripts/MkOrigtargz.pm
--- devscripts-2.19.4/lib/Devscripts/MkOrigtargz.pm	2019-03-01 10:39:51.0 +0100
+++ devscripts-2.19.5/lib/Devscripts/MkOrigtargz.pm	2019-05-09 16:52:33.0 +0200
@@ -307,9 +307,6 @@
 
 # Final step: symlink, copy or rename for signature file.
 
-my $is_ascfile = $self->config->signature_file =~ /\.asc$/i;
-my $is_gpgfile = $self->config->signature_file =~ /\.(gpg|pgp|sig|sign)$/i;
-
 my $destsigfile;
 if ($self->config->signature == 1) {
 $destsigfile = sprintf "%s.asc", $destfile;
@@ -324,22 +321,43 @@
 }
 
 if ($self->config->signature == 1 or $self->config->signature == 2) {
-if ($is_gpgfile) {
-my $enarmor
-  = `gpg --output - --enarmor $self->{config}->{signature_file} 2>&1`;
+my $is_openpgp_ascii_armor = 0;
+my $fh_sig;
+unless (open($fh_sig, '<', $self->config->signature_file)) {
+ds_die "Cannot open $self->{config}->{signature_file}\n";
+return $self->status(1);
+}
+while (<$fh_sig>) {
+if (m/^-BEGIN PGP /) {
+$is_openpgp_ascii_armor = 1;
+last;
+}
+}
+close($fh_sig);
+
+if (not $is_openpgp_ascii_armor) {
+my @enarmor
+  = `gpg --no-options --output - --enarmor $self->{config}->{signature_file} 2>&1`;
 unless ($? == 0) {
 ds_die
-"mk-origtargz: Failed to convert $self->{config}->{signature_file} to *.asc\n";
+"Failed to convert $self->{config}->{signature_file} to *.asc\n";
 return $self->status(1);
 }
-$enarmor =~ s/ARMORED FILE/SIGNATURE/;
-

Bug#928719: unblock: postgresql-11/11.3-1

[Christoph Berg]

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

Please unblock package postgresql-11. The new version fixes two
security bugs, and various other issues. (This is a new upstream minor
release, which would have pushed by the security team if buster was
already released.)

unblock postgresql-11/11.3-1

Christoph


postgresql-11 (11.3-1) unstable; urgency=medium

  * New upstream version.
+ Prevent row-level security policies from being bypassed via selectivity
  estimators (Dean Rasheed)

  Some of the planner's selectivity estimators apply user-defined
  operators to values found in pg_statistic (e.g., most-common values).
  A leaky operator therefore can disclose some of the entries in a data
  column, even if the calling user lacks permission to read that column.
  In CVE-2017-7484 we added restrictions to forestall that, but we failed
  to consider the effects of row-level security.  A user who has SQL
  permission to read a column, but who is forbidden to see certain rows
  due to RLS policy, might still learn something about those rows'
  contents via a leaky operator.  This patch further tightens the rules,
  allowing leaky operators to be applied to statistics data only when
  there is no relevant RLS policy.  (CVE-2019-10130)

+ Avoid access to already-freed memory during partition routing error
  reports (Michael Paquier)

  This mistake could lead to a crash, and in principle it might be
  possible to use it to disclose server memory contents. (CVE-2019-10129)

 -- Christoph Berg   Tue, 07 May 2019 12:04:34 +0200

Bug#927851: what's the matter?

[andrew glaeser]

OK, I guess it could be a fundamental issue in libc, but did not try out

for any changes about Hugin yet:

> andrew@a68n:~$ ssh root@detst
> Linux detst 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64
> 
> The programs included with the Debian GNU/Linux system are free software;
> the exact distribution terms for each program are described in the
> individual files in /usr/share/doc/*/copyright.
> 
> Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
> permitted by applicable law.
> Last login: Thu May  2 18:01:51 2019 from 192.168.0.58
> root@detst:~# aptitude update && aptitude upgrade
> Get: 1 http://security.debian.org/debian-security buster/updates InRelease
> [39.1 kB] Get: 2 http://ftp2.de.debian.org/debian buster InRelease [163
> kB] Hit http://packages.x2go.org/debian buster InRelease  
> Get: 3 http://ftp2.de.debian.org/debian buster/main amd64
> Packages.diff/Index [27.9 kB] Get: 4 http://ftp2.de.debian.org/debian
> buster/main Translation-en.diff/Index [27.9 kB] Get: 5
> http://ftp2.de.debian.org/debian buster/non-free amd64 Packages.diff/Index
> [27.8 kB] Get: 6 http://ftp2.de.debian.org/debian buster/non-free
> Translation-en.diff/Index [27.8 kB] Get: 7 http://ftp2.de.debian.org/debian
> buster/contrib amd64 Packages.diff/Index [27.8 kB] Get: 8
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-03-0210.45.pdiff [8,032 B] Get: 9 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-04-0210.59.pdiff [991 B] Get: 10
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-05-0210.43.pdiff [2,761 B] Get: 11 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-05-2010.36.pdiff [14.0 kB] Get: 12
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-06-0208.27.pdiff [4,718 B] Get: 13 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-06-1410.49.pdiff [34 B] Get: 14
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-06-2008.55.pdiff [8,606 B] Get: 15 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-07-0210.21.pdiff [2,103 B] Get: 16
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-07-1412.19.pdiff [44 B] Get: 17 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-08-0215.06.pdiff [5,021 B] Get: 18
> http://ftp2.de.debian.org/debian buster/main amd64 Packages
> 2019-05-08-1408.44.pdiff [1,515 B] Get: 19 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-09-0209.39.pdiff [812 B] Get: 20
> http://ftp2.de.debian.org/debian buster/main Translation-en
> 2019-05-06-1410.49.pdiff [33 B] Get: 21 http://ftp2.de.debian.org/debian
> buster/main amd64 Packages 2019-05-09-0209.39.pdiff [812 B] Get: 22
> http://ftp2.de.debian.org/debian buster/main Translation-en
> 2019-05-07-1412.19.pdiff [44 B] Get: 23 http://ftp2.de.debian.org/debian
> buster/non-free amd64 Packages 2019-05-05-2010.36.pdiff [5,967 B] Get: 24
> http://ftp2.de.debian.org/debian buster/main Translation-en
> 2019-05-07-1412.19.pdiff [44 B] Get: 25 http://ftp2.de.debian.org/debian
> buster/non-free Translation-en 2019-05-05-2010.36.pdiff [597 B] Get: 26
> http://ftp2.de.debian.org/debian buster/contrib amd64 Packages
> 2019-05-05-2010.36.pdiff [679 B] Get: 27 http://ftp2.de.debian.org/debian
> buster/non-free amd64 Packages 2019-05-05-2010.36.pdiff [5,967 B] Get: 28
> http://ftp2.de.debian.org/debian buster/non-free Translation-en
> 2019-05-05-2010.36.pdiff [597 B] Get: 29 http://ftp2.de.debian.org/debian
> buster/contrib amd64 Packages 2019-05-05-2010.36.pdiff [679 B] Fetched 397
> kB in 7s (58.0 kB/s) Current status: 29 (+29) upgradable, 1412 (+1) new.
> The following packages will be upgraded: apt apt-utils bind9-host
> firefox-esr libapt-inst2.0 libapt-pkg5.0 libbind9-161 libc-bin libc-l10n
> libc6 libcryptsetup12 libdns-export1104 libdns1104 libisc-export1100
> libisc1100 libisccc161 libisccfg163 liblwres161 libv4l-0 libv4lconvert0
> libwavpack1 libxnvctrl0 locales usb.ids vim-common vim-tiny wpasupplicant
> xxd youtube-dl 29 packages upgraded, 0 newly installed, 0 to remove and 0
> not upgraded. Need to get 61.5 MB of archives. After unpacking 13.3 kB will
> be used. Do you want to continue? [Y/n/?] Get: 1
> http://ftp2.de.debian.org/debian buster/main amd64 libc6 amd64 2.28-10
> [2,867 kB] Get: 2 http://ftp2.de.debian.org/debian buster/main amd64
> libapt-pkg5.0 amd64 1.8.1 [966 kB] Get: 3 http://ftp2.de.debian.org/debian
> buster/main amd64 libapt-inst2.0 amd64 1.8.1 [204 kB] Get: 4
> http://ftp2.de.debian.org/debian buster/main amd64 apt amd64 1.8.1 [1,353
> kB] Get: 5 http://ftp2.de.debian.org/debian buster/main amd64 apt-utils
> amd64 1.8.1 [421 kB] Get: 6 http://ftp2.de.debian.org/debian buster/main
> amd64 libc-bin amd64 2.28-10 [789 kB] Get: 7
> http://ftp2.de.debian.org/debian buster/main amd64 vim-tiny amd64
> 2:8.1.0875-3 [627 kB] Get: 8 http://ftp2.de.debian.org/debian buster/main
> 

Bug#927142: Cyrus-Imapd expel from Buster?

[Kim-Alexander Brodowski]

Sorry for the late response. It's been a couple of busy days.

I'll test the changes on monday, but it looks good at first glance.

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

[Kentaro Hayashi]

Hi,

On Wed, 8 May 2019 20:32:53 +0200 Salvatore Bonaccorso  
wrote:
> Hi, 
> 
> [please always include team@security.d.o as so any team member can
> reply]
> 

I've got it, thanks.

> On Wed, May 08, 2019 at 12:03:49PM +0900, Hideki Yamane wrote:
> > Hi Salvatore,
> > 
> >  Can you follow his question? I guess debian revision should be
> >  6.1.5-1+deb9u1, but others are okay.
> 
> I think updating groonga via a future point release is enough for this
> issue, can you go ahead for this route? (change the target
> distribution to stretch instead of stretch-security for that).
> 

Ok, I've uploaded.

> In particular though I think the issue should be fixed in unstable and
> buster, but I notice that testing has 9.0.0-1 and 9.0.1-1 did not
> migrate. So either the release team will accept to unblock 9.0.1-1 or
> buster would need a targeted fix as well via testing-proposed-updates,
> cf. https://release.debian.org/buster/freeze_policy.html .

I've filed as a unblock bug.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928715

Regards,

Bug#928717: Build link error bundled pjproject : relocation against symbol cant be used when shared object

[PICCORO McKAY Lenz]

Source: asterisk
Version: 1:16.2.1~dfsg-1
Severity: grave

lasted source fails to buil din common local install with error:

/usr/bin/ld: res_pjsip_session.o: relocation R_X86_64_PC32 against
symbol `ast_sip_session_media_state_reset' can not be used when making
a shared object; recompile with -fPIC

upstream community forum issue at

https://community.asterisk.org/t/build-link-error-bundled-pjproject-relocation-against-symbol-cant-be-used-when-shared-object/79608

upstream bug at:

https://issues.asterisk.org/jira/browse/ASTERISK-28411

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

Bug#928716: mediawiki: File uploads broken (UploadStashBadPathException)

[Chris Boot]

Source: mediawiki
Version: 1:1.31.1-4
Severity: normal
Tags: patch upstream

Dear maintainers,

MediaWiki 1.31.1 appears to have some incompatibilities with PHP 7.3
which is in Buster. Uploading files, such as images, leads to a
UploadStashBadPathException presented on the web interface, and the
server logs include the following PHP warning:

PHP message: PHP Warning:  preg_match(): Compilation failed: invalid
range in character class at offset 4 in
/usr/share/mediawiki/includes/upload/UploadStash.php on line 247

Some searching suggests this is caused by a broken regex that PHP 7.3 no
longer silently accepts:

https://www.mediawiki.org/wiki/Topic:Utp24qj8pnmpah8p
https://phabricator.wikimedia.org/T215632
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/467546/

This will apparently be fixed in MediaWiki 1.31.2 when that's released,
but given that file uploads appear to be non-functional it may be worth
carrying a patch locally for the Buster release or soon after.

Thanks,
Chris

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

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

Bug#928715: testing-pu: groonga/9.0.0-1+deb10u1

[Kentaro Hayashi]

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

Please unblock groonga package:

* It fixes #928304.
  The bug is reported against 6.1.5-1 on stretch, but it need to be fixed on 
testing and unstable package too. so I've prepared the update.

Note that it is already packages on testing (9.0.0-1) and unstable (9.0.1-1).
 9.0.1-1 contains unrelated changes to #928304, so based on freeze policy,
it seems that update package (9.0.0-1+deb10u1) should be uploaded to 
testing-proposed-updates explicitly.

Here is the debdiff:

debdiff groonga_9.0.0-1.dsc groonga_9.0.0-1+deb10u1.dsc
diff -Nru groonga-9.0.0/debian/changelog groonga-9.0.0/debian/changelog
--- groonga-9.0.0/debian/changelog  2019-02-09 22:13:00.0 +0900
+++ groonga-9.0.0/debian/changelog  2019-05-09 22:44:57.0 +0900
@@ -1,3 +1,13 @@
+groonga (9.0.0-1+deb10u1) testing-proposed-updates; urgency=medium
+
+  * debian/groonga-httpd.logrotate
+debian/groonga-server-gqtp.logrotate
+- Mitigate privilege escalation by changing the owner and group of logs
+  with "su" option. Reported by Wolfgang Hotwagner.
+  (Closes: #928304) (CVE-2019-11675)
+
+ -- Kentaro Hayashi   Thu, 09 May 2019 22:44:57 +0900
+
 groonga (9.0.0-1) unstable; urgency=medium
 
   * New upstream version 9.0.0
diff -Nru groonga-9.0.0/debian/groonga-httpd.logrotate 
groonga-9.0.0/debian/groonga-httpd.logrotate
--- groonga-9.0.0/debian/groonga-httpd.logrotate2019-02-09 
22:12:32.0 +0900
+++ groonga-9.0.0/debian/groonga-httpd.logrotate2019-05-09 
22:43:28.0 +0900
@@ -1,11 +1,11 @@
 /var/log/groonga/httpd/*.log {
+su groonga groonga
 daily
 missingok
 rotate 30
 compress
 delaycompress
 notifempty
-create 640 groonga groonga
 sharedscripts
 postrotate
 . /etc/default/groonga-httpd
diff -Nru groonga-9.0.0/debian/groonga-server-gqtp.logrotate 
groonga-9.0.0/debian/groonga-server-gqtp.logrotate
--- groonga-9.0.0/debian/groonga-server-gqtp.logrotate  2019-02-09 
22:12:32.0 +0900
+++ groonga-9.0.0/debian/groonga-server-gqtp.logrotate  2019-05-09 
22:43:28.0 +0900
@@ -1,11 +1,11 @@
 /var/log/groonga/*-gqtp.log {
+su groonga groonga
 daily
 missingok
 rotate 30
 compress
 delaycompress
 notifempty
-create 640 groonga groonga
 sharedscripts
 postrotate
 . /etc/default/groonga-server-gqtp
diff -Nru groonga-9.0.0/debian/changelog groonga-9.0.0/debian/changelog
--- groonga-9.0.0/debian/changelog	2019-02-09 22:13:00.0 +0900
+++ groonga-9.0.0/debian/changelog	2019-05-09 22:44:57.0 +0900
@@ -1,3 +1,13 @@
+groonga (9.0.0-1+deb10u1) testing-proposed-updates; urgency=medium
+
+  * debian/groonga-httpd.logrotate
+debian/groonga-server-gqtp.logrotate
+- Mitigate privilege escalation by changing the owner and group of logs
+  with "su" option. Reported by Wolfgang Hotwagner.
+  (Closes: #928304) (CVE-2019-11675)
+
+ -- Kentaro Hayashi   Thu, 09 May 2019 22:44:57 +0900
+
 groonga (9.0.0-1) unstable; urgency=medium
 
   * New upstream version 9.0.0
diff -Nru groonga-9.0.0/debian/groonga-httpd.logrotate groonga-9.0.0/debian/groonga-httpd.logrotate
--- groonga-9.0.0/debian/groonga-httpd.logrotate	2019-02-09 22:12:32.0 +0900
+++ groonga-9.0.0/debian/groonga-httpd.logrotate	2019-05-09 22:43:28.0 +0900
@@ -1,11 +1,11 @@
 /var/log/groonga/httpd/*.log {
+su groonga groonga
 daily
 missingok
 rotate 30
 compress
 delaycompress
 notifempty
-create 640 groonga groonga
 sharedscripts
 postrotate
 . /etc/default/groonga-httpd
diff -Nru groonga-9.0.0/debian/groonga-server-gqtp.logrotate groonga-9.0.0/debian/groonga-server-gqtp.logrotate
--- groonga-9.0.0/debian/groonga-server-gqtp.logrotate	2019-02-09 22:12:32.0 +0900
+++ groonga-9.0.0/debian/groonga-server-gqtp.logrotate	2019-05-09 22:43:28.0 +0900
@@ -1,11 +1,11 @@
 /var/log/groonga/*-gqtp.log {
+su groonga groonga
 daily
 missingok
 rotate 30
 compress
 delaycompress
 notifempty
-create 640 groonga groonga
 sharedscripts
 postrotate
 . /etc/default/groonga-server-gqtp

Bug#928714: bird6 next hop keep not forwarded to bgp neighbor

[Diego Arroyo]

Package: bird
Version: 1.6.3-2
Version: 1.6.5-1
Version: 1.6.6-1
Severity: normal

Dear Maintainer,

In a working environment with bgp and ipv4 I am configuring bgp for ipv6 
with similar configuration, but I cannot forward next hop.
I have tested on debian stable with bird 1.6.3-2 and on lab with debian 
buster and versions from buster (1.6.5-1) and sid (1.6.6-1)


Setup consists on 4 routers: 1 and 2 announce network to 3 and 4, that 
are provider-edge to made network public available.
Routers 1 and 2 use own ip for bgp protocol, but they also have a 
virtual IP for the network announce in order to have faster transition 
in case of one of our routers fail when it is not possible to have BFD 
(that is the reason of use "next hop keep" in this environment)


For IPv4 all works as expected and provider-edge routers learn announced 
network with next hop virtual ip, but for IPv6 only learns each node 
self IP independent of the configuration: none, next hop self or next 
hop keep.


I have replicated environment on lab to have access to all 4 routers and 
check if it could be a problem between bird to cisco communication (real 
setup provider-edge routers are cisco), but the problem happens also 
having all 4 routers with bird.


Also, Routers 1 and 2 belongs to one AS, and 3 and 4 belongs to a second 
AS.


Thanks and Best Regards,

Diego Arroyo

Bug#928664: lua-system has a dependency cycle with lua-busted

[Jason Pleau]

Hi

On Wed, May 8, 2019 at 10:27 AM Helmut Grohne  wrote:
>
> Source: lua-system
> Version: 0.2.1-1
> Severity: important
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> lua-system Build-Depends on lua-busted, which happens to depend on
> lua-system. This poses a dependency cycle and makes bootstrapping either
> impossible. The upshot is that lua-system only needs lua-busted for
> running unit tests. One can build lua-system with
> DEB_BUILD_OPTIONS=nocheck, then lua-busted and then the full lua-system.
> Easy. All we need to do here is annotate the dependency. Please consider
> applying the attached patch.
>
> Helmut


I'll be able to look at this in the coming days (maybe next week),
feel free to do an NMU in the meantime if I can't get to it fast
enough.

Thanks !

Bug#928713: ITP: libponapi-client-perl -- Client to a JSON:API v1.0 service

[merkys]

Package: wnpp
Owner: Andrius Merkys 
Severity: wishlist
Control: block -1 by 928694

* Package name    : libponapi-client-perl
  Version : 0.002011
  Upstream Author : Copyright: Mickey Nasriachi  et al.
* URL : https://metacpan.org/release/PONAPI-Client
* License : Artistic
  Programming Lang: Perl
  Description : Client to a JSON:API v1.0 service
 PONAPI::Client is a JSON:API compliant client; it should be able to
communicate
 with any API-compliant service.
 .
 The client does a handful of checks required by the spec, then uses Hijk to
 communicate with the service.
 .
 In most cases, all API methods return a response document:
 .
 my $response = $client->retrieve(...);
 .
 In list context however, all api methods will return the request status and
 the document:
 .
 my ($status, $response) = $client->retrieve(...)

PONAPI::Client is a JSONAPI client implemented in Perl.

Remark: This package is to be maintained in Debian Perl Group.

-- 
Andrius Merkys
Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325
LT-10257 Vilnius, Lithuania

Bug#928710: drkonqi: segfault after using reload button to get backtrace for dolphin

[Bernhard Übelacker]

Control: tags 928710 + upstream
Control: forwarded 928710 https://bugs.kde.org/show_bug.cgi?id=381644


Dear Maintainer,
above the upstream bug of this issue.

Kind regards,
Bernhard

Bug#928712: ASTERISK-28409 due enabled deprecated modules

[PICCORO McKAY Lenz]

Source: asterisk
Version: 1:16.2.1~dfsg-1
Severity: important
Tags: patch


when try to build the chan_vpb module i got taht error:
chan_vpb.cc:427:1: error: uninitialized const member
'ast_channel_tech::send_text_data' … quite xtrange … why?

 a attached patch its provided from upstream bug
https://issues.asterisk.org/jira/browse/ASTERISK-28409 with solution
from communitity here:
https://community.asterisk.org/t/build-problems-asterisk-16/79593/2

Description: ASTERISK-28409
 compiler dont like non-init vars struct
Author: PICCORO Lenz McKAY 

---
Origin: https://community.asterisk.org/t/build-problems-asterisk-16/79593/3
Bug: https://issues.asterisk.org/jira/browse/ASTERISK-28409
Bug-Debian:
Forwarded: yes

--- asterisk-16.2.1~dfsg.orig/channels/chan_vpb.cc
+++ asterisk-16.2.1~dfsg/channels/chan_vpb.cc
@@ -390,6 +390,10 @@ static struct ast_channel_tech vpb_tech
 .write_text = NULL,
 .func_channel_read = NULL,
 .func_channel_write = NULL,
+.get_pvt_uniqueid = NULL,
+.cc_callback = NULL,
+.pre_call = NULL,
+.send_text_data = NULL,
 };

 static struct ast_channel_tech vpb_tech_indicate = {
@@ -424,6 +428,10 @@ static struct ast_channel_tech vpb_tech_
 .write_text = NULL,
 .func_channel_read = NULL,
 .func_channel_write = NULL,
+.get_pvt_uniqueid = NULL,
+.cc_callback = NULL,
+.pre_call = NULL,
+.send_text_data = NULL,
 };

 #if defined(VPB_NATIVE_BRIDGING)


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
Description: ASTERISK-28409
 compiler dont like non-init vars struct
Author: PICCORO Lenz McKAY 

---
Origin: https://community.asterisk.org/t/build-problems-asterisk-16/79593/3
Bug: https://issues.asterisk.org/jira/browse/ASTERISK-28409
Bug-Debian: 
Forwarded: yes

--- asterisk-16.2.1~dfsg.orig/channels/chan_vpb.cc
+++ asterisk-16.2.1~dfsg/channels/chan_vpb.cc
@@ -390,6 +390,10 @@ static struct ast_channel_tech vpb_tech
 	.write_text = NULL,
 	.func_channel_read = NULL,
 	.func_channel_write = NULL,
+	.get_pvt_uniqueid = NULL,
+	.cc_callback = NULL,
+	.pre_call = NULL,
+	.send_text_data = NULL,
 };
 
 static struct ast_channel_tech vpb_tech_indicate = {
@@ -424,6 +428,10 @@ static struct ast_channel_tech vpb_tech_
 	.write_text = NULL,
 	.func_channel_read = NULL,
 	.func_channel_write = NULL,
+	.get_pvt_uniqueid = NULL,
+	.cc_callback = NULL,
+	.pre_call = NULL,
+	.send_text_data = NULL,
 };
 
 #if defined(VPB_NATIVE_BRIDGING)

Bug#928681: gpsd.service files lacks WantedBy=multi-user.target

[Lisandro Damián Nicanor Pérez Meyer]

Control: tag -1 patch

El jueves, 9 de mayo de 2019 02:56:07 -03 Bernd Zeimetz escribió:
> Am 9. Mai 2019 03:15:08 MESZ schrieb "Lisandro Damián Nicanor Pérez Meyer" 
> :
[snip]
> >> Why?  gpsd should never ever be started automatically.
> >
> >I really don't want to sound aggressive nor anoying here here, but
> >just want to make use of a real-case example. Embedded system running
> >Debian in the middle of nowhere without internet connection and no
> >real time clock. GPS has a backup battery that helps maintain it's
> >clock when not powered, so it will have a valid time as soon as it's
> >being turned on. System starts and gpsd is used as fast as possible to
> >get data into ntp (needs -n). No gpsd clients are present, so nobody
> >will call it's socket.
> 
> Gpsdctl will do this for you,  when triggered by udev.

Except in the cases when udev can't handle it.
 
> >> Actually I think the solution you are looking for is to configure
> >
> >udev to handle your gps device properly. Unfortunately most gps devices
> >use standard usb to serial converters,  so we can't handle them all or
> >it will break other things.
> >
> >For those use cases there is gpsd's -n option, like in my example
> >above.
> 
> You can do this,  but this is neither how upstream intends this to work nor
> how you should do this. Udev is the proper way,  then unplugging and
> attaching the GPS will also work.

Oh, I now see why we might be disagreeing. I actually came to this because
we where discussing this in gpsd-dev. I'm not entirely sure to which exact
point you are referring, so:

- The -n option: this option is actually intended for those use cases where
  (a) you need to set up the system clock through gpsd and
  (b) when the user has a device that can't be detected by udev. I have
  actually been accepted a patch in order to clarify this a few days ago:



- Using systemd. I know that upstream developers don't precisely like systemd,
  but doesn't means it can be used. Actually it's a point in which we even
  agree with Fedora maintainers [a] and Gary Miller even asked for a more
  detailed way to set this up so it can be documented [b]. Actually from that
  same mail one could say that upstream does not likes the gpsd.socket unit
  file behavior, but I think we both agree that this works as expected.

[a] 
[b] 

> For those few cases where this doesn't work,  I think modifying a Systemd
> unit is no problem at all.

We can make it not even simpler but even (almost) distro-agnostic. I've
attached a patch for this (also created a merge request in your github
repo in case it fits you better). As you can see it's pretty straightforward,
just keep the WantedBy target in the unit file and use dh_installsystemd to
let the unit file be installed but not enabled nor started.

I have tested this in an up to date buster installation without issues.

**Please note**: with the current gpsd package in buster, and at least on
my system, gpsd will get started upon installation, but will not if the
machine is later rebooted. The same will keep happening with the attached
patch. I'm using a virtual machine to test, so that might be related.

Really trying to get the best for our users, Lisandro.

-- 
Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/
From 994ca106856edda4376b028bbbd6afc6d893485c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Lisandro=20Dami=C3=A1n=20Nicanor=20P=C3=A9rez=20Meyer?=
 
Date: Wed, 8 May 2019 23:47:41 -0300
Subject: [PATCH] Allow gpsd.service to be enabled by the admin at boot time.

Be sure to keep it disabled. The admin needs to explicitely start
it if needed.
---
 debian/changelog| 8 
 debian/patches/full-systemd-support | 5 ++---
 debian/rules| 3 ++-
 3 files changed, 12 insertions(+), 4 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 16bb69795..773da9499 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+gpsd (3.17-6.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Allow a sysadmin to start gpsd.service at boot time by enabling the unit
+file, keeping it disabled at package installation (Closes: #928681).
+
+ -- Lisandro Damián Nicanor Pérez Meyer   Wed, 08 May 2019 23:43:41 -0300
+
 gpsd (3.17-6) unstable; urgency=medium
 
   * [0a8e4e18] Pull json fixes from upstream to fix a stack-based
diff --git a/debian/patches/full-systemd-support b/debian/patches/full-systemd-support
index 4624e110a..0fd20724c 100644
--- a/debian/patches/full-systemd-support
+++ b/debian/patches/full-systemd-support
@@ -1,6 +1,6 @@
 --- a/systemd/gpsd.service
 +++ b/systemd/gpsd.service
-@@ -7,9 +7,7 @@ After=chronyd.service
+@@ -7,8 +7,7 @@ 

Bug#928711: unblock: [pre-approval] cyrus-imapd/3.0.8-5

[Xavier Guimard]

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

Please unblock package cyrus-imapd

Hi all,

we are going to fix #927142 (Cyrus-Imapd RC bug). I noticed also that
there are many spelling errors in this package. Do you think I can add a
this spelling error patch (joined) or upload a minimal change?

Cheers,
Xavier

unblock cyrus-imapd/3.0.8-5

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

Kernel: Linux 4.14.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Description: 
Author: Xavier Guimard 
Forwarded: https://github.com/cyrusimap/cyrus-imapd/issues/2753
Last-Update: 2019-05-09

--- a/backup/lcb_compact.c
+++ b/backup/lcb_compact.c
@@ -362,7 +362,7 @@
 }
 
 /* don't need this record */
-syslog(LOG_DEBUG, "%s: pruning stale MAILBOX RECORD for guid %s",
+syslog(LOG_DEBUG, "%s: prunning stale MAILBOX RECORD for guid %s",
   __func__, guid);
 dlist_unstitch(record, ki);
 dlist_unlink_files(ki);
--- a/doc/html/_sources/imap/download/release-notes/2.2/2.2.x.txt
+++ b/doc/html/_sources/imap/download/release-notes/2.2/2.2.x.txt
@@ -70,12 +70,12 @@
 Changes to the Cyrus IMAP Server since 2.2.5
 
 *   Fix a bug in the proxy code where a backend connection might get closed 
twice
-*   Improved consistancy checking in chk_cyrus
+*   Improved consistency checking in chk_cyrus
 *   Fix segfault in APPEND code
 *   Fix a bug with an interaction between sieve and unixhierarchysep
 *   Fix a file descriptor leak in the quotadb code
 *   Fix a triggered assertation in service-thread services
-*   Add a number of internal consistancy checks to the skiplist code
+*   Add a number of internal consistency checks to the skiplist code
 *   Allow mbpath to handle virtual domains
 *   Fix various MANAGESIEVE client authentication issues
 *   Other minor fixes
@@ -143,7 +143,7 @@
 
 Changes to the Cyrus IMAP Server since 2.1.x
 
-*   There have been extensive performance and consistancy changes to the 
configuration subsystem. This will both ensure greater consistancy between the 
documentation and the code, as well as a more standard format for specifing 
service-specific configuration options in imapd.conf. Important changes are 
detailed here:
+*   There have been extensive performance and consistency changes to the 
configuration subsystem. This will both ensure greater consistency between the 
documentation and the code, as well as a more standard format for specifing 
service-specific configuration options in imapd.conf. Important changes are 
detailed here:
 *   The tls_[service]_* configuration options have been removed. Now use 
[servicename]_tls_*, where servicename is the service identifier from 
cyrus.conf for that particular process.
 *   Administrative groups (e.g. admins and lmtp_admins) no longer union, 
service groups completely override the generic group.
 *   lmtp_allowplaintext is no longer a defined parameter and must be 
specified using the service name of your lmtp process if you require a specific 
value
--- a/doc/html/_sources/imap/reference/admin/murder/murder-installation.txt
+++ b/doc/html/_sources/imap/reference/admin/murder/murder-installation.txt
@@ -170,7 +170,7 @@
 If somehow a mailbox exists on two (or more) backend servers, each
 time one of them synchronizes its database that backend server will
 become authoritative. Though this should not happen during normal
-operation of the murder (because of the consistancy guarantees of
+operation of the murder (because of the consistency guarantees of
 the MUPDATE protocol, and the fact that mailbox operations are
 denied if the mupdate master is down), it is possible when first
 creating the mupdate database or when bringing a new backend server
--- a/doc/html/_sources/imap/reference/faqs/o-berkeleydb.txt
+++ b/doc/html/_sources/imap/reference/faqs/o-berkeleydb.txt
@@ -14,13 +14,13 @@
 hour, and more often on busy sites. 
 
 The other reason is that your :ref:`deliver.db may be very large 
`. This is 
-solvable by increasing the pruning interval (the -E parameter to 
+solvable by increasing the prunning interval (the -E parameter to 
 ctl_deliver, which you should run on a regular basis), or (in a pinch) 
 by just removing the database (since the effects of losing it do not 
 prevent operation, they just cause vacation messages to be resent, and 
 duplicate delivery suppression to possibly deliver duplicates). 
 
-* "by increasing the pruning interval": My understanding is that the 
+* "by increasing the prunning interval": My understanding is that the 
   

Bug#928686: systemd: XFS filesystem errors when using systemd suspend-then-hibernate target

[Shubhra Prakash Nandi]

Hi, I initially did consider this bug as a XFS filesystem bug but after
searching online forums I found this bug was found quite sometime back
i.e. the issue of freezing XFS threads by the Linux kernel but the fix
was incorporated in the XFS as per the following links


https://forums.opensuse.org/showthread.php/513158-Suspend-Not-Functioning-(XFS-Related-)


https://bugzilla.opensuse.org/show_bug.cgi?id=962250

If this issue is still not fixed in the kernel I would be happy to tag
this to kernel package.


-Original Message-
From: Michael Biebl 
To: Shubhra Prakash Nandi , 
928...@bugs.debian.org
Subject: Re: Bug#928686: systemd: XFS filesystem errors when using
systemd suspend-then-hibernate target
Date: Wed, 8 May 2019 23:40:09 +0200

Am 08.05.2019 um 23:06 schrieb Shubhra Prakash Nandi:
> Package: systemd
> Version: 241-3
> Severity: important
> 
> Dear Maintainer,
> 
> I saw XFS errors in syslog as given below when I updated suspend
> target in logind.conf to use suspend-then-hibernate instead. 
> These errors do not appear when I use only suspend target or suspend
> sedation solution as given in this Debian wiki - 
> https://wiki.debian.org/SystemdSuspendSedation
>  which is basically an alternative to suspend-then-hibernate systemd
> target.
> 
> XFS errors happen irrespective to when suspend level is s2idle or
> s2ram (deep).
> 
> I expect suspend-then-hibernate should work similar to
> SystemdSuspendSedation solution given in Debian wiki where no XFS
> filesystem errors appear.
> 
> May  4 00:04:09 my-pc kernel: [  332.306253] PM: suspend entry (deep)
> May  4 00:04:09 my-pc systemd-sleep[5254]: Suspending system...
> May  4 00:04:10 my-pc kernel: [  332.306257] PM: Syncing filesystems
> ... done.
> May  4 00:04:10 my-pc kernel: [  333.478986] (NULL device *):
> firmware: direct-loading firmware iwlwifi-9000-pu-b0-jf-b0-38.ucode
> May  4 00:04:30 my-pc kernel: [  333.542791] (NULL device *):
> firmware: direct-loading firmware i915/kbl_dmc_ver1_04.bin
> May  4 00:04:30 my-pc kernel: [  333.543080] Freezing user space
> processes ... (elapsed 0.003 seconds) done.
> May  4 00:04:30 my-pc kernel: [  333.546820] OOM killer disabled.
> May  4 00:04:30 my-pc kernel: [  333.546821] Freezing remaining
> freezable tasks ... 
> May  4 00:04:30 my-pc kernel: [  353.550044] Freezing of tasks failed
> after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0):
> May  4 00:04:30 my-pc kernel: [  353.550073] xfsaild/dm-
> 7D0   775  2 0x8000
> May  4 00:04:30 my-pc kernel: [  353.550079] Call Trace:
> May  4 00:04:30 my-pc kernel: [  353.550095]  ?
> __schedule+0x2a2/0x870
> May  4 00:04:30 my-pc kernel: [  353.550101]  schedule+0x28/0x80
> May  4 00:04:30 my-pc kernel:
> [  353.550106]  schedule_timeout+0x26d/0x390
> May  4 00:04:30 my-pc kernel:
> [  353.550113]  wait_for_completion+0x11f/0x190
> May  4 00:04:30 my-pc kernel: [  353.550121]  ? wake_up_q+0x70/0x70
> May  4 00:04:30 my-pc kernel: [  353.550217]  ?
> __xfs_buf_submit+0x122/0x240 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550290]  ?
> xfs_buf_read_map+0x106/0x170 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550372]  ?
> xfs_trans_read_buf_map+0xaa/0x2e0 [xfs]
> May  4 00:04:30 my-pc kernel:
> [  353.550444]  xfs_buf_iowait+0x22/0xd0 [xfs]
> May  4 00:04:30 my-pc kernel:
> [  353.550516]  __xfs_buf_submit+0x122/0x240 [xfs]
> May  4 00:04:30 my-pc kernel:
> [  353.550585]  xfs_buf_read_map+0x106/0x170 [xfs]
> May  4 00:04:30 my-pc kernel:
> [  353.550667]  xfs_trans_read_buf_map+0xaa/0x2e0 [xfs]
> May  4 00:04:30 my-pc kernel:
> [  353.550736]  xfs_imap_to_bp+0x67/0xd0 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550814]  xfs_iflush+0x10f/0x240
> [xfs]
> May  4 00:04:30 my-pc kernel:
> [  353.550893]  xfs_inode_item_push+0x13c/0x190 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.550971]  xfsaild+0x3a4/0x7e0
> [xfs]
> May  4 00:04:30 my-pc kernel: [  353.551048]  ?
> xfs_trans_ail_cursor_first+0x80/0x80 [xfs]
> May  4 00:04:30 my-pc kernel: [  353.551054]  kthread+0x112/0x130
> May  4 00:04:30 my-pc kernel: [  353.551059]  ?
> kthread_bind+0x30/0x30
> May  4 00:04:30 my-pc kernel: [  353.551065]  ret_from_fork+0x35/0x40
> May  4 00:04:30 my-pc kernel: [  353.551146] Restarting kernel
> threads ... done.
> May  4 00:04:30 my-pc kernel: [  353.552574] OOM killer enabled.
> May  4 00:04:30 my-pc kernel: [  353.552575] Restarting tasks ...
> done.

This looks like a kernel problem, not a systemd problem.
Can you elaborate why you filed this against systemd?



-- 

Regards,
Shubhra Prakash Nandi

Bug#927142: Cyrus-Imapd expel from Buster?

[Xavier]

Le 09/05/2019 à 15:34, Anthony Prades a écrit :
> Sieve patch added to master branch on salsa.
> 
> For needed upgrade steps commit
> (https://salsa.debian.org/debian/cyrus-imapd/commit/e76b566f92d7153a053f7e03f7c406e64970cb3e),
> if you're agree, I'll merge it, upgrade changelog...
> But I'm not sure if it's ok to do like this in postinst...
> 
> Anthony

My team will test this soon.

Bug#927142: Cyrus-Imapd expel from Buster?

[Anthony Prades]

Sieve patch added to master branch on salsa.

For needed upgrade steps commit
(https://salsa.debian.org/debian/cyrus-imapd/commit/e76b566f92d7153a053f7e03f7c406e64970cb3e),
if you're agree, I'll merge it, upgrade changelog...
But I'm not sure if it's ok to do like this in postinst...

Anthony

On 5/9/19 3:30 PM, Xavier wrote:
> Le 09/05/2019 à 15:13, Anthony Prades a écrit :
>> Hi,
>>
>> I'll add this patch. We use it in production and it works fine.
>>
>> For upgrade steps, what do you think about:
>> https://salsa.debian.org/debian/cyrus-imapd/commit/e76b566f92d7153a053f7e03f7c406e64970cb3e
>>
>> Anthony
> Thanks, that's exactly what I was looking for \o/ !
>
> Should we consider that this patch can close this bug ? If yes, I'll do
> upload+unblock

Bug#927142: Cyrus-Imapd expel from Buster?

[Xavier]

Le 09/05/2019 à 15:13, Anthony Prades a écrit :
> Hi,
> 
> I'll add this patch. We use it in production and it works fine.
> 
> For upgrade steps, what do you think about:
> https://salsa.debian.org/debian/cyrus-imapd/commit/e76b566f92d7153a053f7e03f7c406e64970cb3e
> 
> Anthony

Thanks, that's exactly what I was looking for \o/ !

Should we consider that this patch can close this bug ? If yes, I'll do
upload+unblock

Bug#928622: autodep8 integration with dh

[Antonio Terceiro]

On Thu, May 09, 2019 at 02:03:50PM +0200, Paul Gevers wrote:
> Hi Antonio,
> 
> On 09-05-2019 13:59, Antonio Terceiro wrote:
> >> Actually, I don't know where this mapping is documented, except for in
> >> the code.
> > 
> > the mapping comes from the name that was chosen by whoever implement the
> > corresponding support in autodep8. In this case "go" was chosen:
> 
> No offence, but I don't see any mapping there. If Daniel would use
> "Testsuite: autopkgtest-pkg-dkg-is-great" in his debian/control stanza,
> it would still be detected as go by autodep8 and tested by autopkgtest.

Ah, right. What happens is that language support provides two things:
one is the name, what is used if recognized. another part is a program
that autodetects the type of package from its contents, by looking for
specific files, or the contents of debian/control.

If the package declares `Testsuite: autopkgtest-pkg-$foo` and $foo is
known, then that is used. Otherwise, the autodetection program for each
language is tried. Maybe this autodetection is too much magic and we
want to get rid of it in the the long run, but OTOH that is what allowed
us to start testing a bunch of packages before having the Testsuite:
fields in place.

So, the mapping consists of two parts:

- the name of the directoty under /usr/share/autodep8/support/, which is
  matched against `Testsuite: autopkgtest-pkg-$foo`
- if the above fails, the autodetection script
  (/usr/share/autodep8/support/$foo/detect, for each support $foo) is
  executed, and if if exits with 0 then $foo is assumed to be the
  language of the package.

> [...]
> 
> >> P.s. we may need to improve this logic, I think the Testsuite header
> >> should explain this better. I.e. it should be something like "Testsuite:
> >> autopkgtest-autodep8"
> > 
> > do you mean supporting autopkgtest-autodep8-$foo alongside
> > autopkgtest-pkg-$foo?
> 
> No, really plain "Testsuite: autopkgtest-autodep8". autopkgtest and
> other consumers of that field don't need to know which language it is
> they are testing. Just that it needs autodep8 to detect what it is and
> how to test it.

OK, makes sense.


signature.asc
Description: PGP signature

Bug#927142: Cyrus-Imapd expel from Buster?

[Xavier]

Le 09/05/2019 à 15:10, Ondřej Surý a écrit :
> Xavier,
> 
> feel free to ask for membership in salsa and add yourself to Uploaders and do 
> the upload.
> 
> I haven’t used cyrus-imapd in years, so I am maintaining it just out of 
> inertia and because nobody stepped up until now. So thank you very mich for 
> caring.
> 
> Ondrej
> --
> Ondřej Surý 

Thanks,

My problem here is that I'm not fluent in C language/compilation. I'll
do my best however ;-)

I'm waiting for tests before uploading this. I created a "tmp" branch
for now.

Bug#927142: Cyrus-Imapd expel from Buster?

[Anthony Prades]

Hi,

I'll add this patch. We use it in production and it works fine.

For upgrade steps, what do you think about:
https://salsa.debian.org/debian/cyrus-imapd/commit/e76b566f92d7153a053f7e03f7c406e64970cb3e

Anthony

On 5/9/19 2:46 PM, Xavier wrote:
> Le 09/05/2019 à 10:52, Xavier a écrit :
>>
>> Le 09/05/2019 à 10:13, Ondřej Surý a écrit :
>>> Hi Xavier,
>>>
>>> yes, the comaintainers are really sought.
>>>
>>> The emails here should reset the autoremoval status, so if you have time to 
>>> fix this bug, it doesn’t need to be downgraded, just fixed...
>>>
>>> Ondrej
>>> --
>>> Ondřej Surý
>>> ond...@sury.org
>>>
>>>
>>>
 On 9 May 2019, at 15:04, Xavier  wrote:

 Le 09/05/2019 à 06:37, Xavier a écrit :
> Hi all,
>
> I'm afraid to see that Cyrus-Imapd is going to be out of Buster. Sorry,
> I can't help here, but can this bug be considered as "important" instead
> of "serious" to avoid expel?
>
> Cheers,
> Xavier
 Hi all,

 I just saw that Cyrus-Imapd is RFA. Since I need it here (~120.000
 mailboxes), I can take co-maintenance (and think that this bug should be
 downgraded to "important" since only Sieve part of Cyrus-Imapd is
 affected and there is no CVE).

 Cheers,
 Xavier
>> Following upstream commits, this patch may fix the problem:
>>
>> diff --git a/imap/lmtp_sieve.c b/imap/lmtp_sieve.c
>> index 4c3bbc3b7..9ba030f38 100644
>> --- a/imap/lmtp_sieve.c
>> +++ b/imap/lmtp_sieve.c
>> @@ -414,7 +414,7 @@ static int sieve_redirect(void *ac,
>>  /* if we have a msgid, we can track our redirects */
>>  if (m->id) {
>>  snprintf(buf, sizeof(buf), "%s-%s", m->id, rc->addr);
>> -sievedb = make_sieve_db(mbname_userid(sd->mbname));
>> +sievedb = make_sieve_db(mbname_recipient(sd->mbname,
>> ((deliver_data_t *) mc)->ns));
>>
>>  dkey.id = buf;
>>  dkey.to = sievedb;
>> @@ -496,7 +496,7 @@ static int sieve_reject(void *ac,
>>  body = msg_getheader(md, "original-recipient");
>>  origreceip = body ? body[0] : NULL;
>>  if ((res = send_rejection(md->id, md->return_path,
>> -  origreceip, mbname_userid(sd->mbname),
>> +  origreceip, mbname_recipient(sd->mbname,
>> ((deliver_data_t *) mc)->ns),
>>rc->msg, md->data)) == 0) {
>>  snmp_increment(SIEVE_REJECT, 1);
>>  syslog(LOG_INFO, "sieve rejected: %s to: %s",
>> @@ -735,7 +735,7 @@ static int send_response(void *ac,
>>  while (waitpid(sm_pid, _stat, 0) < 0);
>>
>>  if (sm_stat == 0) { /* sendmail exit value */
>> -sievedb = make_sieve_db(mbname_userid(sdata->mbname));
>> +sievedb = make_sieve_db(mbname_recipient(sdata->mbname,
>> ((deliver_data_t *) mc)->ns));
>>
>>  dkey.id = outmsgid;
>>  dkey.to = sievedb;
> Packages with this patch are ready here:
> https://people.debian.org/~yadd/cyrus-imapd/
>
> Kim-Alexander, could you test them ?
>

Bug#927142: Cyrus-Imapd expel from Buster?

[Ondřej Surý]

Xavier,

feel free to ask for membership in salsa and add yourself to Uploaders and do 
the upload.

I haven’t used cyrus-imapd in years, so I am maintaining it just out of inertia 
and because nobody stepped up until now. So thank you very mich for caring.

Ondrej
--
Ondřej Surý 

> On 9 May 2019, at 19:46, Xavier  wrote:
> 
>> Le 09/05/2019 à 10:52, Xavier a écrit :
>> 
>> 
>>> Le 09/05/2019 à 10:13, Ondřej Surý a écrit :
>>> Hi Xavier,
>>> 
>>> yes, the comaintainers are really sought.
>>> 
>>> The emails here should reset the autoremoval status, so if you have time to 
>>> fix this bug, it doesn’t need to be downgraded, just fixed...
>>> 
>>> Ondrej
>>> --
>>> Ondřej Surý
>>> ond...@sury.org
>>> 
>>> 
>>> 
 On 9 May 2019, at 15:04, Xavier  wrote:
 
 Le 09/05/2019 à 06:37, Xavier a écrit :
> Hi all,
> 
> I'm afraid to see that Cyrus-Imapd is going to be out of Buster. Sorry,
> I can't help here, but can this bug be considered as "important" instead
> of "serious" to avoid expel?
> 
> Cheers,
> Xavier
 
 Hi all,
 
 I just saw that Cyrus-Imapd is RFA. Since I need it here (~120.000
 mailboxes), I can take co-maintenance (and think that this bug should be
 downgraded to "important" since only Sieve part of Cyrus-Imapd is
 affected and there is no CVE).
 
 Cheers,
 Xavier
>> 
>> Following upstream commits, this patch may fix the problem:
>> 
>> diff --git a/imap/lmtp_sieve.c b/imap/lmtp_sieve.c
>> index 4c3bbc3b7..9ba030f38 100644
>> --- a/imap/lmtp_sieve.c
>> +++ b/imap/lmtp_sieve.c
>> @@ -414,7 +414,7 @@ static int sieve_redirect(void *ac,
>> /* if we have a msgid, we can track our redirects */
>> if (m->id) {
>> snprintf(buf, sizeof(buf), "%s-%s", m->id, rc->addr);
>> -sievedb = make_sieve_db(mbname_userid(sd->mbname));
>> +sievedb = make_sieve_db(mbname_recipient(sd->mbname,
>> ((deliver_data_t *) mc)->ns));
>> 
>> dkey.id = buf;
>> dkey.to = sievedb;
>> @@ -496,7 +496,7 @@ static int sieve_reject(void *ac,
>> body = msg_getheader(md, "original-recipient");
>> origreceip = body ? body[0] : NULL;
>> if ((res = send_rejection(md->id, md->return_path,
>> -  origreceip, mbname_userid(sd->mbname),
>> +  origreceip, mbname_recipient(sd->mbname,
>> ((deliver_data_t *) mc)->ns),
>>   rc->msg, md->data)) == 0) {
>> snmp_increment(SIEVE_REJECT, 1);
>> syslog(LOG_INFO, "sieve rejected: %s to: %s",
>> @@ -735,7 +735,7 @@ static int send_response(void *ac,
>> while (waitpid(sm_pid, _stat, 0) < 0);
>> 
>> if (sm_stat == 0) { /* sendmail exit value */
>> -sievedb = make_sieve_db(mbname_userid(sdata->mbname));
>> +sievedb = make_sieve_db(mbname_recipient(sdata->mbname,
>> ((deliver_data_t *) mc)->ns));
>> 
>> dkey.id = outmsgid;
>> dkey.to = sievedb;
> 
> Packages with this patch are ready here:
> https://people.debian.org/~yadd/cyrus-imapd/
> 
> Kim-Alexander, could you test them ?
> 

Bug#928622: autodep8 integration with dh

[Antonio Terceiro]

On Thu, May 09, 2019 at 09:32:32AM +0200, Paul Gevers wrote:
> Hi Daniel,
> 
> On 08-05-2019 23:01, Daniel Kahn Gillmor wrote:
> > Thanks for the pointer to this documentation!  I still have no idea how
> > to apply this for a go package like slt (where i encountered this).  Do
> > i use "Testsuite: autopkgtest-pkg-go" or "Testsuite:
> > autopkgtest-pkg-golang" or something else?  Where would i learn what the
> > appropriate mapping is?
> 
> Actually, I don't know where this mapping is documented, except for in
> the code.

the mapping comes from the name that was chosen by whoever implement the
corresponding support in autodep8. In this case "go" was chosen:

https://salsa.debian.org/ci-team/autodep8/commit/c4e122a5b4e03f353d5026438ef88691e214ad53

> It would be good to document it indeed.

I totally agree that the documentation needs improvement, in both
autodep8 itself and autopkgtest. But it also helps if the
language-specific teams documents this on their side (templates for
debian/* etc).

> If I read the code of autopkgtest correctly, as long as your package is
> supported by autodep8, "Testsuite: autopkgtest-pkg-" should be enough,
> anything after the second hyphen is purely for the user. That said,
> autodep8 uses autopkgtest-pkg-go in its tests.
> 
> paul@testavoira ~ $ rgrep -A1 autopkgtest-pkg- /usr/share/autopkgtest/
> /usr/share/autopkgtest/lib/testdesc.py:if
> 'autopkgtest-pkg-' in testsuite:
> /usr/share/autopkgtest/lib/testdesc.py-
> try_autodep8 = True
> 
> Paul
> 
> P.s. we may need to improve this logic, I think the Testsuite header
> should explain this better. I.e. it should be something like "Testsuite:
> autopkgtest-autodep8"

do you mean supporting autopkgtest-autodep8-$foo alongside
autopkgtest-pkg-$foo?


signature.asc
Description: PGP signature

Bug#927142: Cyrus-Imapd expel from Buster?

[Xavier]

Le 09/05/2019 à 10:52, Xavier a écrit :
> 
> 
> Le 09/05/2019 à 10:13, Ondřej Surý a écrit :
>> Hi Xavier,
>>
>> yes, the comaintainers are really sought.
>>
>> The emails here should reset the autoremoval status, so if you have time to 
>> fix this bug, it doesn’t need to be downgraded, just fixed...
>>
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@sury.org
>>
>>
>>
>>> On 9 May 2019, at 15:04, Xavier  wrote:
>>>
>>> Le 09/05/2019 à 06:37, Xavier a écrit :
 Hi all,

 I'm afraid to see that Cyrus-Imapd is going to be out of Buster. Sorry,
 I can't help here, but can this bug be considered as "important" instead
 of "serious" to avoid expel?

 Cheers,
 Xavier
>>>
>>> Hi all,
>>>
>>> I just saw that Cyrus-Imapd is RFA. Since I need it here (~120.000
>>> mailboxes), I can take co-maintenance (and think that this bug should be
>>> downgraded to "important" since only Sieve part of Cyrus-Imapd is
>>> affected and there is no CVE).
>>>
>>> Cheers,
>>> Xavier
> 
> Following upstream commits, this patch may fix the problem:
> 
> diff --git a/imap/lmtp_sieve.c b/imap/lmtp_sieve.c
> index 4c3bbc3b7..9ba030f38 100644
> --- a/imap/lmtp_sieve.c
> +++ b/imap/lmtp_sieve.c
> @@ -414,7 +414,7 @@ static int sieve_redirect(void *ac,
>  /* if we have a msgid, we can track our redirects */
>  if (m->id) {
>  snprintf(buf, sizeof(buf), "%s-%s", m->id, rc->addr);
> -sievedb = make_sieve_db(mbname_userid(sd->mbname));
> +sievedb = make_sieve_db(mbname_recipient(sd->mbname,
> ((deliver_data_t *) mc)->ns));
> 
>  dkey.id = buf;
>  dkey.to = sievedb;
> @@ -496,7 +496,7 @@ static int sieve_reject(void *ac,
>  body = msg_getheader(md, "original-recipient");
>  origreceip = body ? body[0] : NULL;
>  if ((res = send_rejection(md->id, md->return_path,
> -  origreceip, mbname_userid(sd->mbname),
> +  origreceip, mbname_recipient(sd->mbname,
> ((deliver_data_t *) mc)->ns),
>rc->msg, md->data)) == 0) {
>  snmp_increment(SIEVE_REJECT, 1);
>  syslog(LOG_INFO, "sieve rejected: %s to: %s",
> @@ -735,7 +735,7 @@ static int send_response(void *ac,
>  while (waitpid(sm_pid, _stat, 0) < 0);
> 
>  if (sm_stat == 0) { /* sendmail exit value */
> -sievedb = make_sieve_db(mbname_userid(sdata->mbname));
> +sievedb = make_sieve_db(mbname_recipient(sdata->mbname,
> ((deliver_data_t *) mc)->ns));
> 
>  dkey.id = outmsgid;
>  dkey.to = sievedb;

Packages with this patch are ready here:
https://people.debian.org/~yadd/cyrus-imapd/

Kim-Alexander, could you test them ?

Bug#927324: status report and etc.

[hoxp18]

Dear maintainers,

I sent some related report.
Please take a look at #927094 additional report.

I personally do not send "done" on this,
but cannot continue testing by this machine anymore,
since I'll use the hardware for another purpose.

I just want to report about it here.

Regards.

Bug#927094: Status report and etc.

[hoxp18]

Dear maintainers,

Since I installed Buster in another Kaby Lake machine,
with almost same hardware/software configuration,
I write some additional/comparison report.

* This #927094: Stretch -> Buster dist--upgraded
* New: Buster weekly latest ISO clean install.
* Both: LVM over LUKS, on a same vendor same product series NVMe.

LVM
===

* dist-upgrade:  still saying lvm2-activation-generator related.
* clean-install: no lvm related warning (or above) logs.

Video on resume
===

Both on Kaby Lake iGPU -> HDMI selector -> (different) LCDs

* dist-upgrade:  still i2c NAK bailout logs, and blank on resumes.
 the other HDMI shared amd64 machine claims
 EDID checksum mismatch, blank on resumes sometimes.
 Now I think it would be my OLD LCD issue
 (except i2c logs.)
* clean-install: no i2c related logs. no blank on resume,
 but sometimes the last desktop shown
 instead of lock screen; hit key, then lock screen.

Firefox
===

* Now both boots at almost same speed compared with Stretch era.
  Still has 0.2~1sec window border area blanks at boot.

  My observation: improved around recent libc update (not sure).

ALPM


Not both amd64 machine, on other amd64 Buster testing.
It seems no data-corrupt/loss on ALPM enabled SATA SSDs.

Not so much tested, yet. almost debsums only.

My resource issue
=

I'll planning to use this testing machine for another purpose.

So, I think this report should be closed.

I personally do not send the "done" mail.

If you think this is done/verbose/useless any longer,
please just close this.

Thank you for your reading this. Have a nice day.

Regards.

Bug#928710: drkonqi: segfault after using reload button to get backtrace for dolphin

[Tim Small]

Package: drkonqi
Version: 5.14.5-1
Severity: normal

dolphin crashed, and I didn't have sufficient debug sym installed.  I
installed them, and then hit the "reload" button to re-do the backtrace,
at which point drkonqi crashed.

Backtrace below:

Application: drkonqi (drkonqi), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f7a21e0c840 (LWP 9084))]

Thread 4 (Thread 0x7f7a135bb700 (LWP 9113)):
#0  0x7f7a2609800c in futex_wait_cancelable (private=0, expected=0, 
futex_word=0x55f680cac388) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  0x7f7a2609800c in __pthread_cond_wait_common (abstime=0x0, 
mutex=0x55f680cac338, cond=0x55f680cac360) at pthread_cond_wait.c:502
#2  0x7f7a2609800c in __pthread_cond_wait (cond=0x55f680cac360, 
mutex=0x55f680cac338) at pthread_cond_wait.c:655
#3  0x7f7a1380be63 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#4  0x7f7a1380bbb7 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#5  0x7f7a26091fa3 in start_thread (arg=) at 
pthread_create.c:486
#6  0x7f7a26a4b4cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 3 (Thread 0x7f7a1b007700 (LWP 9095)):
#0  0x7f7a26a3c494 in __GI___libc_read (nbytes=16, buf=0x7f7a1b006b10, 
fd=7) at ../sysdeps/unix/sysv/linux/read.c:26
#1  0x7f7a26a3c494 in __GI___libc_read (fd=7, buf=0x7f7a1b006b10, 
nbytes=16) at ../sysdeps/unix/sysv/linux/read.c:24
#2  0x7f7a254e3aa0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x7f7a2549dc0f in g_main_context_check () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7f7a2549e0e0 in  () at /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#5  0x7f7a2549e25c in g_main_context_iteration () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#6  0x7f7a26f5287b in 
QEventDispatcherGlib::processEvents(QFlags) 
(this=0x7f7a14000b20, flags=...) at kernel/qeventdispatcher_glib.cpp:424
#7  0x7f7a26f0027b in 
QEventLoop::exec(QFlags) 
(this=this@entry=0x7f7a1b006d30, flags=..., flags@entry=...) at 
../../include/QtCore/../../src/corelib/global/qflags.h:140
#8  0x7f7a26d4fec6 in QThread::exec() (this=) at 
../../include/QtCore/../../src/corelib/global/qflags.h:120
#9  0x7f7a27d8c545 in  () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#10 0x7f7a26d59aa7 in QThreadPrivate::start(void*) (arg=0x7f7a27e0cd60) at 
thread/qthread_unix.cpp:367
#11 0x7f7a26091fa3 in start_thread (arg=) at 
pthread_create.c:486
#12 0x7f7a26a4b4cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 2 (Thread 0x7f7a2104c700 (LWP 9092)):
#0  0x7f7a26a40819 in __GI___poll (fds=0x7f7a2104bc78, nfds=1, timeout=-1) 
at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x7f7a2542acf7 in  () at /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x7f7a2542c91a in xcb_wait_for_event () at 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7f7a219aad79 in  () at /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#4  0x7f7a26d59aa7 in QThreadPrivate::start(void*) (arg=0x55f680a6fcd0) at 
thread/qthread_unix.cpp:367
#5  0x7f7a26091fa3 in start_thread (arg=) at 
pthread_create.c:486
#6  0x7f7a26a4b4cf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Thread 1 (Thread 0x7f7a21e0c840 (LWP 9084)):
[KCrash Handler]
#6  0x55f67f72a6e9 in BacktraceLine::type() const (this=0x55f680bd6f18) at 
./src/parser/backtraceline.h:59
#7  0x55f67f72a6e9 in GdbHighlighter::highlightBlock(QString const&) 
(this=0x7f7a1c009060, text=...) at ./src/gdbhighlighter.cpp:80
#8  0x7f7a27400f39 in  () at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#9  0x7f7a274010f8 in  () at /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#10 0x7f7a26f2a906 in QMetaObject::activate(QObject*, int, int, void**) 
(sender=0x55f680c98070, signalOffset=, 
local_signal_index=, argv=) at 
kernel/qobject.cpp:3771
#11 0x7f7a2762d40a in QTextDocument::contentsChange(int, int, int) () at 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#12 0x7f7a273bf4f1 in QTextDocumentPrivate::finishEdit() () at 
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#13 0x7f7a27a573f5 in  () at /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x7f7a27a33d89 in QTextEdit::append(QString const&) () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x55f67f719160 in BacktraceWidget::backtraceNewLine(QString const&) 
(this=, line=...) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:436
#16 0x7f7a26f2aa43 in QtPrivate::QSlotObjectBase::call(QObject*, void**) 
(a=0x7ffebddfb530, r=0x55f680ca2400, this=0x55f680c02910) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:376
#17 0x7f7a26f2aa43 in QMetaObject::activate(QObject*, int, int, void**) 
(sender=0x55f680b32710, signalOffset=, 
local_signal_index=, argv=) at 
kernel/qobject.cpp:3754
#18 0x55f67f766a45 in BacktraceGenerator::newLine(QString const&) 
(this=this@entry=0x55f680b32710, _t1=...) at 

Bug#903392: Preferred git branch structure when upstream moves from tarballs to git

[Ian Jackson]

(adding #903392)

Ben Finney writes ("Re: Preferred git branch structure when upstream moves from 
tarballs to git"):
> What I remain unconvinced of is the worth of abandoning the clean
> separation between an upstream source repository (whether Git repository
> or not) and a VCS repository for Debian packaging (typically in Git).

I disagree with this but I'm not really interested in arguing you out
of it.  As Ian Campbell says, dgit doesn't want to change your
workflow.  It wants to help you help *users* and *downstreams* to
change theirs, from tarballs+diffs to git.

My interest is to make that possible, *without* maintainers having to
change their workflows.

For your workflow, I see broadly two possibilities, depending what
representation you use for upstream source code:

 (i) You use upstream tarballs as your representation of the upstream
 source code, and do not use upstream git branches.

 If this is the case then the benefits for everyone in me
 implementing #903392 for you, and you then using `dgit
 push-source', are - frankly - limited.  The resulting dgit git
 branch would still contain imports of .orig tarballs, rather than
 the actual upstream git history.

 The user of `dgit clone' would get your *packaging* history,
 sure, but this is a much more minor benefit.

 (ii) You use upstream git history, and generate .orig tarballs
 with (say) git-deborig.

 Implementing #903392 for this case should be straightforward,
 provided that your .orig tarballs and the git branch actually are
 identical.  Furthermore, it would be very useful to someone who
 `dgit clone's one of your packages: they would get a full and
 proper git history which would work exactly as they expect.

 The question here would be: how do you manage the upstream git
 branch ?  dgit push would need to automatically find (or be told,
 but that would be a UI nuisance) the upstream git commit.

 (And if that upstream git commit is in a separate tree somewhere,
 dgit would have to find that tree, too.)

If you are roughly in situation (ii) then I am quite interested in
supporting your use of dgit push, eg by working on #903392.  Please
engage in that bug, and encourage others in a similar position to do
the same.

If you are currently in situation (i) then your adoption of dgit is a
low priority for me, since to provide really useful output from `dgit
clone' it would be necessary for you to change your workflow.  (I do
have a wip branch but it is a mess and not tested.  So if someone
wants to work on this, let me know.)

I am not really interested in arguing that people's workflows are
wrong; it is a very religious kind of topic.  Let us save that for a
bar conversation some time ...

HTH.

Ian.

-- 
Ian JacksonThese opinions are my own.

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

Bug#928709: clhep-doc: the page http://localhost/doc/clhep-doc/html/index.html is practically empty.

[nefedov]

Package: clhep-doc
Version: 2.1.4.1+dfsg-1
Severity: normal

 The start page /usr/share/doc/clhep-doc/html/index.html is useless.
 It contains only links to the official site.

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

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

Versions of packages clhep-doc depends on:
ii  libjs-jquery  3.3.1~dfsg-3

clhep-doc recommends no packages.

clhep-doc suggests no packages.

-- no debconf information

Bug#928622: autodep8 integration with dh

[Paul Gevers]

Hi Antonio,

On 09-05-2019 13:59, Antonio Terceiro wrote:
>> Actually, I don't know where this mapping is documented, except for in
>> the code.
> 
> the mapping comes from the name that was chosen by whoever implement the
> corresponding support in autodep8. In this case "go" was chosen:

No offence, but I don't see any mapping there. If Daniel would use
"Testsuite: autopkgtest-pkg-dkg-is-great" in his debian/control stanza,
it would still be detected as go by autodep8 and tested by autopkgtest.

[...]

>> P.s. we may need to improve this logic, I think the Testsuite header
>> should explain this better. I.e. it should be something like "Testsuite:
>> autopkgtest-autodep8"
> 
> do you mean supporting autopkgtest-autodep8-$foo alongside
> autopkgtest-pkg-$foo?

No, really plain "Testsuite: autopkgtest-autodep8". autopkgtest and
other consumers of that field don't need to know which language it is
they are testing. Just that it needs autodep8 to detect what it is and
how to test it.

Paul



signature.asc
Description: OpenPGP digital signature

Bug#880047: proposed nmu to revert change

[Peter Palfrader]

On Thu, 09 May 2019, Peter Palfrader wrote:

> I plan to revert the -5 change from this bug which has also been
> reverted in the stretch upload.

uploaded to delayed 5.
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#880047: proposed nmu to revert change

[Peter Palfrader]

I plan to revert the -5 change from this bug which has also been
reverted in the stretch upload.

It seems to be unnecessary.

diff -Nur postgrey-1.36-5/debian/changelog postgrey-1.36-5.1/debian/changelog
--- postgrey-1.36-5/debian/changelog2017-11-25 11:18:01.0 +0100
+++ postgrey-1.36-5.1/debian/changelog  2019-05-09 13:35:38.0 +0200
@@ -1,3 +1,14 @@
+postgrey (1.36-5.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Revert the 1.36-5 change due to a regression, discussed in #880047#.
+The same patch has also been included in 1.36-3+deb9u1 and reverted
+in 1.36-3+deb9u2.
+There is no point in creating a /var/run/postgrey/ to hold the pidfile
+as using /var/run/postgrey.pid seems to work just fine.
+
+ -- Peter Palfrader   Thu, 09 May 2019 13:35:38 +0200
+
 postgrey (1.36-5) unstable; urgency=medium
 
   * debian/postgrey.init: create /var/run/postgrey if it
diff -Nur postgrey-1.36-5/debian/postgrey.init 
postgrey-1.36-5.1/debian/postgrey.init
--- postgrey-1.36-5/debian/postgrey.init2017-11-25 11:18:01.0 
+0100
+++ postgrey-1.36-5.1/debian/postgrey.init  2019-05-09 13:35:08.0 
+0200
@@ -26,7 +26,7 @@
 DESC="postfix greylisting daemon"
 DAEMON_USER=postgrey
 
-PIDFILE=/var/run/postgrey/$DAEMON_NAME.pid
+PIDFILE=/var/run/$DAEMON_NAME.pid
 SCRIPTNAME=/etc/init.d/$DAEMON_NAME
 
 # Gracefully exit if the package has been removed.
@@ -55,14 +55,6 @@
 #   0 if daemon has been started
 #   1 if daemon was already running
 #   2 if daemon could not be started
-   if [ ! -d /var/run/postgrey/ ]
-   then
-mkdir /var/run/postgrey/
-chown $DAEMON_USER: /var/run/postgrey/
-chmod 0755 /var/run/postgrey/
-# Restore selinux context
-[ -x /sbin/restorecon ] && /sbin/restorecon /var/run/postgrey/
-   fi
 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON 
--test > /dev/null \
 || return 1
 start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- 
\


Cheers,
-- 
|  .''`.   ** Debian **
  Peter Palfrader   | : :' :  The  universal
 https://www.palfrader.org/ | `. `'  Operating System
|   `-https://www.debian.org/

Bug#910857: VM configurated with spice not starting at boot

[Vincent Danjean]

  Hi,

  I also have this problem. With machines configured with spice,
I can find in the log (/var/log/libvirt/qemu/.log at boot time:

[...]
char device redirected to /dev/pts/9 (label charserial0)
((null):6261): Spice-Warning **: reds.c:2489:reds_init_socket: 
getaddrinfo(127.0.0.1,5900): Address family for hostname not supported
2019-05-08T13:15:34.165013Z qemu-system-x86_64: failed to initialize spice 
server
2019-05-08 13:15:34.288+: shutting down, reason=failed
[the whole log is at the end of this message]

  I've no problem with VMs not using spice but all of VMs with spice
fail to start at boot time. If I start them after (generally with
virt-manager but sometimes with virsh), it works perfectly.
  It is a long outstanding bug. I tried to track it down when
systemd was not there yet, so I was able to start the services
one by one. It occurred that the problem disappeared if VMs was
started *after* the network.

  I think this is linked to the fact that the code is using
getaddrinfo with AI_ADDRCONFIG. See
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1492621
and https://bugzilla.redhat.com/show_bug.cgi?id=721350
for more info.

  In my case, I cannot just start the network before the VMs
as one of my VMs is my dhcp server... So I remove spice from
the config of VMs that must start early.
  However, I think there is a problem to mandate that a
not-localhost address exists on the system to allow one
to start a VM. Using VNC instead of Spice does not lead
to the same problem. And, if it is absolutely required,
the error message could be more informative at least...

  Regards,
Vincent


2019-05-08 13:15:33.956+: starting up libvirt version: 5.0.0, package: 2 
(Guido Günther  Sun, 07 Apr 2019 12:36:21 +0200), qemu 
version: 2.8.1(Debian 1:2.8+dfsg-6+deb9u5),
 kernel: 4.19.0-0.bpo.4-amd64, hostname: aya.danjean.fr
LC_ALL=C \
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
QEMU_AUDIO_DRV=spice \
/usr/bin/kvm \
-name guest=alastor,debug-threads=on \
-S \
-object 
secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-21-alastor/master-key.aes
 \
-machine pc-q35-2.8,accel=kvm,usb=off,vmport=off,dump-guest-core=off \
-cpu SandyBridge-IBRS \
-drive 
file=/usr/share/OVMF/OVMF_CODE.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive 
file=/var/lib/libvirt/qemu/nvram/alastor_VARS.fd,if=pflash,format=raw,unit=1 \
-m 4096 \
-realtime mlock=off \
-smp 1,sockets=1,cores=1,threads=1 \
-uuid 67098e3e-3351-4d4d-8434-15811c3ca035 \
-no-user-config \
-nodefaults \
-chardev 
socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-21-alastor/monitor.sock,server,nowait
 \
-mon chardev=charmonitor,id=monitor,mode=control \
-rtc base=utc,driftfix=slew \
-global kvm-pit.lost_tick_policy=delay \
-no-hpet \
-no-shutdown \
-global ICH9-LPC.disable_s3=1 \
-global ICH9-LPC.disable_s4=1 \
-boot strict=on \
-device 
ioh3420,port=0x10,chassis=1,id=pci.1,bus=pcie.0,multifunction=on,addr=0x2 \
-device i82801b11-bridge,id=pci.2,bus=pcie.0,addr=0x1e \
-device pci-bridge,chassis_nr=3,id=pci.3,bus=pci.2,addr=0x0 \
-device ioh3420,port=0x11,chassis=4,id=pci.4,bus=pcie.0,addr=0x2.0x1 \
-device ioh3420,port=0x12,chassis=5,id=pci.5,bus=pcie.0,addr=0x2.0x2 \
-device ioh3420,port=0x13,chassis=6,id=pci.6,bus=pcie.0,addr=0x2.0x3 \
-device ioh3420,port=0x14,chassis=7,id=pci.7,bus=pcie.0,addr=0x2.0x4 \
-device ioh3420,port=0x15,chassis=8,id=pci.8,bus=pcie.0,addr=0x2.0x5 \
-device ich9-usb-ehci1,id=usb,bus=pcie.0,addr=0x1d.0x7 \
-device 
ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pcie.0,multifunction=on,addr=0x1d
 \
-device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pcie.0,addr=0x1d.0x1 \
-device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pcie.0,addr=0x1d.0x2 \
-device virtio-scsi-pci,id=scsi0,bus=pci.5,addr=0x0 \
-device virtio-serial-pci,id=virtio-serial0,bus=pci.4,addr=0x0 \
-drive 
file=/dev/aya+raid1/kvm-alastor-root,format=raw,if=none,id=drive-scsi0-0-0-1,cache=none,aio=native
 \
-device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=1,write-cache=on
 \
-drive 
file=/dev/aya+raid1/kvm-alastor-disk2,format=raw,if=none,id=drive-scsi0-0-0-2,cache=none,aio=native
 \
-device 
scsi-hd,bus=scsi0.0,channel=0,scsi-id=0,lun=2,drive=drive-scsi0-0-0-2,id=scsi0-0-0-2,bootindex=2,write-cache=on
 \
-drive if=none,id=drive-sata0-0-0,media=cdrom,readonly=on \
-device ide-cd,bus=ide.0,drive=drive-sata0-0-0,id=sata0-0-0 \
-netdev tap,fd=39,id=hostnet0,vhost=on,vhostfd=41 \
-device 
virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:77:0a:00,bus=pci.1,addr=0x0 
\
-netdev tap,fd=42,id=hostnet1,vhost=on,vhostfd=43 \
-device 
virtio-net-pci,netdev=hostnet1,id=net1,mac=52:54:00:77:0a:01,bus=pci.7,addr=0x0 
\
-chardev pty,id=charserial0 \
-device isa-serial,chardev=charserial0,id=serial0 \
-chardev 
socket,id=charchannel0,path=/var/lib/libvirt/qemu/channel/target/domain-21-alastor/org.qemu.guest_agent.0,server,nowait
 \
-device 

Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook

[Santiago Vila]

On Thu, May 09, 2019 at 11:40:24AM +, Holger Levsen wrote:
> On Thu, May 09, 2019 at 12:56:18PM +0200, Santiago Vila wrote:
> > Hello Holger. I'd like to work on this issue.
> > 
> > My plan is to change "exit 1" to "exit 0" (as proposed) in both
> > stretch and buster. If that's not enough I will also add a
> > Breaks: debian-security-support (<= 2019.02.02~deb9u1) in base-files.
> 
> this is not enough. and no, if I had time to explain, I would fix it myself. 
> 
> again: we need a fix which works in buster only, without touching stretch.
> 
> we probably need to touch base-files in buster though.

The Breaks I'm offering in base-files will allow upgrades without
touching stretch. Updating the package in stretch will only be a small
improvement to not force a given upgrade path, but not the "fix".
The fix for upgrades from stretch is the Breaks in base-files.

But before I can write <= 2019.02.02~deb9u1 in base-files we should
make sure there are not bad versions in testing, because otherwise
"<= 2019.02.02~deb9u1" could be not enough.

Maybe we should let the current package propagate to testing before
going any further?

Thanks.

Bug#928172: debian-security-support: fails to upgrade from 'testing': dpkg: error: error executing hook

[Holger Levsen]

On Thu, May 09, 2019 at 12:56:18PM +0200, Santiago Vila wrote:
> Hello Holger. I'd like to work on this issue.
> 
> My plan is to change "exit 1" to "exit 0" (as proposed) in both
> stretch and buster. If that's not enough I will also add a
> Breaks: debian-security-support (<= 2019.02.02~deb9u1) in base-files.

this is not enough. and no, if I had time to explain, I would fix it myself. 

again: we need a fix which works in buster only, without touching stretch.

we probably need to touch base-files in buster though.


-- 
tschau,
Holger

---
   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#928333: RM: htslib [i386 hurd-i386 kfreebsd-i386] -- ANAIS; ROM; *i386 no longer supported upstream

[Ivo De Decker]

Control: retitle -1 RM: augustus, bedtools, cyvcf2, delly, dwgsim, fastqtl, 
hilive, nanopolish, qtltools, samtools, segemehl, smalt [i386] -- ANAIS; ROM; 
i386 no longer supported upstream

Hi,

On Thu, May 02, 2019 at 10:16:32AM +0100, Michael Crusoe wrote:
> Hello, this request is a repeat of 
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914991
> 
> The *i386 packages have somehow crept back in for all the 
> reverse-(build-)deps of htslib binary packages.
> 
> Could the removal of *i386 binary packages that (build-)depend on any of the 
> htslib binary packages be repeated?
> 
> Thanks. See also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927850

The list of source package that have binaries on i386 affected by this is:

augustus
bedtools
delly
dwgsim
fastqtl
hilive
nanopolish
qtltools
samtools
segemehl
smalt
cyvcf2

This results in the output below. Non of the affected sources have binaries on
i386, so these are false positives. I updated the subject of this bug to make
it clear what should be removed.

Please note that I restricted this to i386, because kfreebsd-i386 and hurd-386
will be removed from ftp-master soon anyway.

Thanks,

Ivo



Will remove the following packages from unstable:

  augustus | 3.3.2+dfsg-2 | i386
  bedtools | 2.27.1+dfsg-4 | i386
 delly |0.8.1-2 | i386
dwgsim |   0.1.12-2 | i386
   fastqtl | 2.184+dfsg-6+b1 | i386
hilive |  1.1-2 | i386
nanopolish |   0.11.0-2 | i386
python-cyvcf2 |   0.10.8-1 | i386
python3-cyvcf2 |   0.10.8-1 | i386
  qtltools | 1.1+dfsg-3 | i386
  samtools |  1.9-4 | i386
  segemehl |0.3.4-1 | i386
 smalt |0.7.6-8 | i386

Maintainer: Debian Med Packaging Team 


--- Reason ---

--

Checking reverse dependencies...
# Broken Build-Depends:
barrnap: bedtools
bcbio: python3-cyvcf2
   samtools
fastaq: samtools
freebayes: samtools
iva: samtools
 smalt
pbbam: samtools
python-gffutils: bedtools
python-pybedtools: bedtools
python-pysam: samtools (>= 1.9)
reapr: samtools (>= 1.3)
   smalt
roary: bedtools
sga: samtools
srst2: samtools
stacks: samtools
unicycler: samtools

Dependency problem found.

Bug#928708: RFP: franz -- Franz is your messaging app for WhatsApp, Facebook Messenger, Slack, Telegram and many many more.

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: franz
  Version : 5.1.0
  Upstream Author : Stefan Malzner ste...@adlk.io
* URL : https://meetfranz.com/
* License : Apache-2.0
  Programming Lang: javascript
  Description : Franz is your messaging app for WhatsApp, Facebook
Messenger, Slack, Telegram and many many more.

What is Franz?

Franz is the former Emperor of Austria - but also a messaging app that combines
chat & messaging services into one application. Franz currently supports Slack,
WhatsApp, WeChat, Facebook Messenger, Telegram, Google Hangouts, GroupMe, Skype
and many more.

One service
unlimited accounts

Franz allows you to add each service many times. This makes Franz the perfect
tool to manage multiple business and private accounts all at the same time. You
could even use five different Facebook Messenger accounts at once, if some
inexplicable reason urges you to do so.

Endless possibilities

Franz supports a great variety of business and private messaging & chat
services like Slack, WhatsApp, WeChat, Messenger, Telegram, Google Hangouts,
Skype, Zendesk and many more.

It does not matter if you just want to keep in touch with your friends or are
managing a multi-seat customer care team. Franz got you covered.

Get in sync

You need your messaging setup at work, home and 42 other places and don't want
to add all services again and again and again?

Franz 5 offers built in service synchronization. Just sign in to your Franz
account on as many devices as you want and you are ready to go.

Usernames and passwords will not be synchronized.

Franz for Teams

You and your team use Franz? You can now manage Premium subscriptions for as
many colleagues, friends or family members as you want, all from within one
account.

Franz for Teams gives you the option to invite co-workers to your team by
sending them email invitations and manage their subscriptions in your account’s
preferences. Don’t waste time setting up subscriptions for every team member
individually, forget about multiple invoices and different billing cycles - one
team to rule them all!

Extend Franz

The extensive plugin architecture of Franz 5 allows you add and create
unlimited services to adapt Franz a 100% to your needs – not the other way
around.

Together with the amazing Franz community, we are constantly adding new
services to offer a platform that perfectly fits your needs.

Franz is truly an emperor with exceptional communication skills. He is trained
in almost every major language like English, German, French, Spanish,
(Brazilian) Portuguese, Russian, Japanese and many many more. The amazing Franz
community helps Franz to learn new things everyday and is constantly teaching
him new languages to make Franz a truly personalized experience.