Bug#979055: src:extra-xdg-menus: invalid maintainer address

2021-01-02 Thread Ansgar
Source: extra-xdg-menus
Version: 1.0-4
Severity: serious
X-Debbugs-Cc: Hamish Moffatt , Holger Levsen 


The maintainer address is invalid, see below.  Also the maintainer
address is listed a second time in the Uploaders field.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Fri, 01 Jan 2021 14:19:53 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pc...@cam.ac.uk
host mx.cam.ac.uk [131.111.8.149]
SMTP error from remote mail server after RCPT TO::
550- is not a known user on this system;
550 see http://help.uis.cam.ac.uk/email-bounce



Bug#979059: xfce4-screenshooter missleading/false panel icon

2021-01-02 Thread Alf
Package: xfce4-screenshooter
Version: 1.9.8-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
updating from Buster to Bullseye
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The icon sits in the panel at a size of 32x32 pixels and shows a monitor with
a  crossed-out screen. This lets one assume that it will i.e. switch-off the 
monitor
or just kill the X-server. Now knowing what it was in earlier versions you 
never would
guess it will do a screenshot.

Having a look at the icon file at higher resolutions reveals that it should 
represent
a scissor and a dotted rectangle which indictes something to be cut out.

Additionally the light blue color spoils the look when sitting in a dark panel.
I am using the greybird theme and not bluebird.

   * What outcome did you expect instead?

A timy neutral (in color) panal icon showing a camera like in Buster and 
earlier versions of Debian.



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-screenshooter depends on:
ii  libc62.31-6
ii  libcairo21.16.0-4
ii  libexo-2-0   4.16.0-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk-3-0   3.24.24-1
ii  libsoup2.4-1 2.72.0-2
ii  libx11-6 2:1.6.12-1
ii  libxext6 2:1.3.3-1.1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1

Versions of packages xfce4-screenshooter recommends:
ii  libxfce4panel-2.0-4  4.14.4-1

xfce4-screenshooter suggests no packages.

-- no debconf information



Bug#979058: src:geronimo-j2ee-connector-1.5-spec: invalid maintainer address

2021-01-02 Thread Ansgar
Source: geronimo-j2ee-connector-1.5-spec
Version: 2.0.0-1
Severity: serious
X-Debbugs-Cc: Graziano Obertelli , Kyo Lee 
, Holger Levsen 

The maintainer address is invalid, see below.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Fri, 01 Jan 2021 18:49:46 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  g...@eucalyptus.com
retry timeout exceeded



Bug#950761: ipmitool: CVE-2020-5208

2021-01-02 Thread Salvatore Bonaccorso
Control: severity -1 grave

Hi Jörg, Adam,

On Wed, Feb 05, 2020 at 10:11:58PM +0100, Salvatore Bonaccorso wrote:
> Source: ipmitool
> Version: 1.8.18-8
> Severity: important
> Tags: security upstream
> Control: found -1 1.8.18-6
> Control: found -1 1.8.18-3
> 
> Hi,
> 
> The following vulnerability was published for ipmitool.
> 
> CVE-2020-5208[0]:
> | It's been found that multiple functions in ipmitool before 1.8.19
> | neglect proper checking of the data received from a remote LAN party,
> | which may lead to buffer overflows and potentially to remote code
> | execution on the ipmitool side. This is especially dangerous if
> | ipmitool is run as a privileged user. This problem is fixed in version
> | 1.8.19.

Strictly speaking this is not RC (so if you strongly disagree please
downgrade). While not a serious problem if run not with a privileged
user or over untrusted networks, I feel would still be great to have
this issue fixed for the upcoming bullseye.

Possible to rebase to the 1.8.19 release before the upcoming freeze?

Regards,
Salvatore



Bug#979063: php-font-lib: Useless in Debian

2021-01-02 Thread Markus Frosch
Package: php-font-lib
Version: 0.3.1+dfsg-3.1
Severity: serious
X-Debbugs-Cc: taf...@debian.org, only...@debian.org, hol...@debian.org

[ Trying to remove the package from bullseye at least ]

Similar to php-dompdf [1], this package is pretty useless for bullseye,
since it is only needed by php-dompdf, which is not depent on by any
package in testing.

Only possible candidate would be civicrm [2], which seems not be able to
make it to bullseye.

Also see the orphan [3].

Best Regards
Markus Frosch

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=979022
[2] https://tracker.debian.org/pkg/civicrm
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978995



Bug#978995: Useless in Debian

2021-01-02 Thread Markus Frosch
On Fri, 2021-01-01 at 22:19 -0400, David Prévot wrote:
> Package: php-dompdf
> Severity: serious
> 
> [ Reported by a team member to see the package removed from testing ]
> 
> php-dompdf was introduced in Debian as part of the ownCloud packaging
> effort, but no packages depend on it anymore, so I don’t believe it’s
> useful to keep it around.
> 
> Unless someone disagree with the above, I intend to ask for removal of
> this package soon (so if you read this message years from now, no need
> to ask for permission to act on what I’ve failed to…).

Hi David,

I kinda noticed that myself for a while, but it seems like civicrm [1] depends
on it now, which doesn't look like it would make it to bullseye.

See #978994 [2], I orphaned it and php-font-lib #978995 for that reason, also
CCing Dimitry on all bugs.

We could remove it from testing if civicrm won't make it, so this bug should
take care of that at least...

I'll open another serious bug for php-font-lib then.

Best
Markus Frosch

