Bug#962974: RFS: t-coffee bug #962974 fix

[merkys]

Control: forward -1 https://github.com/cbcrg/tcoffee/issues/27

On Wed, 17 Jun 2020 21:05:22 +0200 =?utf-8?Q?=C3=89tienne?= Mollier
 wrote:> The updated package is pushed on
Salsa and ready for review:
> 
>   https://salsa.debian.org/med-team/t-coffee

Thanks for the prompt fix! I have reported the issue upstream.

Best,
Andrius

Bug#960065: updated MP

[Christian Ehrhardt]

Thanks Oliver!

Abandoned
https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/6
and added
https://salsa.debian.org/vmware-packaging-team/pkg-open-vm-tools/-/merge_requests/7

-- 
Christian Ehrhardt
Staff Engineer, Ubuntu Server
Canonical Ltd

Bug#963033: linux-image-arm64: kexec loses EFI system tables with Debian kernels

[Da Xue]

Package: linux-image-arm64
Version: 4.19+105+deb10u4
Severity: important
Tags: d-i

Dear Maintainer,

I am testing with ARM64 systems with u-boot. Debian is booted in EFI mode and 
properly detects the EFI system tables. 

[0.00] efi: EFI v2.80 by Das U-Boot 

[0.00] efi:  RTPROP=0x3aef9040  SMBIOS=0x3aeee000  RNG=0x39b81040  
MEMRESERVE=0x39b80040
[0.00] efi: seeding entropy pool  


Anytime I kexec the same or another Debian kernel, I get the following message:

[0.00] efi: Getting EFI parameters from FDT:
[0.00] efi: Can't find 'System Table' in device tree!

This problem is occuring with both 4.19, 5.4, 5.6, and 5.7 from Debian. It does 
not occur with SUSE or Fedora kernels. 

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

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

Versions of packages linux-image-arm64 depends on:
ii  linux-image-4.19.0-9-arm64  4.19.118-2+deb10u1

linux-image-arm64 recommends no packages.

linux-image-arm64 suggests no packages.

-- no debconf information

Bug#963032: ITP: elpa-elpher -- full-featured gopher and gemini client for GNU Emacs

[Dhavan]

Package: wnpp
Severity: wishlist
Owner: Dhavan Vaidya 

* Package name: elpa-elpher
  Version : 2.7.8
  Upstream Author : Tim Vaughan 
* URL : http://thelambdalab.xyz/elpher
* License : GPLv3+
  Programming Lang: elisp
  Description : full-featured gopher and gemini client for GNU Emacs

It supports:
- intuitive keyboard and mouse-driven browsing,
- out-of-the-box compatibility with evil-mode,
- clickable web and gopher links **in plain text**,
- caching of visited sites,
- pleasant and configurable visualization of gopher directories and
  gemini pages,
- direct visualisation of image files,
- jumping directly to links by name (with autocompletion),
- a simple bookmark management system,
- gopher connections using TLS encryption,
- the Finger protocol.

The official home of elpher is gopher://thelambdalab.xyz/1/projects/elpher/.

gemini protocol is picking up, I have started running my own
gopherhole and haave started following other people via gopher.


--
D Vaidya



signature.asc
Description: OpenPGP digital signature

Bug#963031: man2html: `hman` "executable rejected due to location or path"

[Howard Johnson]

Package: man2html
Version: 1.6g-12
Severity: normal
Tags: patch

The problem:

1) Install and configure man2html package.
2) Make sure that MANHTMLPAGER is not set.
3) Run `hman` command (script) to view man pages in the default
browser: lynx.

3) Bug:  Get red lynx error:  "executable rejected due to location or
path"


Proposed fix:

Change line# 70 in /usr/bin/hman from:

CG="lynxcgi:/usr/lib/cgi-bin/man"

to

CG="http://$HOST/cgi-bin/man;


With fix in place `hman` runs as expected.


A temporary workaround, to avoid this problem rather than fixing it:

Set `MANHTMLPAGER=sensible-browser` prior to starting `hman`.



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

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

Versions of packages man2html depends on:
ii  apache2 [httpd-cgi]2.4.38-3+deb10u3
ii  debconf [debconf-2.0]  1.5.71
ii  gawk   1:4.2.1+dfsg-1
ii  libc6  2.28-10
ii  lynx   2.8.9rel.1-3
ii  man-db 2.8.5-2
ii  man2html-base  1.6g-11
ii  sensible-utils 0.0.12

man2html recommends no packages.

Versions of packages man2html suggests:
ii  chromium [www-browser]  80.0.3987.162-1~deb10u1
ii  google-chrome-stable [www-browser]  83.0.4103.106-1
ii  lynx [www-browser]  2.8.9rel.1-3
ii  swish++ 6.1.5-5
ii  w3m [www-browser]   0.5.3-37

-- debconf information:
  man2html/index_manpages: true

Bug#963030: Pulseaudio backend not enabled in 1:6.0.0~ds0-3

[Zhong Jianxin]

Package: ardour
Version: 1:6.0.0~ds0-3
Severity: normal

`apt-cache show ardour` show no libpulse0 in `Depends`.

Also, build log[1] gives `--with-backends=jack,alsa,dummy`, no
pulseaudio.

[1]: 
https://buildd.debian.org/status/fetch.php?pkg=ardour=amd64=1%3A6.0.0%7Eds0-3=1592412785=0

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

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

Versions of packages ardour depends on:
ii  ardour-data   1:6.0.0~ds0-3
ii  libarchive13  3.4.3-1
ii  libasound21.2.2-2.2
ii  libatkmm-1.6-1v5  2.28.0-2
ii  libaubio5 0.4.9-4+b1
ii  libc6 2.30-8
ii  libcairo2 1.16.0-4
ii  libcairomm-1.0-1v51.12.2-4
ii  libcurl3-gnutls   7.68.0-1
ii  libcwiid1 0.6.00+svn201-5
ii  libdbus-1-3   1.12.18-1
ii  libfftw3-single3  3.3.8-2
ii  libfluidsynth22.1.2-1
ii  libfontconfig12.13.1-4.2
ii  libgcc-s1 10.1.0-4
ii  libgdk-pixbuf2.0-02.40.0+dfsg-5
ii  libglib2.0-0  2.64.3-1
ii  libglibmm-2.4-1v5 2.64.2-1
ii  libgtk2.0-0   2.24.32-4
ii  libgtkmm-2.4-1v5  1:2.24.5-4
ii  libjack-jackd2-0 [libjack-0.125]  1.9.12~dfsg-2+b1
ii  liblilv-0-0   0.24.8~dfsg0-1
ii  liblo70.31-1
ii  liblrdf0  0.6.1-2
ii  libltc11  1.3.1-1
ii  libpango-1.0-01.44.7-4
ii  libpangocairo-1.0-0   1.44.7-4
ii  libpangoft2-1.0-0 1.44.7-4
ii  libpangomm-1.4-1v52.42.1-1
ii  libqm-dsp01.7.1-4
ii  librubberband21.8.2-1
ii  libsamplerate00.1.9-2
ii  libsigc++-2.0-0v5 2.10.2-1
ii  libsndfile1   1.0.28-8
ii  libstdc++610.1.0-4
ii  libsuil-0-0   0.10.6-1
ii  libtag1v5 1.11.1+dfsg.1-2+b1
ii  libusb-1.0-0  2:1.0.23-2
ii  libvamp-hostsdk3v52.10.0-1
ii  libvamp-sdk2v52.10.0-1
ii  libwebsockets16   4.0.16-1
ii  libx11-6  2:1.6.9-2+b1
ii  libxml2   2.9.10+dfsg-5+b1

Versions of packages ardour recommends:
ii  ardour-video-timeline  1:6.0.0~ds0-3

ardour suggests no packages.

-- no debconf information

Bug#963029: brz: conflicts with git-remote-bzr manual page

[Paul Wise]

Package: brz
Version: 3.1.0-4
Severity: serious

Both brz and git-remote-bzr have this file:

/usr/share/man/man1/git-remote-bzr.1.gz

brz needs to gain conflicts/provides git-remote-bzr and possibly a
transition package, or renaming the git-remote-bzr to git-remote-brz.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#962956: reniced: reniced logs several syntax errors

[Christian Garbs]

On Tue, Jun 16, 2020 at 04:48:45PM +0200, Francesco Potortì wrote:
> Package: reniced
> Version: 1.21-1
> Severity: normal
> 
> In daemon.log I read:
> 
> Jun 16 15:43:03 tucano reniced[3522]: Starting reniced:
> Jun 16 15:43:03 tucano reniced[3552]: Starting reniced:
> Jun 16 15:43:03 tucano reniced[3552]: rgument " " isn't numeric in 
> addition (+) at /usr/bin/reniced line Argument " " isn't numeric in 
> addition (+) at /usr/bin/reniced line 435,  line 3.
> Jun 16 15:43:03 tucano reniced[3552]: Argument " " isn't numeric in 
> addition (+) at /usr/bin/reniced line 435,  line 4.

This is a problem with PIDs longer than 5 digits.

It has already been fixed upstream:
https://github.com/mmitch/reniced/issues/2

I have just released reniced v1.22 to make it easier to track the fix.

I don't know when I'll be able to provide an updated Debian package:
Updating the code should be trivial, but there will be new Debian
Policy versions to be included and I need to find a sponsor if I
remember correctly

If anybody wants to step up to update or take over the package, please
go ahead.

Best regards
Christian
-- 
Christian.Garbshttps://www.cgarbs.de

Mit welcher Geschwindigkeit breitet sich das Dunkel aus?

Bug#851771: php-gettext: CVE-2016-6175

[Sunil Mohan Adapa]

tag 851771 + patch
thanks

Hello,

TT-RSS is an important application for FreedomBox and it continues to
use php-gettext library. TT-RSS is currently not available for testing.
It would be nice to have it back.

To address this, I have implemented a parser for the plurals expressions
instead of using the eval() method as discussed in the upstream bug as
solution. This patch is under the same license as php-gettext (GPLv2 or
higher).

- A simple operator-precedence parser that prioritizes simplicity and
readability. Avoid using eval() for evaluating plural expressions.
  - Fixes CVE-2016-6175.
  - Fixes upstream bug https://bugs.launchpad.net/php-gettext/+bug/1606184
  - Fixes Debian bug https://bugs.debian.org/851771

- Grammar for parsing code is same as the grammar for GNU gettext
library:
http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/plural.y

- Extensive tests for various locales with help from Unicode's plurals
rules. Tests for invalid syntax and expression parsing.

This patch has been submitted upstream at
https://bugs.launchpad.net/php-gettext/+bug/1606184 . Please consider
applying the patch in Debian if the upstream doesn't do so shortly.

Thanks,

-- 
Sunil
From ebe92d9d97dc21b82225c6a7977adf87dd00f799 Mon Sep 17 00:00:00 2001
From: Sunil Mohan Adapa 
Date: Thu, 11 Jun 2020 15:00:34 -0700
Subject: [PATCH] Iterate user table in a sorted way, fix tests with latest
 glib

This is primarily to help test cases which assume that the adopted algorithm
prioritizes the users in the exact reverse order they appear in the test
cases (and get inserted into the session in reverse order). With older glib
version, the five users being inserted happened to return the order expected by
the tests. With latest glib, due to a minor tweak in hashing strategy, the
insertion leads to unsorted list leading to failed tests.

In addition, GHashTable makes no guarantees about the stability of items when
iterating multiple times. Since the algorithm is sensitive to order of users, it
is best to return users in an order that is consistent over multiple calls and
stable over insert/remove operations.

This patch maintains a sorted list of user ids and uses it for iteration.

Closes: #22.

Signed-off-by: Sunil Mohan Adapa 
---
 libinfinity/common/inf-user-table.c | 51 -
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/libinfinity/common/inf-user-table.c b/libinfinity/common/inf-user-table.c
index 11b06b4..cb44ef5 100644
--- a/libinfinity/common/inf-user-table.c
+++ b/libinfinity/common/inf-user-table.c
@@ -36,15 +36,11 @@
  * users within the session.
  */
 
-typedef struct _InfUserTableForeachUserData InfUserTableForeachUserData;
-struct _InfUserTableForeachUserData {
-  InfUserTableForeachUserFunc func;
-  gpointer user_data;
-};
-
 typedef struct _InfUserTablePrivate InfUserTablePrivate;
 struct _InfUserTablePrivate {
   GHashTable* table;
+  /* To be able to iterate users in sorted order */
+  GSList* user_ids;
   /* TODO: It would be smarter to map the hash table to a helper struct
* which stores the user availability, locality and the InfUser object */
   GSList* availables;
@@ -179,15 +175,11 @@ inf_user_table_lookup_user_by_name_func(gpointer key,
   return FALSE;
 }
 
-static void
-inf_user_table_foreach_user_func(gpointer key,
- gpointer value,
- gpointer user_data)
+static gint
+inf_user_ids_list_sort_compare_func(gconstpointer a,
+gconstpointer b)
 {
-  InfUserTableForeachUserData* data;
-  data = (InfUserTableForeachUserData*)user_data;
-
-  data->func(INF_USER(value), data->user_data);
+  return GPOINTER_TO_UINT(a) - GPOINTER_TO_UINT(b);
 }
 
 static void
@@ -197,6 +189,7 @@ inf_user_table_init(InfUserTable* user_table)
   priv = INF_USER_TABLE_PRIVATE(user_table);
 
   priv->table = g_hash_table_new_full(NULL, NULL, NULL, NULL);
+  priv->user_ids = NULL;
   priv->availables = NULL;
   priv->locals = NULL;
 }
@@ -216,6 +209,9 @@ inf_user_table_dispose(GObject* object)
   g_slist_free(priv->availables);
   priv->availables = NULL;
 
