Bug#950079: grub-cloud-amd64: prompting due to modified conffiles which were not modified by the user: /etc/default/grub

[Bastian Blank]

Control: severity -1 important

On Tue, Jan 28, 2020 at 09:25:28PM +0100, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package failed the piuparts
> upgrade test because dpkg detected a conffile as being modified and then
> prompted the user for an action. As there is no user input, this fails.
> But this is not the real problem, the real problem is that this prompt
> shows up in the first place, as there was nobody modifying this conffile
> at all, the package has just been installed and upgraded...

This is actually ucf vs conffile in different packages.

> This is a violation of policy 10.7.3, see
> https://www.debian.org/doc/debian-policy/ch-files.html#behavior,
> which says "[These scripts handling conffiles] must not ask unnecessary
> questions (particularly during upgrades), and must otherwise be good
> citizens."

But this is about conffiles, not scripts.

Bastian

-- 
Conquest is easy. Control is not.
-- Kirk, "Mirror, Mirror", stardate unknown

Bug#951569: thunderbird: Changing account to send email doesn't work, it changes only FROM name.

[Nicola]

Package: thunderbird
Version: 1:68.5.0-1
Severity: important

Dear Maintainer,

Situation.
Thunderbird with 5 account e-mail (A, B, C, D, E).

I receive an email on account A "Pippo " and I wish to reply
using account B "Company ".

I compose my e-mail, finally I go to change the account to use (From in the top
of compose window), and I send the e-mail.

The e-mail is sent using the SMTP server of A account, the from A e-mail but
the name of B account. (Company )



-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (950, 'testing'), (400, 'unstable'), (300, 'experimental'), (10, 
'stable')
Architecture: amd64 (x86_64)

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

Versions of packages thunderbird depends on:
ii  debianutils   4.9.1
ii  fontconfig2.13.1-2+b1
ii  libatk1.0-0   2.34.1-1
ii  libc6 2.29-10
ii  libcairo-gobject2 1.16.0-4
ii  libcairo2 1.16.0-4
ii  libdbus-1-3   1.12.16-2
ii  libdbus-glib-1-2  0.110-5
ii  libevent-2.1-72.1.11-stable-1
ii  libffi7   3.3-3
ii  libfontconfig12.13.1-2+b1
ii  libfreetype6  2.10.1-2
ii  libgcc-s1 10-20200204-1
ii  libgdk-pixbuf2.0-02.40.0+dfsg-2
ii  libglib2.0-0  2.62.4-1+b1
ii  libgtk-3-03.24.13-1
ii  libgtk2.0-0   2.24.32-4
ii  libicu63  63.2-2
ii  libjsoncpp1   1.7.4-3.1
ii  libnspr4  2:4.24-1
ii  libnss3   2:3.49.1-1
ii  libpango-1.0-01.42.4-7
ii  libsqlite3-0  3.31.1-1
ii  libstartup-notification0  0.12-6
ii  libstdc++69.2.1-25
ii  libvpx6   1.8.2-dmo1
ii  libx11-6  2:1.6.8-1
ii  libx11-xcb1   2:1.6.8-1
ii  libxcb-shm0   1.13.1-2
ii  libxcb1   1.13.1-2
ii  libxext6  2:1.3.3-1+b2
ii  libxrender1   1:0.9.10-1
ii  libxt61:1.1.5-1+b3
ii  psmisc23.3-1
ii  x11-utils 7.7+4
ii  zlib1g1:1.2.11.dfsg-1.2

Versions of packages thunderbird recommends:
ii  hunspell-en-us [hunspell-dictionary]  1:2018.04.16-1
ii  hunspell-it [hunspell-dictionary] 1:6.4.0~rc2-1
ii  lightning 1:68.5.0-1

Versions of packages thunderbird suggests:
ii  apparmor  2.13.3-7
ii  fonts-lyx 2.3.4-1
ii  libgssapi-krb5-2  1.17-6

-- no debconf information

Bug#950716: transition: ruby2.7

[Graham Inggs]

On Tue, 18 Feb 2020 at 01:16, Lucas Kanashiro  wrote:
> I just uploaded ruby-defaults version 1:2.5.7 to unstable with both
> versions of the ruby interpreter enabled (2.5 and 2.7).

Great!

> We (the Ruby team) should start to request some binNMUs soon.

OK, you can send them to this bug, and no need to CC me.

Is there a reason not to do the binNMUs in the dependency level order
from the tracker [1]?


[1] https://release.debian.org/transitions/html/ruby2.7.html

Bug#908203: opam in buster

[Stéphane Glondu]

[Sorry if you received this message multiple times...]

Hello,

It has been brought to my attention that opam doesn't work in stable
(buster) out of the box. This has been tracked in [1] (fixed in testing
(bullseye)) and [2]. See in particular comments starting at [3].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=908203
[2] https://github.com/ocaml/opam/issues/3827
[3] https://github.com/ocaml/opam/issues/3827#issuecomment-586265289

Martin Lucina (@mato on GitHub) proposed some changes to improve the
situation.

I've tested the following: "opam init" does not work properly without
the changes (I've killed it because it consumes too much memory). With
the changes, it fails (in a chroot) because bwrap fails, but "opam init
--disable-sandboxing" works.

I've attached the proposed changes. I am considering submitting them to
buster. Can someone review them and confirm that they work as expected
(or, at least, that they improve the situation)?


Cheers,

-- 
Stéphane

diff -Nru opam-2.0.3/debian/changelog opam-2.0.3/debian/changelog
--- opam-2.0.3/debian/changelog	2019-02-01 12:05:09.0 +0100
+++ opam-2.0.3/debian/changelog	2020-02-18 07:42:31.0 +0100
@@ -1,3 +1,10 @@
+opam (2.0.3-1+deb10u1) buster; urgency=medium
+
+  * Team upload
+  * Prefer mccs over aspcud (Closes: #908203)
+
+ -- Stéphane Glondu   Tue, 18 Feb 2020 07:42:31 +0100
+
 opam (2.0.3-1) unstable; urgency=medium
 
   * New (bugfix) upstream release
diff -Nru opam-2.0.3/debian/control opam-2.0.3/debian/control
--- opam-2.0.3/debian/control	2019-02-01 10:13:14.0 +0100
+++ opam-2.0.3/debian/control	2020-02-18 07:37:20.0 +0100
@@ -22,7 +22,7 @@
  libopam-file-format-ocaml-dev,
  libjsonm-ocaml-dev,
  libopam-file-format-ocaml-dev,
- aspcud,
+ mccs,
  rsync,
  unzip,
  openssl,
@@ -50,7 +50,7 @@
  ${misc:Depends},
  opam-doc (= ${source:Version}),
  build-essential,
- aspcud | mccs | packup,
+ mccs,
  opam-installer,
  bubblewrap [linux-any],
  unzip,
diff -Nru opam-2.0.3/debian/gbp.conf opam-2.0.3/debian/gbp.conf
--- opam-2.0.3/debian/gbp.conf	2018-12-02 12:53:29.0 +0100
+++ opam-2.0.3/debian/gbp.conf	2020-02-18 07:33:43.0 +0100
@@ -8,3 +8,5 @@
 "src_ext",
 "ocp-build"
 ]
+debian-branch = buster/master
+upstream-branch = buster/upstream
diff -Nru opam-2.0.3/debian/patches/0003-Prefer-mccs-over-aspcud.patch opam-2.0.3/debian/patches/0003-Prefer-mccs-over-aspcud.patch
--- opam-2.0.3/debian/patches/0003-Prefer-mccs-over-aspcud.patch	1970-01-01 01:00:00.0 +0100
+++ opam-2.0.3/debian/patches/0003-Prefer-mccs-over-aspcud.patch	2020-02-18 07:40:53.0 +0100
@@ -0,0 +1,25 @@
+From: Martin Lucina 
+Date: Tue, 18 Feb 2020 07:37:04 +0100
+Subject: Prefer mccs over aspcud
+
+Bug-Debian: https://bugs.debian.org/908203
+Bug: https://github.com/ocaml/opam/issues/3827
+Origin: https://github.com/ocaml/opam/issues/3827#issuecomment-586945810
+---
+ src/solver/opamCudfSolver.ml | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/solver/opamCudfSolver.ml b/src/solver/opamCudfSolver.ml
+index 03486f1..b3b8aa6 100644
+--- a/src/solver/opamCudfSolver.ml
 b/src/solver/opamCudfSolver.ml
+@@ -215,8 +215,8 @@ let make_custom_solver name args criteria =
+ 
+ let default_solver_selection =
+   OpamBuiltinMccs.all_backends @ [
+-(module Aspcud: S);
+ (module Mccs: S);
++(module Aspcud: S);
+ (module Aspcud_old: S);
+ (module Packup: S);
+   ]
diff -Nru opam-2.0.3/debian/patches/series opam-2.0.3/debian/patches/series
--- opam-2.0.3/debian/patches/series	2019-02-01 12:04:22.0 +0100
+++ opam-2.0.3/debian/patches/series	2020-02-18 07:40:53.0 +0100
@@ -1,2 +1,3 @@
 0002-Add-a-test-target.patch
 0002-Fix-spelling-error-in-manpage.patch
+0003-Prefer-mccs-over-aspcud.patch

Bug#951568: devscripts: uscan mode=svn fails with HTTP(S) URLs

[merkys]

Package: devscripts
Forwarded: https://salsa.debian.org/debian/devscripts/merge_requests/173
Tags: patch

Hello,

There is a bug preventing handling of HTTP(S) URLs with mode=svn. I have
submitted a MR in salsa fixing it [1].

[1] https://salsa.debian.org/debian/devscripts/merge_requests/173

Best wishes,
Andrius

Bug#951567: proofgeneral: please, do not depend on emacs-gtk, proofgeneral works with emacs-lucid and even emacs-nox

[Lev Lamberov]

Package: proofgeneral
Version: 4.4.1~pre170114-1.2
Severity: normal

Dear Maintainer,

proofgeneral works with emacs-lucid and with emacs-nox. Please, do not
depend only on emacs-gtk.

With regards,
Lev Lamberov


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

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

Versions of packages proofgeneral depends on:
ii  emacs-gtk  1:26.3+1-1
ii  mmm-mode   0.5.7-3

proofgeneral recommends no packages.

Versions of packages proofgeneral suggests:
pn  proofgeneral-doc  
ii  prooftree 0.13-1+b4

-- no debconf information

Bug#951566: Please allow NEEDRESTART_MODE=automatic (and "needrestart -r automatic")

[Trent W. Buck]

Package: needrestart
Version: 3.4-5
Severity: wishlist
File: /usr/sbin/needrestart

Hi, right now I have to write

NEEDRESTART_MODE=a
needrestart -ra

For clarity I would prefer to write whole words, e.g.

NEEDRESTART_MODE=automatic
needrestart --restart-mode=automatic

I *think* a minimal change would look like this (untested):

   +$opt_r = substr($opt_r, 0, 1) if ($opt_r =~ 
/^(list|interactive|automatic)$/);
die "ERROR: Unknown restart option '$opt_r'!\n" unless($opt_r =~ 
/^(l|i|a)$/);

My perl-fu is weak, so I haven't thought about this in any detail.
I guess $opt_m would get an equivalent one-line change.



-- Package-specific info:
needrestart output:



-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (500, 
'proposed-updates'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages needrestart depends on:
ii  binutils   2.31.1-16
ii  dpkg   1.19.7
ii  gettext-base   0.19.8.1-9
ii  libintl-perl   1.26-2
ii  libmodule-find-perl0.13-1
ii  libmodule-scandeps-perl1.27-1
ii  libproc-processtable-perl  0.56-1
ii  libsort-naturally-perl 1.03-2
ii  libterm-readkey-perl   2.38-1
ii  perl   5.28.1-6
ii  xz-utils   5.2.4-1

Versions of packages needrestart recommends:
ii  libpam-systemd  241-7~deb10u3

Versions of packages needrestart suggests:
ii  iucode-tool  2.3.1-1
pn  needrestart-session | libnotify-bin  

-- no debconf information

Bug#951565: freerdp2-x11: does not work at all, immediately exits, against xrdp server (rdesktop works)

[Thorsten Glaser]

Package: freerdp2-x11
Version: 2.0.0~git20190204.1.2693389a+dfsg1-2
Severity: grave
Justification: renders package unusable

tglase@tglase-nb:~ $ xfreerdp /v:tglase-edge

[07:15:07:750] [29233:29234] [INFO][com.freerdp.client.common.cmdline] - 
loading channelEx cliprdr
[07:15:07:751] [29233:29234] [INFO][com.freerdp.client.x11] - No user name set. 
- Using login name: tglase
[07:15:08:615] [29233:29234] [INFO][com.freerdp.gdi] - Local framebuffer format 
 PIXEL_FORMAT_BGRX32
[07:15:08:615] [29233:29234] [INFO][com.freerdp.gdi] - Remote framebuffer 
format PIXEL_FORMAT_RGB16
[07:15:08:628] [29233:29234] [INFO][com.winpr.clipboard] - initialized POSIX 
local file subsystem
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.update] - [0x03] Cache 
Glyph - SERVER BUG: The support for this feature was not announced! Use 
/relax-order-checks to ignore
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.update] - order flags 03 
failed
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.fastpath] - Fastpath 
update Orders [0] failed, status 0
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.fastpath] - 
fastpath_recv_update() - -1
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.fastpath] - 
fastpath_recv_update_data() fail
[07:15:08:744] [29233:29234] [ERROR][com.freerdp.core.transport] - 
transport_check_fds: transport->ReceiveCallback() - -3
[07:15:08:745] [29233:29234] [ERROR][com.freerdp.core] - freerdp_check_fds() 
failed - 0
[07:15:08:745] [29233:29234] [INFO][com.freerdp.client.common] - Network 
disconnect!
[07:15:08:745] [29233:29234] [ERROR][com.freerdp.client.x11] - Failed to check 
FreeRDP file descriptor
131|tglase@tglase-nb:~ $ rdesktop -g 1000x768 tglase-edge   

Connection established using plain RDP.
[…]

xfreerdp just exits with errorlevel 131 (could be signal 3),
whereas rdesktop works (shows the remote login screen).
xfreerdp, just before exiting, paints a window, but I cannot
see if anything is in it because it goes away too quickly.

I also tried xfreerdp /size:1000x768 /v:tglase-edge but that
does not change anything.

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

Kernel: Linux 5.4.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)

Versions of packages freerdp2-x11 depends on:
ii  libc6 2.29-10
ii  libfreerdp-client2-2  2.0.0~git20190204.1.2693389a+dfsg1-2
ii  libfreerdp2-2 2.0.0~git20190204.1.2693389a+dfsg1-2
ii  libwinpr2-2   2.0.0~git20190204.1.2693389a+dfsg1-2
ii  libx11-6  2:1.6.8-1
ii  libxcursor1   1:1.2.0-2
ii  libxext6  2:1.3.3-1+b2
ii  libxfixes31:5.0.3-1
ii  libxi62:1.7.9-1
ii  libxinerama1  2:1.1.4-2
ii  libxrandr22:1.5.1-1
ii  libxrender1   1:0.9.10-1
ii  libxv12:1.0.11-1

freerdp2-x11 recommends no packages.

freerdp2-x11 suggests no packages.

-- no debconf information

Bug#951564: stretch-pu: package postfix/3.1.14-0+10debu1

[Scott Kitterman]

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

This is the next in the series of postfix 3.1 updates.  It includes the
postfix 3.1 relevant fixes from 3.4.8 and 3.4.9 (as there was no
companion 3.1 release with 3.4.8).  The only other change is to add the
upstream signing key to make it easier for me to verify upstream
signatures when preparing future updates.

All the fixes in this update are already in Testing and will be in
Buster once the recently requested pu for 3.4.9 is accepted.  I have
this version running on a system and have given it basic testing.  Given
upstream's history with maintenance updates, I have confidence this is
very low risk.  Details follow:

  [Scott Kitterman]

  * Check GPG signature when downloading new versions via uscan

  [Wietse Venema]

  * 3.1.15
- Bugfix (introduced: Postfix 2.8): don't gratuitously enable
  all after-220 tests when only one such test is enabled.
  This made selective tests impossible with 'good' clients.
  File: postscreen/postscreen_smtpd.c.
- Bugfix (introduced: Postfix 3.1): support for
  smtp_dns_resolver_options was broken while adding support
  for negative DNS response caching in postscreen. Postfix
  was inadvertently changed to call res_query() instead of
  res_search(). Reported by Jaroslav Skarvada. File:
  dns/dns_lookup.c.