[1] https://tracker.debian.org/pkg/civicrm
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978994
[3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978995



Bug#979066: mangohud: Build fails on buster

2021-01-02 Thread Bob Ham
Source: mangohud
Severity: normal

Hi,

Trying to build the mangohud package on buster fails with:

ccache c++ -Isrc/25a6634@@MangoHud@sha -Isrc -I../src -I../include 
-Isubprojects/dearimgui -I../subprojects/dearimgui -I. -I/usr/include/dbus-1.0 
-I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -fvisibility=hidden 
-fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++14 
-Werror=return-type -fno-math-errno -fno-trapping-math -Wno-non-virtual-dtor 
-Wno-missing-field-initializers -Wno-format-truncation -g -O2 
-fdebug-prefix-map=/store-f/rah/proj/games/mangohud-debian=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIC -pthread -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="v0.6.1"' 
-DNDEBUG -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_GCC_ATOMIC_BUILTINS 
-DHAVE_TIMESPEC_GET -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64 
-DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ 
-DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL 
-DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL 
-DHAVE___BUILTIN_UNREACHABLE '-DMANGOHUD_ARCH="64bit"' -DHAVE_XNVCTRL 
-DHAVE_X11 -DHAVE_DBUS -DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_WAYLAND_KHR 
-MD -MQ 'src/25a6634@@MangoHud@sha/vulkan.cpp.o' -MF 
'src/25a6634@@MangoHud@sha/vulkan.cpp.o.d' -o 
'src/25a6634@@MangoHud@sha/vulkan.cpp.o' -c ../src/vulkan.cpp
../src/vulkan.cpp:69:1: error: ‘VkPhysicalDeviceDriverProperties’ does not name 
a type; did you mean ‘VkPhysicalDeviceDriverPropertiesKHR’?
 VkPhysicalDeviceDriverProperties driverProps = {};
 ^~~~

I'm guessing there needs to be a minimum version for whichever package
provides the VkPhysicalDeviceDriverProperties symbol in its headers.

Regards,

Bob


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

Kernel: Linux 5.10.2-linux-latest-36 (SMP w/16 CPU cores; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)


Bug#979067: pinta: please package pinta 1.7

2021-01-02 Thread Kentaro Hayashi
Package: pinta
Version: 1.6-2
Severity: wishlist
X-Debbugs-Cc: ken...@xdump.org

Hi,

Pinta 1.7 was released last year, [1] and it contains many bug fixes which
including especially crash related:

* Fixed potential crashes when switching tools without any open documents
(#1425612).
* Fixed a crash when clicking on the Open Images pad after closing all images
(#1430789).
* Fixed a potential crash creating gradients (#1446217).
* Fixed some occasional crashes on dragging and dropping or pasting into a new
image (#1838620, #1508777).

I hope that pinta 1.7 will be available.

[1] https://github.com/PintaProject/Pinta/releases/tag/1.7



Bug#979069: pinta: please fix inconsistency state of pinta repository

2021-01-02 Thread Kentaro Hayashi
Package: pinta
X-Debbugs-Cc: ken...@xdump.org
Version: 1.6-2
Severity: wishlist


It seems that pinta repository [1] is not synced with released packages.


For example, the following version is missing in master branch

* pinta_1.3-3
* pinta_1.6-2

Then, the following version is missing in experimental branch

* pinta_1.6-1

[1] https://salsa.debian.org/dotnet-team/pinta


gbp import-dscs will resolve this inconsistency.

Regards,



Bug#979047: RM: pepperflashplugin-nonfree -- RoQA; No longer work; upstream eol

2021-01-02 Thread Adam D. Barratt
On Sat, 2021-01-02 at 19:53 +0800, Shengjing Zhu wrote:
> On Sat, Jan 2, 2021 at 7:51 PM Shengjing Zhu  wrote:
> > Package: ftp.debian.org
> > Severity: normal
> > X-Debbugs-Cc: z...@debian.org
> > 
> > As Adobe has shutdown the download of flash, this package now no
> > longer works.
> > 
> > https://www.adobe.com/products/flashplayer/end-of-life.html
> 
> If possible, remove it from stable and old-stable too.

The FTP Team don't handle stable or oldstable removals. However:

- removals from oldstable aren't possible once it moves to LTS;
however, the package isn't in stretch anyway

- for removal from stable, please "reportbug release.debian.org" and
follow the prompts.

Regards,

Adam



Bug#979071: ITP: neci -- Full Configuration Interaction Quantum Monte Carlo Code

2021-01-02 Thread Michael Banck
Package: wnpp
Severity: wishlist
Owner: Michael Banck 

* Package name: neci
  Version : git snapshot
  Upstream Author : George H. Booth and Ali Alavi
* URL : https://github.com/ghb24/NECI_STABLE
* License : GPLv3
  Programming Lang: Fortran90
  Description : Full Configuration Interaction Quantum Monte Carlo Code

The N-Electron Configuration Interaction (NECI) code base implements FCIQMC
(Full Configuration Interaction Quantum Monte Carlo), a method based on a
stochastic application of the Hamiltonian matrix on a sparse sampling of the
wave function.

It can be interfaced to both OpenMolcas and pySCF in order to implement
stochastic CASSCF (complete active space SCF).



Bug#979066: mangohud: Build fails on buster

2021-01-02 Thread Stephen Kitt
Hi Bob,

On Sat, 02 Jan 2021 13:07:44 +, Bob Ham 
wrote:
> Trying to build the mangohud package on buster fails with:
> 
> ccache c++ -Isrc/25a6634@@MangoHud@sha -Isrc -I../src -I../include
> -Isubprojects/dearimgui -I../subprojects/dearimgui -I.
> -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include
> -fvisibility=hidden -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64
> -std=c++14 -Werror=return-type -fno-math-errno -fno-trapping-math
> -Wno-non-virtual-dtor -Wno-missing-field-initializers
> -Wno-format-truncation -g -O2
> -fdebug-prefix-map=/store-f/rah/proj/games/mangohud-debian=.
> -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
> -D_FORTIFY_SOURCE=2 -fPIC -pthread -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS '-DPACKAGE_VERSION="v0.6.1"'
> -DNDEBUG -D_GNU_SOURCE -DHAVE_PTHREAD -DUSE_GCC_ATOMIC_BUILTINS
> -DHAVE_TIMESPEC_GET -DHAVE___BUILTIN_BSWAP32 -DHAVE___BUILTIN_BSWAP64
> -DHAVE___BUILTIN_CLZ -DHAVE___BUILTIN_CLZLL -DHAVE___BUILTIN_CTZ
> -DHAVE___BUILTIN_EXPECT -DHAVE___BUILTIN_FFS -DHAVE___BUILTIN_FFSLL
> -DHAVE___BUILTIN_POPCOUNT -DHAVE___BUILTIN_POPCOUNTLL
> -DHAVE___BUILTIN_UNREACHABLE '-DMANGOHUD_ARCH="64bit"' -DHAVE_XNVCTRL
> -DHAVE_X11 -DHAVE_DBUS -DVK_USE_PLATFORM_XLIB_KHR
> -DVK_USE_PLATFORM_WAYLAND_KHR -MD -MQ
> 'src/25a6634@@MangoHud@sha/vulkan.cpp.o' -MF
> 'src/25a6634@@MangoHud@sha/vulkan.cpp.o.d' -o
> 'src/25a6634@@MangoHud@sha/vulkan.cpp.o'
> -c ../src/vulkan.cpp ../src/vulkan.cpp:69:1: error:
> ‘VkPhysicalDeviceDriverProperties’ does not name a type; did you mean
> ‘VkPhysicalDeviceDriverPropertiesKHR’? VkPhysicalDeviceDriverProperties
> driverProps = {}; ^~~~
> 
> I'm guessing there needs to be a minimum version for whichever package
> provides the VkPhysicalDeviceDriverProperties symbol in its headers.

That symbol was added in Vulkan 1.2, so presumably the Vulkan dependency
needs to be "(>= 1.2~)". Note that an appropriate version of libvulkan-dev is
already available in buster-backports.

Regards,

Stephen


pgpoU0sEXs1Ox.pgp
Description: OpenPGP digital signature


Bug#979074: buster-pu: package gnutls28/3.6.7-4+deb10u6

2021-01-02 Thread Andreas Metzler
Package: release.debian.org
Severity: normal
Tags: buster
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
The gnutls28 test tests/testpkcs11.sh uses a test certificate that
expired in December 2020, which now causes a testsuite error and FTBFS.
If this is not approved the patch will need to be included in case of
another DSA for GnuTLS or a stable update. I would rather fix this now
to make debian-security's life easier.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
The patch uses datefudge to avoid the timebomb. It is cherrypicked and
adapted (older helper function) from upstream master.

TIA, cu Andreas

diff -Nru gnutls28-3.6.7/debian/changelog gnutls28-3.6.7/debian/changelog
--- gnutls28-3.6.7/debian/changelog	2020-06-07 07:45:55.0 +0200
+++ gnutls28-3.6.7/debian/changelog	2021-01-02 14:15:36.0 +0100
@@ -1,3 +1,11 @@
+gnutls28 (3.6.7-4+deb10u6) UNRELEASED; urgency=medium
+
+  * 45_4.7.0plus-01_testpkcs11-use-datefudge-to-trick-certificate-expiry.patch
+Fix test suite error caused by expired certificate.
+Closes: #977552
+
+ -- Andreas Metzler   Sat, 02 Jan 2021 14:15:36 +0100
+
 gnutls28 (3.6.7-4+deb10u5) buster; urgency=medium
 
   * 42_rel3.6.11_10-session-tickets-parse-extension-during-session-resum.patch
diff -Nru gnutls28-3.6.7/debian/patches/45_4.7.0plus-01_testpkcs11-use-datefudge-to-trick-certificate-expiry.patch gnutls28-3.6.7/debian/patches/45_4.7.0plus-01_testpkcs11-use-datefudge-to-trick-certificate-expiry.patch
--- gnutls28-3.6.7/debian/patches/45_4.7.0plus-01_testpkcs11-use-datefudge-to-trick-certificate-expiry.patch	1970-01-01 01:00:00.0 +0100
+++ gnutls28-3.6.7/debian/patches/45_4.7.0plus-01_testpkcs11-use-datefudge-to-trick-certificate-expiry.patch	2021-01-02 14:15:36.0 +0100
@@ -0,0 +1,73 @@
+From 2b0f6f3a2ff13153aaa70c764ba7a8b90aef794d Mon Sep 17 00:00:00 2001
+From: Daiki Ueno 
+Date: Mon, 28 Dec 2020 16:16:53 +0100
+Subject: [PATCH 3/6] testpkcs11: use datefudge to trick certificate expiry
+Origin: https://gitlab.com/gnutls/gnutls/-/commit/2b0f6f3a2ff13153aaa70c764ba7a8b90aef794d
+Bug: https://gitlab.com/gnutls/gnutls/-/issues/1135
+Bug-Debian: https://bugs.debian.org/977552
+
+The certificates stored in tests/testpkcs11-certs expired on
+2020-12-13.  To avoid verification failure due to that, use datefudge
+to set custom date when calling gnutls-cli, gnutls-serv, and certtool.
+
+Based on the patch by Andreas Metzler:
+https://gitlab.com/gnutls/gnutls/-/issues/1135#note_469682121
+
+Signed-off-by: Daiki Ueno 
+---
+ tests/testpkcs11.sh | 12 +++-
+ 1 file changed, 11 insertions(+), 1 deletion(-)
+
+--- a/tests/testpkcs11.sh
 b/tests/testpkcs11.sh
+@@ -67,6 +67,8 @@ have_ed25519=0
+ P11TOOL="${VALGRIND} ${P11TOOL} --batch"
+ SERV="${SERV} -q"
+ 
++TESTDATE=2020-12-01
++
+ . ${srcdir}/scripts/common.sh
+ 
+ rm -f "${LOGFILE}"
+@@ -79,6 +81,8 @@ exit_error () {
+ 	exit 1
+ }
+ 
++skip_if_no_datefudge
++
+ # $1: token
+ # $2: PIN
+ # $3: filename
+@@ -510,6 +514,7 @@ write_certificate_test () {
+ 	pubkey="$5"
+ 
+ 	echo -n "* Generating client certificate... "
++	datefudge -s "$TESTDATE" \
+ 	"${CERTTOOL}" ${CERTTOOL_PARAM} ${ADDITIONAL_PARAM}  --generate-certificate --load-ca-privkey "${cakey}"  --load-ca-certificate "${cacert}"  \
+ 	--template ${srcdir}/testpkcs11-certs/client-tmpl --load-privkey "${token};object=gnutls-client;object-type=private" \
+ 	--load-pubkey "$pubkey" --outfile tmp-client.crt >>"${LOGFILE}" 2>&1
+@@ -887,6 +892,7 @@ use_certificate_test () {
+ 	echo -n "* Using PKCS #11 with gnutls-cli (${txt})... "
+ 	# start server
+ 	eval "${GETPORT}"
++	SERV="datefudge -s $TESTDATE $SERV" \
+ 	launch_pkcs11_server $$ "${ADDITIONAL_PARAM}" --echo --priority NORMAL --x509certfile="${certfile}" \
+ 		--x509keyfile="$keyfile" --x509cafile="${cafile}" \
+ 		--verify-client-cert --require-client-cert >>"${LOGFILE}" 2>&1
+@@ -895,13 +901,16 @@ use_certificate_test () {
+ 	wait_server ${PID}
+ 
+ 	# connect to server using SC
++	datefudge -s "$TESTDATE" \
+ 	${VALGRIND} "${CLI}" ${ADDITIONAL_PARAM} -p "${PORT}" localhost --priority NORMAL --x509cafile="${cafile}" >"${LOGFILE}" 2>&1 && \
+ 		fail ${PID} "Connection should have failed!"
+ 
++	datefudge -s "$TESTDATE" \
+ 	${VALGRIND} "${CLI}" ${ADDITIONAL_PARAM} -p "${PORT}" localhost --priority NORMAL --x509certfile="${certfile}" \
+ 	--x509keyfile="$keyfile" --x509cafile="${cafile}" >"${LOGFILE}" 2>&1 || \
+ 		fail ${PID} "Connection (with files) should have succeeded!"
+ 
++	datefudge -s "$TESTDATE" \
+ 	${VALGRIND} "${CLI}" ${ADDITIONAL_PARAM} -p "${PORT}" localhost --priority NORMAL --x509certfile="${token};object=gnutls-client;object-type=cert" \
+ 		--x509keyfile="${token};object=gnutls-client;object-type=private" \
+ 		--x509cafile="${cafile}" >"${LOGFILE}" 2>&1 

Bug#979075: redshift-gtk silently adds to systemd causing double instance to run in user session

2021-01-02 Thread deb.bugs
Package: redshift-gtk
Version: 1.12-4
Severity: important
X-Debbugs-Cc: deb.b...@gmx.com

Dear Maintainer,

With the new version 1.12-4, redshift runs twice in the user session, causing
the screen to flicker if a redshift.conf file was previously created.
It is also impossible to kill thoses two instances. When trying, they restart
(zombie-like), and make the screen darker.

This behaviour is due to the fact that redshift and redshift-gtk launch through
systemd at startup.

When installing redshift and redshift-gtk from terminal, you get to read the
following lines:

symlink /etc/systemd/user/default.target.wants/redshift.service →
/usr/lib/systemd/user/redshift.service
symlink /etc/systemd/user/default.target.wants/redshift-gtk.service →
/usr/lib/systemd/user/redshift-gtk.service

Those links and service files cause a "systemd instance" of redshift to launch
parallel to the "user instance" of redshift.
Deleting those links and files (as root) solves the problem.



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages redshift-gtk depends on:
ii  gir1.2-ayatanaappindicator3-0.1  0.5.5-2
ii  init-system-helpers  1.60
ii  python3  3.9.0-4
ii  python3-gi   3.38.0-1+b2
ii  python3-xdg  0.26-3
ii  redshift 1.12-4

Versions of packages redshift-gtk recommends:
ii  at-spi2-core  2.38.0-2

redshift-gtk suggests no packages.

-- no debconf information


Bug#978679: bedtools: autpkgtest failures

2021-01-02 Thread John Marshall
See 
https://alioth-lists.debian.net/pipermail/debian-med-packaging/2020-December/088479.html
 (subject "bedtools autopkgtest fails due to missing htsutil").


Bug#979047: RM: pepperflashplugin-nonfree -- RoQA; No longer work; upstream eol

2021-01-02 Thread Shengjing Zhu
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: z...@debian.org

As Adobe has shutdown the download of flash, this package now no longer works.

https://www.adobe.com/products/flashplayer/end-of-life.html



Bug#979054: src:john: invalid maintainer address

2021-01-02 Thread Ansgar
Source: john
Version: 1.8.0-2
Severity: serious
X-Debbugs-Cc: Julián Moreno Patiño , Holger Levsen 


The maintainer address is invalid, see below.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Fri, 01 Jan 2021 14:49:16 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  rmol...@udea.edu.co
host ASPMX.L.GOOGLE.COM [74.125.195.26]
SMTP error from remote mail server after RCPT TO::
550-5.1.1 The email account that you tried to reach does not exist. Please 
try
550-5.1.1 double-checking the recipient's email address for typos or
550-5.1.1 unnecessary spaces. Learn more at
550 5.1.1  https://support.google.com/mail/?p=NoSuchUser 
em6si11683172pjb.73 - gsmtp



Bug#979052: src:nam: invalid maintainer address

2021-01-02 Thread Ansgar
Source: nam
Version: 1.15-5
Severity: serious
X-Debbugs-Cc: YunQiang Su , Holger Levsen 

The maintainer address is invalid, see below.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Sat, 02 Jan 2021 00:37:27 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  pkg-netsim-de...@lists.alioth.debian.org
host alioth-lists-mx.debian.net [2001:ba8:0:2c77:0:4:0:1]
SMTP error from remote mail server after RCPT 
TO::
550 Unrouteable address



Bug#979053: gettext-el: obsolete conffile left behind

2021-01-02 Thread Sven Joachim
Package: gettext-el
Version: 0.21-3

In version 0.21-1, gettext-el switched to dh-elpa and dropped the
conffile /etc/emacs/site-start.d/50gettext.el.  This is great, but the
old conffile should also be removed on upgrades.

Please refer to dpkg-maintscript-helper(1) and dh_installdeb(1) how to
properly clean up obsolete conffiles.


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

Kernel: Linux 5.10.4-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages gettext-el depends on:
ii  dh-elpa-helper  2.0.6
ii  emacsen-common  3.0.4
ii  gettext 0.21-3

gettext-el recommends no packages.

gettext-el suggests no packages.

-- no debconf information



Bug#979056: src:geronimo-jms-1.1-spec: invalid maintainer address

2021-01-02 Thread Ansgar
Source: geronimo-jms-1.1-spec
Version: 1.1-1
Severity: serious
X-Debbugs-Cc: Graziano Obertelli , Kyo Lee 
, Holger Levsen 

The maintainer address is invalid, see below.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Fri, 01 Jan 2021 18:50:00 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  g...@eucalyptus.com
retry timeout exceeded



Bug#979057: libexo-common: obsolete conffile left behind

2021-01-02 Thread Sven Joachim
Package: libexo-common
Version: 4.16.0-1

Your package used to ship the conffile /etc/xdg/xfce4/helpers.rc, but no
longer does include it.  I presume this is done on purpose since the
libexo-helpers package is also gone, yet the obsolete conffile remains
on the system after upgrades.

Please refer to dpkg-maintscript-helper(1) and dh_installdeb(1) how to
properly clean up obsolete conffiles.


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

Kernel: Linux 5.10.4-nouveau (SMP w/2 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

libexo-common depends on no packages.

libexo-common recommends no packages.

Versions of packages libexo-common suggests:
ii  sensible-utils  0.0.12+nmu1

-- no debconf information



Bug#963477: ruby-rack: CVE-2020-8184

2021-01-02 Thread Salvatore Bonaccorso
Hi Utkarsh

On Sat, Jan 02, 2021 at 05:45:04PM +0530, Utkarsh Gupta wrote:
> Hello,
> 
> On Sat, Jan 2, 2021 at 2:02 AM Salvatore Bonaccorso  wrote:
> > While strictly speaking this issue is no-dsa for buster, I'm raising
> > the severity to RC, would it be possible to address this issue for
> > unstable (and so bullseye) before the freeze?
> 
> Of course. Uploaded a fix! :)
> (thanks for the explicit CC, please do it next time as well if you
> want me to take care of something which falls under the Ruby team).

Thanks! About the explicit CC, well actually I was a bit "vary",
because if it's team maintained one should not start explicitly ping
some of the uploaders. But I'm glad if this was possible. Indeed there
would be more ruby team maintained packages which are currently no-dsa
marked but maybe would be good to fix for and in bullseye. There are
issues for instance in ruby-faye and ruby-faye-websocket as well:
967061, 959392, 967063.

Possibly though we are not to late for those for bullseye.

Regards and thank you!
Salvatore



Bug#978952: wsjtx: No audio on transmit

2021-01-02 Thread Christoph Berg
Re: Hilary Snaden
> Package: wsjtx
> Version: 2.3.0~rc2+repack-1+b1
> Severity: grave
> Justification: renders package unusable
> X-Debbugs-Cc: hilary.sna...@zoho.com
> 
> Dear Maintainer,
> 
> There is no audio output to any of the listed devices (I have tried them 
> all). This was also the case with version 2.2.2,

Hi,

there have been several "no audio" threads on the wsjtx-devel list.
Iirc the problem mostly happens if you click "tune" and then try to
transmit in the same period. Waiting a bit longer might help.

Christoph



Bug#979070: cura: Manage Materials and create or duplicate after some seconds it crashes in AutoSave.py

2021-01-02 Thread RA
Package: cura
Version: 4.8-1
Severity: important

I would need to enter my material into Cura. Otherwise I will not be able to
print.


It opens then a crash report with two fields:

Error traceback
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/cura/AutoSave.py", line 61, in
_onTimeout
self._application.saveSettings()
  File "/usr/lib/python3/dist-packages/cura/CuraApplication.py", line 723, in
saveSettings
ContainerRegistry.getInstance().saveDirtyContainers()
  File "/usr/lib/python3/dist-packages/cura/Settings/CuraContainerRegistry.py",
line 487, in saveDirtyContainers
self.saveContainer(instance)
  File "/usr/lib/python3/dist-packages/UM/Settings/ContainerRegistry.py", line
604, in saveContainer
container.setDirty(False)
  File "/usr/lib/cura/plugins/XmlMaterialProfile/XmlMaterialProfile.py", line
126, in setDirty
if base_file is not None and base_file != self.getId() and not
registry.isReadOnly(base_file):
  File "/usr/lib/python3/dist-packages/UM/Settings/ContainerRegistry.py", line
321, in isReadOnly
return provider.isReadOnly(container_id)
  File
"/usr/lib/uranium/plugins/LocalContainerProvider/LocalContainerProvider.py",
line 188, in isReadOnly
file_path = self._id_to_path[container_id]  # If KeyError: We don't know
this ID.
KeyError: 'custom_material'



Logs
Thread 0x7f1281ffb700 (most recent call first):
  File "/usr/lib/cura/plugins/USBPrinting/USBPrinterOutputDeviceManager.py",
line 87 in _updateThread
  File "/usr/lib/python3.9/threading.py", line 892 in run
  File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
  File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x7f12827fc700 (most recent call first):
  File
"/usr/lib/cura/plugins/RemovableDriveOutputDevice/RemovableDrivePlugin.py",
line 61 in _updateThread
  File "/usr/lib/python3.9/threading.py", line 892 in run
  File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
  File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x7f12837fe700 (most recent call first):
  File "/usr/lib/python3.9/threading.py", line 316 in wait
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 2232 in wait
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1539 in run
  File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
  File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x7f1283fff700 (most recent call first):
  File "/usr/lib/python3.9/threading.py", line 316 in wait
  File "/usr/lib/python3.9/threading.py", line 574 in wait
  File
"/usr/lib/cura/plugins/UM3NetworkPrinting/src/Network/ZeroConfClient.py", line
81 in _handleOnServiceChangedRequests
  File "/usr/lib/python3.9/threading.py", line 892 in run
  File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
  File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x7f12a0ad5700 (most recent call first):
  File "/usr/lib/python3.9/threading.py", line 316 in wait
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 2232 in wait
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1317 in run
  File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
  File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x7f12a12d6700 (most recent call first):
  File "/usr/lib/python3/dist-packages/zeroconf/__init__.py", line 1223 in run
  File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
  File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x7f12a2c7d700 (most recent call first):
  File "/usr/lib/python3/dist-packages/UM/Backend/Backend.py", line 165 in
_storeStderrToLogThread
  File "/usr/lib/python3.9/threading.py", line 892 in run
  File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
  File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x7f12a347e700 (most recent call first):
  File "/usr/lib/python3/dist-packages/UM/Backend/Backend.py", line 153 in
_storeOutputToLogThread
  File "/usr/lib/python3.9/threading.py", line 892 in run
  File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
  File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x7f12bbfff700 (most recent call first):
  File "/usr/lib/python3.9/threading.py", line 312 in wait
  File "/usr/lib/python3.9/threading.py", line 443 in acquire
  File "/usr/lib/python3/dist-packages/UM/JobQueue.py", line 98 in _nextJob
  File "/usr/lib/python3/dist-packages/UM/JobQueue.py", line 123 in run
  File "/usr/lib/python3.9/threading.py", line 954 in _bootstrap_inner
  File "/usr/lib/python3.9/threading.py", line 912 in _bootstrap

Thread 0x7f12dcef9700 (most recent call first):
  File "/usr/lib/python3.9/threading.py", line 312 in wait
  File "/usr/lib/python3.9/threading.py", line 443 in acquire
  File "/usr/lib/python3/dist-packages/UM/JobQueue.py", 

Bug#974979: make courier configuration by default on directories.. event files

2021-01-02 Thread Markus Wanner

Control: tags -1 -moreinfo
Control: severity -1 wishlist
Control: retitle -1 use configuration directories by default

On 12/31/20 2:44 PM, PICCORO McKAY Lenz wrote:

Currently  Courier uses several configuration files in /etc/courier
that can be replaced by a subdirectory whose contents are
concatenated and treated as a single, consolidated, configuration file.


Ah, understood.  Thanks for explaining.  I'm already using multiple 
files in a directory in most cases.  It seems well possible already, but 
just a matter of defaults.  I agree the directories should be created by 
default.



First setp to solve this is in courier-base package, must be changed
to true, this will create the minimal set of directories.


If you're speaking of the `courier-base/webadmin-configmode` template 
question, I'm with you.  This needs to vanish.



Later in a new revision remove the question and migrate to use
only directories (that can co-exist with normal files), manpages
of the courier suite points so many times about those directories..


Manpages should be adjusted to clarify both is possible, IMO.


by example the esmtpacceptmailfor: can be a single file
in the path /etc/courier/esmtpacceptmailfor of a directory at
the path /etc/courier/esmtpacceptmailfor.dir and all files inside
will be parsed as single one.


Yes, works that way.


better example is hosted domains, can be a single file in
/etc/courier/hosteddomains
but is better a directory /etc/courier/hosteddomains and each domain
could be a single file (named as the domain without dots) and with
domain inside in plain text.


I don't necessarily think that's a good approach, but I agree that it 
should be possible.  However, I think it already *is* possible now.  It 
clearly works for me (tm).  Anything in specific that doesn't work when 
configuring using multiple files in a directory?


Regards

Markus



Bug#979047: RM: pepperflashplugin-nonfree -- RoQA; No longer work; upstream eol

2021-01-02 Thread Shengjing Zhu
Control: clone -1 -2
Control: retitle -2 RM: pepperflashplugin-nonfree/1.8.4
Control: reassign -2 release.debian.org
Control: user release.debian@packages.debian.org
Control: usertag -2 rm


On Sat, Jan 2, 2021 at 9:59 PM Adam D. Barratt  wrote:
>
> On Sat, 2021-01-02 at 19:53 +0800, Shengjing Zhu wrote:
> > On Sat, Jan 2, 2021 at 7:51 PM Shengjing Zhu  wrote:
> > > Package: ftp.debian.org
> > > Severity: normal
> > > X-Debbugs-Cc: z...@debian.org
> > >
> > > As Adobe has shutdown the download of flash, this package now no
> > > longer works.
> > >
> > > https://www.adobe.com/products/flashplayer/end-of-life.html
> >
> > If possible, remove it from stable and old-stable too.
>
> The FTP Team don't handle stable or oldstable removals. However:
>
> - removals from oldstable aren't possible once it moves to LTS;
> however, the package isn't in stretch anyway
>
> - for removal from stable, please "reportbug release.debian.org" and
> follow the prompts.
>
> Regards,
>
> Adam
>

--
Shengjing Zhu



Bug#957045: bird: ftbfs with GCC-10

2021-01-02 Thread Benjamin Drung
Hi Ondřej,

On Fri, 17 Apr 2020 10:57:13 + Matthias Klose  wrote:
> Package: src:bird
> Version: 1.6.8-1
> Severity: normal
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-10
> 
> Please keep this issue open in the bug tracker for the package it
> was filed for.  If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
> 
> The package fails to build in a test rebuild on at least amd64 with
> gcc-10/g++-10, but succeeds to build with gcc-9/g++-9. The
> severity of this report will be raised before the bullseye release,
> so nothing has to be done for the buster release.
> 
> The full build log can be found at:
> http://people.debian.org/~doko/logs/gcc10-20200225/bird_1.6.8-1_unstable_gcc10.log
> The last lines of the build log are at the end of this report.

In consideration of the nearing freeze and the fix being applied
upstream, I took the opportunity to prepare a NMU and upload it without
delay. I also couldn't resist to address the lintian warning about
upstart. The debdiff is attached.

Since https://salsa.debian.org/debian/bird lacks the commits for the
last upload (1.6.8-2) I did not commit my changes to the repository, but
attach them as patches to this mail. Then you can apply them with
"git am" once you pushed the changes for 1.6.8-2.

-- 
Benjamin Drung
Debian & Ubuntu Developer
diff -Nru bird-1.6.8/debian/bird.bird6.upstart bird-1.6.8/debian/bird.bird6.upstart
--- bird-1.6.8/debian/bird.bird6.upstart	2020-05-11 10:27:20.0 +0200
+++ bird-1.6.8/debian/bird.bird6.upstart	1970-01-01 01:00:00.0 +0100
@@ -1,18 +0,0 @@
-# bird - BIRD Internet Routing Daemon (IPv6)
-
-description "BIRD Internet Routing Daemon (IPv6)"
-author "Ondřej Surý "
-
-start on runlevel [2345]
-stop on runlevel [016]
-
-respawn
-pre-start script
-/usr/lib/bird/prepare-environment
-/usr/sbin/bird6 -p
-end script
-
-script
-. /etc/bird/envvars
-exec /usr/sbin/bird6 -f -u $BIRD_RUN_USER -g $BIRD_RUN_GROUP $BIRD_ARGS
-end script
diff -Nru bird-1.6.8/debian/bird.bird.upstart bird-1.6.8/debian/bird.bird.upstart
--- bird-1.6.8/debian/bird.bird.upstart	2020-05-11 10:27:20.0 +0200
+++ bird-1.6.8/debian/bird.bird.upstart	1970-01-01 01:00:00.0 +0100
@@ -1,18 +0,0 @@
-# bird - BIRD Internet Routing Daemon (IPv4)
-
-description "BIRD Internet Routing Daemon (IPv4)"
-author "Ondřej Surý "
-
-start on runlevel [2345]
-stop on runlevel [016]
-
-respawn
-pre-start script
-/usr/lib/bird/prepare-environment
-/usr/sbin/bird -p
-end script
-
-script
-. /etc/bird/envvars
-exec /usr/sbin/bird -f -u $BIRD_RUN_USER -g $BIRD_RUN_GROUP $BIRD_ARGS
-end script
diff -Nru bird-1.6.8/debian/changelog bird-1.6.8/debian/changelog
--- bird-1.6.8/debian/changelog	2020-05-11 10:27:20.0 +0200
+++ bird-1.6.8/debian/changelog	2021-01-02 17:40:39.0 +0100
@@ -1,3 +1,11 @@
+bird (1.6.8-2.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix compilation with GCC 10 (Closes: #957045)
+  * Remove obsolete upstart files
+
+ -- Benjamin Drung   Sat, 02 Jan 2021 17:40:39 +0100
+
 bird (1.6.8-2) unstable; urgency=medium
 
   * Sync the linuxdoc mangled files with linuxdoc-tools_0.9.73-2
diff -Nru bird-1.6.8/debian/patches/0004-Unix-fix-compilation-with-GCC-10.patch bird-1.6.8/debian/patches/0004-Unix-fix-compilation-with-GCC-10.patch
--- bird-1.6.8/debian/patches/0004-Unix-fix-compilation-with-GCC-10.patch	1970-01-01 01:00:00.0 +0100
+++ bird-1.6.8/debian/patches/0004-Unix-fix-compilation-with-GCC-10.patch	2021-01-02 17:33:44.0 +0100
@@ -0,0 +1,34 @@
+From e4f91ee4cb11a10df6a61ab4ffcdc8e2da3c3483 Mon Sep 17 00:00:00 2001
+From: Vincent Bernat 
+Date: Mon, 28 Sep 2020 16:30:56 +0200
+Subject: Unix: fix compilation with GCC 10
+
+GCC 10 will now error when declaring a global variable twice:
+
+  https://gcc.gnu.org/gcc-10/porting_to.html#common
+
+Fix this issue by declaring the variable as `extern' in `krt.h'.
+The variable is really declared in `krt.c'.
+
+Bug-Debian: https://bugs.debian.org/957045
+Origin: upstream, https://gitlab.nic.cz/labs/bird/-/commit/e4f91ee4cb11a10df6a61ab4ffcdc8e2da3c3483
+---
+ sysdep/unix/krt.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sysdep/unix/krt.h b/sysdep/unix/krt.h
+index d4a8717e..fe79efc3 100644
+--- a/sysdep/unix/krt.h
 b/sysdep/unix/krt.h
+@@ -112,7 +112,7 @@ struct kif_proto {
+   struct kif_state sys;		/* Sysdep state */
+ };
+ 
+-struct kif_proto *kif_proto;
++extern struct kif_proto *kif_proto;
+ 
+ #define KIF_CF ((struct kif_config *)p->p.cf)
+ 
+-- 
+2.27.0
+
diff -Nru bird-1.6.8/debian/patches/series bird-1.6.8/debian/patches/series
--- bird-1.6.8/debian/patches/series	2020-05-11 10:27:20.0 +0200
+++ bird-1.6.8/debian/patches/series	2021-01-02 17:33:57.0 +0100
@@ -1,3 +1,4 @@
 0001-Link-using-ld.patch
 

Bug#978932: sympa: webinterface broken after installing 6.2.40~dfsg-1+deb10u1

2021-01-02 Thread Sylvain Beucler

Hi,

This looks like a duplicate of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972189
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972189#45

In the buster version though, CGI mode (which fcgiwrap emulates) was 
removed from Sympa hence why I didn't add the same NEWS note as in 
stretch. It looks like this was still working somehow.


For the record here is the NEWS note:

The fix for the CVE-2020-10936 security issue forced us to drop CGI
mode for wwsympa earlier than officially (6.2.24).

In particular, users of nginx+fcgiwrap are invited to switch to
nginx+spawn-fcgi:

https://sympa-community.github.io/manual/install/configure-http-server-spawnfcgi.html

See also:
https://bugs.debian.org/972189
https://github.com/sympa-community/sympa/issues/1020

Cheers!
Sylvain

On 31/12/2020 17:41, Tobias Frost wrote:

Package: sympa
Version: 6.2.40~dfsg-1+deb10u1
Severity: important

Dear Maintainer,

After installation of the security update the web isterface is defunct.
It still loads the "default" site (here: https://$DOMAIN/wws/) but that also
the site that will be loaded when selecting an menue entry, for example "Login".
(IOW, Login not possible as the login form is not presented)

Downgrading to 6.2.40~dfsg-1 makes it work again.

Webserver is an nginx instance.

The only hint I got (could be a red herring) is this in the nginx error log,
the sympa log is silent…

Heres a example of the  nginx one:
(There are many of those…)

2020/12/27 12:13:57 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun 
Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value in string ne at 
/usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M
[Sun Dec 27 12:13:57 2020] wwsympa.fcgi: Use of uninitialized value $remote_addr in string ne at 
/usr/share/sympa/lib/Sympa/WWW/Session.pm line 408" while reading upstream, client: 80.209.204.233, server: 
lists.regensburg-repariert.de, request: "GET /wws/reviewbouncing/info HTTP/2.0", upstream: 
"fastcgi://unix:/run/fcgiwrap.socket:", host: "lists.regensburg-repariert.de"
2020/12/27 12:14:21 [error] 8193#8193: *2819965 FastCGI sent in stderr: "[Sun 
Dec 27 12:14:21 2020] wwsympa.fcgi: Use of uninitialized value in string ne at 
/usr/share/sympa/lib/Sympa/WWW/Session.pm line 408.^M

(Those started exactly on Dec 24, after unattende-upgrades pulled in the 
security update)

Let me know if I can provide more information…

Cheers,





Bug#923198: would it work with elogind?

2021-01-02 Thread Mark Hindley
Sven,

Sorry about the slow reply with this.

On Mon, Sep 30, 2019 at 08:41:41PM +0200, Sven Joachim wrote:
> > But, instead of removing, you can change:
> > Recommends: libpam-systemd
> > to
> > Recommends: default-logind | logind
> >
> > which works nicely with elogind.
> 
> Makes sense.  Can you confirm that rootless X works with elogind?
> Use gdm3 as display manager, or startx and no display manager.

I can confirm that rootless X works with elogind using startx.

I hope that will enable you to make this change.

Thanks

Mark



Bug#976401: uftp: autopkgtest regression in testing: rm: cannot remove '/tmp/uftp-test-data': Operation not permitted

2021-01-02 Thread Adrian Bunk
On Fri, Dec 04, 2020 at 06:10:11PM +0100, Paul Gevers wrote:
> Source: uftp
> Version: 4.10.2-1
>...
> I diffed the installed package between the last successful run on amd64
> and the first the failed. It's:
>...
> uftp: Finishing at Sun Nov 29 11:29:19 2020
> + cmp ./uftp-test-data /tmp/uftp-test-data
> + cleanup
> + rv=0
> + rm -f ./uftp-test-data /tmp/uftp-test-data
> rm: cannot remove '/tmp/uftp-test-data': Operation not permitted
> autopkgtest [11:29:19]: test basic: ---]

Have there been any configuration changes to the autopkgtest environment
of packages running with the isolation-container restriction?

cu
Adrian



Bug#979065: src:yubikey-luks: invalid maintainer address

2021-01-02 Thread Ansgar
Source: yubikey-luks
Version: 0.5.1+29.g5df2b95-4
Severity: serious
X-Debbugs-Cc: Markus Frosch 

The maintainer address is invalid, see below.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Sat, 02 Jan 2021 12:36:29 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  yubikey-l...@tracker.debian.org
host ticharich.debian.org [2607:f8f0:614:1::1274:64]
SMTP error from remote mail server after RCPT 
TO::
550 Unrouteable address



Bug#976402: Proposed official virtual packages - todo and todo.txt

2021-01-02 Thread Bill Allombert
On Thu, Dec 31, 2020 at 04:42:46PM -0500, David Steele wrote:
> > Second seconds request.

> I'm not aware of any other inputs expected of me.

What Sean meant is that, at this stage, this proposal needs to be
seconded by people impacted by this virtual package before being
accepted.

If you know any, you can ask them, this would speed up the process.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 



Bug#978995: Useless in Debian

2021-01-02 Thread David Prévot

Hi Markus,

Le 02/01/2021 à 08:34, Markus Frosch a écrit :

On Fri, 2021-01-01 at 22:19 -0400, David Prévot wrote:

Package: php-dompdf
Severity: serious

[ Reported by a team member to see the package removed from testing ]



I kinda noticed that myself for a while, but it seems like civicrm [1] depends
on it now, which doesn't look like it would make it to bullseye.


Right, that’s a good reason to get it removed from testing but not 
unstable (yet). I’m afraid civicrm needs quite some work to be ready for 
testing again :/.



I'll open another serious bug for php-font-lib then.


Got it, thank you!

Regards

David



Bug#979080: libhtml-template-pro-perl FTCBFS: dependency issues

2021-01-02 Thread Helmut Grohne
Source: libhtml-template-pro-perl
Version: 0.9510-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

libhtml-template-pro-perl cannot be cross built from source, because its
build-depends are not cross satisfiably. Without thinking too much,
annotating test dependencies with  goes a long way. Once done,
the only thing left is replacing the perl dependency with perl-xs-dev
(which is now required for building perl extensions) and then
libhtml-test-pro-perl successfully cross builds. Please consider
applying the attached patch.

Helmut
diff --minimal -Nru libhtml-template-pro-perl-0.9510/debian/changelog 
libhtml-template-pro-perl-0.9510/debian/changelog
--- libhtml-template-pro-perl-0.9510/debian/changelog   2013-05-13 
21:24:25.0 +0200
+++ libhtml-template-pro-perl-0.9510/debian/changelog   2021-01-02 
09:51:48.0 +0100
@@ -1,3 +1,12 @@
+libhtml-template-pro-perl (0.9510-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: (Closes: #-1)
++ Annotate test dependencies with .
++ B-D perl-xs-dev for building a perl extension.
+
+ -- Helmut Grohne   Sat, 02 Jan 2021 09:51:48 +0100
+
 libhtml-template-pro-perl (0.9510-1) unstable; urgency=low
 
   [ Salvatore Bonaccorso ]
diff --minimal -Nru libhtml-template-pro-perl-0.9510/debian/control 
libhtml-template-pro-perl-0.9510/debian/control
--- libhtml-template-pro-perl-0.9510/debian/control 2013-05-13 
21:24:25.0 +0200
+++ libhtml-template-pro-perl-0.9510/debian/control 2021-01-02 
09:51:45.0 +0100
@@ -10,10 +10,10 @@
 Section: perl
 Priority: optional
 Build-Depends: debhelper (>= 9.20120312),
-   perl,
-   libjson-perl,
+   perl-xs-dev,
+   libjson-perl ,
libpcre3-dev,
-   libtest-pod-perl
+   libtest-pod-perl 
 Standards-Version: 3.9.4
 Vcs-Browser: 
http://anonscm.debian.org/gitweb/?p=pkg-perl/packages/libhtml-template-pro-perl.git
 Vcs-Git: 
git://anonscm.debian.org/pkg-perl/packages/libhtml-template-pro-perl.git


Bug#979081: libproxy should make test dependencis optional

2021-01-02 Thread Helmut Grohne
Source: libproxy
Version: 0.4.16-2
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

Please reduce the Build-Depends of libproxy. Some of the Build-Depends
are unsatisfiable during cross builds and a number of bootstrap
dependency cycles go via libproxy. A simple measure to help both is
annotating test dependencies with . I've tried building
libproxy with reduced dependencies and the ones annotated in the
attached patch result in identical binary artifacts as a full build.
Please consider applying it.

Helmut
diff --minimal -Nru libproxy-0.4.16/debian/changelog 
libproxy-0.4.16/debian/changelog
--- libproxy-0.4.16/debian/changelog2020-12-14 18:39:25.0 +0100
+++ libproxy-0.4.16/debian/changelog2021-01-02 14:07:18.0 +0100
@@ -1,3 +1,10 @@
+libproxy (0.4.16-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Tag test dependencies with . (Closes: #-1)
+
+ -- Helmut Grohne   Sat, 02 Jan 2021 14:07:18 +0100
+
 libproxy (0.4.16-2) unstable; urgency=medium
 
   * Fix the loading of the python module, patch from upstream
diff --minimal -Nru libproxy-0.4.16/debian/control 
libproxy-0.4.16/debian/control
--- libproxy-0.4.16/debian/control  2020-12-14 18:39:25.0 +0100
+++ libproxy-0.4.16/debian/control  2021-01-02 14:07:18.0 +0100
@@ -11,16 +11,16 @@
 Build-Depends: debhelper-compat (= 13),
dh-sequence-gnome,
dh-sequence-python3,
-   netbase,
+   netbase ,
cmake,
zlib1g-dev,
libnm-dev [linux-any],
libdbus-1-dev,
-   libkf5config-bin ,
-   libwebkit2gtk-4.0-dev ,
+   libkf5config-bin ,
+   libwebkit2gtk-4.0-dev ,
libjavascriptcoregtk-4.0-dev ,
libglib2.0-dev (>= 2.26) ,
-   libxmu-dev 
+   libxmu-dev 
 Standards-Version: 4.5.0
 Vcs-Browser: https://salsa.debian.org/gnome-team/libproxy
 Vcs-Git: https://salsa.debian.org/gnome-team/libproxy.git


Bug#979078: spriv-tools FTCBFS: build dependency python3-dev not installable

2021-01-02 Thread Helmut Grohne
Source: spirv-tools
Version: 2020.6-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

spirv-tools cannot be cross built from source, because its dependency on
the host architecture python3-dev fails to install. It does not actually
need the development files of python as it doesn't build an extension.
It really wants a build architecture python3. Thus the dependency can be
replaced with python3:native. Once doing so, spirv-tools becomes cross
buildable. Please consider applying the attached patch.

Helmut
diff --minimal -Nru spirv-tools-2020.6/debian/changelog 
spirv-tools-2020.6/debian/changelog
--- spirv-tools-2020.6/debian/changelog 2020-12-08 23:07:00.0 +0100
+++ spirv-tools-2020.6/debian/changelog 2021-01-02 09:28:27.0 +0100
@@ -1,3 +1,11 @@
+spirv-tools (2020.6-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Build-Depends python3:native instead of python3-dev.
+(Closes: #-1)
+
+ -- Helmut Grohne   Sat, 02 Jan 2021 09:28:27 +0100
+
 spirv-tools (2020.6-1) unstable; urgency=medium
 
   * New upstream release. (Closes: #975164)
diff --minimal -Nru spirv-tools-2020.6/debian/control 
spirv-tools-2020.6/debian/control
--- spirv-tools-2020.6/debian/control   2020-12-08 22:27:35.0 +0100
+++ spirv-tools-2020.6/debian/control   2021-01-02 09:28:22.0 +0100
@@ -4,7 +4,7 @@
 Maintainer: Debian X Strike Force 
 Build-Depends: debhelper-compat (= 12),
  cmake,
- python3-dev,
+ python3:native,
  spirv-headers (>= 1.5.4+rt~),
 Standards-Version: 4.5.0
 Homepage: https://github.com/KhronosGroup/SPIRV-Tools


Bug#979079: task cannot be cross built due to unsatisfiable build-depends

2021-01-02 Thread Helmut Grohne
Source: task
Version: 2.5.2+dfsg-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

task cannot be cross built from source, because it has a number of
unsatisfiable Build-Depends. Before thinking too long about this, one
immediately spots that dh-buildinfo is not used (in debian/rules) and
can be dropped with no replacement and that a number of build depends
are required for unit tests only and can thus be tagged . The
attached patch performs change while ensuring that the resulting .debs
remain identical to unmodified ones. Please consider applying it.

Helmut
diff --minimal -Nru task-2.5.2+dfsg/debian/changelog 
task-2.5.2+dfsg/debian/changelog
--- task-2.5.2+dfsg/debian/changelog2020-12-15 11:05:56.0 +0100
+++ task-2.5.2+dfsg/debian/changelog2021-01-02 11:26:41.0 +0100
@@ -1,3 +1,12 @@
+task (2.5.2+dfsg-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop unused dh-buildinfo.
++ Annotate test dependencies with .
+
+ -- Helmut Grohne   Sat, 02 Jan 2021 11:26:41 +0100
+
 task (2.5.2+dfsg-1) unstable; urgency=medium
 
   * d/watch: check github instead of taskwarrior.org
diff --minimal -Nru task-2.5.2+dfsg/debian/control 
task-2.5.2+dfsg/debian/control
--- task-2.5.2+dfsg/debian/control  2020-12-15 11:05:56.0 +0100
+++ task-2.5.2+dfsg/debian/control  2021-01-02 11:25:58.0 +0100
@@ -6,12 +6,11 @@
 Build-Depends: bash-completion,
cmake,
debhelper-compat (= 13),
-   dh-buildinfo,
-   git,
+   git ,
libgnutls28-dev,
-   libjson-perl,
-   libreadline-dev,
-   python3,
+   libjson-perl ,
+   libreadline-dev ,
+   python3 ,
uuid-dev
 Standards-Version: 4.5.0
 Homepage: https://taskwarrior.org


Bug#956633: libpango-1.0-0: 1.44.7-3 regression: wrong font rendering in geany/hexchat: invisible underscores

2021-01-02 Thread Mattia Rizzolo
On Sat, Dec 26, 2020 at 02:28:56AM +0100, Roland Hieber wrote:
> Mattia, I quickly tried the hexchat patch [2] and it improves things for
> me (line height is still a bit smaller than with pango 1.42, but
> underscores are visible again). Could you throw it into the Debian patch
> queue for hexchat?
> 
> [2]: https://github.com/hexchat/hexchat/pull/2500

Uploaded!

-- 
regards,
Mattia Rizzolo

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


signature.asc
Description: PGP signature


Bug#976113: RFS Review for Hydrogen

2021-01-02 Thread Ross Gammon
Hi Nicholas,

Good stuff. I think we are just about ready to upload. Here are the
comments from my review.

Please note, I was not able to do a test installation to check hydrogen
is working. I hope you can confirm that.

Blocking upload:
1. The package fails to build twice in a row (I used the --twice option
in pdebuild). It appears some translation files are not being cleaned
after the first build.

Minor things:
1. We could enable Salsa CI by adding a debian/salsa-ci.yml file.
2. I think the copyright-hints & check files can be removed as they were
used by cdbs?
3. The github issues page could be added to the upstream metadata file.
4. I am not sure what is going on with the icon. There is a lot going on
in d/rules and also a patch. This is probably something that should be
sorted out upstream. As a minimum we should probably forward our patch
upstream or tag the patch as "Forwarded: not-needed" if it is not an
upstream issue. I note that in Ubuntu, they install an svg into the
pixmaps folder.
5. Patch 2001 should probably be tagged as "Forwarded: not-needed" as it
seems Debian specific.
6. I see that even with all hardening options enabled in d/rules, we
still get the "hardening no fortify" lintian error. Are there some flags
not being passed to the build system?
7. I see the large number of commits to add library packages and upload
pre-release versions has resulted in some churn in the changelog. I
think some entries can be removed now that we have agreed to upload a
simpler structure and because it is a proper release (e.g. disabling the
documentation)?

Suggestions/Considerations:
1. It is worth taking a look at the version of hydrogen uploaded in
Ubuntu by Erich Eickmeyer. By adding ladspa-sdk and libtar as build
dependencies (and a patch), it appears that the hydrogen builds with
extra options. Erich also switched the jack dependency to jack2.
2. I see we have added a lintian override for the desktop and appdata
files not being in the same package as the executable. Is there a reason
for not just installing the desktop/appdata files with the executable
instead of in -data?

-- 
Regards,

Ross Gammon
FBEE 0190 904F 1EA0 BA6A  300E 53FE 7BBD A689 10FC



signature.asc
Description: OpenPGP digital signature


Bug#979042: node-rollup-plugin-commonjs: drop embedded copy of legacy plugin

2021-01-02 Thread Pirate Praveen

Control: fixed -1 17.0.0+repack-1

On Sat, 02 Jan 2021 16:39:48 +0530 Pirate Praveen 
 wrote:
> I plan to remove the embedded copy of legacy plugin (similar to how 
it
> was done for node-resolve and babel plugins) for bullseye. It is 
mostly
> a one line patch and we have to maintain only one copy of this 
module.


Uploaded to experimental.



Bug#979085: FTBFS on mips64el

2021-01-02 Thread Shengjing Zhu
Source: sopt
Version: 3.0.1-11
Severity: serious
X-Debbugs-Cc: z...@debian.org


When binNMU sopt, it FTBFS on mips64el, please check log at
https://buildd.debian.org/status/fetch.php?pkg=sopt=mips64el=3.0.1-11%2Bb1=1609594267=0

The following tests FAILED:
 19 - communicator (Bus error)
 20 - serial_vs_parallel_padmm (Bus error)
 21 - mpi_wavelets (Bus error)
 22 - mpi_session (Bus error)

The failed tests seem all related mpi, so I think it's not related to spdlog
or fmtlib. openmpi bumped its version from 4.0.5 to 4.1.0 on 2020-12-21. I
guess it's related to this change of openmpi.



Bug#979087: incompatible with node-postcss 8 and unmaintained

2021-01-02 Thread Pirate Praveen

Package: node-postcss-filter-plugins,node-postcss-minify-font-values
Severity: serious

Already filed request for removal. Filing rc bug in case the removal 
takes longer than auto removal from testing for node-postcss 8 testing 
migration.




Bug#979043: transition: dart

2021-01-02 Thread Sebastian Ramacher
Control: tags -1 + confirmed
Control: forwarded -1 https://release.debian.org/transitions/html/auto-dart.html

On 2021-01-02 12:20:52 +0100, Jochen Sprickerhof wrote:
> Package: release.debian.org
> Severity: normal
> User: release.debian@packages.debian.org
> Usertags: transition
> 
> Dear release team,
> 
> I would like to transition the dart library. I've successfully rebuild
> and tested it's only reverse build dependency: gazebo.
> 
> The automatically generated ben file looks fine.

Please go ahead.

Cheers
-- 
Sebastian Ramacher


signature.asc
Description: PGP signature


Bug#978431: texlive-base: dist-upgrade buster->bullseye fails

2021-01-02 Thread Hilmar Preuße

Am 31.12.2020 um 08:46 teilte Rene Engelhard mit:

Hi,


Just by chance.

My normal buster system dist-upgrade to bullseye.

Just found [1] Seems to be the only conflict in TL. I'll try to look 
into this.


Hilmar

[1] https://piuparts.debian.org/stable2sid/source/t/texlive-extra.html
--
sigfault




OpenPGP_signature
Description: OpenPGP digital signature


Bug#881761: signon-plugin-oauth2 FTCBFS: does not pass cross tools to qmake and other issues

2021-01-02 Thread Pino Toscano
Hi Helmut,

In data martedì 14 novembre 2017 22:32:01 CET, Helmut Grohne ha scritto:
> Source: signon-plugin-oauth2
> Version: 0.22-1
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
> 
> signon-plugin-oauth2 fails to cross build from source for multiple
> reasons:
>  * It does not pass cross tools to qmake. This task can be easily
>deferred to dh_auto_configure these days, but it doesn't fully work,
>so in the best case dh_auto_build will fail until debhelper is fixed.

This was a bug, even more problematic than just for cross-building.
I included this part in my recent signon-plugin-oauth2 0.25-1 upload.

>  * It uses uname -m to discover the host cpu, but that returns the build
>cpu of course.
>  * It uses plain pkg-config, which is the build architecture pkg-config
>while the host architecture one was expected.

These two look like genuine bugs as well. Can you please send them as
merge requests to the upstream repository?
https://gitlab.com/accounts-sso/signon-plugin-oauth2
Upstream accepts MRs, so it should be easy to send them patches.
I'd rather not include patches downstream that are kept there forever,
adding more work to the already small enough attention that this package
(and other Accounts SSO packages) already gets...

Thanks in advance,
-- 
Pino Toscano

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


Bug#979048: src:python-pgpy: invalid maintainer address

2021-01-02 Thread Ansgar
Source: python-pgpy
Version: 0.5.3-1
Severity: serious
X-Debbugs-Cc: Daniel Kahn Gillmor 

The maintainer address is invalid, see below.

Ansgar

 Forwarded Message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Sat, 02 Jan 2021 02:41:42 +

> This message was created automatically by mail delivery software.
>
> A message that you sent could not be delivered to one or more of its
> recipients. This is a permanent error. The following address(es)
> failed:
>
>   mgre...@securityinnovation.com
> host aspmx.l.google.com [64.233.167.27]
> SMTP error from remote mail server after RCPT 
> TO::
> 550-5.1.1 The email account that you tried to reach does not exist. 
> Please try
> 550-5.1.1 double-checking the recipient's email address for typos or
> 550-5.1.1 unnecessary spaces. Learn more at
> 550 5.1.1 
> https://support.google.com/mail/?p=NoSuchUser t12si32908402wre.71 - gsmtp


Reporting-MTA: dns; mailly.debian.org

Action: failed
Final-Recipient: rfc822;mgreene@securityinnovation.com
Status: 5.0.0
Remote-MTA: dns; aspmx.l.google.com
Diagnostic-Code: smtp; 550-5.1.1 The email account that you tried to reach does not exist. Please try
 550-5.1.1 double-checking the recipient's email address for typos or
 550-5.1.1 unnecessary spaces. Learn more at
 550 5.1.1  https://support.google.com/mail/?p=NoSuchUser t12si32908402wre.71 - gsmtp



Bug#964404: quagga is replaced by frr

2021-01-02 Thread Salvatore Bonaccorso
Hi,

On Mon, Jul 06, 2020 at 10:15:43PM +0300, Adrian Bunk wrote:
> Source: quagga
> Version: 1.2.4-4
> Severity: serious
> 
> The maintained fork from quagga that continues the zebra codebase is frr,
> which is already in buster:
> https://tracker.debian.org/pkg/frr
> 
> Additionally shipping quagga in bullseye might bring more confusion
> than benefits.

quagga is now already out of bullseye (at least this RC bugs prevents
it apart additional one). Would it be a good time now to actually ask
for removal of src:quagga in unstable as well?

Regards,
Salvatore



Bug#978155: transition: libqb

2021-01-02 Thread wferi
Sebastian Ramacher  writes:

> On 2020-12-26 19:43:53 +0100, Ferenc Wágner wrote:
> 
>> I'd like to transition to libqb version 2.  The dependency list is
>> fairly short, and mostly contains packages under the HA Team umbrella.
>> The only breakage is caused by symbols file changes, which I'm ready to
>> fix by sourceful uploads of corosync and pacemaker.  The kronosnet
>> package will also receive a sourceful upload to use the new binary
>> package doxygen2man.  Altogether I rebuilt the following packages in
>> preparation:
>> 
>> kronosnet (with source changes)
>> corosync (with source changes)
>> corosync-qdevice
>> pacemaker (with source changes)
>> dlm
>> booth
>> fence-virt
>> sbd
>> ocfs2-tools
>> lvm2
>> usbguard
> 
> Please go ahead with the uploads to unstable.

Hi,

Thanks for triggering the sbd binNMU right after the pacemaker upload
finished buiding on all architectures!  The other packages mentioned
above are all transitive build dependencies, I think they are safe to be
left alone.

There's one last thing which may cause problems (or not): the libqb
testing migration is blocked with the excuse "missing build on all".
However, libqb-doc isn't built anymore, so libqb 2 doesn't ship any
arch-all packages.  If this needs manual intervention, please effect it.

Whoops, you already requested its removal in #979045.  I'm amazed by
your level of attention!  Much appreciated!
-- 
Thanks,
Feri



Bug#968589: PPP name resolver service not restarted upon upgrade

2021-01-02 Thread 積丹尼 Dan Jacobson
Perhaps you could tell me,
how to hardwire
primary   DNS address 168.95.192.1
secondary DNS address 168.95.1.1
for ever and ever, into pppd.
Looking at the man page doesn't say.
Looking at /usr/share/doc/ppp neither.
This is all getting rather crazy.
Hardwiring it in is the right thing for losers like me.
Thanks.



Bug#979050: pyserial-asyncio FTBFS: ERROR: test_asyncio (test.test_asyncio.Test_asyncio)

2021-01-02 Thread Adrian Bunk
Source: pyserial-asyncio
Version: 0.5-1
Severity: serious
Tags: ftbfs

https://buildd.debian.org/status/fetch.php?pkg=pyserial-asyncio=all=0.5-1=1609583381=0

...
   dh_auto_test -i -O--buildsystem=pybuild
I: pybuild base:232: cd 
/<>/.pybuild/cpython3_3.9_pyserial_asyncio/build; python3.9 -m 
unittest discover -v 
test_asyncio (test.test_asyncio.Test_asyncio) ... ERROR

==
ERROR: test_asyncio (test.test_asyncio.Test_asyncio)
--
Traceback (most recent call last):
  File 
"/<>/.pybuild/cpython3_3.9_pyserial_asyncio/build/test/test_asyncio.py",
 line 89, in test_asyncio
self.loop.run_until_complete(coro)
  File "/usr/lib/python3.9/asyncio/base_events.py", line 642, in 
run_until_complete
return future.result()
  File "/usr/lib/python3.9/asyncio/base_events.py", line 1494, in create_server
raise OSError(err.errno, 'error while attempting '
OSError: [Errno 98] error while attempting to bind on address ('127.0.0.1', 
): address already in use

--
Ran 1 test in 0.003s

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



Bug#979051: src:aspell-hr: invalid maintainer address

2021-01-02 Thread Ansgar
Source: aspell-hr
Version: 0.51-4
Severity: serious
X-Debbugs-Cc: Holger Levsen 

The maintainer address is invalid, see below.

Ansgar

 Start of forwarded message 
From: Mail Delivery System 
Subject: Mail delivery failed: returning message to sender
Date: Sat, 02 Jan 2021 01:48:31 +

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  vedr...@riteh.hr
host rijeka.riteh.hr [161.53.40.4]
SMTP error from remote mail server after RCPT TO::
550 5.1.1 : Recipient address rejected:
User unknown in local recipient table



Bug#977468: CVE-2018-1285

2021-01-02 Thread Salvatore Bonaccorso
Control: severity -1 grave

Hi

On Tue, Dec 15, 2020 at 01:20:04PM +0100, Moritz Muehlenhoff wrote:
> Source: log4net
> Severity: important
> Tags: security
> X-Debbugs-Cc: Debian Security Team 
> 
> Please see https://issues.apache.org/jira/browse/LOG4NET-575
> 
> Patch:
> https://github.com/apache/logging-log4net/commit/d0b4b0157d4af36b23c24a23739c47925c3bd8d7

Altough the issue no-dsa for stable releases, it seems worth includign
the fix in unstable and so future bullseye, and for that raising the
severity to RC.

Is log4net still maintained in Debian? We seme to have 1.2.10+dfsg-7
across all still supported suites.

Regards,
Salvatore



Bug#979060: getmail6: should provide a getmail binary package

2021-01-02 Thread Sven Joachim
Package: getmail6
Version: 6.11-1

The getmail source and binary packages have been removed from Debian[1].
To facilitate upgrades from Buster, src:getmail6 should take over the
getmail binary package, otherwise its users will either be left with an
unsupported obsolete package or with nothing at all, depending on what
apt decides to do during the dist-upgrade to Bullseye.


1.  https://tracker.debian.org/news/1201723/removed-513-1-from-unstable/



Bug#979062: please update to rpm 4.16.x

2021-01-02 Thread Matthias Klose
Package: src:rpm
Version: 4.14.2.1+dfsg1-1.1
Severity: important
Tags: sid bullseye patch

please consider updating to rpm 4.16.x in time for the bullseye release.
Compared to buster, there's no upstream version update.

A packaging proposal can be found at
https://launchpad.net/ubuntu/+source/rpm/4.16.1.2+dfsg1-0ubuntu2

diff -urN rpm-4.14.2.1+dfsg1/debian/changelog 
rpm-4.16.1.2+dfsg1/debian/changelog
--- rpm-4.14.2.1+dfsg1/debian/changelog 2020-02-28 19:52:17.0 +0100
+++ rpm-4.16.1.2+dfsg1/debian/changelog 2021-01-02 13:07:03.0 +0100
@@ -1,3 +1,24 @@
+rpm (4.16.1.2+dfsg1-0ubuntu2) hirsute; urgency=medium
+
+  * New upstream version.
+  * Remove patches applied upstream:
+- d/p/map-populate.patch
+- d/p/bashism.patch
+- d/p/lua-compat.patch
+  * Add build dependencies on libaudit-dev and libgcrypt20-dev.
+  * librpm-dev: Depend on libaudit-dev and libgcrypt20-dev.
+  * Add build dependency on gnupg2. Closes: #977827.
+  * rpm: Stop installing files not shipped anymore.
+- usr/lib/rpm/mono*
+- usr/lib/rpm/ocaml-find-requires.sh
+- usr/lib/rpm/*.prov
+  * debian/rpm2archive.8: Remove, provided upstream.
+  * Bump soname versions, update symbols files.
+  * debian/rules: Override dh_auto_clean.
+  * Bump standards version.
+
+ -- Matthias Klose   Sat, 02 Jan 2021 13:07:03 +0100
+
 rpm (4.14.2.1+dfsg1-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -urN rpm-4.14.2.1+dfsg1/debian/control rpm-4.16.1.2+dfsg1/debian/control
--- rpm-4.14.2.1+dfsg1/debian/control   2020-02-28 19:35:40.0 +0100
+++ rpm-4.16.1.2+dfsg1/debian/control   2021-01-02 13:03:53.0 +0100
@@ -31,8 +31,11 @@
libdw-dev,
libdb-dev,
liblua5.2-dev,
-   libsemanage1-dev [linux-any]
-Standards-Version: 4.5.0
+   libsemanage1-dev [linux-any],
+   libgcrypt20-dev,
+   libaudit-dev,
+   gnupg2,
+Standards-Version: 4.5.1
 Vcs-Browser: https://salsa.debian.org/pkg-rpm-team/rpm
 Vcs-Git: https://salsa.debian.org/pkg-rpm-team/rpm.git
 Homepage: https://rpm.org/
@@ -99,12 +102,12 @@
  .
  This package contains localization of rpm and localized man pages.
 
-Package: librpm8
+Package: librpm9
 Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- librpmio8 (= ${binary:Version})
+ librpmio9 (= ${binary:Version})
 Recommends: rpm-common (= ${binary:Version})
 Description: RPM shared library
  The RPM Package Manager (RPM) is a command-line driven package
@@ -114,7 +117,7 @@
  This library allows programs to make use of an RPM database or RPM packages
  without going through the program rpm.
 
-Package: librpmio8
+Package: librpmio9
 Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
@@ -126,13 +129,13 @@
  .
  This library provides basic IO functionality which is used by librpm.
 
-Package: librpmbuild8
+Package: librpmbuild9
 Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- librpm8 (= ${binary:Version}),
- librpmio8 (= ${binary:Version})
+ librpm9 (= ${binary:Version}),
+ librpmio9 (= ${binary:Version})
 Description: RPM build shared library
  The RPM Package Manager (RPM) is a command-line driven package
  management system capable of installing, uninstalling, verifying,
@@ -140,13 +143,13 @@
  .
  This library provides an interface for building RPM packages.
 
-Package: librpmsign8
+Package: librpmsign9
 Architecture: any
 Section: libs
 Depends: ${shlibs:Depends},
  ${misc:Depends},
- librpm8 (= ${binary:Version}),
- librpmio8 (= ${binary:Version})
+ librpm9 (= ${binary:Version}),
+ librpmio9 (= ${binary:Version})
 Description: RPM signing shared library
  The RPM Package Manager (RPM) is a command-line driven package
  management system capable of installing, uninstalling, verifying,
@@ -158,10 +161,10 @@
 Architecture: any
 Section: libdevel
 Priority: optional
-Depends: librpm8 (= ${binary:Version}),
- librpmio8 (= ${binary:Version}),
- librpmbuild8 (= ${binary:Version}),
- librpmsign8 (= ${binary:Version}),
+Depends: librpm9 (= ${binary:Version}),
+ librpmio9 (= ${binary:Version}),
+ librpmbuild9 (= ${binary:Version}),
+ librpmsign9 (= ${binary:Version}),
  libc6-dev,
  libpopt-dev,
  libdb-dev,
@@ -172,6 +175,8 @@
  libzstd-dev,
  libselinux1-dev [linux-any],
  libsqlite3-dev,
+ libgcrypt20-dev,
+ libaudit-dev,
  ${misc:Depends}
 Description: RPM shared library, development kit
  The RPM Package Manager (RPM) is a command-line driven package
@@ -189,10 +194,10 @@
 Depends: ${misc:Depends},
  ${shlibs:Depends},
  ${python3:Depends},
- librpm8 (= ${binary:Version}),
- librpmio8 (= ${binary:Version}),
- librpmbuild8 (= ${binary:Version}),
-  

Bug#979000: libasound2: [Raven/Raven2/FireFlight/Renoir AMD Ryzen] No Sound at all

2021-01-02 Thread Elimar Riesebieter
Hi Maya

* Maya  [2021-01-01 21:42 +0100]:

> Package: libasound2
> Version: 1.2.4-1
> Severity: important
> Tags: newcomer
> X-Debbugs-Cc: maya587...@re-gister.com
> 
> With Debian testing freshly installed on my new Lenovo IdeaPad 5 14ARE05 
> (dual boot
> with Win 10), the sound output isn't working. I can only select 'HDMI1 
> Output' or
> 'HDMI2 Output' as an output device.
> This issue seems to be the one described here for Ubuntu:
> https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1901157
> According to the thread this has been fixed for Ubuntu, but I couldn't find 
> it in the
> changelogs of Debian alsa-lib.

This bug should be fixed by
https://github.com/alsa-project/alsa-lib/commit/d77fb4731886ff1244e815a05b2be6d261382cbe
which is applied to alsa-lib 1.2.4.

[...] 


> Versions of packages libasound2 depends on:
> ii  libasound2-data  1.2.4-1
> ii  libc62.31-6
> 
> libasound2 recommends no packages.
> 
> Versions of packages libasound2 suggests:
> ii  libasound2-plugins  1.2.2-2

Could you please provide the output of

$ dpkg -l | egrep "(alsa|libasound)"

Elimar
-- 
  Numeric stability is probably not all that
  important when you're guessing;-)



Bug#904113: CVE-2018-11489

2021-01-02 Thread Salvatore Bonaccorso
Control: reopen -1

On Thu, Jul 19, 2018 at 11:37:29PM +0200, Moritz Muehlenhoff wrote:
> Source: giflib
> Severity: important
> Tags: security
> 
> https://sourceforge.net/p/giflib/bugs/112/

Looks the wrong bug was closed here? CVE-2018-11490 was sf#113, while
this one is CVE-2018-11489, sf#112, which does not seem to be adressed
yet (altough the upstream report disapeared).

Regards,
Salvatore



Bug#968589: PPP name resolver service not restarted upon upgrade

2021-01-02 Thread 積丹尼 Dan Jacobson
# cat /etc/resolv.conf
# MADE BY ME in /root/bin/openpppd
nameserver 168.95.192.1
nameserver 168.95.1.1
# ls -l /etc/resolv.conf
lrwxrwxrwx 1 root root 39 08-09 02:29 /etc/resolv.conf -> 
../run/systemd/resolve/stub-resolv.conf

Too bad it will always be a link,
even though I did
systemctl disable --now systemd-resolved.service



Bug#968589: PPP name resolver service not restarted upon upgrade

2021-01-02 Thread Chris Boot
On Sat, 2 Jan 2021, at 12:35, 積丹尼 Dan Jacobson wrote:
> # cat /etc/resolv.conf
> # MADE BY ME in /root/bin/openpppd
> nameserver 168.95.192.1
> nameserver 168.95.1.1
> # ls -l /etc/resolv.conf
> lrwxrwxrwx 1 root root 39 08-09 02:29 /etc/resolv.conf -> 
> ../run/systemd/resolve/stub-resolv.conf
> 
> Too bad it will always be a link,
> even though I did
> systemctl disable --now systemd-resolved.service

The Debian BTS is not a personal support service. Please send your questions to 
debian-u...@lists.debian.org or a similar forum. 



Bug#963477: ruby-rack: CVE-2020-8184

2021-01-02 Thread Utkarsh Gupta
Hi Salvatore,

On Sat, Jan 2, 2021 at 5:55 PM Salvatore Bonaccorso  wrote:
> > Of course. Uploaded a fix! :)
> > (thanks for the explicit CC, please do it next time as well if you
> > want me to take care of something which falls under the Ruby team).
>
> Thanks! About the explicit CC, well actually I was a bit "vary",
> because if it's team maintained one should not start explicitly ping
> some of the uploaders. But I'm glad if this was possible.

It's not a problem, I am happy to help the security team as much as I
possibly can (though you'd hopefully know that by now ;)).

> Indeed there would be more ruby team maintained packages which
> are currently no-dsa marked but maybe would be good to fix for
> and in bullseye. There are issues for instance in ruby-faye and
> ruby-faye-websocket as well: 967061, 959392, 967063.

Eeks, sorry for not noticing them earlier. But I've uploaded a fix for all
three of them^ :)

Let me know if there are more that needs immediate fixing or so! \o/


- u



Bug#979076: redshift adds silently to systemd causing it to run twice in user session

2021-01-02 Thread deb.bugs
Package: redshift
Version: 1.12-4
Severity: important
X-Debbugs-Cc: deb.b...@gmx.com

Dear Maintainer,

With the new version 1.12-4, redshift runs twice in the user session, causing
the screen to flicker if a redshift.conf file was previously created.
It is also impossible to kill thoses two instances. When trying, they restart
(zombie-like), and make the screen darker.

This behaviour is due to the fact that redshift and redshift-gtk launch through
systemd at startup.

When installing redshift and redshift-gtk from terminal, you get to read the
following lines:

symlink /etc/systemd/user/default.target.wants/redshift.service →
/usr/lib/systemd/user/redshift.service
symlink /etc/systemd/user/default.target.wants/redshift-gtk.service →
/usr/lib/systemd/user/redshift-gtk.service

Those links and service files cause a "systemd instance" of redshift to launch
parallel to the "user instance" of redshift.
Deleting those links and files (as root) solves the problem.



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_BE:fr
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages redshift depends on:
ii  init-system-helpers  1.60
ii  libc62.31-6
ii  libdrm2  2.4.103-2
ii  libglib2.0-0 2.66.4-1
ii  libwayland-client0   1.18.0-2~exp1.1
ii  libx11-6 2:1.6.12-1
ii  libxcb-randr01.14-2.1
ii  libxcb1  1.14-2.1
ii  libxxf86vm1  1:1.1.4-1+b2

Versions of packages redshift recommends:
ii  geoclue-2.0  2.5.7-2

redshift suggests no packages.

-- no debconf information


Bug#978944: linux-image-5.10.0-1-amd64-unsigned: Please enable CONFIG_PCENGINES_APU2

2021-01-02 Thread Vincent Blut

Control: tags -1 moreinfo

Hi,

Le 2020-12-31T23:52+0100, Maximilian Wilhelm a écrit :

Package: src:linux
Version: 5.10.4-1
Severity: wishlist

Dear Maintainer,

while booting the latest kernels on PCengins APU2 boards I noticed to following
entry in the kernel log:

leds_apu: No PC Engines APUv1 board detected. For APUv2,3 support, enable 
CONFIG_PCENGINES_APU2

It would be nice to have supporte for fiddling with the LEDs of the board so I
would like to ask you to enable above config option in future kernels if there
is no reasons to not to :)


CONFIG_PCENGINES_APU2 is already enabled. Could you please check that 
the "pcengines-apuv2" module is correctly loaded?



Thank you for you work!

Kind regards
Max


Cheers,
Vincent


signature.asc
Description: PGP signature


Bug#979086: node-regexpp: empty vcs git repo

2021-01-02 Thread Pirate Praveen

Package: node-regexpp
Version: 3.1.0-4

Git repo of this package is empty. Please push the git repo to salsa.



Bug#979049: marco: debian/rules do not clean source tree

2021-01-02 Thread Mike Gabriel

Control: severity -1 minor

Hi Nicholas,

On  Sa 02 Jan 2021 12:29:53 CET, Nicholas Guriev wrote:


Source: marco
Version: 1.24.1-1
Severity: serious
Dear Maintainer,

After the following commands run in an package tree dpkg-source sees source
modifications.

export DEB_BUILD_OPTIONS="parallel=4"
debian/rules build
debian/rules clean

Full difference between unpacked directory and after built & clean  
is attached.

It was obtained with `diff -U3 -r`.

The bug has serious severity level because of volition "must" clause  
in §4.9 of

Debian Policy Manual.


clean (required)

This must undo any effects that the build and binary targets may  
have had ...


However, the bug has no impact on end users so I think in the future its
severity may be lowered to minor.


Currently, it is not release critical if packages don't build and  
clean up afterwards in an idempotent way. Although, it is something  
nice-to-have.


Thus, lowering severity immediately to minor.

Mike
--

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpwGRQTFivPZ.pgp
Description: Digitale PGP-Signatur


Bug#979088: plasma-applet-redshift-control: redshift

2021-01-02 Thread Josef Kufner
Package: plasma-applet-redshift-control
Version: 1.0.18+phabricator~2019080100-1
Severity: important

Dear Maintainer,

redshift package adds systemd user unit to start redshift in the session
automatically, which makes the redshift run twice using different
configuration.

This is related to #979075 and #979076.

I guess some kind of per-session shared configuration should be implemented to
make sure the redshift runs only once and with the desired configuration.

Workaround: systemctl stop redshift.service --user && systemctl disable
redshift.service --user



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_CRAP, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE
Locale: LANG=cs_CZ.UTF-8, LC_CTYPE=cs_CZ.UTF-8 (charmap=UTF-8), 
LANGUAGE=cs:en_US:en_GB
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plasma-applet-redshift-control depends on:
ii  fonts-font-awesome  5.0.10+really4.7.0~dfsg-4
ii  redshift1.12-4

plasma-applet-redshift-control recommends no packages.

plasma-applet-redshift-control suggests no packages.

-- no debconf information



Bug#979047: RM: pepperflashplugin-nonfree -- RoQA; No longer work; upstream eol

2021-01-02 Thread Shengjing Zhu
On Sat, Jan 2, 2021 at 7:51 PM Shengjing Zhu  wrote:
>
> Package: ftp.debian.org
> Severity: normal
> X-Debbugs-Cc: z...@debian.org
>
> As Adobe has shutdown the download of flash, this package now no longer works.
>
> https://www.adobe.com/products/flashplayer/end-of-life.html

If possible, remove it from stable and old-stable too.

-- 
Shengjing Zhu



Bug#963477: ruby-rack: CVE-2020-8184

2021-01-02 Thread Utkarsh Gupta
Hello,

On Sat, Jan 2, 2021 at 2:02 AM Salvatore Bonaccorso  wrote:
> While strictly speaking this issue is no-dsa for buster, I'm raising
> the severity to RC, would it be possible to address this issue for
> unstable (and so bullseye) before the freeze?

Of course. Uploaded a fix! :)
(thanks for the explicit CC, please do it next time as well if you
want me to take care of something which falls under the Ruby team).


- u



Bug#979061: xfce4-screenshooter missleading/false panel icon

2021-01-02 Thread Alf
Package: xfce4-screenshooter
Version: 1.9.8-1
Severity: normal

Dear Maintainer,

   * What led up to the situation?
updating from Buster to Bullseye

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
The icon sits in the panel at a size of 32x32 pixels and shows a monitor
with a  crossed-out screen. This lets one assume that it will i.e.
switch-off the monitor or just kill the X-server. Not knowing what it
was in earlier versions you never would guess it will take a screenshot.

Having a look at the icon file at higher resolutions reveals that it
should represent a scissor and a dotted rectangle which indictes
something to be cut out.

Additionally the light blue color spoils the look when sitting in a dark
panel. I am using the greybird theme and not bluebird.

   * What outcome did you expect instead?

A timy neutral (in color) panal icon showing a camera like in Buster and
earlier versions of Debian.



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

Kernel: Linux 5.9.0-5-amd64 (SMP w/4 CPU threads)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE
not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xfce4-screenshooter depends on:
ii  libc62.31-6
ii  libcairo21.16.0-4
ii  libexo-2-0   4.16.0-1
ii  libgdk-pixbuf-2.0-0  2.42.2+dfsg-1
ii  libglib2.0-0 2.66.4-1
ii  libgtk-3-0   3.24.24-1
ii  libsoup2.4-1 2.72.0-2
ii  libx11-6 2:1.6.12-1
ii  libxext6 2:1.3.3-1.1
ii  libxfce4ui-2-0   4.16.0-1
ii  libxfce4util74.16.0-1
ii  libxfixes3   1:5.0.3-2
ii  libxml2  2.9.10+dfsg-6.3+b1

Versions of packages xfce4-screenshooter recommends:
ii  libxfce4panel-2.0-4  4.14.4-1

xfce4-screenshooter suggests no packages.

-- no debconf information



Bug#968589: PPP name resolver service not restarted upon upgrade

2021-01-02 Thread 積丹尼 Dan Jacobson
OK, I figured it out!

cat > /etc/resolv.conf <

Bug#979064: python-xarray doesn't migrate

2021-01-02 Thread Matthias Klose
Package: src:python-xarray
Version: 0.16.2-1
Severity: serious
Tags: sid bullseye

python-xarray doesn't migrate, because numba is not in testing.  If you want the
recent version to migrate, please build without numba support.



Bug#977956: Bug#977870: fixed in chromium 87.0.4280.88-0.4

2021-01-02 Thread Michel Le Bihan
Hello,

I also have an IvyBridge laptop with the i5-3210M and can't reproduce
your issue. Could you please list the graphic related packages that you
have installed and any config changes you have made?

Michel Le Bihan



Bug#979068: deluge-gtk: must depend on at-spi2-core

2021-01-02 Thread sergio
Package: deluge-gtk
Version: 2.0.3-3
Severity: important

Dear Maintainer,

deluge-gtk must depend on at-spi2-core as it segfaults without it:

https://dev.deluge-torrent.org/ticket/3433



Bug#979073: libvtk9-dev: RenderingContextOpenGL2 must be configured explicitly

2021-01-02 Thread Drew Parsons
Package: libvtk9-dev
Version: 9.0.1+dfsg1-5
Severity: normal
Control: affects -1 src:avogadrolibs

I'm trying to build avogadrolibs with VTK support.  It uses
vtkRenderingContextOpenGL2, but this is not currently provided by
libvtk9-dev.

According to discussion at
https://discourse.vtk.org/t/9-0-0-rc1-contextopengl2-not-built/2933
apparently the VTK build now needs to specify RenderingContextOpenGL2
explicitly with -DVTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2=YES:
  cmake -DVTK_MODULE_ENABLE_VTK_RenderingContextOpenGL2=YES ..

Discussion there suggests it was automatically built in the past.
Build behaviour might have changed with commit f46c6717,
https://gitlab.kitware.com/vtk/vtk/-/commit/f46c67172e6dafd239a3fd19ae61490c96ede7dd


(there's some peripherally related discussion at
https://gitlab.kitware.com/vtk/vtk/-/issues/17584 )


Is it possible to enable RenderingContextOpenGL2 in the VTK build?



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

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

Versions of packages libvtk9-dev depends on:
ii  default-jdk2:1.11-72
ii  default-libmysqlclient-dev 1.0.6
ii  libavcodec-dev 7:4.3.1-5
ii  libavformat-dev7:4.3.1-5
ii  libavutil-dev  7:4.3.1-5
ii  libc6-dev  2.31-6
ii  libdouble-conversion-dev   3.1.5-6.1
ii  libeigen3-dev  3.3.9-1
ii  libexpat1-dev [libexpat-dev]   2.2.10-1
ii  libfreetype6-dev   2.10.4+dfsg-1
ii  libgdal-dev3.2.0+dfsg-1
ii  libgl-dev  1.3.2-1
ii  libgl1-mesa-dev20.2.6-1
ii  libgl2ps-dev   1.4.2+dfsg1-1
ii  libglew-dev2.1.0-4+b1
ii  libglu1-mesa-dev [libglu-dev]  9.0.1-1
ii  libhdf5-mpi-dev1.10.6+repack-2
ii  libjpeg-dev1:2.0.5-1.1
ii  libjpeg62-turbo-dev [libjpeg-dev]  1:2.0.5-1.1
ii  libjsoncpp-dev 1.9.4-4
ii  liblz4-dev 1.9.3-1
ii  libnetcdf-cxx-legacy-dev   4.2-12
ii  libnetcdf-dev  1:4.7.4-1
ii  libpng-dev 1.6.37-3
ii  libpq-dev  13.1-1+b1
ii  libproj-dev7.2.1-1
ii  libpython3-dev 3.9.1-1
ii  libswscale-dev 7:4.3.1-5
ii  libtheora-dev  1.1.1+dfsg.1-15
ii  libtiff-dev4.2.0-1
ii  libutfcpp-dev  2.3.4-1.1
ii  libvtk99.0.1+dfsg1-5
ii  libvtk9-java   9.0.1+dfsg1-5
ii  libx11-dev 2:1.6.12-1
ii  libxft-dev 2.3.2-2
ii  libxml2-dev2.9.10+dfsg-6.3+b1
ii  libxss-dev 1:1.2.3-1
ii  libxt-dev  1:1.2.0-1
ii  mpi-default-dev1.13
ii  python3-vtk9   9.0.1+dfsg1-5
ii  tcl-dev8.6.10
ii  tk-dev 8.6.10
ii  vtk9   9.0.1+dfsg1-5
ii  x11proto-core-dev  2020.1-1
ii  x11proto-dev [x11proto-core-dev]   2020.1-1
ii  zlib1g-dev 1:1.2.11.dfsg-2

libvtk9-dev recommends no packages.

Versions of packages libvtk9-dev suggests:
pn  vtk9-doc   
pn  vtk9-examples  

-- no debconf information



Bug#731769: Still works?

2021-01-02 Thread 積丹尼 Dan Jacobson
Useful?
$ du -hs .svn/pristine/
22M .svn/pristine/
$ svn cleanup --vacuum-pristines
$ du -hs .svn/pristine/
22M .svn/pristine/



Bug#979077: On first installation, clamav-daemon fails to start

2021-01-02 Thread Toni
Package: clamav-daemon
Version: 0.102.4+dfsg-0+deb10u1
Severity: normal

Hi,

when I install clamav-daemon for the first time, the daemon fails to
start. This is intentional, as per the systemd unit file (see below),
but I think the logic is wrong:

The logic is that if there is no database file, clamav-daemon should not
run. However, on first start, there can be no database file, so as a
side effect, while eg. (in my case) clamav-freshclam is trying to fetch
a database, the service just exits and doesn't come back automatically.

In my opinion, this is highly counterintuitive. Instead, the daemon
should start and tell everyone that it can't scan anything, due to the
lack of a database, but automatically resume normal operation as soon as
clamav-freshclam has done it's job and installed a virus database,
instead of requiring (manual?) intervention to start the service.

The offending lines in

/etc/system/multi-user.target.wants/clamav-daemon.service

are:

ConditionPathExistsGlob=/var/lib/clamav/main.{c[vl]d,inc}
ConditionPathExistsGlob=/var/lib/clamav/daily.{c[vl]d,inc}


While I am at it, maybe some "restart on failure" mechanism should also
be included?



Thanks,
Toni




-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
AlertExceedsMax disabled
PreludeEnable disabled
PreludeAnalyzerName = "ClamAV"
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
ExtendedDetectionInfo = "yes"
PidFile disabled
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "30"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
DisableCache disabled
VirusEvent disabled
ExitOnOOM disabled
AllowAllMatchScan = "yes"
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
ScanPE = "yes"
ScanELF = "yes"
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
HeuristicAlerts = "yes"
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
AlertBrokenExecutables disabled
AlertEncrypted disabled
AlertEncryptedArchive disabled
AlertEncryptedDoc disabled
AlertOLE2Macros disabled
AlertPhishingSSLMismatch disabled
AlertPhishingCloak disabled
AlertPartitionIntersection disabled
ScanPDF = "yes"
ScanSWF = "yes"
ScanXMLDOCS = "yes"
ScanHWP3 = "yes"
ScanArchive = "yes"
ForceToDisk disabled
MaxScanTime = "12"
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
MaxEmbeddedPE = "10485760"
MaxHTMLNormalize = "10485760"
MaxHTMLNoTags = "2097152"
MaxScriptNormalize = "5242880"
MaxZipTypeRcg = "1048576"
MaxPartitions = "50"
MaxIconsPE = "100"
MaxRecHWP3 = "16"
PCREMatchLimit = "1"
PCRERecMatchLimit = "5000"
PCREMaxFileSize = "26214400"
OnAccessMountPath disabled
OnAccessIncludePath disabled
OnAccessExcludePath disabled
OnAccessExcludeRootUID disabled
OnAccessExcludeUID disabled
OnAccessExcludeUname disabled
OnAccessMaxFileSize = "5242880"
OnAccessDisableDDD disabled
OnAccessPrevention disabled
OnAccessExtraScanning disabled
OnAccessCurlTimeout = "5000"
OnAccessMaxThreads = "5"
OnAccessRetryAttempts disabled
OnAccessDenyOnError disabled
DevACOnly disabled
DevACDepth disabled
DevPerformance disabled
DevLiblog disabled
DisableCertCheck disabled
AlgorithmicDetection = "yes"
BlockMax disabled
PhishingAlwaysBlockSSLMismatch disabled
PhishingAlwaysBlockCloak disabled
PartitionIntersection disabled
OLE2BlockMacros disabled
ArchiveBlockEncrypted disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
LogRotate = "yes"
PidFile disabled
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
PrivateMirror disabled

Bug#979083: i3-wm: config file error. $mod+d is in the file twice

2021-01-02 Thread Brian Farnell
Package: i3-wm
Version: 4.19-1+b1
Severity: important
X-Debbugs-Cc: brianfarn...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
I installed i3 and when presented with the screen asking to generate or us ea 
default config file I chose "generate".  After that I chose Windows as my mod 
key and hit enter.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
I changed the keybinding on one of them.

   * What was the outcome of this action?
It works.

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


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

Kernel: Linux 5.10.0-1-amd64 (SMP w/1 CPU thread)
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 not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages i3-wm depends on:
ii  libc6 2.31-6
ii  libcairo2 1.16.0-5
ii  libev41:4.33-1
ii  libglib2.0-0  2.66.4-1
ii  libpango-1.0-01.46.2-3
ii  libpangocairo-1.0-0   1.46.2-3
ii  libpcre3  2:8.39-13
ii  libstartup-notification0  0.12-6+b1
ii  libxcb-cursor00.1.1-4
ii  libxcb-icccm4 0.4.1-1.1
ii  libxcb-keysyms1   0.4.0-1+b2
ii  libxcb-randr0 1.14-2.1
ii  libxcb-shape0 1.14-2.1
ii  libxcb-util1  0.4.0-1+b1
ii  libxcb-xinerama0  1.14-2.1
ii  libxcb-xkb1   1.14-2.1
ii  libxcb-xrm0   1.0-3+b1
ii  libxcb1   1.14-2.1
ii  libxkbcommon-x11-01.0.3-2
ii  libxkbcommon0 1.0.3-2
ii  libyajl2  2.1.0-3
ii  perl  5.32.0-6

Versions of packages i3-wm recommends:
ii  fonts-dejavu-core   2.37-2
ii  libanyevent-i3-perl 0.17-1
ii  libjson-xs-perl 4.030-1+b1
ii  rxvt-unicode [x-terminal-emulator]  9.22-8+b1
ii  xfonts-base 1:1.0.5

i3-wm suggests no packages.

-- no debconf information



Bug#979084: transition: hamlib

2021-01-02 Thread Christoph Berg
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi,

hamlib has finally released a new version which would be very valuable
to have in Debian/bullseye since the old version is missing support
for any hamradio transceivers sold in the last two years.

The new version has been uploaded to experimental. There are 15
reverse dependencies, all within the Debian Hamradio Team. I
recompiled these, and the only one failing is "grig" which is dead
upstream and should likely be removed anyway. Manual tests have
revealed no problems either. (There is one minor glitch in wsjtx but I
hope to address that.)

I'm sorry for this very late change but upstream has released this
only two days ago...

Ben file:

title = "hamlib";
is_affected = .depends ~ "libhamlib2" | .depends ~ "libhamlib2++c2" | .depends 
~ "libhamlib4" | .depends ~ "libhamlib++4";
is_good = .depends ~ "libhamlib4" | .depends ~ "libhamlib++4";
is_bad = .depends ~ "libhamlib2" | .depends ~ "libhamlib2++c2";

(Unsure if the ++ signs need quoting.)

Are we ok to go ahead?

Thanks,
Christoph



Bug#979080: libhtml-template-pro-perl FTCBFS: dependency issues

2021-01-02 Thread gregor herrmann
On Sat, 02 Jan 2021 11:03:23 +0100, Helmut Grohne wrote:

> libhtml-template-pro-perl cannot be cross built from source, because its
> build-depends are not cross satisfiably. Without thinking too much,
> annotating test dependencies with  goes a long way. Once done,
> the only thing left is replacing the perl dependency with perl-xs-dev
> (which is now required for building perl extensions) and then
> libhtml-test-pro-perl successfully cross builds. 

Fixed package uploaded.

> Please consider
> applying the attached patch.

BTW, your debdiffs never apply, as the packages evolve in git. E.g.
the perl-xs-dev dependency is already added, and we make also other
mass changes, and then the Debian janitor also comes along.

That's no big deal, I just look at your debdiffs and fix what
remains, but it would also be enough to just say "please add
 and perl-xs-dev" (or start from the package's git repo).
 

Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Andrew Lloyd Webber & Tim Rice: Could We Start Again Please


signature.asc
Description: Digital Signature


Bug#979074: buster-pu: package gnutls28/3.6.7-4+deb10u6

2021-01-02 Thread Adam D. Barratt
Control: tags -1 + confirmed

On Sat, 2021-01-02 at 15:17 +0100, Andreas Metzler wrote:
> The gnutls28 test tests/testpkcs11.sh uses a test certificate that
> expired in December 2020, which now causes a testsuite error and
> FTBFS.
> If this is not approved the patch will need to be included in case of
> another DSA for GnuTLS or a stable update. I would rather fix this
> now
> to make debian-security's life easier.
> 

Please go ahead.

Regards,

Adam



Bug#979029: webcamoid: SIGSEGV

2021-01-02 Thread Tomas Jura

Package: webcamoid
Version: 8.6.1+dfsg-2.1
Severity: normal

webcamoid crashes during start with SIGSEGV. A partial stack trace follows:
Thread 1 "webcamoid" received signal SIGSEGV, Segmentation fault.
0x75f1690a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x75f1690a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x7fffe148a3d8 in av_parse_video_size () from 
/usr/lib/x86_64-linux-gnu/libavutil.so.56
#2  0x7fffd55f27ed in MediaWriterFFmpegPrivate::parseOptions(AVClass 
const*) const () from 
/usr/lib/x86_64-linux-gnu/avkys/submodules/MultiSink/libffmpeg.so
#3  0x7fffd55f36cb in MediaWriterFFmpeg::codecOptions(int) () from 
/usr/lib/x86_64-linux-gnu/avkys/submodules/MultiSink/libffmpeg.so
#4  0x7fffe2f50f7f in MultiSinkElement::codecOptions(int) () from 
/usr/lib/x86_64-linux-gnu/avkys/libMultiSink.so
#5  0x7fffe2f56a3e in ?? () from 
/usr/lib/x86_64-linux-gnu/avkys/libMultiSink.so
#6  0x7fffe2f57753 in 
MultiSinkElement::qt_metacall(QMetaObject::Call, int, void**) () from 
/usr/lib/x86_64-linux-gnu/avkys/libMultiSink.so
#7  0x76b0794d in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#8  0x769f0dee in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#9  0x769f2c3a in QV4::QObjectMethod::callInternal(QV4::Value 
const*, QV4::Value const*, int) const () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#10 0x76a0e42f in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#11 0x76a10f57 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#12 0x769ac89d in QV4::Function::call(QV4::Value const*, 
QV4::Value const*, int, QV4::ExecutionContext const*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#13 0x76b23615 in 
QQmlJavaScriptExpression::evaluate(QV4::CallData*, bool*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#14 0x76b28714 in QQmlBinding::evaluate(bool*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#15 0x76b2c5b7 in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#16 0x76b2a394 in 
QQmlBinding::update(QFlags) () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#17 0x76b36a33 in 
QQmlObjectCreator::finalize(QQmlInstantiationInterrupt&) () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#18 0x76acbabc in 
QQmlComponentPrivate::complete(QQmlEnginePrivate*, 
QQmlComponentPrivate::ConstructionState*) () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#19 0x76acdd4e in QQmlComponentPrivate::completeCreate() () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#20 0x76acee40 in QQmlComponent::createObject(QQmlV4Function*) 
() from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#21 0x76acf8e3 in QQmlComponent::qt_metacall(QMetaObject::Call, 
int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Qml.so.5
#22 0x76b0794d in ?? () from 
/usr/lib/x86_64-linux-gnu/libQt5Qml.so.5

...

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

Kernel: Linux 5.10.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=cs_CZ.utf8, LC_CTYPE=cs_CZ.utf8 (charmap=UTF-8), LANGUAGE 
not set

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

Versions of packages webcamoid depends on:
ii  akqml   8.6.1+dfsg-2.1
ii  libavkys8   8.6.1+dfsg-2.1
ii  libc6   2.31-6
ii  libgcc-s1   10.2.1-3
ii  libqt5core5a    5.15.2+dfsg-2
ii  libqt5gui5  5.15.2+dfsg-2
ii  libqt5network5  5.15.2+dfsg-2
ii  libqt5qml5  5.15.2+dfsg-2
ii  libqt5quick5    5.15.2+dfsg-2
ii  libqt5widgets5  5.15.2+dfsg-2
ii  libstdc++6  10.2.1-3
ii  qml-module-qt-labs-folderlistmodel  5.15.2+dfsg-2
ii  qml-module-qt-labs-settings 5.15.2+dfsg-2
ii  qml-module-qtgraphicaleffects   5.15.2-2
ii  qml-module-qtqml-models2    5.15.2+dfsg-2
ii  qml-module-qtquick-controls 5.15.2-2
ii  qml-module-qtquick-controls2    5.15.2+dfsg-2
ii  qml-module-qtquick-dialogs  5.15.2-2
ii  qml-module-qtquick-extras   5.15.2-2
ii  qml-module-qtquick-privatewidgets   5.15.2-2
ii  qml-module-qtquick-templates2   5.15.2+dfsg-2
ii  webcamoid-data  8.6.1+dfsg-2.1
ii  webcamoid-plugins   8.6.1+dfsg-2.1

webcamoid recommends no packages.

webcamoid suggests no packages.

-- no debconf information



Bug#972312: zeitgeist-1.0.3 in debian/unstable now

2021-01-02 Thread crvi c
zeitgeist-1.0.3 is now available in debian/unstable.

https://salsa.debian.org/debian/zeitgeist/-/commits/debian/master

Just an FYI.

Thanks.


Bug#979014: wxpython4.0: FTBFS with doxygen 1.9.0 from experimental

2021-01-02 Thread Paolo Greppi

Il 02/01/21 02:51, Scott Talbert ha scritto:

On Sat, 2 Jan 2021, Paolo Greppi wrote:


The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.8.20 is 50 
MB and contains 1812 files.
The ext/wxWidgets/docs/doxygen/out/xml dir produced with doxygen 1.9.0 is 42 MB 
and contains 1583 files.
I attach the list of contained files.

This could well be a doxygen issue. Please let me know what you think about it.


Thanks for the heads up.  I think in this case it might be a bug in wxWidgets' 
Doyxfile, or at least I think I've found a simple way to fix it.  I just need 
to do a full test.

BTW, do you happen to know how to install just a single package from 
experimental when using sbuild?

Scott


According to the sbuild manpage the charm should be:

--extra-repository="deb http://deb.debian.org/debian experimental main"

but TBH I dont' use sbuild directly, I use ratt which in turn calls sbuild, and 
ratt takes as input a .changes file.

So I build doxygen locally for sid and pass this .changes file to ratt.

Here are the debs I used in case they may help you:
https://www.libpf.com/doxygen_1.9.0.tar.xz

Paolo



Bug#979044: Linphone unable to play shipped mkv ringtones

2021-01-02 Thread Andreas Messer
Package: linphone
Version: 3.12.0-3

When configuring linphone to use one of its shipped .mkv ringtones,
no sound is played and the following error message appears at the console:

linphone-message : Starting local ringtone...
linphone-error : No such filter with id 118
linphone-error : ring_start_with_cb(): could not create player for playing 
'/usr/share/sounds/linphone/rings/four_hands_together.mkv'

The problem occurs since libmediastreamer-base10 is not built with
libmatroska-c support. (special BelledonneCommunications version of
libmatroska 2) 

There is no point in packaging the .mkv files if they can not be
used. Please consider converting them to a supported format
or removal from linphone-common package. Thanks!

Cheers,
Andreas

-- 
gnuPG keyid: 8C2BAF51
fingerprint: 28EE 8438 E688 D992 3661 C753 90B3 BAAA 8C2B AF51


signature.asc
Description: PGP signature


Bug#979025: gimp: Crash while increasing depth of fractal trace filter

2021-01-02 Thread Simon McVittie
Control: reassign -1 libgegl-0.4-0 0.4.12-2

On Fri, 01 Jan 2021 at 23:19:55 -0500, tom wrote:
> I was using the filters > map > "fractal trace",
> adjusting the depth parameter, and a dialog appeared.

I can reproduce this as follows:

* Use a Debian 10 system (mine is a qemu/KVM virtual machine with GNOME)
* Run gimp
* File -> New, 1920x1080 pixels, white background
* Filters -> Map -> Fractal Trace (the version that does not say "legacy")
* Make sure Preview is checked
* Type: Mandelbrot
* X1: -1.0
* X2: 0.5
* Y1: -1.0
* Y2: 1.0
* Depth: initially 3
* Bailout length: 1.0
* Abyss policy: Loop
* Use the selection as input
* Change the Depth to be large
  - I initially used a value between 12000 and 13000, but it crashed
before I could see the exact value
  - 22 seems to be enough to trigger the crash

(For future reference, if you can provide steps with that level of detail,
that'll help maintainers to be able to reproduce bugs.)

>From the backtrace, I think this is a gegl bug. It might be
.

I cannot reproduce this crash via the same steps in the testing/unstable
version of gimp, using gegl 1:0.4.26-2, so it appears this has been
fixed at some point.

> If you want me to install dbg packages and repeat the exercise,
> let me know.

There's no need for that here because I can reproduce the bug myself,
but for future reference, it's always more useful to have a more
informative backtrace with debug symbols available. If I couldn't find
how to trigger this crash myself, I would have needed the full backtrace.

In this case the libgegl-0.4-0-dbgsym package seems like the most
important one; the libglib2.0-0-dbgsym and libc6-dbg packages would
also be useful. To get access to the -dbgsym packages, please see
.

smcv
```
GNU Image Manipulation Program version 2.10.8
git-describe: GIMP_2_10_6-294-ga967e8d2c2
C compiler:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 
8.2.0-13' --with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs 
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr 
--with-gcc-major-version-only --program-suffix=-8 
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id 
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix 
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug 
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new 
--enable-gnu-unique-object --disable-vtable-verify --enable-libmpx 
--enable-plugin --enable-default-pie --with-system-zlib 
--with-target-system-zlib --enable-objc-gc=auto --enable-multiarch 
--disable-werror --with-arch-32=i686 --with-abi=m64 
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic 
--enable-offload-targets=nvptx-none --without-cuda-driver 
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.2.0 (Debian 8.2.0-13) 

using GEGL version 0.4.12 (compiled against version 0.4.12)
using GLib version 2.58.3 (compiled against version 2.58.1)
using GdkPixbuf version 2.38.1 (compiled against version 2.38.0)
using GTK+ version 2.24.32 (compiled against version 2.24.32)
using Pango version 1.42.3 (compiled against version 1.42.3)
using Fontconfig version 2.13.1 (compiled against version 2.13.1)
using Cairo version 1.16.0 (compiled against version 1.16.0)

```
> fatal error: Segmentation fault

Stack trace:
```

# Stack traces obtained from PID 2968 - Thread 2990 #

No threads.
9]
[New LWP 2970]
[New LWP 2971]
[New LWP 2972]
[New LWP 2987]
[New LWP 2990]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__libc_read (nbytes=256, buf=0x7fff28b648d0, fd=17) at 
../sysdeps/unix/sysv/linux/read.c:26
  Id   Target Id  Frame 
* 1Thread 0x7f5e65792e00 (LWP 2968) "gimp"__libc_read (nbytes=256, 
buf=0x7fff28b648d0, fd=17) at ../sysdeps/unix/sysv/linux/read.c:26
  2Thread 0x7f5e64065700 (LWP 2969) "gmain"   0x7f5e6740f819 in 
__GI___poll (fds=0x55788c7ebdd0, nfds=2, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  3Thread 0x7f5e6350f700 (LWP 2970) "gdbus"   0x7f5e6740f819 in 
__GI___poll (fds=0x55788c809450, nfds=3, timeout=-1) at 
../sysdeps/unix/sysv/linux/poll.c:29
  4Thread 0x7f5e54975700 (LWP 2971) "async"   syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  5Thread 0x7f5e4700 (LWP 2972) "worker"  syscall () at 
../sysdeps/unix/sysv/linux/x86_64/syscall.S:38
  6Thread 0x7f5e4edb5700 

Bug#974729: mailcap 3.67: obsolete conffiles

2021-01-02 Thread Martin-Éric Racine
Hey Charles,

No, there isn't. The issue is repeatable both on my Testing host and
in an Unstable chroot.

Martin-Éric

la 2. tammik. 2021 klo 5.13 Charles Plessy (ple...@debian.org) kirjoitti:
>
> Le Fri, Jan 01, 2021 at 07:26:28PM +0200, Martin-Éric Racine a écrit :
> >
> > This part of the bug report still applies to 3.68:
> >
> > mailcap: /etc/mailcap.order
>
> Dear Martin,
>
> I just checked an upgrade on a fresh chroot, and the `/etc/mailcap.order`
> configuration file of the `mailcap` package was not marked obsolete.
>
> Is there a non-standard configuration on your system that could explain
> the difference ?
>
> Have a nice day,
>
> Charles
>
> --
> Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> Tooting from work,   https://mastodon.technology/@charles_plessy
> Tooting from home, https://framapiaf.org/@charles_plessy



Bug#978107: [Pkg-xmpp-devel] Bug#978107: gajim: Crashes when video preview is turned off in settings dialog window

2021-01-02 Thread Martin
On 2021-01-02 05:19, Bruno Kleinert wrote:
> I verified it persists in 1.3.0~beta1-1.

Too bad. Still no problem for me.
Do you have any other machine to narrow down the problem?
You might also like to ask for help in xmpp:ga...@conference.gajim.org?join



Bug#979035: RFP: libsjs-globalize -- JavaScript library for internationalization and localization

2021-01-02 Thread Martin
Package: wnpp
Severity: wishlist
X-Debbugs-Cc: pkg-javascript-de...@lists.alioth.debian.org

* Package name: libsjs-globalize
  Version : 1.6.0
  Upstream Author : OpenJS Foundation and other contributors
* URL : https://github.com/globalizejs/globalize
* License : MIT
  Programming Lang: JavaScript
  Description : JavaScript library for internationalization and localization

A JavaScript library for internationalization and localization
that leverage the official Unicode CLDR JSON data. The library
works both for the browser and as a Node.js module.



Bug#907853: liblwp-protocol-https-perl: turning off hostname verification does not work

2021-01-02 Thread Slaven Rezic

On Mon, 03 Sep 2018 06:03:51 + Slaven Rezic  wrote:
> Package: liblwp-protocol-https-perl
> Version: 6.06-2
> Severity: normal
>
> Dear Maintainer,
>
> to disable hostname verification in https requests one would set 
ssl_opts'

> verify_hostname to a false value. However, this does not work:
>
> $ perl -MLWP::UserAgent -e '$ua=LWP::UserAgent->new; 
$ua->ssl_opts(verify_hostname=>0); $res = 
$ua->get("https://www.dwd.de;); warn $res->as_string'

> 500 Can't connect to www.dwd.de:443 (certificate verify failed)
> Content-Type: text/plain
> Client-Date: Mon, 03 Sep 2018 05:58:34 GMT
> Client-Warning: Internal response
>
> Can't connect to www.dwd.de:443 (certificate verify failed)
>
> SSL connect attempt failed error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed at 
/usr/share/perl5/LWP/Protocol/http.pm line 47.

>
> With a self-compiled perl and modules installed from CPAN this works 
as expected
> (in this case there's no artificial 500 response, but a 403 Forbidden 
response).

>
> I found out that it's possible to workaround the issue with
> Debian's perl by setting SSL_verify_mode:
>
> $ perl -MIO::Socket::SSL=SSL_VERIFY_NONE -MLWP::UserAgent -e 
'$ua=LWP::UserAgent->new; $ua->ssl_opts(SSL_verify_mode => 
SSL_VERIFY_NONE, verify_hostname => 0); $res = 
$ua->get("https://www.dwd.de;); warn $res->as_string'

>
> The issue is still present on Ubuntu 18.04 which has a newer
> version of liblwp-protocol-https-perl. I also don't know if the
> problem lies in LWP, LWP::Protocol::https, IO::Socket::SSL,
> Net::SSLeay, or any other module.
>
> -- System Information:
> Debian Release: 9.5
> APT prefers stable-updates
> APT policy: (500, 'stable-updates'), (500, 'stable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.0-3-amd64 (SMP w/4 CPU cores)
> Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968), LANGUAGE=C 
(charmap=ANSI_X3.4-1968)

> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> Versions of packages liblwp-protocol-https-perl depends on:
> ii ca-certificates 20161130+nmu1+deb9u1
> ii libio-socket-ssl-perl 2.044-1
> ii libnet-http-perl 6.12-1
> ii libwww-perl 6.15-1
> ii perl 5.24.1-3+deb9u4
>
> liblwp-protocol-https-perl recommends no packages.
>
> Versions of packages liblwp-protocol-https-perl suggests:
> pn libcrypt-ssleay-perl 
>
> -- no debconf information
>
>

The problem still exists in debian/testing (libwww-perl 6.50 + 
liblwp-protocol-https-perl 6.09-1 installed here):


perl -MLWP::UserAgent -e '$ua=LWP::UserAgent->new; $ua->ssl_opts(verify_hostname=>0); $res = 
$ua->get("https://quartier-heidestrasse.contempo-webcam.de/;); warn $res->as_string'
500 Can't connect to quartier-heidestrasse.contempo-webcam.de:443 (certificate 
verify failed)
Content-Type: text/plain
Client-Date: Sat, 02 Jan 2021 09:23:22 GMT
Client-Warning: Internal response

Can't connect to quartier-heidestrasse.contempo-webcam.de:443 (certificate 
verify failed)

SSL connect attempt failed error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed at 
/usr/share/perl5/LWP/Protocol/http.pm line 50.



Bug#978984: media-types: /etc/mime.types reported as oldconfig

2021-01-02 Thread Charles Plessy
Le Sat, Jan 02, 2021 at 10:00:51AM +0200, Martin-Éric Racine a écrit :
> 
> The issue can be reproduced both on my Testing host and in an Unstable
> chroot that regularly gets updated.

Thanks for the quick answer; can you give details on the commands you ran ?

On my side:

$ sudo debootstrap stable testMimeSupportUPdate http://deb.debian.org/debian
$ sudo chroot testMimeSupportUPdate
# apt install mime-support
# dpkg-query -W -f='${Conffiles}\n'  mime-support
 /etc/mime.types 0d516753aee0a2c670c79667aad0c836
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
# nano /etc/apt/sources.list # change stable to unstable
# apt update
# apt dist-upgrade
# dpkg-query -W -f='${Conffiles}\n' | command grep 'obsolete$'
 /etc/calendar/default f499e79b0d2d685aa5ae7e1013940b96 obsolete
 /etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete
# dpkg-query -W -f='${Conffiles}\n' media-types 
 /etc/mime.types 43fa90aa9a5e009997f451be169ac530
# md5sum /etc/mime.types
43fa90aa9a5e009997f451be169ac530  /etc/mime.types
# dpkg-query -W -f='${Conffiles}\n'  mailcap
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e
# dpkg-query -W -f='${Conffiles}\n'  mime-support
 /etc/mime.types 0d516753aee0a2c670c79667aad0c836 obsolete
 /etc/mailcap.order ba07e08a7fe3741d0b8339127963190e obsolete

With this chain of events, the obsolete conffiles belong to
mime-support.

Cheers,

-- 
Charles Plessy Nagahama, Yomitan, Okinawa, Japan
Tooting from work,   https://mastodon.technology/@charles_plessy
Tooting from home, https://framapiaf.org/@charles_plessy



Bug#979036: gdb-multiarch: no riscv support?

2021-01-02 Thread BogDan Vatra
Package: gdb-multiarch
Version: 10.1-1.5
Severity: normal
X-Debbugs-Cc: bog...@kde.org

Dear Maintainer,

gdb-multiarch can't be used to connect to qemu, steps to reproduce:

$ qemu-system-riscv64 -M virt -s

$ gdb
GNU gdb (Debian 10.1-1.5) 10.1
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word".
(gdb) target remote :1234
Remote debugging using :1234
warning: Architecture rejected target-supplied description
warning: No executable has been specified and target does not support
determining executable automatically.  Try using the "file" command.
Truncated register 37 in remote 'g' packet
quit)




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

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

Versions of packages gdb-multiarch depends on:
ii  gdb 10.1-1.5
ii  libbabeltrace1  1.5.8-1+b3
ii  libc6   2.31-6
ii  libdebuginfod1  0.182-1
ii  libexpat1   2.2.10-1
ii  libgcc-s1   10.2.1-3
ii  libipt2 2.0.3-1
ii  liblzma55.2.4-1+b1
ii  libmpfr64.1.0-3
ii  libncursesw66.2+20201114-1
ii  libpython3.93.9.1-1
ii  libreadline88.1-1
ii  libsource-highlight4v5  3.1.9-3+b1
ii  libstdc++6  10.2.1-3
ii  libtinfo6   6.2+20201114-1
ii  libxxhash0  0.8.0-1
ii  zlib1g  1:1.2.11.dfsg-2

gdb-multiarch recommends no packages.

gdb-multiarch suggests no packages.

-- no debconf information



Bug#919508: ITP: warewulf -- systems management suite for Linux clusters

2021-01-02 Thread Francesco Poli
Hello Brian,
I wonder what's the status of the work in progress packaging of
warewulf.

I would be very happy to see it properly packaged and included in the
official Debian main archive.

Please let me know.
Thank you for what you have done so far and for what you are doing!


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


pgpr4zz6PL7nZ.pgp
Description: PGP signature


Bug#979043: transition: dart

2021-01-02 Thread Jochen Sprickerhof
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Dear release team,

I would like to transition the dart library. I've successfully rebuild
and tested it's only reverse build dependency: gazebo.

The automatically generated ben file looks fine.

Cheers Jochen



Bug#979046: release.debian.org: Maintain release-calendar.ics

2021-01-02 Thread Bas Couwenberg
Package: release.debian.org
Severity: normal

Key release dates for the upcoming stable release and stable point releases 
used to be maintained in release-calendar.ics [0].

It has not been updated for buster, but it would be great is that can be fixed 
for bullseye.

[0] https://release.debian.org/release-calendar.ics

Kind Regards,

Bas



Bug#970635: moosic: new upstream now supports Python 3

2021-01-02 Thread Arto Jantunen
Control: tags -1 +pending

The Wanderer  writes:

> On 2020-12-23 at 02:08, Arto Jantunen wrote:
>
>> The Wanderer  writes:
>
>>> I've decided it's worth the effort to become the new upstream for
>>> this, and confirmed with the original author that he has no
>>> objections, as he is no longer spending any time maintaining it.
>>> 
>>> Version 1.5.7, based on Python 3 rather than Python 2, is now
>>> available from:
>>> 
>>> https://github.com/inverseparadox/moosic
>>> 
>>> Please consider packaging this version, if possible in time to meet
>>> the release freeze.
>
>>> Please let me know if there's anything I can do to help move this 
>>> forward.
>> 
>> You've done the big part of the work already. I'll try to take care
>> of updating the package as soon as I can, but due to commitments
>> related to the holiday season that will probably take a week or so.
>> That should still give us barely enough time before the freeze.
>
> I am *very* glad to hear that. After sending the above, I discovered
> that the package had in fact already been removed from both testing and
> unstable; I was starting to be concerned that it might need a full RFP /
> ITP / RFS / trip-through-NEW / etc. cycle, which could be more of a
> problem and more time-consuming than I'd prefer to engage with at this
> stage.
>
> While obviously making the release freeze would be preferable, don't
> worry too much if you can't make that time-frame on your end; I'd still
> be happier with the package available in sid (or even experimental) than
> with it dropped entirely, even if it doesn't get shipped with the next
> release.
>
>> Thanks a lot for the work you did here.
>
> Thank *you* for picking this package back up, even with the upstream
> side already handled!
>
> My "if there's anything I can do to help" on this still stands, so long
> as I continue to have the time and other capacity to spare.

The package has been uploaded and is in NEW awaiting processing by the
FTP team.

-- 
Arto Jantunen



Bug#978984: media-types: /etc/mime.types reported as oldconfig

2021-01-02 Thread Martin-Éric Racine
Hey Charles,

The issue can be reproduced both on my Testing host and in an Unstable
chroot that regularly gets updated.

Martin-Éric

la 2. tammik. 2021 klo 5.17 Charles Plessy (ple...@debian.org) kirjoitti:
>
> Le Fri, Jan 01, 2021 at 07:24:28PM +0200, Martin-Éric Racine a écrit :
> >
> > /etc/mime.types is reported as oldconfig belonging to package media-types.
>
> Dear Martin,
>
> I can not reproduce that in a clean chroot.  Can you give extra details
> on your system and the tools you used to upgrade and query dpkg's
> database ?
>
> Have a nice day,
>
> Charles
>
> --
> Charles Plessy Nagahama, Yomitan, Okinawa, Japan
> Tooting from work,   https://mastodon.technology/@charles_plessy
> Tooting from home, https://framapiaf.org/@charles_plessy



Bug#979034: RM: manpages-it -- ROM; package source outdated

2021-01-02 Thread Francesco P. Lovergine
Package: ftp.debian.org
Severity: normal

On the basis of #979027 and the ongoing work to merge -it to l10n 
it is time to let this package go.

-cheers

-- 
Francesco P. Lovergine



Bug#956811: cura: UI not usable because of OpenGL renderer

2021-01-02 Thread Peter Felecan
On Sat, Dec 26, 2020 at 11:19 PM Christoph Berg  wrote:

> > I have a very annoying behavior since a long time but only recently I
> > understood the origin of the problem. By the way, it's similar to the
> > bug report #951033  "cura: UI not usable in 4.4.1" by having a garbled
> > user interface, with buttons not sown and other annoying issues.
> does the current version 4.8 still exhibit this problem?
>
> The 4.8.0 from the testing repository has the same issues and some
additional,  such as when choosing "Preview", the application dumps a core
because of a segmentation fault.

-- 
Peter Felecan


Bug#974664: raptor2: diff for NMU version 2.0.14-1.2

2021-01-02 Thread Salvatore Bonaccorso
Control: tags 974664 + patch
Control: tags 974664 + pending


Dear maintainer,

I've prepared an NMU for raptor2 (versioned as 2.0.14-1.2) and
uploaded it to DELAYED/2. Please feel free to tell me if I
should delay it longer.

Regards,
Salvatore
diff -Nru raptor2-2.0.14/debian/changelog raptor2-2.0.14/debian/changelog
--- raptor2-2.0.14/debian/changelog	2020-11-06 22:08:54.0 +0100
+++ raptor2-2.0.14/debian/changelog	2021-01-02 11:14:00.0 +0100
@@ -1,3 +1,11 @@
+raptor2 (2.0.14-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Malformed input file can lead to a segfault (CVE-2020-25713)
+(Closes: #974664)
+
+ -- Salvatore Bonaccorso   Sat, 02 Jan 2021 11:14:00 +0100
+
 raptor2 (2.0.14-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru raptor2-2.0.14/debian/patches/CVE-2020-25713-raptor2-malformed-input-file-can-lead.patch raptor2-2.0.14/debian/patches/CVE-2020-25713-raptor2-malformed-input-file-can-lead.patch
--- raptor2-2.0.14/debian/patches/CVE-2020-25713-raptor2-malformed-input-file-can-lead.patch	1970-01-01 01:00:00.0 +0100
+++ raptor2-2.0.14/debian/patches/CVE-2020-25713-raptor2-malformed-input-file-can-lead.patch	2021-01-02 11:14:00.0 +0100
@@ -0,0 +1,33 @@
+From a549457461874157c8c8e8e8a6e0eec06da4fbd0 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Caol=C3=A1n=20McNamara?= 
+Date: Tue, 24 Nov 2020 10:30:20 +
+Subject: [PATCH] CVE-2020-25713 raptor2: malformed input file can lead to a
+ segfault
+
+due to an out of bounds array access in
+raptor_xml_writer_start_element_common
+
+See:
+https://bugs.mageia.org/show_bug.cgi?id=27605
+https://www.openwall.com/lists/oss-security/2020/11/13/1
+https://gerrit.libreoffice.org/c/core/+/106249
+---
+ src/raptor_xml_writer.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/raptor_xml_writer.c b/src/raptor_xml_writer.c
+index 56993dc3..4426d38c 100644
+--- a/src/raptor_xml_writer.c
 b/src/raptor_xml_writer.c
+@@ -227,7 +227,7 @@ raptor_xml_writer_start_element_common(raptor_xml_writer* xml_writer,
+   
+   /* check it wasn't an earlier declaration too */
+   for(j = 0; j < nspace_declarations_count; j++)
+-if(nspace_declarations[j].nspace == element->attributes[j]->nspace) {
++if(nspace_declarations[j].nspace == element->attributes[i]->nspace) {
+   declare_me = 0;
+   break;
+ }
+-- 
+2.28.0
+
diff -Nru raptor2-2.0.14/debian/patches/series raptor2-2.0.14/debian/patches/series
--- raptor2-2.0.14/debian/patches/series	2020-11-06 22:08:54.0 +0100
+++ raptor2-2.0.14/debian/patches/series	2021-01-02 11:14:00.0 +0100
@@ -1 +1,2 @@
 Calcualte-max-nspace-declarations-correctly-for-XML-.patch
+CVE-2020-25713-raptor2-malformed-input-file-can-lead.patch


Bug#978589: systemd based startup not working

2021-01-02 Thread Eduard Bloch
Hallo,
* Jamie Zawinski [Wed, Dec 30 2020, 07:05:29PM]:
> > created. With absolute path, it is created but then it's created by
> > lightdm user first and then maybe the user session cannot replace it.
>
> Ok, that definitely means you're running as the wrong user, which explains 
> why .Xauthority is not readable. Though why the earlier xscreensaver log said 
> you were running as the correct user is confusing. Unless that log was from 
> before this problem began.

I don't have enough information to judge here. What I see is that the
xscreensvaer logo appears twice, i.e. when the lightdm screen comes and
when the xsession starts. When I check on the process list briefly in
those first seconds, there is:

lightdm 4881  0.2  0.0  18924  5936 ?Ss   11:44   0:00  \_ 
xscreensaver
lightdm 4959  0.0  0.0   5716  1064 ?SN   11:44   0:00  |   \_ 
xscreensaver-systemd

So not running as user. And that process is terminated soon.  And what
happened with the second appearence of the logo? This looks like an
aborted start of xscreensaver.

Is this maybe lightdm failing to stop its instance in time so
xscreensaver cannot attach the the session and silently dies?

Maybe should be a question to Debian maintainers of resp. stakeholders.

> > Ok. Is this supposed to be gone when user logs out? Does this interfere
> > with my trying different parameters (-log, --log, etc.) above, are those
> > cached and therefore ignored after subsequent changes?
>
> xscreensaver-systemd should be killed by xscreensaver when it exits, but it's 
> definitely not a part of the problem that you're experiencing right now.

Right now I cannot reproduce it, but I am almost sure that I have seen
it once. xscreensaver-systemd was haning around without associated
xscreensaver process.

> > ##
> > xscreensaver: 19:08:25: logging to "/tmp/xscreensaver-log.txt" at Wed Dec 
> > 30 19:08:25 2020
> > ##
>
> No "running as" line in this log?

I've pasted the whole file.

Best regards,
Eduard.

--
 alphascorpii: channel.d.d/fortunes.html
 Rhonda: Die Seite mag ich nicht, da bin ich so häufig drauf.



Bug#979041: libopempi3: aborts python code due to libfabric fork() issues

2021-01-02 Thread Michael Banck
Package: libopenmpi3
Version: 4.1.0-3
Severity: serious

The revert of pmix has fixed some issues, but python packages still show
autopkgtest regressions in dolfin[1], gpaw[2], gyoto[3] and mshr[4] .
The error is always like this:

|A process has executed an operation involving a call
|to the fork() system call to create a child process.
|
|As a result, the libfabric EFA provider is operating in
|a condition that could result in memory corruption or
|other system errors.
|
|For the libfabric EFA provider to work safely when fork()
|is called, you will need to set the following environment
|variable:
|  RDMAV_FORK_SAFE
|
|However, setting this environment variable can result in
|signficant performance impact to your application due to
|increased cost of memory registration.
|
|You may want to check with your application vendor to see
|if an application-level alternative (of not using fork)
|exists.
|
|Your job will now abort.

If I export RDMAV_FORK_SAFE=1, the tests run fine, but (i) it seems
something in OpenMPI has changed so that those programs no longer run
and (ii) the warnings about performance issues are to be considered.

Also note that it seems those errors only happen on amd64/i386, the ARM
ports run fine, maybe because of missing libfabric-related
features/packages?


Michael

[1] https://ci.debian.net/data/autopkgtest/testing/amd64/d/dolfin/9184050/log.gz
[2] https://ci.debian.net/data/autopkgtest/testing/amd64/g/gpaw/9302177/log.gz
[3] https://ci.debian.net/data/autopkgtest/testing/amd64/g/gyoto/9303088/log.gz
[4] https://ci.debian.net/data/autopkgtest/testing/amd64/m/mshr/9300183/log.gz



Bug#979042: node-rollup-plugin-commonjs: drop embedded copy of legacy plugin

2021-01-02 Thread Pirate Praveen

Package: node-rollup-plugin-commonjs
Version: 15.1.0+~9.3.4-2
Severity: important
Owner: Pirate Praveen 

I plan to remove the embedded copy of legacy plugin (similar to how it 
was done for node-resolve and babel plugins) for bullseye. It is mostly 
a one line patch and we have to maintain only one copy of this module.




  1   2   3   >