+  g_slist_free(priv->user_ids);
+  priv->user_ids = NULL;
+
   g_hash_table_foreach(
 priv->table,
 inf_user_table_dispose_foreach_func,
@@ -256,6 +252,12 @@ inf_user_table_add_user_handler(InfUserTable* user_table,
   g_hash_table_insert(priv->table, GUINT_TO_POINTER(id), user);
   g_object_ref(user);
 
+  priv->user_ids = g_slist_insert_sorted(
+priv->user_ids,
+GUINT_TO_POINTER(id),
+inf_user_ids_list_sort_compare_func
+  );
+
   g_signal_connect(
 G_OBJECT(user),
 "notify::status",
@@ -314,6 +316,8 @@ inf_user_table_remove_user_handler(InfUserTable* user_table,
 );
   }
 
+  priv->user_ids = g_slist_remove(priv->user_ids, GUINT_TO_POINTER(id));
+
   inf_user_table_unref_user(user_table, user);
   g_assert(g_hash_table_lookup(priv->table, GUINT_TO_POINTER(id)) == user);
   

Bug#962013: fix is incomplete

[Hiroyuki YAMAMORI]

Dear Maintainer,

Additional Information:

--- json-c_0.13.1+dfsg-9/debian/json-c-doc.doc-base 2020-06-17 07:16:27 
+
+++ (buster 0.12.1+ds-2)/debian/libjson-c-doc.doc-base  2019-01-20 21:47:40 
+
@@ -1,4 +1,4 @@
-Document: json-c-doc
+Document: libjson-c-doc
 Title: JSON-C (libjson-c) manual
 Author: Metaparadigm Pte Ltd
 Abstract: This manual describe the JSON-C API.


Thank you,
Hiroyuki YAMAMORI

Bug#963012: iptables-persistent: forces use of iptables-legacy modules

[gustavo panizzo]

Hi

On Wed, Jun 17, 2020 at 06:41:21PM +0200, Thorsten Glaser wrote:

Package: iptables-persistent
Version: 1.0.11
Severity: important



As a workaround until an updated package reaches buster you can use
the package from -backports where this bug is fixed 


thanks

--
IRC: gfa
GPG: 0x27263FA42553615F904A7EBE2A40A2ECB8DAD8D5
OLD GPG: 0x44BB1BA79F6C6333

Bug#963028: ITP: pychopper -- identify, orient and trim full-length Nanopore cDNA reads

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: pychopper -- identify, orient and trim full-length Nanopore cDNA 
reads
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: pychopper
  Version : 2.4.0
  Upstream Author : Oxford Nanopore Technologies Ltd.
* URL : https://github.com/nanoporetech/pychopper
* License : MPL-2.0
  Programming Lang: Python
  Description : identify, orient and trim full-length Nanopore cDNA reads
 Pychopper v2 is a tool to identify, orient and trim full-length Nanopore
 cDNA reads. The tool is also able to rescue fused reads.  The general
 approach of Pychopper v2 is the following:
 .
  * Pychopper first identifies alignment hits of the primers across the
length of the sequence. The default method for doing this is using
nhmmscan with the pre-trained strand specific profile HMMs, included
with the package. Alternatively, one can use the edlib backend,
which uses a combination of global and local alignment to identify
the primers within the read.
  * After identifying the primer hits by either of the backends, the
reads are divided into segments defined by two consecutive primer
hits. The score of a segment is its length if the configuration of
the flanking primer hits is valid (such as SPP,-VNP for forward reads)
or zero otherwise.
  * The segments are assigned to rescued reads using a dynamic programming
algorithm maximizing the sum of used segment scores (hence the amount
of rescued bases). A crucial observation about the algorithm is that
if a segment is included as a rescued read, then the next segment
must be excluded as one of the primer hits defining it was "used
up" by the previous segment. This put constraints on the dynamic
programming graph. The arrows in read define the optimal path for
rescuing two fused reads with the a total score of l1 + l3.
 .
 A crucial parameter of Pychopper v2 is -q, which determines the
 stringency of primer alignment (E-value in the case of the pHMM
 backend). This can be explicitly specified by the user, however by
 default it is optimized on a random sample of input reads to produce
 the maximum number of classified reads.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/pychopper

Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.

[Adrian Bunk]

On Wed, Jun 17, 2020 at 02:54:37PM -0400, R P Herrold wrote:
> On Wed, 17 Jun 2020, Adrian Bunk wrote:
>...
> > Debian does not have a service agreement with IBM for maintaining the 
> > Debian kernel on s390x, it is the duty of the s390x porters to maintain
> > the Debian kernel and debug problems in the Debian kernel.
> 
> 'duty' as a concept in a social voluntary organization is a 
> slippery concept.  Many people asserting duties by others are 
> really seeking free support, and then disappear like magic.  
> That gets tiring, is not sustainable, and long ago at CentOS, 
> I set the standard and tone that we don't facilitate such 
> behaviour [that has changed with the RHT/IBM purchase, but 
> the history stands]
>...

You skipped the relevant part I wrote before that:

> > If there is a problem like for example kernel crashes with the Debian 
> > kernel on a Debian machine like a buildd for a release architecture, 
> > someone has to debug the problem swiftly.

The Debian System Administrators maintaining the Debian infrastructure 
and the Debian Release that are team requiring these kind of commitments 
from porters of release architectures, e.g.
  https://lists.debian.org/debian-s390/2016/08/msg2.html

The next Debian release will be supported until mid-2024 on all
release architectures.

Back in 2013 the 32bit SPARC port had one active porter,
who resigned from that position 3 days after the release
of Debian 7.0

> -- Russ herrold

cu
Adrian

Bug#963002: udev: Keyboard mis-detected as Apple

[Michael Biebl]

Am 18.06.20 um 00:04 schrieb Vroomfondel:
> Is this something that's likely work-aroundable with udev rules or
> tweaks to the hwdb or does the specific USB ID mean only a hardware fix
> will work? I'm still reading up on how all those files fit together with
> the module loading.

If you want to create custom mappings, then create a hwdb file in
/etc/udev/hwdb.d
See the relevant man pages related to hwdb and
https://wiki.archlinux.org/index.php/Map_scancodes_to_keycodes



signature.asc
Description: OpenPGP digital signature

Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

[Emmanuel Arias]

I've just pushed to salsa the fix, could anyone review it and sponsor
it, please?

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El mié., 17 de jun. de 2020 a la(s) 19:18, Emmanuel Arias
(emmanuelaria...@gmail.com) escribió:
>
> Hi,
>
> I will fix it today
>
> Cheers,
> Arias Emmanuel
> @eamanu
> http://eamanu.com
>
> El mié., 17 de jun. de 2020 a la(s) 19:18, Scott Kitterman
> (deb...@kitterman.com) escribió:
> >
> > On Wed, 17 Jun 2020 21:12:40 +0200 Paul Gevers  wrote:
> > > Source: impacket, smbmap
> > > Control: found -1 impacket/0.9.21-1
> > > Control: found -1 smbmap/1.8.2-1
> > > Severity: serious
> > > Tags: sid bullseye
> > > X-Debbugs-CC: debian...@lists.debian.org
> > > User: debian...@lists.debian.org
> > > Usertags: breaks needs-update
> > >
> > > Dear maintainer(s),
> > >
> > > With a recent upload of impacket the autopkgtest of smbmap fails in
> > > testing when that autopkgtest is run with the binary packages of
> > > impacket from unstable. It passes when run with only packages from
> > > testing. In tabular form:
> > >
> > >passfail
> > > impacket   from testing0.9.21-1
> > > smbmap from testing1.8.2-1
> > > all others from testingfrom testing
> > >
> > > I copied some of the output at the bottom of this report. Is the latest
> > > impacket missing a dependency or is the version function not supported
> > > anymore?
> > >
> > > Currently this regression is blocking the migration of impacket to
> > > testing [1]. Due to the nature of this issue, I filed this bug report
> > > against both packages. Can you please investigate the situation and
> > > reassign the bug to the right package?
> > >
> > > More information about this bug and the reason for filing it can be found 
> > > on
> > > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> > >
> > > Paul
> > >
> > > [1] https://qa.debian.org/excuses.php?package=impacket
> > >
> > > https://ci.debian.net/data/autopkgtest/testing/amd64/s/smbmap/5914948/log.gz
> > >
> > > autopkgtest [07:08:34]: test command1: smbmap -h
> > > autopkgtest [07:08:34]: test command1: [---
> > > Traceback (most recent call last):
> > >   File "/usr/bin/smbmap", line 19, in 
> > > from impacket import version, smbserver
> > >   File "/usr/lib/python3/dist-packages/impacket/version.py", line 7, in
> > > 
> > > import pkg_resources
> > > ModuleNotFoundError: No module named 'pkg_resources'
> > > autopkgtest [07:08:35]: test command1: ---]
> > >
> > Looks like a missing depends on python3-pkg-resources for impacket since
> > that's where it's imported.
> >
> > Scott K

Bug#963002: udev: Keyboard mis-detected as Apple

[Vroomfondel]

On 2020-06-17 21:52, Michael Biebl wrote:

Control: tags -1 + moreinfo

Hi


Salutations!



Am 17.06.20 um 14:08 schrieb Vroomfondel:

Package: udev
Version: 241-7~deb10u4
Severity: normal

Dear Maintainer,

* What led up to the situation?
New Varmilo keyboard

* What was the outcome of this action?
Fn keys not working correctly

* What outcome did you expect instead?
Fn key to work out of the box (as it does with my other Varmilo
KB)

* Futher elaboration:
I've run in to an odd problem recently with a new keyboard, a Varmilo VA88M 
(essentially the UK-ISO version of the VA87M); a fairly bog-standard tenkeyless 
keyboard.

On first use everything seemed to work OK, but it eventualy transpired that the 
Fkeys weren't working as expected. F1 through F6 didn't work at all and F7 
through F12 acted as media keys as if the Fn key was being pressed. Holding 
down the Fn key and pressing Fkeys they worked as expected, so the default 
behaviour of the keyboard was as if the Fn key was being held down all the 
time. Plugging in to a mate's windows machine, the same behaviour didn't occur.

On inspecting lsusb, it seemed that the keyboard was perhaps being erroneously 
detected as an Apple keyboard. lsusb output:
Bus 001 Device 007: ID 05ac:024f Apple, Inc.




Tbh, that sounds like a hardware issue, and not like a software issue.
Why does Varmilo VA88M use the same vendor id as Apple? That sounds fishy.


No idea on that, but I've just checked with the windows machine there and it 
reports the same VID and PID there too (I just assume Windows' handling for 
this keyboard/Mac keyboards is different).




Have you tried contacting the hardware vendor?



Yes, I've fired off a separate query to the hardware vendor, waiting back on a 
response.


There's a recent reddit post here with what sounds like the same issue but I 
can't load the page past the initial comment for some reason.


https://www.reddit.com/r/Varmilo/comments/g4sabk/fn_lock_on_va87m/

In the meantime, or in the event of there not being a viable fix, are there any 
"cleaner" ways to work around the issue? From having a cursory glance through 
the comments in the /lib/udev/hwdb files it seems like custom overrides can be 
set there and submitted upstream if deemed useful.


Is this something that's likely work-aroundable with udev rules or tweaks to the 
hwdb or does the specific USB ID mean only a hardware fix will work? I'm still 
reading up on how all those files fit together with the module loading.

Bug#961765: roundcube-core: package needs work for sqlite

[Guilhem Moulin]

Control: tag -1 + unreproducible

On Fri, 29 May 2020 at 11:38:31 +1000, Russell Coker via 
Pkg-roundcube-maintainers wrote:
> specifying sqlite.  As sqlite is simpler it should be able to configure all
> sqlite stuff if the user selects sqlite as database type.
> […]
> Next when you go to the web page for roundcube when using sqlite you get a
> database connection error.

As written earlier the dbconfig-managed SQLite setup works out of the
box in a clean sid (or buster) chroot so I'm tagging this accordingly.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

[Emmanuel Arias]

Hi,

I will fix it today

Cheers,
Arias Emmanuel
@eamanu
http://eamanu.com

El mié., 17 de jun. de 2020 a la(s) 19:18, Scott Kitterman
(deb...@kitterman.com) escribió:
>
> On Wed, 17 Jun 2020 21:12:40 +0200 Paul Gevers  wrote:
> > Source: impacket, smbmap
> > Control: found -1 impacket/0.9.21-1
> > Control: found -1 smbmap/1.8.2-1
> > Severity: serious
> > Tags: sid bullseye
> > X-Debbugs-CC: debian...@lists.debian.org
> > User: debian...@lists.debian.org
> > Usertags: breaks needs-update
> >
> > Dear maintainer(s),
> >
> > With a recent upload of impacket the autopkgtest of smbmap fails in
> > testing when that autopkgtest is run with the binary packages of
> > impacket from unstable. It passes when run with only packages from
> > testing. In tabular form:
> >
> >passfail
> > impacket   from testing0.9.21-1
> > smbmap from testing1.8.2-1
> > all others from testingfrom testing
> >
> > I copied some of the output at the bottom of this report. Is the latest
> > impacket missing a dependency or is the version function not supported
> > anymore?
> >
> > Currently this regression is blocking the migration of impacket to
> > testing [1]. Due to the nature of this issue, I filed this bug report
> > against both packages. Can you please investigate the situation and
> > reassign the bug to the right package?
> >
> > More information about this bug and the reason for filing it can be found on
> > https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> >
> > Paul
> >
> > [1] https://qa.debian.org/excuses.php?package=impacket
> >
> > https://ci.debian.net/data/autopkgtest/testing/amd64/s/smbmap/5914948/log.gz
> >
> > autopkgtest [07:08:34]: test command1: smbmap -h
> > autopkgtest [07:08:34]: test command1: [---
> > Traceback (most recent call last):
> >   File "/usr/bin/smbmap", line 19, in 
> > from impacket import version, smbserver
> >   File "/usr/lib/python3/dist-packages/impacket/version.py", line 7, in
> > 
> > import pkg_resources
> > ModuleNotFoundError: No module named 'pkg_resources'
> > autopkgtest [07:08:35]: test command1: ---]
> >
> Looks like a missing depends on python3-pkg-resources for impacket since
> that's where it's imported.
>
> Scott K

Bug#960065: patch to replace 'netstat' with 'sdmp'

[Oliver Kurth]

We now have a patch that replaces 'netstat' with 'ss' because the former is 
deprecated. We just created an extra branch with the changes, plus two minor 
sdmp related fixes: 
https://github.com/vmware/open-vm-tools/commits/stable-11.1.0-SDMP-fixes

Thanks,
Oliver

Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

[Scott Kitterman]

On Wed, 17 Jun 2020 21:12:40 +0200 Paul Gevers  wrote:
> Source: impacket, smbmap
> Control: found -1 impacket/0.9.21-1
> Control: found -1 smbmap/1.8.2-1
> Severity: serious
> Tags: sid bullseye
> X-Debbugs-CC: debian...@lists.debian.org
> User: debian...@lists.debian.org
> Usertags: breaks needs-update
> 
> Dear maintainer(s),
> 
> With a recent upload of impacket the autopkgtest of smbmap fails in
> testing when that autopkgtest is run with the binary packages of
> impacket from unstable. It passes when run with only packages from
> testing. In tabular form:
> 
>passfail
> impacket   from testing0.9.21-1
> smbmap from testing1.8.2-1
> all others from testingfrom testing
> 
> I copied some of the output at the bottom of this report. Is the latest
> impacket missing a dependency or is the version function not supported
> anymore?
> 
> Currently this regression is blocking the migration of impacket to
> testing [1]. Due to the nature of this issue, I filed this bug report
> against both packages. Can you please investigate the situation and
> reassign the bug to the right package?
> 
> More information about this bug and the reason for filing it can be found on
> https://wiki.debian.org/ContinuousIntegration/RegressionEmailInformation
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=impacket
> 
> https://ci.debian.net/data/autopkgtest/testing/amd64/s/smbmap/5914948/log.gz
> 
> autopkgtest [07:08:34]: test command1: smbmap -h
> autopkgtest [07:08:34]: test command1: [---
> Traceback (most recent call last):
>   File "/usr/bin/smbmap", line 19, in 
> from impacket import version, smbserver
>   File "/usr/lib/python3/dist-packages/impacket/version.py", line 7, in
> 
> import pkg_resources
> ModuleNotFoundError: No module named 'pkg_resources'
> autopkgtest [07:08:35]: test command1: ---]
> 
Looks like a missing depends on python3-pkg-resources for impacket since 
that's where it's imported.

Scott K

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

Bug#962629: [Pkg-javascript-devel] Bug#962629: rainloop: Rainloop stores passwords in cleartext in logfile

[herrn]

Hello Daniel,

I don't have the possibility to try out a newer version of rainloop, but
according to a recent comment on the github issue [1] this is really fixed
in version 1.14.0 of rainloop. So I assume that only applies to the current
stable release.

Nevertheless I see this bug as grave enough that in my opinion this has to
be mentioned prominently to users of the package or even better be fixed in
a downstream patch (if the actual cause of the problem is known).

Best regards
Marco


[1] 
https://github.com/RainLoop/rainloop-webmail/issues/1872#issuecomment-645547357

On Sun, Jun 14, 2020 at 10:13:23PM -0700, Daniel Ring wrote:
> Hello Marco,
> 
> I wasn't able to reproduce this issue in the current version of Rainloop.
> Passwords were replaced by asterisks in the logs with the hide_passwords
> option enabled (the default). Could you please check to see if package
> version 1.14.0-1, currently in testing/unstable, resolves the issue for you?
> 
> Fortunately the package version in stable is secure by default, as logging
> is disabled in the default config file. The GitHub issue has unfortunately
> been open for over a year with no comments from upstream, so they likely
> have no plans to address it.
> 
> -- Daniel
> 
> On 6/10/2020 2:19 PM, herrn at sout.de (Marco Herrn) wrote:
> > Package: rainloop
> > Version: 1.12.1-2
> > Severity: important
> > 
> > Dear Maintainer,
> > 
> > When writing into a logfile, rainloop writes the passwords of all login
> > attempts (successful or not) into the logfile in cleartext.
> > 
> > Rainloop provides an option 'hide_passwords' in the application.ini that
> > should prohibit that behaviour, which is by default set to 'On'. But
> > apparently this doesn't have any effect.
> > 
> > There is already an unresolved github issue about that topic:
> > https://github.com/RainLoop/rainloop-webmail/issues/1872
> > 
> > Even though this issue doesn't affect the actual usability of rainloop,
> > I set the severity to 'Important' as this is a security issue.
> > 
> > 
> > -- System Information:
> > Debian Release: 10.4
> >APT prefers stable-updates
> >APT policy: (500, 'stable-updates'), (500, 'stable')
> > Architecture: amd64 (x86_64)
> > 
> > Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
> > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
> > LANGUAGE=en_US:en (charmap=UTF-8)
> > Shell: /bin/sh linked to /usr/bin/dash
> > Init: systemd (via /run/systemd/system)
> > LSM: AppArmor: enabled
> > 
> > Versions of packages rainloop depends on:
> > ii  apache2 [httpd] 2.4.38-3+deb10u3
> > ii  ckeditor4.11.1+dfsg-1
> > ii  php-curl2:7.3+69
> > ii  php-fpm 2:7.3+69
> > ii  php-nrk-predis  1.0.0-1
> > ii  php-pclzip  2.8.2-4
> > ii  php-seclib  1.0.14-1
> > ii  php-xml 2:7.3+69
> > ii  php7.3-curl [php-curl]  7.3.14-1~deb10u1
> > ii  php7.3-fpm [php-fpm]7.3.14-1~deb10u1
> > ii  php7.3-json [php-json]  7.3.14-1~deb10u1
> > ii  php7.3-xml [php-xml]7.3.14-1~deb10u1
> > 
> > rainloop recommends no packages.
> > 
> > Versions of packages rainloop suggests:
> > pn  php5-sqlite | php5-mysql | php5-pgsql  
> > 
> > -- Configuration Files:
> > /etc/rainloop/application.ini changed [not included]
> > /etc/rainloop/rainloop.apache.conf changed [not included]
> > 
> > -- no debconf information
> > 

Bug#963027: ITP: sequoia-sop -- Stateless OpenPGP command-line interface (Sequoia)

[Daniel Kahn Gillmor]

Package: wnpp
Severity: wishlist
Owner: Daniel Kahn Gillmor 

* Package name: sequoia-sop
  Version : 0.17.0
  Upstream Author : Justus Winter 
* URL : 
https://sequoia-pgp.org/blog/2020/06/12/202006-sequoia-0.17.0/
* License : GPL 2+
  Programming Lang: Rust
  Description : Stateless OpenPGP command-line interface (Sequoia)

This package contains a rust-based implementation of the Stateless
OpenPGP command-line interface, aka "sop".  It is useful as a
minimalist utility, and as a component in test suites and other
OpenPGP-based verification tools.

https://datatracker.ietf.org/doc/draft-dkg-openpgp-stateless-cli/

Bug#621807: rpcbind should not bind to wildcard

[Andrey ``Bass'' Shcheglov]

Dear maintainers, any update on this?

I'm now running rpcbind 1.2.5-0.3+deb10u1 in Debian 10, and it behaves just the 
same:

> # ps -ef | grep rpcbind | grep -v grep
> _rpc 18484 1  0 00:16 ?00:00:00 /sbin/rpcbind -w -h 127.0.0.1 
> -h ::1 -l
> # lsof -i -a -p 18484
> COMMAND   PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
> rpcbind 18484 _rpc6u  IPv4 6261774  0t0  UDP localhost:sunrpc 
> rpcbind 18484 _rpc   10u  IPv4 6261778  0t0  TCP *:sunrpc (LISTEN)
> rpcbind 18484 _rpc   11u  IPv6 6261779  0t0  UDP localhost:sunrpc 
> rpcbind 18484 _rpc   14u  IPv6 6261782  0t0  TCP *:sunrpc (LISTEN)
Have you tried reporting this upstream, to either
SF project bug-tracker ,
or bu sending an e-mail to 
or ?

-- 
Regards,
Andrey ``Bass'' Shcheglov.

Bug#959573: facter: diff for NMU version 3.11.0-4.2

[Sebastian Ramacher]

Control: tags 959573 + patch
Control: tags 959573 + pending

Dear maintainer,

I've prepared an NMU for facter (versioned as 3.11.0-4.2) and
uploaded it to DELAYED/1. Please feel free to tell me if I
should delay it longer.

Cheers
-- 
Sebastian Ramacher
diff -Nru facter-3.11.0/debian/changelog facter-3.11.0/debian/changelog
--- facter-3.11.0/debian/changelog	2020-04-13 21:45:20.0 +0200
+++ facter-3.11.0/debian/changelog	2020-06-17 23:21:32.0 +0200
@@ -1,3 +1,10 @@
+facter (3.11.0-4.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * debian/patches: Fix tests with yaml-cpp 0.6.3 (Closes: #959573)
+
+ -- Sebastian Ramacher   Wed, 17 Jun 2020 23:21:32 +0200
+
 facter (3.11.0-4.1) unstable; urgency=medium
 
   * Non-maintainer upload
diff -Nru facter-3.11.0/debian/patches/fix-double-tests.patch facter-3.11.0/debian/patches/fix-double-tests.patch
--- facter-3.11.0/debian/patches/fix-double-tests.patch	1970-01-01 01:00:00.0 +0100
+++ facter-3.11.0/debian/patches/fix-double-tests.patch	2020-06-17 23:21:16.0 +0200
@@ -0,0 +1,49 @@
+Description: Fix yaml tests with double values.
+ As of yaml-cpp 0.6.3, the maximal precision for serializing floating
+ point values is used. See
+ https://github.com/jbeder/yaml-cpp/commit/abf941b20d21342cd207df0f8ffe09f41a4d3042
+ .
+ Since 42.4242 cannot be precisely represented with binary floating
+ point numbers, the tests fail. 42.4345, however, can be precisely
+ represented, so use this value for the tests.
+Author: Sebastian Ramacher 
+Bug-Debian: https://bugs.debian.org/959573
+Last-Update: 2020-06-17
+
+--- a/lib/tests/facts/double_value.cc
 b/lib/tests/facts/double_value.cc
+@@ -12,29 +12,29 @@
+ using namespace YAML;
+ 
+ SCENARIO("using a double fact value") {
+-double_value value(42.4242);
+-REQUIRE(value.value() == Approx(42.4242));
++double_value value(42.4345);
++REQUIRE(value.value() == Approx(42.4345));
+ WHEN("serialized to JSON") {
+ THEN("it should have the same value") {
+ json_value json;
+ json_allocator allocator;
+ value.to_json(allocator, json);
+ REQUIRE(json.IsNumber());
+-REQUIRE(json.GetDouble() == Approx(42.4242));
++REQUIRE(json.GetDouble() == Approx(42.4345));
+ }
+ }
+ WHEN("serialized to YAML") {
+ THEN("it should have the same value") {
+ Emitter emitter;
+ value.write(emitter);
+-REQUIRE(string(emitter.c_str()) == "42.4242");
++REQUIRE(string(emitter.c_str()) == "42.4345");
+ }
+ }
+ WHEN("serialized to text") {
+ THEN("it should have the same value") {
+ ostringstream stream;
+ value.write(stream);
+-REQUIRE(stream.str() == "42.4242");
++REQUIRE(stream.str() == "42.4345");
+ }
+ }
+ }
diff -Nru facter-3.11.0/debian/patches/series facter-3.11.0/debian/patches/series
--- facter-3.11.0/debian/patches/series	2020-04-13 21:45:20.0 +0200
+++ facter-3.11.0/debian/patches/series	2020-06-17 22:44:37.0 +0200
@@ -5,3 +5,4 @@
 0005-fix-custom-facts-overriding-core.patch
 0006-FACT-1916-fix-route-parsing-on-Linux.patch
 0007-Don-t-run-rspec-via-bundler.patch
+fix-double-tests.patch


signature.asc
Description: PGP signature

Bug#962973: haskell-readline: Removal notice: broken and unmaintained

[Joey Hess]

It could be converted to haskeline or raw IO, but gnu readline is the
kind of library I think it makes sense to have language bindings to, and
to use the bindings.

This patch seems to fix the build problem:

--- readline-1.0.3.0.orig/readline.cabal2020-06-17 17:09:11.438264895 
-0400
+++ readline-1.0.3.0/readline.cabal 2020-06-17 17:11:23.524724389 -0400
@@ -29,5 +29,5 @@
 build-depends: base < 3
   include-dirs:include
   includes:HsReadline.h
-  install-includes:HsReadline.h HsReadlineConfig.h
+  install-includes:HsReadline.h
   c-sources:   HsReadline_cbits.c

I've sent this patch to the author of the library.

-- 
see shy jo


signature.asc
Description: PGP signature

Bug#963026: game-data-packager: points to non-existing gog website

[Reiner Herrmann]

Package: game-data-packager
Version: 65
Severity: minor

The URL printed by the gog module no longer exists:

$ game-data-packager gog
INFO:game_data_packager.gog:Visit game-data-packager @ GOG.com: 
https://www.gog.com/mix/games_supported_by_debians_gamedatapackager

Regards,
  Reiner


signature.asc
Description: PGP signature

Bug#963025: firmware-iwlwifi: Microcode SW error detected / 9000-pu-b0-jf-b0-46.ucode

[Stefan Pietsch]

Package: firmware-iwlwifi
Version: 20190717-2
Severity: important

Firmware 9000-pu-b0-jf-b0-46.ucode stops working when used with hostapd as soon 
as a wireless client connects.
This also affects firmware 9000-pu-b0-jf-b0-41.ucode.

I was not able to reproduce this with firmware 9000-pu-b0-jf-b0-38.ucode


##


# lspci output of wireless controller

00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi 
[Wireless-AC] (rev 30)
Subsystem: Intel Corporation Cannon Point-LP CNVi [Wireless-AC]
Flags: fast devsel, IRQ 16, IOMMU group 5
Memory at c9738000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [c8] Power Management version 3
Capabilities: [d0] MSI: Enable- Count=1/1 Maskable- 64bit+
Capabilities: [40] Express Root Complex Integrated Endpoint, MSI 00
Capabilities: [80] MSI-X: Enable- Count=16 Masked-
Capabilities: [100] Null
Capabilities: [14c] Latency Tolerance Reporting
Capabilities: [164] Vendor Specific Information: ID=0010 Rev=0 Len=014 

Kernel modules: iwlwifi


##


# cat /proc/version
Linux version 5.6.0-2-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-13)) #1 SMP Debian 
5.6.14-2 (2020-06-09)



##


# dmesg with 9000-pu-b0-jf-b0-41.ucode loaded

[ 1368.793833] iwlwifi :00:14.3: Microcode SW error detected. Restarting 
0x0.
[ 1368.794275] iwlwifi :00:14.3: Start IWL Error Log Dump:
[ 1368.794282] iwlwifi :00:14.3: Status: 0x0040, count: 6
[ 1368.794287] iwlwifi :00:14.3: Loaded firmware version: 41.fc1a7aea.0 
9000-pu-b0-jf-b0-41.ucode
[ 1368.794293] iwlwifi :00:14.3: 0x3203 | ADVANCED_SYSASSERT
[ 1368.794298] iwlwifi :00:14.3: 0xA200 | trm_hw_status0
[ 1368.794302] iwlwifi :00:14.3: 0x | trm_hw_status1
[ 1368.794306] iwlwifi :00:14.3: 0x004885AA | branchlink2
[ 1368.794310] iwlwifi :00:14.3: 0x0047A3E2 | interruptlink1
[ 1368.794313] iwlwifi :00:14.3: 0x | interruptlink2
[ 1368.794317] iwlwifi :00:14.3: 0x0004 | data1
[ 1368.794323] iwlwifi :00:14.3: 0xDEADBEEF | data2
[ 1368.794327] iwlwifi :00:14.3: 0xDEADBEEF | data3
[ 1368.794331] iwlwifi :00:14.3: 0x | beacon time
[ 1368.794335] iwlwifi :00:14.3: 0x0489CF77 | tsf low
[ 1368.794338] iwlwifi :00:14.3: 0x | tsf hi
[ 1368.794342] iwlwifi :00:14.3: 0x | time gp1
[ 1368.794346] iwlwifi :00:14.3: 0x0489CF77 | time gp2
[ 1368.794350] iwlwifi :00:14.3: 0x0001 | uCode revision type
[ 1368.794354] iwlwifi :00:14.3: 0x0029 | uCode version major
[ 1368.794358] iwlwifi :00:14.3: 0xFC1A7AEA | uCode version minor
[ 1368.794370] iwlwifi :00:14.3: 0x0312 | hw version
[ 1368.794391] iwlwifi :00:14.3: 0x18C89008 | board version
[ 1368.794407] iwlwifi :00:14.3: 0x8069FC28 | hcmd
[ 1368.794422] iwlwifi :00:14.3: 0x24022000 | isr0
[ 1368.794435] iwlwifi :00:14.3: 0x | isr1
[ 1368.794447] iwlwifi :00:14.3: 0x0820180A | isr2
[ 1368.794459] iwlwifi :00:14.3: 0x00416CC0 | isr3
[ 1368.794474] iwlwifi :00:14.3: 0x | isr4
[ 1368.794486] iwlwifi :00:14.3: 0x00490191 | last cmd Id
[ 1368.794494] iwlwifi :00:14.3: 0x | wait_event
[ 1368.794498] iwlwifi :00:14.3: 0x10D4 | l2p_control
[ 1368.794502] iwlwifi :00:14.3: 0x00018034 | l2p_duration
[ 1368.794506] iwlwifi :00:14.3: 0x0007 | l2p_mhvalid
[ 1368.794510] iwlwifi :00:14.3: 0x8100 | l2p_addr_match
[ 1368.794514] iwlwifi :00:14.3: 0x000F | lmpm_pmg_sel
[ 1368.794518] iwlwifi :00:14.3: 0x04100930 | timestamp
[ 1368.794521] iwlwifi :00:14.3: 0x502C | flow_handler
[ 1368.794669] iwlwifi :00:14.3: Start IWL Error Log Dump:
[ 1368.794674] iwlwifi :00:14.3: Status: 0x0040, count: 7
[ 1368.794679] iwlwifi :00:14.3: 0x2070 | NMI_INTERRUPT_LMAC_FATAL
[ 1368.794683] iwlwifi :00:14.3: 0x | umac branchlink1
[ 1368.794687] iwlwifi :00:14.3: 0xC0087F22 | umac branchlink2
[ 1368.794691] iwlwifi :00:14.3: 0xC0083C9C | umac interruptlink1
[ 1368.794695] iwlwifi :00:14.3: 0xC0083C9C | umac interruptlink2
[ 1368.794699] iwlwifi :00:14.3: 0x0800 | umac data1
[ 1368.794703] iwlwifi :00:14.3: 0xC0083C9C | umac data2
[ 1368.794707] iwlwifi :00:14.3: 0xDEADBEEF | umac data3
[ 1368.794710] iwlwifi :00:14.3: 0x0029 | umac major
[ 1368.794714] iwlwifi :00:14.3: 0xFC1A7AEA | umac minor
[ 1368.794718] iwlwifi :00:14.3: 0xC0886280 | frame pointer
[ 1368.794722] iwlwifi :00:14.3: 0xC0886280 | stack pointer
[ 1368.794725] iwlwifi :00:14.3: 0x004A0118 | last host cmd
[ 1368.794729] iwlwifi :00:14.3: 0x | isr status reg
[ 1368.794751] iwlwifi :00:14.3: Fseq Registers:
[ 1368.794774] iwlwifi :00:14.3: 0xA7493BFB | FSEQ_ERROR_CODE
[ 1368.794794] iwlwifi :00:14.3: 0x | FSEQ_TOP_INIT_VERSION
[ 1368.794816] iwlwifi :00:14.3: 

Bug#586413: ITA: tightvnc -- virtual network computing server software

[Ola Lundqvist]

Thank you very much.

Den ons 17 juni 2020 20:34Sven Geuer  skrev:

> Owner: debma...@g-e-u-e-r.de
>
> Hi Ola,
>
> thank you for your consent. I take ownership of this bug now. It will
> be closed with the upcoming upload of tightvnc.
>
> Thanks for having maintained tightvnc for all these years.
>
> If there's anything in contrast to what you intended, please let me
> know. We'll get it sorted out.
>
> Sven
>
> Am Mittwoch, den 17.06.2020, 11:25 +0200 schrieb Ola Lundqvist:
> > Hi
> >
> > Wonderful!
> >
> > It would be great if someone else take over. Please remove me as
> > uploader.
> > I have maintained it for many years now and it is time for someone
> > else to
> > take it over.
> >
> > / Ola
> >
> >
> > Den ons 17 juni 2020 08:14Mike Gabriel  skrev:
> >
> > > Hi Sven,
> > >
> > > On  Di 16 Jun 2020 23:07:27 CEST, Sven Geuer wrote:
> > >
> > > > Hi Mike,
> > > > Hi Ola,
> > > >
> > > > I would be interested in maintaining tightvnc as a new member of
> > > > the
> > > > Debian Remote Maintainers Team. I already started some work on it
> > > > in a
> > > > private repository on salsa [1]. 'FTBFS with gcc-10' is already
> > > > fixed.
> > > >
> > > > Being a DM, I currently maintain two packages under the umbrella
> > > > of the
> > > > Debian Security Tools Packaging Team, and had contributed to
> > > > other
> > > > packages of this team [2].
> > > >
> > > > @Mike: May I ask you to accept me as team member to debian-
> > > > remote?
> > > > @Ola: Would you want to stay listed as uploader with moving
> > > > tightvnc to
> > > > the team?
> > > >
> > > > Please let me know, if you accept my application.
> > > >
> > > > Best,
> > > > Sven
> > > >
> > > > [1] https://salsa.debian.org/sven-geuer-guest/tightvnc
> > > > [2]
> > > > https://qa.debian.org/developer.php?email=debmaint%40g-e-u-e-r.de
> > >
> > > Awesome! Regarding your Debian Remote Team applications: Welcome
> > > in!
> > >
> > > I'll wait for Ola's response, then I'll give you permissions on the
> > > tightvnc.git repo.
> > >
> > > Mike
> > > --
> > >
> > > mike gabriel aka sunweaver (Debian Developer)
> > > mobile: +49 (1520) 1976 148
> > > landline: +49 (4351) 486 14 27
> > >
> > > GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577
> > > 1B31
> > > mail: sunwea...@debian.org, http://sunweavers.net
> > >
> > >
>

Bug#963002: udev: Keyboard mis-detected as Apple

[Michael Biebl]

Control: tags -1 + moreinfo

Hi

Am 17.06.20 um 14:08 schrieb Vroomfondel:
> Package: udev
> Version: 241-7~deb10u4
> Severity: normal
> 
> Dear Maintainer,
> 
> * What led up to the situation?
>   New Varmilo keyboard
> 
> * What was the outcome of this action?
>   Fn keys not working correctly
> 
> * What outcome did you expect instead?
>   Fn key to work out of the box (as it does with my other Varmilo
>   KB)
> 
> * Futher elaboration:
> I've run in to an odd problem recently with a new keyboard, a Varmilo VA88M 
> (essentially the UK-ISO version of the VA87M); a fairly bog-standard 
> tenkeyless keyboard.
> 
> On first use everything seemed to work OK, but it eventualy transpired that 
> the Fkeys weren't working as expected. F1 through F6 didn't work at all and 
> F7 through F12 acted as media keys as if the Fn key was being pressed. 
> Holding down the Fn key and pressing Fkeys they worked as expected, so the 
> default behaviour of the keyboard was as if the Fn key was being held down 
> all the time. Plugging in to a mate's windows machine, the same behaviour 
> didn't occur.
> 
> On inspecting lsusb, it seemed that the keyboard was perhaps being 
> erroneously detected as an Apple keyboard. lsusb output:
>   Bus 001 Device 007: ID 05ac:024f Apple, Inc.
> 


Tbh, that sounds like a hardware issue, and not like a software issue.
Why does Varmilo VA88M use the same vendor id as Apple? That sounds fishy.

Have you tried contacting the hardware vendor?




signature.asc
Description: OpenPGP digital signature

Bug#963000: systemd-analyze unit-paths erroneously reports /usr/lib/systemd/system/

[Michael Biebl]

Hi Thijs

Am 17.06.20 um 13:44 schrieb Thijs Kinkhorst:
> Package: systemd
> Version: 245.6-1
> Severity: normal
> 
> Hi,
> 
> This is the output of 'systemd-analyze unit-paths' on my system:
> 
> # systemd-analyze unit-paths
> /etc/systemd/system.control
> /run/systemd/system.control
> /run/systemd/transient
> /run/systemd/generator.early
> /etc/systemd/system
> /etc/systemd/system.attached
> /run/systemd/system
> /run/systemd/system.attached
> /run/systemd/generator
> /usr/local/lib/systemd/system
> /lib/systemd/system
> /usr/lib/systemd/system
> /run/systemd/generator.late
> 
> Howeverm it seems /usr/lib/systemd/system, despite being in the list, is
> not actually searched. It was confirmed by other documentation that in
> Debian this is indeed the case.

Are you sure?


root@pluto:/usr/lib/systemd/system# cat
/usr/lib/systemd/system/test.service
[Unit]
Description=Test

[Service]
RemainAfterExit=yes
ExecStart=/bin/true

root@pluto:/usr/lib/systemd/system# systemctl status test.service
● test.service - Test
 Loaded: loaded (/usr/lib/systemd/system/test.service; static;
vendor preset: enabled)
 Active: active (exited) since Wed 2020-06-17 22:41:42 CEST; 25s ago
   Main PID: 18740 (code=exited, status=0/SUCCESS)
  Tasks: 0 (limit: 19005)
 Memory: 0B
CPU: 0
 CGroup: /system.slice/test.service

Jun 17 22:41:42 pluto systemd[1]: Started Test.


Systemd itself does indeed search /usr/lib/systemd/system . Our
internal/Debian tooling though
(dh_installsystemd/invoke-rc.d/service/...) currently only handles files
from /lib/systemd (mostly for historical reasons where a /usr on a
separate partition mounted during late boot was still supported).

So, theoretically, you can install unit files in /usr/lib/systemd/system
and systemd will process them. What you don't get is full Debian
integration.

Regards,
Michael



signature.asc
Description: OpenPGP digital signature

Bug#963024: buster-pu: package tigervnc/1.9.0+dfsg-3+deb10u2

[Joachim Falk]

Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

The tigervnc-standalone-server/1.9.0+dfsg-3+deb10u1 package is affected
by a bug in libunwind8 (Bug: #923962) exhibited on architectures arm64,
armel, and armhf that makes it unusable (Bug: #932499) on those architectures.

As a workaround, the proposed update tigervnc/1.9.0+dfsg-3+deb10u2
disables building against libunwind on exactly these three architectures.
Other architectures are not affected by the proposed update.

-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: arm64 (aarch64)

Kernel: Linux 4.19.0-9-arm64 (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru tigervnc-1.9.0+dfsg/debian/changelog 
tigervnc-1.9.0+dfsg/debian/changelog
--- tigervnc-1.9.0+dfsg/debian/changelog2020-01-23 19:03:00.0 
+0100
+++ tigervnc-1.9.0+dfsg/debian/changelog2020-06-16 21:36:31.0 
+0200
@@ -1,3 +1,11 @@
+tigervnc (1.9.0+dfsg-3+deb10u2) buster; urgency=medium
+
+  [ Joachim Falk ]
+  * Don't use libunwind for armel, armhf, and arm64 as this library is buggy
+(bug #923962) on those architectures (Closes: #932499).
+
+ -- Joachim Falk   Tue, 16 Jun 2020 21:36:31 +0200
+
 tigervnc (1.9.0+dfsg-3+deb10u1) buster; urgency=high
 
   [ Joachim Falk ]
diff -Nru tigervnc-1.9.0+dfsg/debian/control tigervnc-1.9.0+dfsg/debian/control
--- tigervnc-1.9.0+dfsg/debian/control  2020-01-23 19:02:50.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/control  2020-06-16 21:36:31.0 +0200
@@ -54,7 +54,8 @@
  libaudit-dev [linux-any],
  libdrm-dev (>= 2.4.89) [!hurd-i386],
  libgl1-mesa-dev (>= 9.2),
- libunwind-dev [amd64 arm64 armel armhf hppa i386 ia64 mips64 mips64el mipsel 
powerpc powerpcspe ppc64 ppc64el sh4],
+# Don't use libunwind for armel, armhf, and arm64 as this library is buggy 
(bug #923962) on those architectures.
+ libunwind-dev [amd64 hppa i386 ia64 mips64 mips64el mipsel powerpc powerpcspe 
ppc64 ppc64el sh4],
  libxmuu-dev (>= 1:0.99.1),
  libxext-dev (>= 1:0.99.1),
  libx11-dev (>= 2:1.6),
diff -Nru tigervnc-1.9.0+dfsg/debian/rules tigervnc-1.9.0+dfsg/debian/rules
--- tigervnc-1.9.0+dfsg/debian/rules2020-01-23 19:02:51.0 +0100
+++ tigervnc-1.9.0+dfsg/debian/rules2020-06-16 21:36:31.0 +0200
@@ -25,6 +25,7 @@
 
 include /usr/share/cdbs/1/rules/debhelper.mk
 include /usr/share/cdbs/1/class/cmake.mk
+include /usr/share/dpkg/architecture.mk
 
 # Do our complex patch dance first! After that quilt patch system can proceed!
 clean:: unpatch
@@ -192,7 +193,7 @@
 #-include /usr/share/xserver-xorg/configure_flags.mk
 #xserver_confflags := $(shell echo '$(xserver_confflags)' | sed 
's/--with-builderstring="[^"]*"//')
 
-XORG_DEBIAN_CONFIGURE_FLAGS = \
+XORG_DEBIAN_CONFIGURE_FLAGS := \
$(filter-out \
--prefix=% \
--mandir=% \
@@ -214,6 +215,14 @@
, $(xserver_confflags) \
)
 
+# Don't use libunwind for armel, armhf, and arm64 as this library is buggy
+# (bug #923962) on those architectures.
+ifneq (,$(filter $(DEB_HOST_ARCH), armel armhf arm64))
+   DEB_CONFIGURE_EXTRA_FLAGS += --disable-libunwind
+   XORG_DEBIAN_CONFIGURE_FLAGS := \
+   $(filter-out --enable-libunwind, $(XORG_DEBIAN_CONFIGURE_FLAGS))
+endif
+
 # Next step is run configure script. It is very difficult use correct 
parameters.
 # You should use same parameters as used in your distribution X server and add
 # --disable-xvfb --disable-xnest --disable-xorg

Bug#962917: libatomic-ops: FTBFS in the testsuite on riscv64 due to missing -pthread

[Karsten Merker]

control: severity 962917 important
control: tags 962917 patch

On Tue, Jun 16, 2020 at 12:40:52AM +0200, Karsten Merker wrote:

> libatomic-ops FTBFS on riscv64 due to link failures in the
> testsuite. The build log is available at
> 
>   
> https://buildd.debian.org/status/fetch.php?pkg=libatomic-ops=riscv64=7.6.10-1=1588631725=0
> 
> The source of the link failures is that the tests aren't built
> with the "-pthread" compiler flag.
> 
> Some architectures such as risc64 have native atomics support,
> but only for word-sized operands and not for smaller entities. 
> When called with "-pthread", gcc automatically links in the
> necessary wrapper functions to provide the missing atomic
> operations on those architectures, but this doesn't happen when
> one just links in libpthread with "-lpthread".
> 
> Building the tests with "-pthread" in CFLAGS solves the build
> failures. It would be great if you could upload a new version
> of the package with a corresponding change.

Hello,

attached is a corresponding patch. If the patch is ok for you and
you would like me to perform an NMU, just let me know.

Regards,
Karsten
-- 
Ich widerspreche hiermit ausdrücklich der Nutzung sowie der
Weitergabe meiner personenbezogenen Daten für Zwecke der Werbung
sowie der Markt- oder Meinungsforschung.
>From 2c4627e01637b6e2b4ad3c7d8b8ed92ff020e92b Mon Sep 17 00:00:00 2001
From: Karsten Merker 
Date: Wed, 17 Jun 2020 20:34:06 +0200
Subject: [PATCH] Fix FTFBS in the testsuite on riscv64

---
 debian/changelog |  9 +
 .../libatomic-ops-enable-pthread-in-tests.diff   | 12 
 debian/patches/series|  1 +
 3 files changed, 22 insertions(+)
 create mode 100644 debian/patches/libatomic-ops-enable-pthread-in-tests.diff
 create mode 100644 debian/patches/series

diff --git a/debian/changelog b/debian/changelog
index 2731759..a0c6b39 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+libatomic-ops (7.6.10-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTFBS in the testsuite on riscv64 by adding "-pthread" to
+the testsuite's CFLAGS and thereby making sure that gcc enables
+full atomics support on all platforms. (Closes: #962917)
+
+ -- Karsten Merker   Wed, 17 Jun 2020 19:37:31 +0200
+
 libatomic-ops (7.6.10-1) unstable; urgency=medium
 
   * New upstream release
diff --git a/debian/patches/libatomic-ops-enable-pthread-in-tests.diff b/debian/patches/libatomic-ops-enable-pthread-in-tests.diff
new file mode 100644
index 000..9e6891b
--- /dev/null
+++ b/debian/patches/libatomic-ops-enable-pthread-in-tests.diff
@@ -0,0 +1,12 @@
+diff -Nur libatomic-ops-7.6.10.orig/tests/Makefile.am libatomic-ops-7.6.10/tests/Makefile.am
+--- libatomic-ops-7.6.10.orig/tests/Makefile.am
 libatomic-ops-7.6.10/tests/Makefile.am
+@@ -10,7 +10,7 @@
+ -I$(top_builddir)/src -I$(top_srcdir)/src \
+ -I$(top_builddir)/tests -I$(top_srcdir)/tests
+ 
+-CFLAGS += $(CFLAGS_EXTRA)
++CFLAGS += $(CFLAGS_EXTRA) -pthread
+ 
+ TESTS = test_atomic$(EXEEXT) test_atomic_generalized$(EXEEXT) \
+ test_stack$(EXEEXT) test_malloc$(EXEEXT)
diff --git a/debian/patches/series b/debian/patches/series
new file mode 100644
index 000..6bd8bef
--- /dev/null
+++ b/debian/patches/series
@@ -0,0 +1 @@
+libatomic-ops-enable-pthread-in-tests.diff
-- 
2.20.1

Bug#963023: budgie-extras: superficial autopkgtest

[Paul Gevers]

Source: budgie-extras
Version: 1.0.2-1

Dear maintainer(s),

Because of the recent failure of the autopkgtest of budgie-extras, I
happened to notice that the autopkgtest doesn't test the installed
packages, but the source code tree.

On top of that, the test doesn't substantially test the package, so
please mark your test as superficial, as requested by the release team [1].

Paul

[1] https://release.debian.org/bullseye/rc_policy.txt (section 6.a)



signature.asc
Description: OpenPGP digital signature

Bug#963022: quagga-core: zebra static routes tags not sent to clients

[Guillaume Lécroart]

quagga-core: zebra static routes tags not sent to clients
Package: quagga-core
Version: 1.2.4-3
Severity: normal

Dear Maintainer,

While testing a route-map in bgpd redistributing static routes with tags,
matching tags did not work.
Running "debug bgp zebra" revealed that whatever tag is set with the static
routes set in zebra, client daemon receives a null tag

Syslog debug excerpt :

Jun 17 21:33:12 jck bgpd[330852]: Zebra rcvd: IPv4 route add static
172.17.56.16/29 nexthop 192.168.39.39 metric 0 tag 0

route in zebra is configured with

ip route 172.17.56.16/29 192.168.39.39  tag 349346 244

RIB check :
# sh ip ro 172.17.56.16
Routing entry for 172.17.56.16/29
  Known via "static", distance 244, metric 0, tag 349346, vrf 0, best, fib,
blackhole
  >* 192.168.39.39, via eth0

  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages quagga-core depends on:
ii  adduser   3.118
ii  dpkg  1.19.7
ii  iproute2  4.20.0-2
ii  libc6 2.29-7
ii  libcap2   1:2.25-2
ii  libpam0g  1.3.1-5
ii  libreadline7  7.0-5
ii  libtinfo6 6.1+20181013-2+deb10u2

quagga-core recommends no packages.

Versions of packages quagga-core suggests:
ii  quagga-bgpd1.2.4-3
pn  quagga-isisd   
pn  quagga-ospf6d  
pn  quagga-ospfd   
pn quagga-pimd
pn  quagga-ripd
pn  quagga-ripngd  
pn  snmpd  

-- no debconf information

Rgds

Guillaume

Bug#963021: colorcode: optionnaly display number of remaining possible positions

[Bill Allombert]

Package: colorcode
Version: 0.8.5-2
Severity: wishlist
Tags: upstream

Hello Filippo,

It would be nice if colorcode has an option to display the remaining
number of positions that are compatible with the current information.

This would allow to see how lucky the players were, and how efficient their
strategies were.

Due to the current speed of computers, this can be done by trying all
positions, no need for fancy algorithm.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Bug#962998: Fixed with help from upstream

[Pirate Praveen]

Control: fixed -1 0.7.2-1~bpo10+2

Fixed after lowering minimum required versions of QtQuick, 
QtQuickControls and QtGraphicalEffects.

Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.

[R P Herrold]

On Wed, 17 Jun 2020, Adrian Bunk wrote:

> On Wed, Jun 17, 2020 at 12:20:46PM +0200, Piotr Kolasi?ski wrote:
> > On Tue, Jun 16, 2020 at 11:24:11AM +0300, Adrian Bunk wrote:
> >...
> > > s390x is the only headless release architecture.
> > > This was a real pain for the Debian GNOME maintainers already before
> > > the last release, without any support from s390x porters on fixing
> > > this issue.[1]
> > I don't agree. Fact, that s390x doesn't have direct display doesn't mean
> > that graphical tools are not used.
> >...
> 
> Fact is that the s390x port is different from all other ports in Debian.
> And it is causing extra work to support such a port.

> Which is an even bigger problem when there are no porters doing this work.

A lack of porters is an issue.  The reason I don't 'lend a 
hand' here is the Byzantine and opaque nature of Debian 'hoop 
jumping'

I say this having approached Ian Murdock (rip), and his former 
employee Jeff Licquia, each through the good offices of weekly 
LSB conference calls, trying to get past that
 
> I do not know whether there is anything special about threading on s390x 
> compared to other Linux architectures, but porters are expected to know.

A reproducer was not included.  File a bug and I'll look at it

> Debian does not have a service agreement with IBM for maintaining the 
> Debian kernel on s390x, it is the duty of the s390x porters to maintain
> the Debian kernel and debug problems in the Debian kernel.

'duty' as a concept in a social voluntary organization is a 
slippery concept.  Many people asserting duties by others are 
really seeking free support, and then disappear like magic.  
That gets tiring, is not sustainable, and long ago at CentOS, 
I set the standard and tone that we don't facilitate such 
behaviour [that has changed with the RHT/IBM purchase, but 
the history stands]
 
> > > A port like s390x with unique problems is only sustainable when several 
> > > people with good knowledge of Debian, s390x hardware and the Linux 
> > > kernel have a long-term commitment of swiftly supporting everyone in 
> > > Debian with s390x problems.

> > Good point - the question is why there is not so many people with "good
> > knowledge of Debian" in Mainframe environment?

It is true there are not many known outside of more s390x 
focussed mailing lists, as there is no material Debian 
'uptake' in an Enterprise production environment.  That space 
is small enough that it supports about three non IBM, or SUSE 
players with more than 20 employees

> Debian is a volunteer project.
> s390x is a business-to-business affair.
> 
> Other ports have a community of people who have a Raspberry Pi or 
> an old hppa workstation at home.

umm

Not to put too fine a point on this fine rant, but I've been 
building and supporting a community rebuild of RHEL for 
several years [called ClefOS] now on s390 and s390x (no longer 
s390, as interest died off)

I did so back in the days when I was an active member of the 
CentOS project (one of its founders, actually), before RHT / 
IBM 'bought it out'

I've pushed in fixes needed for LSB / FHS purposes from time 
to time in the past

Build machines are readily available, without charge, through 
Marist Univerity, as well as the more recent IBM spoonsored 
Linux One

As I recall, Alpine has been building a viable s390x 
community distribution for the last couple of years as well

Rick Troth ( a well known s390x'er in the community ) has his 
'Nord' standalone distribution

-- Russ herrold

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Andreas Tille]

Hi,

On Wed, Jun 17, 2020 at 02:12:09PM -0400, Olek Wojnar wrote:
> > That was easy. I have pushed my changes to "sudip" which now builds
> > only those two.
> 
> Great, thanks!

Yep.
 
> Good catch, thanks! The repo should be named google-api-client-java for
> consistency with the rest of the ecosystem. (And Debian Java policy)

Name fixed and uploaded to experimental.

Thanks to all who helped

  Andreas.

-- 
http://fam-tille.de

Bug#963020: impacket breaks smbmap autopkgtest: No module named 'pkg_resources'

[Paul Gevers]

Source: impacket, smbmap
Control: found -1 impacket/0.9.21-1
Control: found -1 smbmap/1.8.2-1
Severity: serious
Tags: sid bullseye
X-Debbugs-CC: debian...@lists.debian.org
User: debian...@lists.debian.org
Usertags: breaks needs-update

Dear maintainer(s),

With a recent upload of impacket the autopkgtest of smbmap fails in
testing when that autopkgtest is run with the binary packages of
impacket from unstable. It passes when run with only packages from
testing. In tabular form:

   passfail
impacket   from testing0.9.21-1
smbmap from testing1.8.2-1
all others from testingfrom testing

I copied some of the output at the bottom of this report. Is the latest
impacket missing a dependency or is the version function not supported
anymore?

Currently this regression is blocking the migration of impacket to
testing [1]. Due to the nature of this issue, I filed this bug report
against both packages. Can you please investigate the situation and
reassign the bug to the right package?

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

Paul

[1] https://qa.debian.org/excuses.php?package=impacket

https://ci.debian.net/data/autopkgtest/testing/amd64/s/smbmap/5914948/log.gz

autopkgtest [07:08:34]: test command1: smbmap -h
autopkgtest [07:08:34]: test command1: [---
Traceback (most recent call last):
  File "/usr/bin/smbmap", line 19, in 
from impacket import version, smbserver
  File "/usr/lib/python3/dist-packages/impacket/version.py", line 7, in

import pkg_resources
ModuleNotFoundError: No module named 'pkg_resources'
autopkgtest [07:08:35]: test command1: ---]



signature.asc
Description: OpenPGP digital signature

Bug#962974: RFS: t-coffee bug #962974 fix

[Étienne Mollier]

Control: tags -1 fixed pending

Greetings,

I took some time to reset my machine to the new default pid_max,
and with a build of t-coffee with an increased MAX_N_PID to
4194304.  This approach seems to work, because the program
properly outputs its version without crash or memory saturation:

$ bash -c 'echo $$' && t_coffee -version && bash -c 'echo $$'
1012124
PROGRAM: T-COFFEE Version_13.41.0.28bdc39 (2019-11-30 10:21:53 - 
Revision 5d5a1c1 - Build 465)
1012132

The run-unit-test script works under high PID number conditions
as well.  My quick understanding of the code is that this number
is used for building a sparse table of processes, which would
grow from 2M to 33M: it is the only drawback I can think of from
that approach, which might remain reasonable (although it might
be a wee bit more a concern on 32 bits CPU).

The updated package is pushed on Salsa and ready for review:

https://salsa.debian.org/med-team/t-coffee


I could not pinpoint the exact moment the default pid_max change
occurred in Debian Bullseye, but the new value of 4194304 is
there and it looks like it will become common in the next few
generations of systems.

That value seems to be a structural limit within Linux on 64bits
machines, so don't seem to be bound to grow further anytime
soon.  From the patch in https://lkml.org/lkml/2020/4/8/344:
| + * Linux limits the maximum number of tasks to PID_MAX_LIMIT, which is 
currently
| + * 0x40 (and can't easily be raised in the future beyond FUTEX_TID_MASK).

Kind Regards,
-- 
Étienne Mollier 
Fingerprint:  5ab1 4edf 63bb ccff 8b54  2fa9 59da 56fe fff3 882d
Help find cures against the Covid-19 !  Give CPU cycles:
  * Rosetta@home: https://boinc.bakerlab.org/rosetta/
  * Folding@home: https://foldingathome.org/


signature.asc
Description: PGP signature

Bug#963019: RFS: pem/0.7.9-3 -- command line personal expense manager

[David da Silva Polverari]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: pem
   Version : 0.7.9-3
   Upstream Author : Prasad J Pandit 
 * URL : https://www.gnu.org/software/pem/
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/pem
   Section : misc

It builds those binary packages:

  pem - command line personal expense manager

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/p/pem/pem_0.7.9-3.dsc

Changes since the last upload:

   * Using new DH level format. Consequently:
   - debian/compat: removed.
   - debian/control: changed from 'debhelper' to 'debhelper-compat' in
 Build-Depends field and bumped level to 13.
   * debian/control:
   - Added '${perl:Depends}' to Depends field.
   - Added 'Rules-Requires-Root: no' to source stanza.
   - Added Vcs-* fields.
   - Bumped Standards-Version to 4.5.0.
   - Marked pem as 'Multi-Arch: foreign'.
   - Removed redundant dh-autoreconf build dependency.
   * debian/copyright: updated copyright years.
   * debian/patches/010_use-usr-bin-perl.patch: added to use '/usr/bin/perl'
 instead of '/usr/bin/env perl' for interpreter invocation.
   * debian/rules: removed redundant '--with autoreconf' dh parameter.
   * debian/salsa-ci.yml: added to provide CI tests for Salsa.
   * debian/tests/control: added to perform a trivial CI test.
   * debian/upstream/metadata: created.
   * debian/watch: using a secure URI.

Regards,

--
  David da Silva Polverari

Bug#963018: /root/.my.cnf overrides .backup-manager_my.cnf config

[sbalbous]

Package: Backup Manager
Version: 0.7.14

Context :
Debian 10.4
mysql Ver 15.1 Distrib 10.3.22-MariaDB
Backup Manager 0.7.14

The backup fail with the following error:
mysqldump: Got error: 1045: "Access denied for user 'backupmanager'@'localhost' 
(using password: YES)" when trying to connect

When I use mysql/mysqldump with -u and -p options, no issues all is fine

The file /root/.backup-manager_my.cnf is present and with the correct 
permissions / password inside.

I have another file /root/.my.cnf containing root user and password and I think 
this is the source of the issue !

When referring to 
https://mariadb.com/kb/en/configuring-mariadb-with-option-files/, it seems that 
the filed passed in the command line with —default-extra-file is overrides with 
the .my.cnf values

if I manually update the commande issued by backup manager using « 
—default-file » instead of « —default-extra-file », it works

sudo /usr/bin/mysqldump --defaults-file=/root/.backup-manager_my.cnf --opt 
-ubackupmanager -hlocalhost -P3306 mysql > mysql.sql


Can you confirm the issue, please ?

Any chance to have this fixed soon or I should « patch » 
https://salsa.debian.org/debian/backup-manager/-/blob/master/lib/backup-methods.sh#L1016
 ?
Maybe the most flexible way would be to be able to define the name of the 
parameter to be used (—default-file or —default-extra-file) in the config file.

Cheers
-sylvain

Bug#941235: remmina-plugin-vnc: VNC plugin not registered

[Matteo F. Vescovi]

Hi!

On 2019-09-27 at 10:48 (-04), Eric Cooper wrote:
> $ dpkg -l | grep vnc
> ii  gir1.2-gtk-vnc-2.0:amd64  0.9.0-1.1+b1
> amd64GObject introspection data for GTK-VNC
> ii  libgtk-vnc-2.0-0:amd640.9.0-1.1+b1
> amd64VNC viewer widget for GTK+3 (runtime libraries)
> ii  libgvnc-1.0-0:amd64   0.9.0-1.1+b1
> amd64VNC GObject wrapper (runtime libraries)
> ii  libvncclient1:amd64   0.9.11+dfsg-1.3
>amd64API to write one's own VNC server - client library
> ii  remmina-plugin-vnc:amd64  1.3.6+dfsg-2
> amd64VNC plugin for Remmina
> ii  tigervnc-viewer   1.9.0+dfsg-3
> amd64Virtual network computing client for X

Eric,

has the situation changed with newer versions?

Please, let me know so I can triage this bug report better... or even
close it, if the issue doesn't show up anymore.

Cheers.

-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature

Bug#586413: ITA: tightvnc -- virtual network computing server software

[Sven Geuer]

Owner: debma...@g-e-u-e-r.de

Hi Ola,

thank you for your consent. I take ownership of this bug now. It will
be closed with the upcoming upload of tightvnc.

Thanks for having maintained tightvnc for all these years.

If there's anything in contrast to what you intended, please let me
know. We'll get it sorted out.

Sven

Am Mittwoch, den 17.06.2020, 11:25 +0200 schrieb Ola Lundqvist:
> Hi
> 
> Wonderful!
> 
> It would be great if someone else take over. Please remove me as
> uploader.
> I have maintained it for many years now and it is time for someone
> else to
> take it over.
> 
> / Ola
> 
> 
> Den ons 17 juni 2020 08:14Mike Gabriel  skrev:
> 
> > Hi Sven,
> > 
> > On  Di 16 Jun 2020 23:07:27 CEST, Sven Geuer wrote:
> > 
> > > Hi Mike,
> > > Hi Ola,
> > > 
> > > I would be interested in maintaining tightvnc as a new member of
> > > the
> > > Debian Remote Maintainers Team. I already started some work on it
> > > in a
> > > private repository on salsa [1]. 'FTBFS with gcc-10' is already
> > > fixed.
> > > 
> > > Being a DM, I currently maintain two packages under the umbrella
> > > of the
> > > Debian Security Tools Packaging Team, and had contributed to
> > > other
> > > packages of this team [2].
> > > 
> > > @Mike: May I ask you to accept me as team member to debian-
> > > remote?
> > > @Ola: Would you want to stay listed as uploader with moving
> > > tightvnc to
> > > the team?
> > > 
> > > Please let me know, if you accept my application.
> > > 
> > > Best,
> > > Sven
> > > 
> > > [1] https://salsa.debian.org/sven-geuer-guest/tightvnc
> > > [2] 
> > > https://qa.debian.org/developer.php?email=debmaint%40g-e-u-e-r.de
> > 
> > Awesome! Regarding your Debian Remote Team applications: Welcome
> > in!
> > 
> > I'll wait for Ola's response, then I'll give you permissions on the
> > tightvnc.git repo.
> > 
> > Mike
> > --
> > 
> > mike gabriel aka sunweaver (Debian Developer)
> > mobile: +49 (1520) 1976 148
> > landline: +49 (4351) 486 14 27
> > 
> > GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577
> > 1B31
> > mail: sunwea...@debian.org, http://sunweavers.net
> > 
> > 


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

Bug#963017: linux-image-5.6.0-2-amd64: System freezes shortly after boot

[Michel Messerschmidt]

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

Dear Maintainer,

after the kernel upgrade to 5.6.14, my system now freezes some seconds after 
each boot, 
during Xorg start. Login via Xorg or console is not possible anymore.

The kernel log ends with these messages:
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x0:0x0, last cmd=0x5f0900
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x0:0x0, last cmd=0x5f0900
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x3:0x0, last cmd=0x5f0900
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x0:0x0, last cmd=0x5f0900
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x0:0x0, last cmd=0x5f0900
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x3:0x0, last cmd=0x5f0900
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x0:0x0, last cmd=0x5f0900
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x0:0x0, last cmd=0x5f0900
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x3:0x0, last cmd=0x5f0900
Jun 17 14:38:49 ryu kernel: snd_hda_intel :01:00.1: spurious response 
0x0:0x0, last cmd=0x5f0900
Jun 17 14:39:12 ryu kernel: rcu: INFO: rcu_sched self-detected stall on CPU
Jun 17 14:39:12 ryu kernel: rcu: 1-: (5249 ticks this GP) 
idle=b62/1/0x4002 softirq=5070/5070 fqs=2624 
Jun 17 14:39:12 ryu kernel: (t=5250 jiffies g=2237 q=894)
Jun 17 14:39:12 ryu kernel: NMI backtrace for cpu 1
Jun 17 14:39:12 ryu kernel: CPU: 1 PID: 1062 Comm: pulseaudio Tainted: P
   OE 5.6.0-2-amd64 #1 Debian 5.6.14-2
Jun 17 14:39:12 ryu kernel: Hardware name: Gigabyte Technology Co., Ltd. To be 
filled by O.E.M./F2A88X-D3H, BIOS F5 05/28/2014
Jun 17 14:39:12 ryu kernel: Call Trace:
Jun 17 14:39:12 ryu kernel:  
Jun 17 14:39:12 ryu kernel:  dump_stack+0x66/0x90
Jun 17 14:39:12 ryu kernel:  nmi_cpu_backtrace.cold+0x14/0x53
Jun 17 14:39:12 ryu kernel:  ? lapic_can_unplug_cpu.cold+0x3e/0x3e
Jun 17 14:39:12 ryu kernel:  nmi_trigger_cpumask_backtrace+0xf6/0xf8
Jun 17 14:39:12 ryu kernel:  rcu_dump_cpu_stacks+0x8f/0xbd
Jun 17 14:39:12 ryu kernel:  rcu_sched_clock_irq.cold+0x1b2/0x3a0
Jun 17 14:39:12 ryu kernel:  update_process_times+0x24/0x50
Jun 17 14:39:12 ryu kernel:  tick_sched_handle+0x22/0x60
Jun 17 14:39:12 ryu kernel:  tick_sched_timer+0x38/0x80
Jun 17 14:39:12 ryu kernel:  ? tick_sched_do_timer+0x60/0x60
Jun 17 14:39:12 ryu kernel:  __hrtimer_run_queues+0xf6/0x270
Jun 17 14:39:12 ryu kernel:  hrtimer_interrupt+0x10e/0x240
Jun 17 14:39:12 ryu kernel:  smp_apic_timer_interrupt+0x6c/0x130
Jun 17 14:39:12 ryu kernel:  apic_timer_interrupt+0xf/0x20
Jun 17 14:39:12 ryu kernel:  
Jun 17 14:39:12 ryu kernel: RIP: 0010:_raw_spin_unlock_irqrestore+0x11/0x20
Jun 17 14:39:12 ryu kernel: Code: 44 89 e8 5d 41 5c 41 5d 41 5e c3 cc cc cc cc 
cc cc cc cc cc cc cc cc cc cc 0f 1f 44 00 00 c6 07 00 0f 1f 40 00 48 89 f7 57 
9d <0f> 1f 44 00 00 c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89
Jun 17 14:39:12 ryu kernel: RSP: 0018:b5ac41733d80 EFLAGS: 0246 
ORIG_RAX: ff13
Jun 17 14:39:12 ryu kernel: RAX:  RBX: 9eca21ff4514 RCX: 

Jun 17 14:39:12 ryu kernel: RDX:  RSI: 0246 RDI: 
0246
Jun 17 14:39:12 ryu kernel: RBP: 0001 R08: 9ec707801da8 R09: 
9ec707801f50
Jun 17 14:39:12 ryu kernel: R10:  R11: 9a250c48 R12: 
9eca21ff4498
Jun 17 14:39:12 ryu kernel: R13: 0246 R14: 9eca21ff4400 R15: 

Jun 17 14:39:12 ryu kernel:  __synchronize_hardirq+0x74/0xe0
Jun 17 14:39:12 ryu kernel:  synchronize_irq+0x35/0xa0
Jun 17 14:39:12 ryu kernel:  do_hw_free+0x13/0x50 [snd_pcm]
Jun 17 14:39:12 ryu kernel:  snd_pcm_common_ioctl+0x764/0xe60 [snd_pcm]
Jun 17 14:39:12 ryu kernel:  ? __fput+0x160/0x250
Jun 17 14:39:12 ryu kernel:  snd_pcm_ioctl+0x23/0x30 [snd_pcm]
Jun 17 14:39:12 ryu kernel:  ksys_ioctl+0x87/0xc0
Jun 17 14:39:12 ryu kernel:  __x64_sys_ioctl+0x16/0x20
Jun 17 14:39:12 ryu kernel:  do_syscall_64+0x52/0x180
Jun 17 14:39:12 ryu kernel:  entry_SYSCALL_64_after_hwframe+0x44/0xa9
Jun 17 14:39:12 ryu kernel: RIP: 0033:0x7fd2b1af4457
Jun 17 14:39:12 ryu kernel: Code: 00 00 90 48 8b 05 39 7a 0c 00 64 c7 00 26 00 
00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 
05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 7a 0c 00 f7 d8 64 89 01 48
Jun 17 14:39:12 ryu kernel: RSP: 002b:7ffe861152a8 EFLAGS: 0246 
ORIG_RAX: 0010
Jun 17 14:39:12 ryu kernel: RAX: ffda RBX: 5584f40bb7d0 RCX: 
7fd2b1af4457
Jun 17 14:39:12 ryu kernel: RDX: 0001 RSI: 4112 RDI: 
0011
Jun 17 14:39:12 ryu kernel: RBP: 5584f40bb750 R08:  R09: 
7ffe86115280
Jun 17 14:39:12 ryu kernel: R10: 

Bug#963016: ITP: ruby-rubocop-packaging -- Automatic downstream compatibility checking tool for Ruby code

[Utkarsh Gupta]

Package: wnpp
Severity: wishlist
Owner: Utkarsh Gupta 

* Package name : ruby-rubocop-packaging
  Version  : 0.1.0
  Upstream Author  : Utkarsh Gupta
* URL  : https://github.com/utkarsh2102/batalert
* License  : Expat
  Programming Lang : Ruby
  Description  : Automatic downstream compatibility checking tool
for Ruby code
 RuboCop::Packaging is an extension of RuboCop, which is a Ruby static code
 analyzer (a.k.a. linter) and code formatter.
 .
 It helps enforcing some of the guidelines that are expected of upstream
 maintainers so that the downstream can build their packages in a clean
 environment without any problems.


Best,
Utkarsh

Bug#963015: ITP: pyranges -- 2D representation of genomic intervals and their annotations

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: pyranges -- 2D representation of genomic intervals and their 
annotations
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: pyranges
  Version : 0.0.58
  Upstream Author : Endre Bakken Stovner
* URL : https://github.com/biocore-ntnu/pyranges
* License : MIT
  Programming Lang: Python
  Description : 2D representation of genomic intervals and their annotations
 A PyRanges object must have the columns Chromosome, Start and
 End. These describe the genomic position and function as implicit row
 labels. A Strand column is optional and adds strand information to the
 intervals. Any other columns are allowed and are considered metadata.
 .
 The structure can be filled from .bed, .bam or .gff files, also from
 tabular or textual representations.

Remark: This package is maintained by Debian Med Packaging Team at
   https://salsa.debian.org/med-team/pyranges

Bug#962998: QtQuickControls2 version fixed

[Pirate Praveen]

After help from upstream previous error with QtQuickControsl 2 was 
fixed now we get


[2020-06-17 23:43:11.599] [qml] [warning] 
qrc:/qml/emoji/EmojiPicker.qml:4:1: module "QtGraphicalEffects" version 
1.9 is not installed (qrc:/qml/emoji/EmojiPicker.qml:4, )

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Olek Wojnar]

Hi Sudip,

On Wed, Jun 17, 2020, 13:38 Sudip Mukherjee 
wrote:

>
> That was easy. I have pushed my changes to "sudip" which now builds
> only those two.
>

Great, thanks!

And, just noticed (after pushing) that the Vcs in d/control is wrong.
> It should be https://salsa.debian.org/java-team/google-api-java-client
> or the repo needs to be renamed.
>

Good catch, thanks! The repo should be named google-api-client-java for
consistency with the rest of the ecosystem. (And Debian Java policy)

-Olek

PS I suppose one could theoretically do google-api-java-client-java but I
think that's needlessly awkward and repetitive.

Bug#963013: invada-studio-plugins-lv2 edit dialog suil error

[Paulo S. Pinheiro]

Package: invada-studio-plugins-lv2

Version: 1.2.0+repack0-8

Uname: Linux 5.4.0-37-lowlatency x86_64

DistroRelease: Ubuntu 20.04

Description:

*I've tried before to report thist bug in Lanunchpad to Ubuntu 
Developers, but they directed me to Debian, because they import the 
package unchanged.*


Here's what happens:
Since I upgraded to Ubuntustudio 20.04 (Intel 64-bit) I can't open the INVADA 
plugins edit dialog on Ardour5 (rev 1:5.12.0-3ubuntu4). No error message dialog.
Running Ardour5 on terminal and trying again I get the following message line 
(example: Invada Early Reflection Reverb):
   "suil error: Unable to open UI library 
/usr/lib/lv2/invada.lv2/inv_erreverb_gui.so (/usr/lib/lv2/invada.lv2/inv_erreverb_gui.so: 
undefined symbol:__sinh_finite)"*.

The inv_erreverb_gui.so* is correctly in */usr/lib/liv2/invada.lv2 directory.

The Ardour native generic control editor dialog works fine for the plugins.

I noticed some LV2 plugins editors open correctly, some others don't. Here are 
the ones with the problem:
. Invada Compressor
. Invada Early Reflection Reverb
. Invada High Pass Filter
. Invada Input Module
. Invada Low Pass Filter
. Invada Meter
. Invada Stereo Phaser
. Invada Tube Distortion

The "good" ones:
. Invada Delay Munge
. Invada Test Tones

The error messages for the other problematic plugins are similar to the  one 
above. The files are all there on the expected directory. Haven't find any 
workaround by Ubuntu Studio or Ardour.

When I tried to compile the Ubuntu package 
(invada-studio-plugins-lv2_1.2.0+repack0) from source I got the error:

"dpkg-checkbuilddeps: erro: Unmet build dependencies: debhelper (>= 11) 
libgtk2.0-dev lv2-dev"

In my system I have:
debhelper: 12.10ubuntu1
libgtk2.0-dev: 2.24.32-4ubuntu4
lv2-dev: 1.16.0-1

So, it seems to me that the plugin is not compatible with the new libgtk2.0-dev 
library, and/or lv2-dev.

But I'm very newbie.


Any other information you need to solve the problem, please let me know.


Thank you in Advance


Paulo S. Pinheiro   

Bug#598892: wu office

[wwwheadoffi...@gmail.com]

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Sudip Mukherjee]

On Wed, Jun 17, 2020 at 5:40 PM Olek Wojnar  wrote:
>
> On Wed, Jun 17, 2020 at 12:19 PM Andreas Tille  wrote:
>>
>> I have the feeling we are coming closer to a solution iteratively now
>> but there are some remaining errors unfortunately:
>
>
> If any of you have a moment, I recommend patching the main pom.xml to only 
> build the two modules that we need (google-api-client and 
> google-api-client-jackson2). That should vastly simplify things.

That was easy. I have pushed my changes to "sudip" which now builds
only those two.
And, just noticed (after pushing) that the Vcs in d/control is wrong.
It should be https://salsa.debian.org/java-team/google-api-java-client
or the repo needs to be renamed.


-- 
Regards
Sudip

Bug#960379: Patch

[Giovanni Mascellani]

Hi, the attached patch seems to work. I don't have time right now to
send in an NMU.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles
From 247b1d32c5e5ddf0a1f629b85147209718255044 Mon Sep 17 00:00:00 2001
From: Giovanni Mascellani 
Date: Wed, 17 Jun 2020 19:06:20 +0200
Subject: [PATCH] Fix FTBFS with Boost 1.71.

---
 .../0006-Fix-FTBFS-with-Boost-1.71.patch  | 21 +++
 debian/patches/series |  1 +
 2 files changed, 22 insertions(+)
 create mode 100644 debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch

diff --git a/debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch b/debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch
new file mode 100644
index 0..b102e1227
--- /dev/null
+++ b/debian/patches/0006-Fix-FTBFS-with-Boost-1.71.patch
@@ -0,0 +1,21 @@
+From: Giovanni Mascellani 
+Date: Wed, 17 Jun 2020 19:05:43 +0200
+Subject: Fix FTBFS with Boost 1.71.
+
+---
+ src/rpc/blockchain.cpp | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/rpc/blockchain.cpp b/src/rpc/blockchain.cpp
+index bd35163..52fcd3c 100644
+--- a/src/rpc/blockchain.cpp
 b/src/rpc/blockchain.cpp
+@@ -2198,7 +2198,7 @@ UniValue scantxoutset(const JSONRPCRequest& request)
+ // no scan in progress
+ return NullUniValue;
+ }
+-result.pushKV("progress", g_scan_progress);
++result.pushKV("progress", int(g_scan_progress));
+ return result;
+ } else if (request.params[0].get_str() == "abort") {
+ CoinsViewScanReserver reserver;
diff --git a/debian/patches/series b/debian/patches/series
index 31faa743e..4257bd031 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -3,3 +3,4 @@
 1003_man_proper_header.patch
 2001_avoid_embedded_libs.patch
 2002_avoid_network_tests.patch
+0006-Fix-FTBFS-with-Boost-1.71.patch
-- 
2.27.0



signature.asc
Description: OpenPGP digital signature

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Andreas Gruenbacher]

On Wed, Jun 17, 2020 at 5:31 PM J. Bruce Fields  wrote:
>
> On Wed, Jun 17, 2020 at 04:42:56PM +0200, Andreas Gruenbacher wrote:
> > Hi Bruce,
> >
> > On Wed, Jun 17, 2020 at 2:58 AM J. Bruce Fields  wrote:
> > > I think I'll send the following upstream.
> >
> > looking good, but how about using a little helper for this?
>
> I like it.  And the new comment's helpful too.
>
> >
> > Also I'm not sure if ecryptfs gets this right, so taking the ecryptfs
> > list into the CC.
>
> Yes, questions I had while doing this:
>
> - cachefiles, ecrypfs, devtmpfs, and unix_mknod skip the check,
>   is that OK for all of them?  (Overlayfs too, I think?--that
>   code's harder to follow.
>
> - why don't vfs_{create,mknod,mkdir} do the IS_POSIXACL check
>   themselves?  Even if it's unnecessary for some callers, surely
>   it wouldn't be wrong?

That's a good question. The security_path_{mkdir,mknod} hooks would
then probably be passed the original create mode before applying the
umask, but at that point it's not clear what the new inode's final
mode will be, anyway.

> I also wondered why both vfs_{create,mknod,mkdir} and the callers were
> calling security hooks, but now I see that the callers are calling
> security_path_* hooks and the vfs_ functions are calling
> security_inode_* hooks, so I guess they're not redundant.
>
> Though now I wonder why some of the callers (nfsd, overlayfs) are
> skipping the security_path_* hooks.

The path based security hooks are only used by apparmor and tomoyo.
Those hooks basically control who (which process) can do what where in
the filesystem, but nfsd isn't aware of the "who", and overlayfs is a
layer below the "where".

Andreas

Bug#962912: glib2.0: g_file_copy_attributes() chokes on binary xattr values

[Philip Withnall]

On Tue, 2020-06-16 at 02:44 +0200, Sergio Gelato wrote:
> control: tags -1 + patch
> 
> * Philip Withnall [2020-06-15 23:25:18 +0200]:
> > https://gitlab.gnome.org/GNOME/glib/-/issues/422
> > 
> > Nobody has yet found time to work on it; merge requests are
> > welcome!
> 
> Here is a patch that works for me.

Thanks. In order for it to go through the GLib CI, review process, and
be properly attributed to you, could you please create a merge request
for it upstream?

https://gitlab.gnome.org/GNOME/glib/-/merge_requests/new

Thanks,
Philip

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Olek Wojnar]

On Wed, Jun 17, 2020 at 12:19 PM Andreas Tille  wrote:

> I have the feeling we are coming closer to a solution iteratively now
> but there are some remaining errors unfortunately:
>

If any of you have a moment, I recommend patching the main pom.xml to only
build the two modules that we need (google-api-client and
google-api-client-jackson2). That should vastly simplify things.

-Olek

Bug#963012: iptables-persistent: forces use of iptables-legacy modules

[Thorsten Glaser]

Package: iptables-persistent
Version: 1.0.11
Severity: important

root@jens:~# netfilter-persistent save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
# Warning: iptables-legacy tables present, use iptables-legacy-save to see them
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save
# Warning: ip6tables-legacy tables present, use ip6tables-legacy-save to see 
them

There are no legacy tables present, though:

root@jens:~# iptables -nvL
Chain INPUT (policy ACCEPT 4768 packets, 551K bytes)
 pkts bytes target prot opt in out source   destination
[…]
 1580 96616 RETURN all  --  *  *   0.0.0.0/00.0.0.0/0
# Warning: iptables-legacy tables present, use iptables-legacy to see them
root@jens:~# iptables-legacy -nvL
Chain INPUT (policy ACCEPT 586 packets, 39772 bytes)
 pkts bytes target prot opt in out source   destination 


Chain FORWARD (policy ACCEPT 10 packets, 760 bytes)
 pkts bytes target prot opt in out source   destination 


Chain OUTPUT (policy ACCEPT 387 packets, 124K bytes)
 pkts bytes target prot opt in out source   destination 



The warning comes because the legacy kernel modules are loaded.
Calling iptables-legacy will auto-load them, so we blacklist them…

root@jens:~# cat /etc/modprobe.d/iptables-legacy.conf 
blacklist arptable_filter
blacklist ebtable_broute
blacklist ebtable_filter
blacklist ebtable_nat
blacklist ip6table_filter
blacklist ip6table_mangle
blacklist ip6table_nat
blacklist ip6table_raw
blacklist ip6table_security
blacklist iptable_filter
blacklist iptable_mangle
blacklist iptable_nat
blacklist iptable_raw
blacklist iptable_security

… but then it errors out like this:

root@jens:~# netfilter-persistent save
run-parts: executing /usr/share/netfilter-persistent/plugins.d/15-ip4tables save
Warning: skipping IPv4 (Kernel support is missing)
run-parts: executing /usr/share/netfilter-persistent/plugins.d/25-ip6tables save
/usr/share/netfilter-persistent/plugins.d/25-ip6tables: 36: 
/usr/share/netfilter-persistent/plugins.d/25-ip6tables: log_action_cont_msg: 
not found
run-parts: /usr/share/netfilter-persistent/plugins.d/25-ip6tables exited with 
return code 127

This is two errors in one (but the log_action_cont_msg bug
is already reported elsewhere so I’ll concentrate on the
15-ip4tables one (which probably also affects 25-ip6tables
though).

The code in question:
save_rules()
{
#save IPv4 rules
#need at least iptable_filter loaded:
modprobe -b -q iptable_filter || true
if [ ! -f /proc/net/ip_tables_names ]; then
echo "Warning: skipping IPv4 (Kernel support is 
missing)"

This is doubly wrong. The iptable_filter module and
*especially* /proc/net/ip_tables_names are used ONLY
by iptables-legacy; see the following for details:
https://bugzilla.redhat.com/show_bug.cgi?id=1668007

Effectively, iptables-persistent in buster forces
the use of iptables-legacy ONLY.

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=de_DE.UTF-8 (charmap=locale: Cannot set LC_MESSAGES to default 
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages iptables-persistent depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  iptables   1.8.2-4
ii  netfilter-persistent   1.0.11

iptables-persistent recommends no packages.

iptables-persistent suggests no packages.

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LC_MESSAGES = "en_GB.utf8",
LC_MEASUREMENT = "en_GB.utf8",
LC_PAPER = "en_GB.utf8",
LANG = "de_DE.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("de_DE.UTF-8").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
  iptables-persistent/autosave_v6: true
  iptables-persistent/autosave_v4: true

Bug#905385: stretch-pu: package weboob/1.2-1

[duck]

Quack,

On 2020-06-17 02:32, Adam D. Barratt wrote:


That's entirely your choice. I'll convert this request to a removal
from oldstable,  but if you do decide that you'd like to update it
instead then please let us know ASAP.


Thanks for the clarification.
Please convert it to removal then.

Regards.
\_o<

--
Marc Dequènes

Bug#963011: scalene: please re-upload as source-only

[ydirson]

Package: python3-scalene
Version: 0.7.5-1

The package has not migrated to testing and 
https://tracker.debian.org/pkg/scalene shows
why:

 Not built on buildd: arch all binaries uploaded by sergi...@sergiodj.net, a 
new source-only upload is needed to allow migration

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Andreas Tille]

Hi Sudip,

On Wed, Jun 17, 2020 at 11:42:52AM +0100, Sudip Mukherjee wrote:
> 
> I have taken the liberty to push to "tmancill" branch and the issue

As I tried to express:  I wished you all would take the freedom to
simply push to the master branch which is perfectly fine for me. ;-)
Thanks a lot for providing some fix in any case!

> with "com.google.api.client.util" is now resolved. It needs to depend
> on "libgoogle-oauth-client-java" which is still in NEW.

I've a local repository and can deal with this.

> But, it now fails with:
> 
> google-api-client/src/main/java/com/google/api/client/googleapis/services/AbstractGoogleClientRequest.java:[435,16]
> cannot find symbol
> [ERROR]   symbol:   method setResponseReturnRawInputStream(boolean)
> [ERROR]   location: variable httpRequest of type
> com.google.api.client.http.HttpRequest
> 
> And, indeed 
> https://salsa.debian.org/java-team/google-http-client-java/-/blob/master/google-http-client/src/main/java/com/google/api/client/http/HttpRequest.java
> is not having the method "setResponseReturnRawInputStream". And, it
> seems the packaged version of libgoogle-http-client-java in Debian is
> 1.27 and "setResponseReturnRawInputStream" was added in v1.29.0. So,
> we will need to update  libgoogle-http-client-java to 1.29.0 atleast.

I somehow ignored Olek's hint that we should rather start with version
1.27 to avoid issues with circular (and more) dependencies.  That's
why I downgraded the version in Git now and merged tmancill branch to
master. 

I have the feeling we are coming closer to a solution iteratively now
but there are some remaining errors unfortunately:


...
[INFO] --- maven-compiler-plugin:3.8.1:testCompile (default-testCompile) @ 
google-api-client ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 27 source files to 
/build/google-api-client-java-1.27.1/google-api-client/target/test-classes
[INFO] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:
 Some input files use or override a deprecated API.
[INFO] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:
 Recompile with -Xlint:deprecation for details.
[INFO] -
[ERROR] COMPILATION ERROR : 
[INFO] -
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[29,38]
 package com.google.api.client.protobuf does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[182,43]
 package ErrorOutput does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[192,38]
 package ErrorOutput does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[228,39]
 package MockData does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[235,35]
 package MockData does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[244,39]
 package MockData does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[251,35]
 package MockData does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/auth/oauth2/CloudShellCredentialTest.java:[36,39]
 package com.google.api.client.json.gson does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/auth/oauth2/GoogleClientSecretsTest.java:[18,39]
 package com.google.api.client.json.gson does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[196,20]
 package ErrorOutput does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[207,25]
 package ErrorOutput does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[333,50]
 package MockData does not exist
[ERROR] 
/build/google-api-client-java-1.27.1/google-api-client/src/test/java/com/google/api/client/googleapis/batch/BatchRequestTest.java:[339,50]
 package MockData does not exist
[ERROR] 

Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR

[Boyuan Yang]

Hi kokoye,

在 2020-06-17星期三的 21:42 +0630，Ko Ko Ye`写道：
> Dear Mentors 
> Now update 0.1-2
> https://mentors.debian.net/debian/pool/main/w/wifi-qr/wifi-qr_0.1-2.dsc
> 
> implement with Hidden Network.
> remove wifi-qr.policy
> remove sudo usermode
> change array to mapfile mode.
> and
> shellcheck with @pabs suggestion.
> https://github.com/kokoye2007/wifi-qr/issues/9

There are several issues:

* Since this is a new upload, please do not reuse your old RFS bug (
https://bugs.debian.org/961899). Please open another RFS bug with
correct version string (0.1-2) and we can discuss further there. Please
do not further reply to this bug report.

* You are actually making changes as an upstream to fix some issues. In
this case, please consider making another upstream release (for
example, 0.2). Putting your changes in debian/patches/ is not
reasonable at all. In this case you are the upstream, you have full
control of the original project and you should not bother with
patching.

* Please, delete the .pc directory (
https://github.com/kokoye2007/wifi-qr/tree/master/.pc) for good and
never let it appear in your git repo again. This directory should
*never* appear anytime anywhere and I have provided the reason to you
in previous emails.

* Finally, could you please write in full English sentences with
correct grammar in your email communication as well as the package
description (
https://github.com/kokoye2007/wifi-qr/blob/master/debian/control)
instead of using scattered words? That will definitely help with the
understanding.

Please fix the issues above and we can do further review in your new
RFS request thread.

-- 
Thanks,
Boyuan Yang


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

Bug#962553: gffread: autopkgtest needs update for new version of gff2aplot: warning on stderr

[Graham Inggs]

Control: reopen -1

Now it fails in a different way:

autopkgtest [11:10:15]: test run-tests:  - - - - - - - - - - results -
- - - - - - - - -
run-testsFAIL stderr:
/tmp/autopkgtest-lxc.cerfkec6/downtmp/build.2n1/src/debian/tests/run-tests:
line 109:  8512 Segmentation fault  gffread ${gff} > /dev/null
autopkgtest [11:10:15]: test run-tests:  - - - - - - - - - - stderr -
- - - - - - - - -
/tmp/autopkgtest-lxc.cerfkec6/downtmp/build.2n1/src/debian/tests/run-tests:
line 109:  8512 Segmentation fault  gffread ${gff} > /dev/null
/tmp/autopkgtest-lxc.cerfkec6/downtmp/build.2n1/src/debian/tests/run-tests:
line 109:  8514 Segmentation fault  gffread ${gff} > /dev/null

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[J. Bruce Fields]

On Wed, Jun 17, 2020 at 04:42:56PM +0200, Andreas Gruenbacher wrote:
> Hi Bruce,
> 
> On Wed, Jun 17, 2020 at 2:58 AM J. Bruce Fields  wrote:
> > I think I'll send the following upstream.
> 
> looking good, but how about using a little helper for this?

I like it.  And the new comment's helpful too.

> 
> Also I'm not sure if ecryptfs gets this right, so taking the ecryptfs
> list into the CC.

Yes, questions I had while doing this:

- cachefiles, ecrypfs, devtmpfs, and unix_mknod skip the check,
  is that OK for all of them?  (Overlayfs too, I think?--that
  code's harder to follow.

- why don't vfs_{create,mknod,mkdir} do the IS_POSIXACL check
  themselves?  Even if it's unnecessary for some callers, surely
  it wouldn't be wrong?

I also wondered why both vfs_{create,mknod,mkdir} and the callers were
calling security hooks, but now I see that the callers are calling
security_path_* hooks and the vfs_ functions are calling
security_inode_* hooks, so I guess they're not redundant.

Though now I wonder why some of the callers (nfsd, overlayfs) are
skipping the security_path_* hooks.

--b.

> 
> Thanks,
> Andreas
> 
> --
> 
> Add a posix_acl_apply_umask helper for filesystems like nfsd to apply
> the umask before calling into vfs_create, vfs_mkdir, and vfs_mknod when
> necessary.
> 
> Signed-off-by: Andreas Gruenbacher 
> ---
>  fs/namei.c|  9 +++--
>  fs/nfsd/vfs.c |  6 ++
>  fs/overlayfs/dir.c|  4 ++--
>  fs/posix_acl.c| 15 +++
>  include/linux/posix_acl.h |  6 ++
>  5 files changed, 28 insertions(+), 12 deletions(-)
> 
> diff --git a/fs/namei.c b/fs/namei.c
> index 72d4219c93ac..a68887d3a446 100644
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -3054,8 +3054,7 @@ static struct dentry *lookup_open(struct nameidata *nd, 
> struct file *file,
>   if (open_flag & O_CREAT) {
>   if (open_flag & O_EXCL)
>   open_flag &= ~O_TRUNC;
> - if (!IS_POSIXACL(dir->d_inode))
> - mode &= ~current_umask();
> + posix_acl_apply_umask(dir->d_inode, );
>   if (likely(got_write))
>   create_error = may_o_create(>path, dentry, mode);
>   else
> @@ -3580,8 +3579,7 @@ long do_mknodat(int dfd, const char __user *filename, 
> umode_t mode,
>   if (IS_ERR(dentry))
>   return PTR_ERR(dentry);
>  
> - if (!IS_POSIXACL(path.dentry->d_inode))
> - mode &= ~current_umask();
> + posix_acl_apply_umask(path.dentry->d_inode, );
>   error = security_path_mknod(, dentry, mode, dev);
>   if (error)
>   goto out;
> @@ -3657,8 +3655,7 @@ long do_mkdirat(int dfd, const char __user *pathname, 
> umode_t mode)
>   if (IS_ERR(dentry))
>   return PTR_ERR(dentry);
>  
> - if (!IS_POSIXACL(path.dentry->d_inode))
> - mode &= ~current_umask();
> + posix_acl_apply_umask(path.dentry->d_inode, );
>   error = security_path_mkdir(, dentry, mode);
>   if (!error)
>   error = vfs_mkdir(path.dentry->d_inode, dentry, mode);
> diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
> index d22a056da477..0c625b004b0c 100644
> --- a/fs/nfsd/vfs.c
> +++ b/fs/nfsd/vfs.c
> @@ -1226,8 +1226,7 @@ nfsd_create_locked(struct svc_rqst *rqstp, struct 
> svc_fh *fhp,
>   iap->ia_mode = 0;
>   iap->ia_mode = (iap->ia_mode & S_IALLUGO) | type;
>  
> - if (!IS_POSIXACL(dirp))
> - iap->ia_mode &= ~current_umask();
> + posix_acl_apply_umask(dirp, >ia_mode);
>  
>   err = 0;
>   host_err = 0;
> @@ -1461,8 +1460,7 @@ do_nfsd_create(struct svc_rqst *rqstp, struct svc_fh 
> *fhp,
>   goto out;
>   }
>  
> - if (!IS_POSIXACL(dirp))
> - iap->ia_mode &= ~current_umask();
> + posix_acl_apply_umask(dirp, >ia_mode);
>  
>   host_err = vfs_create(dirp, dchild, iap->ia_mode, true);
>   if (host_err < 0) {
> diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
> index 1bba4813f9cb..4d98db2a0208 100644
> --- a/fs/overlayfs/dir.c
> +++ b/fs/overlayfs/dir.c
> @@ -325,8 +325,8 @@ static int ovl_create_upper(struct dentry *dentry, struct 
> inode *inode,
>   struct dentry *newdentry;
>   int err;
>  
> - if (!attr->hardlink && !IS_POSIXACL(udir))
> - attr->mode &= ~current_umask();
> + if (!attr->hardlink)
> +posix_acl_apply_umask(udir, >mode);
>  
>   inode_lock_nested(udir, I_MUTEX_PARENT);
>   newdentry = ovl_create_real(udir,
> diff --git a/fs/posix_acl.c b/fs/posix_acl.c
> index 95882b3f5f62..7ee647b74bc2 100644
> --- a/fs/posix_acl.c
> +++ b/fs/posix_acl.c
> @@ -578,6 +578,21 @@ posix_acl_chmod(struct inode *inode, umode_t mode)
>  }
>  EXPORT_SYMBOL(posix_acl_chmod);
>  
> +/*
> + * On inode creation, filesystems with ACL support are expected to apply the
> + * umask when no ACL is inherited from the parent directory; this is 

Bug#963010: [Pkg-roundcube-maintainers] Bug#963010: Acknowledgement (roundcube-core: roundcube upgrade keeps breaking my instance due to automatic permission changes of config.inc.php)

[Guilhem Moulin]

On Wed, 17 Jun 2020 at 17:09:01 +0200, Mirko Vogt wrote:
> However above report was closed in Feb 2020 with a comment that bug was
> believed to be fixed. If that's the case, the fix apparently didn't make
> it back to stable/buster, though.

Right, as written on the list:

| I believe is a duplicate of https://bugs.debian.org/951194 (RC) and
| fixed 1.4.3+dfsg.1-1.  I'm not sure the fix is suitable for buster-pu
| though.

(FWIW my “please use the Debian BTS” wasn't an invitation to file a bug
in this case, but to query the BTS to check if the issue was already
reported and/or fixed.)

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#963010: Acknowledgement (roundcube-core: roundcube upgrade keeps breaking my instance due to automatic permission changes of config.inc.php)

[Mirko Vogt]

I was made aware that this might be a duplicate of

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951194

and it indeed seems to be the same issue.

However above report was closed in Feb 2020 with a comment that bug was
believed to be fixed. If that's the case, the fix apparently didn't make
it back to stable/buster, though.

Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR

[Ko Ko Ye`]

Dear Mentors
Now update 0.1-2
https://mentors.debian.net/debian/pool/main/w/wifi-qr/wifi-qr_0.1-2.dsc

implement with Hidden Network.
remove wifi-qr.policy
remove sudo usermode
change array to mapfile mode.
and
shellcheck with @pabs suggestion.
https://github.com/kokoye2007/wifi-qr/issues/9

who can sponsor and mentoring again.

with regards.

On Tue, Jun 9, 2020 at 11:01 PM Ko Ko Ye`  wrote:

> Dear Debian Mentors
>
> when I see and like the Android WiFi QR Code System.
> I am bash with using data from /etc/NetworkManager/system-connections/
>
> Single Bash Script. with qrencode [1]
> terminal mode is ok.
>
> migrate for GUI mode
> i am using Zenity [2] and Scan for zbar-cam [3]
>
> .desktop is not work with sudo mode
> so using Policy Kit polkit [4]
>
> now
> i am migrating with nmcli [5]
> its no need sudo mode.
>
> so i think remove pokit and policy file [6]
> and change desktop file again [7]
>
> any suggestions?
>
> I am uploading again. it needs a sponsor to reupload or something else.
>
>
>
> We still need enterprise / LDAP network connection.
> API is learned from ZXing QR [8].
> just support OPEN / WEP / WPA / HIDDEN mode only.
>
>
> with regards.
>
> [1] https://packages.debian.org/source/sid/qrencode
> [2] https://packages.debian.org/source/sid/zenity
> [3] https://packages.debian.org/source/jessie/zbar
> [4] https://packages.debian.org/source/sid/policykit-1
> [5] https://packages.debian.org/source/sid/network-manager
> [6]
> https://github.com/kokoye2007/wifi-qr/blob/6c775472dec72b149f0aa161d71c90458940e31f/wifi-qr.policy
> [7]
> https://github.com/kokoye2007/wifi-qr/commit/8525b05d2d4f2cda97d0d7661f4e5d09deaa0bd8#diff-67251b201b3016eedbe1aad563377abc
> [8] https://zxing.appspot.com/
>
>
>
>
>
>
>
>
> On Fri, Jun 5, 2020 at 9:20 PM Ko Ko Ye`  wrote:
>
>> thanks Boyuan
>>
>> noted.
>>
>> I am changing Architecture:all and uploaded.
>>
>> with regards.
>>
>>
>> On Fri, Jun 5, 2020 at 8:25 PM Boyuan Yang  wrote:
>>
>>> On Fri, 5 Jun 2020 09:35:07 +0630 "Ko Ko Ye`" 
>>> wrote:
>>> > -- Forwarded message -
>>> > From: Ko Ko Ye` 
>>> > Date: Fri, Jun 5, 2020 at 9:32 AM
>>> > Subject: Re: Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect
>>>
>>>
>>>
>>> Have you seen that bartm bot closed your RFS report again?
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961899;msg=19
>>>
>>> It is due to that you removed your package from mentors.debian.net (
>>> https://mentors.debian.net/package/wifi-qr) and re-add it. When it gets
>>> removed, the bot will detect it and close the bug report automatically.
>>> You are expected to reopen the wrongly-closed bug report.
>>>
>>> Please *DO* *NOT* unnecessarily remove and readd your package on
>>> mentors.debian.net. You can always make a re-upload onto
>>> mentors.debian.net with the same package name and same version name.
>>> The mentors.debian.net site supports such behavior.
>>> (This does not apply to Debian's official archive, though.)
>>>
>>> --
>>> Regards,
>>> Boyuan Yang
>>>
>>
>>
>> --
>>
>> with regards *Ko Ko Ye`*
>>
>> +95 97989 22022
>> +95 94500 22022
>> +95 9731 47907
>> kokoye2...@gmail.com
>> kokoye2...@ubuntu.com
>>
>> skype: kokoye2007
>> jitsi: kokoye2007
>>
>> http://ubuntu-mm.net
>> http://wiki.ubuntu.com/kokoye2007
>> http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
>>
>
>
> --
>
> with regards *Ko Ko Ye`*
>
> +95 97989 22022
> +95 94500 22022
> +95 9731 47907
> kokoye2...@gmail.com
> kokoye2...@ubuntu.com
>
> skype: kokoye2007
> jitsi: kokoye2007
>
> http://ubuntu-mm.net
> http://wiki.ubuntu.com/kokoye2007
> http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
>


-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect with QR

[Ko Ko Ye`]

now i am update with


On Tue, Jun 9, 2020 at 11:01 PM Ko Ko Ye`  wrote:

> Dear Debian Mentors
>
> when I see and like the Android WiFi QR Code System.
> I am bash with using data from /etc/NetworkManager/system-connections/
>
> Single Bash Script. with qrencode [1]
> terminal mode is ok.
>
> migrate for GUI mode
> i am using Zenity [2] and Scan for zbar-cam [3]
>
> .desktop is not work with sudo mode
> so using Policy Kit polkit [4]
>
> now
> i am migrating with nmcli [5]
> its no need sudo mode.
>
> so i think remove pokit and policy file [6]
> and change desktop file again [7]
>
> any suggestions?
>
> I am uploading again. it needs a sponsor to reupload or something else.
>
>
>
> We still need enterprise / LDAP network connection.
> API is learned from ZXing QR [8].
> just support OPEN / WEP / WPA / HIDDEN mode only.
>
>
> with regards.
>
> [1] https://packages.debian.org/source/sid/qrencode
> [2] https://packages.debian.org/source/sid/zenity
> [3] https://packages.debian.org/source/jessie/zbar
> [4] https://packages.debian.org/source/sid/policykit-1
> [5] https://packages.debian.org/source/sid/network-manager
> [6]
> https://github.com/kokoye2007/wifi-qr/blob/6c775472dec72b149f0aa161d71c90458940e31f/wifi-qr.policy
> [7]
> https://github.com/kokoye2007/wifi-qr/commit/8525b05d2d4f2cda97d0d7661f4e5d09deaa0bd8#diff-67251b201b3016eedbe1aad563377abc
> [8] https://zxing.appspot.com/
>
>
>
>
>
>
>
>
> On Fri, Jun 5, 2020 at 9:20 PM Ko Ko Ye`  wrote:
>
>> thanks Boyuan
>>
>> noted.
>>
>> I am changing Architecture:all and uploaded.
>>
>> with regards.
>>
>>
>> On Fri, Jun 5, 2020 at 8:25 PM Boyuan Yang  wrote:
>>
>>> On Fri, 5 Jun 2020 09:35:07 +0630 "Ko Ko Ye`" 
>>> wrote:
>>> > -- Forwarded message -
>>> > From: Ko Ko Ye` 
>>> > Date: Fri, Jun 5, 2020 at 9:32 AM
>>> > Subject: Re: Bug#961899: RFS: wifi-qr/0.1-1 -- WiFi Share and Connect
>>>
>>>
>>>
>>> Have you seen that bartm bot closed your RFS report again?
>>>
>>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961899;msg=19
>>>
>>> It is due to that you removed your package from mentors.debian.net (
>>> https://mentors.debian.net/package/wifi-qr) and re-add it. When it gets
>>> removed, the bot will detect it and close the bug report automatically.
>>> You are expected to reopen the wrongly-closed bug report.
>>>
>>> Please *DO* *NOT* unnecessarily remove and readd your package on
>>> mentors.debian.net. You can always make a re-upload onto
>>> mentors.debian.net with the same package name and same version name.
>>> The mentors.debian.net site supports such behavior.
>>> (This does not apply to Debian's official archive, though.)
>>>
>>> --
>>> Regards,
>>> Boyuan Yang
>>>
>>
>>
>> --
>>
>> with regards *Ko Ko Ye`*
>>
>> +95 97989 22022
>> +95 94500 22022
>> +95 9731 47907
>> kokoye2...@gmail.com
>> kokoye2...@ubuntu.com
>>
>> skype: kokoye2007
>> jitsi: kokoye2007
>>
>> http://ubuntu-mm.net
>> http://wiki.ubuntu.com/kokoye2007
>> http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
>>
>
>
> --
>
> with regards *Ko Ko Ye`*
>
> +95 97989 22022
> +95 94500 22022
> +95 9731 47907
> kokoye2...@gmail.com
> kokoye2...@ubuntu.com
>
> skype: kokoye2007
> jitsi: kokoye2007
>
> http://ubuntu-mm.net
> http://wiki.ubuntu.com/kokoye2007
> http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm
>


-- 

with regards *Ko Ko Ye`*

+95 97989 22022
+95 94500 22022
+95 9731 47907
kokoye2...@gmail.com
kokoye2...@ubuntu.com

skype: kokoye2007
jitsi: kokoye2007

http://ubuntu-mm.net
http://wiki.ubuntu.com/kokoye2007
http://wiki.ubuntu.com/MyanmarTeam http://loco.ubuntu.com/teams/ubuntu-mm

Bug#963010: roundcube-core: roundcube upgrade keeps breaking my instance due to automatic permission changes of config.inc.php

[Mirko Vogt]

Package: roundcube-core
Version: 1.3.13+dfsg.1-1~deb10u1
Severity: important

Hello,

I'm on Debian stable (buster) and using roundcube together with php-fpm
(and Debian's unattended-upgrade functionality for the security feed).

Already the second time an (unattended )upgrade broke my roundcube setup
resulting in the webinterface saying:

config.inc.php was not found.

What's happening is, that the upgrade - while maybe not entirely
overriding (its custom values and credentials are still in place) - is
definitely touching the config file located under
/etc/roundcube/config.inc.php -- at least changing its permissions.

So, while my config.inc.php is supposed to have the following
permissions in order for everything to work:

-rw-r-  1 root php-roundcube [..] config.inc.php

it looks like this after the upgrade:

-rw-r-  1 root www-data [..] config.inc.php

which makes this file unreadable for the php-fpm process run under the
user "php-roundcube".

I kindly ask not to automatically change the config files' permissions
during upgrades.

If you think my use case is an edge case or I'm better off with a
different solution to my issue I'm all ears.

For the moment, though, I would assume using php-fpm (running under a
different user than 'www-data') is quite common, as well as I think it's
sane to expect custom configuration files' permissions not being changed
during updates by default.

Thanks a lot!

  mirko

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl (was: Re: Bug#962254: NFS(v4) broken at 4.19.118-2)

[Andreas Gruenbacher]

Hi Bruce,

On Wed, Jun 17, 2020 at 2:58 AM J. Bruce Fields  wrote:
> I think I'll send the following upstream.

looking good, but how about using a little helper for this?

Also I'm not sure if ecryptfs gets this right, so taking the ecryptfs
list into the CC.

Thanks,
Andreas

--

Add a posix_acl_apply_umask helper for filesystems like nfsd to apply
the umask before calling into vfs_create, vfs_mkdir, and vfs_mknod when
necessary.

Signed-off-by: Andreas Gruenbacher 
---
 fs/namei.c|  9 +++--
 fs/nfsd/vfs.c |  6 ++
 fs/overlayfs/dir.c|  4 ++--
 fs/posix_acl.c| 15 +++
 include/linux/posix_acl.h |  6 ++
 5 files changed, 28 insertions(+), 12 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 72d4219c93ac..a68887d3a446 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -3054,8 +3054,7 @@ static struct dentry *lookup_open(struct nameidata *nd, 
struct file *file,
if (open_flag & O_CREAT) {
if (open_flag & O_EXCL)
open_flag &= ~O_TRUNC;
-   if (!IS_POSIXACL(dir->d_inode))
-   mode &= ~current_umask();
+   posix_acl_apply_umask(dir->d_inode, );
if (likely(got_write))
create_error = may_o_create(>path, dentry, mode);
else
@@ -3580,8 +3579,7 @@ long do_mknodat(int dfd, const char __user *filename, 
umode_t mode,
if (IS_ERR(dentry))
return PTR_ERR(dentry);
 
-   if (!IS_POSIXACL(path.dentry->d_inode))
-   mode &= ~current_umask();
+   posix_acl_apply_umask(path.dentry->d_inode, );
error = security_path_mknod(, dentry, mode, dev);
if (error)
goto out;
@@ -3657,8 +3655,7 @@ long do_mkdirat(int dfd, const char __user *pathname, 
umode_t mode)
if (IS_ERR(dentry))
return PTR_ERR(dentry);
 
-   if (!IS_POSIXACL(path.dentry->d_inode))
-   mode &= ~current_umask();
+   posix_acl_apply_umask(path.dentry->d_inode, );
error = security_path_mkdir(, dentry, mode);
if (!error)
error = vfs_mkdir(path.dentry->d_inode, dentry, mode);
diff --git a/fs/nfsd/vfs.c b/fs/nfsd/vfs.c
index d22a056da477..0c625b004b0c 100644
--- a/fs/nfsd/vfs.c
+++ b/fs/nfsd/vfs.c
@@ -1226,8 +1226,7 @@ nfsd_create_locked(struct svc_rqst *rqstp, struct svc_fh 
*fhp,
iap->ia_mode = 0;
iap->ia_mode = (iap->ia_mode & S_IALLUGO) | type;
 
-   if (!IS_POSIXACL(dirp))
-   iap->ia_mode &= ~current_umask();
+   posix_acl_apply_umask(dirp, >ia_mode);
 
err = 0;
host_err = 0;
@@ -1461,8 +1460,7 @@ do_nfsd_create(struct svc_rqst *rqstp, struct svc_fh *fhp,
goto out;
}
 
-   if (!IS_POSIXACL(dirp))
-   iap->ia_mode &= ~current_umask();
+   posix_acl_apply_umask(dirp, >ia_mode);
 
host_err = vfs_create(dirp, dchild, iap->ia_mode, true);
if (host_err < 0) {
diff --git a/fs/overlayfs/dir.c b/fs/overlayfs/dir.c
index 1bba4813f9cb..4d98db2a0208 100644
--- a/fs/overlayfs/dir.c
+++ b/fs/overlayfs/dir.c
@@ -325,8 +325,8 @@ static int ovl_create_upper(struct dentry *dentry, struct 
inode *inode,
struct dentry *newdentry;
int err;
 
-   if (!attr->hardlink && !IS_POSIXACL(udir))
-   attr->mode &= ~current_umask();
+   if (!attr->hardlink)
+  posix_acl_apply_umask(udir, >mode);
 
inode_lock_nested(udir, I_MUTEX_PARENT);
newdentry = ovl_create_real(udir,
diff --git a/fs/posix_acl.c b/fs/posix_acl.c
index 95882b3f5f62..7ee647b74bc2 100644
--- a/fs/posix_acl.c
+++ b/fs/posix_acl.c
@@ -578,6 +578,21 @@ posix_acl_chmod(struct inode *inode, umode_t mode)
 }
 EXPORT_SYMBOL(posix_acl_chmod);
 
+/*
+ * On inode creation, filesystems with ACL support are expected to apply the
+ * umask when no ACL is inherited from the parent directory; this is usually
+ * done by posix_acl_create.  Filesystems like nfsd that call vfs_create,
+ * vfs_mknod, or vfs_mkdir directly are expected to call posix_acl_apply_umask
+ * to apply the umask first when necessary.
+ */
+void
+posix_acl_apply_umask(struct inode *inode, umode_t *mode)
+{
+   if (!IS_POSIXACL(inode))
+   *mode &= ~current_umask();
+}
+EXPORT_SYMBOL(posix_acl_apply_umask);
+
 int
 posix_acl_create(struct inode *dir, umode_t *mode,
struct posix_acl **default_acl, struct posix_acl **acl)
diff --git a/include/linux/posix_acl.h b/include/linux/posix_acl.h
index 90797f1b421d..76e402ff4f92 100644
--- a/include/linux/posix_acl.h
+++ b/include/linux/posix_acl.h
@@ -73,6 +73,7 @@ extern int set_posix_acl(struct inode *, int, struct 
posix_acl *);
 
 #ifdef CONFIG_FS_POSIX_ACL
 extern int posix_acl_chmod(struct inode *, umode_t);
+extern void posix_acl_apply_umask(struct inode *, umode_t *);
 extern int posix_acl_create(struct inode *, umode_t *, struct posix_acl **,
  

Bug#942765: tftp-hpa: Vcs-Git needs updating

[Salvatore Bonaccorso]

Control: tags -1 + pending

Hi,

On Mon, Oct 21, 2019 at 10:59:56AM +0200, Uwe Kleine-König wrote:
> Package: tftp-hpa
> Version: 5.2+20150808-1+b1
> Severity: normal
> 
> Hello,
> 
> The Vcs-Git header of the tftp-hpa source package points to
> git://git.debian.org/users/ron/tftp-hpa.git which doesn't work any more.
> 
> It seems packaging now lives on https://salsa.debian.org/ron/tftp-hpa.
> An upload of tftp-hpa with the Vcs-Git (and Vcs-Browser) header updated
> or a forward using https://salsa.debian.org/salsa/AliothRewriter (or
> both) would be great.

Looks this was commited as
https://salsa.debian.org/ron/tftp-hpa/-/commit/78d37e76dd74a47ca854ee1494d42f11d2677589
in the packaging repository but no new upload since then.

Regards,
Salvatore

Bug#963008: apt: [INTL:nl] Dutch po file for the apt package

[Frans Spiesschaert]

 
 
Package: apt 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch po file for the apt package. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as "po/nl.po" in your package build tree. 
 

-- 
Met vriendelijke groet,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#963009: ircd-hybrid: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: ircd-hybrid 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of ircd-hybrid debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#963007: tzdata: [INTL:nl] Dutch translation of debconf messages

[Frans Spiesschaert]

 
 
Package: tzdata 
Severity: wishlist 
Tags: l10n patch 
 
 
 
Dear Maintainer, 
 
 
Please find attached the updated Dutch translation of tzdata debconf
messages. 
It has been submitted for review to the debian-l10n-dutch mailing list. 
Please add it to your next package revision. 
It should be put as debian/po/nl.po in your package build tree. 
 

-- 
Kind regards,
Frans Spiesschaert



nl.po.gz
Description: application/gzip

Bug#963006: RFS: xplc/0.3.13-9 [QA] -- Light weight component system

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: xplc
   Version : 0.3.13-9
   Upstream Author : Pierre Phaneuf 
 * URL : http://xplc.sourceforge.net/
 * License : LGPL-2.1
 * Vcs : https://salsa.debian.org/debian/xplc
   Section : libs

It builds those binary packages:

  libxplc0.3.13 - Light weight component system
  libxplc0.3.13-dev - Light weight component system (Development libraries and 
headers)
  uuidcdef - Universally Unique Identifier (UUID) generator

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/x/xplc/xplc_0.3.13-9.dsc

Changes since the last upload:

   * QA upload.
   * Fix ftbfs with gcc-10. (Closes: #957992)


-- 
Regards
Sudip

Bug#962402: haskell-text-icu built

[Gianfranco Costamagna]

control: severity -1 important

On Sat, 13 Jun 2020 18:59:12 +0300 Adrian Bunk  wrote:
> On Fri, Jun 12, 2020 at 09:49:21PM +0200, Frédéric Bonnard wrote:
> > Hi,
> > I wanted to check that FTBFS but it actually built, on different setup.
> > After a give back on ppc64el and s390x, everything went fine. Very few
> > changes between the failing and succeeding build. Same ghc, kernel.
> > For the record, linux-libc-dev, libgmpxx4ldbl, libgmp-dev, libkrb5support0,
> > libk5crypto3, libkrb5-3, libgssapi-krb5-2, libnghttp2-14, hscolour were
> > not the same.
> 
> Both the buildd failures and the build failures in the reproducible CI 
> look as if the failure is random, perhaps with a different probability
> depending on some unknown factor.

Hello, I propose to downgrade to important, and raise back if we still 
experience the issue...

Gianfranco

Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.

[Adrian Bunk]

On Wed, Jun 17, 2020 at 12:20:46PM +0200, Piotr Kolasiński wrote:
> On Tue, Jun 16, 2020 at 11:24:11AM +0300, Adrian Bunk wrote:
>...
> > s390x is the only headless release architecture.
> > This was a real pain for the Debian GNOME maintainers already before
> > the last release, without any support from s390x porters on fixing
> > this issue.[1]
> I don't agree. Fact, that s390x doesn't have direct display doesn't mean
> that graphical tools are not used.
>...

Fact is that the s390x port is different from all other ports in Debian.
And it is causing extra work to support such a port.
Which is an even bigger problem when there are no porters doing this work.

>...
> About "s390x hardware and the Linux kernel" - I'm just only advanced user
> (I hope), but as I know - the kernel support in this area is mostly done
> by IBM. Does someone can tell me how many changes have to be done in Debian
> and what kind for the kernel? Does we really need many people in this
> area?
>...

Two porters are the minimum requirement for release architectures.

Just yesterday there was a question from a Debian maintainer sent to the
s390 list about an s390x-only problem in a package[1]:

  Any of you have any idea why the threads on s390x behave differently
  than all the other architectures?

I do not know whether there is anything special about threading on s390x 
compared to other Linux architectures, but porters are expected to know.

If there is a problem like for example kernel crashes with the Debian 
kernel on a Debian machine like a buildd for a release architecture, 
someone has to debug the problem swiftly.

Debian does not have a service agreement with IBM for maintaining the 
Debian kernel on s390x, it is the duty of the s390x porters to maintain
the Debian kernel and debug problems in the Debian kernel.

>...
> > A port like s390x with unique problems is only sustainable when several 
> > people with good knowledge of Debian, s390x hardware and the Linux 
> > kernel have a long-term commitment of swiftly supporting everyone in 
> > Debian with s390x problems.
> Good point - the question is why there is not so many people with "good
> knowledge of Debian" in Mainframe environment?
>...

Debian is a volunteer project.
s390x is a business-to-business affair.

Other ports have a community of people who have a Raspberry Pi or 
an old hppa workstation at home.

Nonne has an old mainframe at home for keeping Debian running on it
as a hobby.

>...
> How many of potential
> mainframe users know that Debian supports s390x architecture? If not
> many - why?
>...

How many companies are buying a mainframe without any software support
contracts with IBM or other companies?

With that kind of financial investment you usually want a Linux 
distribution that is supported by IBM, and buy support for that
distribution from the company behind the distribution.

>...
> > IMHO it would be best if s390x would become a non-release architecture 
> > in ports.
> My previous message was sent because I worry, that if this architecture
> will become not-release, after short time disappear

A Debian port disappears when there are not enough porters with the 
necessary skills keeping it working.

For non-release architectures one dedicated person is enough.

> (and some people abandon it or switch to Ubuntu
>...

What people are you talking about?

Philipp made a good point that the Debian s390x port might already have
no users at all left.

> Piotr

cu
Adrian

[1] https://lists.debian.org/debian-s390/2020/06/msg00015.html

Bug#962847: exim4: takes forever to send a mail after sleeping

[Rémi Letot]

Marc Haber writes:

> On Mon, Jun 15, 2020 at 01:56:18PM +0200, Rémi Letot wrote:
>> My mail client and exim are both running on my laptop, and the provided
>> logs are from that same laptop.
>> 
>> The fault is the delay between exim accepting the message, and actually
>> delivering it to the smarthost. During that delay, my mail client is
>> stuck too.
>
> That is highly implausible. In a normal setup, the SMTP client is out of
> the game as soon exim has locally queued the message. Can you run
> tcpdump on lo to find out what's happening? I guess that you're putting
> the laptop to sleep before the (local) TCP session has been properly
> closed, making it subject to the exponential backoff algorithm and
> eventually a session timeout. There is not much exim can do in this
> situation.

nope, I'm not a developper but I know computers and networks, I don't
put it to sleep while it is delivering anything.

Besides, I had reverted to exim 4.93-16 since my last message, and have
not had any problem for several days. Now I upgraded again to 4.94-2 to
get a capture, and tadaaa, the delay is back. So it's definitely linked
to exim4.94, not to my usage pattern. (Now I agree with you, I can't
begin to understand how that delay can be directly linked to the sleep
time of the laptop, that's... interresting :-)

Events:

- wake my laptop
- test with 4.93-16, immediately delivered
- upgrade to 4.94-2
- send a test mail, immediately delivered
- pause to be sure that everything is done networkwise
- put the laptop to sleep
- wait about 20 seconds
- wake the laptop
- pause to be sure that everyting is done networkwise
- send a test mail, 20 secondish delay is there
- sudo tcpdump -i lo -w exim4.pcap
- send a second test mail
- the delay is there between 15:16:47.250804 and 15:17:04.667741

See attached capture. 


> Maybe it helps to force exim to actually queue messsages from lo instead
> of trying immediate delivery?

I just applied the default debian smarthost configuration, how do I
change that so that it queues the messages ? I think that this would
just hide the bug and delay, probably just give me my mail client back
but still delaying the actual deliveries. But I can try it for testing
purpose if you give me complete instructions.

Thanks,
-- 
Rémi



exim4.pcap
Description: application/vnd.tcpdump.pcap

Bug#963004: okular: crashes while opening file in kde/plasma when using two screens positioned at an offset

[Boris Hupkens van der Elst]

Package: okular
Version: 4:20.04.2-1
Severity: important

Dear Maintainer,

On a fresh install of debian testing with KDE okular crashes when it is started
with a filename argument. So in both the default scenario when I try to open a
file in dolphin, or via command line. However, when okular is opened
without document and I open a file via file->open it works as expected.

As it is very unexpected that a package fails so spectacularly on a
fresh install I tried to deduce what makes my environment non-standard: 
After trying which settings in the KDE system settings are relevant I
found it only happens when I have my two screens positioned 'wrong'. If
that is the case, okular crashes always on any document. If they are
positioned 'right' it always works as expected.

I have two screens, primary 1920x1080, secondary 2560x1440. The second
screen is to the right of the primary screen. If the second screen is 
positioned significantly higher it is 'wrong' and the application
crashes on startup. If it is just a little bit higher (bottom of second
screen a little above bottom of primary streen) it works ok, and it also
works if the bottoms are equal, the tops are equal or it is
significantly below the primary screen.

Expected results: Okular should be able to open a file no matter the
screen configuration.

With kind regards,

Boris

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

Kernel: Linux 5.6.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=nl_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_US:en (charmap=locale: Cannot set LC_MESSAGES to default 
locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages okular depends on:
ii  kinit 5.70.0-1
ii  kio   5.70.1-1
ii  libc6 2.30-8
ii  libfreetype6  2.10.1-2
ii  libjpeg62-turbo   1:1.5.2-2+b1
ii  libkf5activities5 5.70.0-1
ii  libkf5archive55.70.0-1
ii  libkf5bookmarks5  5.70.0-1
ii  libkf5codecs5 5.70.0-1
ii  libkf5completion5 5.70.0-1
ii  libkf5configcore5 5.70.0-1
ii  libkf5configgui5  5.70.0-1
ii  libkf5configwidgets5  5.70.0-1
ii  libkf5coreaddons5 5.70.0-1
ii  libkf5crash5  5.70.0-1
ii  libkf5i18n5   5.70.0-1
ii  libkf5iconthemes5 5.70.0-1
ii  libkf5itemviews5  5.70.0-1
ii  libkf5jobwidgets5 5.70.0-1
ii  libkf5kexiv2-15.0.0   19.08.1-1+b2
ii  libkf5kiocore55.70.1-1
ii  libkf5kiowidgets5 5.70.1-1
ii  libkf5parts5  5.70.0-1
ii  libkf5pty55.70.0-1
ii  libkf5purpose-bin 5.70.0-1
ii  libkf5purpose55.70.0-1
ii  libkf5service-bin 5.70.0-1
ii  libkf5service55.70.0-1
ii  libkf5textwidgets55.70.0-1
ii  libkf5wallet-bin  5.70.0-1
ii  libkf5wallet5 5.70.0-1
ii  libkf5widgetsaddons5  5.70.0-1
ii  libkf5windowsystem5   5.70.0-1
ii  libkf5xmlgui5 5.70.0-1
ii  libokular5core9   4:20.04.2-1
ii  libphonon4qt5-4   4:4.11.1-3
ii  libpoppler-qt5-1  0.71.0-6
ii  libqca-qt5-2  2.2.1-2
ii  libqmobipocket2   4:17.08.3-2+b1
ii  libqt5core5a  5.12.5+dfsg-10+b1
ii  libqt5dbus5   5.12.5+dfsg-10+b1
ii  libqt5gui55.12.5+dfsg-10+b1
ii  libqt5printsupport5   5.12.5+dfsg-10+b1
ii  libqt5svg55.12.5-2
ii  libqt5texttospeech5   5.12.5-1
ii  libqt5widgets55.12.5+dfsg-10+b1
ii  libqt5xml55.12.5+dfsg-10+b1
ii  libspectre1   0.2.8-2
ii  libstdc++610.1.0-3
ii  phonon4qt54:4.11.1-3
ii  zlib1g1:1.2.11.dfsg-2

Versions of packages okular recommends:
ii  cups-bsd  2.3.3-1

Versions of packages okular suggests:
ii  ghostscript9.52~dfsg-1
pn  okular-extra-backends  
ii  poppler-data   0.4.9-2
pn  texlive-binaries   
pn  unrar  

-- debconf information:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_US:en",
LC_ALL = (unset),
LC_CTYPE = "C.UTF-8",
LANG = "nl_NL.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Bug#963005: New upstream release

[Martin Michlmayr]

Package: tig
Severity: wishlist

2.5.1 is available.

-- 
Martin Michlmayr
https://www.cyrius.com/

Bug#962996: freeradius-redis redisReplyReaderGetError

[Vladimir Briatka]

Package: freeradius-redis
Version: 3.0.17+dfsg-1.1

after enabling redis module

root@test# cd /etc/freeradius/3.0/mods-enabled
root@test# ln -s ../mods-available/redis* .
root@test# freeradius -X|tail -10
  # Loading module "unpack" from file 
/etc/freeradius/3.0/mods-enabled/unpack

  # Loaded module rlm_utf8
  # Loading module "utf8" from file /etc/freeradius/3.0/mods-enabled/utf8
  # Loaded module rlm_date
  # Loading module "date" from file /etc/freeradius/3.0/mods-enabled/date
  date {
    format = "%b %e %Y %H:%M:%S %Z"
    utc = no
  }
/etc/freeradius/3.0/mods-enabled/redis[10]: Failed to link to module 
'rlm_redis': /usr/lib/freeradius/rlm_redis.so: undefined symbol: 
redisReplyReaderGetError


Best Regards
Vladimir Briatka


--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Bug#962998: build fixed with help from Nilesh

[Pirate Praveen]

But when running it fails to display any room and console has the 
errors messages


Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use 
QT_QPA_PLATFORM=wayland to run on Wayland anyway.

ssl3 ext invalid servername
ssl3 ext invalid servername
[2020-06-17 18:57:53.321] [qml] [warning] 
qrc:/qml/TimelineView.qml:28:5: Type EmojiPicker unavailable 
(qrc:/qml/TimelineView.qml:28, )
[2020-06-17 18:57:53.321] [qml] [warning] 
qrc:/qml/emoji/EmojiPicker.qml:2:1: module "QtQuick.Controls" version 
2.9 is not installed (qrc:/qml/emoji/EmojiPicker.qml:2, )

[2020-06-17 18:57:53.458] [db] [info] restoring state from cache
[2020-06-17 18:57:53.481] [db] [info] sessions restored
[2020-06-17 18:57:53.482] [db] [info] loading 538 rooms
[2020-06-17 18:57:53.533] [ui] [info] jdenticon plugin not found.
[2020-06-17 18:57:53.574] [ui] [info] starting nheko 0.7.2
error:Invalid event type: [json.exception.out_of_range.403] key 
'redacted_by' not found {

Bug#962596: (no subject)

[Michael Catanzaro]

Hi,

I asked Fedora's ca-certificates maintainer to comment on this. I 
didn't fully understand his reply, but he says this was some sort of 
mistake in Debian's package and not an upstream problem: 
https://bugzilla.redhat.com/show_bug.cgi?id=1845988#c3


"""
So mozilla lists relevent changes between NSS processing and the raw 
cert trust database here: 
https://wiki.mozilla.org/CA/Additional_Trust_Changes . NSS was indeed 
whitelisting accepted intermediates, but it also didn't explicitly 
removed the target CA's from the trust list. It now uses 
CKA_NSS_SERVER_DISTRUST_AFTER to handle how it distrusts the given CA's.


I've verified that the cert has not been removed from the current trust 
list, but CKA_NSS_SERVER_DISTRUST_AFTER has been set in the latest 
version. This means if the certs issued from this CA was issued after 
the specified date, then the trust would be distrusted, otherwise it 
will continue to be trusted.


I suspect Debian took out the certs from the trust store altogether, 
rather than process the list straight from mozilla.


Upshot: if you process CKA_NSS_SERVER_DISTRUST_AFTER, then you will get 
safer behavior, otherwise the ca's are still trusted in the latest list.

"""

I suspect you have more broken certificates that need to be restored 
than just GeoTrust.


Furthermore, last time we had a major Debian-specific certificate 
verification issue, we discovered that Debian is not actually capable 
of restoring previously-removed certificates without manual user 
intervention, see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743339. That means 
that even once these certificates are restored, users who have already 
updated to the affected version of ca-certificates will suffer 
permanently broken certificate verification unless they have found this 
bug report and know to take manual intervention, because the 
certificates will remain disabled locally.


Michael

Bug#933357: opendmarc (version 1.3.2-6) buster

[David Bürgin]

Control: tags -1 moreinfo

In the meantime the /var/run paths have been updated to /run. It’s not
clear to me if there is anything else left to do here, so tagging as
‘moreinfo’.

Bug#962973: haskell-readline: Removal notice: broken and unmaintained

[Clint Adams]

On Tue, Jun 16, 2020 at 09:10:32PM -0700, Sean Whitton wrote:
> keysafe, in experimental, depends on haskell-readline.
> 
> CCing upstream: Joey, do you think it would be possible for keysafe to
> migrate to use something maintained?

Some options suggested at

https://github.com/haskell-infra/hackage-trustees/issues/268#issuecomment-645354720

Bug#962254: Umask ignored when mounting NFSv4.2 share of an exported Filesystem with noacl

[J. Bruce Fields]

On Wed, Jun 17, 2020 at 06:58:29AM +0200, Salvatore Bonaccorso wrote:
> On Tue, Jun 16, 2020 at 08:58:49PM -0400, J. Bruce Fields wrote:
> Thank you, could test this on my test setup and seem to work properly.

Great, thanks.

> Should it also be CC'ed to sta...@vger.kernel.org so it is picked up
> by the current supported stable series?

Will do.--b.

Bug#962934: inkscape package contains a Debug build

[Mattia Rizzolo]

Control: found -1 1.0-1
Control: severity -1 normal

On Tue, Jun 16, 2020 at 08:01:20AM +0200, Benjamin Sygnat wrote:
> According to the Debian build logs for inkscape 1.0-1 (amd64), inkscape is
> built with the cmake option CMAKE_BUILD_TYPE=None. Effectively, this turns the
> build into a Debug build with asserts being in place, etc.

Right, but what problem is this causing to you?
I'm aware of only this related bug:
https://gitlab.com/inkscape/inkscape/-/issues/1472

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature

Bug#963003: Mark more symbols as optional, not seen when built with -march=z13 on s390x

[Matthias Klose]

Package: src:lib3mf
Version: 1.8.1+ds-3
Severity: important
Tags: sid bullseye patch

Mark more symbols as optional, not seen when built with -march=z13 on s390x.

patch at
http://launchpadlibrarian.net/484652140/lib3mf_1.8.1+ds-3build1_1.8.1+ds-3ubuntu1.diff.gz

Bug#963002: udev: Keyboard mis-detected as Apple

[Vroomfondel]

Package: udev
Version: 241-7~deb10u4
Severity: normal

Dear Maintainer,

* What led up to the situation?
New Varmilo keyboard

* What was the outcome of this action?
Fn keys not working correctly

* What outcome did you expect instead?
Fn key to work out of the box (as it does with my other Varmilo
KB)

* Futher elaboration:
I've run in to an odd problem recently with a new keyboard, a Varmilo VA88M 
(essentially the UK-ISO version of the VA87M); a fairly bog-standard tenkeyless 
keyboard.

On first use everything seemed to work OK, but it eventualy transpired that the 
Fkeys weren't working as expected. F1 through F6 didn't work at all and F7 
through F12 acted as media keys as if the Fn key was being pressed. Holding 
down the Fn key and pressing Fkeys they worked as expected, so the default 
behaviour of the keyboard was as if the Fn key was being held down all the 
time. Plugging in to a mate's windows machine, the same behaviour didn't occur.

On inspecting lsusb, it seemed that the keyboard was perhaps being erroneously 
detected as an Apple keyboard. lsusb output:
Bus 001 Device 007: ID 05ac:024f Apple, Inc.

Corresponding udevinfo output confirming the VID and PID (but name is correctly 
identified as a Varmilo):
udevadm info --path 
/devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:05AC:024F.000D/input/input20
P: 
//devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:05AC:024F.000D/input/input20
L: 0
E: 
DEVPATH=//devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/0003:05AC:024F.000D/input/input20
E: PRODUCT=3/5ac/24f/110
E: NAME="AONE Varmilo Keyboard"
E: PHYS="usb-:00:14.0-4/input0"
E: UNIQ=""
E: PROP=0
E: EV=120013
E: KEY=1 0 0 0 1007b1007 ff9f207ac14057ff ffbeffdfffef 
fffe
E: MSC=10
E: LED=1f
E: 
MODALIAS=input:b0003v05ACp024Fe0110-e0,1,4,11,14,k71,72,73,74,75,77,78,79,7A,7B,7C,7D,7E,7F,80,81,82,83,84,85,86,87,88,89,8A,8C,8E,96,98,9E,9F,A1,A3,A4,A5,A6,AD,B0,B1,B2,B3,B4,B7,B8,B9,BA,BB,BC,BD,BE,BF,C0,C1,C2,CC,E0,E1,E3,E4,E5,E6,F0,1D0,ram4,l0,1,2,3,4,sfw
E: SUBSYSTEM=input
E: USEC_INITIALIZED=389851205999
E: ID_INPUT=1
E: ID_INPUT_KEY=1
E: ID_INPUT_KEYBOARD=1
E: ID_VENDOR=AONE
E: ID_VENDOR_ENC=AONE
E: ID_VENDOR_ID=05ac
E: ID_MODEL=Varmilo_Keyboard
E: ID_MODEL_ENC=Varmilo\x20Keyboard
E: ID_MODEL_ID=024f
E: ID_REVISION=0100
E: ID_SERIAL=AONE_Varmilo_Keyboard
E: ID_TYPE=hid
E: ID_BUS=usb
E: ID_USB_INTERFACES=:030101:03:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=usbhid
E: ID_PATH=pci-:00:14.0-usb-0:4:1.0
E: ID_PATH_TAG=pci-_00_14_0-usb-0_4_1_0
E: ID_FOR_SEAT=input-pci-_00_14_0-usb-0_4_1_0
E: TAGS=:seat:

As far as I can tell, this keyboard should be being claimed by plain usbhid but 
is instead being claimed by hid_apple instead. At first I thought blacklisting 
the hid_apple module would force it to be claimed by regular usbhid but that 
just stopped the keyboard from working at all.

Looking in to the modinfo of hid_apple I can see there's an option named fnmode 
that governs the default behaviour of the Fn key which sounded exactly like the 
issue I was experiencing.
parm:   fnmode:Mode of fn key on Apple keyboards (0 = disabled, 
[1] = fkeyslast, 2 = fkeysfirst) (uint)

Sure enough, creating a module override for hid_apple setting this to 2 worked 
around the issue and then the Fkeys worked as expected:
options hid_apple fnmode=2

However this workaround is less then ideal (since if anyone did plug in a real 
apple keyboard this behaviour would be enforced for anything using hid_apple) 
so I was wondering if there was a way of fixing this "properly". I've never 
done any messing about of this sort before (first real issue I've ever had with 
linux device detection TBH) but after a wee dig around I found the following 
file which seems to suggest that all 05ac devices are always read as Apple 
keyboard devices:
grep -nB1 Apple /lib/udev/hwdb.d/20-usb-vendor-model.hwdb
22796-usb:v05AC*
22797: ID_VENDOR_FROM_DATABASE=Apple, Inc.

Ditto for the linux UDB ID repo:
https://usb-ids.gowdy.us/read/UD/05ac/024f

I realise this is probably fairly esoteric and I'm not sure why the KB 
seemingly has the same IDs as apple kit but is there a better workaround that 
can be done for keyboards based on e.g. the name? A quick mess around with udev 
rules didn't reveal any obvious ways of forcing any particular module.

I have another Varmilo keyboard, a VA69M also with similar Fn key functionality 
that doesn't present this problem (but it doesn't present itself as an Apple 
keyboard either, it shows as a Holtek).


-- Package-specific info:

-- System Information:
Debian Release: 10.4
 

Bug#963001: ITP: yanagiba: Filters low quality Oxford Nanopore reads basecalled with Albacore

[Nilesh Patra]

Package: wnpp
Severity: wishlist
Owner: Nilesh Patra 
X-Debbugs-CC: debian-de...@lists.debian.org


* Package name: yanagiba
  Version : 1.0.0
  Upstream Author : Adam Taranto
* URL : https://github.com/Adamtaranto/Yanagiba

* License : Expat
  Programming Lang: Python
  Description : Filters low quality Oxford Nanopore reads basecalled
with Albacore

 Yanagiba is used to filter short or low quality
 Oxford Nanopore reads which have been basecalled
 with Albacore. It takes fastq.gz and an Albacore
 summary file as input. If no Albacore summary file
 is provided attempt to calculate mean qscore from
 directly from fastq file using NanoMath. Note:
 Calculated quality scores appear to be lower
 for reads called with Metrichor, you may need
 to lower your minqual setting in this case.

I take the responsibility to maintain this package.

Bug#963000: systemd-analyze unit-paths erroneously reports /usr/lib/systemd/system/

[Thijs Kinkhorst]

Package: systemd
Version: 245.6-1
Severity: normal

Hi,

This is the output of 'systemd-analyze unit-paths' on my system:

# systemd-analyze unit-paths
/etc/systemd/system.control
/run/systemd/system.control
/run/systemd/transient
/run/systemd/generator.early
/etc/systemd/system
/etc/systemd/system.attached
/run/systemd/system
/run/systemd/system.attached
/run/systemd/generator
/usr/local/lib/systemd/system
/lib/systemd/system
/usr/lib/systemd/system
/run/systemd/generator.late

Howeverm it seems /usr/lib/systemd/system, despite being in the list, is
not actually searched. It was confirmed by other documentation that in
Debian this is indeed the case.

It seems that the output of this command is therefore not helpful (and seems
not actually based on the used paths?).


Kind regards,
Thijs

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages systemd depends on:
ii  adduser3.118
ii  libacl12.2.53-8
ii  libapparmor1   2.13.4-2
ii  libaudit1  1:2.8.5-3+b1
ii  libblkid1  2.35.2-2
ii  libc6  2.30-8
ii  libcap21:2.34-2
ii  libcrypt1  1:4.4.16-1
ii  libcryptsetup122:2.3.3-1
ii  libgcrypt201.8.5-5
ii  libgnutls303.6.14-2
ii  libgpg-error0  1.38-1
ii  libidn2-0  2.3.0-1
ii  libip4tc2  1.8.5-1
ii  libkmod2   27+20200310-2
ii  liblz4-1   1.9.2-2
ii  liblzma5   5.2.4-1+b1
ii  libmount1  2.35.2-2
ii  libpam0g   1.3.1-5
ii  libpcre2-8-0   10.34-7
ii  libseccomp22.4.3-1+b1
ii  libselinux13.0-1+b3
ii  libsystemd0245.6-1
ii  mount  2.35.2-2
ii  ntp [time-daemon]  1:4.2.8p14+dfsg-2
ii  util-linux 2.35.2-2

Versions of packages systemd recommends:
ii  dbus  1.12.18-1

Versions of packages systemd suggests:
pn  policykit-1
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.137
ii  libnss-systemd   245.6-1
ii  libpam-systemd   245.6-1
ii  udev 245.6-1

-- no debconf information

Bug#962956: reniced: reniced logs several syntax errors

[Francesco Potortì]

The quick patch is easy:

diff -pub /usr/bin/reniced\~ /usr/bin/reniced
--- /usr/bin/reniced~   2016-05-15 16:52:46.0 +0200
+++ /usr/bin/reniced2020-06-17 13:11:28.446821729 +0200
@@ -432,8 +432,8 @@ sub read_processes()
my $line = ; # skip first line
while ($line = ) {
chomp $line;
-   my $pid = substr($line, 0, 5 )+ 0;
-   my $cmd = substr($line, 6 );
+   my $pid = substr($line, 0, 7 )+ 0;
+   my $cmd = substr($line, 8 );
push @proc, { PID => $pid, CMD => $cmd };
}
 }

But it is dependont on the running kernel.  The implementation is
fragile and should be made independent of the number of digits of the
process identifier

-- 
Francesco Potortì (ricercatore)Voice:  +39.050.621.3058
ISTI - Area della ricerca CNR  Mobile: +39.348.8283.107
via G. Moruzzi 1, I-56124 Pisa Skype:  wnlabisti
(gate 20, 1st floor, room C71) Web:http://fly.isti.cnr.it

Bug#830572: UNRELEASED entry and new upstream version

[Guido Günther]

Hi,
On Thu, Jun 11, 2020 at 10:22:14AM +0200, Raphael Hertzog wrote:
> On Wed, 10 Jun 2020, Guido Günther wrote:
> > Happy to apply a patch. I'm using
> > 
> > ```
> > [import-orig]
> > # Automatically forward the changelog after importing a new upstream version
> > postimport = gbp dch -S -a --debian-branch=$GBP_BRANCH && git commit 
> > --amend -C@{0} debian/changelog
> > ```
> > 
> > to basically get this.
> 
> Note that "gbp dch -S -a" will not do what I'm asking here. My issue is
> when we have a pre-existing UNRELEASED entry for the former upstream
> version. That changelog entry is reused by "gbp dch" but the version
> number is not changed to match the latest upstream release that was merged
> before with gbp import-orig.

If you start using the hook it will do the right thing for new versions
from there on but as said it's just a stop gap.

> 
> More concretely, I have merged upstream release 4.0 but right
> now my changelog has this:
> cpputest (3.8-8) UNRELEASED; urgency=medium
> 
> And after "gbp dch" it still has the same header line when it should have
> updated it to 4.0-1 (or 4.0-1~1.gbp with -S).

Looking at the code this happens since there's no section being added:

https://git.sigxcpu.org/cgit/git-buildpackage/tree/gbp/scripts/dch.py#n524

and so we don't even start looking for a new version.

It would be best to make `gbp-dch` always check for new merged in
upstream tags and udpate the version accordingly (maybe hidden behind a
config option for people using upstrem git or complex histories).

Cheers,
 -- Guido

> 
> Cheers,
> -- 
>   ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog 
>   ⣾⠁⢠⠒⠀⣿⡁
>   ⢿⡄⠘⠷⠚⠋The Debian Handbook: https://debian-handbook.info/get/
>   ⠈⠳⣄   Debian Long Term Support: https://deb.li/LTS
> 

Bug#962999: mmtf-python: missing test dependencies

[Adrian Bunk]

Source: mmtf-python
Version: 1.1.2-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/m/mmtf-python/5907696/log.gz

...
autopkgtest [15:09:39]: test command1: python3 mmtf/tests/codec_tests.py
autopkgtest [15:09:39]: test command1: [---
Traceback (most recent call last):
  File "mmtf/tests/codec_tests.py", line 4, in 
import numpy
ModuleNotFoundError: No module named 'numpy'
autopkgtest [15:09:40]: test command1: ---]
autopkgtest [15:09:40]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 1



Additionally, python3-msgpack and python3-numpy might also
be appropriate for Recommends or Suggests?

Bug#959829: [covid-19] Help needed to finalise bazel predependency google-api-client-java

[Sudip Mukherjee]

On Wed, Jun 17, 2020 at 9:13 AM Andreas Tille  wrote:
>
> Hi Tony,
>
> On Tue, Jun 16, 2020 at 09:34:20PM -0700, tony mancill wrote:
> >
> > I've pushed a "tmancill" branch to the Salsa repo that gets us further
> > along.

I have taken the liberty to push to "tmancill" branch and the issue
with "com.google.api.client.util" is now resolved. It needs to depend
on "libgoogle-oauth-client-java" which is still in NEW.
But, it now fails with:

google-api-client/src/main/java/com/google/api/client/googleapis/services/AbstractGoogleClientRequest.java:[435,16]
cannot find symbol
[ERROR]   symbol:   method setResponseReturnRawInputStream(boolean)
[ERROR]   location: variable httpRequest of type
com.google.api.client.http.HttpRequest

And, indeed 
https://salsa.debian.org/java-team/google-http-client-java/-/blob/master/google-http-client/src/main/java/com/google/api/client/http/HttpRequest.java
is not having the method "setResponseReturnRawInputStream". And, it
seems the packaged version of libgoogle-http-client-java in Debian is
1.27 and "setResponseReturnRawInputStream" was added in v1.29.0. So,
we will need to update  libgoogle-http-client-java to 1.29.0 atleast.


-- 
Regards
Sudip

Bug#960265: s390x install Debootstrap warning: Failure while configuring base packages. s390-tools depends on perl:any.

[Piotr Kolasiński]

On Tue, Jun 16, 2020 at 11:24:11AM +0300, Adrian Bunk wrote:
> On Mon, Jun 15, 2020 at 12:17:39AM +0200, Vctl Piotr Kolasinski wrote:
> >...
> > In my opinion the big problem may be w ith access to the real platform
> > (currently I have access and possibilities but I don't know how long).
> > Of course we have emulators like hercules (which I use from very long
> > time) and know qemu s390 port (only with virtio, not tested by me),
> > but it is probably not enough in power (as long as yo don't have very
> > powerful emulation platform or use cross-compile). Anyway if Debian
> > maintainers have access to valid build environment, I think you should
> > not remove the architecture.
> 
> Hardware is not the problem.
> Forcing 1000 volunteers in Debian to support a port that has no porters 
> and no users is the problem.
> 
> Debian has an s390x porterbox that is available to all Debian developers.
> For normal package development this is sufficient.
> 
> The s390x port has some unique problems.
> And with a390x as release architecture package maintainers in Debian are 
> supposed to fix these problems in their packages if they want their 
> packages in the next Debian release.
> 
> Forcing volunteers to do unpleasant work like porting to s390x is making 
> it a more attractive choice to stop contributing to Debian.
I understand your point. I just started to read about Debian
maintainers, developers, porteboxes etc., I will not discuss with you. 
My mail was sent because I use Debian in any possible place, advertise it, 
treat as stable, good alternative to other distros. From other site I
didn't know about unique problems for that arch.
> 
> s390x is the only big endian release architecture.
> Big endian hardware has become exotic, and some of the younger 
> maintainers in Debian might have never seen big endian hardware.
> Endian problems are common problems in packages,
> and porting software to support big endian can be a real pain.
> 
Is that not why Linux is so popular - portability? 

> s390x is the only headless release architecture.
> This was a real pain for the Debian GNOME maintainers already before
> the last release, without any support from s390x porters on fixing
> this issue.[1]
I don't agree. Fact, that s390x doesn't have direct display doesn't mean
that graphical tools are not used. Is really good way to thinking about Linux
as desktop system only? In my daily work we have much more Linux boxes
in VM (as host and target) then desktop system (where Windows is the
king and never will change in next 20 years). I still remember that
X Window architecture assume remote operations and local Xserver is only
one of a few possible configurations. 
Of course if we assume, that we produce desktop system, the s390x is not
composing with that. I use Debian in many instances - only two of them I
access directly (using graphics), the rest is some kind of "server" (but
I still can reach then graphically using vnc protocol). 
> 
> A port like s390x with unique problems is only sustainable when several 
> people with good knowledge of Debian, s390x hardware and the Linux 
> kernel have a long-term commitment of swiftly supporting everyone in 
> Debian with s390x problems.
Good point - the question is why there is not so many people with "good
knowledge of Debian" in Mainframe environment? How many of potential
mainframe users know that Debian supports s390x architecture? If not
many - why? 
About "s390x hardware and the Linux kernel" - I'm just only advanced user
(I hope), but as I know - the kernel support in this area is mostly done
by IBM. Does someone can tell me how many changes have to be done in Debian
and what kind for the kernel? Does we really need many people in this
area? 

> 
> IMHO it would be best if s390x would become a non-release architecture 
> in ports.
My previous message was sent because I worry, that if this architecture
will become not-release, after short time disappear (and some people
abandon it or switch to Ubuntu - as long as it exists). 
> 
> Architectures in ports are autobuilt like release architectures,
> but there is no pressure on the volunteers maintaining packages
> in Debian to spend their time on supporting these architectures.
> Other architectures like m68k, big endian powerpc, alpha, hppa
> and ia64 that also tend to have one dedicated porter each but
> not many users left are also in ports.
Here is my lack of knowledge - I just started to dig Debian ecosystem as
supporter, I don't know too much about preparing releases, building
packages etc. Last time when I had problems with installation on
Mainframe, I have learned many things about Debian installer, but ...
I even don't know where to start reading about it  be useful for
others. Anyway I want to be active Debian user (partially on the
Mainframe) and I want to help.

Anyway thank for support till this time.


Piotr

Bug#962560: code-saturne built-in file editor fails

[Yvan Fournier]

Hello,

The built-in viewer (not editor) is a simple text file viewer intended for
various log files, though it could be used to view .csv or .dat plot file
contents also.

It only displays file contents, and is not intended for files whith a specific
structure and/or binary files surch as the MED, CGNS, or EnSight files used for
visualization with tools such as ParaView.

The GUI should report that binary files are not supported rather than crash upon
read, so there is a minor bug, which we will fix, but this feature is not
intended for this type of file in any case.

Bug#962750: nheko 0.7.1 is in buster-backports

[Pirate Praveen]

Control: fixed -1 0.7.1-1~bpo10+1

closing.



signature.asc
Description: OpenPGP digital signature

Bug#962997: ITP: treerecs -- Correct, rearrange and (re-)root gene trees

[David Parsons]

Package: wnpp
Severity: wishlist
Owner: David Parsons 

* Package name: treerecs
  Version : 1.2
  Upstream Author : Treerecs 
* URL : https://sympa.inria.fr/sympa/info/treerecs
* License : AGPL
  Programming Lang: C++
  Description : Correct, rearrange and (re-)root gene trees

Treerecs is an open-source (species- and gene-) tree reconciliation software 
distributed under the GNU AGPL licence.
It can correct, rearrange and (re-)root gene trees with regard to a given 
species tree.
It was designed to be both efficient and easy to install and to use.

I intend tha this package will be maintained through the debian-med team

Bug#932296: qa.debian.org: getwatch filling up /tmp

[Julien Cristau]

On Wed, Jun 17, 2020 at 07:00:43 +0100, Adam D. Barratt wrote:

> On Wed, 2020-06-17 at 00:14 +0200, Lucas Nussbaum wrote:
> > Apparently the condition where this happens is quite rare
> > occurences on 08/2019, 12/2019, 06/2020), so notifying me after the
> > files were cleaned up from /tmp makes it hard to identify which
> > packages cause this issue. If I could get notified when a warning
> > limit is reached, it would be much easier to debug.
> 
> I'm not sure what the usual policy on that is, but I didn't clean up
> /tmp after disabling the importer last night:
> 
> drwx-- 3 udd uddadm  4096 Jun 16 20:20 getwatch.qmapshack.n13QHA
> drwx-- 3 udd uddadm  4096 Jun 16 20:20 getwatch.picard-tools.Zg0jud
> drwx-- 3 udd uddadm  4096 Jun 16 20:50 getwatch.qmapshack.aH184l
> drwx-- 3 udd uddadm  4096 Jun 16 20:50 getwatch.picard-tools.SqIkjD
> drwx-- 3 udd uddadm  4096 Jun 16 21:20 getwatch.qmapshack.1pIg10
> drwx-- 3 udd uddadm  4096 Jun 16 21:20 getwatch.picard-tools.g3weib
> drwx-- 3 udd uddadm  4096 Jun 16 21:50 getwatch.qmapshack.oklPSa
> drwx-- 3 udd uddadm  4096 Jun 16 21:50 getwatch.picard-tools.Lo3UhJ
> 
This is how it looked before reboot yesterday, according to my terminal's
scroll buffer:

jcristau@ullmann:~$ ls -l /tmp/getwatch.* -d
drwx-- 3 udd uddadm 4096 Jun 16 12:50 /tmp/getwatch.deepin-icon-theme.dXa34U
drwx-- 3 udd uddadm 4096 Jun 16 12:20 /tmp/getwatch.deepin-icon-theme.EDzB2B
drwx-- 3 udd uddadm 4096 Jun 16 11:20 /tmp/getwatch.deepin-icon-theme.fG5L65
drwx-- 3 udd uddadm 4096 Jun 16 13:50 /tmp/getwatch.deepin-icon-theme.GKeDmI
drwx-- 3 udd uddadm 4096 Jun 16 10:50 /tmp/getwatch.deepin-icon-theme.JiwELJ
drwx-- 3 udd uddadm 4096 Jun 16 14:20 /tmp/getwatch.deepin-icon-theme.kgoDIn
drwx-- 3 udd uddadm 4096 Jun 16 09:50 /tmp/getwatch.deepin-icon-theme.kqqITx
drwx-- 3 udd uddadm 4096 Jun 16 13:20 /tmp/getwatch.deepin-icon-theme.p0Lknv
drwx-- 3 udd uddadm 4096 Jun 16 10:20 /tmp/getwatch.deepin-icon-theme.sMzg7u
drwx-- 3 udd uddadm 4096 Jun 16 11:50 /tmp/getwatch.deepin-icon-theme.uSHETI
drwx-- 3 udd uddadm 4096 Jun 16 11:20 /tmp/getwatch.htsjdk.eC4uvs
drwx-- 3 udd uddadm 4096 Jun 16 11:50 /tmp/getwatch.htsjdk.EU4suU
drwx-- 3 udd uddadm 4096 Jun 16 14:20 /tmp/getwatch.htsjdk.kih83R
drwx-- 3 udd uddadm 4096 Jun 16 12:20 /tmp/getwatch.htsjdk.L9J9LA
drwx-- 3 udd uddadm 4096 Jun 16 10:20 /tmp/getwatch.htsjdk.m2FgS0
drwx-- 3 udd uddadm 4096 Jun 16 10:50 /tmp/getwatch.htsjdk.MwALoV
drwx-- 3 udd uddadm 4096 Jun 16 09:50 /tmp/getwatch.htsjdk.N7bIVe
drwx-- 3 udd uddadm 4096 Jun 16 13:20 /tmp/getwatch.htsjdk.NRopqF
drwx-- 3 udd uddadm 4096 Jun 16 13:50 /tmp/getwatch.htsjdk.wEFDNs
drwx-- 3 udd uddadm 4096 Jun 16 12:50 /tmp/getwatch.htsjdk.Wqf6gL
drwx-- 3 udd uddadm 4096 Jun 16 09:50 /tmp/getwatch.picard-tools.BfwMyC
drwx-- 3 udd uddadm 4096 Jun 16 12:20 /tmp/getwatch.picard-tools.gY2ZQk
drwx-- 3 udd uddadm 4096 Jun 16 12:50 /tmp/getwatch.picard-tools.I1wZDY
drwx-- 3 udd uddadm 4096 Jun 16 11:50 /tmp/getwatch.picard-tools.JG01pg
drwx-- 3 udd uddadm 4096 Jun 16 14:20 /tmp/getwatch.picard-tools.KawVh5
drwx-- 3 udd uddadm 4096 Jun 16 11:20 /tmp/getwatch.picard-tools.l0wUag
drwx-- 3 udd uddadm 4096 Jun 16 13:20 /tmp/getwatch.picard-tools.oVJAT9
drwx-- 3 udd uddadm 4096 Jun 16 13:50 /tmp/getwatch.picard-tools.SdFotX
drwx-- 3 udd uddadm 4096 Jun 16 10:50 /tmp/getwatch.picard-tools.Tq98F0
drwx-- 3 udd uddadm 4096 Jun 16 10:20 /tmp/getwatch.picard-tools.zPqqVr
drwx-- 3 udd uddadm 4096 Jun 16 12:20 /tmp/getwatch.qmapshack.B3SMHo
drwx-- 3 udd uddadm 4096 Jun 16 10:20 /tmp/getwatch.qmapshack.hADG4I
drwx-- 3 udd uddadm 4096 Jun 16 13:20 /tmp/getwatch.qmapshack.I1X2xV
drwx-- 3 udd uddadm 4096 Jun 16 09:50 /tmp/getwatch.qmapshack.i8ooLp
drwx-- 3 udd uddadm 4096 Jun 16 11:20 /tmp/getwatch.qmapshack.JRgmcP
drwx-- 3 udd uddadm 4096 Jun 16 13:50 /tmp/getwatch.qmapshack.k7ujsc
drwx-- 3 udd uddadm 4096 Jun 16 10:50 /tmp/getwatch.qmapshack.muqRD1
drwx-- 3 udd uddadm 4096 Jun 16 11:50 /tmp/getwatch.qmapshack.VkgQed
drwx-- 3 udd uddadm 4096 Jun 16 14:20 /tmp/getwatch.qmapshack.W00S3T
drwx-- 3 udd uddadm 4096 Jun 16 12:50 /tmp/getwatch.qmapshack.zPrnz7

Cheers,
Julien

Bug#936227: boost1.67: Python2 removal in sid/bullseye

[Giovanni Mascellani]

Hi,

Il 17/06/20 06:10, Sandro Tosi ha scritto:
> great! I see the transition is almost completed - i'm wondering when
> it's going to be the time we can remove src:boost1.67 from unstable:
> it is now the only remaining rdep of cython, which in turn it's the
> only remaining rdep of src:python-numpy which i'd like to remove soon

I see xnox just filed a RM bug asking for a force removal:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962950

That seems a little aggressive, but I have no idea what's the FTP team's
idea on that.

On the social side, it seems there is disagreement with the kig
maintainer (pino) on how to handle the transition and the fact that kig
does not yet support Python 3:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962348

Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



signature.asc
Description: OpenPGP digital signature