- Bugfix (introduced: Postfix 3.0): sanitize server responses
  before storing them in the verify database, to avoid Postfix
  warnings about malformed UTF8. File: verify/verify.c.
- Bugfix (introduced: Postfix 2.5): the Milter connect event
  macros were evaluated before the Milter connection itself
  had been negotiated. Problem reported by David Bürgin.
  Files: milter/milter.h, milter/milter.c, milter/milter8.c

Scott K
diff -Nru postfix-3.1.14/debian/changelog postfix-3.1.15/debian/changelog
--- postfix-3.1.14/debian/changelog 2019-10-01 19:28:19.0 -0400
+++ postfix-3.1.15/debian/changelog 2020-02-16 14:59:05.0 -0500
@@ -1,3 +1,32 @@
+postfix (3.1.15-0+deb9u1) stretch; urgency=medium
+
+  [Scott Kitterman]
+
+  * Check GPG signature when downloading new versions via uscan
+
+  [Wietse Venema]
+
+  * 3.1.15
+- Bugfix (introduced: Postfix 2.8): don't gratuitously enable
+  all after-220 tests when only one such test is enabled.
+  This made selective tests impossible with 'good' clients.
+  File: postscreen/postscreen_smtpd.c.
+- Bugfix (introduced: Postfix 3.1): support for
+  smtp_dns_resolver_options was broken while adding support
+  for negative DNS response caching in postscreen. Postfix
+  was inadvertently changed to call res_query() instead of
+  res_search(). Reported by Jaroslav Skarvada. File:
+  dns/dns_lookup.c.
+- Bugfix (introduced: Postfix 3.0): sanitize server responses
+  before storing them in the verify database, to avoid Postfix
+  warnings about malformed UTF8. File: verify/verify.c.
+- Bugfix (introduced: Postfix 2.5): the Milter connect event
+  macros were evaluated before the Milter connection itself
+  had been negotiated. Problem reported by David Bürgin.
+  Files: milter/milter.h, milter/milter.c, milter/milter8.c
+
+ -- Scott Kitterman   Sun, 16 Feb 2020 14:59:05 -0500
+
 postfix (3.1.14-0+deb9u1) stretch; urgency=medium
 
   [Wietse Venema]
diff -Nru postfix-3.1.14/debian/upstream/signing-key.asc 
postfix-3.1.15/debian/upstream/signing-key.asc
--- postfix-3.1.14/debian/upstream/signing-key.asc  1969-12-31 
19:00:00.0 -0500
+++ postfix-3.1.15/debian/upstream/signing-key.asc  2020-02-16 
14:53:17.0 -0500
@@ -0,0 +1,154 @@
+-BEGIN PGP PUBLIC KEY BLOCK-
+Version: GnuPG v2.0.18 (FreeBSD)
+
+mQMuBFYZbx0RCADaN3/xzcSgTh/Zdpn5Ia0cRAGF/0ZKbd6azuiFTvXQd/JLZkYj
+DkNHHGZImtQhPf+aa7JXCUSqrbgvSyYOYUI6enx+W8RBzvYBWEccW1Ls4D7mxUmA
+CbHfcGn7gdEXaQaHS4sJzoYCGRboOKyLCGHvSajxr+HidAv9JEzuGb20TRZ9bL9B
+P3LrKIleSSJICH5qU+mGtCE0nZspAhpbLizCAx9jkS5lKfmPI7ua2q+nDQJ3/Q9I
+mfJGM6HR2SvPR5hl9ZoZF0p44bl30hmwezbkx151+Zt23MW+OWUtpoZQBiW5q3J0
+wa6td1llChOrjTYBhSIhiHifC59FCnxp48EzAQCGskLjC2PyrPOOPMRez5yaxLJq
+YhAuOc8hZNVmCSeVKQf+MbxsyUaraay4SpUIwtzRYZVBrdjM8XGeBJcmFBhWHaoD
+G1fIflmP8RfmP0lx8CUSMR4o508mKZ8Rf5VQlAkjUFMeCG+3Hf1bmvZqUwiwy27o
+tuhud+XSN5QErzbP7nakkmE8vUhzWQAYIrg/GMSWOZW74JWuhRUgBgEDG8AMQNRS
+JfABm3/c+xJlidnLjgam73iG0VM/ivzdOKKZM/XCqihmpSJg7U0a2C0cnOOFQkHa
++ym7rgeZJrUM2A/KEWS8i/eqBlp7RZXovpSFfFIWWbM9HngdjND0Kk7RMxtzgt6p
+GrQaqArthyOlMpZ72xTdnUGex5rxgo19J9eJmkrg7wf/cncD5yuR99/myQjAqx+a
+uHOV7vOclyyZB7HLqW5ry4AozRv8TNTPsYUNc7ie4gjslkwXFSgv/RVjBIMeM7Jd
+JRvBvehttr0SnkiiixTFEjw1n9kIJAh3YD+3/zP2rz2nxYyQhCdswcQNVHWQcx17
+bCMgzXw5ysjusG+lej1dueEApXlU6+mfnfbQ05lR4u5wAxfbcqN6vS4aEiYbTixL
+Kgm9wffU9Snshqz4OU4Nj8so2OtDrCyAZ+WQEOY7A+j96VUFeM3FaBnvWz8b5JZg
+JaMbKr5naovFIBaDBzLzxjn42IcI778EwFetXbFGrLSZU17FoufDnOEFKbwkJehh

Bug#895937: database upgrade from schema 8 to 9 fails - workaround

[tv.deb...@googlemail.com]

On 17/02/2020 22:39, Agustin Martin wrote:

On Sat, Apr 21, 2018 at 02:16:26AM +0530, tv.deb...@googlemail.com wrote:

Since Digikam crashes on Mariadb database conversion I tried reverting to
older Digikam version, but that only gave me an empty view. So the database
is unusable with the previous Digikam versions.
Restoring a previous database version leads to the same result: failed
conversion, corruption that makes it unusable with previous Digikam version.

I downloaded the Digikam 5.9 appimage from digikam.org, which fails to
convert the database too, but doesn't crash. From it I was able to migrate
the Mariadb database to sqlite (conversion is very slow). Using the sqlite
was totally impractical due to sluggishness and high system load, so I
converted it back to "external Mysql" (Mariadb) with the exact same settings
in database configuration as the previous one 'user, db names...).
Again conversion is slow but about twice as fast as the other way round.

Important, once conversion back to Mariadb is complete, and Digikam settings
have been switched back to external Mysql database, Digikam scanned all
content but displayed an empty view. I needed to close and relaunch before I
could see the images.

I can now use Digikam 5.9 from Debian Unstable with the newly converted
Mariadb external database, I did not notice any data loss, tags are intact
too..

So problem solved for me, the double database conversion workaround is time
expensive but works.


Hi,

According to upstream bugtracking system

   https://bugs.kde.org/show_bug.cgi?id=393855

this seems fixed in digikam 6.0. Since Debian sid already has 6.4.0, I expect
this problem to be fixed in Debian.

Can we close this bug report?

Thanks for your contribution to Debian.

Regards,

Hi, as far as I am concerned this bug can be closed. All new upgrades 
proceeded without any problem regarding the database.
Currently using 6.4 from unstable with Mariadb (about 6 
photos/videos in the main library, + tags and faces) and having no issues.


Thank you for your time and your hard work.

Bug#951563: buster-pu: package postfix/3.4.8-0+10debu1

[Scott Kitterman]

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

This is the latest in the series of postfix 3.4 maintenance updates for
buster.  The version is in bullseye already and I have it running
locally without issue.  In addition to the upstream bugfixes, there are
two Debian packaging fixes: a correction to the lmtp man page redirect
and a sysv init update that fixes a regression in the last update (that
solved the problem that it was intended to solve, but caused problems
with multiple postfix instances).  This update has been tested by end
users to work in both configurations.  Neither fix has any regression
risk for users of Debian's default init system.  Details follow:

postfix (3.4.9-0+10debu1) buster; urgency=medium

  [Scott Kitterman]

  * Correct Debian's smtp (8) man page name in d/p/debian-man-name.diff for
lmtp.  Closes: #920356
  * Fix d/init.d running change so it works with multi-instance again - Thanks
to jaros...@thinline.cz for the fix.  Closes: #944922

  [Wietse Venema]

  * 3.4.9
- Bugfix (introduced: Postfix 3.1): support for
  smtp_dns_resolver_options was broken while adding support
  for negative DNS response caching in postscreen. Postfix
  was inadvertently changed to call res_query() instead of
  res_search(). Reported by Jaroslav Skarvada. File:
  dns/dns_lookup.c.

- Bugfix (introduced: Postfix 3.0): sanitize server responses
  before storing them in the verify database, to avoid Postfix
  warnings about malformed UTF8. File: verify/verify.c.

- Bugfix (introduced: Postfix 2.5): the Milter connect event
  macros were evaluated before the Milter connection itself
  had been negotiated. Problem reported by David Bürgin.
  Files: milter/milter.h, milter/milter.c, milter/milter8.c

Scott K
diff -Nru postfix-3.4.8/debian/changelog postfix-3.4.9/debian/changelog
--- postfix-3.4.8/debian/changelog  2020-01-15 09:05:50.0 -0500
+++ postfix-3.4.9/debian/changelog  2020-02-16 01:30:10.0 -0500
@@ -1,3 +1,33 @@
+postfix (3.4.9-0+10debu1) buster; urgency=medium
+
+  [Scott Kitterman]
+
+  * Correct Debian's smtp (8) man page name in d/p/debian-man-name.diff for
+lmtp.  Closes: #920356
+  * Fix d/init.d running change so it works with multi-instance again - Thanks
+to jaros...@thinline.cz for the fix.  Closes: #944922
+
+  [Wietse Venema]
+
+  * 3.4.9
+- Bugfix (introduced: Postfix 3.1): support for
+  smtp_dns_resolver_options was broken while adding support
+  for negative DNS response caching in postscreen. Postfix
+  was inadvertently changed to call res_query() instead of
+  res_search(). Reported by Jaroslav Skarvada. File:
+  dns/dns_lookup.c.
+
+- Bugfix (introduced: Postfix 3.0): sanitize server responses
+  before storing them in the verify database, to avoid Postfix
+  warnings about malformed UTF8. File: verify/verify.c.
+
+- Bugfix (introduced: Postfix 2.5): the Milter connect event
+  macros were evaluated before the Milter connection itself
+  had been negotiated. Problem reported by David Bürgin.
+  Files: milter/milter.h, milter/milter.c, milter/milter8.c
+
+ -- Scott Kitterman   Sun, 16 Feb 2020 01:30:10 -0500
+
 postfix (3.4.8-0+10debu1) buster; urgency=medium
 
   [Scott Kitterman]
diff -Nru postfix-3.4.8/debian/init.d postfix-3.4.9/debian/init.d
--- postfix-3.4.8/debian/init.d 2020-01-15 09:02:40.0 -0500
+++ postfix-3.4.9/debian/init.d 2020-02-16 01:28:07.0 -0500
@@ -35,12 +35,14 @@
 running() {
 INSTANCE="$1"
 if [ "X$INSTANCE" = X ]; then
-   POSTCONF="postconf"
+   POSTMULTI=""
 else
-   POSTCONF="postmulti -i $INSTANCE -x postconf"
+   POSTMULTI="postmulti -i $INSTANCE -x "
 fi
+POSTCONF="${POSTMULTI} postconf"
+
 daemon_directory=$($POSTCONF -hx daemon_directory 2>/dev/null || echo 
/usr/lib/postfix/sbin)
-if ! $daemon_directory/master -t 2>/dev/null ; then
+if ! ${POSTMULTI} $daemon_directory/master -t 2>/dev/null ; then
 echo y
 fi
 }
diff -Nru postfix-3.4.8/debian/patches/debian-man-name.diff 
postfix-3.4.9/debian/patches/debian-man-name.diff
--- postfix-3.4.8/debian/patches/debian-man-name.diff   2020-01-15 
09:04:20.0 -0500
+++ postfix-3.4.9/debian/patches/debian-man-name.diff   2020-02-16 
01:27:45.0 -0500
@@ -6,4 +6,4 @@
 +++ postfix-dev/man/man8/lmtp.82019-02-16 02:46:57.254292885 -0500
 @@ -1 +1 @@
 -.so man8/smtp.8
-+.so man8/smtp.8debian
++.so man8/smtp.8postfix
diff -Nru postfix-3.4.8/HISTORY postfix-3.4.9/HISTORY
--- postfix-3.4.8/HISTORY   2019-11-11 18:01:20.0 -0500
+++ postfix-3.4.9/HISTORY   2020-02-02 12:51:46.0 -0500
@@ -24319,3 +24319,23 @@
now, the parser skips object types that it does not know
about for usability, and logs a warning because ignoring
inputs is not kosher. 

Bug#951562: RM: validator.js -- ROM; Unmaintained

[Xavier Guimard]

Package: ftp.debian.org
Severity: normal

Hi,

validator.js is unmaintained (locked in unstable for a while). Dak
reports no dependency. Then I think it is safe to remove it from Debian.

Cheers,
Xavier

Bug#951561: lyx: Clicking on a cross-reference goes to the wrong page

[Kingsley G. Morse Jr.]

Package: lyx
Version: 2.3.4.2-2
Severity: normal

Dear Maintainer,

Thank you very much for maintaining lyx!

It has been a venerable and trustworthy tool for
many years!

The main reason I'm writing is I may have
discovered a small bug.

Basically, some cross-references lead to the wrong
pages.

I'll attach 3 files that I hope you can use to
duplicate the problem:

1.) A very short .lyx file named "bug.lyx".

2.) A PDF of it, created with the following menu
path

File->Export->PDF (ps2pdf)

3.) A screen shot of the mismatched page numbers I
see.

Maybe you'll see them too.

I expected

a.) hoovering the mouse's pointer over the page
number "2" in the red cross-reference box
to pop up a yellow tool tip that said

"Go to page 2."

But it says 

"Go to page 1."


b.) clicking on the page number "2" in the red
cross-reference box to advance to page 2.

But it stays on page 1.


Most cross-references in a bigger, real life, .lyx
file have correct page numbers.

I hope that helps,
Kingsley

-- System Information:
Debian Release: bullseye/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: i386 (i686)

