Bug#964334: segfault repeatedly

[Julien-Benjamin]

Package: chromium
Version: 83.0.4103.116-1~deb10u2
Followup-For: Bug #964334

Like said before, Chromium keeps crashing within a few minutes maximum.

It has also becomes very very slow since the last update.

Happening to me on stable with a few packages from the backports
(kernel 5.4 + nvidia-driver).

Thanks for maintaining this package,

JB

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

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

Versions of packages chromium depends on:
ii  chromium-common83.0.4103.116-1~deb10u2
ii  libasound2 1.1.8-1
ii  libatk-bridge2.0-0 2.30.0-5
ii  libatk1.0-02.30.0-2
ii  libatspi2.0-0  2.30.0-7
ii  libavcodec-extra58 [libavcodec58]  7:4.1.4-1~deb10u1
ii  libavformat58  7:4.1.4-1~deb10u1
ii  libavutil567:4.1.4-1~deb10u1
ii  libc6  2.28-10
ii  libcairo2  1.16.0-4
ii  libcups2   2.2.10-6+deb10u3
ii  libdbus-1-31.12.16-1
ii  libdrm22.4.97-1
ii  libevent-2.1-6 2.1.8-stable-4
ii  libexpat1  2.2.6-2+deb10u1
ii  libflac8   1.3.2-3
ii  libfontconfig1 2.13.1-2
ii  libfreetype6   2.9.1-3+deb10u1
ii  libgbm118.3.6-2+deb10u1
ii  libgcc11:8.3.0-6
ii  libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii  libglib2.0-0   2.58.3-2+deb10u2
ii  libgtk-3-0 3.24.5-1
ii  libharfbuzz0b  2.3.1-1
ii  libicu63   63.1-6+deb10u1
ii  libjpeg62-turbo1:1.5.2-2+b1
ii  libjsoncpp11.7.4-3
ii  liblcms2-2 2.9-3
ii  libminizip11.1-8+b1
ii  libnspr4   2:4.20-1
ii  libnss32:3.42.1-1+deb10u2
ii  libopenjp2-7   2.3.0-2+deb10u1
ii  libopus0   1.3-1
ii  libpango-1.0-0 1.42.4-8~deb10u1
ii  libpangocairo-1.0-01.42.4-8~deb10u1
ii  libpng16-161.6.36-6
ii  libpulse0  12.2-4+deb10u1
ii  libre2-5   20190101+dfsg-2
ii  libsnappy1v5   1.1.7-1
ii  libstdc++6 8.3.0-6
ii  libvpx51.7.0-3+deb10u1
ii  libwebp6   0.6.1-2
ii  libwebpdemux2  0.6.1-2
ii  libwebpmux30.6.1-2
ii  libx11-6   2:1.6.7-1
ii  libx11-xcb12:1.6.7-1
ii  libxcb-dri3-0  1.13.1-2
ii  libxcb11.13.1-2
ii  libxcomposite1 1:0.4.4-2
ii  libxcursor11:1.1.15-2
ii  libxdamage11:1.1.4-3+b3
ii  libxext6   2:1.3.3-1+b2
ii  libxfixes3 1:5.0.3-1
ii  libxi6 2:1.7.9-1
ii  libxml22.9.4+dfsg1-7+b3
ii  libxrandr2 2:1.5.1-1
ii  libxrender11:0.9.10-1
ii  libxslt1.1 1.1.32-2.2~deb10u1
ii  libxss11:1.2.3-1
ii  libxtst6   2:1.2.3-1
ii  zlib1g 1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  83.0.4103.116-1~deb10u2

Versions of packages chromium suggests:
pn  chromium-driver  
ii  chromium-l10n83.0.4103.116-1~deb10u2
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1+deb10u1

Versions of packages chromium-common recommends:
ii  chromium-sandbox83.0.4103.116-1~deb10u2
ii  dunst [notification-daemon] 1.3.2-1
ii  fonts-liberation1:1.07.4-9
ii  gnome-shell [notification-daemon]   3.30.2-11~deb10u1
ii  libgl1-mesa-dri 18.3.6-2+deb10u1
ii  libu2f-udev 1.1.9-1
ii  mate-notification-daemon [notification-daemon]  1.20.2-1
ii  notification-daemon 3.20.0-4
ii  plasma-workspace [notification-daemon]  4:5.14.5.1-1
ii  upower

Bug#964366: bashtop: insecure use of /tmp

[Jakub Wilk]

Package: bashtop
Version: 0.9.19-1
Severity: grave
Tags: security

bashtop creates a Python script in /tmp and runs it. But Python adds the 
directory containing the script to the module search path¹, and /tmp is 
world-writable, so this in insecure. A local user could plant malicious 
Python module in /tmp, which would be executed by bashtop.


Proof of concept:

  $ install -m 644 /path/to/psutil.py /tmp
  $ bashtop
   ___
  < pwned >
   ---
  \   ^__^
   \  (oo)\___
  (__)\   )\/\
  ||w |
  || ||
  Aborted


¹ https://docs.python.org/3/using/cmdline.html#cmdarg-script

-- System Information:
Architecture: i386

Versions of packages bashtop depends on:
ii  bash5.0-6
ii  gawk1:5.0.1+dfsg-1
ii  procps  2:3.3.16-5

Versions of packages bashtop recommends:
ii  lm-sensors  1:3.6.0-2
un  sysstat 
ii  python3-psutil  5.7.0-1
ii  curl7.68.0-1

--
Jakub Wilk
import os; os.system('(tput reset && cowsay pwned) >/dev/tty; kill -ABRT %s' % os.getppid())

Bug#962221: Fixes for CVE-2020-13696 (#962221)

[Vasyl Gello]

Hi Jeremy!

Thanks for contributing the security release! I checked your changes and pushed 
them to the team repo.
I do not have an upload rights, so CCing Sebastian and Mattia.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature

Bug#961843: tags

[Glenn Strauss]

tags 961843 - moreinfo

Bug#961843: buster-pu: package lighttpd/1.4.53-4

[Glenn Strauss]

