Bug#981165: stunnel4: CRL signature verification ignores non-first CA in multi-CA CAFile

[Vincent Pelletier]

Dear Maintainer,

Actually after more thought on the manpage, I wonder if the "multiple
certificates" mentioned actually in the manpage would actually refer
to intermediate certificates and not just multiple "final" CA
certificates.

So maybe this is a documentation "bug" (=needs clarification) and not
a code bug.

Regards,
-- 
Vincent Pelletier

Bug#981167: RM: edtsurf [i386] -- ROM; Not built on i386 but still in unstable

[Andreas Tille]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 980...@bugs.debian.org

Hi ftpmasters,

as reported in bug #980415 edtsurf is not build any more but the old
package in unstable is blocking testing migration.  So please remove
edtsurf from unstable for i386 architecture.

Thanks a lot for your work as ftpmaster
   Andreas.

Bug#979124: pandoc 2.11.4

[Yukiharu YABUKI]

FYI: New Upstream released 2.11.4

https://github.com/jgm/pandoc/releases/tag/2.11.4

--
++++++++++++++
Yukiharu Yabuki (矢吹幸治)  I use Debian GNU/Linux
mail: yab...@netfort.gr.jp
クレクレタコラは好き / クレクレタコだはイヤ
++++++++++++++

Bug#981166: apt-cacher-ng HTTPS URLs cannot be pinned

[duck]

Package: apt
Version: 2.1.18
Severity: wishlist
Control: affects -1 apt-cacher-ng

Quack,

I am using apt-cacher-ng and in order to use https I'm using the method 
recommended by its author by prepending HTTPS/// to the host, which 
gives URLs of the like:

  http://HTTPS///myrepo.example.com/debian

Previously I was using o= to match but now prefers matching with the 
origin. I realized that when using a proxy with this trick, and even if 
I encode the slashes as %2f it is not matching. In fact after looking 
into the code I found out it simply split at the first slash, and 
matches with "HTTPS" which means it de facto matches all my configured 
sources, not very practical.


I did not find any way to work around this problem. Would it be possible 
to split using the non-decoded string maybe? (and we could ask the 
apt-cacher-ng to recommend the encoded version instead) Or any other 
solution?


Regards.
\_o<

--
Marc Dequènes

Bug#981165: stunnel4: CRL signature verification ignores non-first CA in multi-CA CAFile

[Vincent Pelletier]

Package: stunnel4
Version: 3:5.50-3
Severity: normal

Dear Maintainer,

(note: I am reporting an issue which occured on a different machine, system
information below is likely irrelevant)

$ cat stunnel.conf
setuid = stunnel4
setgid = stunnel4
pid = /var/run/stunnel4/stunnel4.pid

debug = warning

[client]
client = yes
accept = ::1:8080
verifyChain = yes
CAfile = /etc/ssl/certs/local.ca.crt
CRLfile = /etc/ssl/certs/local.crl.pem
cert = /etc/ssl/private/local.crt.pem
connect = :
checkHost = example.com
$ cat /etc/ssl/certs/local.crl.pem
-BEGIN X509 CRL-

-END X509 CRL-
$ cat /etc/ssl/certs/local.ca.crt
-BEGIN CERTIFICATE-

-END CERTIFICATE-
-BEGIN CERTIFICATE-

-END CERTIFICATE-
$ openssl crl -noout -in /etc/ssl/certs/local.crl.pem -CAfile 
/etc/ssl/certs/local.ca.crt
verify failure

Extracting the second CA certificate to a separate file (openssl stops 
processing CAfile on the first certificate) and the validation passes:

$ openssl crl -noout -in /etc/ssl/certs/local.crl.pem -CAfile 
~/only_second_cacert.ca.crt
verify OK

>From /var/log/daemon.log :

stunnel: LOG4[115]: CERT: Pre-verification error: CRL signature failure
stunnel: LOG4[115]: Rejected by CERT at depth=0: CN=example.com
stunnel: LOG3[115]: error queue: 1416F086: error:1416F086:SSL 
routines:tls_process_server_certificate:certificate verify failed
stunnel: LOG3[115]: error queue: D0C5006: error:0D0C5006:asn1 encoding 
routines:ASN1_item_verify:EVP lib
stunnel: LOG3[115]: error queue: 4067072: error:04067072:rsa 
routines:rsa_ossl_public_decrypt:padding check failed
stunnel: LOG3[115]: SSL_connect: 407008A: error:0407008A:rsa 
routines:RSA_padding_check_PKCS1_type_1:invalid padding

Comenting-out CRLfile allows the client to establish the connection.

The manpage entry for CAfile clearly mentions that it supports files containing 
multiple certificates, so I believe this is a bug.

At the moment, the certificate served by : is still signed by the 
first CA, so I do not know yet if that part has the same issue.

Regards,
Vincent Pelletier

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

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

Bug#981155: ITP: ruby-backport -- Ruby library for event-driven IO

[Abraham Raji]

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

* Package name    : ruby-backport
  Version : 1.1.2
  Upstream Author : 2018 Fred Snyder for Castwide Technologies LLC* URL 
    : https://github.com/castwide/backport* License : Expat
  Programming Lang: Ruby
  Description : Ruby library for event-driven IO
A pure Ruby library for event-driven IO. This library is designed with
portability as the highest priority, which is why it's written in pure Ruby.

This package is required for solargraph the ruby language server.
I will package and maintain this gem with the help of the ruby team.

Abraham Raji
-- 
Mea navis aëricumbens anguillis abundat.

Bug#979427: src:libnet-ipaddress-perl: invalid maintainer address

[Bruno Kleinert]

On Wed, 06 Jan 2021 16:58:00 +0100 Ansgar  wrote:
> Source: libnet-ipaddress-perl
> Version: 1.10-3
> Severity: serious
> Tags: bullseye sid
> X-Debbugs-Cc: Cyril Bouthors , Cyril Bouthors 
> , 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: Wed, 06 Jan 2021 15:53:01 +
> 

Hi,

I wonder if the package is still relevant, because it has only one
reverse dependency, which in turn has no reverse dependencies:

$ apt rdepends libnet-ipaddress-perl
libnet-ipaddress-perl
Reverse Depends:
  Depends: libnet-google-safebrowsing2-perl

$ apt rdepends libnet-google-safebrowsing2-perl
libnet-google-safebrowsing2-perl
Reverse Depends:

The same for reverse build-dependencies:

$ grep-dctrl -FBuild-Depends libnet-ipaddress-perl -w -sPackage 
/var/lib/apt/lists/*Sources 
Package: libnet-google-safebrowsing2-perl
$ grep-dctrl -FBuild-Depends libnet-google-safebrowsing2-perl -w -sPackage 
/var/lib/apt/lists/*Sources 


Disregarding Holger's NMUs of both packages, their relevant changelog
entries date back to April 2013.

Maybe they are both candidates for removal?

Cheers,
Bruno


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

Bug#981164: libinput10: Thinkpad X1 2nd gen - clickpad doesn't work

[Russell Stuart]

Package: libinput10
Version: 1.16.4-3
Severity: wishlist

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Dear Maintainer,

Lenovo Thinkpad X1, 2nd gen.  Clicking the clickpad doesn't register
using metacity.  libinput shows nothing when it is clicked.  It worked
fine on buster, under X.


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

Kernel: Linux 5.10.0-1-amd64 (SMP w/12 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 libinput10 depends on:
ii  libc6 2.31-9
ii  libevdev2 1.10.1+dfsg-1
ii  libinput-bin  1.16.4-3
ii  libmtdev1 1.1.6-1
ii  libudev1  247.2-5
ii  libwacom2 1.7-1

libinput10 recommends no packages.

libinput10 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZqiOeH6lCkTWvjmorNSfiF5UUm4FAmARAzQACgkQrNSfiF5U
Um4qmhAAvg2hAbYaPy9TOZjJZKn/QoxEVSOrLUYH7OxR1tbkApxQZnR/p+7tVieb
kzGrylC8NG8yteqZhu9rwN6mZmClIAKfR9KQwVY9klxiRTggJ9J5IL3fdgm6aIO2
8gKTOhSTUjQcYJS9otVi4fYGcASSgSpgU+x97RPRAxjcYfKOfNvfGAhG1DfkCTZo
uKoJbnLFEdp3iO5q4WmZaG+RCExVERp+Waz1yYw87nD7DntPuLOVh6Ui3jdsZKky
IbvyQSpRvzQRzGvAzwNE54fVkqrDf2Veqjh/d/ooBvvRsj9T9xO/b3mjITfbknck
LtOyG30IUG0CtmNOuYWtHXxs2Xz2qXWn6rRufDwNYbwBfWZDxrBnBi7aIIzS75Hm
8ICTX/fB852nttKrGMgu28hPO6CZZfKJOsl6cqRWgpMh/0fQG16tP+teaDDkyCoo
jHqXXMKQPOqVhVfeqECLyPxRDOYWQNY4Fdc9YBidjTLMFNKi1vPZi8WZM1xx6qkZ
fiAiWo7Ktn3jJ1ACBrhKZDwuCEgisLTeq3hJILp4KDN1MsGYg73+uClt02bvvAVB
3ibVbh2abNFkoGAzEbPiJUTspUyO1+bHeP4A7ckzb+ZqvLasl3U8Qkxr6hB+It2N
AB+5qPM6WaKBCuuxQDM4o5/0UvfT63Ru+27YENQCyaDRQsmcJFs=
=yFYq
-END PGP SIGNATURE-

Bug#981114: nvidia-driver: Fails to display on any monitor change

[David Headland]

Hi Andreas,

Thanks very much for the quick reply. I've given this a try as 
requested: nvidia-tesla-450-driver and dependencies installed, then ran 
"update-glx --config nvidia" and selected /usr/lib/nvidia/tesla-450 and 
rebooted after it had recreated the initrd.


On reboot, I checked the X server log to ensure it had selected the 
correct version, and "450.102.04" was reported, so that looked good. At 
that point, I tried switching away to a new display then switching back, 
removing and re-inserting cables, and forcing a DPMS off state using 
xset, and each time the display came back without any problems, so it 
looks like the CVE fix isn't the cause of the problems.


Let me know if I can try anything else, and thanks again for your efforts.

All the best,
-Dave.

On 26/01/2021 19:26, Andreas Beckmann wrote:

Hi David,

could you try nvidia-tesla-450-driver 450.102.04-1 from sid?
It is installable along the regular driver and you can switch between
the different drivers with update-glx (and then reboot to load the other
kernel module and libraries).

This is just to check whether the 450 series got "broken" too with the
latest version (which includes a CVE fix).

Thanks

Andreas

PS: If it is still working fine, we might keep the tesla-450 driver in
bullseye along tesla-460.





OpenPGP_signature
Description: OpenPGP digital signature

Bug#981134: hwloc: reduce Build-Depends

[Helmut Grohne]

Control: clone -1 -2
Control: retitle -2 triggers invalid-arch-string-in-source-relation for valid 
gnu-any-any
Control: tags -2 - patch
Control: severity -2 important
Control: reassign -2 lintian
Control: block -1 by -2

On Tue, Jan 26, 2021 at 10:27:08PM +0100, Samuel Thibault wrote:
> Helmut Grohne, le mar. 26 janv. 2021 14:35:08 +0100, a ecrit:
> > +Build-Depends: debhelper-compat (= 12), dh-exec, libltdl-dev 
> > [!gnu-any-any],
> 
> Ah, that triggers lintian's
> 
> E: hwloc source: invalid-arch-string-in-source-relation gnu-any-any 
> [Build-Depends: libltdl-dev [!gnu-any-any]]

That's bad. Seems like you'll have to delay this part. Having lintian
complain here definitely is a bug. I do wonder why it doesn't use
libdpkg-perl to parse architecture patterns.

Helmut

Bug#981161: krb5: drop unused Build-Depends: libncurses-dev

[Helmut Grohne]

Source: krb5
Version: 1.18.3-4
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

krb5 participates in dependency loops relevant to architecture bootstrap
and already carries a stage1 profile to help here. I've looked into
generally reducing dependencies in that set anyhow and figured that it
doesn't use libncurses-dev at all. Mentions of curses are only left in
the documentation for building krb5, but it's not actually used anymore.
Please consider applying the attached patch to drop it.

Helmut
diff --minimal -Nru krb5-1.18.3/debian/changelog krb5-1.18.3/debian/changelog
--- krb5-1.18.3/debian/changelog2020-11-23 17:53:02.0 +0100
+++ krb5-1.18.3/debian/changelog2021-01-27 06:13:46.0 +0100
@@ -1,3 +1,10 @@
+krb5 (1.18.3-4.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused libncurses-dev build dependency. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 27 Jan 2021 06:13:46 +0100
+
 krb5 (1.18.3-4) unstable; urgency=medium
 
 
diff --minimal -Nru krb5-1.18.3/debian/control krb5-1.18.3/debian/control
--- krb5-1.18.3/debian/control  2020-11-23 17:53:02.0 +0100
+++ krb5-1.18.3/debian/control  2021-01-27 06:13:45.0 +0100
@@ -4,7 +4,7 @@
 Build-Depends: debhelper-compat (= 13), byacc | bison,
  comerr-dev, docbook-to-man,
  libkeyutils-dev [linux-any], libldap2-dev , libsasl2-dev ,
- libncurses5-dev, libssl-dev,  ss-dev,
+ libssl-dev,  ss-dev,
  libverto-dev (>= 0.2.4), pkg-config
 Build-Depends-Indep: python3, python3-cheetah, python3-lxml, python3-sphinx, 
doxygen, doxygen-latex
 Standards-Version: 4.5.0

Bug#981162: at-spi2-core: drop unused libxkbcommon*-dev dependencies

[Helmut Grohne]

Source: at-spi2-core
Version: 2.38.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

at-spi2-core participates in dependency loops relevant to architecture
bootstrap. Rather than look into such a difficult problem, I looked for
easily droppable dependencies and found that the libxkbcommon*-dev
dependencies seem unused. A look at NEWS confirms that it was dropped in
2.26.1. Please consider applying the attached patch to drop the unused
dependencies.

Helmut
diff --minimal -Nru at-spi2-core-2.38.0/debian/changelog 
at-spi2-core-2.38.0/debian/changelog
--- at-spi2-core-2.38.0/debian/changelog2020-09-12 23:07:32.0 
+0200
+++ at-spi2-core-2.38.0/debian/changelog2021-01-27 07:10:29.0 
+0100
@@ -1,3 +1,10 @@
+at-spi2-core (2.38.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop libxkbcommon*-dev dependencies unused since 2.26.1. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 27 Jan 2021 07:10:29 +0100
+
 at-spi2-core (2.38.0-2) unstable; urgency=medium
 
   * Upload to unstable.
diff --minimal -Nru at-spi2-core-2.38.0/debian/control 
at-spi2-core-2.38.0/debian/control
--- at-spi2-core-2.38.0/debian/control  2020-09-12 21:42:06.0 +0200
+++ at-spi2-core-2.38.0/debian/control  2021-01-27 07:10:28.0 +0100
@@ -7,8 +7,6 @@
dbus, libdbus-1-dev,
gedit ,
libglib2.0-dev,
-   libxkbcommon-x11-dev,
-   libxkbcommon-dev,
libxtst-dev,
meson (>= 0.46.0),
libgirepository1.0-dev,

Bug#981160: groff: annotate Build-Depends: poppler-utils

[Helmut Grohne]

Source: groff
Version: 1.22.4-5
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

groff participates in dependency loops relevant to architecture
bootstrap. Instead of looking into such a difficult problem, I looked
for easily droppable dependencies and found that poppler-utils is only
used for pdfimages and pdfimages is only used for testing pdfmom. As
such, it can be annotated  to become irrelevant to all this
bootstrappy stuff. Please consider applying the attached patch.

Helmut
diff --minimal -Nru groff-1.22.4/debian/changelog groff-1.22.4/debian/changelog
--- groff-1.22.4/debian/changelog   2020-05-06 10:24:11.0 +0200
+++ groff-1.22.4/debian/changelog   2021-01-27 06:34:23.0 +0100
@@ -1,3 +1,10 @@
+groff (1.22.4-5.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate Build-Depends: poppler-utils . (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 27 Jan 2021 06:34:23 +0100
+
 groff (1.22.4-5) unstable; urgency=medium
 
   [ Debian Janitor ]
diff --minimal -Nru groff-1.22.4/debian/control groff-1.22.4/debian/control
--- groff-1.22.4/debian/control 2020-05-06 10:24:11.0 +0200
+++ groff-1.22.4/debian/control 2021-01-27 06:34:22.0 +0100
@@ -3,7 +3,7 @@
 Priority: important
 Maintainer: Colin Watson 
 Standards-Version: 3.9.8
-Build-Depends: bison (>= 1:1.875b), debhelper-compat (= 12), dh-exec, dpkg-dev 
(>= 1.17.0~), ghostscript, netpbm, psutils, x11proto-core-dev, libx11-dev, 
libxmu-dev, libxt-dev, libxaw7-dev, texinfo (>= 4.8), pkg-config, 
libuchardet-dev, gsfonts, poppler-utils
+Build-Depends: bison (>= 1:1.875b), debhelper-compat (= 12), dh-exec, dpkg-dev 
(>= 1.17.0~), ghostscript, netpbm, psutils, x11proto-core-dev, libx11-dev, 
libxmu-dev, libxt-dev, libxaw7-dev, texinfo (>= 4.8), pkg-config, 
libuchardet-dev, gsfonts, poppler-utils 
 Homepage: https://www.gnu.org/software/groff/
 Vcs-Git: https://salsa.debian.org/debian/groff.git
 Vcs-Browser: https://salsa.debian.org/debian/groff

Bug#981159: extra-cmake-modules: drop unused qt Build-Depends

[Helmut Grohne]

Source: extra-cmake-modules
Version: 5.78.0-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

extra-cmake-modules participates in dependency loops relevant to
architecture bootstrap. Instead of looking into such a difficult
problem, I looked for easily droppable dependencies and found that its
qt dependencies are unused - presumably since its test suite is
disabled. Please consider applying the attached patch to drop the
relevant dependencies. Alternatively, consider enabling the tests.

Helmut
diff --minimal -Nru extra-cmake-modules-5.78.0/debian/changelog 
extra-cmake-modules-5.78.0/debian/changelog
--- extra-cmake-modules-5.78.0/debian/changelog 2021-01-22 14:43:12.0 
+0100
+++ extra-cmake-modules-5.78.0/debian/changelog 2021-01-27 06:54:03.0 
+0100
@@ -1,3 +1,10 @@
+extra-cmake-modules (5.78.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused qt build dependencies. (Closes: #-1)
+
+ -- Helmut Grohne   Wed, 27 Jan 2021 06:54:03 +0100
+
 extra-cmake-modules (5.78.0-3) unstable; urgency=medium
 
   * Cherry-pick upstream fix for tar invocation in app templates.
diff --minimal -Nru extra-cmake-modules-5.78.0/debian/control 
extra-cmake-modules-5.78.0/debian/control
--- extra-cmake-modules-5.78.0/debian/control   2021-01-11 14:56:40.0 
+0100
+++ extra-cmake-modules-5.78.0/debian/control   2021-01-27 06:54:03.0 
+0100
@@ -14,9 +14,6 @@
python3-sphinx ,
python3-sphinxcontrib.qthelp ,
python3-sphinxcontrib.serializinghtml ,
-   qtdeclarative5-dev,
-   qttools5-dev (>= 5.4),
-   qttools5-dev-tools (>= 5.4),
 Build-Depends-Indep: dh-sequence-sphinxdoc
 Standards-Version: 4.5.1
 Rules-Requires-Root: no

Bug#981158: mp3splt FTCBFS: abuses AC_CHECK_FILE

[Helmut Grohne]

Source: mp3splt
Version: 2.6.2+20170630-3.1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

mp3splt fails to cross build from source, because it uses AC_CHECK_FILE
to check whether cutter (a testing tool) is present. While it wants to
use cutter during unit tests, the AC_CHECK_FILE attempts to check for it
on the host and when no check result is seed, it simply fails. This is a
case where a simple "test -e" is better. Please consider applying the
attached patch. When doing so, keep in mind that you must regenerate the
relevant configure scripts as this is not being done at build time.

Helmut
--- mp3splt-2.6.2+20170630.orig/libmp3splt/configure.ac
+++ mp3splt-2.6.2+20170630/libmp3splt/configure.ac
@@ -252,7 +252,7 @@
 AC_CHECK_CUTTER
 
 cutter_command="no"
-AC_CHECK_FILE([$CUTTER], [cutter_command="yes"])
+AS_IF([test -e "$CUTTER"], [cutter_command="yes"])
 
 if test "x$CUTTER" != x;then
   if test "x$cutter_command" = xyes;then
--- mp3splt-2.6.2+20170630.orig/mp3splt-gtk/configure.ac
+++ mp3splt-2.6.2+20170630/mp3splt-gtk/configure.ac
@@ -312,7 +312,7 @@
 AC_CHECK_CUTTER
 
 cutter_command="no"
-AC_CHECK_FILE([$CUTTER], [cutter_command="yes"])
+AS_IF([test -e "$CUTTER"], [cutter_command="yes"])
 
 if test "x$CUTTER" != x;then
   if test "x$cutter_command" = xyes;then

Bug#981127: cockpit: FTBFS on hppa - test timeout is way too small

[Martin Pitt]

Control: forwarded -1 https://github.com/cockpit-project/cockpit/pull/15223
Control: tag -1 upstream pending

Hello John,

Ugh, is HPPA know to have such a poor threading performance in general?
Thanks for doing the manual build!

> We either need to skip the test-tls-certfile on hppa or greatly extend the
> timeout.

Let's do the former then. That test isn't that important, it mostly checks that
our threading logic does not have race conditions. But that should not be very
architecture specific.

I sent an upstream PR to do that, it'll be in 237.

Thanks!

Martin

Bug#981157: dkimpy-milter: get_identities_sign() does not reset the i= signature identity

[Michel Lespinasse]

Package: dkimpy-milter
Version: 1.2.1-1~bpo10+1
Severity: normal

This is a tiny thing I noticed while checking the dkimpy-milter code
for another issue I was looking at:

dkimMilter.get_identities_sign() initially sets iequals = None;
from context it seems that it should set self.iequals = None instead.

I have no idea if there are any consequences to that, but I also noticed
that envfrom() does not reset self.iequals, so there is at least a risk
that the value could be incorrectly propagated from one email to the next
if they are received on the same connection.

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

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

Versions of packages dkimpy-milter depends on:
ii  adduser3.118
ii  python33.7.3-1
ii  python3-authres1.1.1-1
ii  python3-dkim   1.0.3-1~bpo10+1
ii  python3-dns3.2.0-2
ii  python3-dnspython  1.16.0-1
ii  python3-milter 1.0.3-3
ii  python3-nacl   1.3.0-2
ii  python3-pkg-resources  40.8.0-1

dkimpy-milter recommends no packages.

Versions of packages dkimpy-milter suggests:
ii  lsb-base  10.2019051400
ii  postfix   3.4.14-0+deb10u1

-- no debconf information

Bug#981156: dkimpy-milter: issues in sign-vs-verify logic (and documentation)

[Michel Lespinasse]

Package: dkimpy-milter
Version: 1.2.1-1~bpo10+1
Severity: normal


I have been encountering issues trying to configure the sign-vs-verify
logic in dkimpy-milter. Some of it comes down to confusing documentation,
but it also appears that the behavior I want can not be configured.

I would like the sign-vs-verify logic to behave similarly to the
smtpd_relay_restrictions rules in my postfix configuration:
- any email coming from local networks (local sendmail, localhost smtpd,
or 10.0.0.0/8 smtpd) should be signed,
- any email coming from other sources should be verified.


Reading the documentation, it seems that setting InternalHosts should work,
but this doesn't seem to be the case:

In dkimMilter.connect(),
- self.internal_connection is set if the connection comes from an address 
matching InternalHosts, or if the milter macros match MacroList.
- self.external_connection is set if the milter macros match MacroListVerify

In dkimMilter.eom():
- self.external_connection disables signing
- self.internal_connection disables verifying

Therefore, MacroListVerify ends up controllinjg signing (despite what
the name implies!), and MacroList ends up controlling verifying
(despite what the documentation says about it). Additionally, for a
smtpd milter receiving mail from both internal and external
connections, it is not possible to control signing based on the
InternalHosts value.


My wishes for resolving this bug are:
1- There should be a way to control signing based on the originating
connection's IP address;
2- It would be nice for the documentation to explain how the
MacroList, MacroListVerify and InternalHosts values interact to
determine wether we are dealing with an internal/trusted or
external/untrusted connection (right now the values are only described
separately and the interactions are not documented in any way);
3- I am not sure if there are any reasons for connections to be marked as
both internal and external at once, or to have neither markings - if there
are valid reasons for that, the documentation should explain them; if not
maybe the milter should emit a warning when incorrectly configured...
4- The interaction between Mode and internal vs external connections
should be documented (i.e. that Mode=s still only signs internal
connections, and Mode=v still only verifies external connections).


Sorry for the long winded report, hope it is at least clear enough :)

Thanks,


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

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

Versions of packages dkimpy-milter depends on:
ii  adduser3.118
ii  python33.7.3-1
ii  python3-authres1.1.1-1
ii  python3-dkim   1.0.3-1~bpo10+1
ii  python3-dns3.2.0-2
ii  python3-dnspython  1.16.0-1
ii  python3-milter 1.0.3-3
ii  python3-nacl   1.3.0-2
ii  python3-pkg-resources  40.8.0-1

dkimpy-milter recommends no packages.

Versions of packages dkimpy-milter suggests:
ii  lsb-base  10.2019051400
ii  postfix   3.4.14-0+deb10u1

-- no debconf information

Bug#980980: linux-image-5.10.0-2-arm64-unsigned: flood of false udev messages make udisks2 eat CPU usage on usb-booted raspi4

[Ryutaroh Matsumoto]

Control: forwarded -1 
http://lists.infradead.org/pipermail/linux-rpi-kernel/2021-January/007985.html

Forwarded to the linux-rpi-kernel list. Ryutaroh

Bug#940704: [Pkg-javascript-devel] Bug#940704: next error

[Xavier]

Le 27/01/2021 à 00:14, Paolo Greppi a écrit :
> I fixed the error:
> 
>     Cannot find module 'babel-preset-env'
> 
> but I am not sure if the fix is 100% right.
> 
> Now I get:
> 
>     TypeError: Cannot read property 'mkdir' of undefined
>    5 | export default function(filename?: string):
> Promise {
>    6 |   return new Promise((resolve, reject) => {
>     >  7 | temp.mkdir(filename, function(err, path) {
> 
> I added node-temp in debian/tests/control Depends afetr jest, but that
> did not help (it would have errored on require('temp') anyway).
> 
> I have then turned my attention at brushing up node-temp, see this
> message to the js-team list:
> https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052152.html

Hi,

fixed (patch for node-mkdirp ≥ 1), take a look at my changes

Bug#981052: xen: XSA-360: IRQ vector leak on x86

[Salvatore Bonaccorso]

Control: retitle -1 xen: CVE-2021-3308: XSA-360: IRQ vector leak on x86

On Mon, Jan 25, 2021 at 08:08:02PM +0100, Salvatore Bonaccorso wrote:
> Source: xen
> Version: 4.14.0+88-g1d1d1f5391-2
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team 
> 
> 
> Hi
> 
> For details see https://xenbits.xen.org/xsa/advisory-360.html . 
> 
> It does not affect version in buster afaict.

This now has assigned CVE-2021-3308.

Regards,
Salvatore

Bug#981070: e2fsprogs: (Possibly) e2fsck sometimes enables ext4 features on ext2 filesystems?

[Theodore Ts'o]

On Wed, Jan 27, 2021 at 01:10:33AM +0100, Christoph Biedl wrote:
> 
> Yes, and my question here: Is it possible the existence of that bogus
> fscrypt feature flag made e2fsck or the kernel think this is an ext4,
> and things went downhill from there? That's a situation I'd like to
> avoid - since in the (today rare) case the bootloader cannot handle
> ext4, this will result in an unbootable system.

So, it had nothing to do with the fscrypt flag; the kernel message was
because that an inode flag was set on an inode, *not* a feature flag
in the superblock.

Looking at the tune2fs -l output, the issue was the inline_data file
system feature flag:

> Filesystem features:  ext_attr resize_inode dir_index filetype 
> inline_data sparse_super

That *is* a feature which e2fsck will offer to set, but only if there
is a valid inode which (a) has the inline data flag in the inode, (b)
there is a "system.data" extended attribute which has a non-zero size.
In that case, if the inode has valid inline data, e2fsck will assume
that what had happened feature flag was erroneously cleared, and will
ask permission to set it back:

Pass 1: Checking inodes, blocks, and sizes
Inode 12 has inline data, but superblock is missing INLINE_DATA feature
Fix? yes

If there is an inode that has the INLINE_DATA_FL inode flag set, but
there is not a valid system.data extended attribute, then e2fsck will
assume that it's random garbage written into the inode table that
happened to have the INLINE_DATA_FL bit set in the i_flags field set,
then e2fsck will ask permission to clear the inode and then get rid of
the file:

Pass 1: Checking inodes, blocks, and sizes
Inode 12 has INLINE_DATA_FL flag on filesystem without inline data support.
Clear? yes
Pass 2: Checking directory structure
Entry 'foo' in / (2) has deleted/unused inode 12.  Clear? yes


What could have happened on your file system?  Well, there are two
scenarios that could explain what had happened:

1) Somehow the inode was corrupted to (a) both set the inline data
flag, and (b) a valid extended attribute that had "system.data" (which
can't be set via the userspace API; it would have had to been
magically, random set).   Highly unlikely.

2) There was a random bit flip that enabled the inline_data feature
flag in the superblock.  The other fscrypt kernel message would
be explained another random bit flip and/or random garbage written
into an inode table block.

3) An admin accidentally ran "tune2fs -O inline_data /dev/sdXX" to
enable the inline_data feature.  The fscrypt message could be
explained as above.

In any case, e2fsck is doing the right thing.  It *is* possible for
e2fsck to set the inline_data feature flag, yes. but it's under
very tightly constrained circumstances, and the alternative would be
to have e2fsck to delete user data that could potentially be quite
valuable.  (For example, a cryptographic key which protects a bitcoin
wallet with $220 million dollars worth of bitcoin in it.  :-P )

Could this happen when it shouldn't?  Well, it would highly unlikely
--- as in one in bazillions odds unlucky.  It's actually much more
likely that a random bitflip in the in-memory superblock toggled the
inline_data feature bit set.

- Ted

Bug#978973: RFP: gnome-activity-journal -- Activity Journal for the GNOME desktop environment ( Powered by Zeitgeist 1.0.3 )

[crvi c]

Hi Sudip,

I'll be tagging the package this weekend. If you've any queries, please let
me know.

Thanks,

On Sun, 10 Jan 2021 at 00:28, crvi c  wrote:

> Sounds good.
>
>
> On Fri, 8 Jan 2021 at 17:19, Sudip Mukherjee 
> wrote:
>
>> On Thu, Jan 7, 2021 at 10:29 AM crvi c  wrote:
>> >
>> > Hi Sudip,
>> >
>> > I've a couple of pending changes. I'll tag the version shortly.
>>
>> Thanks. I will start with packaging and upload. It needs to cross the
>> NEW queue which takes time. I can update the package after you have
>> done your changes.
>>
>>
>> --
>> Regards
>> Sudip
>>
>

Bug#981113: ITP: root -- open-source data analysis framework

[Benda Xu]

Steffen Möller  writes:

> cern-root ?

+1


FYI, the following is the previous CERN ROOT changelog.  The old name
was root and changed to root-system since 5.15.07-1.

  
http://metadata.ftp-master.debian.org/changelogs/main/r/root-system/unstable_changelog

Benda

Bug#981143: RFS: opensysusers/0.6-2 [QA] -- processes sysusers.d directory to create system users

[Lorenzo Puliti]

Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: plore...@disroot.org

Dear mentors,

I am looking for a sponsor for my package "opensysusers":

 * Package name: opensysusers
   Version : 0.6-2
   Upstream Author : Chris Cromer 
 * URL : https://github.com/artix-linux/opensysusers
 * License : LGPL-2.1+, BSD-2-clause
 * Vcs : https://salsa.debian.org/debian/opensysusers
   Section : net

It builds those binary packages:

  opensysusers - processes sysusers.d directory to create system users

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/o/opensysusers/opensysusers_0.6-2.dsc

Git repo:

  https://salsa.debian.org/Lorenzo.ru.g-guest/opensysusers/-/tree/release-0.6-2

Changes since the last upload:

 opensysusers (0.6-2) unstable; urgency=medium
 .
   * QA upload.
   * Rename and ship opensysusers manpages:
  changing name is necessary to avoid a conflict
  with systemd manpages

Regards,
-- 
  Lorenzo Puliti

Bug#981154: RM: godot [mips64el] -- RoQA; no longer builds on mips64el

[Adrian Bunk]

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

godot no longer builds on mips64el, see #978567.

Bug#981055: Fwd: Re: Heads up: Bug#981055: O: john -- active password cracking tool [origin: hert...@debian.org]

[Axel Beckert]

Control: retitle -1 ITA: john -- active password cracking tool
Control: owner -1 Debian Security Tools 

Hi,

with Julián (previous co-maintainer of john who wants to continue to
work on it, CC'ed) already being in pkg-security-team on Salsa and me
being invited to join (see below), we'll solve this WNPP issue by
moving john under the Debian Security Tools Packaging Team umbrella.

I think this is a good solution for all interested parties as well as
Debian's and Kali's john users. :-)

- Forwarded message from Raphael Hertzog  -
Date: Tue, 26 Jan 2021 09:34:54 +0100
From: Raphael Hertzog 
To: Axel Beckert 
Cc: Debian Security Tools 
Subject: Re: Heads up: Bug#981055: O: john -- active password cracking tool

Hello Axel,

On Tue, 26 Jan 2021, Axel Beckert wrote:
> just a heads up since I know that the Kali people maintain their own,
> much more featureful john package and I wonder if we can get that into
> Debian now:
> 
> john has been orphaned by the MIA team just today:
> https://bugs.debian.org/981055

Thanks for the notification. I believe it's a good idea, yes. We'll take
care of it.

> I'm thinking about doing a QA upload to at least fix that RC bug, but
> I do not intent to take over the package maintenance as I'm sure some
> of you can do that much better than I can do and the Kali people
> already have john 1.9.0 packaged.

I would not mind if you joined pkg-security :-)

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

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

Bug#640288: marked as done (/usr/share/john/cronjob: line 28: cd: /var/lib/john: No such file or directory)

[Axel Beckert]

Control: reopen -1
Control: found -1 1.8.0-3

Hi Jakub,

Debian Bug Tracking System wrote:
> $ dpkg -r john
> (Reading database ... 11903 files and directories currently installed.)
> Removing john ...
> /usr/share/john/cronjob: line 28: cd: /var/lib/john: No such file or directory
[…]
>* Unconditionally and always call "mkdir -p $PIDDIR" in cron job. It's
>  idempotent anyways. (Closes: #502878, #640288)

I accidentially closed this bug with the recent upload despite it
wasn't really fixed.

There were two very similar, but not identical bug reports (#502878
and #640288), one for /var/lib/john/ and one for /var/run/john/. I
just fixed the /var/run/john/ one.

What didn't really help was that the variable RUNDIR contains
/var/lib/john and not /var/run/john (which is stored in $PIDDIR).

Will fix that very soon in git and latest in a few days with the next
upload.

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


signature.asc
Description: PGP signature

Bug#981153: cargo: Please package new upstream

[Mike Hommey]

Source: cargo
Version: 0.47.0-3
Severity: wishlist

Firefox now requires version 0.48, latest upstream is 0.50, and unstable
is on 0.47.

Mike

Bug#975075: tech-ctte: non-systemd dependencies in non-NM packages

[Sandro Tosi]

> Here, the situation here is more complicated. There was a private
> communication with the committee, but such side conversations are
> unfair: How can Matthew ever feel that justice was served? I would
> personally not feel closure unless I saw all such communications and
> had an opportunity to respond.
>
> Secrecy, if it is really needed, should instead be implemented by
> requiring all parties involved to keep sealed records confidential.
>
> I urge the committee to please reconsider its willingness to engage
> with one party without the other present. The dignity of the Technical
> Committee—Debian's highest and most hallowed body—could suffer.

the ability to talk privately with the committee is something CTTE has
allowed for a long time; it's a two-sided coin: it can prevent heated
exchanges, but it can also leave a sour taste in the petitioner's
mouth.

While i would tend to agree that it's slightly unfair, i've never been
on the other side to judge it fully.

Regards,
-- 
Sandro "morph" Tosi
My website: http://sandrotosi.me/
Me at Debian: http://wiki.debian.org/SandroTosi
Twitter: https://twitter.com/sandrotosi

Bug#981152: ncmpc: Assertion failed: i < filelist->size() during "Browse" while another client is repeatedly clearing the playlist queue

[Daniel Kahn Gillmor]

Package: ncmpc
Version: 0.42-1
Severity: important

running ncmpc to connect to an mpd server, i get a crash with a
warning about "Assertion failed:

ncmpc: ../src/FileListPage.cxx:492: virtual void 
FileListPage::PaintListItem(WINDOW*, unsigned int, unsigned int, unsigned int, 
bool) const: Assertion `i < filelist->size()' failed.
 Aborted

I get this warning by going into the "Browse" view (hitting '3') and
then navigating to any of the listed folders by hitting enter.  It
seems to do this when viewing any of the subfolders i investigate
using "Browse".

Below is a backtrace from such an assertion:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77ae8537 in __GI_abort () at abort.c:79
#2  0x77ae840f in __assert_fail_base (fmt=0x77c51128 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=0x55593307 "i < 
filelist->size()", file=0x5559320b "../src/FileListPage.cxx", line=492, 
function=) at assert.c:92
#3  0x77af7662 in __GI___assert_fail 
(assertion=assertion@entry=0x55593307 "i < filelist->size()", 
file=file@entry=0x5559320b "../src/FileListPage.cxx", line=line@entry=492, 
function=function@entry=0x55593420 "virtual void 
FileListPage::PaintListItem(WINDOW*, unsigned int, unsigned int, unsigned int, 
bool) const") at assert.c:101
#4  0x55573070 in FileListPage::PaintListItem (this=, 
w=, i=, y=1, width=, 
selected=) at ../src/FileListPage.cxx:492
#5  0x5557497d in ListWindow::Paint (this=0x55608798, renderer=...) 
at ../src/ListWindow.cxx:56
#6  0x5556eaa7 in ScreenManager::Paint (this=0x7fffe0a8, 
main_dirty=) at ../src/screen_paint.cxx:51
#7  0x5556dd18 in ScreenManager::Update (this=, c=..., 
seek=...) at ../src/screen.cxx:226
#8  0x5556496e in mpdclient_idle_callback (events=) at 
../src/Main.cxx:193
#9  0x555676c8 in mpdclient::OnIdle (this=0x7fffdeb0, 
_events=) at ../src/mpdclient.cxx:72
#10 0x55565c8c in mpdclient::GetConnection 
(this=this@entry=0x7fffdeb0) at ../src/mpdclient.cxx:471
#11 0x55573321 in screen_file_load_list (filelist=..., 
current_path=0x556087f8 "cd-tracks", c=0x7fffdeb0) at 
../src/FileBrowserPage.cxx:92
#12 FileBrowserPage::Reload (this=this@entry=0x55608780, c=...) at 
../src/FileBrowserPage.cxx:111
#13 0x55573465 in FileBrowserPage::ChangeDirectory 
(this=this@entry=0x55608780, c=..., new_path=...) at 
../src/FileBrowserPage.cxx:123
#14 0x555736fd in FileBrowserPage::ChangeToEntry (this=0x55608780, 
c=..., entry=...) at ../src/FileBrowserPage.cxx:163
#15 0x55573c25 in FileBrowserPage::HandleEnter (this=0x55608780, 
c=...) at ../src/FileBrowserPage.cxx:196
#16 0x55572c11 in FileListPage::OnCommand (cmd=Command::PLAY, c=..., 
this=0x55608780) at ../src/FileListPage.cxx:431
#17 FileListPage::OnCommand (this=this@entry=0x55608780, c=..., 
cmd=cmd@entry=Command::PLAY) at ../src/FileListPage.cxx:372
#18 0x55573cdd in FileBrowserPage::OnCommand (this=0x55608780, 
c=..., cmd=Command::PLAY) at ../src/FileBrowserPage.cxx:350
#19 0x5556e338 in ScreenManager::OnCommand (this=0x7fffe0a8, c=..., 
seek=..., cmd=cmd@entry=Command::PLAY) at ../src/screen.cxx:232
#20 0x55564558 in do_input_event (event_loop=..., 
cmd=cmd@entry=Command::PLAY) at ../src/Main.cxx:231
#21 0x5556b89a in AsyncUserInput::OnSocketReady (this=0x7fffe360) 
at ../src/event/SocketEvent.hxx:94
#22 0x5558dc79 in EventLoop::Run (this=this@entry=0x7fffde50) at 
../src/event/Loop.cxx:332
#23 0x55564a54 in Instance::Run (this=this@entry=0x7fffde50) at 
../src/Instance.cxx:100
#24 0x5556385c in main (argc=-8624, argv=0x7fffe4b8) at 
../src/Main.cxx:351

One thing to note: i only see this behavior when the same mpd server
has another client connected to it that is misbehaving.  In
particular, the misbehaving client is constantly clearing the queue
(imagine another ncmpc client attached to a machine where the keyboard
is erroneously sending the "c" keypress).

So this might be some sort of TOCTOU failure associated with testing
membership in the current queue when displaying a list of folders
during browsing?  Feel free to forward the report upstream if you
think it's not a debian-specific issue.  I can reproduce the error
(though not as reliably) on a debian buster system as well, as long as
the same misbehaving mpd client is connected to the same server.

Thanks for maintaining ncmpc in debian!

--dkg


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

Kernel: Linux 5.10.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, 

Bug#981055: O: john -- active password cracking tool

[Axel Beckert]

Hi again,

Axel Beckert wrote:
> Julián Moreno Patiño wrote:
> > I will continue maintaining john the ripper package, but please go
> > ahead with the QA Upload.
[…]
> The Debian Security Tools Packaging Team (Cc'ed) also showed interest
> in the package. So I recommend to continue packaging it under their
> umbrella:

I just noticed that you already joined that team three years ago.

So I will go ahead and move the debian/john git repo on Salsa to the
pkg-security-team group and update it to their standards.

I'll also re-add you as Uploader. :-)

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

Bug#981151: RFS: xbanish/1.7-1 [ITP] -- banish the mouse cursor when typing, show it again when the mouse moves

[Scupake]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "xbanish":

 * Package name: xbanish
   Version : 1.7-1
   Upstream Author : joshua stein 
 * URL : https://github.com/jcs/xbanish
 * License : BSD-3-Clause
 * Vcs : https://codeberg.org/Scupake/xbanish-deb
   Section : x11

It builds those binary packages:

  xbanish - banish the mouse cursor when typing, show it again when the mouse 
moves

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/x/xbanish/xbanish_1.7-1.dsc

Changes for the initial release:

 xbanish (1.7-1) unstable; urgency=low
 .
   * Initial release (Closes: #981140)

Regards,
-- 
  Scupake


signature.asc
Description: PGP signature

Bug#950761: RFS: ipmitool/1.8.18-11 [RC] -- utility for IPMI control with kernel driver or LAN interface (daemon)

[Thomas Goirand]

Hi Jorg,

Do you need sponsoring for the upload of the last upstream version in
unstable? Can we see this moving forward?

Cheers,

Thomas Goirand (zigo)

Bug#981150: gpick: Please consider using a newer lua (lua5.2 -> 5.3 or 5.4)

[Boyuan Yang]

Source: gpick
Version: 0.2.6~rc1-5
Severity: minor

Dear Debian gpick package maintainer,

It seems that package gpick is still using lua5.2. According to
https://www.lua.org/versions.html , the last version of lua5.2 is
released in 2015 and there will be no further releases. Please consider
switching to a newer lua implementation.

According to
https://github.com/thezbyg/gpick/blob/master/CMakeLists.txt , package
gpick support either lua5.3 or lua5.4. Both of them are available in
Debian.

-- 
Thanks,
Boyuan Yang


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

Bug#978459: plasma-base: diff for NMU version 5.20.0+nmu1

[Boyuan Yang]

Control: tags -1 -pending -patch

Hi,

在 2021-01-27星期三的 08:28 +0900，Norbert Preining写道：
> On Tue, 26 Jan 2021, Boyuan Yang wrote:
> > I've prepared an NMU for plasma-base (versioned as 5.20.0+nmu1) and
> > uploaded it to DELAYED/7. Please feel free to tell me if I
> 
> No, please stop that.
> 
> I will request removal of this package.
> 
> It should NOT transition to testing, as I have already stated.
> 
> Thanks

Thanks for the info. I have already removed it from the DELAYED queue.

Regards,
Boyuan Yang

Bug#966566: backup-manager: FTPS purges and uploads fail

[Pierre-Elliott Bécue]

Le jeudi 30 juillet 2020 à 21:11:38+0200, Bachsau a écrit :
> Package: backup-manager
> Version: 0.7.14-1+deb10u1
> Severity: important
> Tags: patch
> 
> Dear Maintainer,
> 
> backup-manager-upload fails to gather a list of files from the FTP server in 
> order to purge them. The error message from Perl is "Not an ARRAY reference". 
> It also fails to find the archives for uploading because it uses `basename` 
> on the full path without changing its working directory before.
> 
> Both of these errors are caused by serious mistakes in the code, which 
> doesn't seem to have been tested thoroughly after backup-manager was updated 
> to use a new library for uploads.

Dear Maxi,

Due to the bug being a bit old, of important severity, and the upcoming
freeze, I made a patch from Bachsau's work and made a NMU upload to
DELAYED/5.

I also updated the git repository on salsa accordingly, and I attach the
NMU patchset here.

Should you have any issue with this NMU, please do feel free to tell me
to cancel it and I'll do.

If you need some help to maintain backup-manager, don't hesitate to
tell, I'm eager to do a more important release to get lintian happy and
fit the latest release of the Policy.

With best regards,

-- 
Pierre-Elliott Bécue
GPG: 9AE0 4D98 6400 E3B6 7528  F493 0D44 2664 1949 74E2
It's far easier to fight for one's principles than to live up to them.
From 0c7a470e88d879ee0fd664284925f21c2452db76 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Pierre-Elliott=20B=C3=A9cue?= 
Date: Wed, 27 Jan 2021 01:08:03 +0100
Subject: [PATCH] Add new patch:
 0007-Fixes-two-coding-bugs-in-backup-manager-upload

Thanks to Bachsau for reporting (Closes: #966566)
---
 debian/changelog  |  8 
 ...coding-bugs-in-backup-manager-upload.patch | 44 +++
 debian/patches/series |  1 +
 3 files changed, 53 insertions(+)
 create mode 100644 debian/patches/0007-Fixes-two-coding-bugs-in-backup-manager-upload.patch

diff --git a/debian/changelog b/debian/changelog
index 770207d..73a7b72 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+backup-manager (0.7.14-1.2) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Add new patch: 0007-Fixes-two-coding-bugs-in-backup-manager-upload
+Thanks to Bachsau for reporting (Closes: #966566)
+
+ -- Pierre-Elliott Bécue   Wed, 27 Jan 2021 01:07:50 +0100
+
 backup-manager (0.7.14-1.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff --git a/debian/patches/0007-Fixes-two-coding-bugs-in-backup-manager-upload.patch b/debian/patches/0007-Fixes-two-coding-bugs-in-backup-manager-upload.patch
new file mode 100644
index 000..006a70d
--- /dev/null
+++ b/debian/patches/0007-Fixes-two-coding-bugs-in-backup-manager-upload.patch
@@ -0,0 +1,44 @@
+From: Bachsau 
+Date: Wed, 27 Jan 2021 01:05:07 +0100
+Subject: Fixes two coding bugs in backup-manager-upload
+
+backup-manager-upload fails to gather a list of files from the FTP
+server in order to purge them. The error message from Perl is "Not an
+ARRAY reference". It also fails to find the archives for uploading
+because it uses `basename` on the full path without changing its working
+directory before.
+
+This patch fixes these two bugs
+---
+ backup-manager-upload | 11 ++-
+ 1 file changed, 2 insertions(+), 9 deletions(-)
+
+diff --git a/backup-manager-upload b/backup-manager-upload
+index d159eae..1366f60 100755
+--- a/backup-manager-upload
 b/backup-manager-upload
+@@ -526,13 +526,7 @@ sub ftp_clean_directory($)
+ # First, create the list of existing archives
+ my ($fh, $filename) = get_tempfile('ftp-archives-XX');
+ my $BM_UPLOAD_FTP_SECURE = $ENV{"BM_UPLOAD_FTP_SECURE"};
+-my $ra_files;
+-if ($BM_UPLOAD_FTP_SECURE eq "true") {
+-$ra_files = $ftp->list();
+-}
+-else {
+-$ra_files = $ftp->ls();
+-}
++my $ra_files = $ftp->ls();
+ foreach my $file (@$ra_files) {
+ print $fh "$file\n";
+ }
+@@ -812,8 +806,7 @@ sub ftp_put_file ($$)
+ sub ftptls_put_file ($$)
+ {
+ my ($ftp, $file) = @_;
+-my $basename = basename ($file);
+-return $ftp->put ($basename, $file);
++return $ftp->put ($file);
+ }
+ 
+ # }}}
diff --git a/debian/patches/series b/debian/patches/series
index cec10e4..4ee0ee7 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,3 +4,4 @@ debian-user-guide-location.patch
 fix-tar-errors.patch
 fix-sanitize-messages.patch
 fix-purging-of-remote-archives-via-ftp-or-ssh.patch
+0007-Fixes-two-coding-bugs-in-backup-manager-upload.patch
-- 
2.29.2



signature.asc
Description: PGP signature

Bug#980115: connection failure when rx initialized after 08:25:36 GMT 14 Jan 2021

[A. Lewenberg]

On Mon, 18 Jan 2021 19:19:14 -0800 Benjamin Kaduk  wrote:

On Mon, Jan 18, 2021 at 06:04:39PM +, Jeremy Stanley wrote:
> Thanks for pulling this into unstable and testing! Is there any work
> in progress to fix it in stable as well? I took a quick peek in
> Salsa and didn't see any merge requests or an obvious branch for
> Buster's 1.8.2 (just the debian/1.8.2-1 tag).

It is a clear candidate to fix in stable, though the only concrete steps
I've been able to take so far are to confirm with the security team that it
is not a candidate for being fixed via a DSA.

The actual work of backporting the patches should be ~trivial, so the
process work of engaging with the release team will be the dominating
factor.

-Ben


Even though this fix is not strictly about security, without the fix it 
makes it impossible to patch the kernel and reboot our servers as this 
restart breaks the OpenAFS client.


So I urge the package maintainers to build a buster version containing 
the fix.


A. Lewenberge

Bug#981149: pacpl: A source-only upload is needed for testing migration

[Boyuan Yang]

Source: pacpl
Version: 6.1.2-1
Severity: important

Dear Debian pacpl package maintainer,

According to https://tracker.debian.org/pkg/pacpl , the latest upload
of pacpl was not a source-only upload. This means that the new version
will not migrate to Debian Testing. If this is not solved before Debian
11's hard freeze, the new version of pacpl will miss Debian 11 release.

Please make another source-only upload of package pacpl following
https://wiki.debian.org/SourceOnlyUpload . Let me know if you have any
questions.

-- 
Regards,
Boyuan Yang


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

Bug#932461: src:libfm: archivers.list fix xarchiver command

[Amy Kos]

Hi,

On Tue, 21 Jan 2021 11:03:42 +0100 Ingo Brückl  wrote:

> Will this make it for bullseye in time? At the moment it seems still missing.

Let's hope so.

https://salsa.debian.org/lxde-team/libfm/-/merge_requests/3

Cheers,
Amy

Bug#981070: e2fsprogs: (Possibly) e2fsck sometimes enables ext4 features on ext2 filesystems?

[Christoph Biedl]

Theodore Ts'o wrote...

> On Tue, Jan 26, 2021 at 12:10:20AM +0100, Christoph Biedl wrote:

> >   EXT4-fs (sdf3): mounted filesystem without journal. Opts: (null)
> > 
> > Expected:
> > 
> >   EXT4-fs (sdf3): mounting ext2 file system using the ext4 subsystem
> 
> That's just a matter of how it was mounted.  If you mount with -t
> ext2, you'll get:
> 
> # mke2fs -t ext2 /tmp/foo.img  2M
> # mount -t ext2 /tmp/foo.img /mnt
> [39916.330690] EXT4-fs (loop0): mounting ext2 file system using the ext4 
> subsystem
> 
> If you mount the same file system with ext4, you'll get:
> 
> # mount -t ext4 /tmp/foo.img /mnt
> 
> [39880.180962] EXT4-fs (loop0): mounted filesystem without journal. Opts: 
> (null). Quota mode: none.

Sorry, I should have provided some details here:

That kernel (in case that matters) has

# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y

and when mounting an ext2 this configuration does the right thing™ without
having to provide additional parameters like "-t". I could confirm that
by mounting an even way older ext2 that I found in my archives.

> > Therefore I assume e2fsck, while repairing the damage, by accident
> > enabled some feature bits that made the kernel think it is dealing with
> > an ext4
> > 
> > As I said, the raw image is destroyed. However I kept the output of
> > "tune2fs -l" (again, from testing), possibly this provides enough hint
> > to investigate?
> 
> You didn't actually include the output of tune2fs -l in your bug
> report.  Given that you named them "broken" and "okay" I assume you
> meant to attach them, but forgot to do so?

Yes, yes, attachments, signature, at least one I always forget.

> That being said, I'm pretty sure e2fsck enabled file system features;
> in general, it doesn't do that, and certainly not with any of the
> features added since the ext4 era.
> 
> My best guess is that I/O errors resulted in garbage getting written
> to the inode table, and e2fsck wasn't clearly the fscrypt inode flag
> when the fscrypt feature flag was not set; that would explain the
> fscrypt kernel error message that you saw.

Yes, and my question here: Is it possible the existence of that bogus
fscrypt feature flag made e2fsck or the kernel think this is an ext4,
and things went downhill from there? That's a situation I'd like to
avoid - since in the (today rare) case the bootloader cannot handle
ext4, this will result in an unbootable system.

And yes, providing "-t ext2" would have alerted. However, since the
CONFIG_EXT4_USE_FOR_EXT2 option always just worked in the past, I got a
bit lazy ...

Regards,

Christoph
Filesystem volume name:   boot-pontelli
Last mounted on:  /mnt/usbstick
Filesystem UUID:  0398a2d2-b74e-47e2-894f-0877f3f36bc0
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  ext_attr resize_inode dir_index filetype inline_data 
sparse_super
Filesystem flags: signed_directory_hash
Default mount options:user_xattr acl
Filesystem state: not clean
Errors behavior:  Continue
Filesystem OS type:   Linux
Inode count:  62496
Block count:  249868
Reserved block count: 12493
Free blocks:  175795
Free inodes:  62327
First block:  1
Block size:   1024
Fragment size:1024
Reserved GDT blocks:  256
Blocks per group: 8192
Fragments per group:  8192
Inodes per group: 2016
Inode blocks per group:   252
Filesystem created:   Sun May 11 16:14:32 2014
Last mount time:  Mon Jan 25 20:50:04 2021
Last write time:  Mon Jan 25 20:50:04 2021
Mount count:  1
Maximum mount count:  20
Last checked: Mon Jan 25 20:49:50 2021
Check interval:   15552000 (6 months)
Next check after: Sat Jul 24 21:49:50 2021
Lifetime writes:  2732 MB
Reserved blocks uid:  0 (user root)
Reserved blocks gid:  0 (group root)
First inode:  11
Inode size:   128
Default directory hash:   half_md4
Directory Hash Seed:  76f2e6b9-fd15-49b3-a118-ef1263a6faed

Filesystem volume name:   boot-pontelli
Last mounted on:  /mnt/boot
Filesystem UUID:  5f5e9ad4-183f-4dae-8045-b3c960a02a66
Filesystem magic number:  0xEF53
Filesystem revision #:1 (dynamic)
Filesystem features:  ext_attr resize_inode dir_index filetype sparse_super 
large_file
Filesystem flags: signed_directory_hash
Default mount options:user_xattr acl
Filesystem state: not clean
Errors behavior:  Continue
Filesystem OS type:   Linux
Inode count:  62496
Block count:  249868
Reserved block count: 12493
Free blocks:  232103
Free inodes:  62485
First block:  1
Block size:   1024
Fragment size:1024
Reserved GDT blocks:  256
Blocks per group:   

Bug#935950: fonts-symbola: Much newer version is available at upstream

[Yuri D'Elia]

It seems that the current version is 13.00, released March 2020,
at the new URL: https://dn-works.com/ufas/

Bug#980981: mirror listing update for debian.ccns.ncku.edu.tw

[Sean Ho]

Control: retitle -1 mirror submission for debian.csie.ncku.edu.tw

Hello,

Julien Cristau  於 2021年1月26日 週二 上午1:16寫道：
> o It seems your mirror is not up to date, having last updated on Tue, 19 Jan 
> 2021 04:40:08 +
> o The latest ftpsync versions come with a wrapper script called
>   ftpsync-cron, which is intended to be run out of cron every hour or so
>   (at a randomish offset).  The script monitors your upstream mirror,

I've set running ftpsync-cron hourly, and it should be able to check
the upstream mirror status more frequently.

> o The DNS zone for debian.ccns.ncku.edu.tw has a single name server.  At 
> least two are
>   required for better reliability/availability.

I've change the main mirror domain name to "debian.csie.ncku.edu.tw",
for its DNS zone has multiple(>=2) name server.

Sincerely,
Sean

Bug#930334: lxqt

[Amy Kos]

Hi,

if possible, some time, please look at:

https://salsa.debian.org/lxqt-team/libfm-qt/-/merge_requests/3

I hope this will be a proper patch.

Cheers,
Amy

Bug#981148: elpa-elpher: gemini:// breaks when gnutls-verify-error is t

[Sean Whitton]

Package: elpa-elpher
Version: 2.10.2-2

Hello,

In the elpher-get-host-response function there is

(when (and (eq use-tls 'gemini) (not elpher-gemini-TLS-cert-checks))
  (setq-local network-security-level 'low))

but I think that the when form should also contain

(setq-local gnutls-verify-error nil)

because it disables roughly the same checks at the gnutls library level
(see the docstring for the variable gnutls-verify-error).  I have
gnutls-verify-error set to t in my init for the sake of https
connections, but it probably makes sense for it to be off for gemini.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Brice Goglin, le mer. 27 janv. 2021 00:12:18 +0100, a ecrit:
> libnuma-dev and libibverbs-dev are also only needed for tests (libnuma
> isn't used in the lib itself since 2.0).

I committed for libnuma, thanks!

For libibverbs-dev, it was removed as part of
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950067

Samuel

Bug#973196: monero: FTBFS: optional.hpp:1591:3: error: static assertion failed: If you want to output boost::optional, include header

[mjxmr]

Dear Jonas,

TL;DR:

The following list of packages allows to build Monero under sid:

build-essential cmake pkg-config libboost-all-dev libssl-dev libzmq3-dev 
libunbound-dev libsodium-dev libunwind8-dev liblzma-dev libreadline6-dev 
libldns-dev libexpat1-dev libpgm-dev libhidapi-dev libusb-1.0-0-dev 
libprotobuf-dev protobuf-compiler libudev-dev

Longer explanation:

I have been experimenting with sid, using Docker (see attachement) and I was 
able to reproduce the problem, by simulating the list of dependencies, that 
occur in your build log (line 8 of the attached Dockerfile). The problem 
appears to be, that the Debian's dependency list is missing some of the boost 
libraries, needed to build Monero. The list above (and the only uncommented one 
in the Dockerfile) is the default, officially documented list. This list is 
being used in the Monero CI and it should serve as a pragmatic solution for you 
for the time being.

What I didn't have time to do, is to bisect the individual packages, in order 
to find the root cause of the problem, which might turn out to be simply a 
packaging problem.
I was looking for the optional_io.hpp file, mentioned in the error log, and it 
does appear to be available in the default 
[libboost1.74-dev](https://packages.debian.org/sid/libboost1.74-dev):
https://packages.debian.org/search?suite=sid=amd64=path=contents=optional_io.hpp
... so I got not more clues unfortunately.

In order to use the Dockerfile properly, please put it into the monero root 
source tree and run from the same directory:
sudo docker build -t monero .

I hope it helps.

MJ
Monero dev

Dockerfile
Description: Binary data

Bug#981147: loggedfs: missing dependency on fuse/fuse3 for fusermount binary

[Paul Wise]

Package: loggedfs
Version: 0.9+ds-2
Severity: serious

When I try to run loggedfs on a system without fuse/fuse3 installed I
get an error because the fusermount binary is not found.

   $ dir=$(mktemp --directory tmp-XX)
   $ loggedfs -f `pwd`/$dir
   2021-01-27 07:14:50,851 INFO [default] LoggedFS not running as a daemon
   2021-01-27 07:14:50,851 INFO [default] LoggedFS starting at 
/home/pabs/tmp-sLfW8Zzzf3.
   2021-01-27 07:14:50,851 INFO [default] chdir to /home/pabs/tmp-sLfW8Zzzf3
   fuse: failed to exec fusermount: No such file or directory
   2021-01-27 07:14:50,854 INFO [default] LoggedFS closing.

Based on the other bug I have filed it looks like loggedfs can only use
fuse not fuse3. The fuse3 package has "Provides: fuse (= 3.10.1-2)" so
you will have to depend on fuse << 3 to make loggedfs work.

Unfortunately fuse3 is required by other packages on my system, so
adding this dependency will be annoying for me, a better option would
be to make the code work with fuse3 and just depend on any fuse.

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

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

Versions of packages loggedfs depends on:
ii  libc6   2.31-9
ii  libfuse22.9.9-3
ii  libgcc-s1   10.2.1-6
ii  libpcre32:8.39-13
ii  libstdc++6  10.2.1-6
ii  libxml2 2.9.10+dfsg-6.3+b1

loggedfs recommends no packages.

loggedfs suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#978459: plasma-base: diff for NMU version 5.20.0+nmu1

[Norbert Preining]

On Tue, 26 Jan 2021, Boyuan Yang wrote:
> I've prepared an NMU for plasma-base (versioned as 5.20.0+nmu1) and
> uploaded it to DELAYED/7. Please feel free to tell me if I

No, please stop that.

I will request removal of this package.

It should NOT transition to testing, as I have already stated.

Thanks

Norbert

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

Bug#981113: ITP: root -- open-source data analysis framework

[Stephan Lachnit]

Control: retitle -1 ITP: cern-root -- data analysis framework

> Please add prefix "cern-" to the package name - both source and binary
> packages.

> Please re-use the old name.  "root" is a terrible choice of package name.

> At least. Even "root-system" is not very distict, I'd rather choose
> something like "root-analysis-framework", assuming that name is a good
> description for what the package does.

I agree with you all, the name is case-insensitive not very unambiguous.

I'm not a big fan of `root-system` either, as I think it's ambiguous as
well and doesn't really describe the software. I'll go with `cern-root`,
that should be pretty unambiguous.

Regards,
Stephan

Bug#981134: hwloc: reduce Build-Depends

[Brice Goglin]

Le 26/01/2021 à 14:35, Helmut Grohne a écrit :
> Source: hwloc
> Version: 2.4.0+dfsg-3
> Tags: patch
> User: helm...@debian.org
> Usertags: rebootstrap
>
> hwloc participates in dependency loops relevant to architecture
> bootstrap. Rather than work on such a difficult problem, I looked for
> easily droppable dependencies. It turns out that on glibc systems, hwloc
> prefers dlopen over ltdl, so we can restrict the dependency to !glibc
> systems. The libxml2-utils dependency is used for xmllint, which is used
> for tests. It can be annotated .


libnuma-dev and libibverbs-dev are also only needed for tests (libnuma
isn't used in the lib itself since 2.0).

Brice

Bug#981146: loggedfs: fails: fusermount: unknown option 'nonempty'

[Paul Wise]

Package: loggedfs
Version: 0.9+ds-2
Severity: serious

When I try to use loggedfs I get an error, presumably because loggedfs
wants fuse rather than fuse3, but I can't install fuse because other
things I have installed want fuse3 instead of fuse.

   $ dir=$(mktemp --directory tmp-XX)
   $ loggedfs -f `pwd`/$dir
   2021-01-27 07:12:43,997 INFO [default] LoggedFS not running as a daemon
   2021-01-27 07:12:43,997 INFO [default] LoggedFS starting at 
/home/pabs/tmp-C5P8Oih4Kz.
   2021-01-27 07:12:43,997 INFO [default] chdir to /home/pabs/tmp-C5P8Oih4Kz
   fusermount: unknown option 'nonempty'
   2021-01-27 07:12:44,001 INFO [default] LoggedFS closing.
   $ rmdir $dir
   $ apt list fuse fuse3
   Listing... Done
   fuse3/testing,unstable,now 3.10.1-2 amd64 [installed,automatic]
   fuse/testing,unstable 2.9.9-3 amd64

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

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

Versions of packages loggedfs depends on:
ii  libc6   2.31-9
ii  libfuse22.9.9-3
ii  libgcc-s1   10.2.1-6
ii  libpcre32:8.39-13
ii  libstdc++6  10.2.1-6
ii  libxml2 2.9.10+dfsg-6.3+b1

loggedfs recommends no packages.

loggedfs suggests no packages.

-- no debconf information

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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

Bug#940704: next error

[Paolo Greppi]

I fixed the error:

Cannot find module 'babel-preset-env'

but I am not sure if the fix is 100% right.

Now I get:

TypeError: Cannot read property 'mkdir' of undefined
   5 | export default function(filename?: string): Promise {
   6 |   return new Promise((resolve, reject) => {
>  7 | temp.mkdir(filename, function(err, path) {

I added node-temp in debian/tests/control Depends afetr jest, but that did not 
help (it would have errored on require('temp') anyway).

I have then turned my attention at brushing up node-temp, see this message to 
the js-team list:
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2021-January/052152.html

Paolo

Bug#981115: please support multiple compose keys in keyboard-configuration

[Lennart Sorensen]

On Tue, Jan 26, 2021 at 10:33:07PM +0100, Martin wrote:
> On 2021-01-26 14:02, Lennart Sorensen wrote:
> > It is not that simple.
> ...
> > Simply manually putting in the config instead seems like a lot less work.
> 
> Thanks for the investigation, Lennart!
> 
> I probably stay with:
> 
> $ setxkbmap -option compose:caps
> $ setxkbmap -option compose:ralt

You could do them on one line too.

-- 
Len Sorensen

Bug#978459: plasma-base: diff for NMU version 5.20.0+nmu1

[Boyuan Yang]

Control: tags 978459 + patch
Control: tags 978459 + pending

Dear maintainer,

I've prepared an NMU for plasma-base (versioned as 5.20.0+nmu1) and
uploaded it to DELAYED/7. Please feel free to tell me if I
should delay it longer.

Regards,
Boyuan Yang

diff -Nru plasma-base-5.20.0/debian/changelog plasma-base-
5.20.0+nmu1/debian/changelog
--- plasma-base-5.20.0/debian/changelog 2020-12-02 18:32:56.0
-0500
+++ plasma-base-5.20.0+nmu1/debian/changelog2021-01-26
17:45:28.0 -0500
@@ -1,3 +1,11 @@
+plasma-base (5.20.0+nmu1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * No change source-only upload for testing migration.
+(Closes: #978459)
+
+ -- Boyuan Yang   Tue, 26 Jan 2021 17:45:28 -0500
+
 plasma-base (5.20.0) unstable; urgency=medium
 
   [ Norbert Preining ]


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

Bug#981145: todo.txt-gtd: missing Breaks+Replaces: turnin-ng

[Andreas Beckmann]

Package: todo.txt-gtd
Version: 0.5
Severity: serious
User: debian...@lists.debian.org
Usertags: piuparts

Hi,

during a test with piuparts I noticed your package fails to upgrade from
'stable'.
It installed fine in 'stable', then the upgrade to 'sid' fails
because it tries to overwrite other packages files without declaring a
Breaks+Replaces relation.

See policy 7.6 at
https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces

This test intentionally skipped 'testing' to find file overwrite
problems before packages migrate from 'unstable' to 'testing'.

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

  Preparing to unpack .../todo.txt-gtd_0.5_all.deb ...
  Unpacking todo.txt-gtd (0.5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/todo.txt-gtd_0.5_all.deb (--unpack):
   trying to overwrite '/usr/share/man/man1/project.1.gz', which is also in 
package turnin-ng 1.3-1
  Errors were encountered while processing:
   /var/cache/apt/archives/todo.txt-gtd_0.5_all.deb

These files are in conflict between the two packages:

  /usr/bin/project
  /usr/share/man/man1/project.1.gz

Since turnin-ng has been removed after buster (due to being python2-only),
the Breaks+Replaces can be unversioned.


cheers,

Andreas


turnin-ng=1.3-1_todo.txt-gtd=0.5.log.gz
Description: application/gzip

Bug#981144: golang-github-cli-safeexec: A source-only upload is needed

[Boyuan Yang]

Source: golang-github-cli-safeexec
Version: 1.0.0-1
Severity: important
X-Debbugs-CC: f...@debian.org

Dear Debian golang-github-cli-safeexec package maintainers,

According to https://tracker.debian.org/pkg/golang-github-cli-safeexec
, this package did not receive any update after its initial upload. As
a result, it did not migrate to Debian Testing. We need another source-
only upload, or this package will not be able to enter the upcoming
Debian 11 release due to release freeze.

Please make another source-only upload following
https://wiki.debian.org/SourceOnlyUpload . Thanks!

-- 
Regards,
Boyuan Yang


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

Bug#981142: RFS: hello/3.1-4 [ITP] -- dayon

[Fensterkitt Computer Support]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "Dayon!":

Package name    : dayon
Version : 1.10.3
Upstream Author : Reto Galante, i...@fensterkitt.ch
URL :https://github.com/RetGal/Dayon  

License : GPL3
Section : RemoteAccess

It builds those binary packages:

(which includes both, the assistant and the assisted app, written in Java)

https://launchpad.net/~regal/+archive/ubuntu/dayon/+files/dayon_1.10.3~202101211301~ubuntu20.04.1_all.deb
  

To access further information about this package, please visit one of the 
following URLs:

https://snapcraft.io/dayon  

https://retgal.github.io/Dayon/  

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

wget -x 
https://launchpad.net/~regal/+archive/ubuntu/dayon/+sourcefiles/dayon/1.10.3~202101211301~ubuntu20.04.1/dayon_1.10.3~202101211301~ubuntu20.04.1.dsc

Regards from Switzerland,
Reto Galante

Bug#980261: RFS: jgmenu/4.3.0-1 [RFP] -- Simple X11 menu

[Boyuan Yang]

X-Debbugs-CC: mat...@linuxmint.pl jgm...@gmail.com


On Sat, 16 Jan 2021 21:38:16 +0100 =?UTF-8?Q?Mateusz_=c5=81ukasik?=
 wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> I am looking for a sponsor for my package "jgmenu":
> 
>   * Package name    : jgmenu
> Version : 4.3.0-1
> Upstream Author : Johan Malm 
>   * URL : https://jgmenu.github.io/
>   * License : LGPL-2+, GPL-2+, Expat, LGPL-3+
>   * Vcs : https://github.com/mati75/jgmenu
> Section : x11
> 
> It builds those binary packages:
> 
>    jgmenu-xfce4-panel-applet - xfce4-panel applet for jgmenu
>    jgmenu - Simple X11 menu
> 
> To access further information about this package, please visit the
following URL:
> 
>    https://mentors.debian.net/package/jgmenu/
> 
> Alternatively, one can download the package with dget using this
command:
> 
>    dget -x
https://mentors.debian.net/debian/pool/main/j/jgmenu/jgmenu_4.3.0-1.dsc
> 
> Changes for the initial release:
> 
>   jgmenu (4.3.0-1) unstable; urgency=medium
>   .
> * Initial release. (Closes: #882210)


One major problem: debian/copyright in your work says that the whole
project is licensed under GPL-2+, however the LICENSE file from
upstream only gives GPLv2 license text. The README file also does not
mention that the whole project is licensed under GPLv2 **or later**.

Could you please contact upstream to clarify the case? The best output
would be adding a "the whole project is licensed under GPLv2 or later"
sentense in the README file, which would make things clear to everyone.

P.S. I took a look at upstream's debian/copyright file at
https://github.com/johanmalm/jgmenu/blob/master/debian/copyright , in
which the upstream only mentioned GPL-2, not GPL-2+. If upstream is
only willing to release the whole project under GPL-2-only, using GPL-
2+ is wrong and must be fixed.

-- 
Thanks,
Boyuan Yang


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

Bug#981077: ITP: request-tracker5 -- extensible trouble-ticket tracking system

[Geert Stappers]

On Tue, Jan 26, 2021 at 01:17:46AM +, Dominic Hargreaves wrote:
> * Package name: request-tracker5
>   Upstream Author : Best Practical Solutions, LLC >
> * URL : https://bestpractical.com/rt/
> * License : GPL-2
>  .
>  This package supports three database types out of the box: MySQL,
>  PostgreSQL and SQLite. In order to support a zero-configuration install,
>  SQLite will be used by default, but is not recommended for production
>  use. Please see /usr/share/doc/request-tracker5/NOTES.Debian for more
>  details and consider installing rt5-db-postgresql or rt5-db-mysql at
>  the same time as this package.

How I would write those last three lines

}  use. Please see /usr/share/doc/request-tracker5/NOTES.Debian for more
}  details. Consider to install rt5-db-postgresql or rt5-db-mysql when
}  installing this package.


It is the  'at the same time as this'  that I'm wanting to loose.

Please feel free to ignore this non-native English speaker.


Regards
Geert Stappers
-- 
Silence is hard to parse

Bug#981141: transition: gdk-pixbuf binNMUs to drop transitional package

[Simon McVittie]

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

The library package libgdk-pixbuf2.0-0 was recently (in early December)
split into libgdk-pixbuf-2.0-0 and the deprecated libgdk-pixbuf-xlib-2.0-0,
with a transitional libgdk-pixbuf2.0-0 that depends on both. Newly built
packages will depend on libgdk-pixbuf-2.0-0 and/or libgdk-pixbuf-xlib-2.0-0,
but binary packages that were built before December still depend on
what is now a transitional package.

This is a "soft" transition and does not need a flag-day or coordination:
if bullseye releases with this transition incomplete, the only practical
impact is that the deprecated libgdk-pixbuf-xlib-2.0-0 stays installed
on more systems.

If you're still willing to trigger binNMUs at this stage of the freeze,
reverse dependencies of libgdk-pixbuf2.0-0 could be rebuilt to drop the
dependency on the transitional package. Most of them will lose their
unnecessary indirect dependency on the deprecated library as a result.

A few packages that were most recently built shortly after the transition
might show as both "good" and "bad", because they depend on
"libgdk-pixbuf-2.0-0 | libgdk-pixbuf2.0-0". This is harmless and I don't
mind whether they get rebuilt or not.

Ben file:

title = "gdk-pixbuf";
is_affected = .depends ~ "libgdk-pixbuf2.0-0" | .depends ~ 
"libgdk-pixbuf-2.0-0" | .depends ~ "libgdk-pixbuf-xlib-2.0-0";
is_good = .depends ~ "libgdk-pixbuf-2.0-0" | .depends ~ 
"libgdk-pixbuf-xlib-2.0-0";
is_bad = .depends ~ "libgdk-pixbuf2.0-0";

Thanks,
smcv

Bug#981068: [arm64] ldconfig segfaults inside a qemu-aarch64-static chroot

[Domenico Andreoli]

On Tue, Jan 26, 2021 at 09:31:58PM +0100, Aurelien Jarno wrote:
> On 2021-01-25 23:13, Domenico Andreoli wrote:
...
> > 
> > The issue is introduced with --enable-static-pie on -7, downgrading to
> > -6 or rebuilding -9 without --enable-static-pie makes the problem go away.
> 
> PIE support on arm64 requires at least qemu version 5.0. Please upgrade
> your qemu version.

Indeed I had just verified that also a basic hello world with static
PIE was failing when I read your email.

I confirm that with newer qemu everything is fine.

Thanks!

> 
> Aurelien
> 

Dom

-- 
rsa4096: 3B10 0CA1 8674 ACBA B4FE  FCD2 CE5B CF17 9960 DE13
ed25519: FFB4 0CC3 7F2E 091D F7DA  356E CC79 2832 ED38 CB05

Bug#981140: Info I forgot to mention

[Scupake]

- I am currently working on packaging it, and I do need a sponsor.

Sorry I didn't mention this in the first email.
- Scupake


signature.asc
Description: PGP signature

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Samuel Thibault, le mar. 26 janv. 2021 22:25:16 +0100, a ecrit:
> Helmut Grohne, le mar. 26 janv. 2021 22:14:22 +0100, a ecrit:
> > Maybe w3m can also be moved to b-d-i though?
> 
> Strictly speaking, no, as it is needed to update the README file from
> the doxygen html file, and it is getting installed in binary:any
> packages. But that's relatively pedantic, since the README file itself
> is an a completely easily modifiable form.

I have commented it, so it is documented how to get it generated, in
case anybody really wants to do it :)

Samuel

Bug#978636: move to merged-usr-only?

[Ansgar]

On Tue, 2021-01-26 at 13:17 +0200, Wouter Verhelst wrote:
> We can (and should, IMO) declare *today* that for bookworm, shipping
> files in / (as opposed to /usr) that are not compatibility symlinks
> will be RC.

I fear we are drifting away from just deciding to move to merged-/usr
to implementation details, but I originally[1] suggested to wait one
release between making merged-/usr mandatory (could happen in bookworm)
and moving installation paths in packages (could happen in trixie).

This seems to avoid several problems:
- partial upgrades to bookworm or backported packages from bookworm to
bullseye and from trixie to bookworm should still just work (backports
from then-testing trixie to then-oldstable bullseye, that is over two
releases, would need to take a bit more care)
- we need to touch packages for the move only once
- compat symlinks have various problems (cf. references to essential
packages[2] and OpenSuSE[3]).

Ansgar

  [1]: https://lists.debian.org/debian-devel/2020/11/msg00232.html
  [2]: https://lists.debian.org/debian-ctte/2021/01/msg00041.html
  [3]: https://lists.debian.org/debian-ctte/2021/01/msg00037.html

Bug#981140: ITP: xbanish: banish the mouse cursor when typing, show it again when the mouse moves

[Scupake]

Package: wnpp

* Package name: xbanish
  Version : 4.5
  Upstream Author : joshua stein 
* URL : https://github.com/jcs/xbanish
* License : BSD-3-Clause
  Programming Lang: C
  Description : banish the mouse cursor when typing, show it again when the
mouse moves

xbanish hides the mouse cursor when you start typing, and shows it again when
the mouse cursor moves or a mouse button is pressed. This is similar to
xterm's pointerMode setting, but xbanish works globally in the X11 session.

- I personally use this package because just having the cursor on the
  screen doing nothing is a bit annoying.
- unclutter's -keystroke is supposed to have the same functionality but
  it's broken.

- Scupake


signature.asc
Description: PGP signature

Bug#981139: frr: OSPF crashes after sh ip ospf interface lo

[Alexey]

Package: frr
Version: 7.4-1+b1
Severity: normal
Tags: upstream

Dear Maintainer,

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

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

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


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

Kernel: Linux 5.10.0-2-amd64 (SMP w/1 CPU thread)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages frr depends on:
ii  adduser   3.118
ii  iproute2  5.10.0-3
ii  libc-ares21.17.1-1
ii  libc6 2.31-9
ii  libcap2   1:2.44-1
ii  libcrypt1 1:4.4.17-1
ii  libjson-c50.15-1
ii  libpam0g  1.4.0-2
ii  libreadline8  8.1-1
ii  libsystemd0   247.2-5
ii  libyang1  1.0.184-2
ii  logrotate 3.18.0-1

Versions of packages frr recommends:
ii  frr-pythontools  7.4-1

Versions of packages frr suggests:
pn  frr-doc  

-- Configuration Files:
/etc/frr/daemons changed:
bgpd=yes
ospfd=yes
ospf6d=yes
ripd=yes
ripngd=yes
isisd=yes
pimd=yes
ldpd=yes
nhrpd=yes
eigrpd=yes
babeld=yes
sharpd=yes
pbrd=yes
bfdd=yes
fabricd=yes
vrrpd=yes
vtysh_enable=yes
zebra_options="  -A 127.0.0.1 -s 9000"
bgpd_options="   -A 127.0.0.1"
ospfd_options="  -A 127.0.0.1"
ospf6d_options=" -A ::1"
ripd_options="   -A 127.0.0.1"
ripngd_options=" -A ::1"
isisd_options="  -A 127.0.0.1"
pimd_options="   -A 127.0.0.1"
ldpd_options="   -A 127.0.0.1"
nhrpd_options="  -A 127.0.0.1"
eigrpd_options=" -A 127.0.0.1"
babeld_options=" -A 127.0.0.1"
sharpd_options=" -A 127.0.0.1"
pbrd_options="   -A 127.0.0.1"
staticd_options="-A 127.0.0.1"
bfdd_options="   -A 127.0.0.1"
fabricd_options="-A 127.0.0.1"
vrrpd_options="  -A 127.0.0.1"


-- no debconf information

backtrace:
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7efea3d15537 in __GI_abort () at abort.c:79
#2  0x7efea3d1540f in __assert_fail_base (fmt=0x7efea3e7e128 "%s%s%s:%u: 
%s%sAssertion `%s' failed.\n%n", assertion=0x7efea3fb241a "node->lock > 0", 
file=0x7efea3fb240e "lib/table.h", line=258, function=) at 
assert.c:92
#3  0x7efea3d24662 in __GI___assert_fail (assertion=0x7efea3fb241a 
"node->lock > 0", file=0x7efea3fb240e "lib/table.h", line=258, 
function=0x7efea3fc7de0 "route_unlock_node") at assert.c:101
#4  0x7efea3f85853 in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#5  0x7efea3f8644b in route_next () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#6  0x55f38a6df28f in ?? ()
#7  0x55f38a6dfb5d in ?? ()
#8  0x55f38a6e019f in ?? ()
#9  0x7efea3f33fec in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#10 0x7efea3f356d7 in cmd_execute_command () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#11 0x7efea3f358d6 in cmd_execute () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#12 0x7efea3f90345 in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#13 0x7efea3f909d1 in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#14 0x7efea3f938f0 in ?? () from /usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#15 0x7efea3f8ae76 in thread_call () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#16 0x7efea3f52aa8 in frr_run () from 
/usr/lib/x86_64-linux-gnu/frr/libfrr.so.0
#17 0x55f38a6a1b02 in main ()

Bug#981115: please support multiple compose keys in keyboard-configuration

[Martin]

On 2021-01-26 14:02, Lennart Sorensen wrote:
> It is not that simple.
...
> Simply manually putting in the config instead seems like a lot less work.

Thanks for the investigation, Lennart!

I probably stay with:

$ setxkbmap -option compose:caps
$ setxkbmap -option compose:ralt

Cheers

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Helmut Grohne, le mar. 26 janv. 2021 14:35:08 +0100, a ecrit:
> +Build-Depends: debhelper-compat (= 12), dh-exec, libltdl-dev [!gnu-any-any],

Ah, that triggers lintian's

E: hwloc source: invalid-arch-string-in-source-relation gnu-any-any 
[Build-Depends: libltdl-dev [!gnu-any-any]]

Samuel

Bug#981136: ki18n: drop unused Build-Depends: graphviz, qtscript5-dev

[Norbert Preining]

Hi Helmut,

> -   graphviz,
> -   qtscript5-dev (>= 5.8.0~),

Both are gone now in git. 

Thanks

Norbert

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

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Helmut Grohne, le mar. 26 janv. 2021 22:14:22 +0100, a ecrit:
> Maybe w3m can also be moved to b-d-i though?

Strictly speaking, no, as it is needed to update the README file from
the doxygen html file, and it is getting installed in binary:any
packages. But that's relatively pedantic, since the README file itself
is an a completely easily modifiable form.

Samuel

Bug#980106: python3.8-venv: can't create venv for python3.8 (and version other than 3.90), missing distutils

[Caleb Donovick]

Hi,

Is there a technical reason why maintaining multiple versions of Python on
debian is not possible?  I understand that it would be an engineering
effort but I am curious if there is more fundamental reason that makes
having multiple versions of Python on debian difficult.

Thanks,

Caleb


On Tue, Jan 26, 2021, 3:39 AM Matthias Klose  wrote:

> On 1/14/21 4:13 PM, Urs Schroffenegger wrote:
> > * What outcome did you expect instead?
> >
> > a virtual environment to be created.
> >
> >
> > Furthermore, I can run previously created virtualenv using python3.8,
> but I
> > can't install packages with pip, also with missing distutils errors.
> >
> > I don't know if this is a bug or if it's to be expected on unstable. But
> it
> > seems to me that python version numbers started to change faster lately.
> What's
> > debian's policy for other versions of python than the latests ? If older
> > version have no support, is there a debian way to work with multiple
> versions?
> > Or should I use something like pyenv for those cases?
>
> Debian ships with one Python3 version only.  So once we are finished with
> upgrading to a new Python version, the old Python3 version (3.8 in this
> case) is
> removed.  The removal bug https://bugs.debian.org/978710 is not yet
> addressed.
>
> Note that you also find snapshot builds for 3.10 in experimental, but
> there's no
> support for any third party modules.
>
> If you want to maintain packages for 3.8 yourself, you have to provide the
> binary packages built from the source packages python3.8 and
> python3-stdlib-extensions yourself.
>
> Yes, Python3 upstream now has a planned twelve months release cadence.
>
> Closing this issue as won't fix.
>
> Matthias
>
> --
> To unsubscribe, send mail to 980106-unsubscr...@bugs.debian.org.
>

Bug#975472: xmobar: autopkgtest regression on ppc64el: Not found

[Paul Gevers]

Control: notfound -1 0.36-2

Hi,

On Tue, 26 Jan 2021 20:25:27 +0200 Ilias Tsitsimpis
 wrote:
> Version: 0.36-2

I think this alone is not enough to mark the bug as not affecting the
version and the bts still block the package. Hopefully this mail fixes that.

Paul



OpenPGP_signature
Description: OpenPGP digital signature

Bug#981134: hwloc: reduce Build-Depends

[Helmut Grohne]

Hi Samuel,

On Tue, Jan 26, 2021 at 10:10:18PM +0100, Samuel Thibault wrote:
> Ah, that is unexpected actually, we do want to rebuild the
> documentation. Is that part a problem for loops?

I actually don't know. The list is so long that I'm having a hard time
figuring anything. So at first I just look into removing no-impact edges
as much as possible. I also prefer actually rebuilding the
documentation. Maybe w3m can also be moved to b-d-i though?

Consider the bug here being an unused dependency. Dropping it is a
solution as is using it.

Helmut

Bug#876010: lxde: LXDE session doesn't properly load - desktop is managed but no panel is loaded.

[Ulf]

Package: lxde
Version: 10+nmu1
Followup-For: Bug #876010
X-Debbugs-Cc: un.oslonor...@gmail.com

Dear maintainer!

After full-upgrade from buster to bullseye _lxpanel_ is sometimes not present.
Restart of lightdm helps, sometimes multiple restarts are needed.

Output of ps -efx for OK and NOK case is available ...

Severity from my point of view is _important_ - non-root-users cannot handle 
this situation.

Thanks in advance for help!

Regards
Unni

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

Kernel: Linux 5.10.0-1-amd64 (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 /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lxde depends on:
ii  gnome-calculator 3.38.2-1
ii  gpicview 0.2.5-3+b1
ii  leafpad  0.8.18.1-5
ii  lxappearance 0.6.3-1+b1
ii  lxappearance-obconf  0.2.3-1+b1
ii  lxde-core10+nmu1
ii  lxde-icon-theme  0.5.1-2.1
ii  lxhotkey-gtk 0.1.0-1.1
ii  lxinput  0.3.5-1+b1
ii  lxrandr  0.3.2-1+b1
ii  lxsession-edit   0.5.5-2
ii  lxterminal   0.3.2-1.1
ii  mousepad 0.5.1-1
ii  xarchiver1:0.5.4.16-1

Versions of packages lxde recommends:
ii  chromium [www-browser]   87.0.4280.141-0.1~deb10u1
pn  clipit   
ii  evince [pdf-viewer]  3.38.0-3
ii  firefox-esr [www-browser]78.6.1esr-1
ii  gdm3 [x-display-manager] 3.38.2.1-1
ii  gnome-disk-utility   3.38.1-1
ii  gnome-system-tools   3.0.0-9.1
ii  gucharmap1:13.0.5-1
ii  lightdm [x-display-manager]  1.26.0-7
ii  lxmusic  0.4.7-1+b1
ii  lxpolkit 0.5.5-2
ii  lynx [www-browser]   2.9.0dev.6-1
ii  menu-xdg 0.6+nmu1
ii  mupdf [pdf-viewer]   1.17.0+ds1-1.2
ii  network-manager-gnome1.18.0-1
ii  qpdfview [pdf-viewer]0.4.18-4
ii  transmission-gtk 3.00-1
ii  usermode 1.113-4
ii  vlc  3.0.12-1
ii  xserver-xorg 1:7.7+21

Versions of packages lxde suggests:
ii  gimp 2.10.22-2
pn  libreoffice  
ii  lxlauncher   0.2.5-1+b1
ii  lxtask   0.1.10-1
pn  pidgin   
pn  pk-update-icon   
pn  xfce4-power-manager  

-- no debconf information

Bug#981134: hwloc: reduce Build-Depends

[Samuel Thibault]

Helmut Grohne, le mar. 26 janv. 2021 14:35:08 +0100, a ecrit:
> Finally, the documentation is not rebuilt during package build.

Ah, that is unexpected actually, we do want to rebuild the
documentation. Is that part a problem for loops?

I applied the rest, thanks!

Samuel

Bug#981138: tiemu FTCBFS: issues around build tool builds

[Helmut Grohne]

Source: tiemu
Version: 3.04~git20110801-nogdb+dfsg1-2
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

tiemu is mostly prepared for cross building, but fails doing so in the
end. There are two reasons for this:

 * In src/core/uae, build tools are built with plain gcc (which is
   good), but the host architecture LDFLAGS containing tons of host
   libraries are also passed. Since these libraries are only installed
   for the host architecture, linking fails. These tools do not use any
   libraries beyond libc though, so the LDFLAGS can be dropped here.
 * In the man directory, the cleaner application is built with the host
   architecture compiler. Running it results in an Exec format error.
   The compiler needs to be changed as has been done in src/core/uae.

Once fixing these, tiemu cross builds successfully. Please consider
applying the attached patch.

Helmut
--- tiemu-3.04~git20110801-nogdb+dfsg1.orig/src/core/uae/Makefile
+++ tiemu-3.04~git20110801-nogdb+dfsg1/src/core/uae/Makefile
@@ -29,11 +29,11 @@
 # Build generators and files to generate
 build68k: build68k_host.o
 	@echo "-> Compiling 68k builder..."
-	C_INCLUDE_PATH="" LIBRARY_PATH="" gcc $(LDFLAGS) -o $@ $?
+	C_INCLUDE_PATH="" LIBRARY_PATH="" gcc -o $@ $?
 
 gencpu: gencpu_host.o readcpu_host.o cpudefs_host.o missing_host.o xmalloc_host.o
 	@echo "-> Compiling CPU generator..."
-	C_INCLUDE_PATH="" LIBRARY_PATH="" gcc $(LDFLAGS) -o $@ gencpu_host.o readcpu_host.o cpudefs_host.o missing_host.o xmalloc_host.o
+	C_INCLUDE_PATH="" LIBRARY_PATH="" gcc -o $@ gencpu_host.o readcpu_host.o cpudefs_host.o missing_host.o xmalloc_host.o
 
 cpudefs.c: build68k table68k
 	@echo "-> Building CPU definitions..."
--- tiemu-3.04~git20110801-nogdb+dfsg1.orig/man/Makefile.am
+++ tiemu-3.04~git20110801-nogdb+dfsg1/man/Makefile.am
@@ -10,6 +10,6 @@
 
 dist_win: $(man_MANS)
 	groff -Tascii -man $(man_MANS) > Manpage
-	C_INCLUDE_PATH="" LIBRARY_PATH="" $(CC) cleaner.c -o cleaner
+	C_INCLUDE_PATH="" LIBRARY_PATH="" gcc cleaner.c -o cleaner
 	./cleaner Manpage
 	rm Manpage cleaner

Bug#981137: git: annotate test dependencies

[Helmut Grohne]

Source: git
Version: 1:2.30.0-1
Tags: patch
User: debian-cr...@lists.debian.org
Usertags: cross-satisfiability

git cannot be cross built from source, because its Build-Depends are not
cross satisfiable. Instead of looking into such a difficult problem, I
looked for easily droppable dependencies. Given that git is normally
reproducible, one can easily verify that a nocheck build with the
following dependencies turned into Build-Conflicts exactly reproduces a
regular build if one keeps debian/changelog unmodified:

 * subversion
 * libsvn-perl
 * libyaml-perl
 * libhttp-date-perl
 * libcgi-pm-perl
 * liberror-perl
 * libmailtools-perl
 * cvs
 * cvsps
 * libdbd-sqlite3-perl
 * unzip
 * libio-pty-perl

It could be that some of these really are unused, but that's difficult
to tell without deeper git knowledge. The safe bet is annotating them
. Please consider applying the attached patch.

Helmut
diff --minimal -Nru git-2.30.0/debian/changelog git-2.30.0/debian/changelog
--- git-2.30.0/debian/changelog 2020-12-29 01:22:30.0 +0100
+++ git-2.30.0/debian/changelog 2021-01-26 10:53:55.0 +0100
@@ -1,3 +1,10 @@
+git (1:2.30.0-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Annotate test dependencies . (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 26 Jan 2021 10:53:55 +0100
+
 git (1:2.30.0-1) unstable; urgency=low
 
   * new upstream release (see RelNotes/2.30.0.txt).
diff --minimal -Nru git-2.30.0/debian/control git-2.30.0/debian/control
--- git-2.30.0/debian/control   2020-12-29 01:21:37.0 +0100
+++ git-2.30.0/debian/control   2021-01-26 10:53:54.0 +0100
@@ -6,14 +6,14 @@
 Build-Depends: libz-dev, gettext,
  libpcre2-dev | libpcre3-dev,
  libcurl4-gnutls-dev, libexpat1-dev,
- subversion, libsvn-perl, libyaml-perl,
+ subversion , libsvn-perl , libyaml-perl ,
  tcl, python3,
- libhttp-date-perl | libtime-parsedate-perl,
- libcgi-pm-perl,
- liberror-perl,
- libmailtools-perl,
- cvs, cvsps, libdbd-sqlite3-perl,
- unzip, libio-pty-perl,
+ libhttp-date-perl  | libtime-parsedate-perl ,
+ libcgi-pm-perl ,
+ liberror-perl ,
+ libmailtools-perl ,
+ cvs , cvsps , libdbd-sqlite3-perl ,
+ unzip , libio-pty-perl ,
  debhelper-compat (= 10),
  dh-exec (>= 0.7),
  dh-apache2,

Bug#981136: ki18n: drop unused Build-Depends: graphviz, qtscript5-dev

[Helmut Grohne]

Source: ki18n
Version: 5.78.0-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

ki18n participates in dependency loops relevant to architecture
bootstrap. Instead of looking into such a difficult problem, I looked
for easily droppable dependencies. Norbert likely already committed the
dropping of graphviz to git. I'm including it for completeness and
confirmation here. Beyond that, qtscript5-dev is also unused. No
#include of it is mentioned anywhere in the source. I think it can
safely be dropped and I verified that doing so does not change output
artifacts. Please consider applying the attached patch.

Helmut
diff --minimal -Nru ki18n-5.78.0/debian/changelog ki18n-5.78.0/debian/changelog
--- ki18n-5.78.0/debian/changelog   2021-01-17 04:02:22.0 +0100
+++ ki18n-5.78.0/debian/changelog   2021-01-26 06:54:07.0 +0100
@@ -1,3 +1,10 @@
+ki18n (5.78.0-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused graphviz and qtscript5-dev from Build-Depends. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 26 Jan 2021 06:54:07 +0100
+
 ki18n (5.78.0-2) unstable; urgency=medium
 
   * Release to unstable.
diff --minimal -Nru ki18n-5.78.0/debian/control ki18n-5.78.0/debian/control
--- ki18n-5.78.0/debian/control 2021-01-17 03:54:33.0 +0100
+++ ki18n-5.78.0/debian/control 2021-01-26 06:54:05.0 +0100
@@ -9,13 +9,11 @@
doxygen (>= 1.8.13~),
extra-cmake-modules (>= 5.78.0~),
gettext,
-   graphviz,
libqt5sql5-sqlite:native,
pkg-kde-tools (>= 0.15.15ubuntu1~),
python3:any,
qtbase5-dev (>= 5.14.0~),
qtdeclarative5-dev (>= 5.14.0~),
-   qtscript5-dev (>= 5.8.0~),
qttools5-dev,
qttools5-dev-tools (>= 5.4)
 Standards-Version: 4.5.1

Bug#981134: hwloc: reduce Build-Depends

[Helmut Grohne]

Source: hwloc
Version: 2.4.0+dfsg-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

hwloc participates in dependency loops relevant to architecture
bootstrap. Rather than work on such a difficult problem, I looked for
easily droppable dependencies. It turns out that on glibc systems, hwloc
prefers dlopen over ltdl, so we can restrict the dependency to !glibc
systems. The libxml2-utils dependency is used for xmllint, which is used
for tests. It can be annotated . Finally, the documentation is
not rebuilt during package build. As a result, doxygen-latex, transfig
and w3m are unused and can be dropped. Please consider applying the
attached patch. Alternatively, consider actually rebuilding the
documentation during package build.

Helmut
diff --minimal -Nru hwloc-2.4.0+dfsg/debian/changelog 
hwloc-2.4.0+dfsg/debian/changelog
--- hwloc-2.4.0+dfsg/debian/changelog   2020-12-31 15:21:52.0 +0100
+++ hwloc-2.4.0+dfsg/debian/changelog   2021-01-26 14:20:03.0 +0100
@@ -1,3 +1,15 @@
+hwloc (2.4.0+dfsg-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Restrict libltdl-dev dependency to !glibc systems as hwloc prefers
+  dlopen for glibc.
++ Annotate test dependency libxml2-utils .
++ Drop dependencies doxygen-latex, transfig and w3m as the documentation
+  is not rebuilt during package build anyway.
+
+ -- Helmut Grohne   Tue, 26 Jan 2021 14:20:03 +0100
+
 hwloc (2.4.0+dfsg-3) unstable; urgency=medium
 
   * control: Update packaging URL.
diff --minimal -Nru hwloc-2.4.0+dfsg/debian/control 
hwloc-2.4.0+dfsg/debian/control
--- hwloc-2.4.0+dfsg/debian/control 2020-12-31 14:41:28.0 +0100
+++ hwloc-2.4.0+dfsg/debian/control 2021-01-26 14:20:03.0 +0100
@@ -1,16 +1,15 @@
 Source: hwloc
 Priority: optional
 Maintainer: Samuel Thibault 
-Build-Depends: debhelper-compat (= 12), dh-exec, libltdl-dev,
+Build-Depends: debhelper-compat (= 12), dh-exec, libltdl-dev [!gnu-any-any],
   valgrind [amd64 arm64 armhf i386 mips64el mipsel ppc64el s390x powerpc 
ppc64],
-  libcairo2-dev, libx11-dev, libxml2-dev, libxml2-utils, libncurses5-dev,
+  libcairo2-dev, libx11-dev, libxml2-dev, libxml2-utils , 
libncurses5-dev,
   libnuma-dev [linux-any],
   libxnvctrl-dev,
   libpciaccess-dev, libudev-dev [linux-any], pkg-config,
   ocl-icd-opencl-dev [!hurd-i386] | opencl-dev, opencl-headers,
-  autoconf (>= 2.63), w3m,
+  autoconf (>= 2.63),
   dpkg-dev (>= 1.16)
-Build-Depends-Indep: doxygen-latex, transfig
 Build-Conflicts: autoconf2.13
 Standards-Version: 4.5.0
 Section: libs

Bug#981135: cmake: drop unused Build-Depends: libbz2-dev and liblzma-dev

[Helmut Grohne]

Source: cmake
Version: 3.18.4-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

cmake participates in dependency loops relevant to architecture
bootstrap. Rather than look into such a difficult problem, I looked into
easily droppable dependencies and found that both libbz2-dev and
liblzma-dev are unused as cmake prefers decompressing these formats via
libarchive. Please consider applying the attached patch to drop them.

Helmut
diff --minimal -Nru cmake-3.18.4/debian/changelog cmake-3.18.4/debian/changelog
--- cmake-3.18.4/debian/changelog   2020-10-19 16:20:14.0 +0200
+++ cmake-3.18.4/debian/changelog   2021-01-26 16:54:47.0 +0100
@@ -1,3 +1,11 @@
+cmake (3.18.4-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused Build-Depends: libbz2-dev and liblzma-dev. (Closes: #-1)
+Compression support is handled via libarchive.
+
+ -- Helmut Grohne   Tue, 26 Jan 2021 16:54:47 +0100
+
 cmake (3.18.4-1) unstable; urgency=medium
 
   [ Tobias Frost ]
diff --minimal -Nru cmake-3.18.4/debian/control cmake-3.18.4/debian/control
--- cmake-3.18.4/debian/control 2020-10-15 20:02:00.0 +0200
+++ cmake-3.18.4/debian/control 2021-01-26 16:54:45.0 +0100
@@ -7,11 +7,9 @@
 Build-Depends: debhelper-compat (= 12),
freebsd-glue [kfreebsd-any],
libarchive-dev (>= 3.3.3),
-   libbz2-dev,
libcurl4-openssl-dev | libcurl-ssl-dev,
libexpat1-dev,
libjsoncpp-dev,
-   liblzma-dev,
libncurses5-dev,
librhash-dev,
libuv1-dev (>= 1.10),

Bug#981133: libxkbcommon: reduce Build-Depends

[Helmut Grohne]

Source: libxkbcommon
Version: 1.0.3-2
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

libxkbcommon participates in dependency loops relevant to architecture
bootstrap. Instead of looking into such a difficult problem, I looked
for easily droppable dependencies.

An obvious one is cmake as libxkbcommon now uses meson.

libx11-dev is less obvious. libxkbcommon now uses libxcb a lot and does
not use any libx11-dev header.

I'm not sure what xutils-dev was ever used for. I couldn't locate any
use of it anywhere in libxkbcommon or an explanation in a changelog.
Maybe it was build with xmkmf at an earlier time? I suggest dropping it
as well.

x11-xkb-utils and xkb-data are less obvious. I'm not sure whether
they're completely unused or whether they're used in tests. The safe bet
is annotating them , but maybe removing them is better.

Since libxkbcommon is normally reproducible, one can verify the
correctness of this change. A regular build produces the very same
binary artifacts as a nocheck build with all of the mentioned
dependencies turned into Build-Conflicts. Please consider applying the
attached patch.

Helmut
diff --minimal -Nru libxkbcommon-1.0.3/debian/changelog 
libxkbcommon-1.0.3/debian/changelog
--- libxkbcommon-1.0.3/debian/changelog 2020-11-26 13:55:39.0 +0100
+++ libxkbcommon-1.0.3/debian/changelog 2021-01-26 20:47:43.0 +0100
@@ -1,3 +1,14 @@
+libxkbcommon (1.0.3-2.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
++ Drop cmake as we now use meson.
++ Drop libx11-dev as we now use libxcb.
++ Drop xutils-dev as no tool of it is being used.
++ Annotate x11-xkb-utils and xkb-data .
+
+ -- Helmut Grohne   Tue, 26 Jan 2021 20:47:43 +0100
+
 libxkbcommon (1.0.3-2) unstable; urgency=medium
 
   [ Simon McVittie ]
diff --minimal -Nru libxkbcommon-1.0.3/debian/control 
libxkbcommon-1.0.3/debian/control
--- libxkbcommon-1.0.3/debian/control   2020-11-26 13:50:36.0 +0100
+++ libxkbcommon-1.0.3/debian/control   2021-01-26 20:47:43.0 +0100
@@ -6,7 +6,6 @@
 Build-Depends:
  debhelper-compat (= 12),
  bison,
- cmake,
  dh-exec,
  doxygen,
  flex,
@@ -15,14 +14,12 @@
  pkg-config,
  quilt,
  libwayland-dev [linux-any],
- libx11-dev,
  libxcb-xkb-dev (>= 1.10),
  libxml2-dev,
  wayland-protocols [linux-any],
- x11-xkb-utils,
+ x11-xkb-utils ,
  x11proto-dev,
- xkb-data,
- xutils-dev (>= 7.5+4),
+ xkb-data ,
  xvfb ,
 Standards-Version: 4.5.0
 Homepage: http://www.xkbcommon.org/

Bug#981132: jack-audio-connection-kit: reduce Build-Depends

[Helmut Grohne]

Source: jack-audio-connection-kit
Version: 1:0.125.0-3
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

jack-audio-connection-kit participates in dependency loops relevant to
architecture bootstrap. Rather than look into such a difficult problem,
I looked for easily droppable dependencies. I found that patchutils is
not used anywhere. I suppose that it was used for the quilt patchsystem
before the package was switched to source format quilt. Beyond that,
uuid-dev seems unused. jack now has its own uuid header and the
dependency (both Build-Depends and -dev Depends) can be dropped with no
replacement. Please consider applying the attached patch.

Helmut
diff --minimal -Nru jack-audio-connection-kit-0.125.0/debian/changelog 
jack-audio-connection-kit-0.125.0/debian/changelog
--- jack-audio-connection-kit-0.125.0/debian/changelog  2017-11-11 
12:06:25.0 +0100
+++ jack-audio-connection-kit-0.125.0/debian/changelog  2021-01-26 
07:34:08.0 +0100
@@ -1,3 +1,10 @@
+jack-audio-connection-kit (1:0.125.0-3.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Drop unused dependencis on patchutils and uuid-dev. (Closes: #-1)
+
+ -- Helmut Grohne   Tue, 26 Jan 2021 07:34:08 +0100
+
 jack-audio-connection-kit (1:0.125.0-3) unstable; urgency=medium
 
   [ Mattia Rizzolo ]
diff --minimal -Nru jack-audio-connection-kit-0.125.0/debian/control 
jack-audio-connection-kit-0.125.0/debian/control
--- jack-audio-connection-kit-0.125.0/debian/control2017-11-11 
11:52:35.0 +0100
+++ jack-audio-connection-kit-0.125.0/debian/control2021-01-26 
07:34:06.0 +0100
@@ -23,9 +23,7 @@
  libtool,
  libzita-alsa-pcmi-dev [linux-any],
  libzita-resampler-dev [linux-any],
- patchutils,
  po-debconf,
- uuid-dev,
 Standards-Version: 4.1.1
 Homepage: http://jackaudio.org/
 Vcs-Git: 
https://anonscm.debian.org/git/pkg-multimedia/jack-audio-connection-kit.git
@@ -116,7 +114,6 @@
 Depends:
  libjack0 (= ${binary:Version}),
  pkg-config,
- uuid-dev,
  ${devlibs:Depends},
  ${misc:Depends},
  ${shlibs:Depends},

Bug#981131: fig2dev: reduce Build-Depends

[Helmut Grohne]

Source: fig2dev
Version: 1:3.2.8-1
Tags: patch
User: helm...@debian.org
Usertags: rebootstrap

fig2dev participates in dependency loops relevant to architecture
bootstrap. Rather than looking into such a difficult problem, I looked
into easily droppable dependencies. It turns out that fig2dev formerly
used xmkmf, but no longer does. As such, the xutils-dev dependency can
be dropped. The netpbm and texlive-latex-extra dependencies are used for
testing fig2dev, but not otherwise. Thus they can be annotated
. Please consider applying the attached patch.

Helmut
diff --minimal -Nru fig2dev-3.2.8/debian/changelog 
fig2dev-3.2.8/debian/changelog
--- fig2dev-3.2.8/debian/changelog  2020-12-26 16:40:20.0 +0100
+++ fig2dev-3.2.8/debian/changelog  2021-01-26 11:04:19.0 +0100
@@ -1,3 +1,13 @@
+fig2dev (1:3.2.8-1.1) UNRELEASED; urgency=medium
+
+  * Non-maintainer upload.
+  * Reduce Build-Depends: (Closes: #-1)
+* Drop xutils-dev as fig2dev no longer uses xmkmf.
+* Annotate netpbm and texlive-latex-extra  as they are only used
+  during tests.
+
+ -- Helmut Grohne   Tue, 26 Jan 2021 11:04:19 +0100
+
 fig2dev (1:3.2.8-1) unstable; urgency=medium
 
   * New upstream version 3.2.8.
diff --minimal -Nru fig2dev-3.2.8/debian/control fig2dev-3.2.8/debian/control
--- fig2dev-3.2.8/debian/control2020-12-26 16:40:20.0 +0100
+++ fig2dev-3.2.8/debian/control2021-01-26 11:04:19.0 +0100
@@ -7,15 +7,14 @@
gawk,
ghostscript,
libpng-dev,
-   netpbm,
+   netpbm ,
texlive-font-utils,
texlive-fonts-recommended,
texlive-lang-german,
texlive-latex-base,
-   texlive-latex-extra,
+   texlive-latex-extra ,
texlive-latex-recommended,
texlive-pictures (>= 2013.20140314),
-   xutils-dev,
zlib1g-dev
 Homepage: https://sourceforge.net/projects/mcj/
 Vcs-Git: https://salsa.debian.org/debian/fig2dev.git

Bug#981130: dump1090-mutability FTCBFS: hard codes the build architecture pkg-config

[Helmut Grohne]

Source: dump1090-mutability
Version: 1.15~20180310.4a16df3+dfsg-7
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

dump1090-mutability fails to cross build from source, because the
upstream Makefile hard codes the build architecture pkg-config and thus
it fails finding the relevant dependencies. Making it substitutable is
all that it takes to make dump1090-mutability cross buildable. Please
consider applying the attached patch.

Helmut
--- dump1090-mutability-1.15~20180310.4a16df3+dfsg.orig/Makefile
+++ dump1090-mutability-1.15~20180310.4a16df3+dfsg/Makefile
@@ -17,7 +17,8 @@
 CPPFLAGS+=-DMODES_DUMP1090_VERSION=\"$(DUMP1090_VERSION)\"
 CFLAGS+=-O2 -g -Wall -Werror -W -Wno-unknown-warning-option -Wno-format-truncation
 LIBS=-lpthread -lm
-LIBS_RTL=`pkg-config --libs libusb-1.0 librtlsdr`
+PKG_CONFIG?=pkg-config
+LIBS_RTL=`$(PKG_CONFIG) --libs libusb-1.0 librtlsdr`
 CC=gcc
 
 UNAME := $(shell uname)
@@ -48,7 +49,7 @@
 %.o: %.c *.h
 	$(CC) $(CPPFLAGS) $(CFLAGS) $(EXTRACFLAGS) -c $< -o $@
 
-dump1090.o: CFLAGS += `pkg-config --cflags libusb-1.0 librtlsdr`
+dump1090.o: CFLAGS += `$(PKG_CONFIG) --cflags libusb-1.0 librtlsdr`
 
 dump1090: dump1090.o anet.o interactive.o mode_ac.o mode_s.o net_io.o crc.o demod_2400.o stats.o cpr.o icao_filter.o track.o util.o convert.o $(COMPAT)
 	$(CC) -g -o $@ $^ $(LIBS) $(LIBS_RTL) $(LDFLAGS)

Bug#980841: [Pkg-pascal-devel] Bug#980841: fpc: Please add workaround patch to fix FTBFS on m68k

[Abou Al Montacir]

Hi,
On Tue, 2021-01-26 at 16:33 +0100, John Paul Adrian Glaubitz wrote:
> It seems that FPC has a fix for this now [1] which is supposed to ship withFPC
> 3.2.2. I have not personally verified yet whether this fixes the issuefor me,
> but it might be worth a shot to try 3.2.2 without my patch first.
Please let us know if you come to make it work.
-- 
Cheers,
Abou Al Montacir


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

Bug#978636: move to merged-usr-only?

[Simon McVittie]

On Tue, 26 Jan 2021 at 12:17:37 -0600, Gunnar Wolf wrote:
> Wouter Verhelst dijo [Tue, Jan 26, 2021 at 01:17:38PM +0200]:
> > We can (and should, IMO) declare *today* that for bookworm, shipping
> > files in / (as opposed to /usr) that are not compatibility symlinks will
> > be RC.
> 
> I agree with you

For at least the Essential packages like bash and libc6, I don't think
we can go in that order. Given that implementations of merged /usr via
aliasing symlinks already exist, I think Essential packages that ship
part of their Essential functionality in /bin, /sbin, /lib* must stay
as they are now, until after we have had a flag day (a release)
at which either:

a. those aliasing symlinks are guaranteed to be in place (Ansgar's request
   in this bug)
b. those aliasing symlinks are forbidden and must be rolled back (Guillem's
   preferred answer to this, but judging by #914897 and discussion of this
   bug, very unlikely to be the technical committee's preferred answer)

That's because these two axioms collide:

* Essential packages must provide their Essential functionality while
  unpacked but not configured
  - e.g. unpacking libc6:i386 creates /lib/ld-linux.so.2, which is Essential
functionality that other packages rely on

* There are existing installations with merged /usr via aliasing symlinks
  - Therefore compatibility symlinks (in either direction!) must be created
by a maintainer script rather than directly shipped in the
dpkg --fsys-tarfile, otherwise they will fail to unpack on those existing
systems
- e.g. if unpacking libc6:i386 creates /usr/lib/ld-linux.so.2, then it
  cannot also create /lib/ld-linux.so.2; that would have to happen
  later, when it's configured

I don't see a way to have a compromise position in Essential packages,
other than the one we have right now (where the name in the
dpkg --fsys-tarfile must match other packages' expectations, whether
that means with or without /usr), without breaking the Essential
property.

When thinking about this transition (and any contentious issue, really),
please distinguish between:

- things that (in someone's opinion, maybe yours) we *shouldn't* do;
- things that (according to properties we take as axiomatic, like the
  Essential property and the requirement that upgrades work) we *can't* do

I have been trying hard to consider all the options that are available -
even the ones that I personally think we *shouldn't* do - but immediately
dismiss the ones that we *can't* do.

smcv

Bug#971093: closed by Debian FTP Masters (reply to Jonas Meurer ) (Bug#971093: fixed in lazr.config 2.2.2-1)

[Jonas Meurer]

Hey Colin,

Am 26.01.21 um 11:12 schrieb Colin Watson:

On Mon, Jan 25, 2021 at 10:59:28PM +, Colin Watson wrote:

On Sat, Jan 02, 2021 at 12:24:05AM +, Debian Bug Tracking System wrote:

* Disable test `test_not_stackable` which fails for python3.9
  (Closes: #970148)


Thanks for sorting out the immediate issue, but this should really have
been reported upstream for a proper fix.  I've proposed a better fix
just now:

   
https://code.launchpad.net/~cjwatson/lazr.config/zope.interface-5.0.0/+merge/396876


Fixed upstream now in lazr.config 2.2.3, and I've uploaded 2.2.3-1 to
Debian.


Thanks a lot for taking care Colin, that's much appreciated!

Indeed I had reporting it upstream on my todo list, but I was too busy 
with other stuff in the meantime.


Cheers
 jonas



OpenPGP_signature
Description: OpenPGP digital signature

Bug#948739: Bug #948739: gparted should not mask .mount units

[John Paul Adrian Glaubitz]

Hello!

It looks like this particular issue has been fixed in gparted 1.2.0 which
was just released a few days ago [1]:

> - Don't try to mask non-existent Systemd \xe2\x97\x8f.service (#129, !64)

Might be an idea to update gparted to version 1.2.0 before the Bullseye freeze
which is coming in Mid-February [2].

Adrian

> [1] https://sourceforge.net/projects/gparted/files/gparted/gparted-1.2.0/
> [2] https://release.debian.org/bullseye/freeze_policy.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Bug#981068: [arm64] ldconfig segfaults inside a qemu-aarch64-static chroot

[Aurelien Jarno]

control: reassign -1 qemu-user-static
control: found -1 qemu-user-static/1:3.1+dfsg-8
control: close -1 1:5.0-1
control: affects -1 libc6

On 2021-01-25 23:13, Domenico Andreoli wrote:
> Package: libc-bin
> Version: 2.31-7
> 
> The issue is reproducible inside a arm64 chroot, on a amd64 host,
> via qemu-aarch64-static. No problems on a native arm64.
> 
> Package upgrade fails with segmentation fault on post-installation,
> it's ldconfig:
> 
> # dpkg -i libc-bin_2.31-7_arm64.deb
> Unknown host QEMU_IFLA type: 50
> Unknown host QEMU_IFLA type: 51
> Unknown host QEMU_IFLA type: 50
> Unknown host QEMU_IFLA type: 51
> Unknown host QEMU_IFLA type: 50
> Unknown host QEMU_IFLA type: 51
> Unknown host QEMU_IFLA type: 50
> Unknown host QEMU_IFLA type: 51
> (Reading database ... 50524 files and directories currently installed.)
> Preparing to unpack libc-bin_2.31-7_arm64.deb ...
> Unpacking libc-bin (2.31-7) over (2.31-6) ...
> Setting up libc-bin (2.31-7) ...
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> Segmentation fault
> dpkg: error processing package libc-bin (--install):
>  installed libc-bin package post-installation script subprocess returned 
> error exit status 139
> Processing triggers for man-db (2.9.3-2) ...
> Errors were encountered while processing:
>  libc-bin
> #
> 
> # ldconfig -v
> Unknown host QEMU_IFLA type: 50
> Unknown host QEMU_IFLA type: 51
> Unknown host QEMU_IFLA type: 50
> Unknown host QEMU_IFLA type: 51
> Unknown host QEMU_IFLA type: 50
> Unknown host QEMU_IFLA type: 51
> Unknown host QEMU_IFLA type: 50
> Unknown host QEMU_IFLA type: 51
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> qemu: uncaught target signal 11 (Segmentation fault) - core dumped
> zsh: segmentation fault  ldconfig -v
> #
> 
> The issue is introduced with --enable-static-pie on -7, downgrading to
> -6 or rebuilding -9 without --enable-static-pie makes the problem go away.

PIE support on arm64 requires at least qemu version 5.0. Please upgrade
your qemu version.

Aurelien

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


signature.asc
Description: PGP signature

Bug#981129: nginx-common: suggested packages are not visible when installing nginx

[Xavier Brochard]

Package: nginx-common
Version: 1.14.2-2+deb10u3
Severity: normal

Dear Maintainer,
While I use Nginx for nearly 5 years now, I never noticed the suggested 
packages in nginx-common. 
I think those packages should be suggested by all of nginx core, extra and 
light versions. 
This is strongly needed by fcgiwrap and ssl-cert which are a requirement when 
using Nginx with some other Debian's packages that require an httpd server with 
cgi, but don't need a heavy one like Apache.

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

   * What led up to the situation?
looking for fcgiwrap in nginx I didn't see it in n
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

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


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

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

Versions of packages nginx-common depends on:
ii  debconf [debconf-2.0]  1.5.71
ii  lsb-base   10.2019051400

nginx-common recommends no packages.

Versions of packages nginx-common suggests:
ii  fcgiwrap   1.1.0-12
ii  nginx-doc  1.14.2-2+deb10u3
ii  ssl-cert   1.0.39

-- Configuration Files:
/etc/nginx/nginx.conf changed [not included]
/etc/nginx/sites-available/default changed [not included]

-- debconf information excluded

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

dolfinx developers appear to be discussing the issue at 
https://github.com/FEniCS/dolfinx/issues/1277

referring to alignment issues with eigen.

Not clear yet where the underlying fault is.

Bug#981104: added missing dependencies to git

[Pirate Praveen]

Control: tags -1 pending

Added these two to Depends,

+ , gstreamer1.0-nice
+ , gstreamer1.0-qt5

gstreamer1.0-qt5 includes qmlgl

Bug#981128: libgmsh4: SIGABRT in dolfinx demo from gmsh polynomialBasis via Eigen::compute_inverse

[Drew Parsons]

Package: libgmsh4
Version: 4.7.1+ds1-2
Severity: normal
Control: affects -1 dolfinx-doc

dolfinx-doc provides some python demos for dolfinx which are tested by
debci. One of the demos tests gmsh. You can see it (demo_gmsh.py) has
been failing in debci, e.g.
https://ci.debian.net/data/autopkgtest/testing/amd64/d/dolfinx/9989408/log.gz
with the error message:

  double free or corruption (out)
  
  Loguru caught a signal: SIGABRT


The SIGABRT is reproducible manually
  # apt-get install python3-dolfinx dolfinx-doc
  $ python3 /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py


gdb gives a detailed backtrace which suggests the problem might come
not from dolfinx but from libgmsh.so.4 in polynomialBasis, or possibly
from eigen in Eigen::internal::compute_inverse

$ gdb python3
(gdb) run /usr/share/dolfinx/demo-python/gmsh/demo_gmsh.py
...
double free or corruption (out)

Thread 1 "python3" received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x77c2a537 in __GI_abort () at abort.c:79
#2  0x77c83768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x77d91e31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x77c8aa5a in malloc_printerr (str=str@entry=0x77d94210 "double 
free or corruption (out)") at malloc.c:5347
#4  0x77c8c088 in _int_free (av=0x77dc3b80 , 
p=0x3df9b90, have_lock=) at malloc.c:4314
#5  0x7fff982dfad8 in 
Eigen::internal::compute_inverse, 0, Eigen::Stride<0, 0> >, Eigen::Map, 0, Eigen::Stride<0, 0> >, -1>::run(Eigen::Map, 0, Eigen::Stride<0, 0> > const&, 
Eigen::Map, 0, Eigen::Stride<0, 0> >&) 
()
   from /lib/x86_64-linux-gnu/libgmsh.so.4.7
#6  0x7fff982e574f in polynomialBasis::polynomialBasis(int) () from 
/lib/x86_64-linux-gnu/libgmsh.so.4.7
#7  0x7fff9824dbca in gmsh::model::mesh::getElementProperties(int, 
std::__cxx11::basic_string, std::allocator 
>&, int&, int&, int&, std::vector >&, int&) () 
from /lib/x86_64-linux-gnu/libgmsh.so.4.7
#8  0x7fff98e07640 in gmshModelMeshGetElementProperties () from 
/lib/x86_64-linux-gnu/libgmsh.so.4.7
#9  0x77fa1d1d in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#10 0x77fa1289 in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
#11 0x7fffb91ce360 in _call_function_pointer (argtypecount=, 
argcount=9, resmem=0x7fffd7a0, restype=, atypes=, avalues=, 
pProc=0x7fff98e075c0 , flags=4353) at 
./Modules/_ctypes/callproc.c:920
#12 _ctypes_callproc (pProc=0x7fff98e075c0 , 
argtuple=, flags=4353, argtypes=, 
restype=<_ctypes.PyCSimpleType at remote 0xbfdaa0>, checker=0x0)
at ./Modules/_ctypes/callproc.c:1263
#13 0x7fffb91c48d8 in PyCFuncPtr_call (self=, 
inargs=, kwds=) at 
./Modules/_ctypes/_ctypes.c:4201
#14 0x0051db9b in _PyObject_MakeTpCall (tstate=0x9632b0, 
callable=<_FuncPtr(__name__='gmshModelMeshGetElementProperties') at remote 
0x7fffb83f41c0>, args=, nargs=, 
keywords=) at ../Objects/call.c:191
#15 0x005178a1 in _PyObject_VectorcallTstate (kwnames=0x0, 
nargsf=, args=0x4562720, 
callable=<_FuncPtr(__name__='gmshModelMeshGetElementProperties') at remote 
0x7fffb83f41c0>, 
tstate=0x9632b0) at ../Include/cpython/abstract.h:116
#16 _PyObject_VectorcallTstate (kwnames=0x0, nargsf=, 
args=0x4562720, 
callable=<_FuncPtr(__name__='gmshModelMeshGetElementProperties') at remote 
0x7fffb83f41c0>, tstate=0x9632b0)
at ../Include/cpython/abstract.h:103
#17 PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0x4562720, 
callable=<_FuncPtr(__name__='gmshModelMeshGetElementProperties') at remote 
0x7fffb83f41c0>) at ../Include/cpython/abstract.h:127
#18 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x9632b0) at ../Python/ceval.c:5072
#19 _PyEval_EvalFrameDefault (tstate=, f=, 
throwflag=) at ../Python/ceval.c:3487
#20 0x00528ee3 in _PyEval_EvalFrame (throwflag=0, 
f=Frame 0x4562560, for file /usr/lib/python3/dist-packages/gmsh.py, line 
2256, in getElementProperties (elementType=, api_elementName_=, 
api_dim_=, api_order_=, api_numNodes_=, 
api_localNodeCoord_=, 
api_localNodeCoord_n_=, 
api_numPrimaryNodes_=, ierr=), tstate=0x9632b0) at ../Include/internal/pycore_ceval.h:40
#21 function_code_fastcall (globals=, nargs=1, args=, co=, tstate=0x9632b0) at ../Objects/call.c:330
#22 _PyFunction_Vectorcall (func=, stack=, 
nargsf=, kwnames=) at ../Objects/call.c:367
#23 0x0051721b in _PyObject_VectorcallTstate (kwnames=0x0, 
nargsf=, args=0x9be108, callable=, tstate=0x9632b0) at ../Include/cpython/abstract.h:118
#24 PyObject_Vectorcall (kwnames=0x0, nargsf=, args=0x9be108, 
callable=) at 
../Include/cpython/abstract.h:127
#25 call_function (kwnames=0x0, oparg=, pp_stack=, tstate=0x9632b0) at ../Python/ceval.c:5072
#26 _PyEval_EvalFrameDefault (tstate=, f=, 
throwflag=) at ../Python/ceval.c:3487
#27 

Bug#981113: ITP: root -- open-source data analysis framework

[Stephan Lachnit]

Package: wnpp
Severity: wishlist
Owner: Stephan Lachnit 
X-Debbugs-Cc: debian-de...@lists.debian.org, stephanlach...@protonmail.com, 
debian-scie...@lists.debian.org

* Package name: root
  Version : 6.22.06
  Upstream Author : CERN 
* URL : https://github.com/root-project/root
* License : LGPL-2.1
  Programming Lang: C++
  Description : open-source data analysis framework

The ROOT system provides a set of OO frameworks with all the functionality
needed to handle and analyze large amounts of data in a very efficient way.
Having the data defined as a set of objects, specialized storage methods are
used to get direct access to the separate attributes of the selected objects,
without having to touch the bulk of the data. Included are histograming methods
in an arbitrary number of dimensions, curve fitting, function evaluation,
minimization, graphics and visualization classes to allow the easy setup of an
analysis system that can query and process the data interactively or in batch
mode, as well as a general parallel processing framework, PROOF, that can
considerably speed up an analysis.
Thanks to the built-in C++ interpreter cling, the command, the scripting and
the programming language are all C++. The interpreter allows for fast
prototyping of the macros since it removes the time consuming compile/link
cycle. It also provides a good environment to learn C++. If more performance is
needed the interactively developed macros can be compiled using a C++ compiler
via a machine independent transparent compiler interface called ACliC.
The system has been designed in such a way that it can query its databases in
parallel on clusters of workstations or many-core machines. ROOT is an open
system that can be dynamically extended by linking external libraries. This
makes ROOT a premier platform on which to build data acquisition, simulation
and data analysis systems.

I want to maintain ROOT in the science team. ROOT was already in Debian as
`root-system` [1], but hasn't been updated since 2015.
I will probably go with a more easy maintainable route like I did with Geant4
for the start and do package splitting later.

[1] https://tracker.debian.org/pkg/root-system

Bug#980480: [pkg-go] Bug#980480: autopkgtest always fail

[Reinhard Tartler]

On Tue, Jan 26, 2021 at 10:44 AM Shengjing Zhu  wrote:

> So for podman, it can either keep this line and drop
> autopkgtest-pkg-go, or write Makefile in a way that autopkgtest-pkg-go
> can recognize.
>

I suppose the issue is around here:
https://salsa.debian.org/go-team/packages/dh-golang/-/blob/21002d72bfeab16a7f86696a585e04aa12803585/script/dh_golang_autopkgtest#L40-45

the issue is that the testsuite is literally invoking debian/rules (with
the options -pRfq), and the `$(info ...)` statement is producing additional
output that confuses the awk script from the debhelper.

I don't see a good solution to that other than
rewriting dh_golang_autopkgtest.

-rt

Bug#981114: nvidia-driver: Fails to display on any monitor change

[Andreas Beckmann]

Hi David,

could you try nvidia-tesla-450-driver 450.102.04-1 from sid?
It is installable along the regular driver and you can switch between
the different drivers with update-glx (and then reboot to load the other
kernel module and libraries).

This is just to check whether the 450 series got "broken" too with the
latest version (which includes a CVE fix).

Thanks

Andreas

PS: If it is still working fine, we might keep the tesla-450 driver in
bullseye along tesla-460.

Bug#981127: cockpit: FTBFS on hppa - test timeout is way too small

[John David Anglin]

Source: cockpit
Version: 236-1
Severity: normal
Tags: patch

Dear Maintainer,

Cockpit fails to build on hppa because the test-tls-certfile test times out.
For example, see this log:
https://buildd.debian.org/status/fetch.php?pkg=cockpit=hppa=236-1=1611676114=0

I had a successful build by extending the timeout from 300 seconds to 3600
seconds.  See:
https://buildd.debian.org/status/fetch.php?pkg=cockpit=hppa=236-1=1611682342=0

Attached is patch that I used.

We either need to skip the test-tls-certfile on hppa or greatly extend the
timeout.  The test spends most of its time in the kernel (maybe there is
lock contention).

Regards,
Dave Anglin

-- System Information:
Debian Release: bullseye/sid
  APT prefers buildd-unstable
  APT policy: (500, 'buildd-unstable'), (500, 'unstable')
Architecture: hppa (parisc64)

Kernel: Linux 5.10.10+ (SMP w/4 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Index: cockpit-236/Makefile.am
===
--- cockpit-236.orig/Makefile.am
+++ cockpit-236/Makefile.am
@@ -279,7 +279,7 @@ AM_CPPFLAGS = \
 AM_LDFLAGS = -Wl,--as-needed
 
 LOG_DRIVER = $(PYTHON) $(top_srcdir)/tools/tap-driver
-LOG_COMPILER = sh -c 'timeout 300 "$$0" "$$@" --tap' # For GLib < 2.62
+LOG_COMPILER = sh -c 'timeout 3600 "$$0" "$$@" --tap' # For GLib < 2.62
 
 TEST_EXTENSIONS = .html .sh
 SH_LOG_DRIVER = $(LOG_DRIVER)
Index: cockpit-236/Makefile.in
===
--- cockpit-236.orig/Makefile.in
+++ cockpit-236/Makefile.in
@@ -2087,7 +2087,7 @@ AM_CPPFLAGS = \
 
 AM_LDFLAGS = -Wl,--as-needed
 LOG_DRIVER = $(PYTHON) $(top_srcdir)/tools/tap-driver
-LOG_COMPILER = sh -c 'timeout 300 "$$0" "$$@" --tap' # For GLib < 2.62
+LOG_COMPILER = sh -c 'timeout 3600 "$$0" "$$@" --tap' # For GLib < 2.62
 TEST_EXTENSIONS = .html .sh
 SH_LOG_DRIVER = $(LOG_DRIVER)
 HTML_LOG_DRIVER = $(LOG_DRIVER)

Bug#978636: move to merged-usr-only?

[Felix Lechner]

Hi,

On Tue, Jan 26, 2021 at 3:45 AM Wouter Verhelst  wrote:
>
> You can start writing a lintian check today

Here is a Lintian check that follows Ansgar's specification in the
second d-d thead. Of course, it will not be merged until the project
works out a suitable consensus on this controversial topic:

https://salsa.debian.org/lintian/lintian/-/merge_requests/349

Thank you!

Kind regards
Felix Lechner

Bug#981055: O: john -- active password cracking tool

[Baptiste Beauplat]

On 2021/01/26 05:15 PM, Axel Beckert wrote:
> Hi Julián,
> 
> cool to hear from you! (Actually didn't expect a that quick reaction. :-)
> 
> Julián Moreno Patiño wrote:
> > I will continue maintaining john the ripper package, but please go
> > ahead with the QA Upload.
> 

Mmm, I should I checked with you first before orphaning the package.
Sorry about that Julián, I'll be more thorough next time :)

-- 
Baptiste Beauplat - lyknode


signature.asc
Description: PGP signature