Kernel: Linux 4.4.0-1-686-pae (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages lyx depends on:
ii  libc62.29-9
ii  libenchant-2-2   2.2.7+repack1-1
ii  libgcc-s110-20200211-1
ii  libmagic11:5.37-6
ii  libmythes-1.2-0  2:1.2.4-3+b1
ii  libqt5core5a 5.12.5+dfsg-8
ii  libqt5gui5   5.12.5+dfsg-8
ii  libqt5svg5   5.12.5-2
ii  libqt5widgets5   5.12.5+dfsg-8
ii  libstdc++6   9.2.1-24
ii  lyx-common   2.3.4.2-2
ii  xdg-utils1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1+b1

Versions of packages lyx recommends:
pn  dvipng   
ii  epdfview [pdf-viewer]0.1.8-3
ii  evince [pdf-viewer]  3.32.0-3
ii  fonts-lyx2.1.4-2
ii  ghostscript  9.50~dfsg-5
ii  gv [pdf-viewer]  1:3.7.4-1
ii  imagemagick  8:6.9.10.23+dfsg-2.1
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1
ii  mupdf [pdf-viewer]   1.15.0+ds1-1
ii  okular [pdf-viewer]  4:17.12.2-2.2
ii  poppler-utils0.71.0-5+b1
ii  preview-latex-style  11.88-1.1
ii  psutils  1.17.dfsg-2
ii  qpdfview [pdf-viewer]0.4.18-1+b1
ii  texlive-fonts-recommended2019.20200210-1
ii  texlive-latex-extra  2019.202000210-1
ii  texlive-latex-recommended2019.20200210-1
ii  texlive-plain-generic2019.202000210-1
pn  texlive-science  
ii  xpdf [pdf-viewer]3.03-17+b1

Versions of packages lyx suggests:
ii  chktex  1.7.4-1
pn  gnuhtml2latex   
ii  groff   1.22.4-3
ii  inkscape0.92.2-1+b1
pn  latex2rtf   
ii  librsvg2-bin2.46.4-1
ii  libtiff-tools   4.0.10+git190818-1
pn  linuxdoc-tools  
pn  noweb   
ii  rcs 5.9.4-3
pn  sgmltools-lite  
ii  texlive-plain-generic [tex4ht]  2019.202000210-1
pn  texlive-xetex   
pn  writer2latex
pn  wv  

-- debconf information:
  lyx/upgrade-notice:
#LyX 2.3 created this file. For more info see http://www.lyx.org/
\lyxformat 544
\begin_document
\begin_header
\save_transient_properties true
\origin unavailable
\textclass article
\use_default_options false
\maintain_unincluded_children false
\language american
\language_package default
\inputencoding default
\fontencoding global
\font_roman "default" "default"
\font_sans "default" "default"
\font_typewriter "default" "default"
\font_math "auto" "auto"
\font_default_family default
\use_non_tex_fonts false
\font_sc false
\font_osf false
\font_sf_scale 100 100
\font_tt_scale 100 100
\use_microtype false
\use_dash_ligatures true
\graphics dvips
\default_output_format default
\output_sync 0
\bibtex_command default
\index_command default
\paperfontsize 10
\spacing single
\use_hyperref true
\pdf_bookmarks true
\pdf_bookmarksnumbered false
\pdf_bookmarksopen false
\pdf_bookmarksopenlevel 1
\pdf_breaklinks false
\pdf_pdfborder false
\pdf_colorlinks false
\pdf_backref false
\pdf_pdfusetitle true
\papersize default
\use_geometry true
\use_package amsmath 1
\use_package amssymb 1
\use_package cancel 1
\use_package esint 0
\use_package mathdots 1
\use_package mathtools 1
\use_package mhchem 1
\use_package stackrel 1
\use_package stmaryrd 1
\use_package undertilde 1
\cite_engine basic
\cite_engine_type default
\biblio_style plain

Bug#951559: pinot FTCBFS: uses the build architecture pkg-config

[Helmut Grohne]

Source: pinot
Version: 1.10-1.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

pinot fails to cross build from source, because it fails finding dbus
libraries using the build architecture pkg-config. This is due to using
AC_PATH_PROG for discovering pkg-config. Usually, one should be using
the PKG_PROG_PKG_CONFIG macro here. Failing that, use AC_PATH_TOOL. The
configure.in also hard codes the build architecture pkg-config instead
of using the discovered one in two occasions. The attached patch fixes
that. After applying it, pinot fails the "if gio can sniff png" check,
because it cannot be performed during cross building. Would it be ok for
you to pass either --enable-gio or --disable-gio to configure to remove
the need for running the test?

In any case, please consider applying the attached patch to fix the
issue with calling pkg-config and close this bug when doing so.

Helmut
--- pinot-1.10.orig/configure.in
+++ pinot-1.10/configure.in
@@ -65,7 +65,7 @@
 
 AC_LANG_CPLUSPLUS
 
-AC_PATH_PROG(PKG_CONFIG, pkg-config, no)
+PKG_PROG_PKG_CONFIG
 AC_PATH_PROG(DESKTOP_INSTALL, desktop-file-install, no)
 
 dnl DEBUG mode
@@ -112,7 +112,7 @@
 AM_CONDITIONAL(HAVE_DBUS, false)
 if test "x$enable_dbus" = "xyes"; then
PKG_CHECK_MODULES(DBUS, dbus-glib-1)
-   DBUS_NUM_VERSION=`pkg-config --modversion dbus-1 | awk 'BEGIN { FS = "."; } { printf "%d", ($1 * 1000 + $2) * 1000 + $3;}'`
+   DBUS_NUM_VERSION=`$PKG_CONFIG --modversion dbus-1 | awk 'BEGIN { FS = "."; } { printf "%d", ($1 * 1000 + $2) * 1000 + $3;}'`
AC_DEFINE_UNQUOTED(DBUS_NUM_VERSION,$DBUS_NUM_VERSION, [DBus version number])
AM_CONDITIONAL(HAVE_DBUS, true)
 fi
@@ -414,7 +414,7 @@
 AC_SUBST(MISC_LIBS)
 AC_CHECK_HEADERS([sys/vfs.h sys/statfs.h sys/mount.h sys/statvfs.h attr/xattr.h dlfcn.h regex.h fnmatch.h pwd.h])
 PKG_CHECK_MODULES(MIMEINFO, shared-mime-info )
-SHARED_MIME_INFO_PREFIX=`pkg-config --variable=prefix shared-mime-info`
+SHARED_MIME_INFO_PREFIX=`$PKG_CONFIG --variable=prefix shared-mime-info`
 AC_SUBST(SHARED_MIME_INFO_PREFIX)
 AC_DEFINE_UNQUOTED(SHARED_MIME_INFO_PREFIX,"$SHARED_MIME_INFO_PREFIX",
 [the shared-mime-info prefix])

Bug#951560: mark mandoc Multi-Arch: foreign

[Helmut Grohne]

Package: mandoc
Version: 1.14.4-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:libfido2

libfido2 fails to cross build from source, because it fails running
mandoc with an Exec format error. Usually, this indicates that mandoc
should be marked Multi-Arch: foreign. In this case, such a marking is
correct, because mandoc exclusively deals with architecture-independent
file formats. As such its behaviour does not depend on the architecture
it is being run on. Please consider applying the attached patch.

Helmut
diff --minimal -Nru mdocml-1.14.4/debian/changelog 
mdocml-1.14.4/debian/changelog
--- mdocml-1.14.4/debian/changelog  2018-08-09 20:55:23.0 +0200
+++ mdocml-1.14.4/debian/changelog  2020-02-18 06:11:46.0 +0100
@@ -1,3 +1,10 @@
+mdocml (1.14.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Mark mandoc Multi-Arch: foreign. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 18 Feb 2020 06:11:46 +0100
+
 mdocml (1.14.4-1) unstable; urgency=medium
 
   * New upstream version 1.14.4
diff --minimal -Nru mdocml-1.14.4/debian/control mdocml-1.14.4/debian/control
--- mdocml-1.14.4/debian/control2018-08-09 20:55:23.0 +0200
+++ mdocml-1.14.4/debian/control2020-02-18 06:11:45.0 +0100
@@ -11,6 +11,7 @@
 
 Package: mandoc
 Architecture: any
+Multi-Arch: foreign
 Depends: ${shlibs:Depends}, ${misc:Depends}
 Description: BSD manpage compiler toolset
  mandoc is a suite of tools compiling mdoc, the roff macro language of choice

Bug#951558: lr FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: lr
Version: 1.5.1-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

lr fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
lr cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru lr-1.5.1/debian/changelog lr-1.5.1/debian/changelog
--- lr-1.5.1/debian/changelog   2020-02-15 23:12:10.0 +0100
+++ lr-1.5.1/debian/changelog   2020-02-18 05:59:32.0 +0100
@@ -1,3 +1,10 @@
+lr (1.5.1-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 18 Feb 2020 05:59:32 +0100
+
 lr (1.5.1-2) unstable; urgency=medium
 
   * debian/rules
diff --minimal -Nru lr-1.5.1/debian/rules lr-1.5.1/debian/rules
--- lr-1.5.1/debian/rules   2020-02-15 23:12:10.0 +0100
+++ lr-1.5.1/debian/rules   2020-02-18 05:59:31.0 +0100
@@ -6,7 +6,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) $(shell dpkg-buildflags --export=configure)
+   dh_auto_build -- $(shell dpkg-buildflags --export=configure)
 
 override_dh_auto_install:
dh_auto_install -- PREFIX=/usr

Bug#951557: RFP: commento -- fast, bloat-free comments platform

[Antoine Beaupre]

Package: wnpp
Severity: wishlist

* Package name: commento
  Version : 1.7.0
  Upstream Author : Adhityaa Chandrasekar
* URL : https://commento.io/
* License : MIT/Expat
  Programming Lang: Go, Javascript
  Description : fast, bloat-free comments platform

Commento is a platform that you can embed in your website to allow
your readers to add comments. It's reasonably fast
lightweight. Supports markdown, import from Disqus, voting, automated
spam detection, moderation tools, sticky comments, thread locking,
OAuth login, single sign-on, and email notifications.



The other package in Debian similar to this is Isso, written in
Python. Isso is heavier than Commento (40KB vs 11KB) and slightly less
featureful. Commento also supports a PostgreSQL while Isso uses
sqlite.

I am not using it yet, but I'm considering it to replace the comments
system on my blog.

Bug#951440: [Freedombox-pkg-team] Bug#951440: plinth: [INTL:ru] Russian debconf templates translation

[Sunil Mohan Adapa]

tags -1 + pending
thanks

Thank you for the patch. I have applied it on master.

Also, the Russian translation for FreedomBox web interface could use
some help, if you are interested[1].

https://hosted.weblate.org/projects/freedombox/plinth/ru/

-- 
Sunil

On 16/02/20 7:59 am, Lev Lamberov wrote:
> Source: plinth
> Severity: wishlist
> Tags: l10n patch
> 
> Dear Maintainer,
> 
> please, find attached the debconf templates translation into Russian.
> 
> Cheers!
> Lev Lamberov
> 
> 
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers testing
>   APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
> 
> Kernel: Linux 5.4.0-3-amd64 (SMP w/4 CPU cores)
> Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
> TAINT_UNSIGNED_MODULE
> Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), 
> LANGUAGE=ru_RU.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
> 
> 
> ___
> Freedombox-pkg-team mailing list
> freedombox-pkg-t...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/freedombox-pkg-team
> 



signature.asc
Description: OpenPGP digital signature

Bug#951556: RFP: git-mount -- Mount a specific revision of a git repo as FUSE filesystem

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: git-mount
  Version : 0.0.01
  Upstream Author : George Shank
* URL : https://github.com/taterbase/git-mount
* License : MIT
  Programming Lang: Go
  Description : Mount a specific revision of a git repo as FUSE filesystem

git-mount let's you mount your repo as a filesystem based on a revision.
If only one argument is passed in git-mount treats that argument as a treeish. 
Based on your current location in the repo it will mount all files and folders 
from that level and deeper. git-mount will only ever descend files, never 
ascend, so if you are in folder foo and folder foo is the top level of th repo 
the whole repo will be mounted. If you go into foo/bar and call git-mount 
{treeish} then only bar and its descendants will be mounted.

Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts

[Ryutaroh Matsumoto]

> luahbtex should behave better, right, if the font is loaded with the
> harf renderer selected?

Ah, you seems right. But, when I added [RawFeature={mode=harf}] to
the example given at the beginning of this report and processed the file
with lualatex-dev in TeXLive 2019 of February 14, the memory comsumption
was again mere 2GB... (I did it on last Saturday).

{mode=harf} can possibly behave better as we do not observe the huge
memory comsumption in xelatex, but I have personally not digged into
that possiblitty as the lualatex-ja developer recommends not to use
{mode=harf} with lualatex-ja as

\paragraph{Using \LuaTeX-ja with LuaHB\TeX}
Using \LuaTeX-ja with LuaHB\TeX (\LuaTeX\ integrated with
\href{https://github.com/harfbuzz/harfbuzz}{HarfBuzz}) is not well tested.
Maybe documents can typeset without an error,
but with unwanted results (especially, vertical typesetting and \cs{CID}).
Especially,
\emph{We don't recommend defining a Japanese font with HarfBuzz},
by specifying \texttt{Renderer=Harfbuzz}~etc.\ (\Pkg{fontspec}) or~{mode=harf} 
(otherwise).

at 
https://ja.osdn.net/projects/luatex-ja/scm/git/luatexja/blobs/master/doc/luatexja.dtx

Best regards, Ryutaroh

Bug#951555: RFP: gitfs -- Version controlled file system

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: gitfs
  Version : 0.5.3
  Upstream Author : Vlad Temian 
* URL : https://www.presslabs.com/code/gitfs/
* License : Apache-2.0
  Programming Lang: Python
  Description : Version controlled file system

gitfs is a FUSE file system that fully integrates with git. You can mount a 
remote repository's branch locally, and any subsequent changes made to the 
files will be automatically committed to the remote.

gitfs was developed by the awesome engineering team at Presslabs, a Managed 
WordPress Hosting provider.
What's its purpose?

gitfs was designed to bring the full powers of git to everyone, no matter how 
little they know about versioning. A user can mount any repository and all 
their changes will be automatically converted into commits. gitfs will also 
expose the history of the branch you're currently working on by simulating 
snapshots of every commit.

gitfs is useful in places where you want to keep track of all your files, but 
at the same time you don't have the possibility of organizing everything into 
commits yourself. A FUSE filesystem for git repositories, with local cache.

Features

Automatically commits changes: create, delete, update files and their 
metadata
Browse through working index and commit history
Merges with upstream by automatically accepting local changes
Caching commits reduces the memory footprint and speeds up navigation
Reduces the number of pushes by batching commits

Bug#951497: rumur: building from sources makes machine un-usable or OOM/kills kernel

[Matthew Fernandez]

> On Feb 17, 2020, at 13:54, Anatoly Pugachev  wrote:
> 
> On Mon, Feb 17, 2020 at 11:12 PM Matthew Fernandez
>  wrote:
>> 
>> Yikes, sorry.
>> 
>> The test suite for this package auto-detects the number of CPUs and 
>> parallelises across all of them. This is not very well behaved when calling 
>> it from the outer build system, as it doesn’t pay attention to any -j flag 
>> you’ve passed there. To compound the situation, some of the individual test 
>> cases themselves are also multithreaded.
>> 
>> I think the simplest solution is to force the test suite to always run 
>> single-threaded when called via ctest. Can I close this bug by making this 
>> change when packaging the next upstream release? Or do I also need to upload 
>> new packages for the existing versions in Debian?
> 
> 
> Matthew,
> 
> being "Version: 2020.01.27-1" is available in the repository , is it
> possible to fix test suite to run single-threaded (or maybe -j2) via
> debian package patch and bump version to "2020.01.27-2" and upload?
> 
> Thanks.

Yes, good point, fair enough. I was midway through cutting a new upstream 
release when the first report arrived, so I’ll make the fix there and package 
that, and then backport it to a 2020.01.27-2 upload.

The new test suite responsible for this hammering was actually added several 
upstream releases back, but it looks like 2020.01.27-1 is the only package to 
make it through to unstable so far, so I assume I don’t need to backport this 
change to -2 uploads for older packages that only ever existed in testing.

Bug#951554: RFP: latte-integrale -- Lattice point Enumeration is a computer software dedicated to the problems of counting lattice points and integration inside convex polytopes.

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: latte-integrale
  Version : 1.7.5
  Upstream Author : Matthias Köppe 
* URL : https://www.math.ucdavis.edu/~latte/
* License : GPL
  Programming Lang: C++
  Description : Lattice point Enumeration is a computer software dedicated 
to the problems of counting lattice points and integration inside convex 
polytopes.

This is LattE integrale, the official new version of LattE.

In addition to the traditional LattE function of counting lattice
points in polytopes by variants of Barvinok's algorithm, LattE
integrale can also compute volumes and integrate polynomial functions
over polytopes.  It supersedes LattE macchiato, an improved version of 
LattE.

Bug#951553: RFP: qepcad -- Quantifier Elimination by Partial Cylindrical Algebraic Decomposition

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: qepcad
  Version : B 1.72
  Upstream Author : Christopher W Brown 
* URL : https://www.usna.edu/Users/cs/wcbrown/qepcad/B/QEPCAD.html
* License : BSD, MIT
  Programming Lang: C
  Description : Quantifier Elimination by Partial Cylindrical Algebraic 
Decomposition

QEPCAD is an implementation of quantifier elimination by partial cylindrical 
algebraic decomposition due orginally to Hoon Hong, and subsequently added on 
to by many others. It is an interactive command-line program written in C/C++, 
and based on the SACLIB library. Presented here is QEPCAD B version 1.x, the 
"B" designating a substantial departure from the original QEPCAD and 
distinguishing it from any development of the original that may proceed in a 
different direction. QEPCAD and the SACLIB library are the result of a program 
of research by George Collins and his PhD students that has spanned several 
decades ... and continues still!

I extended and improved QEPCAD for several years. Improvements that didn't 
involve changes to the way the program interacted with the user I'd just go 
ahead and make. However, changes that affected the interaction of QEPCAD and 
the user, or changes that added new features were "tacked on" to the program, 
requiring the user to know about extra commands. Moreover, there was no 
cannonical source for QEPCAD distribution or documentation, and no internet 
accessible source at all. This branch of QEPCAD, QEPCAD "B", was introduced to 
address those problems - to make QEPCAD easily accessable through the internet, 
to provide good documentation, and to incorporate many improvements and 
extensions in a way that makes them most accessible to the user. 

Bug#951552: RFP: aldor -- The Aldor Programming Language

[Alessandro Barbieri]

Package: wnpp
Severity: wishlist

* Package name: aldor
  Version : 1.2.0
  Upstream Author : Pippijn van Steenhoven 
* URL : http://pippijn.github.io/aldor/
* License : Apache-2.0
  Programming Lang: C
  Description : The Aldor Programming Language

Compiler and libraries for the Aldor Programming Language
The Aldor Programming Language is the successor of A# as the extension
language of the Axiom computer algebra system.
The Aldor language combines imperative, functional, and object-oriented
features. It has an elaborate dependent type system, allowing types to be used
as first-class values. Aldor's syntax is heavily influenced by Pascal, but it
is optionally indentation-sensitive, like Python. In its current
implementation, it is compiled, but an interactive listener is provided.

Bug#934200: gbp import-orig is broken with multiple source tarballs

[Sandro Tosi]

> this is still happening: i'm trying to upgrade dblatex to the latest
> upstream release and the source package has 2 upstream tarballs.
>
> `gbp import-orig --uscan` imports only the "main" tarball but not the
> additional component (`examples`,
> https://salsa.debian.org/debian/dblatex/tree/pristine-tar) and `gbp
> import-orig ../../dblatex*orig*` complains multiple files are
> specified on the command-line, and i did not find a combination of
> commands to import 2 tarballs one after the other.
>
> I'm not sure how frequent is the case of multiple tarballs, but it
> would still be extra-useful if this bug could be addressed soon.

nevermind (i guess?), upon further reading i found out i need to use
the `--component` cli option; maybe an example in the doc/manpage
would be useful? thanks for maintaining gbp!

Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts

[Norbert Preining]

> the memory comsumption was improved from 6GB to mere 2GB!

a "mere 2GB" ;-)

luahbtex should behave better, right, if the font is loaded with the
harf renderer selected?

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#851291: Fails to import xz-utils: pristine-xz failed to reproduce build of /tmp/xz-utils_5.2.2.orig.tar.xz

[Steven Robbins]

On Fri, 13 Jan 2017 18:54:52 +0100 Guido =?iso-8859-1?Q?G=FCnther?= 
 wrote:
> Package: pristine-tar
> Version: 1.37
> Severity: normal
> 
> Hi,
> Importing xz-utils fails 

Importing new upstream of Digikam failed in the same manner:

steve@riemann:~/Packages/digikam/salsa$ gbp import-orig --pristine-tar --
upstream-branch=upstream-experimental --debian-branch=experimental ~/
digikam-7.0.0-beta2.tar.xz
What is the upstream version? [7.0.0-beta2] 
gbp:info: Importing '/home/steve/digikam-7.0.0-beta2.tar.xz' to branch 
'upstream-experimental'...
gbp:info: Source package is digikam
gbp:info: Upstream version is 7.0.0-beta2
gbp:error: Import of ../digikam_7.0.0-beta2.orig.tar.xz failed: Couldn't 
commit to 'pristine-tar' with upstream 
'1f34561014cb40737a8db9e7584a10da6f5c9265': pristine-xz failed to reproduce 
build of ../digikam_7.0.0-beta2.orig.tar.xz
(Please file a bug report.)
pristine-tar: failed to generate delta
gbp:error: Error detected, Will roll back changes.
gbp:info: Rolling back branch upstream-experimental by resetting it to 
3f62a39ecd3bf98407ba58e152aa60180950aabb
gbp:info: Rolling back branch pristine-tar by resetting it to 
581613c2045eb2398e1bcceb5637585044ace09f
gbp:error: Rolled back changes after import error.


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

Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts

[Ryutaroh Matsumoto]

> Your best bet is bringing this up to the luatex-dev mailing list, not
> here in Debian, because we will surely not patch anything of that
> dimension.

I agree. Actually, this Debian bug already has  "upstream" tag and
marked "forwarded" to https://github.com/u-fischer/luaotfload/issues/49

I think  this is recognized by the upstream.

If my memory is correct, this comes from the underlying ConTeXt
and it was also discussed in the ConTeXt mailing list. Because of that,
the memory comsumption was improved from 6GB to mere 2GB!

Best regards, Ryutaroh

Bug#951550: procps: document /usr/lib/sysctl.d/

[Christoph Anton Mitterer]

On Tue, 2020-02-18 at 12:58 +1100, Craig Small wrote:
> It's mentioned in the sysctl man page under the --system option.

Hmm but isn't that quite "hidden"...?

sysctl(8):
FILES
   /proc/sys
   /etc/sysctl.conf
=> doesn't even mentioned /etc/sysctl.d/


sysctl.conf(5)/sysctl.d(5)
=> do mention all files properly

/etc/sysctl.conf:
# See /etc/sysctl.d/ for additional system variables.
# See sysctl.conf (5) for information.
=> kinda implies it's "only" /etc/sysctl.d/


/etc/sysctl.d/README.sysctl
=> same here... the directory contains the symlink to /etc/sysctl.conf
... so unless the user will read either of sysctl.conf(5)/sysctl.d(5)
he may not notice that there are other locations.


Cheers,
Chris.

Bug#915797: /etc/sysctl.d/protect-links.conf should be in /usr/lib/sysctl.d/

[Christoph Anton Mitterer]

Hey.

I strongly disagree that this should be in /usr, as it's configuration.

The fashion of recent years to place configuration in /usr is IMHO
quite questionable:

/usr is generally nothing that people are expected to monitor so if the
distro decides to change a previous (distro-)default it will be
unnoticed by users (in contrast to /etc).

This can have quite bad effects if the users depends on such (previous)
defaults.


I think having defaults stored in /usr is kinda "ok" if these are
upstream defaults (an upstream could also just change defaults in the
sources without the enduser noticing it).. but I think distros
shouldn't do so - especially if the changes don't match the default
upstream behaviour.


Cheers,
Chris.

Bug#951550: procps: document /usr/lib/sysctl.d/

[Craig Small]

It's mentioned in the sysctl man page under the --system option.

   --system
  Load settings from all system configuration files. Files are
read from directories in the following list in given order from top to
bottom.  Once a file of a given  filename  is  loaded,  any
  file of the same name in subsequent directories is ignored.
  /run/sysctl.d/*.conf
  /etc/sysctl.d/*.conf
  /usr/local/lib/sysctl.d/*.conf
  /usr/lib/sysctl.d/*.conf
  /lib/sysctl.d/*.conf
  /etc/sysctl.conf

Bug#951507: wine: please fix arm64 build failure with some gcc versions

[Michael Gilbert]

control: retitle -1 wine: fails to build with clang 9 on arm64

On Mon, Feb 17, 2020 at 10:54 AM Gianfranco Costamagna wrote:
> Hello, looks like wine is still failing on Ubuntu arm64, probably because of 
> new gcc or new glibc, or a combo of them both...

The difference is that clang 9 is ubuntu's default and debian's
default is clang 8.

Best wishes,
Mike

Bug#951398: pax.jar FTBFS: issue introduction

[Norbert Preining]

found 951398 2019.20191208-1
thanks

On Mon, 17 Feb 2020, John Scott wrote:
> pax.jar seems to exist in version 2019.20191208-1 as well. If someone could 
> affirm this is not an issue introduced with the new upload, could one set 
> this 
> bug as being found in 2019.20191208-1? This would enable the transition to 
> testing.

Done so, but transition is blocked by a bogus autopkgtest of pyxplot, I
have already reported a bug for that, without response.

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951280: fixed in ncbi-blast+ 2.9.0-4

[Aaron M. Ucko]

That's a fair request.  From a technical perspective, it should be
straightforward (the same change should work there), but I'll need to
get official approval from the Release Team.  There's also a version of
ncbi-blast+ in buster-backports that I should be able to fix more
readily, but I can understand if you'd rather leave backports alone.

Thanks for asking, and sorry you ran into trouble here.

-- Aaron

Patrice Duroux  writes:

> Hi,
>
> Thanks for the work.
> But is there any plan to solve it for ncbi-blast+ in Buster for which the bug
> report was addressed initially?
> Do I have to mix Buster / Sid on my system?
>
> Thanks,
> Patrice
>
> On Mon, 17 Feb 2020 01:50:53 + Debian FTP Masters <
> ftpmas...@ftp-master.debian.org> wrote:
>> Source: ncbi-blast+
>> Source-Version: 2.9.0-4
>> Done: u...@debian.org (Aaron M. Ucko)
>> 
>> We believe that the bug you reported is fixed in the latest version of
>> ncbi-blast+, which is due to be installed in the Debian FTP archive.
>> 
>> A summary of the changes between this version and the previous one is
>> attached.
>> 
>> Thank you for reporting the bug, which will now be closed.  If you
>> have further comments please address them to 951...@bugs.debian.org,
>> and the maintainer will reopen the bug report if appropriate.
>> 
>> Debian distribution maintenance software
>> pp.
>> Aaron M. Ucko  (supplier of updated ncbi-blast+ package)
>> 
>> (This message was generated automatically at their request; if you
>> believe that there is a problem with it please contact the archive
>> administrators by mailing ftpmas...@ftp-master.debian.org)
>> 
>> 
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>> 
>> Format: 1.8
>> Date: Sun, 16 Feb 2020 20:16:33 -0500
>> Source: ncbi-blast+
>> Architecture: source
>> Version: 2.9.0-4
>> Distribution: unstable
>> Urgency: high
>> Maintainer: Debian Med Packaging Team <
> debian-med-packag...@lists.alioth.debian.org>
>> Changed-By: Aaron M. Ucko 
>> Closes: 951280
>> Changes:
>>  ncbi-blast+ (2.9.0-4) unstable; urgency=high
>>  .
>>* debian/control: Standards-Version: 4.5.0 (already compliant).
>>* debian/rules: DEB_CONFIGURE_COMMON_FLAGS += --without-sse42.
>>  (Closes: #951280.)
>> Checksums-Sha1:
>>  7427fdad6764091bcad72a436a1e8122ba980844 2297 ncbi-blast+_2.9.0-4.dsc
>>  54c7ff368b62216dc64943e3f9173690338e8001 29112 ncbi-blast+_2.9.0-
> 4.debian.tar.xz
>>  86c672c0d92dcd99fe73faaf13d1a355d152f84c 8853 ncbi-blast+_2.9.0-
> 4_source.buildinfo
>> Checksums-Sha256:
>>  26b9aa389bc41b8b570b3883374828f085244f66615ffa3ced38f64033dcfa04 2297 ncbi-
> blast+_2.9.0-4.dsc
>>  dc79f19dea2d581ba12957d7aa70d20accd83e50eacdc484e5d668f4e5c0c7b0 29112 ncbi-
> blast+_2.9.0-4.debian.tar.xz
>>  e2ea23323bad1095a5902aa169ba477fa2b9d3908b0d4bb51fd5faa296c2bbf4 8853 ncbi-
> blast+_2.9.0-4_source.buildinfo
>> Files:
>>  4db70f8ccc3c830edb570aef31da120f 2297 science optional ncbi-blast+_2.9.0-
> 4.dsc
>>  216a8b45f29c2419924a6f214bef27f0 29112 science optional ncbi-blast+_2.9.0-
> 4.debian.tar.xz
>>  5cf07deee0d0c1fa2f82b28099550fb8 8853 science optional ncbi-blast+_2.9.0-
> 4_source.buildinfo
>> 
>> -BEGIN PGP SIGNATURE-
>> 
>> iQIzBAEBCAAdFiEEfDq5z9IwvTDdAJxZHnCRsfFKZKIFAl5J6eoACgkQHnCRsfFK
>> ZKJ++A/+Ppu1Y69CUK3za3XrrgT+nHT3oZeinrdaysAXJNAITp3snwKJm6PgTdaM
>> 1YakzLrZtZ2pWvQ2qRMcvAnyGbM4mg6+7uia4SIRN+OwBji3nFX4NpRfVXQyQQ0N

Bug#951551: ITP: httpx -- fully featured HTTP client, with sync and async APIs, and support for both HTTP/1.1 and HTTP/2

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: httpx
  Version : 0.11.1
  Upstream Author : Encode OSS
* URL : https://www.python-httpx.org/
* License : BSD
  Programming Lang: Python
  Description : fully featured HTTP client, with sync and async APIs, and 
support for both HTTP/1.1 and HTTP/2

HTTPX is a fully featured HTTP client for Python 3, which provides sync and
async APIs, and support for both HTTP/1.1 and HTTP/2.

HTTPX builds on the well-established usability of `requests`, and gives you:

* A broadly `requests`-compatible API
* Standard synchronous interface, but with async support if you need it
* HTTP/1.1 and HTTP/2 support
* Ability to make requests directly to WSGI applications or ASGI applications.
* Strict timeouts everywhere.
* Fully type annotated.
* 99% test coverage.

Plus all the standard features of `requests`:

* International Domains and URLs
* Keep-Alive & Connection Pooling
* Sessions with Cookie Persistence
* Browser-style SSL Verification
* Basic/Digest Authentication
* Elegant Key/Value Cookies
* Automatic Decompression
* Automatic Content Decoding
* Unicode Response Bodies
* Multipart File Uploads
* HTTP(S) Proxy Support
* Connection Timeouts
* Streaming Downloads
* .netrc Support
* Chunked Requests

Bug#914859: sysctl.conf: include (and set?) the upcoming protected_fifos and protected_regular options

[Craig Small]

The settings are 1 not 2 to be in line with other distributions.

On Tue, 18 Feb. 2020, 12:39 pm Christoph Anton Mitterer, <
cales...@scientia.net> wrote:

> btw:
>
> What's the reason to not also set:
> fs.protected_fifos = 2
>
> ?
>
> Cheers,
> Chris.
>

Bug#951550: procps: document /usr/lib/sysctl.d/

[Christoph Anton Mitterer]

Package: procps
Version: 2:3.3.16-1+b1
Severity: normal


Hi.

It seems that /usr/lib/sysctl.d/ is docuemnted nowhere, or did I miss that?

I think it should be mentioned in:
- the manpage
- /etc/sysctl.conf
- /etc/sysctl.d/README.sysctl

Maybe also with information in which order these files are parsed.

Thanks,
Chris.

Bug#914859: sysctl.conf: include (and set?) the upcoming protected_fifos and protected_regular options

[Christoph Anton Mitterer]

btw:

What's the reason to not also set:
fs.protected_fifos = 2

?

Cheers,
Chris.

Bug#951398: pax.jar FTBFS: issue introduction

[John Scott]

Hello,

pax.jar seems to exist in version 2019.20191208-1 as well. If someone could 
affirm this is not an issue introduced with the new upload, could one set this 
bug as being found in 2019.20191208-1? This would enable the transition to 
testing.

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

Bug#949312: txsocksx: should this package be removed?

[Scott Kitterman]

On Monday, February 17, 2020 5:58:14 PM EST Adrian Bunk wrote:
> On Mon, Feb 17, 2020 at 12:05:59PM -0500, Scott Kitterman wrote:
> > Here's a thought:
> > 
> > Given the concern Adrian has expressed relative to tahoe-lafs, how about
> > if
> > someone uploads the relevant packages to experimental:
> > 
> > python-txsocksx -> foolscap -> tahoe-lafs
> > 
> > Then the Unstable rm can go forward, but in the event python2 stays in the
> > bullseye release, it's easy to re-introduce.  It wouldn't even need to go
> > through New.  You'd probably want to upload any other depends that might
> > drop python2 support as well with a sufficiently high version that they
> > won't get removed due to NVIU.
> 
> How would this bring any advantage?
> 
> Sandro seems to be working mainly on testing, and RC bugs already exist
> that prevent re-migration to testing.

It would allow for packages to remain in the archive without complicating 
other removal efforts.  Since he is working from Testing (and to a lesser 
extent Unstable), if the package is in Experimental, it'd be out of the way 
and unlikely to be futzed with.
> 
> BTW: The Christmas Eve removal in #937449 a few days after removal
>  from testing and despite maintainer objection might be a good
>  example how early removal from unstable makes people not happy.

We're certainly not perfect.  In cases where a package was removed when it 
shouldn't be, people can ping me on IRC in #debian-ftp and I'll be glad to 
give it a priority look to get it back in the archive.

Scott K

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

Bug#888705: abseil-cpp packaging

[Benjamin Barenblat]

On Sunday, February 16, 2020, at 10:48 PM +0100, László Böszörményi (GCS) wrote:
> In my reading abseil is _not_ guaranteed to have ABI compatibility at
> all times. That's why it meant to be a static library collection only.
> Forcing it to build shared libraries and have other packages than
> libabseil-cpp-dev is no sense I think.

Abseil does reserve the right to break ABI at any time, and I can’t
speak to their future plans. But I think ABI breakages are unlikely to
occur in practice within an LTS release. If we wait and then package an
LTS release, I it’ll be completely reasonable to ship .so’s and .a’s.

Relatedly, I think we should only package LTS Abseil for Debian. If
someone finds a CVE in Abseil, the Abseil team are going to want to
backport the fix to LTS releases; they’re not going to want to backport
it everywhere else.

> @Benjamin: may you ask its developers to use the system gtest libraries
> if only ABSL_RUN_TESTS set to ON?

Absolutely. I’ll bring it up with them at work tomorrow (today was a US
holiday).

Bug#914859: sysctl.conf: include (and set?) the upcoming protected_fifos and protected_regular options

[Christoph Anton Mitterer]

Hey Craig.

Thanks for your efforts into clarifying this :-)

I guess if someone rund into troubles, he'll tell soonish ;-)


Cheers,
Chris.

Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts

[Norbert Preining]

Hi

> lualatex in TeXlive 2020, so I bet this #930292 will remain the same,

Yes, probably.

> I wonder if this issue (huge memory comsumption with a huge number
> (e.g. 65535) of glyphs) can be fixed...

Your best bet is bringing this up to the luatex-dev mailing list, not
here in Debian, because we will surely not patch anything of that
dimension.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#950127: pyside2 fails all autopkg tests

[Steve Langasek]

Package: pyside2
Followup-For: Bug #950127
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu focal ubuntu-patch

These tests fail because the test dependencies are always buggy when there
is more than one supported version of python in the archive; the tests
invoke py3versions to enumerate the versions of python to test against, but
there is no test dependency on python3-all, so no version of python other
than the default python3 is guaranteed to be installed.

The attached patch should fix this; I've uploaded this change to Ubuntu. 
Please consider including it in Debian as well.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru pyside2-5.14.0/debian/control pyside2-5.14.0/debian/control
--- pyside2-5.14.0/debian/control   2020-02-10 16:13:30.0 -0800
+++ pyside2-5.14.0/debian/control   2020-02-17 16:43:21.0 -0800
@@ -1,8 +1,7 @@
 Source: pyside2
 Section: python
 Priority: optional
-Maintainer: Ubuntu Developers 
-XSBC-Original-Maintainer: Debian Qt/KDE Maintainers 

+Maintainer: Debian Qt/KDE Maintainers 
 Uploaders: Sophie Brun ,
Raphaël Hertzog ,
   Sebastien Delafond 
diff -Nru pyside2-5.14.0/debian/tests/control 
pyside2-5.14.0/debian/tests/control
--- pyside2-5.14.0/debian/tests/control 2020-02-10 16:13:08.0 -0800
+++ pyside2-5.14.0/debian/tests/control 2020-02-17 16:43:21.0 -0800
@@ -1,156 +1,156 @@
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtcore 
PySide2.QtCore
-Depends: python3-pyside2.qtcore
+Depends: python3-pyside2.qtcore, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtwidgets 
PySide2.QtWidgets
-Depends: python3-pyside2.qtwidgets
+Depends: python3-pyside2.qtwidgets, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qt3drender 
PySide2.Qt3DRender
-Depends: python3-pyside2.qt3drender
+Depends: python3-pyside2.qt3drender, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtquick 
PySide2.QtQuick
-Depends: python3-pyside2.qtquick
+Depends: python3-pyside2.qtquick, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qtpositioning PySide2.QtPositioning
-Depends: python3-pyside2.qtpositioning
+Depends: python3-pyside2.qtpositioning, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtx11extras 
PySide2.QtX11Extras
-Depends: python3-pyside2.qtx11extras
+Depends: python3-pyside2.qtx11extras, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtqml 
PySide2.QtQml
-Depends: python3-pyside2.qtqml
+Depends: python3-pyside2.qtqml, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qtwebenginecore PySide2.QtWebEngineCore
-Depends: python3-pyside2.qtwebenginecore
+Depends: python3-pyside2.qtwebenginecore, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qttexttospeech PySide2.QtTextToSpeech
-Depends: python3-pyside2.qttexttospeech
+Depends: python3-pyside2.qttexttospeech, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qthelp 
PySide2.QtHelp
-Depends: python3-pyside2.qthelp
+Depends: python3-pyside2.qthelp, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qtscripttools PySide2.QtScriptTools
-Depends: python3-pyside2.qtscripttools
+Depends: python3-pyside2.qtscripttools, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtnetwork 
PySide2.QtNetwork
-Depends: python3-pyside2.qtnetwork
+Depends: python3-pyside2.qtnetwork, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh 
python3-pyside2.qtmultimediawidgets PySide2.QtMultimediaWidgets
-Depends: python3-pyside2.qtmultimediawidgets
+Depends: python3-pyside2.qtmultimediawidgets, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qtlocation 
PySide2.QtLocation
-Depends: python3-pyside2.qtlocation
+Depends: python3-pyside2.qtlocation, python3-all
 Restrictions: allow-stderr, superficial
 
 Test-Command: debian/tests/test_install_python3.sh python3-pyside2.qt3dlogic 
PySide2.Qt3DLogic

Bug#951539: ITP: bruteforce-wallet -- Try to find a password of a encrypted wallet file

[Sam Hartman]

Might I suggest that wallet is kind of generic and I'm aware of a number
of different tools out there that claim to be wallets of various kinds.
I think the description should do a better job of scoping which wallets
this is good for.

Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts

[Ryutaroh Matsumoto]

>> I know. It was by lualatex-dev in TeXLive 2019 as of 14 Februrary.
> 
> Within the next 2 months or so TeX Live 2020 pretest will be uploaded,
> which will contain luahbtex and all the required changes.

As you know, lualatex-dev in TeXlive 2019 (after Nov. 2019)
will almost the same as
lualatex in TeXlive 2020, so I bet this #930292 will remain the same,
which of couse I do not welcome...
I wonder if this issue (huge memory comsumption with a huge number
(e.g. 65535) of glyphs) can be fixed...
I understand that lualatex has to examine every pair of all the glyphs,
which could be 65535 * 65535 paris...

Best regards, Ryutaroh

Bug#950772: Patch: swupdate: FTBFS during separate arch/indep builds

[Bastian Germann]

Hi,

I have created a merge request at
https://salsa.debian.org/debian/swupdate/merge_requests/2 which fixes
the issue. Please consider merging and uploading to sid.

Regards,
Bastian

Bug#951348: Let me know how I can help

[Emery Berger]

I saw the ITP; that’d be great. Please file issues or PRs and I will attend
to them quickly.

Best,
— emery
-- 
--
Professor Emery Berger
College of Information and Computer Sciences
University of Massachusetts Amherst
www.emeryberger.org, @emeryberger

Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts

[Norbert Preining]

> I know. It was by lualatex-dev in TeXLive 2019 as of 14 Februrary.

Within the next 2 months or so TeX Live 2020 pretest will be uploaded,
which will contain luahbtex and all the required changes.

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951549: systemd-fstab-generator: zfs entries in fstab should require zfs-import-scan or zfs-import-cache

[Peter B]

Package: systemd
Version: 244-3
Severity: normal



-- Package-specific info:

ZFS filesystems can be mounted through fstab, the zpool needs to be
imported before the mount. Currently systemd does not enforce
imports before mounts.

I demonstrably worked around this using this option in fstab:
'x-systemd.requires=zfs-import-scan.service'

I believe more generically all zfs filesystems in fstab should 'want' to
be 'after' the following services:
zfs-import-scan.service
zfs-import-cache.service

The three ways I know to have Debian import zpools:
- systemd: zfs-import-scan.service
- systemd: zfs-import-cache.service
- zfs kernel module parameter: zfs_autoimport_disable=0

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

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

Versions of packages systemd depends on:
ii  adduser  3.118
ii  libacl1  2.2.53-5
ii  libapparmor1 2.13.3-7
ii  libaudit11:2.8.5-2+b1
ii  libblkid12.34-0.1
ii  libc62.29-6
ii  libcap2  1:2.27-1
ii  libcryptsetup12  2:2.2.2-1
ii  libgcrypt20  1.8.5-3
ii  libgnutls30  3.6.11.1-2
ii  libgpg-error01.36-7
ii  libidn2-02.2.0-2
ii  libip4tc21.8.4-1
ii  libkmod2 26-3
ii  liblz4-1 1.9.2-2
ii  liblzma5 5.2.4-1+b1
ii  libmount12.34-0.1
ii  libpam0g 1.3.1-5
ii  libpcre2-8-0 10.34-7
ii  libseccomp2  2.4.2-2
ii  libselinux1  3.0-1
ii  libsystemd0  244-3
ii  mount2.34-0.1
ii  util-linux   2.34-0.1

Versions of packages systemd recommends:
ii  dbus  1.12.16-2

Versions of packages systemd suggests:
ii  policykit-10.105-26
pn  systemd-container  

Versions of packages systemd is related to:
pn  dracut   
ii  initramfs-tools  0.135
ii  udev 244-3

-- no debconf information
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#
UUID=99bc5718-d81c-11e9-ae7d-84349719f1b2   /   ext4
defaults,noatime,errors=remount-ro  0 1
#UUID=cd07d6e4-7442-4661-90b1-b5fc5057b97a  /home   ext4
defaults0 2
zpool0/home /home   zfs 
defaults,noatime,x-systemd.requires=zfs-import-scan.service 0 0
UUID=FE5F-67F7  /boot/efi   vfat
umask=0077  0 1

tmpfs   /tmptmpfs   
size=25%0 0
tmpfs   /var/tmptmpfs   
size=25%0 0

/dev/sr0/media/cdrom0   udf,iso9660 user,noauto 0   0

Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK fonts

[Ryutaroh Matsumoto]

> There is no luahbtex in Debian.

I know. It was by lualatex-dev in TeXLive 2019 as of 14 Februrary.
It suggests that the situation will remain the same in near future,
unless packaging modifies the upstream source in significant way.
I should have written the background in more detail to avoid your
misunderstanding.

Ryutaroh

From: Norbert Preining 
Subject: Re: Bug#930292: texlive-luatex: lualatex uses huge memory for Noto CJK 
fonts
Date: Sat, 15 Feb 2020 12:27:27 +0900

> On Sat, 15 Feb 2020, Ryutaroh Matsumoto wrote:
>> This is LuaHBTeX, Version 1.11.2 (TeX Live 2020/dev)
> 
> There is no luahbtex in Debian.
> 
> Norbert
> 
> --
> PREINING Norbert   http://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951468: symlinks: segfault when symlink is /..

[Bernhard Übelacker]

Dear Maintainer,
I tried to debug this issue.

(gdb) bt
#0  tidy_path (path=0x55f0c81ea140  "/../") at symlinks.c:96
#1  0x55f0c7fe6908 in fix_symlink (my_dev=2049, path=0x55f0c81ec1e0 
 "/tmp/tmp.tlVVwIgOZQ/mylink") at symlinks.c:185
#2  0x55f0c7fe6e81 in dirwalk (pathlen=, dev=2049, 
path=0x55f0c81ec1e0  "/tmp/tmp.tlVVwIgOZQ/mylink") at symlinks.c:290
#3  0x55f0c7fe5f1d in main (argc=, argv=0x7ffd5d3596f0) 
at symlinks.c:376


I guess I found a buffer underrun in following lines:

76  static int tidy_path (char *path)
...
91  while ((p = strstr(path,"/../")) != NULL) {
92  s = p+3;
93  for (p--; p != path; p--) if (*p == '/') break;

In line 93 p equals path already but is decremented before the
condition 'p != path' is checked the first time.
Therefore this loop is just ended when the first '/' is found
before the begin of the path variable, which is "luckily" in our
case in the .rodata section of the executable, to that we want
to write in line 96.

This modification makes symlinks not crash and shows plausible output:

-   for (p--; p != path; p--) if (*p == '/') break;
+   for (p--; p > path; p--) if (*p == '/') break;

Kind regards,
Bernhard

# Buster/stable amd64 qemu VM 2020-02-16


apt update
apt dist-upgrade

apt install systemd-coredump mc fakeroot symlinks gdb symlinks-dbgsym
apt build-dep symlinks




mkdir /home/benutzer/source/symlinks/orig -p
cd/home/benutzer/source/symlinks/orig
apt source symlinks
cd




cat < reproduce.sh
#! /usr/bin/env sh
MYTMP=\$(mktemp -d)
ln -s /.. \$MYTMP/mylink
symlinks \$MYTMP
EOF

chmod +x reproduce.sh
./reproduce.sh

journalctl --no-pager

coredumpctl list

coredumpctl gdb 1443

set width 0
set pagination off
directory /home/benutzer/source/symlinks/orig/symlinks-1.4
bt







###
###
###





benutzer@debian:~$ ./reproduce.sh 
Segmentation fault (core dumped)



root@debian:~# journalctl --no-pager
...
Feb 17 23:49:17 debian kernel: symlinks[1443]: segfault at 55f0c81e70ed ip 
55f0c7fe675a sp 7ffd5d359360 error 7 in symlinks[55f0c7fe5000+3000]
Feb 17 23:49:17 debian kernel: Code: 1d 0f 1f 80 00 00 00 00 80 3a 2f 74 11 48 
83 ea 01 48 39 d5 75 f2 48 89 ea 80 3a 2f 75 29 31 c9 0f b6 74 08 03 bb 01 00 
00 00 <40> 88 34 0a 48 83 c1 01 40 84 f6 75 e9 4c 89 e6 48 89 ef e8 0e f6
Feb 17 23:49:17 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice.
Feb 17 23:49:17 debian systemd[1]: Started Process Core Dump (PID 1444/UID 0).
Feb 17 23:49:17 debian systemd-coredump[1445]: Process 1443 (symlinks) of user 
1000 dumped core.
   
   Stack trace of thread 1443:
   #0  0x55f0c7fe675a n/a 
(symlinks)
   #1  0x55f0c7fe6908 n/a 
(symlinks)
   #2  0x55f0c7fe6e81 n/a 
(symlinks)
   #3  0x55f0c7fe5f1d n/a 
(symlinks)
   #4  0x7fea02a9f09b 
__libc_start_main (libc.so.6)
   #5  0x55f0c7fe61da n/a 
(symlinks)
Feb 17 23:49:17 debian systemd[1]: systemd-coredump@0-1444-0.service: Succeeded.


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash
error 7 == 0b111
 *   bit 0 ==1: protection fault
 *   bit 1 ==1: write access
 *   bit 2 ==1: user-mode access





root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Mon 2020-02-17 23:49:17 CET1443  1000  1000  11 present   /usr/bin/symlinks





root@debian:~# coredumpctl gdb 1443
   PID: 1443 (symlinks)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Mon 2020-02-17 23:49:17 CET (1min 25s ago)
  Command Line: symlinks /tmp/tmp.tlVVwIgOZQ
Executable: /usr/bin/symlinks
 Control Group: /user.slice/user-1000.slice/session-3.scope
  Unit: session-3.scope
 Slice: user-1000.slice
   Session: 3
 Owner UID: 1000 (benutzer)
   Boot ID: 2d5d5576a57947a7aad042da5f907289
Machine ID: 33f18f39d2a9438eb75b0ed52848afcd
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.symlinks.1000.2d5d5576a57947a7aad042da5f907289.1443.158197975700.lz4
   Message: Process 1443 (symlinks) of user 1000 dumped core.

Stack trace of thread 1443:
#0  0x55f0c7fe675a n/a (symlinks)
#1  0x55f0c7fe6908 n/a (symlinks)
#2  0x55f0c7fe6e81 n/a (symlinks)
#3  0x55f0c7fe5f1d n/a (symlinks)
#4  0x7fea02a9f09b __libc_start_main (libc.so.6)
#5  0x55f0c7fe61da n/a (symlinks)

GNU gdb 

Bug#951398: Rebuild pax

[Norbert Preining]

BTW, you messed up the $dist variable, the pax.jar needs to go to
texmf-dist/scripts/pax/ not texmf-dist/tex/latex/pax/

The correct replacement in the build file is that

+  

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951548: RFS: aewm/1.3.12-5 [QA] -- minimalist window manager for X11

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: aewm
   Version : 1.3.12-5
   Upstream Author : Decklin Foster 
 * URL : https://www.red-bean.com/decklin/aewm/
 * License : MIT
 * Vcs : https://salsa.debian.org/debian/aewm
   Section : x11

It builds those binary packages:

  aewm - minimalist window manager for X11

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

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

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

  dget -x https://mentors.debian.net/debian/pool/main/a/aewm/aewm_1.3.12-5.dsc

Changes since the last upload:

   * QA upload.
   * Update Standards-Version to 4.5.0
   * Fix FTCBFS. (Closes: #933233)
   * Add Vcs link for salsa.


-- 
Regards
Sudip

Bug#951398: Rebuild pax

[Norbert Preining]

On Mon, 17 Feb 2020, Bastien ROUCARIES wrote:
> They need to be replaced by link to their respective package (normally
> it is symlink to /usr/share/commons-logging.jar)

THanks, this is what I already implemented and test-building now.

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#950716: transition: ruby2.7

[Lucas Kanashiro]

Hi Graham,

I just uploaded ruby-defaults version 1:2.5.7 to unstable with both
versions of the ruby interpreter enabled (2.5 and 2.7).

We (the Ruby team) should start to request some binNMUs soon.

-- 
Lucas Kanashiro

Bug#951547: Initial packaging

[Zygmunt Krynicki]

I’ve prepared initial packaging here

https://github.com/zyga/libzt/tree/pkg/debian/packaging/debian

It builds and passes lintian checks although my packaging memory may be a 
little rusty.

Bug#945240: evolution: HTML messages become unreadable after changing theme

[Alberto Garcia]

On Wed, Jan 29, 2020 at 12:22:04PM +0100, Alberto Garcia wrote:

> > For WebKit, let's discuss in
> > https://bugs.webkit.org/show_bug.cgi?id=202194 to keep things in one
> > place.
> 
> So there's now a patch for the WebKit 2.26 branch that IIUC would
> solve this problem without having to patch Evolution at all.
> 
>https://trac.webkit.org/changeset/255350/webkit
> 
> If everything works fine it will be available in the next stable
> release of the webkit2gtk package.

WebKitGTK 2.26.4 is now available in testing, sid and buster-security,
can anyone check if that fixes this problem in Evolution?

Thanks!

Berto

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Johannes Schauer]

Hi,

Quoting Francesco Poli (2020-02-17 23:10:57)
> On Sun, 02 Feb 2020 20:29:04 +0100 Johannes Schauer wrote:
> 
> > Quoting Johannes Schauer (2020-02-02 20:22:49)
> [...]
> > > 1. you can try the qcow2 image you built without autopkgtest by just 
> > > running it
> > >inside qemu like so:
> > > 
> > > $ qemu-system-x86_64 -enable-kvm -m 512 -serial 
> > > unix:/tmp/ttyS0,server,nowait -drive 
> > > "file=$HOME/Downloads/TEST/debian-unstable.qcow2,cache=unsafe,if=virtio,index=0"
> > 
> > One non-obvious thing is missing here. After running the above command you 
> > have
> > a new unix socket under /tmp/ttyS0 that you should be able to connect to 
> > using
> > a serial terminal emulator. This is how autopkgtest connects to qemu. So 
> > after
> > running above command, check that everything works by running something 
> > like:
> > 
> > $ minicom -D 'unix#/tmp/ttyS0'
> 
> Hello and sorry for the long delay (I had been busy in too many things...).
> 
> I tried the test you suggested and found out that the virtual machine
> fails to boot!
> The attached screenshot is what is shown in the graphical window...
> seemingly forever.
> 
> I haven't even tried to connect to /tmp/ttyS0, as I guess a virtual
> machine that fails to boot will never bring the serial terminal
> emulator up and running...
> 
> I am really ignorant about qemu: do you happen to have any idea on what
> went wrong?

here is a hunch:

Can you show me how you converted the tarball mmdebstrap produced into your
debian-unstable.qcow2 image?

Thanks!

cheers, josch

signature.asc
Description: signature

Bug#951545: spamc: 500k default max_size for spamc is too small for today's use

[Russell Coker]

Package: spamc
Version: 3.4.2-1+deb10u2
Severity: normal
Tags: upstream

When we ran mail servers on 32bit systems a default of skipping spam checks on
the rare messages that were more than 500k in size made sense.

Nowadays messages larger than that are normal and scanning a 10MB message is
not a problem for CPU use or memory allocation on most systems.

I believe that the default should just work for most people who don't have
unusual needs.  Running spamassassin on a 32bit system nowadays is an
unusual situation that the users could be expected to tune for.  Running it
on a system with many gigs of RAM is more the usual case.

For the benefit of other people with this issue, a line like the following in
/etc/default/spamass-milter will make it take 10MB messages (the "--" and
following is the relevant part).

OPTIONS="-u spamass-milter -i 127.0.0.1 -r 5 -- -s 10485760"

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

Kernel: Linux 4.19.0-8-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: SELinux: enabled - Mode: Enforcing - Policy name: default

Versions of packages spamc depends on:
ii  libc6  2.28-10
ii  libssl1.1  1.1.1d-0+deb10u2

spamc recommends no packages.

Versions of packages spamc suggests:
ii  spamassassin  3.4.2-1+deb10u2

-- no debconf information

Bug#951536: Debian Bug Tracking System

[Arthur de Jong]

On Mon, 2020-02-17 at 21:57 +0100, Ingo wrote:
> On first login after boot up on the linux console with a local user I
> have to wait one minute to get a shell prompt. After first login I
> can logoff and login as usual without delay.

This is weird. I suspect this is related to the mechanism that nslcd
uses to authenticate itself to the LDAP server. I'm afraid I don't know
all the details of SASL/GSSAPI/Kerberos protocols and how OpenLDAP uses
them.

> The account is a local unix account with entries in /etc/passwd and
> /etc/group and does not has a posixAccount on the ldap directory.
> Authorization against the ldap server is done with SASL Proxy
> Authorization.

One way to work around this particular problem is to use the
nss_initgroups_ignoreusers option to exclude group lookups for local
user accounts.

> The bug is only seen when quering for the group account. This can
> simply verified with removing the 'ldap' postfix at the line
> group:  files ldap
> in /etc/nsswitch.conf. Without 'ldap' on that line I can first login
> after boot up without delay.

The reason that this lookup occurs is because nslcd supports having
local users in LDAP groups (the NSS subsystem generally supports
this). On login the secondary groups of a user are looked up resulting
in this LDAP search.

> As shown in the debug log below the dbus-daemon is timing out the
> attempt of nslcd to connect to the ldap server.

The logs show two queries: a lookup for the groups of user local which
comes from the login process (pid 362) and one for the groups of user
nslcd which comes from dbus-daemon (pid 345).

Apparently, some part of the SASL/GSSAPI/Kerberos authentication
triggers a dbus lookup. The dbus authentication (the second query in
nslcd) fails with a timeout and the whole thing fails. If that is true
  nss_initgroups_ignoreusers nslcd
should be sufficient to fix this.

Can you confirm?

-- 
-- arthur - adej...@debian.org - https://people.debian.org/~adejong --



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

Bug#949312: txsocksx: should this package be removed?

[Adrian Bunk]

On Mon, Feb 17, 2020 at 12:05:59PM -0500, Scott Kitterman wrote:
> Here's a thought:
> 
> Given the concern Adrian has expressed relative to tahoe-lafs, how about if 
> someone uploads the relevant packages to experimental:
> 
> python-txsocksx -> foolscap -> tahoe-lafs
> 
> Then the Unstable rm can go forward, but in the event python2 stays in the 
> bullseye release, it's easy to re-introduce.  It wouldn't even need to go 
> through New.  You'd probably want to upload any other depends that might drop 
> python2 support as well with a sufficiently high version that they won't get 
> removed due to NVIU.

How would this bring any advantage?

Sandro seems to be working mainly on testing, and RC bugs already exist
that prevent re-migration to testing.

> Scott K

cu
Adrian

BTW: The Christmas Eve removal in #937449 a few days after removal 
 from testing and despite maintainer objection might be a good
 example how early removal from unstable makes people not happy.

Bug#951547: ITP: libzt -- libzt is a simple and robust unit test library for C

[Zygmunt Krynicki]

Package: wnpp
Severity: wishlist
Owner: Zygmunt Krynicki 

* Package name: libzt
  Version : 0.1
  Upstream Author : Zygmunt Krynicki 
* URL : http://github.com/zyga/libz/
* License : LGPL
  Programming Lang: C
  Description : libzt is a simple and robust unit test library for C

The library provides functions for common checks and assertions,
which produce readable diagnostic messages that integrate well with
"make check" and programming editors, such as vi.

 - Robust, allowing you to focus on your code.
 - Simple and small, making it quick to learn and use.
 - Doesn't use dynamic memory allocation, reducing error handling.
 - Equipped with useful helpers for writing test cases.
 - Portable and supported on Linux, MacOS and Windows.
 - Documented  and fully coverage and integration tested.

This package may be useful to projects that want to write C unit tests but 
don't want
to depend on glib or roll their own solution I would like to maintain it myself 
or
in a team. The package needs to be sponsored.

Bug#951546: timewarrior: Bash completion doesn't work for timew

[Clément Hermann]

Package: timewarrior
Version: 1.2.0-1
Severity: normal
Tags: patch

Hi,

bash completion doesn't work, because the completion script is installed
in /usr/share/bash-completion/ instead of
/usr/share/bash-completion/completions/.

It would probably be better to use dh_bash-completion.

Please find a patch attached :)

(note that it will trigger a lintian warning, I'm disscussing this in
https://salsa.debian.org/lintian/lintian/merge_requests/292).

Cheers,

nodens

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

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

Versions of packages timewarrior depends on:
ii  libc62.29-10
ii  libgcc-s1 [libgcc1]  10-20200211-1
ii  libgcc1  1:10-20200211-1
ii  libstdc++6   10-20200211-1

Versions of packages timewarrior recommends:
ii  taskwarrior  2.5.1+dfsg-8

Versions of packages timewarrior suggests:
ii  python  2.7.17-2

-- no debconf information
>From 3a78ef9487e71705e4641789a9d04a90e28a1711 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20Hermann?= 
Date: Fri, 14 Feb 2020 17:24:27 +0100
Subject: [PATCH] Fix bash-completion installation path

- removes dh-auto-install override
- adds --with-bash-completion to dh call
--adds d/timewarrior.bash-completion control file
- adds bash-completion to build-depends
---
 debian/control | 2 +-
 debian/rules   | 7 +--
 debian/timewarrior.bash-completion | 1 +
 3 files changed, 3 insertions(+), 7 deletions(-)
 create mode 100644 debian/timewarrior.bash-completion

diff --git a/debian/control b/debian/control
index 5984306..f30e6ba 100644
--- a/debian/control
+++ b/debian/control
@@ -3,7 +3,7 @@ Section: utils
 Priority: optional
 Maintainer: Debian Tasktools Packaging Team 
 Uploaders: Gordon Ball 
-Build-Depends: debhelper-compat (= 12), cmake, git, python
+Build-Depends: debhelper-compat (= 12), cmake, git, python, bash-completion
 Standards-Version: 4.4.1
 Homepage: https://timewarrior.net/
 Vcs-Browser: https://salsa.debian.org/tasktools-team/timew
diff --git a/debian/rules b/debian/rules
index 02f9548..611059d 100755
--- a/debian/rules
+++ b/debian/rules
@@ -6,17 +6,12 @@ TAG_VERSION := $(shell echo $(DEB_VERSION_UPSTREAM) | tr '~' 
'.' | sed -e 's/+[d
 export DEB_BUILD_MAINT_OPTIONS = hardening=+all
 
 %:
-   dh $@
+   dh $@ --with bash-completion
 
 override_dh_auto_configure:
find . -type f -exec sed -i '1s|^#!/usr/bin/env 
python|#!/usr/bin/python|' {} \;
dh_auto_configure
 
-override_dh_auto_install:
-   dh_auto_install
-   mkdir -p debian/timewarrior/usr/share/bash-completion
-   cp completion/timew-completion.bash 
debian/timewarrior/usr/share/bash-completion/timew
-
 override_dh_installchangelogs:
dh_installchangelogs -k ChangeLog
 
diff --git a/debian/timewarrior.bash-completion 
b/debian/timewarrior.bash-completion
new file mode 100644
index 000..5f2d031
--- /dev/null
+++ b/debian/timewarrior.bash-completion
@@ -0,0 +1 @@
+completion/timew-completion.bash timew
-- 
2.25.0

Bug#560289: git-buildpackage: repackaged upstream tarball's dir should be -.orig

[Richard Laager]

On Thu, 10 Dec 2009 10:33:33 +0100 Thomas Koch  wrote:
> Package: git-buildpackage
> Version: 0.4.61
> Severity: normal
> 
> As of developers-reference, 6.7.8.2. (Repackaged upstream source):
> 
> A repackaged .orig.tar.gz should use
> -.orig as the name of the top-level
> directory in its tarball. This makes it possible to distinguish pristine
> tarballs from repackaged ones.

The current version of the developers reference says:

"may use packagename-upstream-version+dfsg (or any atter suffix which is
added to the tarball name) as the name of the top-level directory in its
tarball. This makes it possible to distinguish pristine tarballs from
repackaged ones."

-- 
Richard

Bug#951543: Please enable SECO HDMI CEC driver

[Sébastien Noel]

Package: src:linux
Severity: wis hlist
Tags: patch

Dear Maintainer,

Could you please enable CONFIG_VIDEO_SECO_CEC ?
That device is found on x86 board from UDOO, it would be very cool
to not have to rebuild the kernel by hand :-)

Thanks.

Sébastien

--- a/config-5.4.13
+++ b/config-5.4.13
@@ -4797,6 +4797,7 @@
 # CONFIG_REGULATOR_TPS65132 is not set
 # CONFIG_REGULATOR_TPS6524X is not set
 CONFIG_CEC_CORE=y
+CONFIG_CEC_NOTIFIER=y
 CONFIG_RC_CORE=m
 CONFIG_RC_MAP=m
 CONFIG_LIRC=y
@@ -5122,7 +5123,9 @@
 # CONFIG_VIDEO_VIM2M is not set
 # CONFIG_VIDEO_VICODEC is not set
 # CONFIG_DVB_PLATFORM_DRIVERS is not set
-# CONFIG_CEC_PLATFORM_DRIVERS is not set
+CONFIG_CEC_PLATFORM_DRIVERS=y
+CONFIG_VIDEO_SECO_CEC=m
+CONFIG_VIDEO_SECO_RC=y
 # CONFIG_SDR_PLATFORM_DRIVERS is not set
 
 #

Bug#951544: mate-session-manager: FTBFS on non-linux

[Svante Signell]

Source: mate-session-manager
Severity: important
Version: 1.24.0-1
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hello,

The latest version of mate-session-manager FTBFS on Hurd and kFreeBSD due to a
missing build dependency on libegl-dev. Looking at the build logs for linux*
architectures reveals that libegl-dev (and dependant libraries) are installed
for the builds, making them succeed without an explicit build-dependency. How
that is happening is unknown to this bug submitter.

The attached patch fixes the build for hurd-any and kfreebsd-any. Maybe that
dependency should also be added to the linux-any targets. In that case the build
dependency to add would be simply libegl-dev.

Thanks.
--- a/debian/control	2020-02-13 11:20:44.0 +0100
+++ b/debian/control	2020-02-17 22:59:52.0 +0100
@@ -25,6 +25,7 @@
libxrender-dev,
libxt-dev,
libxtst-dev,
+   libgles-dev [hurd-any kfreebsd-any],
mate-common (>= 1.18),
xmlto,
xsltproc,

Bug#951539: ITP: bruteforce-wallet -- Try to find a password of a encrypted wallet file

[Francisco]

Hi. I'm packing the bruteforce-wallet.
The only things that are missing are a proper man page and the upstream
add the openSSL exception for GPL3 +.

I have these two lintian warnings:
E: bruteforce-wallet: possible-gpl-code-linked-with-openssl
W: bruteforce-wallet: binary-without-manpage usr/bin/bruteforce-wallet

I submitted a license update request at
https://github.com/glv2/bruteforce-wallet/issues/26 to fix this.

Regards

-- 
Francisco Vilmar Cardoso Ruviaro 
4096R: 1B8C F656 EF3B 8447 2F48 F0E7 82FB F706 0B2F 7D00

Bug#944485: mmdebstrap: please implement the creation of QEMU/KVM images for autopkgtest-virt-qemu

[Francesco Poli]

On Sun, 02 Feb 2020 20:29:04 +0100 Johannes Schauer wrote:

> Quoting Johannes Schauer (2020-02-02 20:22:49)
[...]
> > 1. you can try the qcow2 image you built without autopkgtest by just 
> > running it
> >inside qemu like so:
> > 
> > $ qemu-system-x86_64 -enable-kvm -m 512 -serial 
> > unix:/tmp/ttyS0,server,nowait -drive 
> > "file=$HOME/Downloads/TEST/debian-unstable.qcow2,cache=unsafe,if=virtio,index=0"
> 
> One non-obvious thing is missing here. After running the above command you 
> have
> a new unix socket under /tmp/ttyS0 that you should be able to connect to using
> a serial terminal emulator. This is how autopkgtest connects to qemu. So after
> running above command, check that everything works by running something like:
> 
> $ minicom -D 'unix#/tmp/ttyS0'

Hello and sorry for the long delay (I had been busy in too many things...).

I tried the test you suggested and found out that the virtual machine
fails to boot!
The attached screenshot is what is shown in the graphical window...
seemingly forever.

I haven't even tried to connect to /tmp/ttyS0, as I guess a virtual
machine that fails to boot will never bring the serial terminal
emulator up and running...

I am really ignorant about qemu: do you happen to have any idea on what
went wrong?


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpZIGyLBOK0C.pgp
Description: PGP signature

Bug#951542: RFS: abr2gbr/1:1.0.2-2.1 [NMU, RC] -- Converts PhotoShop brushes to GIMP

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: important

Dear mentors,

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

 * Package name: abr2gbr
   Version : 1:1.0.2-2.1
   Upstream Author : Marco Lamberto 
 * URL : http://www.sunnyspot.org/gimp/tools.html
 * License : GPL-2.0+
 * Vcs : None
   Section : x11

It builds those binary packages:

  abr2gbr - Converts PhotoShop brushes to GIMP

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/a/abr2gbr/abr2gbr_1.0.2-2.1.dsc

Changes since the last upload:

   * Non-maintainer upload.
   * Fix ftbfs. (Closes: #925625)
 - Thanks to Reiner Herrmann.


-- 
Regards
Sudip

Bug#951497: rumur: building from sources makes machine un-usable or OOM/kills kernel

[Anatoly Pugachev]

On Mon, Feb 17, 2020 at 11:12 PM Matthew Fernandez
 wrote:
>
> Yikes, sorry.
>
> The test suite for this package auto-detects the number of CPUs and 
> parallelises across all of them. This is not very well behaved when calling 
> it from the outer build system, as it doesn’t pay attention to any -j flag 
> you’ve passed there. To compound the situation, some of the individual test 
> cases themselves are also multithreaded.
>
> I think the simplest solution is to force the test suite to always run 
> single-threaded when called via ctest. Can I close this bug by making this 
> change when packaging the next upstream release? Or do I also need to upload 
> new packages for the existing versions in Debian?


Matthew,

being "Version: 2020.01.27-1" is available in the repository , is it
possible to fix test suite to run single-threaded (or maybe -j2) via
debian package patch and bump version to "2020.01.27-2" and upload?

Thanks.

Bug#951541: mate-panel: FTBFS on non-linux

[Svante Signell]

Source: mate-panel
Severity: important
Version: 1.24.0-1
Tags: patch
User: debian-h...@lists.debian.org
Usertags: hurd
X-Debbugs-CC: debian-h...@lists.debian.org

Hello,

The latest version of mate-panel FTBFS on Hurd and kFreeBSD due to a build
dependency of libgtk-layer-shell-dev. That package is dependant on Wayland,
which is not yet available on hurd-any or kfreebsd-any.

The attached patch makes the build-dependency linux-any only.

Thanks.
--- a/debian/control	2020-02-13 13:07:28.0 +0100
+++ b/debian/control	2020-02-17 14:58:08.0 +0100
@@ -13,7 +13,7 @@
gir1.2-freedesktop,
gobject-introspection,
gtk-doc-tools,
-   libgtk-layer-shell-dev (>= 0.1.0-3~),
+   libgtk-layer-shell-dev (>= 0.1.0-3~) [linux-any],
intltool,
libatk1.0-dev,
libcairo2-dev,

Bug#951398: Rebuild pax

[Bastien ROUCARIES]

On Mon, Feb 17, 2020 at 10:12 PM Norbert Preining  wrote:
>
> Hi Bastien,
>
> On Mon, 17 Feb 2020, Bastien ROUCARIES wrote:
> > For rebuilding pax you need to apply this patch then from
>
> Ok, it is not that easy but done that now.
>
> > source/pax/latex/pax run ant
>
> ok.
>
> This script generates **three** files:
> texmf-dist/tex/latex/pax/pax.jargood
> texmf-dist/tex/latex/pax/lib/commons-logging.jar
> texmf-dist/tex/latex/pax/lib/pdfbox.jar
>
> Are the last two necessary there, i.e., should we replace them with
> links to the respective files in the installed packages?

They need to be replaced by link to their respective package (normally
it is symlink to /usr/share/commons-logging.jar)

Best

Bastien
>
> Best
>
> Norbert
>
> --
> PREINING Norbert  https://www.preining.info
> Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
> GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951540: ITP: golang-github-go-resty-resty -- Simple HTTP and REST client library for Go

[Alois Micard]

Package: wnpp
Severity: wishlist
Owner: Alois Micard 

* Package name: golang-github-go-resty-resty
  Version : 2.1.0-1
  Upstream Author : Go Resty
* URL : https://github.com/go-resty/resty
* License : Expat
  Programming Lang: Go
  Description : Simple HTTP and REST client library for Go


This package is needed for advancedlogic/GoOse

Thanks in advance.

-
Aloïs Micard 

GPG: rsa4096/A5999EBDFC063F1F

Bug#951539: ITP: bruteforce-wallet -- Try to find a password of a encrypted wallet file

[Francisco Vilmar Cardoso Ruviaro]

Package: wnpp
Severity: wishlist
Owner: Francisco Vilmar Cardoso Ruviaro 

* Package name: bruteforce-wallet
  Version : 1.5.2
  Upstream Author : Guillaume LE VAILLANT 

* URL : https://github.com/glv2/bruteforce-wallet
* License : GPL-3+
  Programming Lang: C
  Description : Try to find a password of a encrypted wallet file

 The program tries to decrypt one of the encrypted addresses
 in the wallet by trying all the possible passwords.
 It is especially useful if you know something about the password
 (i.e. you forgot a part of your password but still remember most of it).
 Finding the password of a wallet without knowing anything about it would
 take way too much time (unless the password is really short and/or weak).

Bug#951533: The package is too large and contains multiple packages in itself

[David Bremner]

KOLANICH  writes:

Control: severity -1 wishlist

> Package: racket-common
> Version: 7.2+dfsg1-2
>
> May worth splitting.

I'd be hesitant to start such a project unless there was a concrete
problem I was solving. Upstream ships the "packages" that way as part of
the standard source distribution. It would be possible to use a more
minimal source distribution, but then things start to
break. Unfortunately I don't have time to devote to that kind of debugging.

Bug#951538: golang-github-sylabs-sif: FTBFS: Can't exec "go"

[Ivo De Decker]

package: src:golang-github-sylabs-sif
version: 1.0.9-1
severity: serious
tags: ftbfs

Hi,

The latest upload of golang-github-sylabs-sif to unstable fails everywhere:

Can't exec "go": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 484.

https://buildd.debian.org/status/package.php?p=golang-github-sylabs-sif

Cheers,

Ivo

Bug#951537: php-horde-data: CVE-2020-8518

[Salvatore Bonaccorso]

Source: php-horde-data
Version: 2.1.4-6
Severity: grave
Tags: security upstream
Justification: user security hole
Control: found -1 2.1.4-5
Control: found -1 2.1.4-3

Hi,

The following vulnerability was published for php-horde-data.

CVE-2020-8518[0]:
| Horde Groupware Webmail Edition 5.2.22 allows injection of arbitrary
| PHP code via CSV data, leading to remote code execution.


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2020-8518
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8518
[1] https://lists.horde.org/archives/announce/2020/001285.html

Regards,
Salvatore

Bug#951057: [Pkg-clamav-devel] Bug#951057: clamav-freshclam: allow overriding of CA store

[Scott Kitterman]

Thanks.  It looks like clamav-freshclam will also need Depends ca-certificates 
added.  I'd prefer Recommends if we can get away with it.  What do you think?

Bug#951398: Rebuild pax

[Norbert Preining]

Hi Bastien,

On Mon, 17 Feb 2020, Bastien ROUCARIES wrote:
> For rebuilding pax you need to apply this patch then from

Ok, it is not that easy but done that now.

> source/pax/latex/pax run ant

ok.

This script generates **three** files:
texmf-dist/tex/latex/pax/pax.jargood
texmf-dist/tex/latex/pax/lib/commons-logging.jar
texmf-dist/tex/latex/pax/lib/pdfbox.jar

Are the last two necessary there, i.e., should we replace them with
links to the respective files in the installed packages?

Best

Norbert

--
PREINING Norbert  https://www.preining.info
Accelia Inc. + IFMGA ProGuide + TU Wien + JAIST + TeX Live + Debian Dev
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Bug#951533: The package is too large and contains multiple packages in itself

[KOLANICH]

Package: racket-common
Version: 7.2+dfsg1-2

May worth splitting.

Bug#951536: Debian Bug Tracking System

[Ingo]

Package: nslcd
Version: 0.9.10-2
Severity: normal



-- System Information:
Debian Release: 10.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages nslcd depends on:
ii  adduser3.118
ii  ca-certificates20190110
ii  debconf [debconf-2.0]  1.5.71
ii  libc6  2.28-10
ii  libgssapi-krb5-2   1.17-3
ii  libldap-2.4-2  2.4.47+dfsg-3+deb10u1
ii  lsb-base   10.2019051400

Versions of packages nslcd recommends:
ii  bind9-host [host] 1:9.11.5.P4+dfsg-5.1
ii  ldap-utils2.4.47+dfsg-3+deb10u1
ii  libnss-ldapd [libnss-ldap]0.9.10-2
pn  libpam-ldapd | libpam-ldap | libpam-krb5 | libpam-he  
pn  nscd  
pn  nslcd-utils   

Versions of packages nslcd suggests:
ii  kstart  4.2-2

-- debconf information excluded


On first login after boot up on the linux console with a local user I have
to wait one minute to get a shell prompt. After first login I can logoff
and login as usual without delay.

The account is a local unix account with entries in /etc/passwd and
/etc/group and does not has a posixAccount on the ldap directory.
Authorization against the ldap server is done with SASL Proxy
Authorization.

The bug is only seen when quering for the group account. This can simply
verified with removing the 'ldap' postfix at the line
group:  files ldap
in /etc/nsswitch.conf. Without 'ldap' on that line I can first login after
boot up without delay.

If I use ssh or a serial console (on a virtual machine) then there is no
problem. In these cases LOGIN isn't involved so it seems only to be a
problem in conjunction with LOGIN.

As shown in the debug log below the dbus-daemon is timing out the attempt
of nslcd to connect to the ldap server. These are the important lines:

Feb 15 15:52:45 kawa dbus-daemon[345]: [system] Connection has not 
authenticated soon enough, closing it (auth_timeout=3ms, elapsed: 60015ms)
Feb 15 15:52:45 kawa nslcd[403]: [8b4567]  failed to bind 
to LDAP server ldap://kdc-master.home.hoeft-online.de: Can't contact LDAP 
server: Invalid argument

I have verified with tcpdump that nslcd does not output any ip packages
to the ldap server. It just do nothing on the network at this time. The
immediate next attempt of nslcd to connect to the ldap server succeded. 



Here are the configuration files

# /etc/nslcd.conf
# nslcd configuration file. See nslcd.conf(5)
# for details.

# The user and group nslcd should run as.
uid nslcd
gid nslcd

# Logging options, default is info
log syslog debug

# The location at which the LDAP server(s) should be reachable.
uri ldap://kdc-master.home.hoeft-online.de

# The search base that will be used for all queries.
base ou=home,dc=hoeft-online,dc=de

# The LDAP protocol version to use.
#ldap_version 3

# The DN to bind with for normal lookups.
binddn uid=anyuser,ou=people,ou=home,dc=hoeft-online,dc=de

# The DN used for password modifications by root.
#rootpwmoddn cn=admin,dc=example,dc=com

# SSL options
#ssl off
#tls_reqcert never
tls_cacertfile /etc/ssl/certs/ca-certificates.crt

# SASL options
sasl_mech GSSAPI
krb5_ccname /run/nslcd/nslcd.tkt

# The search scope.
#scope sub



# /etc/nsswitch.conf
passwd: files ldap
group:  files ldap
shadow: files
gshadow:files

hosts:  files resolve [!UNAVAIL=return] dns
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis



Debug log from the systemd journal
--
Feb 15 15:20:16 kawa systemd[1]: Started Wait for Network to be Configured.
Feb 15 15:20:16 kawa systemd[1]: Reached target Network is Online.
Feb 15 15:20:16 kawa systemd[1]: Starting LSB: LDAP connection daemon...
Feb 15 15:20:16 kawa systemd-timesyncd[260]: Synchronized to time server for 
the first time 178.63.9.212:123 (2.debian.pool.ntp.org).
Feb 15 15:20:19 kawa nslcd[373]: Starting Keep alive Kerberos ticket: k5start.
Feb 15 15:20:19 kawa sshd[384]: Server listening on 0.0.0.0 port 22.
Feb 15 15:20:19 kawa sshd[384]: Server listening on :: port 22.
Feb 15 15:20:19 kawa systemd[1]: Started OpenBSD Secure Shell server.
Feb 15 15:20:20 kawa lvm[234]: Monitoring snapshot 
vg1-deb10.2_recommended+ssh+resolve_no_krb5.lv.
Feb 15 15:20:20 kawa systemd[1]: Started LVM2 poll daemon.
Feb 15 15:20:21 kawa lvm[342]:   Background polling started for 1 logical 
volume(s) in volume group "vg1"
Feb 15 15:20:24 kawa lvm[342]:   5 logical volume(s) in volume group "vg1" 

Bug#951535: RFS: dbview/1.0.4-3 [QA] -- View dBase III files

[Sudip Mukherjee]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: dbview
   Version : 1.0.4-3
   Upstream Author : Martin Schulze 
 * URL : http://www.infodrom.org/projects/dbview/
 * License : GPL-2.0+
 * Vcs : https://salsa.debian.org/debian/dbview
   Section : misc

It builds those binary packages:

  dbview - View dBase III files

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/d/dbview/dbview_1.0.4-3.dsc

Changes since the last upload:

   * QA upload.
   * Add Vcs link to salsa.
   * Update Standards-Version to 4.5.0
   * Add hardening flag.
 - Add patch to use LDFLAGS in Makefile.
   * Remove DH_VERBOSE flag.

-- 
Regards
Sudip

Bug#810992: O: cwiid -- library to interface with the wiimote

[Pablo Mestre]

I am interested in maintaining the sonic-pi package [1] which depends on
cwiid. For this reason I would also like to keep the cwiid package or is
there already someone working on this?

Regards

[1] https://tracker.debian.org/pkg/sonic-pi

Bug#936358: cwiid: Python2 removal in sid/bullseye

[Pablo Mestre]

I am interested in maintaining the sonic-pi package [1] which depends on
cwiid. For this reason I would also like to keep the cwiid package or is
there already someone working on this?

Regards

[1] https://tracker.debian.org/pkg/sonic-pi


El 2/17/20 a las 5:42 PM, Pablo Mestre escribió:
> Hi
>
> Im happy to help with this issue...
>
>
> Pablo Mestre
>

Bug#951057: clamav-freshclam: allow overriding of CA store

[Adam D. Barratt]

On Mon, 2020-02-17 at 00:00 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-02-10 13:50:00 [+], Adam D. Barratt wrote:
> > With 0.102, Freshclam started using libcurl for database downloads,
> > but appears to provide no way to configure which certificates
> > should be trusted.
> 
> I just learned about the https part.

We discovered it after monitoring started complaining that the
signature databases weren't being updated.

> > but this isn't ideal. A configuration option to allow specifying an
> > alternative bundle / root, or even respecting CURL_CA_BUNDLE, would
> > be much appreciated.
> [...]
> I was going to submit a pu for 102.2 which migrated to testing a few
> days ago and then this showed up. At [0] I prepared a deb9u1 based
> package of 102.2 with a patch [1] on top of it which should do just
> what you asked for (just set the enviroment variable CURL_CA_BUNDLE
> before invoking freshclam and all should be good).

Thanks!

I've built stretch packages based on your source package, and buster
packages using the buster branch on salsa with the new patch added, and
both seem to be performing well. I look forward to being able to
install the packages from the archive proper. :-)

For the record, d.o's systemd override for freshclam is now:

# /etc/systemd/system/clamav-freshclam.service.d/override.conf
[Service]
Environment=CURL_CA_BUNDLE=/etc/ssl/ca-global/ca-certificates.crt

Regards,

Adam

Bug#951534: Make possible to repack postunpack_hook changed contents

[Marco Trevisan]

Package: git-buildpackage

Using postunpack command is possible to change the content of the source
directories, with something way more advanced than `filters`, however
once the content is modified, it will only be part of the repo, while
it's not possible to repack the resulting orig file.

This can be quite convenient when projects are provided as sub-projects
and some advanced filtering is needed.

For example, the mozilla source provides also mozjs sources, and it's
possible to generate the orig for such package using a script they
provide, in debian we can't regenerate such origin just using gbp
import-orig.

I.e. this would be what I'd like to achieve without having to use
filters at all, and having a matching tarball

https://salsa.debian.org/3v1n0-guest/mozjs68/commit/35e8885c

Bug#936358: cwiid: Python2 removal in sid/bullseye

[Pablo Mestre]

Hi

Im happy to help with this issue...


Pablo Mestre

Bug#951532: libinput: Touchpad behavour changed

[Lukas Straub]

Source: libinput
Version: 1.15.1-1
Severity: normal

Dear Maintainer,
Since Version 1.15.1-1 the behavour of the Touchpad changed. I have a "unified" 
Touchpad i.e. no physical seperate buttons, the whole touchpad is pressed down.
-It's now impossible to do a middle or right-click and drag (It will always 
send left-click)
-If I have my finger on the touch area first, I can do left-click and drag. If 
the mouse button is pressed first, it's impossible to drag (the pointer stays 
where it is). 

These problems go away if I downgrade to libinput-bin 1.14.3-1.

Regards,
Lukas Straub

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

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

Bug#951527: Update to 2.0.39

[KOLANICH]

Package: dnscrypt-proxy
Version: 2.0.31+ds1-1

A new useful feature - a workaround of a long-lasting Firefox bug preventing 
using ESNI without using DoH in FF itself.

Bug#951531: network-manager: unable to activate wired connection when network-manager manages it

[kiemlicz]

Package: network-manager
Version: 1.14.6-2+deb10u1
Severity: grave
Justification: renders package unusable

Dear Maintainer,


   * What led up to the situation?
(Default Debian 10.3 installation with Plasma)
I wanted NetworkManager to manage my connection.
I've disabled /etc/network/interfaces like so:
```
#loopback
auto lo
iface lo inet loopback

#
#auto eno1
#allow-hotplug eno1
#iface eno1 inet dhcp
```
I've added the connection to the NetworkManager from GUI, reboot the system
The NetworkManager GUI constantly loops: activating -> deactivating ->
activating...
journalctl:
```
Feb 17 21:06:01 EDIT kernel: e1000e: eno1 NIC Link is Up 1000 Mbps Full Duplex,
Flow Control: Rx/Tx
Feb 17 21:06:01 EDIT kernel: IPv6: ADDRCONF(NETDEV_CHANGE): eno1: link becomes
ready
Feb 17 21:06:01 EDIT NetworkManager[720]:   [1581969961.4093] device
(eno1): carrier: link connected
Feb 17 21:06:01 EDIT NetworkManager[720]:   [1581969961.4099] device
(eno1): state change: unavailable -> disconnected (reason 'carrier-changed',
sys-iface-state: 'managed')
Feb 17 21:06:01 EDIT NetworkManager[720]:   [1581969961.4123] manager:
startup complete
Feb 17 21:06:01 EDIT systemd[1]: Started Network Manager Wait Online.
-- Subject: A start job for unit NetworkManager-wait-online.service has
finished successfully
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit NetworkManager-wait-online.service has finished
successfully.
--
-- The job identifier is 108.
Feb 17 21:06:01 EDIT systemd[1]: Reached target Network is Online.
-- Subject: A start job for unit network-online.target has finished
successfully
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit network-online.target has finished successfully.
--
-- The job identifier is 105.
```

```
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.4523] keyfile:
add connection /etc/NetworkManager/system-connections/eno1.nmconnection
(db0f6d02-5fca-4290-b3da-dbbd02728756,"eno1")
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.4527] audit:
op="connection-add" uuid="db0f6d02-5fca-4290-b3da-dbbd02728756" name="eno1"
pid=1765 uid=1000 result="success"
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.4530] policy:
auto-activating connection 'eno1' (db0f6d02-5fca-4290-b3da-dbbd02728756)
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.4561] device
(eno1): Activation: starting connection 'eno1' (db0f6d02-5fca-4290-b3da-
dbbd02728756)
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.4562] device
(eno1): state change: disconnected -> prepare (reason 'none', sys-iface-state:
'managed')
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.4564] manager:
NetworkManager state is now CONNECTING
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.5545] device
(eno1): state change: prepare -> config (reason 'none', sys-iface-state:
'managed')
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.5552] device
(eno1): state change: config -> ip-config (reason 'none', sys-iface-state:
'managed')
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.5582] dhcp4
(eno1): activation: beginning transaction (timeout in 45 seconds)
Feb 17 21:07:02 EDIT NetworkManager[720]:   [1581970022.5593] dhcp4
(eno1): dhclient started with pid 1773
Feb 17 21:07:02 EDIT avahi-daemon[717]: Joining mDNS multicast group on
interface eno1.IPv6 with address fe80::f9f0:2e76:1ffa:d4e5.
Feb 17 21:07:02 EDIT avahi-daemon[717]: New relevant interface eno1.IPv6 for
mDNS.
Feb 17 21:07:02 EDIT avahi-daemon[717]: Registering new address record for
fe80::f9f0:2e76:1ffa:d4e5 on eno1.*.
Feb 17 21:07:02 EDIT dhclient[1773]: DHCPDISCOVER on eno1 to 255.255.255.255
port 67 interval 6
Feb 17 21:07:03 EDIT ntpd[798]: error resolving pool 2.debian.pool.ntp.org:
Temporary failure in name resolution (-3)
Feb 17 21:07:04 EDIT ntpd[798]: error resolving pool 1.debian.pool.ntp.org:
Temporary failure in name resolution (-3)
Feb 17 21:07:06 EDIT ntpd[798]: error resolving pool 3.debian.pool.ntp.org:
Temporary failure in name resolution (-3)
Feb 17 21:07:08 EDIT NetworkManager[720]:   [1581970028.5620] device
(eno1): state change: ip-config -> unavailable (reason 'carrier-changed', sys-
iface-state: 'managed')
Feb 17 21:07:08 EDIT NetworkManager[720]:   [1581970028.5946] dhcp4
(eno1): canceled DHCP transaction, DHCP client pid 1773
Feb 17 21:07:08 EDIT NetworkManager[720]:   [1581970028.5947] dhcp4
(eno1): state changed unknown -> done
Feb 17 21:07:08 EDIT avahi-daemon[717]: Withdrawing address record for
fe80::f9f0:2e76:1ffa:d4e5 on eno1.
Feb 17 21:07:08 EDIT avahi-daemon[717]: Leaving mDNS multicast group on
interface eno1.IPv6 with address fe80::f9f0:2e76:1ffa:d4e5.
Feb 17 21:07:08 EDIT avahi-daemon[717]: Interface eno1.IPv6 no longer relevant
for mDNS.
Feb 17 21:07:08 EDIT NetworkManager[720]:   [1581970028.5980] manager:
NetworkManager state is now CONNECTED_LOCAL
Feb 17 21:07:09 EDIT NetworkManager[720]:   [1581970029.1432] device