reattaching debdiff
diff -Nru lighttpd-1.4.53/debian/changelog lighttpd-1.4.53/debian/changelog
--- lighttpd-1.4.53/debian/changelog2019-04-13 00:00:00.0 -0400
+++ lighttpd-1.4.53/debian/changelog2020-03-21 19:30:00.0 -0400
@@ -1,11 +1,67 @@
+lighttpd (1.4.53-4+deb10u1) UNRELEASED; urgency=high
+
+  * QA upload.
+  * backport security, bug, portability fixes from lighttpd 1.4.54, 1.4.55
+  * mod_evhost, mod_flv_streaming:
+[regression] %0 pattern does not match hostnames without the domain part
+https://redmine.lighttpd.net/issues/2932
+  * mod_magnet: Lighttpd crashes on wrong return type in lua script
+https://redmine.lighttpd.net/issues/2938
+  * failed assertion on incoming bad request with server.error-handler
+https://redmine.lighttpd.net/issues/2941
+  * mod_wstunnel: fix wstunnel.ping-interval for big-endian architectures
+https://redmine.lighttpd.net/issues/2944
+  * fix abort in server.http-parseopts with url-path-2f-decode enabled
+https://redmine.lighttpd.net/issues/2945
+  * remove repeated slashes in server.http-parseopts with 
url-path-dotseg-remove, including leading "//"
+  * [regression][Bisected] lighttpd uses way more memory with POST since 1.4.52
+https://redmine.lighttpd.net/issues/2948
+  * OPTIONS should return 2xx status for non-existent resources if Allow is set
+https://redmine.lighttpd.net/issues/2939
+  * use high precision stat timestamp (on systems where available) in etag
+  * mod_authn_ldap/mod_cgi race condition, "Can't contact LDAP server"
+https://redmine.lighttpd.net/issues/2940
+  * SUN_LEN in sock_addr.c (1.4.53, 1.4.54)
+https://redmine.lighttpd.net/issues/2962
+  * Embedded vim command line in conf file with no comment (#) hangs server
+https://redmine.lighttpd.net/issues/2980
+  * mod_authn_gssapi: 500 if fail to delegate creds
+https://redmine.lighttpd.net/issues/2967
+  * mod_authn_gssapi: option to store delegated creds
+https://redmine.lighttpd.net/issues/2967
+  * mod_auth: require digest uri= match original URI
+HTTP digest authentication not compatible with some clients
+https://redmine.lighttpd.net/issues/2974
+  * mod_auth: send Authentication-Info nextnonce when nonce is approaching 
expiration
+  * mod_auth: http_auth_const_time_memeq improvement
+  * mod_auth: http_auth_const_time_memeq_pad()
+  * mod_auth: use constant time comparison when comparing digests
+  * stricter request header parsing: reject WS following header field-name
+https://redmine.lighttpd.net/issues/2985
+  * stricter request header parsing: reject Transfer-Encoding + Content-Length
+https://redmine.lighttpd.net/issues/2985
+  * mod_openssl: reject invalid ALPN
+  * mod_accesslog: parse multiple cookies
+https://redmine.lighttpd.net/issues/2986
+  * preserve %2b and %2B in query string
+https://redmine.lighttpd.net/issues/2999
+  * mod_auth: close connection after bad password
+mitigation slows down brute force password attacks
+https://redmine.lighttpd.net/boards/3/topics/8885
+  * do not accept() > server.max-connections
+  * update /var/run -> /run for systemd (closes: #929203)
+
+ -- Glenn Strauss   Sat, 21 Mar 2020 18:30:00 -0500
+
 lighttpd (1.4.53-4) unstable; urgency=high
 
+  * QA upload.
   * fix mixed use of srv->split_vals array (regression)
   * mod_magnet:fix invalid script return-type crash
   * fix assertion with server.error-handler
   * mod_wstunnel:fix wstunnel.ping-interval for big-endian architectures
   * fix abort in server.http-parseopts with url-path-2f-decode enabled
-CVE-2019-11072 (closes #926885)
+CVE-2019-11072 (closes: #926885)
 
  -- Glenn Strauss   Sat, 13 Apr 2019 00:00:00 -0400
 
diff -Nru lighttpd-1.4.53/debian/.gitlab-ci.yml 
lighttpd-1.4.53/debian/.gitlab-ci.yml
--- lighttpd-1.4.53/debian/.gitlab-ci.yml   2019-04-13 00:00:00.0 
-0400
+++ lighttpd-1.4.53/debian/.gitlab-ci.yml   2020-03-21 19:30:00.0 
-0400
@@ -1,13 +1,7 @@
-include: 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+include:
+  - https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml
+  - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
 
-build:
-extends: .build-unstable
-
-lintian:
-extends: .test-lintian
-
-autopkgtest:
-extends: .test-autopkgtest
-
-piuparts:
-extends: .test-piuparts
+variables:
+  # Disable reprotest until salsa-ci-team/pipeline#26 is resolved.
+  SALSA_CI_DISABLE_REPROTEST: 1
diff -Nru 
lighttpd-1.4.53/debian/patches/config-update-var-run-run-for-systemd.patch 
lighttpd-1.4.53/debian/patches/config-update-var-run-run-for-systemd.patch
--- lighttpd-1.4.53/debian/patches/config-update-var-run-run-for-systemd.patch  
1969-12-31 19:00:00.0 -0500
+++ lighttpd-1.4.53/debian/patches/config-update-var-run-run-for-systemd.patch  
2020-03-21 19:30:00.0 -0400
@@ -0,0 +1,67 @@
+From 15cdc313b500e2473de7bafdcf1c703dbfd11e56 Mon Sep 

Bug#587398:

[Ais Ha]

0559345202

Bug#960860: PCSX2 was updated in repository, thanks. This bug can be closed.

[Beta Version]

Bug#964359: smplayer: Please remove smplayer from the main repositories. It pops a dialog box asking for a donation every so many sessions. This is detrimental to Debian reputation. If others follow t

[Vasyl Gello]

Hi Eduardo!

I briefly checked smplayer Salsa git and it seems that the nag is controlled by 
DONATE_REMINDER define:
https://salsa.debian.org/multimedia-team/smplayer/-/blob/master/src/basegui.h#L76

I can try patching it in Debian but I am not smplayer user so I will need some 
time to start smplayer for a couple of days.
-- 
Vasyl Gello
==
Certified SolidWorks Expert

Mob.:+380 (98) 465 66 77

E-Mail: vasek.ge...@gmail.com

Skype: vasek.gello
==
호랑이는 죽어서 가죽을 남기고 사람은 죽어서 이름을 남긴다

signature.asc
Description: PGP signature

Bug#964365: diffoscope: comparing squashfs filesystems: Could not open foo.squashfs, because No such file or directory

[Paul Wise]

Package: diffoscope
Version: 150
Severity: normal

When comparing squashfs filesystems I get an error saying the first
filesystem could not be found, even though I created it just before. 

$ mkdir foo bar
$ touch foo/foo bar/foo
$ chronic mksquashfs foo foo.squashfs
$ chronic mksquashfs bar bar.squashfs
$ diffoscope foo.squashfs bar.squashfs 
--- foo.squashfs
+++ bar.squashfs
│┄ Command `unsquashfs -n -f -no -li -d . foo.squashfs` failed with exit code 
1. Standard error:
│┄ Could not open foo.squashfs, because No such file or directory
@@ -1,8 +1,8 @@
-: 6873 7173 0200  eeac 025f  0200  hsqs..._
+: 6873 7173 0200  f1ac 025f  0200  hsqs..._
 0010:   0100 1100 c000 0100 0400   
 0020: 2000    c700      ...
 0030: bf00         
 0040: 6000    8c00     `...
 0050: a100    b100     
 0060: 2a00 78da 6362 58c0 c800 044f d730 c583  *.x.cbXO.0..
 0070: 1940 f01f 08a0 4c06 4686 1770 7926 a818  .@L.F..py&..

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing-debug
  APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 
'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 
'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.0-1-nouveau-extra-crash-debug-info-amd64 (SMP w/4 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU:en 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages diffoscope depends on:
ii  python33.8.2-3
ii  python3-distro 1.5.0-1
ii  python3-distutils  3.8.3-2
ii  python3-libarchive-c   2.9-0.1
ii  python3-magic  2:0.4.15-4
ii  python3-pkg-resources  46.1.3-1

Versions of packages diffoscope recommends:
ii  abootimg 0.6-1+b2
ii  acl  2.2.53-8
ii  apksigner0.9-1
ii  apktool  2.4.1-1
ii  binutils-multiarch   2.34-8
ii  bzip21.0.8-3
ii  caca-utils   0.99.beta19-2.1
ii  colord   1.4.4-2
ii  db-util  5.3.1+nmu1
ii  default-jdk [java-sdk]   2:1.11-72
ii  default-jdk-headless 2:1.11-72
pn  device-tree-compiler 
pn  docx2txt 
ii  e2fsprogs1.45.6-1
ii  enjarify 1:1.0.3-4
ii  ffmpeg   7:4.3-2
ii  fontforge-extras 1:20190801~dfsg-4
pn  fp-utils 
ii  genisoimage  9:1.1.11-3.1
ii  gettext  0.19.8.1-10
ii  ghc  8.8.1+dfsg1+is+8.6.5+dfsg1-3
ii  ghostscript  9.52~dfsg-1
ii  giflib-tools 5.1.9-1
ii  gnumeric 1.12.47-1
ii  gnupg2.2.20-1
ii  gnupg-utils  2.2.20-1
pn  hdf5-tools   
ii  imagemagick  8:6.9.10.23+dfsg-2.1+b2
ii  imagemagick-6.q16 [imagemagick]  8:6.9.10.23+dfsg-2.1+b2
ii  jsbeautifier 1.11.0-1
ii  libarchive-tools 3.4.3-1
ii  llvm 1:9.0-49.1
ii  lz4 [liblz4-tool]1.9.2-2
pn  mono-utils   
ii  ocaml-nox4.08.1-8
pn  odt2txt  
pn  oggvideotools
ii  openjdk-11-jdk [java-sdk]11.0.7+10-3
ii  openssh-client   1:8.3p1-1
ii  openssl  1.1.1g-1
ii  pgpdump  0.33-2
ii  poppler-utils0.71.0-6
pn  procyon-decompiler   
ii  python3-argcomplete  1.8.1-1.3
ii  python3-binwalk  2.2.0+dfsg1-1
ii  python3-debian   0.1.37
ii  python3-defusedxml   0.6.0-2
ii  python3-guestfs  1:1.42.0-6
ii  python3-jsondiff 1.1.1-4
pn  python3-pdfminer 
ii  python3-progressbar  2.5-2
pn  python3-pypdf2   
ii  python3-pyxattr  0.6.1-2+b1
ii  python3-rpm  4.14.2.1+dfsg1-1.1+b1
ii  python3-tlsh 3.4.4+20151206-1.3+b2
pn  r-base-core  
ii  rpm2cpio 4.14.2.1+dfsg1-1.1+b1
ii  sng  1.1.0-4
ii  sqlite3  3.32.3-1
ii  squashfs-tools   1:4.4-2
ii  tcpdump  4.9.3-6
ii  unzip   

Bug#963703: 963703: gnutls28 3.5.8-5+deb9u5 flagged for acceptance

[R hertoric]

--
*From:* Adam D Barratt 
*Sent:* Friday, July 3, 2020 1:55:08 PM
*To:* 963...@bugs.debian.org <963...@bugs.debian.org>
*Cc:* 963703-submit...@bugs.debian.org <963703-submit...@bugs.debian.org>
*Subject:* Bug#963703: gnutls28 3.5.8-5+deb9u5 flagged for acceptance

package nnn.d...@debian.org

tags 963703 = stretch pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance
into the proposed-updates queue for Debian stretch.

Thanks for your contribution!

Upload details
==

Package: gnutls28
Version: 3.5.8-5+deb9u5

Explanation: fix memory corruption issue [CVE-2019-3829]; fix memory leak;
add support for zero length session tickets, fix connection errors on
TLS1.2 sessions to some hosting providers

Bug#964351: stretch-pu: package intel-microcode/3.20200616.1~deb9u1

[R hertoric]

Freeze {diffstat:
 changelog  |   8 ++
 debian/changelog   |  19 
 intel-ucode/06-4e-03   | Bin 104448 -> 101376
bytes
 intel-ucode/06-5e-03   | Bin 104448 -> 101376
bytes
 microcode-20200609.d => microcode-20200616.d   |   0
 releasenote|  32
-
 s000406E3_m00C0_r00D6.fw   | Bin 101376 -> 0 bytes
 bin => supplementary-ucode-20200616_BDX-ML.bin |   0
 8 files changed, 32 insertions(+), 27 deletions(-)

On Sun, Jul 5, 2020, 3:51 PM Henrique de Moraes Holschuh 
wrote:

> Package: release.debian.org
> Severity: normal
> Tags: stretch
> User: release.debian@packages.debian.org
> Usertags: pu
>
> I'd like to update the intel-microcode packages in buster and stretch to
> 3.202006016.1~deb{9,10}u1.
>
> This is basically the same packages already in buster and stretch via
> buster/strech-security, with one extra microcode revert.  It effectively
> fixes a regression introduced by the security updates for a single
> processor model (Xeon E3 with signature 0x506e3).
>
> The upload via s-p-u/os-p-u was suggested by the security team: we
> agreed the revert of microcode 0x506e3 did not really deserve a DSA and
> could be handled through the upcoming point releases (it affects only
> *some* motherboards with such processors).
>
> The git diff is attached.  Unfortunately, stable debdiff gets mightly
> confused by a directory rename that only has binary files inside, so git
> diff does a much better job here.
>
> diffstat:
>  changelog  |   8 ++
>  debian/changelog   |  19 
>  intel-ucode/06-4e-03   | Bin 104448 -> 101376
> bytes
>  intel-ucode/06-5e-03   | Bin 104448 -> 101376
> bytes
>  microcode-20200609.d => microcode-20200616.d   |   0
>  releasenote|  32
> -
>  s000406E3_m00C0_r00D6.fw   | Bin 101376 -> 0 bytes
>  bin => supplementary-ucode-20200616_BDX-ML.bin |   0
>  8 files changed, 32 insertions(+), 27 deletions(-)
>
> --
>   Henrique Holschuh
>

Bug#963267: buster-pu: package multipath-tools/0.7.9-3+deb10u1

[R hertoric]

Send reply to edre...@gmail.com

On Sun, Jun 21, 2020, 11:57 AM Chris Hofstaedtler  wrote:

> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
>
> Dear Stable Release Managers,
>
> I'd like to push a fix for #959727 to buster. The bug causes us some
> trouble with block devices that are -sometimes- missing. I've tested
> the fix a while ago (on buster), and it seemed to help.
>
> Please consider this.
>
> Thanks,
> Chris
>
> diff -Nru multipath-tools-0.7.9/debian/changelog
> multipath-tools-0.7.9/debian/changelog
> --- multipath-tools-0.7.9/debian/changelog  2019-03-18
> 15:26:38.0 +
> +++ multipath-tools-0.7.9/debian/changelog  2020-06-21
> 16:41:48.0 +
> @@ -1,3 +1,9 @@
> +multipath-tools (0.7.9-3+deb10u1) buster; urgency=medium
> +
> +  * [775fe68] kpartx: use correct path to partx in udev rule (Closes:
> #959727)
> +
> + -- Chris Hofstaedtler   Sun, 21 Jun 2020 16:41:48 +
> +
>  multipath-tools (0.7.9-3) unstable; urgency=medium
>
>* [51a7724] Reliably extract the running systemd version
> diff -Nru multipath-tools-0.7.9/debian/patches/partx-path.patch
> multipath-tools-0.7.9/debian/patches/partx-path.patch
> --- multipath-tools-0.7.9/debian/patches/partx-path.patch   1970-01-01
> 00:00:00.0 +
> +++ multipath-tools-0.7.9/debian/patches/partx-path.patch   2020-06-21
> 16:41:48.0 +
> @@ -0,0 +1,14 @@
> +Use Debian-specific path for partx (from util-linux).
> +
> +Index: multipath-tools/kpartx/del-part-nodes.rules
> +===
> +--- multipath-tools.orig/kpartx/del-part-nodes.rules
>  multipath-tools/kpartx/del-part-nodes.rules
> +@@ -28,6 +28,6 @@ GOTO="end_del_part_nodes"
> + LABEL="del_part_nodes"
> + IMPORT{db}="DM_DEL_PART_NODES"
> + ENV{DM_DEL_PART_NODES}!="1", ENV{DM_DEL_PART_NODES}="1", \
> +-  RUN+="/usr/sbin/partx -d --nr 1-1024 $env{DEVNAME}"
> ++  RUN+="/usr/bin/partx -d --nr 1-1024 $env{DEVNAME}"
> +
> + LABEL="end_del_part_nodes"
> diff -Nru multipath-tools-0.7.9/debian/patches/series
> multipath-tools-0.7.9/debian/patches/series
> --- multipath-tools-0.7.9/debian/patches/series 2019-02-08
> 13:38:26.0 +
> +++ multipath-tools-0.7.9/debian/patches/series 2020-06-21
> 16:41:48.0 +
> @@ -6,3 +6,4 @@
>  fix-usrmerge-paths.patch
>  11-dm-mpath-fix-DM_UDEV_RULES_VSN-check.patch
>  enable-cross-build.patch
> +partx-path.patch
>
>

Bug#964351: stretch-pu: package intel-microcode/3.20200616.1~deb9u1

[Henrique de Moraes Holschuh]

On Sun, 05 Jul 2020, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> On Sun, 2020-07-05 at 17:46 -0300, Henrique de Moraes Holschuh wrote:
> > I'd like to update the intel-microcode packages in buster and stretch
> > to 3.202006016.1~deb{9,10}u1.
> > 
> > This is basically the same packages already in buster and stretch via
> > buster/strech-security, with one extra microcode revert.  It
> > effectively fixes a regression introduced by the security updates for
> > a single processor model (Xeon E3 with signature 0x506e3).
> > 
> 
> Please go ahead.

Uploaded, thanks!

-- 
  Henrique Holschuh

Bug#964350: buster-pu: package intel-microcode/3.20200616.1~deb10u1

[Henrique de Moraes Holschuh]

On Sun, 05 Jul 2020, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> On Sun, 2020-07-05 at 17:45 -0300, Henrique de Moraes Holschuh wrote:
> > I'd like to update the intel-microcode packages in buster and stretch
> > to 3.202006016.1~deb{9,10}u1.
> > 
> > This is basically the same packages already in buster and stretch via
> > buster/strech-security, with one extra microcode revert.  It
> > effectively fixes a regression introduced by the security updates for
> > a single processor model (Xeon E3 with signature 0x506e3).
> 
> Please go ahead.

Uploded, thanks!

-- 
  Henrique Holschuh

Bug#964364: evolution-ews: E-mail sent via EWS replaces the recipient's name with a copy of their e-mail address.

[Pavel N. Krivitsky]

Package: evolution-ews
Version: 3.36.3-1
Severity: important

Dear Maintainer,

Since about a month ago, when I send an e-mail via my employer's Office365
setup using Evolution's EWS support, I find that the message that is placed
into the Sent folder has the correct recipient names, but the message that is
actually sent appears to replace the recipient's name with their e-mail
address. For example,

In composer: To: John Smith 
In Sent folder: To: John Smith 
Actually received: To: john.sm...@example.com 

I have attempted to isolate the problem by sending messages to myself. To
summarise, I find that the name is preserved if *any* of the following
situations:

* Sending through the Office365 web Outlook (the webmail interface).
* Sending from Evolution through Office356's SMTP interface
(smtp.office365.com).
* The recipient is within the employer's domain (e.g., if my domain is
example.biz, then
John Smith  -> preserved
John Smith  -> jon.sm...@example.net

)

It is only when sending to a recipient outside the employer's domain using
Evolution's EWS that the problem occurs. For messages with multiple
heterogeneous recipients, those in the domain have their names preserved, those
outside rewritten.




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

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

Versions of packages evolution-ews depends on:
ii  evolution3.36.3-1
ii  evolution-data-server3.36.3-1
ii  libc62.31-0experimental0
ii  libcamel-1.2-62  3.36.3-1
ii  libebackend-1.2-10   3.36.3-1
ii  libebook-1.2-20  3.36.3-1
ii  libebook-contacts-1.2-3  3.36.3-1
ii  libecal-2.0-13.36.3-1
ii  libedata-book-1.2-26 3.36.3-1
ii  libedata-cal-2.0-1   3.36.3-1
ii  libedataserver-1.2-243.36.3-1
ii  libedataserverui-1.2-2   3.36.3-1
ii  libevolution 3.36.3-1
ii  libglib2.0-0 2.64.3-2
ii  libgtk-3-0   3.24.20-1
ii  libical3 3.0.8-1+b1
ii  libmspack0   0.10.1-2
ii  libpango-1.0-0   1.44.7-4
ii  libsoup2.4-1 2.70.0-1
ii  libxml2  2.9.10+dfsg-5+b1

evolution-ews recommends no packages.

evolution-ews suggests no packages.

-- no debconf information

Bug#964358: libedit2: readline() SIGSEGV

[federicjohnson]

Package: libedit2
Version:  3.1-20181209-1

Hello.
Found a bug in libedit package which causes readline() to segfault after 
writting a large amount of data.
It crashes somewhere in function e_wgets() called from e_gets() from readline().
Looks like a buffer overflow, but appears to be crashing after trying to 
derreference a null pointer
I don't think this would represent a security issue even if it is exploitable 
in some way, but i report it just in case.

Bug appears to be fixed in newer versions of the lib, solved by building from 
source and installing the sid release of package 
"libedit2_3.1-20191231-1_amd64.deb".

Proof of concept:

readline.c:

/* gcc readline.c -o readline -ledit */
#include 

int main(int argc, char **argv)
{
    readline("Give me a line: ");
}



poc.py:

#!/usr/bin/env python3 

import pty
import os

def read(fd):
data = os.read(fd, 1024)
if data.decode().find('Give me a line') != -1:
os.write(fd, bytes("A"*1000, 'ascii'))
return data

r = pty.spawn([os.getcwd() + '/readline'], read)

if r & 0xF == 11:
print ("\nGot SIGSEGV")


Output:

gcc readline.c -o readline -ledit && python3 poc.py
Give me a line: A
AAA
AAA
AAA
AAA
Got SIGSEGV
-

Bug#964363: syncthing: Please update to version 1.6.1

[Giorgos Skafidas]

Package: syncthing
Version: 1.1.4~ds1-5
Severity: wishlist

Dear Maintainer,

please consider updating Syncthing to its latest upstream version, 1.6.1.

Thank you for your efforts!

Bug#964362: chromium crash frequently, SEGV_MAPERR

[ayan]

Package: chromium
Version: 83.0.4103.116-2
Severity: important

chromium
[5734:5734:0706/092317.088155:ERROR:sandbox_linux.cc(374)] InitializeSandbox()
called with multiple threads in process gpu-process.
[5695:5716:0706/092317.979847:ERROR:database.cc(1632)] History sqlite error 5,
errno 0: database is locked, sql: PRAGMA auto_vacuum
[5695:5716:0706/092317.979932:ERROR:database.cc(1632)] History sqlite error 5,
errno 0: database is locked, sql: PRAGMA journal_mode=TRUNCATE
[5695:5717:0706/092528.357148:ERROR:connection_factory_impl.cc(420)] Failed to
connect to MCS endpoint with error -118
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
[5695:5717:0706/093054.868663:ERROR:socket_stream.cc(218)] Closing stream with
result -2
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Fontconfig error: Cannot load default config file
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
[5734:5734:0706/094110.141746:ERROR:shared_image_manager.cc(212)]
SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a
non-existent mailbox.
[5734:5734:0706/094110.143585:ERROR:shared_image_manager.cc(212)]
SharedImageManager::ProduceSkia: Trying to Produce a Skia representation from a
non-existent mailbox.
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Received signal 11 SEGV_MAPERR 7f0164171c37
#0 0x55c04ba68c69 (/usr/lib/chromium/chromium+0x52b3c68)
#1 0x55c04b9c7ef3 (/usr/lib/chromium/chromium+0x5212ef2)
#2 0x55c04ba687f1 (/usr/lib/chromium/chromium+0x52b37f0)
#3 0x7f818e616110 (/usr/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f)
#4 0x7f8189701d3c (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b)
#5 0x7f8189703f33 

Bug#861182: Bug#963732: RFS ete

[zhao feng]

Thanks a lot!

> Uploaded.  Unfortunately I realised to late that the python3-*
> dependencies are not resolved automatically.  I've added these manually
> in Git and will upload with the source-only upload that is needed after
> the package is accepted.

To run the unittest we need some more dependencies like `scipy`, `qt`
but they are optional for the runtime of `ete3`.
That is, users can still use some API of `ete3` without `qt`, `skbio `.

On Sun, Jul 5, 2020 at 9:31 PM Andreas Tille  wrote:
>
> On Sun, Jul 05, 2020 at 07:49:41PM +0800, zhao feng wrote:
> > I have enabled the pipeline in one fork
> > https://salsa.debian.org/zhaofeng-shu33-guest/python-ete3/-/pipelines/153000
> > and I think the build error does not exist any more.
>
> Yes, I've uploaded now.
>
> > > Finally I'm wondering whether the binary package should be rather
> > > Architecture: all .
> > Done
>
> Uploaded.  Unfortunately I realised to late that the python3-*
> dependencies are not resolved automatically.  I've added these manually
> in Git and will upload with the source-only upload that is needed after
> the package is accepted.
>
> Thanks for your work on this
>
>  Andreas.
>
> PS: Future discussion is better on debian-...@lists.debian.org.
> In case you might have other packages that are interesting for
> bioinformatics please also do this in Debian Med team.
>
> --
> http://fam-tille.de

Bug#935532: debmake: Upstream-Contact field

[Osamu Aoki]

Control: tags -1 pending

I guess I need to update corresponding part in debmake-doc

Osamu

Bug#953724: package description

[Osamu Aoki]

Jonas

Rest assured I "removed lines"

What I did: 

 * Knock-out incorrect package description lines.
 * Keep copyright parsing python code as is
 * Keep encouraging statement in template file to use licensecheck

Sorry for my confusing message :-)

I didn't go for "different" thinking that I may make debmake to call
licensecheck in future.

On Sun, 2020-07-05 at 17:03 +0200, Jonas Smedegaard wrote:
> Quoting Osamu Aoki (2020-07-05 16:25:40)
> > Control: tags -1 pending
> > 
> > (Patch commuted to salsa.)
> > 
> > Yes your updated licensecheck is as good in functionality with
> > 
> >  --deb-machine
> > 
> > option!  This is incorrect.
> > 
> > I admit my script has some shortcomings.  But I also realize
> > replacing
> > it with your licensecheck doesn't solve this.  So I will keep it as
> > is
> > while urging people to use licensecheck in generated template file.
> 
> You mean that you will keep the package description as-is?
> 
> Please consider _reprhasing_ (not removing), to avoid users
> misreading 
> it as debmake being a superset of licensecheck which is not true.
> 
> Concretely, I propose to replace the word "more" with the word 
> "different".
> 
> 
>  - Jonas
> 
From 8aa67476b1a053d669e284ed66e7c01f76fc21ba Mon Sep 17 00:00:00 2001
From: Osamu Aoki 
Date: Sun, 5 Jul 2020 23:09:07 +0900
Subject: [PATCH 1/2] Update package description

Drop incorrect statement on licensecheck.

Signed-off-by: Osamu Aoki 
---
 debian/changelog | 5 -
 debian/control   | 1 -
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index d4cd4e1..a51fccb 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -4,7 +4,10 @@ debmake (4.3.2-1) UNRELEASED; urgency=medium
   * d/changelog: Remove trailing whitespaces
 
   [VictorRodriguez]
-  *  Warning instead of error debmake fail due to missing shebang in setup.py
+  * Warning instead of error debmake fail due to missing shebang in setup.py
+
+  [ Osamu Aoki ]
+  * Drop incorrect statement on licensecheck.  Closes: #953724
 
  -- vmrod   Mon, 06 May 2019 15:29:40 -0500
 
diff --git a/debian/control b/debian/control
index ef4dfe8..739eee5 100644
--- a/debian/control
+++ b/debian/control
@@ -47,4 +47,3 @@ Description: helper script to make the Debian source package
  .
  This debmake command also scans copyright and license texts in the source
  files to help crafting the proper DEP-5 compatible debian/copyright file.
- It does more than what licensecheck(1) offers.
-- 
2.20.1

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

On Mon, 06 Jul 2020 at 01:48:45 +0200, Vincent Lefevre wrote:
> On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote:
>> On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote:
>>> On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
 The raison d'être of wait_for_dropbear() is to avoid handing the
 execution over to init(1) with a running ipconfig process or unclean
 network stack.  This is what the race condition described in #943459 is
 about.  wait_for_dropbear() somewhat of a hack, but ipconfig doesn't
 seem to react to SIGTERM and I couldn't do better at the time.
>>> 
>>> How about SIGKILL, then?
>> 
>> No.
> 
> Why no?

Not gonna send SIGKILL processes not under my control.  Bad practice.
It might leave all sort crap behind, I need a documented abort
mechanism.
 
>>> The user has more knowledge than initramfs. For instance, he knows
>>> whether the link is present. And he generally knows the typical
>>> time he has to wait for the DHCP server (unless a major problem
>>> occurs with the server, in which case he may have to wait any time).
>>> So it's better to leave the control to the user.
>> 
>> I could certainly make the timeout configurable, but that's be an option
>> hardcoded in the initramfs (or the kernel command line) so probably not
>> ideal to manually flip occasionally when the users knows there is no
>> link present.
> 
> If you let the user run a script that controls the timeout, that
> would be better. For instance, a typical setting when dropbear is
> used to unlock the disk(s) would be to set the timeout so that the
> following conditions are *both* satisfied:
> 
> 1. Some lower bound has been reached (say 10 seconds).
> 
> 2. The passphrase has been validated.
> 
> This makes sense because in this case, it is useless to abort
> wait_for_dropbear() while the passphrase has not been validated
> yet.

wait_for_dropbear() runs at init-bottom stage, so after dm-crypt devices
have been mapped (if cryptsetup-initramfs is installed and the crypttab
is not empty, that is).  So you're essentially asking to set the timeout
to 10s.

> BTW, I've just noticed that the timeout introduces a second annoying
> regression: If there is a temporary issue with the DHCP server just
> after the machine has been restarted, so that the timeout is reached,
> the user will not be able to unlock the disk until he can go back in
> front of his machine!

You mean the timeout from configure_networking() it init-premout stage?
That's not a regression from 2020.79-1, didn't touch the premount script
for many years.  Yes configure_networking() might fail and leave the
system without network, however dropbear-initramfs is not the place to
fix this.  configure_networking() comes from initramfs-tools, and AFAICT
the same problem arises for NFS mounts.

> My proposal would solve this issue.

Then I probably didn't understand the issue you're describing.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964361: wsclean: FTBFS in sid schroot with 'debian/rules binary'

[McIntyre, Vincent (CASS, Marsfield)]

Package: wsclean
Version: 2.9-2
Severity: minor

I was trying to build this version on buster and got build failures.
I tried in a sid schroot and got the same failure, so reporting.

I was building with 'debian/rules binary'.
Also tried 'debian/rules build; debian/rules binary', as per [1].
Building with 'dpkg-buildpackage -us -uc -b' does work, however.
If this is expected behaviour, please just close the bug.

Everything is fine up until the dh_install stage, which fails like this:

make[2]: Entering directory '/var/tmp/wsclean/obj-x86_64-linux-gnu'
make[2]: Nothing to be done for 'preinstall'.
make[2]: Leaving directory '/var/tmp/wsclean/obj-x86_64-linux-gnu'
Install the project...
/usr/bin/cmake -P cmake_install.cmake
-- Install configuration: "None"
-- Installing: /var/tmp/wsclean/debian/tmp/usr/bin/wsclean
-- Set runtime path of "/var/tmp/wsclean/debian/tmp/usr/bin/wsclean" to 
"/usr/lib:/usr/lib/x86_64-linux-gnu/hdf5/serial"
-- Installing: /var/tmp/wsclean/debian/tmp/usr/lib/libwsclean.a
-- Installing: /var/tmp/wsclean/debian/tmp/usr/include/wscleaninterface.h
make[1]: Leaving directory '/var/tmp/wsclean/obj-x86_64-linux-gnu'
   dh_install
dh_install: Cannot find (any matches for) "usr/lib/*/libwsclean*.so.*" (tried 
in ., debian/tmp)

dh_install: libwsclean2 missing files: usr/lib/*/libwsclean*.so.*
dh_install: Cannot find (any matches for) "usr/lib/*/libwsclean.a" (tried in ., 
debian/tmp)

dh_install: wsclean-dev missing files: usr/lib/*/libwsclean.a
dh_install: Cannot find (any matches for) "usr/lib/*/libwsclean.so" (tried in 
., debian/tmp)

dh_install: wsclean-dev missing files: usr/lib/*/libwsclean.so
dh_install: missing files, aborting
make: *** [debian/rules:10: binary] Error 25

I noticed that libwsclean.a ends up in
  debian/tmp/usr/lib/libwsclean.a
rather than in
  debian/tmp/usr/lib/x86_64-linux-gnu/libwsclean.a
which may be significant.
There are no files in debian/tmp/usr/lib/x86_64-linux-gnu/
and that directory does not exist.

Kind regards
Vince

[1] https://www.debian.org/doc/manuals/maint-guide/build.en.html

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

Kernel: Linux 4.19.0-9-amd64 (SMP w/8 CPU cores)
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: unable to detect

Versions of packages wsclean depends on:
ii  libc62.30-8
ii  libgcc-s110.1.0-4
ii  libstdc++6   10.1.0-4
pn  libwsclean2  

wsclean recommends no packages.

Versions of packages wsclean suggests:
pn  wsclean-dev  

# git remote -v
origin  https://salsa.debian.org/debian-astro-team/wsclean.git (fetch)
origin  https://salsa.debian.org/debian-astro-team/wsclean.git (push)

# git log -1
commit 387fecd8cfdc88c86b46c0a8c1195b2e779e6d2d (HEAD -> master, tag: 
debian/2.9-2, origin/master, origin/HEAD)
Author: Ole Streicher 
Date:   Tue Apr 28 08:37:40 2020 +0200

No-change source-only re-upload

Bug#964360: libghc-doctemplates-doc: depends on unavailable haddock-interface-33

[Norbert Preining]

Package: libghc-doctemplates-doc
Version: 0.2.2.1-4
Severity: serious
Justification: uninstallable

Hi

seems that libghc-doctemplates-doc is not installable.

$ sudo apt install libghc-doctemplates-doc
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 libghc-doctemplates-doc : Depends: haddock-interface-33 but it is not 
installable
   Recommends: ghc-doc but it is not going to be 
installed
   Recommends: libghc-aeson-doc but it is not going to 
be installed
   Recommends: libghc-blaze-html-doc but it is not 
going to be installed
E: Unable to correct problems, you have held broken packages.

Best

Norbert

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

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

Versions of packages libghc-doctemplates-doc depends on:
pn  haddock-interface-33  

Versions of packages libghc-doctemplates-doc recommends:
pn  ghc-doc
pn  libghc-aeson-doc   
pn  libghc-blaze-html-doc  
ii  libjs-mathjax  2.7.8+dfsg-1

libghc-doctemplates-doc suggests no packages.

Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1

[R hertoric]

Yes, it is correct.

On Sun, Jul 5, 2020, 7:00 PM Samuel Henrique  wrote:

> Hello, I believe you picked the wrong bug id, could you double check that,
> please?
>
> Thanks
>

Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1

[Samuel Henrique]

Hello, I believe you picked the wrong bug id, could you double check that,
please?

Thanks

Bug#964228: buster-pu: package nmap/7.70+dfsg1-6+deb10u1

[R hertoric]

> tags -1 + confirmed
Bug #964350 [release.debian.org] buster-pu: package
intel-microcode/3.20200616.1~deb10u1
Added tag(s) confirmed.

On Fri, Jul 3, 2020, 4:24 PM Samuel Henrique  wrote:

> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
>
> A backported upstream patch [0] is required to fix #940284 [1] on nmap;
> Bug title: autogeneration of ssl key in ssl server mode of ncat is broken
>
> The issue itself is well described in both BTS [1] and the upstream
> bug report [2], but the summary of it is that the openssl shipped with
> Buster requires a key with minimum size of 2048b, while nmap 7.70
> generates one sized 1024b. This has been fixed in 7.80 (which is the
> version on Testing right now).
>
> The debdiff is attached to this email,
>
> Thanks,
>
> [0]
> https://github.com/nmap/nmap/commit/25db5fbb0d8fb88b6e7f4f298c862cd05ed0f8b1
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=940284
> [2] https://github.com/nmap/nmap/pull/1310
>
> --
> Samuel Henrique 
>

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-06 01:06:58 +0200, Guilhem Moulin wrote:
> On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote:
> > On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
> >> The raison d'être of wait_for_dropbear() is to avoid handing the
> >> execution over to init(1) with a running ipconfig process or unclean
> >> network stack.  This is what the race condition described in #943459 is
> >> about.  wait_for_dropbear() somewhat of a hack, but ipconfig doesn't
> >> seem to react to SIGTERM and I couldn't do better at the time.
> > 
> > How about SIGKILL, then?
> 
> No.

Why no?

> > The user has more knowledge than initramfs. For instance, he knows
> > whether the link is present. And he generally knows the typical
> > time he has to wait for the DHCP server (unless a major problem
> > occurs with the server, in which case he may have to wait any time).
> > So it's better to leave the control to the user.
> 
> I could certainly make the timeout configurable, but that's be an option
> hardcoded in the initramfs (or the kernel command line) so probably not
> ideal to manually flip occasionally when the users knows there is no
> link present.

If you let the user run a script that controls the timeout, that
would be better. For instance, a typical setting when dropbear is
used to unlock the disk(s) would be to set the timeout so that the
following conditions are *both* satisfied:

1. Some lower bound has been reached (say 10 seconds).

2. The passphrase has been validated.

This makes sense because in this case, it is useless to abort
wait_for_dropbear() while the passphrase has not been validated
yet.

Then there are 2 cases:

1. The user is in front of his machine. He also knows whether he
should get an answer from the DHCP server. Then, depending on the
context and the messages from the DHCP client that appear on the
screen, he can validate his passphrase ASAP (e.g. because there is
no link, so that there cannot be an answer from a DHCP server) or
wait for the DHCP server to answer (the user may be the admin of
the DHCP server, e.g. for a machine at home, so that he will know
what to do).

2. The user is not in front of his machine, which may be far away.
The only solution is to unlock the disk(s) via SSH. Since the user
cannot type the passphrase, there will never be a timeout (due to
condition 2), which is exactly what the user wants.

Note that with these rules, condition 1 is even normally useless.
It may only be useful to avoid a mistake from the user, or if the
user has confidence that it will always work in practice (if the
chosen value is large enough), so that the user would validate
his passphrase ASAP.

BTW, I've just noticed that the timeout introduces a second annoying
regression: If there is a temporary issue with the DHCP server just
after the machine has been restarted, so that the timeout is reached,
the user will not be able to unlock the disk until he can go back in
front of his machine! My proposal would solve this issue.

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

Bug#963548: chromium: Affects security upgrade as well

[Boyd Stephen Smith Jr.]

Package: chromium
Version: 83.0.4103.116-1~deb10u2
Followup-For: Bug #963548

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Maintainer,

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

   * What led up to the situation?
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


- -- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (900, 'stable-updates'), (900, 'stable'), (850, 
'proposed-updates'), (700, 'testing'), (500, 'unstable'), (300, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages chromium depends on:
ii  chromium-common  83.0.4103.116-1~deb10u2
ii  libasound2   1.1.8-1
ii  libatk-bridge2.0-0   2.30.0-5
ii  libatk1.0-0  2.30.0-2
ii  libatspi2.0-02.30.0-7
ii  libavcodec58 7:4.1.4-1~deb10u1
ii  libavformat587:4.1.4-1~deb10u1
ii  libavutil56  7:4.1.4-1~deb10u1
ii  libc62.30-8
ii  libcairo21.16.0-4
ii  libcups2 2.2.10-6+deb10u3
ii  libdbus-1-3  1.12.16-1
ii  libdrm2  2.4.97-1
ii  libevent-2.1-6   2.1.8-stable-4
ii  libexpat12.2.6-2+deb10u1
ii  libflac8 1.3.2-3
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.10.1-2
ii  libgbm1  18.3.6-2+deb10u1
ii  libgcc-s1 [libgcc1]  10.1.0-4
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk-3-0   3.24.5-1
ii  libharfbuzz0b2.3.1-1
ii  libicu63 63.1-6+deb10u1
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  libjsoncpp1  1.7.4-3
ii  liblcms2-2   2.9-3
ii  libminizip1  1.1-8+b1
ii  libnspr4 2:4.25-1
ii  libnss3  2:3.42.1-1+deb10u2
ii  libopenjp2-7 2.3.0-2+deb10u1
ii  libopus0 1.3-1
ii  libpango-1.0-0   1.42.4-8~deb10u1
ii  libpangocairo-1.0-0  1.42.4-8~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpulse012.2-4+deb10u1
ii  libre2-5 20190101+dfsg-2
ii  libsnappy1v5 1.1.8-1
ii  libstdc++6   10.1.0-4
ii  libvpx5  1.7.0-3+deb10u1
ii  libwebp6 0.6.1-2
ii  libwebpdemux20.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libx11-6 2:1.6.7-1
ii  libx11-xcb1  2:1.6.9-2+b1
ii  libxcb-dri3-01.13.1-2
ii  libxcb1  1.13.1-2
ii  libxcomposite1   1:0.4.5-1
ii  libxcursor1  1:1.1.15-2
ii  libxdamage1  1:1.1.4-3+b3
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxi6   2:1.7.9-1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  libxslt1.1   1.1.32-2.2~deb10u1
ii  libxss1  1:1.2.3-1
ii  libxtst6 2:1.2.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages chromium recommends:
ii  chromium-sandbox  83.0.4103.116-1~deb10u2

Versions of packages chromium suggests:
pn  chromium-driver  
pn  chromium-l10n
pn  chromium-shell   

Versions of packages chromium-common depends on:
ii  x11-utils  7.7+4
ii  xdg-utils  1.1.3-1+deb10u1

Versions of packages chromium-common recommends:
ii  chromium-sandbox83.0.4103.116-1~deb10u2
ii  fonts-liberation1:1.07.4-9
ii  libgl1-mesa-dri 18.3.6-2+deb10u1
ii  libu2f-udev 1.1.9-1
ii  notification-daemon 3.20.0-4
ii  plasma-workspace [notification-daemon]  4:5.14.5.1-1
ii  upower  0.99.10-1

Versions of packages chromium-sandbox depends on:
ii  libc6  2.30-8

- -- no debconf information

-BEGIN PGP SIGNATURE-

iHQEARECADQWIQTFhn3a8g2plxzZYyjnmmovsbVAWQUCXwJZzxYcYnNzQGlndWFu
YXN1aWNpZGUubmV0AAoJEOeaai+xtUBZsmQAn31sYIMQksDT8rRa0Mq81G087y/T
AKCOE4uoE69+cvvdsx/Tw4cq3m5agA==
=ZoTW
-END PGP SIGNATURE-

Bug#963267: buster-pu: package multipath-tools/0.7.9-3+deb10u1

[R hertoric]

Id rather talk about call me 5045038792

On Sun, Jun 21, 2020, 11:57 AM Chris Hofstaedtler  wrote:

> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
>
> Dear Stable Release Managers,
>
> I'd like to push a fix for #959727 to buster. The bug causes us some
> trouble with block devices that are -sometimes- missing. I've tested
> the fix a while ago (on buster), and it seemed to help.
>
> Please consider this.
>
> Thanks,
> Chris
>
> diff -Nru multipath-tools-0.7.9/debian/changelog
> multipath-tools-0.7.9/debian/changelog
> --- multipath-tools-0.7.9/debian/changelog  2019-03-18
> 15:26:38.0 +
> +++ multipath-tools-0.7.9/debian/changelog  2020-06-21
> 16:41:48.0 +
> @@ -1,3 +1,9 @@
> +multipath-tools (0.7.9-3+deb10u1) buster; urgency=medium
> +
> +  * [775fe68] kpartx: use correct path to partx in udev rule (Closes:
> #959727)
> +
> + -- Chris Hofstaedtler   Sun, 21 Jun 2020 16:41:48 +
> +
>  multipath-tools (0.7.9-3) unstable; urgency=medium
>
>* [51a7724] Reliably extract the running systemd version
> diff -Nru multipath-tools-0.7.9/debian/patches/partx-path.patch
> multipath-tools-0.7.9/debian/patches/partx-path.patch
> --- multipath-tools-0.7.9/debian/patches/partx-path.patch   1970-01-01
> 00:00:00.0 +
> +++ multipath-tools-0.7.9/debian/patches/partx-path.patch   2020-06-21
> 16:41:48.0 +
> @@ -0,0 +1,14 @@
> +Use Debian-specific path for partx (from util-linux).
> +
> +Index: multipath-tools/kpartx/del-part-nodes.rules
> +===
> +--- multipath-tools.orig/kpartx/del-part-nodes.rules
>  multipath-tools/kpartx/del-part-nodes.rules
> +@@ -28,6 +28,6 @@ GOTO="end_del_part_nodes"
> + LABEL="del_part_nodes"
> + IMPORT{db}="DM_DEL_PART_NODES"
> + ENV{DM_DEL_PART_NODES}!="1", ENV{DM_DEL_PART_NODES}="1", \
> +-  RUN+="/usr/sbin/partx -d --nr 1-1024 $env{DEVNAME}"
> ++  RUN+="/usr/bin/partx -d --nr 1-1024 $env{DEVNAME}"
> +
> + LABEL="end_del_part_nodes"
> diff -Nru multipath-tools-0.7.9/debian/patches/series
> multipath-tools-0.7.9/debian/patches/series
> --- multipath-tools-0.7.9/debian/patches/series 2019-02-08
> 13:38:26.0 +
> +++ multipath-tools-0.7.9/debian/patches/series 2020-06-21
> 16:41:48.0 +
> @@ -6,3 +6,4 @@
>  fix-usrmerge-paths.patch
>  11-dm-mpath-fix-DM_UDEV_RULES_VSN-check.patch
>  enable-cross-build.patch
> +partx-path.patch
>
>

Bug#964359: smplayer: Please remove smplayer from the main repositories. It pops a dialog box asking for a donation every so many sessions. This is detrimental to Debian reputation. If others follow t

[Eduardo GV]

Package: smplayer
Version: 18.10.0~ds0-1
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
Every so many times Smplayer is used, an anoying dialog box asking for money 
pops up. For now it is only smplayer, but if others follow the example, we will 
essentially turn Debian into shareware. A pop up asking for money is 
detrimental to Debian reputation.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages smplayer depends on:
ii  libc6   2.28-10
ii  libgcc1 1:8.3.0-6
ii  libqt5core5a5.11.3+dfsg1-1+deb10u3
ii  libqt5dbus5 5.11.3+dfsg1-1+deb10u3
ii  libqt5gui5  5.11.3+dfsg1-1+deb10u3
ii  libqt5network5  5.11.3+dfsg1-1+deb10u3
ii  libqt5script5   5.11.3+dfsg-3
ii  libqt5widgets5  5.11.3+dfsg1-1+deb10u3
ii  libqt5xml5  5.11.3+dfsg1-1+deb10u3
ii  libstdc++6  8.3.0-6
ii  libx11-62:1.6.7-1
ii  mplayer 2:1.3.0-8+b4
ii  zlib1g  1:1.2.11.dfsg-1

Versions of packages smplayer recommends:
ii  smplayer-l10n18.10.0~ds0-1
ii  smplayer-themes  1:18.6.0-1

smplayer suggests no packages.

-- no debconf information

Bug#964346: buster-pu: package wav2cdr/2.3.4-2+deb10u1

[R hertoric]

 * Use C99 fixed-size integer types to fix runtime assertion on
64bit architectures other than amd64 and alpha. (Closes: #956927)
  * Stop linking to the dead Homepage
Stop sending all packages thru broken  security needs to update tty

On Sun, Jul 5, 2020, 3:24 PM Adrian Bunk  wrote:

> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
>
>   * Use C99 fixed-size integer types to fix runtime assertion on
> 64bit architectures other than amd64 and alpha. (Closes: #956927)
>   * Stop linking to the dead Homepage.
>

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Guilhem Moulin]

On Mon, 06 Jul 2020 at 00:54:42 +0200, Vincent Lefevre wrote:
> On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
>> The raison d'être of wait_for_dropbear() is to avoid handing the
>> execution over to init(1) with a running ipconfig process or unclean
>> network stack.  This is what the race condition described in #943459 is
>> about.  wait_for_dropbear() somewhat of a hack, but ipconfig doesn't
>> seem to react to SIGTERM and I couldn't do better at the time.
> 
> How about SIGKILL, then?

No.
 
>> Consider a slow DHCP setup where ipconfig gets a lease after 45s or so.
> 
> With a temporary DHCP server failure, it can be more than the current
> timeout of 60 seconds.

Of course.  Like most thresholds this is at attempt at finding a
reasonable default, not something that covers all cases…
 
>> While it's running you unlock drives so the boot process can proceed.
>> If the execution is handed over to init(1) right away, without waiting
>> for ipconfig to settle or give up (nor for dropbear to start), then
>> ipconfig and dropbear will race with the network stack resp. SSHd of the
>> main system.  This might yield a static IP being overwritten by DHCP,
>> like in #943459, and/or OpenSSH failing to start because dropbear
>> listens on 22/tcp already.
> 
> The user has more knowledge than initramfs. For instance, he knows
> whether the link is present. And he generally knows the typical
> time he has to wait for the DHCP server (unless a major problem
> occurs with the server, in which case he may have to wait any time).
> So it's better to leave the control to the user.

I could certainly make the timeout configurable, but that's be an option
hardcoded in the initramfs (or the kernel command line) so probably not
ideal to manually flip occasionally when the users knows there is no
link present.

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964351: stretch-pu: package intel-microcode/3.20200616.1~deb9u1

[R hertoric]

Package intel-microcode} freeze{3.20200616.1~deb9u1

On Sun, Jul 5, 2020, 4:03 PM Adam D. Barratt 
wrote:

> Control: tags -1 + confirmed
>
> On Sun, 2020-07-05 at 17:46 -0300, Henrique de Moraes Holschuh wrote:
> > I'd like to update the intel-microcode packages in buster and stretch
> > to 3.202006016.1~deb{9,10}u1.
> >
> > This is basically the same packages already in buster and stretch via
> > buster/strech-security, with one extra microcode revert.  It
> > effectively fixes a regression introduced by the security updates for
> > a single processor model (Xeon E3 with signature 0x506e3).
> >
>
> Please go ahead.
>
> Regards,
>
> Adam
>
>

Bug#964350: buster-pu: package intel-microcode/3.20200616.1~deb10u1

[R hertoric]

3.202006016.1~deb{9,10}u1{ፈርeeዝ}

On Sun, Jul 5, 2020, 3:48 PM Henrique de Moraes Holschuh 
wrote:

> Package: release.debian.org
> Severity: normal
> Tags: buster
> User: release.debian@packages.debian.org
> Usertags: pu
>
> I'd like to update the intel-microcode packages in buster and stretch to
> 3.202006016.1~deb{9,10}u1.
>
> This is basically the same packages already in buster and stretch via
> buster/strech-security, with one extra microcode revert.  It effectively
> fixes a regression introduced by the security updates for a single
> processor model (Xeon E3 with signature 0x506e3).
>
> The upload via s-p-u/os-p-u was suggested by the security team: we
> agreed the revert of microcode 0x506e3 did not really deserve a DSA and
> could be handled through the upcoming point releases (it affects only
> *some* motherboards with such processors).
>
> The git diff is attached.  Unfortunately, stable debdiff gets mightly
> confused by a directory rename that only has binary files inside, so git
> diff does a much better job here.
>
> diffstat:
>  changelog  |   8 ++
>  debian/changelog   |  19 
>  intel-ucode/06-4e-03   | Bin 104448 -> 101376
> bytes
>  intel-ucode/06-5e-03   | Bin 104448 -> 101376
> bytes
>  microcode-20200609.d => microcode-20200616.d   |   0
>  releasenote|  32
> -
>  s000406E3_m00C0_r00D6.fw   | Bin 101376 -> 0 bytes
>  bin => supplementary-ucode-20200616_BDX-ML.bin |   0
>  8 files changed, 32 insertions(+), 27 deletions(-)
>
> --
>   Henrique Holschuh
>

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

[Graham Inggs]

Hi Adrian

On Sun, 5 Jul 2020 at 19:02, Adrian Bunk  wrote:
> This is #962550.

Are you sure?

The failing test was with ligclib1 0.11.8-1 from testing and gff2aplot
2.0-13 from unstable.

Regards
Graham

Bug#964187: cryptsetup: takes one minute to unlock the disk with a passphrase

[Vincent Lefevre]

On 2020-07-05 16:34:05 +0200, Guilhem Moulin wrote:
> On Sun, 05 Jul 2020 at 12:08:41 +0200, Vincent Lefevre wrote:
> > On 2020-07-04 01:07:15 +0200, Guilhem Moulin wrote:
> >> That would introduce back the race condition described in #943459.
> > 
> > I don't think so, as this would be equivalent to the current code when
> > it reaches the 60-second timeout, except that the wait_for_dropbear()
> > function will return earlier (with return value 1).
> 
> The raison d'être of wait_for_dropbear() is to avoid handing the
> execution over to init(1) with a running ipconfig process or unclean
> network stack.  This is what the race condition described in #943459 is
> about.  wait_for_dropbear() somewhat of a hack, but ipconfig doesn't
> seem to react to SIGTERM and I couldn't do better at the time.

How about SIGKILL, then?

> If wait_for_dropbear() were to have an abort mechanism that didn't wait
> for ipconfig to settle or give up, then we would reintroduce the race
> condition.
> 
> > Thus this would be no worse than the current code.
> 
> Consider a slow DHCP setup where ipconfig gets a lease after 45s or so.

With a temporary DHCP server failure, it can be more than the current
timeout of 60 seconds.

> While it's running you unlock drives so the boot process can proceed.
> If the execution is handed over to init(1) right away, without waiting
> for ipconfig to settle or give up (nor for dropbear to start), then
> ipconfig and dropbear will race with the network stack resp. SSHd of the
> main system.  This might yield a static IP being overwritten by DHCP,
> like in #943459, and/or OpenSSH failing to start because dropbear
> listens on 22/tcp already.

The user has more knowledge than initramfs. For instance, he knows
whether the link is present. And he generally knows the typical
time he has to wait for the DHCP server (unless a major problem
occurs with the server, in which case he may have to wait any time).
So it's better to leave the control to the user.

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

Bug#805310: libsasl2-modules: Annoying message "DIGEST-MD5 common mech free" with slapd

[Vincent Lefevre]

On 2020-07-02 11:57:41 +0200, Paride Legovini wrote:
> I didn't try it, but replacing
> 
>   /etc/logcheck/ignore.d.server/libsasl2-modules
> 
> with the version proposed by IOhannes m zmoelnig [1] may work around the
> issue. If the change is confirmed to be working it should be very easy
> for the package maintainers to include it in the next upload.
> 
> Paride
> 
> [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805310#10

This does not work for me, but I haven't rebooted the machine.
Restarting the rsyslog and saslauthd services has no effect.

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

Bug#964318: gosa login broken with PHP 7.4

[Holger Levsen]

control: severity -1 important

On Sun, Jul 05, 2020 at 05:42:01PM +0200, Wolfgang Schweer wrote:
> while working on Debian Edu Bullseye, I noticed that it is no longer 
> possible to log into the GOSa² web interface after a main server 
> upgrade.

this pretty much sounds like a 'serious' bug ( = unsuitable for a stable 
release as per https://www.debian.org/Bugs/Developer#severities and not
just important ("major impact,  without rendering it completely unusable
to everyone") or less, though I will follow Wolfgang's example and opt 
for the lesser severity. (maybe it still works with new accounts?)

Mike, please raise the severity further / as needed and more importantly, 
please upload a fix! ;) & thank you for maintaining GOSa², we need it! :)


-- 
cheers,
Holger

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


signature.asc
Description: PGP signature

Bug#964177: SIGSEGV after regression "fixed"

[Boyd Stephen Smith Jr.]

found 964177 83.0.4103.116-1~deb10u2
thanks

---8<---
% apt-cache policy chromium
chromium:
  Installed: 83.0.4103.116-1~deb10u2
  Candidate: 83.0.4103.116-1~deb10u2
  Version table:
 83.0.4103.116-2 700
700 http://deb.debian.org/debian testing/main amd64 Packages
500 http://deb.debian.org/debian sid/main amd64 Packages
 *** 83.0.4103.116-1~deb10u2 900
900 http://deb.debian.org/debian-security stable/updates/main amd64 
Packages
100 /var/lib/dpkg/status
 80.0.3987.162-1~deb10u1 900
900 http://deb.debian.org/debian stable/main amd64 Packages
--->8---

---8<---
Fontconfig error: Cannot load default config file
Received signal 11 SEGV_MAPERR 7f01944019c7
#0 0x563e3ac9e469 (/usr/lib/chromium/chromium+0x51f9468)
#1 0x563e3abfc193 (/usr/lib/chromium/chromium+0x5157192)
#2 0x563e3ac9dff1 (/usr/lib/chromium/chromium+0x51f8ff0)
#3 0x7f96bc801110 (/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f)
#4 0x7f96b6afbd3c (/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b)
#5 0x7f96b6afdf33 (/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32)
#6 0x7f96b6affbf9 __libc_malloc
#7 0x563e3acb5bee operator new()
#8 0x7f96b6d86a2c std::__cxx11::basic_string<>::reserve()
#9 0x7f96b6d7c498 std::__cxx11::basic_stringbuf<>::overflow()
#10 0x7f96b6d8504a std::basic_streambuf<>::xsputn()
#11 0x7f96b6d77714 std::__ostream_insert<>()
#12 0x563e3ac9e7b9 (/usr/lib/chromium/chromium+0x51f97b8)
#13 0x563e3ac9e844 (/usr/lib/chromium/chromium+0x51f9843)
#14 0x563e3ac0e9d2 (/usr/lib/chromium/chromium+0x51699d1)
#15 0x563e3ac10b1e (/usr/lib/chromium/chromium+0x516bb1d)
#16 0x563e3937962a (/usr/lib/chromium/chromium+0x38d4629)
#17 0x563e3937967e (/usr/lib/chromium/chromium+0x38d467d)
#18 0x563e38a1f98f (/usr/lib/chromium/chromium+0x2f7a98e)
#19 0x563e39333559 (/usr/lib/chromium/chromium+0x388e558)
#20 0x563e3933379e (/usr/lib/chromium/chromium+0x388e79d)
#21 0x563e3937ce67 (/usr/lib/chromium/chromium+0x38d7e66)
#22 0x563e393a8ac2 (/usr/lib/chromium/chromium+0x3903ac1)
#23 0x563e393a8d7e (/usr/lib/chromium/chromium+0x3903d7d)
#24 0x563e3937963f (/usr/lib/chromium/chromium+0x38d463e)
#25 0x563e3937967e (/usr/lib/chromium/chromium+0x38d467d)
#26 0x563e38a1f98f (/usr/lib/chromium/chromium+0x2f7a98e)
#27 0x563e38cd6f53 (/usr/lib/chromium/chromium+0x3231f52)
#28 0x563e39001e22 (/usr/lib/chromium/chromium+0x355ce21)
#29 0x563e3add1aff (/usr/lib/chromium/chromium+0x532cafe)
#30 0x563e3add8274 (/usr/lib/chromium/chromium+0x5333273)
#31 0x563e3add616d (/usr/lib/chromium/chromium+0x533116c)
#32 0x563e3add4e2c (/usr/lib/chromium/chromium+0x532fe2b)
#33 0x563e3adcd913 (/usr/lib/chromium/chromium+0x5328912)
#34 0x563e3ade977b (/usr/lib/chromium/chromium+0x534477a)
#35 0x563e3ade9a41 (/usr/lib/chromium/chromium+0x5344a40)
#36 0x563e3ade9040 (/usr/lib/chromium/chromium+0x534403f)
#37 0x563e38cbfe26 (/usr/lib/chromium/chromium+0x321ae25)
#38 0x563e38cbf94c (/usr/lib/chromium/chromium+0x321a94b)
#39 0x563e38cbbd51 (/usr/lib/chromium/chromium+0x3216d50)
#40 0x563e38cb261b (/usr/lib/chromium/chromium+0x320d61a)
#41 0x563e38ca4f1b (/usr/lib/chromium/chromium+0x31fff1a)
#42 0x563e38ca4c03 (/usr/lib/chromium/chromium+0x31ffc02)
#43 0x563e38cc39a6 (/usr/lib/chromium/chromium+0x321e9a5)
#44 0x563e3acbb28a (/usr/lib/chromium/chromium+0x5216289)
#45 0x7f96bae159ba (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.6.0.2+0x229b9)
#46 0x7f96bae16537 event_base_loop
#47 0x563e3acbb510 (/usr/lib/chromium/chromium+0x521650f)
#48 0x563e3ac5ac05 (/usr/lib/chromium/chromium+0x51b5c04)
#49 0x563e3ac32a1d (/usr/lib/chromium/chromium+0x518da1c)
#50 0x563e38f9dd93 (/usr/lib/chromium/chromium+0x34f8d92)
#51 0x563e3ac713f7 (/usr/lib/chromium/chromium+0x51cc3f6)
#52 0x563e3acae0ce (/usr/lib/chromium/chromium+0x52090cd)
#53 0x7f96bc7f5f27 start_thread
#54 0x7f96b6b7331f clone
  r8: 0077  r9: 0050 r10: 7f96ac9d3a70 r11: 
007c
  
 r12: 7f969420 r13: 7f969430 r14: 7f96942c1bc0 r15: 
0040
  
  di: 0021  si: 0004  bp: 0020  bx: 
7f01944019bf
  
  dx: 7f969480  ax: 7f969428b970  cx: 7f01944019bf  sp: 
7f96ac9d3880
  
  ip: 7f96b6afbd3c efl: 00010202 cgf: 002b0033 erf: 
0004
  
 trp: 000e msk:  cr2: 7f01944019c7
[end of stack trace]
Calling _exit(1). Core file will not be generated.
--->8---

-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


signature.asc
Description: This is a 

Bug#964177: SIGABRT with 83.0.4103.116-1~deb10u2

[Boyd Stephen Smith Jr.]

83.0.4103.116-1~deb10u2 was supposed to be fixed, and I'm still seeing random 
crashes.  It's not technically a segfault, but SIGABRT is close.

---8<---
free(): double free detected in tcache 2
   
[23/160]
Received signal 6
#0 0x55b366fa2469 (/usr/lib/chromium/chromium+0x51f9468) 
#1 0x55b366f00193 (/usr/lib/chromium/chromium+0x5157192) 
#2 0x55b366fa1ff1 (/usr/lib/chromium/chromium+0x51f8ff0) 
#3 0x7efe15ead110 (/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f)
#4 0x7efe1015d781 gsignal   
#5 0x7efe1014755b abort   
#6 0x7efe101a0038 (/lib/x86_64-linux-gnu/libc-2.30.so+0x7e037)
#7 0x7efe101a73da (/lib/x86_64-linux-gnu/libc-2.30.so+0x853d9)
#8 0x7efe101a921d (/lib/x86_64-linux-gnu/libc-2.30.so+0x8721c)
#9 0x55b364e6514b (/usr/lib/chromium/chromium+0x30bc14a) 
#10 0x55b36567d5d8 (/usr/lib/chromium/chromium+0x38d45d7)
#11 0x55b36567d67e (/usr/lib/chromium/chromium+0x38d467d)
#12 0x55b364d2398f (/usr/lib/chromium/chromium+0x2f7a98e)
#13 0x55b365637559 (/usr/lib/chromium/chromium+0x388e558)
#14 0x55b36563779e (/usr/lib/chromium/chromium+0x388e79d)   
  
#15 0x55b365680e67 (/usr/lib/chromium/chromium+0x38d7e66)   
  
#16 0x55b3656acac2 (/usr/lib/chromium/chromium+0x3903ac1)   
  
#17 0x55b3656acd7e (/usr/lib/chromium/chromium+0x3903d7d)   
  
#18 0x55b36567d63f (/usr/lib/chromium/chromium+0x38d463e)   
  
#19 0x55b36567d67e (/usr/lib/chromium/chromium+0x38d467d) 
#20 0x55b364d2398f (/usr/lib/chromium/chromium+0x2f7a98e)
--->8---

-- 
Boyd Stephen Smith Jr.   ,= ,-_-. =.
b...@iguanasuicide.net   ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/\_/


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

Bug#964357: alttab: fails to start: ***buffer overflow detected ***: alttab terminated - Aborted

[rv]

Package: alttab
Version: 1.3.0-1
Severity: important

Dear Maintainer,

   * What led up to the situation?

Don't know, maybe an update?

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

$ alttab 
*** buffer overflow detected ***: alttab terminated
Abortado

Then, opened issue at:
https://github.com/sagb/alttab/issues/96

   * What was the outcome of this action?

Can't cope at the time with the complexities of developer's proposed steps.

   * What outcome did you expect instead?

Simple solution. ;)


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

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

Versions of packages alttab depends on:
ii  libc62.30-8
ii  libpng16-16  1.6.37-2
ii  libx11-6 2:1.6.9-2+b1
ii  libxft2  2.3.2-2
ii  libxrandr2   2:1.5.1-1
ii  libxrender1  1:0.9.10-1
ii  zlib1g   1:1.2.11.dfsg-2

alttab recommends no packages.

Versions of packages alttab suggests:
ii  fonts-dejavu-core  2.37-2

-- no debconf information

Bug#964113: RFS: materia-kde/20200614-1 [ITP] -- Port of the popular GTK theme Materia for Plasma 5

[Boyuan Yang]

Hi Leandro,

在 2020-07-01星期三的 22:57 -0300，Leandro Cunha写道：
> Dear mentors,
> 
> The code is in my Salsa repository until the creation of the
> mentioned VCS and I am not allowed to access the project file. After
> that, the work will be centered on the informed VCS. 
> 
> [0] https://salsa.debian.org/leandrocunha/materia-kde

I have imported your project into salsa.debian.org/debian/materia-kde.
Please use this new repo for future packaging.

After review, there are several issues that need to be fixed before we
proceed. I fixed several issues (as well added me as the uploader) in 
https://salsa.debian.org/debian/materia-kde/-/commit/42145c86d8ac221353ee5c439b3dce15f25928c5
 and you may review the changes here. Besides, I reimported the
upstream source code to guarantee that we are using exactly the same
source code as upstream tagged in the GitHub repository. You may find
corresponding changes in the upstream/latest branch.

There is one serious issue left that cannot be fixed by myself: in
debian/copyright file, you listed that the files are licensed under
GPL-3. In the license  text, you wrote that the files are licensed
under "GPL version 3 or any later version", which contradicts with each
other. Since the LICENSE only contains the license of GPL-3, I have no
idea whether the whole project is under GPL-3 or GPL-3+. Please contact
the upstream and clarify the license condition. Ideally please provide
such clarification in upstream README.md file.

Please feel free to let me know if you have any questions regarding my
changes. Let me know after the licensing issue is solved so that the
package can be uploaded.

-- 
Regards,
Boyuan Yang


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

Bug#964356: libcoarrays-{mpich,openmpi}-dev: not co-installable due to usr/lib/x86_64-linux-gnu/libcaf_mpi.a

[Andreas Beckmann]

Package: libcoarrays-mpich-dev,libcoarrays-openmpi-dev
Version: 2.9.0-1
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package failed to install
because it tries to overwrite other packages files ...

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

  Selecting previously unselected package libcoarrays-openmpi-dev:amd64.
  Preparing to unpack .../38-libcoarrays-openmpi-dev_2.9.0-1_amd64.deb ...
  Unpacking libcoarrays-openmpi-dev:amd64 (2.9.0-1) ...
  dpkg: error processing archive 
/tmp/apt-dpkg-install-wpbcvq/38-libcoarrays-openmpi-dev_2.9.0-1_amd64.deb 
(--unpack):
   trying to overwrite '/usr/lib/x86_64-linux-gnu/libcaf_mpi.a', which is also 
in package libcoarrays-mpich-dev:amd64 2.9.0-1
  Errors were encountered while processing:
   /tmp/apt-dpkg-install-wpbcvq/38-libcoarrays-openmpi-dev_2.9.0-1_amd64.deb
 

cheers,

Andreas

Bug#964355: roundcube: Cross-Site Scripting (XSS) vulnerability via HTML messages with malicious svg/namespace

[Guilhem Moulin]

Source: roundcube
Severity: important
Tags: security
Control: found -1 1.4.6+dfsg.1-3
Control: found -1 1.3.13+dfsg.1-1~deb10u1
Control: found -1 1.2.3+dfsg.1-4+deb9u5

AFAICT no CVE was assigned for this yet.  1.2.x, 1.3.x and 1.4.x
branches are affected.  Upstream fix:
 
1.4.x 
https://github.com/roundcube/roundcubemail/commit/3e8832d029b035e3fcfb4c75839567a9580b4f82
1.3.x 
https://github.com/roundcube/roundcubemail/commit/19502419757a976dbd55ce5a746610c5bab7896b
1.2.x 
https://github.com/roundcube/roundcubemail/commit/f3d1566cf223eb04f47b6dfffcd88753f66c36ee

-- 
Guilhem.


signature.asc
Description: PGP signature

Bug#964354: gatling: new upstream version (0.15)

[Benjamin Valentin]

Package: gatling

Version: 0.13-6.1


A new version of the software is available.

gatling 0.15 was released 2016-10-03 and fixed several bugs.

It would be great to have this update packaged in Debian.

Bug#964293: hubicfuse: error while loading libssl.so.1.0.0

[Stephen Kitt]

Control: tag -1 + stretch
Control: fixed -1 3.0.1-1

On Sun, 5 Jul 2020 11:51:43 +0200, Stephen Kitt  wrote:
> On Sun, 05 Jul 2020 11:42:08 +0200, rpnpif  wrote:
> > The command hubicfuse /mnt/hubic -o noauto_cache,sync_read
> > get the result :
> > hubicfuse: error while loading shared libraries: libssl.so.1.0.0: cannot
> > open shared object file: No such file or directory
> > 
> > but libssl1.1 was needed.  
> 
> What does
> 
>   command -v hubicfuse
> 
> show?

Also, do you have libssl1.0.2 installed? libcurl3 depends on it in Stretch so
it should be available if you have hubicfuse installed...

Regards,

Stephen


pgpNA9noBZQ_2.pgp
Description: OpenPGP digital signature

Bug#964311: libmatroska6v5: New upstream release 1.6.0

[Matteo F. Vescovi]

On 2020-07-05 at 14:48 (+02), Christian Marillat wrote:
> Package: libmatroska6v5
>
> Dear Maintainer,
>
> Please package this new version needed by mkvtoolnix 48.0.0

FYI, both libebml and libmatroska had a SONAME bump within their new
releases v1.4.0 and v1.6.0, respectively.
Packages are now in NEW queue for approval/rejection by FTP-Masters.


-- 
Matteo F. Vescovi || Debian Developer
GnuPG KeyID: 4096R/0x8062398983B2CF7A


signature.asc
Description: PGP signature

Bug#964194: gitlab: "internal API unreachable" when pushing something to repository

[Frederik Himpe]

Pirate Praveen schreef op 2020-07-05 23:00:


In 2 days and 70+ rebuilds we have gitlab working with ruby 2.7 (just
tested git clone and git push).



Once you confirm, I can push these packages to fasttrack.debian.net


Sorry, I cannot test it any more because in the meantime I migrated to 
the omnibus packages.


Thank you for your work though.

Regards,
--
Frederik Himpe 
Vrije Universiteit Brussel

Bug#964353: libpappsomspp FTBFS: Boost not yet found

[Adrian Bunk]

Source: libpappsomspp
Version: 0.7.5-1
Severity: serious
Tags: ftbfs

https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libpappsomspp.html
https://buildd.debian.org/status/package.php?p=libpappsomspp

...
-- CMAKE_CURRENT_BINARY_DIR: /<>/obj-aarch64-linux-gnu
-- Compiling in release mode.
-- CMAKE_BUILD_TYPE: Release.
-- Boost not yet found. Searching for it.
CMake Error at 
/usr/lib/aarch64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:117 
(find_package):
  Could not find a package configuration file provided by "boost_filesystem"
  (requested version 1.71.0) with any of the following names:

boost_filesystemConfig.cmake
boost_filesystem-config.cmake

  Add the installation prefix of "boost_filesystem" to CMAKE_PREFIX_PATH or
  set "boost_filesystem_DIR" to a directory containing one of the above
  files.  If "boost_filesystem" provides a separate development package or
  SDK, be sure it has been installed.
Call Stack (most recent call first):
  /usr/lib/aarch64-linux-gnu/cmake/Boost-1.71.0/BoostConfig.cmake:182 
(boost_find_component)
  /usr/share/cmake-3.16/Modules/FindBoost.cmake:443 (find_package)
  CMakeLists.txt:172 (find_package)


-- Configuring incomplete, errors occurred!

Bug#964265: ITP: exfatprogs -- tools to create, check and label exFAT filesystems

[Sven Hoexter]

On Sun, Jul 05, 2020 at 09:35:14AM +0300, Andrei POPESCU wrote:
> On Sb, 04 iul 20, 19:56:45, s...@stormbind.net wrote:
> > While fuse-exfat can be coinstalled at any moment exfat-utils and
> > exfatprogs will for now conflict with each other.
> 
> Isn't this the typical use-case for alternatives?

IMO sensible if you have two packages which are likely to be coinstalled
often. For those kind of niche tools I've here I do not want user to be
bothered to figure out which alternative is selected and which he would
actually like to use. Additionally the native names of the tools shipped
in exfat-utils are
/sbin/dumpexfat
/sbin/exfatfsck
/sbin/exfatlabel
/sbin/mkexfatfs
So probably the midterm will be that the exfatprogs provide
the kind of "official" mkfs.exfat and fsck.exfat tools. But for now
I prefer to keep the already tested exfat-utils in place. If you want
to rely on the exfatprogs tools I assume that is a conscious decision
and you're ok with letting go of the exfat-utils implementation.

In case there is some overboarding interest in always having both installed,
and bothering user with managing alternatives in case he'd like to switch
between implementations, I might change that. But for now I do not believe
it would offer value for the average user.

The only case I can imagine right now that would break is desktop
environment 1 depends on exfatprogs and desktop environment 2 depends on
exfat-utils and a user has both DEs installed. But even here using alternatives
might call for bad surprises when parameter differ. So I believe even in
this case we are all better off for now if the packages conflict and thus
make clear that they are different tools, and should not be installed in
parallel, at least not with the same binary names. (I did not yet check
if they are flag by flag compatible or not)


Cheers,
Sven

Bug#964194: gitlab: "internal API unreachable" when pushing something to repository

[Pirate Praveen]

On Fri, Jul 3, 2020 at 21:50, Pirate Praveen  
wrote:



On Fri, Jul 3, 2020 at 18:13, Frederik Himpe  
wrote:

Pirate Praveen schreef op 2020-07-03 17:55:


gitaly's config.toml.examples have this,

[hooks]
custom_hooks_dir = "/home/git/custom_hooks"

Try setting it to /usr/share/gitlab-shell/hooks/


In config.toml.example of the same version on a source install, I 
have this setting in the [gitlab-shell] section, not in [hooks]. 
And on that working source install, I don't even have it set in the 
config.toml in use.


Anyway, I tried it, but it did not help.


I don't have anything more to suggest. I'm starting to work on 
getting ruby 2.7 in fasttrack which should hopefully fix this, but it 
will take some time as about 47 native gems will need to be 
recompiled with ruby 2.7.


In 2 days and 70+ rebuilds we have gitlab working with ruby 2.7 (just 
tested git clone and git push).


Add https://people.debian.org/~praveen/fasttrack-staging/ and 
https://people.debian.org/~srud/fasttrack-staging/ repos with 
buster-backports and buster-fasttrack suites


Once you confirm, I can push these packages to fasttrack.debian.net

Bug#964351: stretch-pu: package intel-microcode/3.20200616.1~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-07-05 at 17:46 -0300, Henrique de Moraes Holschuh wrote:
> I'd like to update the intel-microcode packages in buster and stretch
> to 3.202006016.1~deb{9,10}u1.
> 
> This is basically the same packages already in buster and stretch via
> buster/strech-security, with one extra microcode revert.  It
> effectively fixes a regression introduced by the security updates for
> a single processor model (Xeon E3 with signature 0x506e3).
> 

Please go ahead.

Regards,

Adam

Bug#964346: buster-pu: package wav2cdr/2.3.4-2+deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-07-05 at 23:20 +0300, Adrian Bunk wrote:
>   * Use C99 fixed-size integer types to fix runtime assertion on
> 64bit architectures other than amd64 and alpha. (Closes: #956927)
>   * Stop linking to the dead Homepage.

Please go ahead.

Regards,

Adam

Bug#964350: buster-pu: package intel-microcode/3.20200616.1~deb10u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-07-05 at 17:45 -0300, Henrique de Moraes Holschuh wrote:
> I'd like to update the intel-microcode packages in buster and stretch
> to 3.202006016.1~deb{9,10}u1.
> 
> This is basically the same packages already in buster and stretch via
> buster/strech-security, with one extra microcode revert.  It
> effectively fixes a regression introduced by the security updates for
> a single processor model (Xeon E3 with signature 0x506e3).

Please go ahead.

Regards,

Adam

Bug#964340: stretch-pu: package sogo-connector/68.0.1-2~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-07-05 at 23:02 +0300, Adrian Bunk wrote:
> The version of sogo-connector in stretch does not work
> with the version of thunderbird in stretch. (#945061)
> 
> The attached debdiff is against the version in unstable,
> which has already been backported to buster. (#948205)
> 

Please go ahead.

Regards,

Adam

Bug#964325: stretch-pu: package compactheader/3.0.0~beta5-2~deb9u1

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sun, 2020-07-05 at 20:51 +0300, Adrian Bunk wrote:
> The version of compactheader in stretch does not work
> with the version of thunderbird in stretch. (#944021)
> 
> The attached debdiff is against the version in unstable,
> which has already been backported to buster. (#948203)
> 

Please go ahead.

Regards,

Adam

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

An additional question : I still do not understand why, if this is a
"source" package, the source (and the Makefile) does not get included ? 

Am I missing something ? 


On 2020-07-05 17:26, Joan Moreau wrote:

Ok, I tried to put a Makefile that import all needed packages dynamically (via "git clone" mostly) 

You may check https://github.com/grosjo/tomboy-reborn/blob/master/packages/tomboy-reborn_1.0.0-1_amd64.deb 

Thank you 

On 2020-07-05 15:53, Sudip Mukherjee wrote: 
On Sun, Jul 5, 2020 at 3:31 PM Joan Moreau  wrote: 
Hi


The lazbuild is commented because this does not work properly from console, one shall use lazarus IDE in order to compile the sources properly, and according to its architecture. 
uhhh.. Debian builds are automated and there is no human interaction,

so build using IDE will not work. It needs to be command based, so it
can be added to the script.

Thank you for the tip about DESTDIR, it seems it works now.

What do you think of https://github.com/grosjo/tomboy-reborn/releases/tag/1.0.0 ? 
I can take a look, but until you can build it without IDE, its not

going to help. :(

Bug#964351: stretch-pu: package intel-microcode/3.20200616.1~deb9u1

[Henrique de Moraes Holschuh]

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

I'd like to update the intel-microcode packages in buster and stretch to
3.202006016.1~deb{9,10}u1.

This is basically the same packages already in buster and stretch via
buster/strech-security, with one extra microcode revert.  It effectively
fixes a regression introduced by the security updates for a single
processor model (Xeon E3 with signature 0x506e3).

The upload via s-p-u/os-p-u was suggested by the security team: we
agreed the revert of microcode 0x506e3 did not really deserve a DSA and
could be handled through the upcoming point releases (it affects only
*some* motherboards with such processors).

The git diff is attached.  Unfortunately, stable debdiff gets mightly
confused by a directory rename that only has binary files inside, so git
diff does a much better job here.

diffstat:
 changelog  |   8 ++
 debian/changelog   |  19 
 intel-ucode/06-4e-03   | Bin 104448 -> 101376 bytes
 intel-ucode/06-5e-03   | Bin 104448 -> 101376 bytes
 microcode-20200609.d => microcode-20200616.d   |   0
 releasenote|  32 -
 s000406E3_m00C0_r00D6.fw   | Bin 101376 -> 0 bytes
 bin => supplementary-ucode-20200616_BDX-ML.bin |   0
 8 files changed, 32 insertions(+), 27 deletions(-)

-- 
  Henrique Holschuh
diff --git a/changelog b/changelog
index d033202..b0565f2 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,11 @@
+2020-06-16:
+  * Downgraded microcodes (to a previously shipped revision):
+sig 0x000406e3, pf_mask 0xc0, 2019-10-03, rev 0x00d6, size 101376
+sig 0x000506e3, pf_mask 0x36, 2019-10-03, rev 0x00d6, size 101376
+  * Works around hangs on boot on Skylake-U/Y and Skylake Xeon E3,
+
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
+  * This update *removes* the SRBDS mitigations from the above processors
+
 2020-06-09:
   * Implements mitigation for CVE-2020-0543 Special Register Buffer Data
 Sampling (SRBDS), aka INTEL-SA-00320
diff --git a/debian/changelog b/debian/changelog
index 9a576a8..863eecf 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+intel-microcode (3.20200616.1~deb9u1) stretch; urgency=high
+
+  * Rebuild for Debian oldstable (stretch), no changes
+
+ -- Henrique de Moraes Holschuh   Sun, 05 Jul 2020 15:26:41 
-0300
+
+intel-microcode (3.20200616.1) unstable; urgency=high
+
+  * New upstream microcode datafile 20200616
++ Downgraded microcodes (to a previously shipped revision):
+  sig 0x000406e3, pf_mask 0xc0, 2019-10-03, rev 0x00d6, size 101376
+  sig 0x000506e3, pf_mask 0x36, 2019-10-03, rev 0x00d6, size 101376
+  * Works around hangs on boot on Skylake-U/Y and Skylake Xeon E3,
+
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
+  * This update *removes* the SRBDS mitigations from the above processors
+  * Note that Debian had already downgraded 0x406e3 in release 3.20200609.2
+
+ -- Henrique de Moraes Holschuh   Sun, 28 Jun 2020 18:38:57 
-0300
+
 intel-microcode (3.20200609.2~deb9u1) stretch-security; urgency=high
 
   * Rebuild for stretch-security, no changes
diff --git a/intel-ucode/06-4e-03 b/intel-ucode/06-4e-03
index 33b963e..1fabcf8 100644
Binary files a/intel-ucode/06-4e-03 and b/intel-ucode/06-4e-03 differ
diff --git a/intel-ucode/06-5e-03 b/intel-ucode/06-5e-03
index 4e947ea..a3119d5 100644
Binary files a/intel-ucode/06-5e-03 and b/intel-ucode/06-5e-03 differ
diff --git a/microcode-20200609.d b/microcode-20200616.d
similarity index 100%
rename from microcode-20200609.d
rename to microcode-20200616.d
diff --git a/releasenote b/releasenote
index 9b60007..f7302d5 100644
--- a/releasenote
+++ b/releasenote
@@ -82,37 +82,15 @@ OS vendors must ensure that the late loader patches 
(provided in
 linux-kernel-patches\) are included in the distribution before packaging the
 BDX-ML microcode for late-loading.
 
-== 20200609 Release ==
--- Updates upon 20200520 release --
+== 20200616 Release ==
+-- Updates upon 20200609 release --
 Processor Identifier Version   Products
 ModelStepping F-MO-S/PI  Old->New
  new platforms 
 
  updated platforms 
-HSW  C0   6-3c-3/32 0027->0028 Core Gen4
-BDW-U/Y  E0/F06-3d-4/c0 002e->002f Core Gen5
-HSW-UC0/D06-45-1/72 0025->0026 Core Gen4
-HSW-HC0   6-46-1/32 001b->001c Core Gen4
-BDW-H/E3 E0/G06-47-1/22 0021->0022 Core Gen5
-SKL-U/Y  D0   6-4e-3/c0 00d6->00dc Core Gen6 Mobile
-SKL-U23e K1   6-4e-3/c0 00d6->00dc Core Gen6 Mobile
-SKX-SP   B1   6-55-3/97 

Bug#964352: python-peachpy should be Architecture: amd64 x32

[Adrian Bunk]

Source: python-peachpy
Version: 0.0~git20200303.f189ad2-3
Severity: important
Tags: ftbfs

https://buildd.debian.org/status/package.php?p=python-peachpy

...
==
ERROR: runTest (test.x86_64.test_load.LoadAsm)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.8_peachpy/build/test/x86_64/test_load.py",
 line 28, in runTest
py_multiply = asm_multiply.finalize(abi.detect()).encode().load()
  File 
"/<>/.pybuild/cpython3_3.8_peachpy/build/peachpy/x86_64/function.py",
 line 308, in finalize
raise TypeError("%s is not an ABI object" % str(abi))
TypeError: None is not an ABI object

--
Ran 1309 tests in 3.706s

FAILED (errors=1)
E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd 
'/<>/.pybuild/cpython3_3.8_peachpy/build'; python3.8 -m unittest 
discover -v
dh_auto_test: error: pybuild --test -i python{version} -p 3.8 returned exit 
code 13
make: *** [debian/rules:8: binary-arch] Error 25


m68k and sh4 are building with nocheck.

Bug#964350: buster-pu: package intel-microcode/3.20200616.1~deb10u1

[Henrique de Moraes Holschuh]

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

I'd like to update the intel-microcode packages in buster and stretch to
3.202006016.1~deb{9,10}u1.

This is basically the same packages already in buster and stretch via
buster/strech-security, with one extra microcode revert.  It effectively
fixes a regression introduced by the security updates for a single
processor model (Xeon E3 with signature 0x506e3).

The upload via s-p-u/os-p-u was suggested by the security team: we
agreed the revert of microcode 0x506e3 did not really deserve a DSA and
could be handled through the upcoming point releases (it affects only
*some* motherboards with such processors).

The git diff is attached.  Unfortunately, stable debdiff gets mightly
confused by a directory rename that only has binary files inside, so git
diff does a much better job here.

diffstat:
 changelog  |   8 ++
 debian/changelog   |  19 
 intel-ucode/06-4e-03   | Bin 104448 -> 101376 bytes
 intel-ucode/06-5e-03   | Bin 104448 -> 101376 bytes
 microcode-20200609.d => microcode-20200616.d   |   0
 releasenote|  32 -
 s000406E3_m00C0_r00D6.fw   | Bin 101376 -> 0 bytes
 bin => supplementary-ucode-20200616_BDX-ML.bin |   0
 8 files changed, 32 insertions(+), 27 deletions(-)

-- 
  Henrique Holschuh
diff --git a/changelog b/changelog
index d033202..b0565f2 100644
--- a/changelog
+++ b/changelog
@@ -1,3 +1,11 @@
+2020-06-16:
+  * Downgraded microcodes (to a previously shipped revision):
+sig 0x000406e3, pf_mask 0xc0, 2019-10-03, rev 0x00d6, size 101376
+sig 0x000506e3, pf_mask 0x36, 2019-10-03, rev 0x00d6, size 101376
+  * Works around hangs on boot on Skylake-U/Y and Skylake Xeon E3,
+
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
+  * This update *removes* the SRBDS mitigations from the above processors
+
 2020-06-09:
   * Implements mitigation for CVE-2020-0543 Special Register Buffer Data
 Sampling (SRBDS), aka INTEL-SA-00320
diff --git a/debian/changelog b/debian/changelog
index 89ee06e..67308d4 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,22 @@
+intel-microcode (3.20200616.1~deb10u1) buster; urgency=high
+
+  * Rebuild for Debian stable (buster), no changes
+
+ -- Henrique de Moraes Holschuh   Sun, 05 Jul 2020 15:18:54 
-0300
+
+intel-microcode (3.20200616.1) unstable; urgency=high
+
+  * New upstream microcode datafile 20200616
++ Downgraded microcodes (to a previously shipped revision):
+  sig 0x000406e3, pf_mask 0xc0, 2019-10-03, rev 0x00d6, size 101376
+  sig 0x000506e3, pf_mask 0x36, 2019-10-03, rev 0x00d6, size 101376
+  * Works around hangs on boot on Skylake-U/Y and Skylake Xeon E3,
+
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/issues/31
+  * This update *removes* the SRBDS mitigations from the above processors
+  * Note that Debian had already downgraded 0x406e3 in release 3.20200609.2
+
+ -- Henrique de Moraes Holschuh   Sun, 28 Jun 2020 18:38:57 
-0300
+
 intel-microcode (3.20200609.2~deb10u1) buster-security; urgency=high
 
   * Rebuild for buster-security, no changes
diff --git a/intel-ucode/06-4e-03 b/intel-ucode/06-4e-03
index 33b963e..1fabcf8 100644
Binary files a/intel-ucode/06-4e-03 and b/intel-ucode/06-4e-03 differ
diff --git a/intel-ucode/06-5e-03 b/intel-ucode/06-5e-03
index 4e947ea..a3119d5 100644
Binary files a/intel-ucode/06-5e-03 and b/intel-ucode/06-5e-03 differ
diff --git a/microcode-20200609.d b/microcode-20200616.d
similarity index 100%
rename from microcode-20200609.d
rename to microcode-20200616.d
diff --git a/releasenote b/releasenote
index 9b60007..f7302d5 100644
--- a/releasenote
+++ b/releasenote
@@ -82,37 +82,15 @@ OS vendors must ensure that the late loader patches 
(provided in
 linux-kernel-patches\) are included in the distribution before packaging the
 BDX-ML microcode for late-loading.
 
-== 20200609 Release ==
--- Updates upon 20200520 release --
+== 20200616 Release ==
+-- Updates upon 20200609 release --
 Processor Identifier Version   Products
 ModelStepping F-MO-S/PI  Old->New
  new platforms 
 
  updated platforms 
-HSW  C0   6-3c-3/32 0027->0028 Core Gen4
-BDW-U/Y  E0/F06-3d-4/c0 002e->002f Core Gen5
-HSW-UC0/D06-45-1/72 0025->0026 Core Gen4
-HSW-HC0   6-46-1/32 001b->001c Core Gen4
-BDW-H/E3 E0/G06-47-1/22 0021->0022 Core Gen5
-SKL-U/Y  D0   6-4e-3/c0 00d6->00dc Core Gen6 Mobile
-SKL-U23e K1   6-4e-3/c0 00d6->00dc Core Gen6 Mobile
-SKX-SP   B1   6-55-3/97 

Bug#916519: wml on Debian should be updated to 2.10.0

[Axel Beckert]

Hi Shlomi,

Shlomi Fish wrote:
> > I'm surprised that this was only 2.5 years ago. It feels as if that
> > struggle with the switch to cmake was like half a decade ago. :-)
> 
> Just for the record, *my* first commits referencing cmake were (according to
> git log --stat):
> 
> commit c69856d5089498bf65d55fbf699928d1a268bbda
> Author: shlomif 
> Date:   Sat Jan 19 08:14:59 2008 +

You've got a point there. Checked my git history. I maintained wml
above 2.0.x for quite a while (starting in 2012 with 2.2.0) only in
Debian Experimental. A branch named cmake is mentioned in merge
commits at least since mid 2013. And yeah, now I remember again: It
took at least two Debian releases until I was confident enough to
merge the cmake-based WML back into master and Debian Unstable... So
my gut feeling that this fight with cmake was half a decade ago is not
that wrong. :-)

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

Bug#964349: RM: libmaus2 [armel armhf i386] -- RoQA; no longer builds on 32bit

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal
Control: block -1 by 964347

See #934619 for background.

Bug#964348: bbhash: Missing test dependencies

[Adrian Bunk]

Source: bbhash
Version: 1.0.0-2
Severity: serious

https://ci.debian.net/data/autopkgtest/testing/amd64/b/bbhash/5910297/log.gz

...
autopkgtest [21:08:27]: test run-unit-test: [---
g++ -o Bootest  bootest.cpp -O3 -std=c++11 -lpthread
make: g++: Command not found
make: *** [makefile:29: Bootest] Error 127

Bug#964347: RM: biobambam2 [armel armhf i386] -- RoQA; build dependency libmaus2 is no longer available on 32bit

[Adrian Bunk]

Package: ftp.debian.org
Severity: normal

See #934619 for background.

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Ok, I tried to put a Makefile that import all needed packages
dynamically (via "git clone" mostly) 


You may check
https://github.com/grosjo/tomboy-reborn/blob/master/packages/tomboy-reborn_1.0.0-1_amd64.deb


Thank you 


On 2020-07-05 15:53, Sudip Mukherjee wrote:

On Sun, Jul 5, 2020 at 3:31 PM Joan Moreau  wrote: 


Hi

The lazbuild is commented because this does not work properly from console, one 
shall use lazarus IDE in order to compile the sources properly, and according 
to its architecture.


uhhh.. Debian builds are automated and there is no human interaction,
so build using IDE will not work. It needs to be command based, so it
can be added to the script.


Thank you for the tip about DESTDIR, it seems it works now.

What do you think of https://github.com/grosjo/tomboy-reborn/releases/tag/1.0.0 
?


I can take a look, but until you can build it without IDE, its not
going to help. :(

Bug#964345: ITP: nanoplot -- plotting scripts for long read sequencing data

[Andreas Tille]

Ich hoffe, Du hast es auf Salsa gefunden, denn es ist schon eine Weile da!


On Sun, Jul 05, 2020 at 10:18:01PM +0200, Steffen Moeller wrote:
> Package: wnpp
> Severity: wishlist
> 
> Subject: ITP: nanoplot -- plotting scripts for long read sequencing data
> Package: wnpp
> Owner: Steffen Moeller 
> Severity: wishlist
> 
> * Package name: nanoplot
>   Version : 1.30.1
>   Upstream Author : Wouter De Coster
> * URL : https://github.com/wdecoster/NanoPlot
> * License : MIT
>   Programming Lang: Python
>   Description : plotting scripts for long read sequencing data
>  NanoPlot provides plotting scripts for long read sequencing data.
>  .
>  These scripts perform data extraction from Oxford Nanopore sequencing data
>  in the following formats:
>  .
>   * fastq files (optionally compressed)
>   * fastq files generated by albacore, guppy or MinKNOW containing additional
> information (optionally compressed)
>   * sorted bam files
>   * sequencing_summary.txt output table generated by albacore, guppy or
> MinKnow basecalling (optionally compressed)
>   * fasta files (optionally compressed)
>   * multiple files of the same type can be offered simultaneously
> 
> Remark: This package is maintained by Debian Med Packaging Team at
>https://salsa.debian.org/med-team/nanoplot
> 
> ___
> Debian-med-packaging mailing list
> debian-med-packag...@alioth-lists.debian.net
> https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-med-packaging

-- 
http://fam-tille.de

Bug#964346: buster-pu: package wav2cdr/2.3.4-2+deb10u1

[Adrian Bunk]

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

  * Use C99 fixed-size integer types to fix runtime assertion on
64bit architectures other than amd64 and alpha. (Closes: #956927)
  * Stop linking to the dead Homepage.
diff -Nru wav2cdr-2.3.4/debian/changelog wav2cdr-2.3.4/debian/changelog
--- wav2cdr-2.3.4/debian/changelog  2017-11-02 12:46:02.0 +0200
+++ wav2cdr-2.3.4/debian/changelog  2020-07-05 23:09:10.0 +0300
@@ -1,3 +1,12 @@
+wav2cdr (2.3.4-2+deb10u1) buster; urgency=medium
+
+  * QA upload.
+  * Use C99 fixed-size integer types to fix runtime assertion on
+64bit architectures other than amd64 and alpha. (Closes: #956927)
+  * Stop linking to the dead Homepage.
+
+ -- Adrian Bunk   Sun, 05 Jul 2020 23:09:10 +0300
+
 wav2cdr (2.3.4-2) unstable; urgency=medium
 
   * QA upload.
diff -Nru wav2cdr-2.3.4/debian/control wav2cdr-2.3.4/debian/control
--- wav2cdr-2.3.4/debian/control2017-11-02 12:46:02.0 +0200
+++ wav2cdr-2.3.4/debian/control2020-07-05 23:09:10.0 +0300
@@ -4,7 +4,6 @@
 Maintainer: Debian QA Group 
 Build-Depends: debhelper (>= 10), bsdmainutils, gawk
 Standards-Version: 4.1.1
-Homepage: http://volker.dnsalias.net/soft/index.html#wav2cdr
 
 Package: wav2cdr
 Architecture: any
diff -Nru wav2cdr-2.3.4/debian/patches/50_fix-inttypes.patch 
wav2cdr-2.3.4/debian/patches/50_fix-inttypes.patch
--- wav2cdr-2.3.4/debian/patches/50_fix-inttypes.patch  1970-01-01 
02:00:00.0 +0200
+++ wav2cdr-2.3.4/debian/patches/50_fix-inttypes.patch  2020-07-05 
23:09:10.0 +0300
@@ -0,0 +1,57 @@
+Description: Use C99 fixed-size integer types
+ This fixes runtime assertion on 64bit architectures
+ other than amd64 and alpha.
+Author: Adrian Bunk 
+Bug-Debian: https://bugs.debian.org/956927
+
+--- wav2cdr-2.3.4.orig/chelp.h
 wav2cdr-2.3.4/chelp.h
+@@ -76,6 +76,7 @@ HISTORY:
+ #ifndef CHELP_H
+ #define CHELP_H
+ 
++#include 
+ 
+ /* Mnemonics for logical and bit-wise operators
+ */
+@@ -166,32 +167,18 @@ typedef charstring;
+ */
+ #ifndef HAS_FIXEDSIZES
+ #define HAS_FIXEDSIZES
+-typedef unsigned char   UINT8, byte;/*  8 bits */
+-typedef unsigned short  UINT16, dbyte, word;/* 16 bits */
+-#if defined(__alpha) OR defined(__x86_64__)
+-  typedef unsigned int  UINT32,
++typedef uint8_t UINT8, byte;/*  8 bits */
++typedef uint16_tUINT16, dbyte, word;/* 16 bits */
++typedef uint32_tUINT32,
+ qbyte, dword, lword;/* 32 bits */
+-#else
+-  typedef unsigned long UINT32,
+-qbyte, dword, lword;/* 32 bits */
+-#endif
+ 
+-typedef signed char SINT8;  /*  8 bits signed */
+-typedef signed shortSINT16; /* 16 bits signed */
+-#if defined(__alpha) OR defined(__x86_64__)
+-  typedef signed intSINT32; /* 32 bits signed */
+-#else
+-  typedef signed long   SINT32; /* 32 bits signed */
+-#endif
++typedef int8_t  SINT8;  /*  8 bits signed */
++typedef int16_t SINT16; /* 16 bits signed */
++typedef int32_t SINT32; /* 32 bits signed */
+ 
+ #ifdef ANSIEXT
+-#ifdef __alpha
+-  typedef unsigned long UINT64, llword; /* 64 bits */
+-  typedef signed long   SINT64; /* 64 bits signed */
+-#else
+-  typedef unsigned long long  UINT64, llword;   /* 64 bits */
+-  typedef signed long longSINT64;   /* 64 bits signed */
+-#endif
++  typedef uint64_t  UINT64, llword;   /* 64 bits */
++  typedef int64_t   SINT64;   /* 64 bits signed */
+ #endif
+ /* check the sizes here? then we would depend on limits.h
+better to require the user to use assert():
diff -Nru wav2cdr-2.3.4/debian/patches/series 
wav2cdr-2.3.4/debian/patches/series
--- wav2cdr-2.3.4/debian/patches/series 2017-11-02 12:46:02.0 +0200
+++ wav2cdr-2.3.4/debian/patches/series 2020-07-05 23:09:10.0 +0300
@@ -2,3 +2,4 @@
 20_make-uninstall.patch
 30_add-GCC-hardening.patch
 40_fix-typo.patch
+50_fix-inttypes.patch

Bug#964208: wsjtx: FTBFS without internet access

[tmancill]

On Sun, Jul 05, 2020 at 09:55:30PM +0200, Christoph Berg wrote:
> Re: tmanc...@debian.org
> > > I/O error : Attempt to load network entity 
> > > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > > warning: failed to load external entity 
> > > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
> > > compilation error: file /etc/asciidoc/docbook-xsl/manpage.xsl line 12 
> > > element import
> > > xsl:import : unable to load 
> > > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > > ...
> > 
> > So I propose that we reassign this to asciidoc, since any package that
> > build-depends on asciidoc and uses the manpage stylesheet should fail in
> > the same manner.  I don't have any experience with XSL stylesheets, but
> > I assume that the asciidoc package can be updated to include the
> > necessary components such that xsl files need not be fetched from the
> > network during the build.
> > 
> > Does that sound reasonable to folks?
> 
> The primary problem is that we are missing a build-dependency on
> docbook-xsl and possibly more packages of the xsl family which contain
> the necessary files.
> 
> I can't say if that is actually a bug in asciidoc to not depend on
> the bunch. (I guess at least a Recommends or Suggests there is in
> order, but that wouldn't fix the B-D problem.)

Ooh, thank you for the tip about docbook-xsl!  That gives us a path
forward for wsjtx.  I see what you're saying about this maybe not being
a bug for asciidoc.  For now I'll add docbook-xsl to the B-D for wsjtx
and upload with the patch for XSLTPROC_OPTS to add --nonet.

Thanks,
tony

Bug#964208: wsjtx: FTBFS without internet access

[Christoph Berg]

Re: tmanc...@debian.org
> For now I'll add docbook-xsl to the B-D for wsjtx
> and upload with the patch for XSLTPROC_OPTS to add --nonet.

That's the best option, I think.

Thanks!

Christoph

Bug#964345: ITP: nanoplot -- plotting scripts for long read sequencing data

[Steffen Moeller]

Package: wnpp
Severity: wishlist

Subject: ITP: nanoplot -- plotting scripts for long read sequencing data
Package: wnpp
Owner: Steffen Moeller 
Severity: wishlist

* Package name: nanoplot
  Version : 1.30.1
  Upstream Author : Wouter De Coster
* URL : https://github.com/wdecoster/NanoPlot
* License : MIT
  Programming Lang: Python
  Description : plotting scripts for long read sequencing data
 NanoPlot provides plotting scripts for long read sequencing data.
 .
 These scripts perform data extraction from Oxford Nanopore sequencing data
 in the following formats:
 .
  * fastq files (optionally compressed)
  * fastq files generated by albacore, guppy or MinKNOW containing additional
information (optionally compressed)
  * sorted bam files
  * sequencing_summary.txt output table generated by albacore, guppy or
MinKnow basecalling (optionally compressed)
  * fasta files (optionally compressed)
  * multiple files of the same type can be offered simultaneously

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

Bug#964344: src:fastqc: fails to migrate to testing for too long: B-D on package that fails to migrate

[Paul Gevers]

Source: fastqc
Version: 0.11.9+dfsg-3
Severity: serious
Control: close -1 0.11.9+dfsg-4
Tags: sid bullseye
User: release.debian@packages.debian.org
Usertags: out-of-sync
Control: block -1 by 959955

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:fastqc in its
current version in unstable has been trying to migrate for 60 days [2].
Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

If you believe your package is unable to migrate to testing due to
issues beyond your control, don't hesitate to contact the Release Team.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=fastqc




signature.asc
Description: OpenPGP digital signature

Bug#959579: adapta-gtk-theme: FTBFS: make[2]: *** [Makefile:1040: all] Error 1

[Samuel Henrique]

Hello Sudip and Franciscarlos,

I'm writing this email as I help Franciscarlos by sponsoring his
uploads and we had discussed the state of adapta-gtk-theme upstream
and this issue privately before.

Thanks for the patch and the delayed upload. I cancelled the upload
for now so we can have this discussion.

adapta-gtk-theme's upstream archived the project about 2 years ago,
and we are not sure if the current version of gnome on
testing/unstable works without issues with it. We had agreed to fill a
package removal request because of that, and I haven't replied to this
bug before because I was going to fill the RoM as the next step (I
should have done it earlier).

I believe the way forward (to have this package on Debian), for
someone interested in it, is to contact upstream and see if they're
willing to let someone else assume the maintenance, especially since
this patch should be there. Once there's a new upstream and guarantee
that the project is working with the latest gnome release, we will be
able to ship adapta-gtk-theme again.

The next step from our side is to fill the RoM removal request, I will
help Franciscarlos with that.

Please feel free to give your inputs.

Thanks,


-- 
Samuel Henrique 

Bug#964342: RM: mathematica-fonts/20

[Adrian Bunk]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
Control: clone -1 -2
Control: retitle -2 RM: mathematica-fonts/21
Control: tags -1 stretch
Control: tags -2 buster

fonts-mathematica is an installer for fonts that
are no longer downloadable. (#960466)

Bug#964341: src:connectagram: fails to migrate to testing for too long: maintainer build arch:all

[Paul Gevers]

Source: connectagram
Version: 1.2.10-1
Severity: serious
Control: close -1 1.2.11-1
Tags: sid bullseye pending
User: release.debian@packages.debian.org
Usertags: out-of-sync

Dear maintainer(s),

As recently announced [1], the Release Team now considers packages that
are out-of-sync between testing and unstable for more than 60 days as
having a Release Critical bug in testing. Your package src:connectagram
in its current version in unstable has been trying to migrate for 60
days [2]. Hence, I am filing this bug.

If a package is out of sync between unstable and testing for a longer
period, this usually means that bugs in the package in testing cannot be
fixed via unstable. Additionally, blocked packages can have impact on
other packages, which makes preparing for the release more difficult.
Finally, it often exposes issues with the package and/or
its (reverse-)dependencies. We expect maintainers to fix issues that
hamper the migration of their package in a timely manner.

This bug will trigger auto-removal when appropriate. As with all new
bugs, there will be at least 30 days before the package is auto-removed.

I have immediately closed this bug with the version in unstable, so if
that version or a later version migrates, this bug will no longer affect
testing. I have also tagged this bug to only affect sid and bullseye, so
it doesn't affect (old-)stable.

Your package is blocked because the arch:all binary package(s) aren't
built on a buildd. Unfortunately the Debian infrastructure doesn't allow
arch:all packages to be properly binNMU'ed. Hence, I will shortly do a
no-changes source-only upload to DELAYED/15, closing this bug. Please
let me know if I should delay or cancel that upload.

Paul

[1] https://lists.debian.org/debian-devel-announce/2020/02/msg5.html
[2] https://qa.debian.org/excuses.php?package=connectagram




signature.asc
Description: OpenPGP digital signature

Bug#964339: node-expat: autopkgtest regression: Cannot find module 'iconv'

[Paul Gevers]

Source: node-expat
Version: 2.3.18+ds-1
X-Debbugs-CC: debian...@lists.debian.org
Severity: serious
User: debian...@lists.debian.org
Usertags: regression

Dear maintainer(s),

Thank you for fixing bug #963060, however with the upload fixing that
issued the autopkgtest of node-expat fails in testing when that
autopkgtest is run with the binary packages of node-expat from unstable.
It passes when run with only packages from testing. In tabular form:

   passfail
node-expat from testing2.3.18+ds-1
all others from testingfrom testing

I copied some of the output at the bottom of this report.

Currently this regression is blocking the migration to testing [1]. Can
you please investigate the situation and fix it?

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

Paul

[1] https://qa.debian.org/excuses.php?package=node-expat

https://ci.debian.net/data/autopkgtest/testing/amd64/n/node-expat/6151675/log.gz

autopkgtest [16:26:52]: test command2: vows --spec ./test/**/*.js
autopkgtest [16:26:52]: test command2: [---
internal/modules/cjs/loader.js:969
  throw err;
  ^

Error: Cannot find module 'iconv'
Require stack:
- /tmp/autopkgtest-lxc.wq1g4b2f/downtmp/build.zVe/src/test/index.js
- /usr/share/nodejs/vows/bin/vows
at Function.Module._resolveFilename
(internal/modules/cjs/loader.js:966:15)
at Function.Module._load (internal/modules/cjs/loader.js:842:27)
at Module.require (internal/modules/cjs/loader.js:1026:19)
at require (internal/modules/cjs/helpers.js:72:18)
at Object.
(/tmp/autopkgtest-lxc.wq1g4b2f/downtmp/build.zVe/src/test/index.js:4:13)
at Module._compile (internal/modules/cjs/loader.js:1138:30)
at Object.Module._extensions..js
(internal/modules/cjs/loader.js:1158:10)
at Module.load (internal/modules/cjs/loader.js:986:32)
at Function.Module._load (internal/modules/cjs/loader.js:879:14)
at Module.require (internal/modules/cjs/loader.js:1026:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
'/tmp/autopkgtest-lxc.wq1g4b2f/downtmp/build.zVe/src/test/index.js',
'/usr/share/nodejs/vows/bin/vows'
  ]
}
autopkgtest [16:26:52]: test command2: ---]



signature.asc
Description: OpenPGP digital signature

Bug#964340: stretch-pu: package sogo-connector/68.0.1-2~deb9u1

[Adrian Bunk]

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

The version of sogo-connector in stretch does not work
with the version of thunderbird in stretch. (#945061)

The attached debdiff is against the version in unstable,
which has already been backported to buster. (#948205)

Despite the dh compat difference the resulting package works,
and debdiff reports no differences.
diff -Nru sogo-connector-68.0.1/debian/changelog 
sogo-connector-68.0.1/debian/changelog
--- sogo-connector-68.0.1/debian/changelog  2020-02-05 13:31:44.0 
+0200
+++ sogo-connector-68.0.1/debian/changelog  2020-07-05 21:47:13.0 
+0300
@@ -1,3 +1,11 @@
+sogo-connector (68.0.1-2~deb9u1) stretch; urgency=medium
+
+  * Non-maintainer upload.
+  * Rebuild for stretch.
+- Lower dh compat to 10.
+
+ -- Adrian Bunk   Sun, 05 Jul 2020 21:47:13 +0300
+
 sogo-connector (68.0.1-2) unstable; urgency=medium
 
   * [2bfa6a2] d/control: bump Standards-Version to 4.5.0
diff -Nru sogo-connector-68.0.1/debian/compat 
sogo-connector-68.0.1/debian/compat
--- sogo-connector-68.0.1/debian/compat 1970-01-01 02:00:00.0 +0200
+++ sogo-connector-68.0.1/debian/compat 2020-07-05 21:47:13.0 +0300
@@ -0,0 +1 @@
+10
diff -Nru sogo-connector-68.0.1/debian/control 
sogo-connector-68.0.1/debian/control
--- sogo-connector-68.0.1/debian/control2020-02-05 13:30:39.0 
+0200
+++ sogo-connector-68.0.1/debian/control2020-07-05 21:47:13.0 
+0300
@@ -7,7 +7,7 @@
  Christoph Goehre ,
 Standards-Version: 4.5.0
 Build-Depends:
- debhelper-compat (= 12),
+ debhelper (>= 10),
 Rules-Requires-Root: no
 Homepage: https://github.com/inverse-inc/sogo-connector
 X-Debian-Homepage: http://wiki.debian.org/SOGoConnector

Bug#964328: [wxmaxima] GLib-GIO-CRITICAL : g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

[John Scott]

Control: reassign -1 libwxgtk3.0-gtk3-0v5 3.0.4+dfsg
Control: affects -1 wxmaxima

On Sunday, July 5, 2020 2:37:26 PM EDT Gunter Königsmann wrote:
> How does one reassign bugs?
I got it. See https://www.debian.org/Bugs/server-control



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

Bug#964208: wsjtx: FTBFS without internet access

[Christoph Berg]

Re: tmanc...@debian.org
> > I/O error : Attempt to load network entity 
> > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > warning: failed to load external entity 
> > "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
> > compilation error: file /etc/asciidoc/docbook-xsl/manpage.xsl line 12 
> > element import
> > xsl:import : unable to load 
> > http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> > ...
> 
> So I propose that we reassign this to asciidoc, since any package that
> build-depends on asciidoc and uses the manpage stylesheet should fail in
> the same manner.  I don't have any experience with XSL stylesheets, but
> I assume that the asciidoc package can be updated to include the
> necessary components such that xsl files need not be fetched from the
> network during the build.
> 
> Does that sound reasonable to folks?

The primary problem is that we are missing a build-dependency on
docbook-xsl and possibly more packages of the xsl family which contain
the necessary files.

I can't say if that is actually a bug in asciidoc to not depend on
the bunch. (I guess at least a Recommends or Suggests there is in
order, but that wouldn't fix the B-D problem.)

Christoph

Bug#960835: Debian Jessie site lists only 4 archs as supported -- updated patch for jessie

[Holger Wansing]

Hi,

Holger Wansing  wrote:
> Hi,
> 
> Holger Wansing  wrote:
> > I managed to get this running. A patch is attached.
> > Even if LTS period for jessie is nearly at its end, I created this patch for
> > the Jessie pages, because that gives the possibility to test it NOW (since
> > the jessie 8.11.0 and 8.11.1 images are now in place, but Stretch LTS are 
> > not).
> > 
> > If we agree on this solution, I would adapt the patch for Stretch.
> 
> Since LTS is now over for Jessie, I have overworked the patch again 
> (attached),
> and I will apply it shortly, if noone objects.

Done.
Everything looks fine.


Holger


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

Bug#954823: hydrogen: Qt5 version available

[Jonas Smedegaard]

Quoting Nicholas D Steeves (2020-07-05 18:31:43)
> Hi Jonas,
> 
> Thank you for replying, and so sorry for the long delay.
> 
> Jonas Smedegaard  writes:
> 
> > [ re-posting, bugreport cc'ed this time ]
> >
> > Quoting Nicholas D Steeves (2020-05-30 22:34:10)
> >> On Sat, May 30, 2020 at 03:57:44PM -0400, Nicholas D Steeves wrote:
> >> > On Fri, Apr 03, 2020 at 07:19:06AM +0200, Jaromír Mikeš wrote:
> [snip]
> >> Do you object to the move to dh?  Also, would you like to remain an
> >> Uploader or would you like me to remove your name from the list at
> >> this time?
> >
> > Please go ahead, and please remove me as uploader (not because of that 
> > change - I am changing away from cdbs myself as well nowadays - but 
> > because I no longer have a special interest in that package)
> >
> 
> I was able to find some of the reasons for the previous packaging
> decisions, such has how librubberband causes timing issues (in a drum
> machine, this would be RC imho!); however, calling rubberband as an
> application apparently does not produce this issue.  I think OSC support
> would be really nice to have, but suspect it was disable because liblo
> was buggy, and I stumbled upon what seems to be the fact that this is
> still the case (https://github.com/hydrogen-music/hydrogen/issues/897).
> 
> Why weren't you building the shared lib before?  It looks like hydrogen
> might have been statically linked?  That seems wrong to me, so I wonder
> what the reason was ;-)
> 
> I'm guessing the files that would have gone into the -dev package were
> deleted because long ago there was no need.  Do you know if they would
> now be useful for something like plugins?
> 
> If you can share why these, and other decisions, were made I'd very much
> appreciate it.  At this time core functionality, MIDI, and export of
> some formats was confirmed to be good (#960539), but I'm trying to be
> careful about disrupting more advanced functionality other users may
> depend on.

Please explore any comments in the packaging files, or git commits - in 
that order.  I very much doubt that I have any more information to share 
than is contained in either of those.  Feel free to ask if there is some 
comment or commit message that you do not understand.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature

Bug#964337: RFS: eqonomize/1.4.3-1 [ITA] -- personal accounting software for the small household economy

[Fabio Augusto De Muzio Tobich]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name: eqonomize
   Version : 1.4.3-1
   Upstream Author : Hanna Knutsson 
 * URL : https://eqonomize.github.io/
 * License : GPL-3+
 * Vcs : https://salsa.debian.org/debian/eqonomize
   Section : kde

It builds those binary packages:

  eqonomize - personal accounting software for the small household economy
  eqonomize-doc - documentation for the Eqonomize! accounting software

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/e/eqonomize/eqonomize_1.4.3-1.dsc

Changes since the last upload:

   [ Debian Janitor ]
   * Set upstream metadata fields: Repository.
 .
   [ Fabio Augusto De Muzio Tobich ]
   * New maintainer. (Closes: #744738)
   * New upstream release. (LP: #119591, LP: #479039, LP: #502391, LP: #519075,
 LP: #633286, LP: #1806727)
   * debian/control:
   - Added Rules-Requires-Root field to source stanza.
   - Bumped DH level to 13.
   - Bumped Standards-Version to 4.5.0.
   - Removed docbook2x and docbook-xml from Build-Depends field, in source
 stanza, not needed anymore since we're using a different method to
 generate the manpage.
   - Reorganized long description in package stanzas.
   * debian/copyright: updated all data.
   * debian/eqonomize.manpages: updated.
   * debian/manpages/:
   - create-man.sh: created to make the manpage from the .txt source file.
   - eqonomize.txt: created to provide the source to the manpage.
   - eqonomize.xml: removed. Using .txt as the manpage source now.
   * debian/patches/:
   - Patch renamed to follow a new numeric prefix system.
   - 010-fix-ftbfs-with-gcc4.3.patch: header updated.
   - 020-add-desktop-entry-keywords.patch: added.
   * debian/source/lintian-overrides: added to inform the manpage created was
 forwarded to upstream.
   * debian/rules:
   - Removed unnecessary DEB_LDFLAGS_MAINT_APPEND flags.
   - Removed unnecessary override_dh_auto_build, using different method to
 generate the manpage now.
   - Removed unnecessary override_dh_clean.
   * debian/salsa-ci.yml: added to provide CI tests for Salsa.
   * debian/tests/control: created to perform a trivial CI test.
   * debian/upstream/metadata: updated.

Regards,

-- 
⢀⣴⠾⠻⢶⣦⠀ Fabio A. De Muzio Tobich
⣾⠁⢰⠒⠀⣿⡁ 9730 4066 E5AE FAC2 2683
⢿⡄⠘⠷⠚⠋⠀ D03D 4FB3 B4D3 7EF6 3B2E
⠈⠳⣄  GPG:rsa4096/7EF63B2E

Bug#964317: Fw: RFP: portfolio -- Portfolio Performance - an open source tool to calculate the overall performance of an investment portfolio

[Alexander Gerasiov]

Forwarding to debian-java@


Begin forwarded message:

Date: Sun, 05 Jul 2020 18:17:46 +0300
From: Alexander GQ Gerasiov 
To: Debian Bug Tracking System 
Subject: RFP: portfolio -- Portfolio Performance - an open source tool
to calculate the overall performance of an investment portfolio


Package: wnpp
Severity: wishlist

* Package name: portfolio
  Version :  0.46.6
  Upstream Author : Andreas Buchen 
* URL : https://www.portfolio-performance.info/en/
* License : Eclipse Public License 1.0
  Programming Lang: Java
  Description : Portfolio Performance - an open source tool to
  calculate the overall performance of an investment portfolio

Very powerful app to track your investment. Some of it's features from
official site:

* Record the full history of your transactions: purchases, sales,
  taxes, fees, ...
* Calculate performance indicators such as the True-Time Weighted Rate
  of Return or the Internal Rate of Return (IRR) for your holdings.
* Update historical quotes from a variety of sources: Yahoo Finance,
  Finnhub.io, Quandl, or AlphaVantage. Alternatively, scrape quotes
  from HTML pages or JSON documents.
* All data is stored in XML for further processing and can be exported
  as CSV or JSON.
* Rebalance your investment portfolio based on a freely defined Asset
  Allocation.
* Keep foreign currency accounts using the exchange rates published by
  the European Central Bank (ECB).


I, personally, will be glad to help in packaging, but I'm not familiar
with Java and Maven, so need someone who could help with this.


-- 
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: a...@gerasiov.net  WWW: https://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Bug#964336: Mimedefang's relay_is_blacklisted_multi function gets confused if Net::DNS::Resolver falls back to TCP in order to retry queries with truncated UDP response packets

[Alain Knaff]

Package: mimedefang
Version: 2.84-3
Severity: important
Tags: patch

Dear maintainer,

The relay_is_blacklisted_multi function seems to be unaware that 
Net::DNS::Resolver->bgread (and bgbusy) may change their $handle 
parameter in the caller's scope via the $_[1] = $newvalue idiom under 
certain conditions.


Indeed, such change happens when the reply to the UDP query is 
truncated, and Net::DNS::Resolver has to re-issue the query as a TCP 
query. This happens frequently with the bl.spamcop.net blacklist.


The result of this is that the lookup for the domain in the 
$sock_to_domain hash fails, as $sock is no longer the original $sock 
that it was before the call to bgread.


If this happens, you'll find entries such as the following in the log:
Jun 28 00:20:33 lll mimedefang-multiplexor[23337]: 05RMKV8R016512: Worker 5 
stderr: Use of uninitialized value $domain in hash element at 
/usr/bin/mimedefang.pl line 1714.
Jun 28 00:20:33 lll mimedefang-multiplexor[23337]: 05RMKV8R016512: Worker 5 
stderr: Use of uninitialized value in string eq at /usr/bin/mimedefang.pl line 
1714.
Jun 28 00:20:33 lll mimedefang-multiplexor[23337]: 05RMKV8R016512: Worker 5 
stderr: Use of uninitialized value $domain in hash element at 
/usr/bin/mimedefang.pl line 1717.

==> in order to be correct, $domain = $sock_to_domain{$sock}; has to 
happen *before* $res->bgread($sock). Likewise, $sel->remove($sock) also 
needs to happen before bgread.



Another issue is that if a TCP fallback was indeed performed, then 
bgread may still block even though its handle was in the select's 
can_read set.


==> so if we want to make sure that we parallelize all queries, rather 
than blocking on a single one of them, we need to test 
$res->bgbusy($sock). And if indeed busy, add $sock again to the 
sock_to_domain hash and $sel (as it may have been changed by 
Net::DNS::Resolver's bgbusy).


The attached patch accomplishes this.

Thanks,

Alain
--- mimedefang-orig.pl	2020-07-03 20:04:25.418013798 +0200
+++ mimedefang.pl	2020-07-05 21:01:38.566585418 +0200
@@ -1697,9 +1697,14 @@
 	my @ready;
 	@ready = $sel->can_read($expire);
 	foreach $sock (@ready) {
-	my $pack = $res->bgread($sock);
 	$sel->remove($sock);
 	$domain = $sock_to_domain{$sock};
+	if($res->bgbusy($sock)) {
+		$sock_to_domain{$sock}=$domain;
+		$sel->add($sock);
+		next;
+	}
+	my $pack = $res->bgread($sock);
 	undef($sock);
 	my($rr, $rcode);
 	$rcode = $pack->header->rcode;

Bug#961179: RFS: inkscape-textext/1.0.1-1 [ITP] -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Hello again,

Is there anything I can do to help move this process along?
Are you still willing to sponsor an upload for this package?

Thank you,
Antonio Russo

Bug#964208: wsjtx: FTBFS without internet access

[tmancill]

On Sat, Jul 04, 2020 at 01:08:32PM +0200, Christoph Berg wrote:
> Ideally we should add some --nonet flag to make the failure both more obvious 
> and reproducible.

Here's an update on this bug...  

There is a "--nonet" option that can be passed to xsltproc, but the
build fails when that option is used, returning error code 5; from the
xsltproc manpage:

   5
   Error in the stylesheet

The issue lies in the asciidoc package when the manpage stylesheet is
used in conjunction with --nonet.  I tweaked the autopkgtest to show the
failure and pushed a branch and created a merge request [1].  From the
verbose output of the now failing test:

> ...
> creating dictionary for stylesheet
> reusing dictionary from /etc/asciidoc/docbook-xsl/manpage.xsl for stylesheet
> xsltParseStylesheetProcess : found stylesheet
> xsltPreprocessStylesheet: removing ignorable blank node
> Reusing dictionary for document
> I/O error : Attempt to load network entity 
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> warning: failed to load external entity 
> "http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl;
> compilation error: file /etc/asciidoc/docbook-xsl/manpage.xsl line 12 element 
> import
> xsl:import : unable to load 
> http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl
> ...

So I propose that we reassign this to asciidoc, since any package that
build-depends on asciidoc and uses the manpage stylesheet should fail in
the same manner.  I don't have any experience with XSL stylesheets, but
I assume that the asciidoc package can be updated to include the
necessary components such that xsl files need not be fetched from the
network during the build.

Does that sound reasonable to folks?

Thanks,
tony

[1] https://salsa.debian.org/debian/asciidoc/-/merge_requests/1


signature.asc
Description: PGP signature

Bug#964242: bsdmainutils: depends on non-existing version of bsdextrautils

[Harlan Lieberman-Berg]

affects 964242 debootstrap
thanks

On Sun, 5 Jul 2020 12:52:54 +0200 Michael Meskes  wrote:
> On Sat, Jul 04, 2020 at 10:52:04AM +0200, Rene Engelhard wrote:
> > But that bsdextrautils (>= 2.35.2-7) doesn't exist:
>
> Yes, as already communicated we had to wait with the next util-linux upload
> until bsdmainutils made it out of NEW. Now that it has, Chris will upload as
> soon as he finds the time.

Because debootstrap follows Recommends and bsdmainutils is Recommended
by bsdutils in Priority: required, this bug means debootstrap can't
currently create sid bases.

Sincerely,

-- 
Harlan Lieberman-Berg
~hlieberman

Bug#964334: segfault repeatedly

[Stefano Zacchiroli]

Package: chromium
Version: 83.0.4103.116-2
Severity: grave

I've upgraded chromium to the current version in testing, and it segfaults
repeatedly (and very "reliably"! :-)) after usually ~1 minute of runtime, even
when not used in foreground, with a stack trace like this one:

-

$ chromium 

(chromium:1480721): Gtk-WARNING **: 21:03:45.963: Theme parsing error: 
gtk.css:6:20: The 'gtk-key-bindings' property has been renamed to 
'-gtk-key-bindings'
[1480760:1480760:0705/210346.245467:ERROR:sandbox_linux.cc(374)] 
InitializeSandbox() called with multiple threads in process gpu-process.
[1480764:1480779:0705/210348.465499:ERROR:nss_util.cc(283)] After loading Root 
Certs, loaded==false: NSS error code: -8018
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space 
not permitted on grayscale PNG
libpng warning: iCCP: profile 'Photoshop ICC profile': 'RGB ': RGB color space 
not permitted on grayscale PNG
libpng warning: iCCP: known incorrect sRGB profile
libpng warning: iCCP: known incorrect sRGB profile
Received signal 11 SEGV_MAPERR 7f01744946c7
#0 0x557d36628c69 (/usr/lib/chromium/chromium+0x52b3c68)
#1 0x557d36587ef3 (/usr/lib/chromium/chromium+0x5212ef2)
#2 0x557d366287f1 (/usr/lib/chromium/chromium+0x52b37f0)
#3 0x7f1a95d8d110 (/usr/lib/x86_64-linux-gnu/libpthread-2.30.so+0x1410f)
#4 0x7f1a90e78d3c (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x85d3b)
#5 0x7f1a90e7af33 (/usr/lib/x86_64-linux-gnu/libc-2.30.so+0x87f32)
#6 0x7f1a90e7cbf9 __libc_malloc
#7 0x557d366409be operator new()
#8 0x7f1a91103a2c std::__cxx11::basic_string<>::reserve()
#9 0x7f1a910f9498 std::__cxx11::basic_stringbuf<>::overflow()
#10 0x7f1a9110204a std::basic_streambuf<>::xsputn()
#11 0x7f1a910f4714 std::__ostream_insert<>()
#12 0x557d36628d39 (/usr/lib/chromium/chromium+0x52b3d38)
#13 0x557d36629054 (/usr/lib/chromium/chromium+0x52b4053)
#14 0x557d3659a412 (/usr/lib/chromium/chromium+0x5225411)
#15 0x557d3659c548 (/usr/lib/chromium/chromium+0x5227547)
#16 0x557d34ce212a (/usr/lib/chromium/chromium+0x396d129)
#17 0x557d34ce217e (/usr/lib/chromium/chromium+0x396d17d)
#18 0x557d34337387 (/usr/lib/chromium/chromium+0x2fc2386)
#19 0x557d34c9b3d9 (/usr/lib/chromium/chromium+0x39263d8)
#20 0x557d34c9b61e (/usr/lib/chromium/chromium+0x392661d)
#21 0x557d34ce5967 (/usr/lib/chromium/chromium+0x3970966)
#22 0x557d34d114c7 (/usr/lib/chromium/chromium+0x399c4c6)
#23 0x557d34d1177e (/usr/lib/chromium/chromium+0x399c77d)
#24 0x557d34ce213f (/usr/lib/chromium/chromium+0x396d13e)
#25 0x557d34ce217e (/usr/lib/chromium/chromium+0x396d17d)
#26 0x557d34337387 (/usr/lib/chromium/chromium+0x2fc2386)
#27 0x557d345fa7a3 (/usr/lib/chromium/chromium+0x32857a2)
#28 0x557d349690bc (/usr/lib/chromium/chromium+0x35f40bb)
#29 0x557d3675a45f (/usr/lib/chromium/chromium+0x53e545e)
#30 0x557d36760a24 (/usr/lib/chromium/chromium+0x53eba23)
#31 0x557d3675eb62 (/usr/lib/chromium/chromium+0x53e9b61)
#32 0x557d3675d82d (/usr/lib/chromium/chromium+0x53e882c)
#33 0x557d36756213 (/usr/lib/chromium/chromium+0x53e1212)
#34 0x557d36771abb (/usr/lib/chromium/chromium+0x53fcaba)
#35 0x557d36771de0 (/usr/lib/chromium/chromium+0x53fcddf)
#36 0x557d36771370 (/usr/lib/chromium/chromium+0x53fc36f)
#37 0x557d345e3c46 (/usr/lib/chromium/chromium+0x326ec45)
#38 0x557d345e376c (/usr/lib/chromium/chromium+0x326e76b)
#39 0x557d345dfeed (/usr/lib/chromium/chromium+0x326aeec)
#40 0x557d345d674b (/usr/lib/chromium/chromium+0x326174a)
#41 0x557d345c9044 (/usr/lib/chromium/chromium+0x3254043)
#42 0x557d345c8d75 (/usr/lib/chromium/chromium+0x3253d74)
#43 0x557d345e7426 (/usr/lib/chromium/chromium+0x3272425)
#44 0x557d366460e0 (/usr/lib/chromium/chromium+0x52d10df)
#45 0x7f1a94b42b0f (/usr/lib/x86_64-linux-gnu/libevent-2.1.so.7.0.0+0x23b0e)
#46 0x7f1a94b4324f event_base_loop
#47 0x557d3664638e (/usr/lib/chromium/chromium+0x52d138d)
#48 0x557d365e65d5 (/usr/lib/chromium/chromium+0x52715d4)
#49 0x557d365be670 (/usr/lib/chromium/chromium+0x524966f)
#50 0x557d349043b3 (/usr/lib/chromium/chromium+0x358f3b2)
#51 0x557d365fc2a9 (/usr/lib/chromium/chromium+0x52872a8)
#52 0x557d36638c9e (/usr/lib/chromium/chromium+0x52c3c9d)
#53 0x7f1a95d81f27 start_thread
#54 0x7f1a90ef031f clone
  r8: 0077  r9: 0050 r10: 0004 r11: 
007c
 r12: 7f1a7420 r13: 7f1a7430 r14: 7f1a74736850 r15: 
0020
  di: 0021  si: 0004  bp: 0020  bx: 
7f01744946bf
  dx: 7f1a7480  ax: 7f1a742d4d90  cx: 7f01744946bf  sp: 
7f1a826d3440
  ip: 7f1a90e78d3c efl: 00010202 cgf: 002b0033 erf: 
0004
 trp: 000e msk:  cr2: 7f01744946c7
[end of stack trace]
Calling _exit(1). Core file will not be generated.

-

Thanks a lot for maintaining chromium in Debian,
Hope this helps


-- System Information:
Debian 

Bug#964335: linux-headers-amd64: cannot upgrade to 5.7.6-1

[Giuseppe Bilotta]

Package: linux-headers-amd64
Version: 5.6.14-2
Severity: serious

Try to upgrade linux-headers-amd64, linux-image-amd64 and linux-perf to
version 5.7.6-1 results in the following errors:

Preparing to unpack .../15-linux-headers-amd64_5.7.6-1_amd64.deb ...
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-headers-amd64/copyright' not owned by package 
'linux-headers-amd64'
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-headers-amd64/changelog.gz' not owned by package 
'linux-headers-amd64'
dpkg-maintscript-helper: error: directory 
'/usr/share/doc/linux-headers-amd64' contains files not owned by package 
linux-headers-amd64, cannot switch to symlink
dpkg: error processing archive 
/tmp/apt-dpkg-install-zTcKDN/15-linux-headers-amd64_5.7.6-1_amd64.deb 
(--unpack):
 new linux-headers-amd64 package pre-installation script subprocess 
returned error exit status 1
Preparing to unpack .../16-linux-image-amd64_5.7.6-1_amd64.deb ...
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-image-amd64/NEWS.Debian.gz' not owned by package 
'linux-image-amd64'
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-image-amd64/copyright' not owned by package 
'linux-image-amd64'
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-image-amd64/changelog.gz' not owned by package 
'linux-image-amd64'
dpkg-maintscript-helper: error: directory 
'/usr/share/doc/linux-image-amd64' contains files not owned by package 
linux-image-amd64, cannot switch to symlink
dpkg: error processing archive 
/tmp/apt-dpkg-install-zTcKDN/16-linux-image-amd64_5.7.6-1_amd64.deb (--unpack):
 new linux-image-amd64 package pre-installation script subprocess returned 
error exit status 1
Preparing to unpack .../17-linux-perf_5.7.6-1_amd64.deb ...
dpkg-maintscript-helper: error: file '/usr/share/doc/linux-perf/copyright' 
not owned by package 'linux-perf'
dpkg-maintscript-helper: error: file 
'/usr/share/doc/linux-perf/changelog.gz' not owned by package 'linux-perf'
dpkg-maintscript-helper: error: directory '/usr/share/doc/linux-perf' 
contains files not owned by package linux-perf, cannot switch to symlink
dpkg: error processing archive 
/tmp/apt-dpkg-install-zTcKDN/17-linux-perf_5.7.6-1_amd64.deb (--unpack):
 new linux-perf package pre-installation script subprocess returned error 
exit status 1

Note that the dependencies linux-headers-5.7.0-1-{amd64,common},
linux-image-5.7.0-1-amd64, linux-perf-5.7 have all been upgrade to
5.7.6-1, it's only the versionless one that fail.

(I'm not sure how to tag this as also affecting the linux-image-amd64 and
linux-perf packages, sorry.)

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

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

Versions of packages linux-headers-amd64 depends on:
ii  linux-headers-5.6.0-2-amd64  5.6.14-2

linux-headers-amd64 recommends no packages.

linux-headers-amd64 suggests no packages.

-- no debconf information

Bug#963792: transition: ros-*

[R hertoric]

Lilly kill all


On Sat, Jun 27, 2020, 4:54 AM Jochen Sprickerhof 
wrote:

> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
>
> Hi release team,
>
> I would like to transition these packages to unstable:
>
> ros-roscpp-core
> ros-ros-comm
> ros-geometric-shapes
> ros-urdf
> ros-interactive-markers
> ros-actionlib
> ros-geometry2
> ros-vision-opencv
>
> Would you be ok with doing all of them at the same time?
> (Otherwise I would start with ros-roscpp-core.)
>
> The generated Ben files are ok.
>
> Cheers Jochen
>
> -- System Information:
> Debian Release: bullseye/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 5.7.0-1-amd64 (SMP w/8 CPU cores)
> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8),
> LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
>

Bug#964333: ITP: tmd710-tncsetup -- tool to configure the TNC on several Kenwood radios

[Francois Marier]

Package: wnpp
Severity: wishlist
Owner: Francois Marier 

* Package name: tmd710-tncsetup
  Version : 1.13
  Upstream Author : Francois Marier 
* URL : https://github.com/fmarier/tmd710_tncsetup
* License : GPL-3.0-or-later
  Programming Lang: C
  Description : tool to configure the TNC on several Kenwood radios

This is a tool to configure the TNC on several Kenwood radios.

See
https://feeding.cloud.geek.nz/posts/using-kenwood-th-d72a-with-pat-linux-ax25/
for a concrete example of how this tool can be useful with the other Linux
packet utilities.

The following radios are known to work with this tool:

- TM-D710
- TH-D72

Bug#964332: ITP: canadian-ham-exam -- practice test for the Canadian Amateur Radio exam

[Francois Marier]

Package: wnpp
Severity: wishlist
Owner: Francois Marier 

* Package name: canadian-ham-exam
  Version : 1.0.0
  Upstream Author : Francois Marier 
* URL : https://launchpad.net/canadian-ham-exam
* License : AGPL-3.0-or-later
  Programming Lang: Python
  Description : practice test for the Canadian Amateur Radio exam

Canadian Ham Exam uses the official question bank from Industry Canada and
allows aspiring hams to practice the section of their choice as they are
learning the material for the exam.

It requires a copy of the question bank, which can be downloaded free of
charge from the Industry Canada website:

   http://www.ic.gc.ca/eic/site/025.nsf/eng/h_4.html

Both the basic and the advanced exams are supported, in English and French.

Bug#964328: [wxmaxima] GLib-GIO-CRITICAL : g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

[Gunter Königsmann]

How does one reassign bugs? I second the argumentation but wxMaxima doesn't use 
the dbus, nor can it show nor suppress these warnings. It is libwxWidgets, who 
does.

On July 5, 2020 8:05:47 PM GMT+02:00, kamar...@gmail.com wrote:
>Package: wxmaxima
>Version: 19.01.2-1
>Severity: minor
>
>Launching wxmaxima from the command line gives the following warnings.
>
>GLib-GIO-CRITICAL **: 13:59:04.632: g_dbus_proxy_new: assertion
>'G_IS_DBUS_CONNECTION (connection)' failed
>
>The application starts and works fine though. If the warning is
>important, the underlying code should be fixed. If it is not
>important, wxmaxima should suppress it. It is distracting and reduces
>the usability of the application.
>
>thanks
>raju
>
>
>--- System information. ---
>Architecture:
>Kernel:   Linux 4.19.0-9-amd64
>
>Debian Release: 10.4
>  500 stable-updates  deb.debian.org
>  500 stable  dl.google.com
>  500 stable  deb.debian.org
>  100 buster-backports deb.debian.org
>
>--- Package information. ---
>Depends(Version) | Installed
>-+-
>libc6  (>= 2.14) |
>libgcc1   (>= 1:3.0) |
>libstdc++6  (>= 5.2) |
>libwxbase3.0-0v5 (>= 3.0.4+dfsg) |
>libwxgtk3.0-0v5  (>= 3.0.4+dfsg) |
>ibus-gtk3|
>maxima   |
>
>
>Recommends  (Version) | Installed
>=-+-===
>maxima-doc| 5.42.1-1
>
>
>Suggests (Version) | Installed
>==-+-===
>fonts-jsmath   |
>texlive-latex-extra| 2018.20190227-2

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Bug#964087: RFS: TomboyReborn/1.0-1 - Drop in replacement of deprecated Gnome Tomboy

[Joan Moreau]

Hi 


The lazbuild is commented because this does not work properly from
console, one shall use lazarus IDE in order to compile the sources
properly, and according to its architecture. 

Thank you for the tip about DESTDIR, it seems it works now. 


What do you think of
https://github.com/grosjo/tomboy-reborn/releases/tag/1.0.0 ? 


Thank you very much for your support

Bug#964331: RM: colorediffs-extension/0.6.2012.01.27.14.07.45-1

[Adrian Bunk]

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

colorediffs-extension does not work with Thunderbird >= 60 (#918171),
due to that it was already removed from unstable before the release
of buster (#929333).

Bug#964330: python3-lib2to3: Please depend on python3:any

[Elrond]

Package: python3-lib2to3
Version: 3.8.3-2
Severity: wishlist
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

Hi,

python3-lib2to3 currently depends on just python3.
As python3-lib2to3 is Multi-Arch=foreign, it probably
should depend on python3:any.

For example python3-pkg-resources already does exactly
this.


Could you please look into this?


Cheers

Elrond

Bug#964287: Experiencing same bug in stable

[Szymon Lukaszczyk]

I'm experiencing exactly same bug, but now the package is in stable

Chromium 83.0.4103.116 built on Debian 10.4, running on Debian 10.4 - 
83.0.4103.116-1~deb10u2


--
Sincerely,
Szymon Łukaszczyk

StoreKeeper B.V.
+31 (0) 85 0 16 8008
Wijnkamp 3
7471 CA Goor
storekeeper.nl

Bug#964328: [wxmaxima] GLib-GIO-CRITICAL : g_dbus_proxy_new: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

[kamaraju]

Package: wxmaxima
Version: 19.01.2-1
Severity: minor

Launching wxmaxima from the command line gives the following warnings.

GLib-GIO-CRITICAL **: 13:59:04.632: g_dbus_proxy_new: assertion
'G_IS_DBUS_CONNECTION (connection)' failed

The application starts and works fine though. If the warning is
important, the underlying code should be fixed. If it is not
important, wxmaxima should suppress it. It is distracting and reduces
the usability of the application.

thanks
raju


--- System information. ---
Architecture:
Kernel:   Linux 4.19.0-9-amd64

Debian Release: 10.4
  500 stable-updates  deb.debian.org
  500 stable  dl.google.com
  500 stable  deb.debian.org
  100 buster-backports deb.debian.org

--- Package information. ---
Depends(Version) | Installed
-+-
libc6  (>= 2.14) |
libgcc1   (>= 1:3.0) |
libstdc++6  (>= 5.2) |
libwxbase3.0-0v5 (>= 3.0.4+dfsg) |
libwxgtk3.0-0v5  (>= 3.0.4+dfsg) |
ibus-gtk3|
maxima   |


Recommends  (Version) | Installed
=-+-===
maxima-doc| 5.42.1-1


Suggests (Version) | Installed
==-+-===
fonts-jsmath   |
texlive-latex-extra| 2018.20190227-2

Bug#964100: iputils-arping should use alternatives to remove conflict with arping

[Boian Bonev]

Hi Noah,

On Thu, 2020-07-02 at 10:32 -0700, Noah Meyerhans wrote:
> On Wed, Jul 01, 2020 at 09:29:22PM +0300, Boian Bonev wrote:
> > I would like to propose a patch with alternatives support.
> > 
> > Before doing this there are some things to confirm:
> > 
> > - are you willing to accept such a patch?
> 
> It seems reasonable.  I have a vague (and possibly mistaken) memory
> that
> I looked in to doing this a number of years ago and found that it
> would
> not be appropriate to use alternatives for these two programs.  I
> don't
> remember the reasoning and I haven't managed to find any record of
> this,
> though.

The first possibly problematic thing that I see is that iputils-arping
is installed in /usr/bin/ while arping is installed in /usr/sbin/
I believe that this should be solved by installing a link from
/usr/bin/arping to /usr/sbin/arping; and make the alternative be
/usr/sbin/arping

The second would be in case the maintainers of arping refuse to accept
a patch or implement alternatives support.

> I'd like to determine more definitively whether my memory is accurate
> or
> not before we proceed with this work, so please give me some time.

Sure, I didn't prepare the patch yet - it would be pointless without
confirmation...

With best regards,
b.

Bug#964329: xul-ext-exteditor <= 1.0.3-1 is not working or installable with Thunderbird 68

[Adrian Bunk]

Package: xul-ext-exteditor
Version: 1.0.0-1
Severity: serious
Control: fixed -1 2.0.2-1~exp1

The version in stable must be updated to the version in unstable.