Bug#951530: nq FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: nq
Version: 0.3.1-3
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

nq fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
nq cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru nq-0.3.1/debian/changelog nq-0.3.1/debian/changelog
--- nq-0.3.1/debian/changelog   2020-02-15 23:23:27.0 +0100
+++ nq-0.3.1/debian/changelog   2020-02-17 21:14:44.0 +0100
@@ -1,3 +1,10 @@
+nq (0.3.1-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 17 Feb 2020 21:14:44 +0100
+
 nq (0.3.1-3) unstable; urgency=medium
 
   * Upstream repository relocated to https://github.com/leahneukirchen
diff --minimal -Nru nq-0.3.1/debian/rules nq-0.3.1/debian/rules
--- nq-0.3.1/debian/rules   2020-02-15 23:23:27.0 +0100
+++ nq-0.3.1/debian/rules   2020-02-17 21:14:34.0 +0100
@@ -6,7 +6,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) $(shell dpkg-buildflags --export=configure)
+   dh_auto_build -- $(shell dpkg-buildflags --export=configure)
 
 override_dh_auto_install:
dh_auto_install -- PREFIX=/usr

Bug#951529: snooze FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: snooze
Version: 0.4-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

snooze fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
snooze cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru snooze-0.4/debian/changelog snooze-0.4/debian/changelog
--- snooze-0.4/debian/changelog 2020-02-15 23:52:28.0 +0100
+++ snooze-0.4/debian/changelog 2020-02-17 21:10:55.0 +0100
@@ -1,3 +1,10 @@
+snooze (0.4-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 17 Feb 2020 21:10:55 +0100
+
 snooze (0.4-2) unstable; urgency=medium
 
   * debian/rules
diff --minimal -Nru snooze-0.4/debian/rules snooze-0.4/debian/rules
--- snooze-0.4/debian/rules 2020-02-15 23:52:28.0 +0100
+++ snooze-0.4/debian/rules 2020-02-17 21:10:54.0 +0100
@@ -6,7 +6,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) $(shell dpkg-buildflags --export=configure)
+   dh_auto_build -- $(shell dpkg-buildflags --export=configure)
 
 override_dh_auto_install:
dh_auto_install -- PREFIX=/usr

Bug#951528: holes FTCBFS: does not pass cross tools to make

[Helmut Grohne]

Source: holes
Version: 0.1-4
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

holes fails to cross build from source, because it does not pass cross
tools to make. The easiest way of doing so - using dh_auto_build - makes
holes cross buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru holes-0.1/debian/changelog holes-0.1/debian/changelog
--- holes-0.1/debian/changelog  2020-02-15 22:45:50.0 +0100
+++ holes-0.1/debian/changelog  2020-02-17 21:13:38.0 +0100
@@ -1,3 +1,10 @@
+holes (0.1-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Let dh_auto_build pass cross tools to make. (Closes: #-1)
+
+ -- Helmut Grohne   Mon, 17 Feb 2020 21:13:38 +0100
+
 holes (0.1-4) unstable; urgency=medium
 
   * Upstream repository relocated to https://github.com/leahneukirchen
diff --minimal -Nru holes-0.1/debian/rules holes-0.1/debian/rules
--- holes-0.1/debian/rules  2020-02-15 22:45:50.0 +0100
+++ holes-0.1/debian/rules  2020-02-17 21:13:38.0 +0100
@@ -6,7 +6,7 @@
dh $@
 
 override_dh_auto_build:
-   $(MAKE) $(shell dpkg-buildflags --export=configure)
+   dh_auto_build -- $(shell dpkg-buildflags --export=configure)
 
 override_dh_auto_install:
dh_auto_install -- PREFIX=/usr

Bug#951497: rumur: building from sources makes machine un-usable or OOM/kills kernel

[Matthew Fernandez]

Yikes, sorry.

The test suite for this package auto-detects the number of CPUs and 
parallelises across all of them. This is not very well behaved when calling it 
from the outer build system, as it doesn’t pay attention to any -j flag you’ve 
passed there. To compound the situation, some of the individual test cases 
themselves are also multithreaded.

I think the simplest solution is to force the test suite to always run 
single-threaded when called via ctest. Can I close this bug by making this 
change when packaging the next upstream release? Or do I also need to upload 
new packages for the existing versions in Debian?

Bug#951526: ITP: r-cran-pixmap -- GNU R bitmap images (Pixel Maps)

[Andreas Tille]

Package: wnpp
Severity: wishlist

Subject: ITP: r-cran-pixmap -- GNU R bitmap images (Pixel Maps)
Package: wnpp
Owner: Andreas Tille 
Severity: wishlist

* Package name: r-cran-pixmap
  Version : 0.4
  Upstream Author : Roger Bivand, Friedrich Leisch and Martin Maechler
* URL : https://cran.r-project.org/package=pixmap
* License : GPL-2
  Programming Lang: GNU R
  Description : GNU R bitmap images (Pixel Maps)
 This GNU R package is a family "pixmap" of classes providing
 methods for creating, plotting and converting bitmapped images
 in three different formats: RGB, grey and indexed pixmaps.

Remark: This package is maintained by Debian R Packages Maintainers at
   https://salsa.debian.org/r-pkg-team/r-cran-pixmap

Bug#951524: network-manager: Cannot connect to VPN for unmanaged wired connection: "Could not find source connection."

[kiemlicz]

Package: network-manager
Version: 1.14.6-2+deb10u1
Severity: important

Dear Maintainer,


   * What led up to the situation?
I want to connect to VPN

Default Debian buster installation
I've imported VPN connection

Trying to connect yields:
Feb 17 20:44:16 EDIT NetworkManager[721]:   [1581968656.1998] audit:
op="connection-activate" uuid="31befe8d-800a-4905-97e4-16cd0aed0c30"
name="EDIT" pid=2104 uid=1000 result="fail" reason="Could not find source
connection."

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I guess it might be caused by the fact that NetworkManager doesn't manage wired
connection.
Yet it is still not what the user expects.
Unfortunately switching the connection to be managed by NetworkManager doesn't
help (the wired connection stuck in activating->deactivating loop, I'm going to
submit another bug)
   * What was the outcome of this action?
Feb 17 20:44:16 EDIT NetworkManager[721]:   [1581968656.1998] audit:
op="connection-activate" uuid="31befe8d-800a-4905-97e4-16cd0aed0c30"
name="EDIT" pid=2104 uid=1000 result="fail" reason="Could not find source
connection."
   * What outcome did you expect instead?
Successful VPN connection

Kind regards
Stanley



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

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

Versions of packages network-manager depends on:
ii  adduser3.118
ii  dbus   1.12.16-1
ii  init-system-helpers1.56+nmu1
ii  libaudit1  1:2.8.4-3
ii  libbluetooth3  5.50-1
ii  libc6  2.28-10
ii  libcurl3-gnutls7.64.0-4
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libgnutls303.6.7-4+deb10u2
ii  libjansson42.12-1
ii  libmm-glib01.10.0-1
ii  libndp01.6-1+b1
ii  libnewt0.520.52.21-4
ii  libnm0 1.14.6-2+deb10u1
ii  libpam-systemd 241-7~deb10u3
ii  libpolkit-agent-1-00.105-25
ii  libpolkit-gobject-1-0  0.105-25
ii  libpsl50.20.2-2
ii  libreadline7   7.0-5
ii  libselinux12.8-1+b1
ii  libsystemd0241-7~deb10u3
ii  libteamdctl0   1.28-1
ii  libudev1   241-7~deb10u3
ii  libuuid1   2.33.1-0.1
ii  lsb-base   10.2019051400
ii  policykit-10.105-25
ii  udev   241-7~deb10u3
ii  wpasupplicant  2:2.7+git20190128+0c1e29f-6+deb10u1

Versions of packages network-manager recommends:
ii  crda 3.18-1
ii  dnsmasq-base [dnsmasq-base]  2.80-1
ii  iptables 1.8.2-4
ii  isc-dhcp-client  4.4.1-2
ii  modemmanager 1.10.0-1
ii  ppp  2.4.7-2+4.1

Versions of packages network-manager suggests:
pn  libteam-utils  

-- no debconf information

Bug#951396: libpam-radius-auth: CVE-2015-9542

[Salvatore Bonaccorso]

Hi,

FTR, whilst one can argue the issue is not that severe to warrant a RC
severity, I'm raising it here since libpam-radius-auth is orphaned now
since some years.

If there is still interest in this pam module it likely needs a
maintainer otherwise we should not release bullseye with
libpam-radius-auth unmaintained.

Regards,
Salvatore

Bug#951522: FTBFS: wants long-removed emacs25

[Adam Borowski]

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

Hi!
I'm afraid this package build-depends on emacs25, which is long since gone.


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

Kernel: Linux 5.6.0-rc1-00073-g6af17278568f (SMP w/64 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)