date:20230227

Source: golang-github-jesseduffield-termbox-go
Version: 0.0~git20180919.1e272ff-2
Severity: serious
X-Debbugs-Cc: z...@debian.org

Fork of golang-github-nsf-termbox-go.
No new development in https://github.com/jesseduffield/termbox-go since 2020.
One reverse-depends golang-github-jesseduffield-gocui (#1032109).

Bug#1032104: linux: ppc64el iouring corrupted read

2023-02-27 Thread Diederik de Haas

On Tuesday, 28 February 2023 04:13:18 CET Daniel Black wrote:
> Source: linux
> Version: 5.10.0-21-powerpc64le
> Severity: grave
> Justification: causes non-serious data loss
> X-Debbugs-Cc: dan...@mariadb.org
> 
> >From https://jira.mariadb.org/browse/MDEV-30728
> 
> MariaDB's mtr tests on a number of specific tests depend on the correct
> kernel operation.
> 
> As observed in these tests, there is a ~1/5 chance the
> encryption.innodb_encryption test will read zeros on the later part of
> the 16k pages that InnoDB uses by default.
> 
> This affects MariaDB-10.6+ packages where there is a liburing in the
> distribution.
> 
> I tested on tmpfs. This is a different fault from bug #1020831 as:
> * there is no iouring error, just a bunch of zeros where data was
>   expected.
> * this is ppc64le only.

What was the last kernel where this problem did NOT occur?
It's probably needed to pinpoint the (upstream) commit that caused this error/
issue and the best start is normally finding the closest range with Debian 
kernel releases where it did not and did occur.

> -- System Information:
> Debian Release: bullseye
>   APT prefers jammy-updates
>   APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500,
> 'jammy'), (100, 'jammy-backports') Architecture: ppc64el (ppc64le)
> 
> Kernel: Linux 5.10.0-21-powerpc64le (SMP w/128 CPU threads)
> Init: unable to detect

Why is there no 'bullseye' in APT policy's output?
Mixing distrubutions (aka FrankenDebian) isn't recommended, but seeing no 
bullseye in there is odd, especially since the kernel version very much does 
look like Debian.

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

Bug#1032113: Don't release with bookworm

Source: golang-github-jesseduffield-roll
Version: 0.0~git20190629.695be2e-3
Severity: serious
X-Debbugs-Cc: z...@debian.org

Fork of golang-github-stvp-roll-
One reverse-depends golang-github-jesseduffield-rollrus (#1032112).

Bug#1032112: Don't release with bookworm

Source: golang-github-jesseduffield-rollrus
Version: 0.0~git20190701.dd028cb-4
Severity: serious
X-Debbugs-Cc: z...@debian.org

Fork of golang-github-heroku-rollrus.
No new development in https://github.com/jesseduffield/rollrus since 2019.
No reverse-depends.

Bug#1032110: Apparmor denies access to /etc/ipsec.secrets.d/

2023-02-27 Thread James Lownie

Version: 5.9.1-1+deb11u3 
Package: strongswan-charon 
Version: 5.9.1-1+deb11u3 
Severity: normal 
X-Debbugs-Cc: none 


Dear maintainer, 

I ran into a problem using Strongswan which looks like a bug to me. I'm not 
sure if its in strongswan-charon or in Apparmor but I fixed it by editing 
/etc/apparmor.d/usr.lib.ipsec.charon which is strongswan-charon code, so I'm 
raising it here first. 

The problem was that when I ran the command 'ipsec rereadsecrets' these 
messages appeared in syslog: 

Feb 28 14:50:41 myhostname charon: 01[CFG] expanding file expression 
'/etc/ipsec.secrets.d/*' failed 
Feb 28 14:50:41 myhostname kernel: [2262128.239395] audit: type=1400 
audit(1677556241.557:15): apparmor="DENIED" operation="open" 
profile="/usr/lib/ipsec/charon" name="/etc/ipsec.secrets.d/" pid=49996 
comm="charon" requested_mask="r" d 
enied_mask="r" fsuid=0 ouid=0 
Feb 28 14:50:41 myhostname kernel: [2262128.239405] audit: type=1400 
audit(1677556241.557:16): apparmor="DENIED" operation="open" 
profile="/usr/lib/ipsec/charon" 
name="/etc/ipsec.secrets.d/99-netier_datacenter.secrets" pid=49996 comm=" 
charon" requested_mask="r" denied_mask="r" fsuid=0 ouid=0 

Incoming connections were then rejected: 

Feb 28 14:46:57 myhostname charon: 14[CFG] selected peer config 'my_sa_name' 
Feb 28 14:46:57 myhostname charon: 14[IKE] no shared key found for 
'192.168.XXX.0' - '192.168.XXX.0' 
Feb 28 14:46:57 fw-cwp-dubbo charon: 14[IKE] received 
ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding 
Feb 28 14:46:57 fw-cwp-dubbo charon: 14[ENC] generating IKE_AUTH response 1 [ 
N(AUTH_FAILED) ] 

I disabled this profile using aa-complain and verified that ipsec could read 
the secrets file and that the connection could be opened. 

I then modified /etc/apparmor.d/usr.lib.ipsec.charon as follows, after which 
IPSec was able to load the secrets file and authenticate incoming connections: 

+ # Site-specific additions and overrides. See local/README for details. 
+ #include  
+ /etc/ipsec.secrets.d/ r, 
+ /etc/ipsec.secrets.d/** r, 

/etc/ipsec.conf r, 
/etc/ipsec.secrets r, 
/etc/ipsec.*.secrets r, 
/etc/ipsec.d/ r, 
/etc/ipsec.d/** r, 
/etc/ipsec.d/crls/* rw, 
/etc/opensc/opensc.conf r, 
/etc/strongswan.conf r, 
/etc/strongswan.d/ r, 
/etc/strongswan.d/** r, 
/etc/tnc_config r, 

/proc/sys/net/core/xfrm_acq_expires w, 

/run/charon.* rw, 
/run/pcscd/pcscd.comm rw, 

/usr/lib/ipsec/charon rmix, 
/usr/lib/ipsec/imcvs/ r, 
/usr/lib/ipsec/imcvs/** rm, 

/usr/lib/*/opensc-pkcs11.so rm, 

/var/lib/strongswan/* r, 

/{,var/}run/systemd/notify w, 

# allow self to read file descriptors (LP #1786250) 
# restrict to our own process-ID as per apparmor vars 
@{PROC}/@{pid}/fd/ r, 

# for using the ha plugin (LP: #1773956) 
@{PROC}/@{pid}/net/ipt_CLUSTERIP/ r, 
@{PROC}/@{pid}/net/ipt_CLUSTERIP/* rw, 

- # Site-specific additions and overrides. See local/README for details. 
- #include  
- /etc/ipsec.secrets.d/ r, 
- /etc/ipsec.secrets.d/** r, 
} 

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

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

Versions of packages strongswan-charon depends on: 
ii debconf [debconf-2.0] 1.5.77 
ii iproute2 5.10.0-4 
ii libc6 2.31-13+deb11u5 
ii libstrongswan 5.9.1-1+deb11u3 
ii strongswan-libcharon 5.9.1-1+deb11u3 
ii strongswan-starter 5.9.1-1+deb11u3 

strongswan-charon recommends no packages. 

strongswan-charon suggests no packages. 

-- Configuration Files: 
/etc/apparmor.d/usr.lib.ipsec.charon changed: 
/usr/lib/ipsec/charon flags=(attach_disconnected) { 
#include  
#include  
#include  
#include  
#include  
capability ipc_lock, 
capability net_admin, 
capability net_raw, 
# allow priv dropping (LP: #1333655) 
capability chown, 
capability setgid, 
capability setuid, 
capability setpcap, 
# libcharon-extra-plugins: xauth-pam 
capability audit_write, 
# libstrongswan-standard-plugins: agent 
capability dac_override, 
network, 
network raw, 
/{,usr/}bin/dash rmPUx, 
# libcharon-extra-plugins: kernel-libipsec 
/dev/net/tun rw, 
# Site-specific additions and overrides. See local/README for details. 
#include  
/etc/ipsec.secrets.d/ r, 
/etc/ipsec.secrets.d/** r, 
/etc/ipsec.conf r, 
/etc/ipsec.secrets r, 
/etc/ipsec.*.secrets r, 
/etc/ipsec.d/ r, 
/etc/ipsec.d/** r, 
/etc/ipsec.d/crls/* rw, 
/etc/opensc/opensc.conf r, 
/etc/strongswan.conf r, 
/etc/strongswan.d/ r, 
/etc/strongswan.d/** r, 
/etc/tnc_config r, 
/proc/sys/net/core/xfrm_acq_expires w, 
/run/charon.* rw, 
/run/pcscd/pcscd.comm rw, 
/usr/lib/ipsec/charon rmix, 
/usr/lib/ipsec/imcvs/ r, 
/usr/lib/ipsec/imcvs/** rm, 
/usr/lib/*/opensc-pkcs11.so rm, 
/var/lib/strongswan/* r, 
/{,var/}run/systemd/notify w, 
# allow self to

Bug#1032111: Don't release with bookworm

Source: golang-github-jesseduffield-pty
Version: 1.1.3+git20191112.07ed706-2
Severity: serious
X-Debbugs-Cc: z...@debian.org

Fork of golang-github-creack-pty.
No new development in https://github.com/jesseduffield/pty since 2019
No reverse-depends.

Bug#1032109: Don't release with bookworm

Source: golang-github-jesseduffield-gocui
Version: 0.3.0+git20190803.ad0cd60-1
Severity: serious
X-Debbugs-Cc: z...@debian.org

Fork of golang-github-jroimartin-gocui.
No reverse-depends.

Bug#1032108: Don't release with bookworm

Source: golang-github-jesseduffield-asciigraph
Version: 0.4.1+git20190605.6d88e39-3
Severity: serious
X-Debbugs-Cc: z...@debian.org

Fork of golang-github-guptarohit-asciigraph
No new development in https://github.com/jesseduffield/asciigraph since 2019
No reverse-depends.

Bug#1032107: Don't release with bookworm

Source: golang-github-jesseduffield-go-getter
Version: 0.0~git20180822.906e156-5
Severity: serious
X-Debbugs-Cc: z...@debian.org


Fork of golang-github-hashicorp-go-getter.
No new development in https://github.com/jesseduffield/go-getter since 2018
No reverse-depends.

Bug#1032106: Don't release with bookworm

Source: golang-github-hashicorp-terraform-plugin-test
Version: 1.3.0+git20200503.328f99a-3
Severity: serious
X-Debbugs-Cc: z...@debian.org


Upstream repo https://github.com/hashicorp/terraform-plugin-test is archived.
No reverse-depends.

Bug#1026126: crosvm update

2023-02-27 Thread Junichi Uekawa



After removing all optional dependencies, crosvm builds with cargo now with 
changes at:

https://github.com/dancerj/crosvm/tree/+wip-debian

Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705

2023-02-27 Thread Amanda Trusted

One more pull request added, thanks to Pavel!

From: Amanda Trusted 
Date: Friday, February 24, 2023 at 6:00 PM
To: Jose M Calhariz , 1029...@bugs.debian.org 
<1029...@bugs.debian.org>
Subject: Re: Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
Thank you Jose!

We added another fix for CVE-2022-37705.

So, here is the updated list.

[0] CVE - 
https://security-tracker.debian.org/tracker/CVE-2022-37704
 
https://www.cve.org/CVERecord?id=CVE-2022-37704
Fixes  - 
https://github.com/zmanda/amanda/pull/197,
https://github.com/zmanda/amanda/pull/202,
https://github.com/zmanda/amanda/pull/203,
https://github.com/zmanda/amanda/pull/205/

[1] CVE - 
https://security-tracker.debian.org/tracker/CVE-2022-37705
 
https://www.cve.org/CVERecord?id=CVE-2022-37705
Fixes - 
https://github.com/zmanda/amanda/pull/196
https://github.com/zmanda/amanda/pull/204/



[2] CVE - 
https://security-tracker.debian.org/tracker/CVE-2022-37703
 
https://www.cve.org/CVERecord?id=CVE-2022-37703
Fix - 
https://github.com/zmanda/amanda/pull/198

Thank you,
AmandaTrusted.

From: Jose M Calhariz 
Date: Friday, February 24, 2023 at 9:43 AM
To: Amanda Trusted , 1029...@bugs.debian.org 
<1029...@bugs.debian.org>
Subject: Re: Bug#1029829: amanda: CVE-2022-37704 CVE-2022-37705
WARNING: This email

Bug#909533: No ability to specify legacy arrays in mdadm.conf to build automatically at boot

2023-02-27 Thread Daniel Baumann

close 909533
thanks

Hi,

thank you for your report.

EFI system partitions (ESP) are partitions with a specific partition
type, regardless of the filesystem within (usually fat32).

Linux MD depends on having the partitions of type Linux raid, so mdadm
cannot be used for this use case.

The "correct" way to mirror your ESPs is to have a grub hook that takes
care of this. Currently, debian doesn't have this out-of-the-box
included in the grub2 packages, but Ubuntu has a 'grub-multi-install'
that takes care of that.

As an alternative to this, if you search the internet, you'll also find
several "rsync hooks" for grub2 to do this in another way.

Regards,
Daniel

Bug#763207: mdadm: kernel segfault related to software RAID5 rebuild

2023-02-27 Thread Daniel Baumann

close 763207
thanks

Hi,

thank you for reporting this.

I second upstreams opinion that there's nothing at the MD layer involved
here. Given that the bugreport is a single issue nobody else reported
and is 9 years old without followups since, I'm closing this bug.

If you can still reproduce the issue with current versions of
everything, please open a new bug.

Regards,
Daniel

Bug#759063: mdadm RAID5 array intermittently stalls during a write operation

2023-02-27 Thread Daniel Baumann

close 759063
thanks

Hi,

thank you for reporting this.

I second upstreams opinion that there's nothing at the MD layer involved
here. Given that the bugreport is a single issue nobody else reported
and is 9 years old without followups since, I'm closing this bug.

If you can still reproduce the issue with current versions of
everything, please open a new bug.

Regards,
Daniel

Bug#1032105: pkg-perl-tools: [dpt prepare] gitddiff shouldn't use last tag but last tag in current branch

2023-02-27 Thread Yadd


On 2/28/23 07:24, Yadd wrote:

Package: pkg-perl-tools
Version: 0.75
Severity: minor

Hi,

thanks for this powerful tool. When using `dpt prepare` on a package
that have backports, it shows the difference with last backport, not
last unstable upload. You can try for example with lemonldap-ng.

In lib/dpt-lib.sh, maybe you could replace

   TAG=$(git rev-list -n1 --tags)

by

   TAG=$(git describe | perl -pe 's/-\d+-\w+$//')


or simply

  TAG=$(git describe --abbrev=0)

Bug#1032105: pkg-perl-tools: [dpt prepare] gitddiff shouldn't use last tag but last tag in current branch

2023-02-27 Thread Yadd

Package: pkg-perl-tools
Version: 0.75
Severity: minor

Hi,

thanks for this powerful tool. When using `dpt prepare` on a package
that have backports, it shows the difference with last backport, not
last unstable upload. You can try for example with lemonldap-ng.

In lib/dpt-lib.sh, maybe you could replace

  TAG=$(git rev-list -n1 --tags)

by

  TAG=$(git describe | perl -pe 's/-\d+-\w+$//')

Cheers,
Yadd

Bug#1028725: flycheck: FTBFS: make: *** [debian/rules:4: binary] Error 25

2023-02-27 Thread Sergio Durigan Junior

On Monday, February 27 2023, David Bremner wrote:

> Sergio Durigan Junior  writes:
>>
>> I was testing with an upstream build.  For Debian's Emacs, we should
>> use:
>>
>>   buttercup --eval "(setq comp-enable-subr-trampolines nil)" -L .
>>
>
> Did you get that working with the upstream version currently in master
> or with a new upstream snapshot? I tried cherry picking 8379be91 but it
> seemed not to be enough (there was a bunch of conflicts, so maybe I
> missed something).

I backported 8379be91, and it needed manual adjustments to apply
cleanly.  After that, it was enough to solve the other two failures.

Here's the full diff.  If you're OK with it I can upload the package.

-- 
Sergio
GPG key ID: 237A 54B1 0287 28BF 00EF  31F4 D0EB 7628 65FC 5E36
Please send encrypted e-mail if possible
https://sergiodj.net/

diff --git a/debian/changelog b/debian/changelog
index cd3ad07b..30f802ea 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,14 @@
+flycheck (32-2) unstable; urgency=medium
+
+  * Team upload.
+  * d/p/fix-buttercup-tests-on-emacs-28.patch: Adjust tests for Emacs 28.
+  * d/rules: Invoke buttercup disabling subr-trampolines.
+Workaround issue described at
+https://github.com/jorgenschaefer/emacs-buttercup/issues/230.
+(Closes: #1028725)
+
+ -- Sergio Durigan Junior   Mon, 27 Feb 2023 22:17:21 
-0500
+
 flycheck (32-1) unstable; urgency=medium
 
   * new upstream release
diff --git a/debian/patches/fix-buttercup-tests-on-emacs-28.patch 
b/debian/patches/fix-buttercup-tests-on-emacs-28.patch
new file mode 100644
index ..c41e7bff
--- /dev/null
+++ b/debian/patches/fix-buttercup-tests-on-emacs-28.patch
@@ -0,0 +1,58 @@
+From: Philipp Stephani 
+Date: Mon, 6 Dec 2021 16:55:24 +0100
+Subject: Fix Buttercup tests on Emacs 28.
+MIME-Version: 1.0
+Content-Type: text/plain; charset="utf-8"
+Content-Transfer-Encoding: 8bit
+
+- On Emacs 28, Checkdoc has a new customization option
+  ‘checkdoc-column-zero-backslash-before-paren’.
+
+- The header line format is slightly different.
+
+Origin: backport, 
https://github.com/flycheck/flycheck/commit/8fefc5079107cd8f047f2f6cf6e22ff6772a90fe
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028725
+---
+ flycheck.el   | 6 --
+ test/specs/test-error-list.el | 4 +++-
+ 2 files changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/flycheck.el b/flycheck.el
+index a1298fe..19847dc 100644
+--- a/flycheck.el
 b/flycheck.el
+@@ -8519,7 +8519,7 @@ See Info Node `(elisp)Byte Compilation'."
+ (kill-buffer)))
+ 
+ (defconst flycheck-emacs-lisp-checkdoc-variables
+-  '(checkdoc-symbol-words
++  `(checkdoc-symbol-words
+ checkdoc-arguments-in-order-flag
+ checkdoc-force-history-flag
+ checkdoc-permit-comma-termination-flag
+@@ -8528,7 +8528,9 @@ See Info Node `(elisp)Byte Compilation'."
+ checkdoc-spellcheck-documentation-flag
+ checkdoc-verb-check-experimental-flag
+ checkdoc-max-keyref-before-warn
+-sentence-end-double-space)
++sentence-end-double-space
++,@(and (>= emacs-major-version 28)
++   '(checkdoc-column-zero-backslash-before-paren)))
+   "Variables inherited by the checkdoc subprocess.")
+ 
+ (defun flycheck-emacs-lisp-checkdoc-variables-form ()
+diff --git a/test/specs/test-error-list.el b/test/specs/test-error-list.el
+index 70f132a..226e235 100644
+--- a/test/specs/test-error-list.el
 b/test/specs/test-error-list.el
+@@ -67,7 +67,9 @@
+ (it "has a local header line"
+   (flycheck/with-error-list-buffer
+ (expect header-line-format
+-:to-equal " File  Line Col Level ID Message (Checker) ")
++:to-equal (if (< emacs-major-version 28)
++  " File  Line Col Level ID Message (Checker) "
++" File Line ▼ Col Level ID Message (Checker) "))
+ (expect 'header-line-format :to-be-local
+ 
+   (describe "Columns"
diff --git a/debian/patches/series b/debian/patches/series
index 6603290d..6d1290ed 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -6,3 +6,4 @@ skip-rpmlint-test.patch
 skip-flaky-tests.patch
 python3-in-test.patch
 skip-truncated-stdin-tests.patch
+fix-buttercup-tests-on-emacs-28.patch
diff --git a/debian/rules b/debian/rules
index f298da1f..7e12c97f 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,11 @@ override_dh_installchangelogs:
 override_dh_auto_build:
( cd doc && make OFFLINE=yes html )
 
+# Temporary workaround for
+# https://github.com/jorgenschaefer/emacs-buttercup/issues/230
+override_dh_elpa_test:
+   buttercup --eval '(setq comp-enable-subr-trampolines nil)' -L .
+
 # The file flycheck.html in the _downloads subdir is generated from
 # the old texinfo manual, which is deprecated by upstream.  Don't
 # install it as parts could be out-of-date


signature.asc
Description: PGP signature

Bug#1032104: linux: ppc64el iouring corrupted read

2023-02-27 Thread Daniel Black

Source: linux
Version: 5.10.0-21-powerpc64le
Severity: grave
Justification: causes non-serious data loss
X-Debbugs-Cc: dan...@mariadb.org

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 ***

>From https://jira.mariadb.org/browse/MDEV-30728

MariaDB's mtr tests on a number of specific tests depend on the correct
kernel operation.

As observed in these tests, there is a ~1/5 chance the
encryption.innodb_encryption test will read zeros on the later part of
the 16k pages that InnoDB uses by default.

This affects MariaDB-10.6+ packages where there is a liburing in the
distribution.

This has been observed in the CI of Debian
(https://ci.debian.net/packages/m/mariadb/testing/ppc64el/)
and upstreams https://buildbot.mariadb.org/#/builders/318.
The one ppc64le worker that has the Debian 5.10.0-21 kernel,
the same as the Debian CI, has the prefix ppc64le-db-bbw1-*.

Test faults occur on all MariaDB 10.6+ builds in containers on this kernel.
There a no faults on non-ppc64le or RHEL7/8 based ppc64le kernels.

To reproduce:

apt-get install mariadb-test
cd /usr/share/mysql/mysql-test
./mtr --mysqld=--innodb-flush-method=fsync --mysqld=--innodb-use-native-aio=1 
--vardir=/var/lib/mysql  --force encryption.innodb_encryption,innodb,undo0 
--repeat=12 

A test will frequenty fail.

2023-02-28  1:41:01 0 [ERROR] InnoDB: Database page corruption on disk or a 
failed read of file './ibdata1' page [page id: space=0, page number=282]. You 
may have to recover from a backup.

(the page number isn't predictable)

The complete mtr error log of mariadb server is $PWD/var/log/mysqld.1.err

I tested on tmpfs. This is a different fault from bug #1020831 as:
* there is no iouring error, just a bunch of zeros where data was
  expected.
* this is ppc64le only.

Note, more serious faults exist on overlayfs (MDEV-28751) and remote
filesystems so sticking to local xfs, ext4, btrfs is recommended.

-- System Information:
Debian Release: bullseye
  APT prefers jammy-updates
  APT policy: (500, 'jammy-updates'), (500, 'jammy-security'), (500, 'jammy'), 
(100, 'jammy-backports')
Architecture: ppc64el (ppc64le)

Kernel: Linux 5.10.0-21-powerpc64le (SMP w/128 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: unable to detect

Bug#1030545: qemu: qemu-img and qemu-system-s390x hang on s390x

Source: qemu
Followup-For: Bug #1030545
Control: block -1 by 1031753

Bug#1032013: Handling of -e violates policy for x-terminal-emulator

2023-02-27 Thread John Crawley


Hello Louis-Philippe,
thank you for fixing the bug.
As far as I can tell, the -e option is now handled correctly by terminator when 
invoked as x-terminal-emulator.

Just for the record, I may be misunderstanding the Debian Policy [1], but:
1) neither -c nor --execute are mentioned, only -e.
2) command lines like
x-terminal-emulator -e 'if this; then that; fi'
*should not* work, any more than 'if this; then that; fi' would work in an 
actual terminal.
The outer quotes would make the whole line into a single argument, but an 
executable is required as the first word. Such commands do work on some 
terminals, but I don't think Debian Policy expects that:

" may be *multiple* arguments, which form the argument list to the executed 
program"

So this should work (and now does):
x-terminal-emulator -e sh -c 'if this; then that; fi'

Thanks again!

[1] 
https://www.debian.org/doc/debian-policy/ch-customized-programs.html#packages-providing-a-terminal-emulator
--
John

Bug#1028743: python-bottle: FTBFS: AssertionError: b'OK' != "URLError(ConnectionRefusedError(111, 'Connection refused'))"

Source: python-bottle
Followup-For: Bug #1028743
Control: forwarded -1 https://github.com/bottlepy/bottle/issues/1410

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

Package: nodejs
Followup-For: Bug #1030284
X-Debbugs-Cc: t...@debian.org

> My plan is to rebuild / retest reverse deps before hard freeze.

That's a good plan.

Do you know whether any of those tests include cases that spin up large (as in:
may consume more than 50% of a system's memory) numbers of processes/threads?

Context: I've begun worrying about the additional overhead from stack
preallocation -- where increasing the stack size might significantly reduce the
number of processes that fit in memory while running simultaneously.

> Thanks, I'll welcome any patch to start with.

FWIW: I am still somewhere between 'do nothing' and 'ok, maybe, after seeing
more data that it is a safe increase'.

I don't trust myself enough to write any logic/syscall-related changes in a
patch but may provide one that updates the constant limits in the relevant
header file(s).

Thorsten: if you'd like an rlimit-based approach then I think that may be upon
you to write, or to request from upstream (where I accidentally impersonated
you on the GitHub issue, by the way - sorry about that!).

Bug#1032103: logwatch misses (filters) failed systemd services if unit type is 'simple'

2023-02-27 Thread Timo Sigurdsson

Package: logwatch
Version: 7.5.5-1
Severity: important

Dear Maintainer,

I recently discovered that logwatch did not report a systemd service 
(snapper-timeline.service) that failed repeatedly on my system. Looking through 
the script
/usr/share/logwatch/scripts/services/systemd
I determined that the reason for this is that the script makes wrong 
assumptions about what the log entries should look like - or assumptions that 
don't apply to a service of the type 'simple'.

The comments within the script explain the logic:
> # Failure will generate multiple messages like:
> # Feb  5 16:37:50 hostname systemd: ansible-pull.service: main process 
> exited, code=exited, status=2/INVALIDARGUMENT
> # Feb  5 16:37:50 hostname systemd: Failed to start Run ansible-pull on boot.
> # Feb  5 16:37:50 hostname systemd: Unit ansible-pull.service entered failed 
> state.
> # Feb  5 16:37:50 hostname systemd: ansible-pull.service failed.

and a few lines further down:
> # These events will be caught with the Unit X entered failed state message

So, everything other than "Unit {} entered failed state." will be ignored.

The problem here is that type simple services will not trigger this log message 
when they fail, see this example:

$ journalctl -u snapper-timeline.service -S 2023-02-16 -U 2023-02-17
-- Journal begins at Fri 2022-12-02 07:02:42 CET, ends at Tue 2023-02-28 
01:24:53 CET. --
Feb 16 03:05:29 HomeSrv systemd[1]: Started Timeline of Snapper Snapshots.
Feb 16 03:05:43 HomeSrv systemd-helper[2690]: running timeline for 'archive'.
Feb 16 03:05:44 HomeSrv systemd-helper[2690]: running timeline for 'documents'.
Feb 16 03:05:44 HomeSrv systemd-helper[2690]: running timeline for 'home'.
Feb 16 03:05:44 HomeSrv systemd-helper[2690]: running timeline for 'photos'.
Feb 16 03:05:44 HomeSrv systemd-helper[2690]: IO Error (.snapshots is not a 
btrfs subvolume).
Feb 16 03:05:44 HomeSrv systemd-helper[2690]: timeline for 'photos' failed.
Feb 16 03:05:44 HomeSrv systemd-helper[2690]: running timeline for 'root'.
Feb 16 03:05:45 HomeSrv systemd[1]: snapper-timeline.service: Main process 
exited, code=exited, status=1/FAILURE
Feb 16 03:05:45 HomeSrv systemd[1]: snapper-timeline.service: Failed with 
result 'exit-code'.

As the log message "Unit {} entered failed state." doesn't appear here, the 
failure of the unit is never reported by logwatch (snapper-timeline.service, in 
this example, is a simple service). I would have expected logwatch would catch 
such failures and report them and I think the script should be changed to look 
for messages that actually appear for all unit types in case of failure.


Thanks and regards,

Timo


-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (400, 'proposed-updates')
Architecture: amd64 (x86_64)

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

Versions of packages logwatch depends on:
ii  msmtp-mta [mail-transport-agent]  1.8.11-2.1
ii  perl  5.32.1-4+deb11u2

Versions of packages logwatch recommends:
ii  libdate-manip-perl   6.83-1
ii  libsys-cpu-perl  0.61-2+b6
ii  libsys-meminfo-perl  0.99-1+b5

logwatch suggests no packages.

-- no debconf information
Thank you for using reportbug

Bug#1028725: flycheck: FTBFS: make: *** [debian/rules:4: binary] Error 25

2023-02-27 Thread David Bremner

Sergio Durigan Junior  writes:
>
> I was testing with an upstream build.  For Debian's Emacs, we should
> use:
>
>   buttercup --eval "(setq comp-enable-subr-trampolines nil)" -L .
>

Did you get that working with the upstream version currently in master
or with a new upstream snapshot? I tried cherry picking 8379be91 but it
seemed not to be enough (there was a bunch of conflicts, so maybe I
missed something).

d

Bug#1031697: Info received (Bug#1031697 closed by Debian FTP Masters (reply to Timo Aaltonen ) (Bug#1031697: fixed in libx11 2:1.8.4-1))

2023-02-27 Thread Safir Secerovic

Dear Debian Developer,

I can confirm that the bug has been resolved with the 1.8.4-2 release of
libx11.

Thank You so much for everything.
Safir

On Mon, Feb 27, 2023 at 10:30 AM Debian Bug Tracking System <
ow...@bugs.debian.org> wrote:

> Thank you for the additional information you have supplied regarding
> this Bug report.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> Your message has been sent to the package maintainer(s):
>  Debian X Strike Force 
>
> If you wish to submit further information on this problem, please
> send it to 1031...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 1031697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031697
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
>

Bug#1012682: argon2: New upstream version available

2023-02-27 Thread Bastian Germann


X-Debbugs-Cc: ond...@debian.org

On Sat, 11 Jun 2022 19:15:10 +0200 Bastian Germann wrote:

Please import the new upstream version 20190702 that installs the pkg-config 
file,
which enables dropping d/rules' workaround for it.


Ondřej, I see you have imported the new upstream version in git but did not 
proceed with a NMU.
Do you want to finish it or did you see any problems with it?

Bug#1032084: gourmand: Missing dependency to python3-extruct

2023-02-27 Thread Christian Marillat

reassign 1032084 python3-recipe-scrapers
found 1032084 14.32.0-1
notfound 1032084 14.32.1-1
thanks

On 27 févr. 2023 20:01, "Jack.R"  wrote:

> Package: gourmand
> Version: 1.1.0+really1.1.0~rc3-2
> Severity: normal
>
> Dear Maintainer,

Hello,

> After apt-get dist-upgrade in order to upgrade Gourmand:
>   Dépaquetage de gourmand (1.1.0+really1.1.0~rc3-2) sur (1.1.0+really1.0.0-3) 
> ...
> it failed to start.

[...]

> ModuleNotFoundError: No module named 'extruct'
>
> This suggest a missing dependency to python3-extruct. 
> I install it and now Gourmand start properly.

The problem come from the python3-recipe-scrapers package.

Already fixed in 14.32.1-1

Christian

Bug#1030284: [Pkg-javascript-devel] Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

2023-02-27 Thread Jérémy Lal

Le mar. 28 févr. 2023 à 00:33, James Addison  a écrit :

> Package: nodejs
> Followup-For: Bug #1030284
> X-Debbugs-Cc: t...@debian.org,
> reply+aagshfqluldiwi3obwdg6lgb7if7fevbnhheauz...@reply.github.com
>
> mirabilos gesagt:
>
> > We know the default ulimits for users in Debian, and they are higher
> > than the 1 MiB assumed by v8, by quite some factor, so this won’t break
> > things which are not currently broken (by that exception). This will do
> > for the release I think.
>
> Relaying my understanding of this, so far:
>
> An increase in the V8 stack size should not cause earlier-process-exits
> for any
> processes that previously ran on Debian systems where the
> architecture-default-or-greater stack size is configured[1].
>
> In other words: the same-number-or-greater of JavaScript processes should
> continue to run on any given Debian system where the configured stack size
> is
> greater-than-or-equal to the architecture's default, after the V8 stack
> size
> limit is increased.
>
> And we expect that it should repair a failing reproducible build test for
> at
> least one Debian package on arm64.


Thanks, I'll welcome any patch to start with.
My plan is to rebuild / retest reverse deps before hard freeze.

Bug#1032102: argon2: Please use https URL for d/copyright Format

2023-02-27 Thread Bastian Germann


Source: argon2
Version: 0~20171227-0.3
Severity: minor

Please use https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
in the Format field of debian/copyright.

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

Package: nodejs
Followup-For: Bug #1030284
X-Debbugs-Cc: t...@debian.org, 
reply+aagshfqluldiwi3obwdg6lgb7if7fevbnhheauz...@reply.github.com

mirabilos gesagt:

> We know the default ulimits for users in Debian, and they are higher
> than the 1 MiB assumed by v8, by quite some factor, so this won’t break
> things which are not currently broken (by that exception). This will do
> for the release I think.

Relaying my understanding of this, so far:

An increase in the V8 stack size should not cause earlier-process-exits for any
processes that previously ran on Debian systems where the
architecture-default-or-greater stack size is configured[1].

In other words: the same-number-or-greater of JavaScript processes should
continue to run on any given Debian system where the configured stack size is
greater-than-or-equal to the architecture's default, after the V8 stack size
limit is increased.

And we expect that it should repair a failing reproducible build test for at
least one Debian package on arm64.

[1] - see limits.conf

Bug#1030511: Apparent s390x kernel bug

2023-02-27 Thread Hilko Bengen

Control: tags -1 + pending
Control: block -1 by 1031753

The hangs manifest in qemu-img, but according to #1030545, the root
cause seems to be an s390x-specific kernel bug which has been described
in #1031753.

Bug#1031923: d-i.debian.org: testing (bookworm): Unable to boot due to unsupported FEATURE_C12 in e2fsck

2023-02-27 Thread Cyril Brulebois

Hi,

Cesar Enrique Garcia Dabo  (2023-02-27):
> Thank you for the answer. Good to know that it is a known issue and is being
> taken care of.
> 
> Regarding why I took that image. I just followed the official Debian
> webpages:
> 
> https://www.debian.org/CD/http-ftp/index.en.html

Many thanks for the follow-up…

> From there I clicked on "Official CD/DVD images of the "testing"
> distribution (/regenerated weekly/)
> "
> 
> https://cdimage.debian.org/cdimage/weekly-builds/ -> amd64 -> iso-cd -> 
> https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso
> 
> So from my perspective I wasn't using a "random" image, but rather an
> official one, as the web pages indicate.

… now I understand what you went through.

Unfortunately, I wasn't aware of those instructions, and that looks utterly
buggy. How can we claim to publish “official images” that are snapshots, built
using debian-installer daily builds, that can be broken by random packages in
unstable, and left unfixed for weeks?!

We already have specific instructions on the d-i page[1] regarding
*actual* official releases (as soon as testing gets an Alpha 1), plus
snapshots. My first instinct would be to entirely scrap testing-related
things from the page you started from[2], and just redirect to [1]
instead.

 1. https://www.debian.org/devel/debian-installer/
 2. https://www.debian.org/CD/http-ftp/


That link should be updated too… http://debian-cd.debian.net/


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Bug#1030851: bullseye-pu: package symfony/4.4.19+dfsg-2+deb11u2

2023-02-27 Thread David Prévot


Hi,

Le 27/02/2023 à 08:18, David Prévot a écrit :

Le 26/02/2023 à 21:54, Paul Gevers a écrit :

On 08-02-2023 13:53, David Prévot wrote:

[ Tests ]
I didn’t test it thoroughly (I doubt to have much time for at least
another week), but it passes


There are issues with the installability of src:symfony packages as 
can be seen from the autopkgtests [1]:


Thank you for the heads up! Shame on me for not checking thoroughly the 
autotest result

[…]
I’ll look at it ASAP […] and provide an 
updated version with an update to this bug report.


I’ve uploaded symfony/4.4.19+dfsg-2+deb11u3 without the dependency bump, 
debdiff against 4.4.19+dfsg-2+deb11u2 attached.


Regards

taffit
diff --git a/debian/changelog b/debian/changelog
index 3f054d84ec..8aac84e7c5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+symfony (4.4.19+dfsg-2+deb11u3) bullseye; urgency=medium
+
+  * Drop dependency bump.
+Thanks to Paul Gevers 
+
+ -- David Prévot   Mon, 27 Feb 2023 23:05:34 +0100
+
 symfony (4.4.19+dfsg-2+deb11u2) bullseye; urgency=medium
 
   * Backport security fixes from Symfony 4.4.50
diff --git a/debian/patches/Security-Http-Remove-CSRF-tokens-from-storage-on-successf.patch b/debian/patches/Security-Http-Remove-CSRF-tokens-from-storage-on-successf.patch
index 27842fb9a3..e61a2160e4 100644
--- a/debian/patches/Security-Http-Remove-CSRF-tokens-from-storage-on-successf.patch
+++ b/debian/patches/Security-Http-Remove-CSRF-tokens-from-storage-on-successf.patch
@@ -8,10 +8,9 @@ Origin: backport, https://github.com/symfony/symfony/commit/c75c5699f02da5ebb92c
  .../Bundle/SecurityBundle/Resources/config/security.xml|  1 +
  .../SecurityBundle/Tests/Functional/CsrfFormLoginTest.php  |  6 ++
  .../Bundle/SecurityBundle/Tests/Functional/LogoutTest.php  |  4 +---
- src/Symfony/Bundle/SecurityBundle/composer.json|  2 +-
  .../Http/Session/SessionAuthenticationStrategy.php | 14 +++---
  .../Tests/Session/SessionAuthenticationStrategyTest.php| 13 +
- 6 files changed, 33 insertions(+), 7 deletions(-)
+ 5 files changed, 32 insertions(+), 6 deletions(-)
 
 diff --git a/src/Symfony/Bundle/SecurityBundle/Resources/config/security.xml b/src/Symfony/Bundle/SecurityBundle/Resources/config/security.xml
 index 3491383..eabe5e5 100644
@@ -81,19 +80,6 @@ index cb7868f..465027f 100644
  
  $client->request('GET', '/logout');
  
-diff --git a/src/Symfony/Bundle/SecurityBundle/composer.json b/src/Symfony/Bundle/SecurityBundle/composer.json
-index 872ef66..6627cdb 100644
 a/src/Symfony/Bundle/SecurityBundle/composer.json
-+++ b/src/Symfony/Bundle/SecurityBundle/composer.json
-@@ -24,7 +24,7 @@
- "symfony/security-core": "^4.4",
- "symfony/security-csrf": "^4.2|^5.0",
- "symfony/security-guard": "^4.2|^5.0",
--"symfony/security-http": "^4.4.5"
-+"symfony/security-http": "^4.4.50"
- },
- "require-dev": {
- "doctrine/doctrine-bundle": "^1.5|^2.0",
 diff --git a/src/Symfony/Component/Security/Http/Session/SessionAuthenticationStrategy.php b/src/Symfony/Component/Security/Http/Session/SessionAuthenticationStrategy.php
 index a4bb888..7369105 100644
 --- a/src/Symfony/Component/Security/Http/Session/SessionAuthenticationStrategy.php

Bug#1029231: curl_multi_socket_action is broken in curl 7.87 (and 7.74.0-1.3+deb11u5)

2023-02-27 Thread Samuel Henrique

> Apologies, this is a duplicate of bug 1029231 and it seems like curl
> 7.88 is intended to move to testing?

That's right, the fix should migrate to testing in around 3 days (and
it's live on stable-security).

I appreciate all the bug reports we've got, so thank you Syldra, Marc
and Malte :)

Cheers,

-- 
Samuel Henrique

Bug#1031923: d-i.debian.org: testing (bookworm): Unable to boot due to unsupported FEATURE_C12 in e2fsck

2023-02-27 Thread Cesar Enrique Garcia Dabo

Thank you for the answer. Good to know that it is a known issue and is
being taken care of.

Regarding why I took that image. I just followed the official Debian
webpages:

https://www.debian.org/CD/http-ftp/index.en.html

From there I clicked on "Official CD/DVD images of the "testing"
distribution (/regenerated weekly/)
"

https://cdimage.debian.org/cdimage/weekly-builds/ -> amd64 -> iso-cd ->
https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-amd64-netinst.iso

So from my perspective I wasn't using a "random" image, but rather an
official one, as the web pages indicate.

Best regards,

Hi,

Andrew, please use reply-all, to reply to the bug and to the bug
submitter. A list-only reply doesn't quite help…

Andrew M.A. Cater (2023-02-25):

I have installed Debian testing (bookworm) from one of the latest ISO images
(https://cdimage.debian.org/cdimage/weekly-builds/amd64/iso-cd/debian-testing-
amd64-netinst.iso from 2023-02-21) and after an apparently succesfull
installation the system cannot be booted.

Enrique, thanks for the report.

We've published an official release one week ago. I'm not sure why
you're not using that instead of a random weekly build.

This is a known issue - try using the Alpha 2 installer in which this
issue is not present.

The e2fsprogs mismatch with grub is likely to be fixed by reverting
problematic versions.

No, the problem here is that e2fsck is from testing, while the
filesystem has been created by mke2fs from unstable, and the former
doesn't know about a new feature turned on by the latter.

Cheers,

Bug#1032101: libheif: CVE-2023-0996

Source: libheif
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for libheif.

CVE-2023-0996[0]:
| There is a vulnerability in the strided image data parsing code in the
| emscripten wrapper for libheif. An attacker could exploit this through
| a crafted image file to cause a buffer overflow in linear memory
| during a memcpy call.

https://github.com/strukturag/libheif/pull/759
https://govtech-csg.github.io/security-advisories/2023/02/24/CVE-2023-0996.html


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-0996
https://www.cve.org/CVERecord?id=CVE-2023-0996

Please adjust the affected versions in the BTS as needed.

Bug#1032100: golang-github-hashicorp-go-getter: CVE-2023-0475

Source: golang-github-hashicorp-go-getter
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for golang-github-hashicorp-go-getter.

CVE-2023-0475[0]:
| HashiCorp go-getter up to 1.6.2 and 2.1.1 is vulnerable to
| decompression bombs. Fixed in 1.7.0 and 2.2.0.

https://discuss.hashicorp.com/t/hcsec-2023-4-go-getter-vulnerable-to-denial-of-service-via-malicious-compressed-archive/50125

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-0475
https://www.cve.org/CVERecord?id=CVE-2023-0475

Please adjust the affected versions in the BTS as needed.

Bug#1032099: libpod: CVE-2023-0778

Source: libpod
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libpod.

CVE-2023-0778[0]:
https://bugzilla.redhat.com/show_bug.cgi?id=2168256
https://github.com/containers/podman/commit/6ca857feb07a5fdc96fd947afef03916291673d8


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2023-0778
https://www.cve.org/CVERecord?id=CVE-2023-0778

Please adjust the affected versions in the BTS as needed.

Bug#1026961: openconnect: fails to restore previous network configuration

2023-02-27 Thread Francesco Poli

On Sat, 25 Feb 2023 18:48:30 + Luca Boccassi wrote:

[...]
> On Sat, 24 Dec 2022 19:36:39 +0100 "Francesco Poli (wintermute)"
>  wrote:
[...]
> > At the end of the session, I expected openconnect to automatically
> > restore the network configuration as it had found it at the beginning
> > of the session.
[...]
> > Please fix this issue and/or forward this bug report upstream, as
> > appropriate.
> 
> Please report this upstream

Dear Luca,
I tried, but it seems that I would need to create a gitlab.com account
just to report this bug.

You probably already have an account there: could you please be so kind
and forward my bug report upstream, instead of closing it?

Doing so would have a number of advantages: you could tag this bug
report as forwarded and it would keep track of the upstream bug status;
moreover, keeping my Debian bug report open (until a fix has landed in
Debian) would inform other Debian users that the bug is already known,
thus avoiding that other Debian bug reports are filed in the future
about the same issue...

I hope you agree with my reasoning.

Bye and thanks for your time and patience.

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

pgpECDww1b7fg.pgp
Description: PGP signature

Bug#1032098: feh: remove unneeded(?) dependency on yudit-common?

2023-02-27 Thread Adrian

Package: feh
Severity: minor
X-Debbugs-Cc: solarsh...@gmail.com

Dear Maintainer,

Why does a tiny package like feh depend on a large, seemingly-unrelated
one like yudit-common?

As far as I can see, it's a debian-specific thing added in Feb 2018 with
package version 2.23.2-1: "Use yudit.ttf from yudit-common package"; but
I can't find any reason for the change? Why the new dep? Why that
package specifically instead of some generic font package?

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

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

Versions of packages feh depends on:
ii  libc6 2.31-13+deb11u5
ii  libcurl4  7.74.0-1.3+deb11u5
ii  libexif12 0.6.22-3
ii  libimlib2 1.7.1-2
ii  libpng16-16   1.6.37-3
ii  libx11-6  2:1.7.2-1
ii  libxinerama1  2:1.1.4-2
pn  yudit-common  

Versions of packages feh recommends:
ii  libjpeg-turbo-progs [libjpeg-progs]  1:2.0.6-4

feh suggests no packages.

Bug#1032097: ITP: libpromise-xs-perl -- Fast promises in Perl

2023-02-27 Thread Alexander Zangerl

Package: wnpp
Severity: wishlist
Owner: Alexander Zangerl 
X-Debbugs-Cc: debian-de...@lists.debian.org

* Package name: libpromise-xs-perl
  Version : 0.18
  Upstream Author : Tom van der Woerdt , Felipe 
Gasper https://metacpan.org/release/Promise-XS
* License : Artistic
  Programming Lang: Perl, C
  Description : Fast promises in Perl

This module provides a Promises/A+ interface with its
major parts implemented in XS for speed. It is a fork
and refactor of AnyEvent::XSPromises, and retains that module's
bare-bones interface.

This is one of a few Promises implementations in perl, none of
which have made it into debian yet. i think it's time to change
that.

Bug#1032096: jsurf-alggeo: Autopkgtest failure on armel

2023-02-27 Thread Vladimir Petko

Source: jsurf-alggeo
Version: 0.4.1+ds-3
Severity: normal
X-Debbugs-Cc: vladimir.pe...@canonical.com

Dear Maintainer,

The package fails make-TestJSurf test due to the race condition
de.mfo.jsurf.test.TestJSurf creates a SwingWorker, waits 100 milliseconds,
attempts to cancel rendering tasks in stopDrawingMethod() and then asserts that
time after swing worker creation has not exceeded 200 msec. This is a flaky
assertion that depends on the host machine's performance.
See related log [1].

Would it be possible to consider a patch that retries stopDrawing() and
asserts that the rendering was interrupted instead?
Thank you for considering the patch!

[1] https://ci.debian.net/data/autopkgtest/unstable/armel/j/jsurf-
alggeo/31633915/log.gz
diff --git a/src/test/java/de/mfo/jsurf/test/TestJSurf.java b/src/test/java/de/mfo/jsurf/test/TestJSurf.java
index 4f83c0f..8b93a3f 100644
--- a/src/test/java/de/mfo/jsurf/test/TestJSurf.java
+++ b/src/test/java/de/mfo/jsurf/test/TestJSurf.java
@@ -8,6 +8,10 @@ import de.mfo.jsurf.algebra.*;
 import de.mfo.jsurf.parser.*;
 import de.mfo.jsurf.util.FileFormat;
 import java.util.Properties;
+import java.util.concurrent.TimeoutException;
+import java.util.concurrent.ExecutionException;
+import java.util.concurrent.TimeUnit;
+
 import javax.swing.SwingWorker;
 
 public class TestJSurf
@@ -27,6 +31,8 @@ public class TestJSurf
 
 		class BackgroundRenderer extends SwingWorker< Void, Void >
 		{
+			public boolean interrupted = false;
+
 		   @Override
 		   public Void doInBackground() {
 		   		try {
@@ -35,6 +41,7 @@ public class TestJSurf
 		   		catch( RenderingInterruptedException rie )
 		   		{
 		   			System.out.println( "Rendering interrupted" );
+	interrupted = true;
 		   		}
 			return null;
 		   }
@@ -45,16 +52,23 @@ public class TestJSurf
 		br.execute();
 
 	long t = System.currentTimeMillis();
-	Thread.sleep( 100 );
-
 		System.out.println( "Attempting to stop rendering" );
-	asr.stopDrawing();
+		for (int i = 0; i < 100; ) {
+			try
+			{
+asr.stopDrawing();
+br.get(100, TimeUnit.MILLISECONDS);
+break;
+			}
+			catch (InterruptedException e) {}
+			catch (ExecutionException e) {}
+			catch (TimeoutException e) {}
+		}
 
-	br.get();
 	t = System.currentTimeMillis() - t;
 	System.out.println( "Render method finished after " + t + "ms" );
 
-		Assert.assertTrue( "stopDrawing must interrupt and stop the rendering process", t < 200 );
+		Assert.assertTrue( "stopDrawing must interrupt and stop the rendering process", br.interrupted );
 	}
 
 	@Test

Bug#1031366: nvidia-driver: black screen after update to 525.85.12-1 when nvidia-drm.modeset=1 is set

2023-02-27 Thread Christian Lauinger

I managed to get it in runlevel 3 with nvidia-drm.modeset=1

here is the log from the gdm3 start:


Feb 27 22:15:52 debian rtkit-daemon[1301]: Successfully made thread
3650 of process 3650 owned by '115' high priority at nice level -11.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 3 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 3 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 3 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 3 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 3 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Successfully made thread
3699 of process 3649 owned by '115' RT at priority 20.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 4 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 4 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 4 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Successfully made thread
3700 of process 3647 owned by '115' RT at priority 20.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 5 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian wireplumber[3649]: Failed to set scheduler
settings: Die Operation ist nicht erlaubt
Feb 27 22:15:52 debian wireplumber[3649]: SPA handle
'api.libcamera.enum.manager' could not be loaded; is it installed?
Feb 27 22:15:52 debian wireplumber[3649]: PipeWire's libcamera SPA
missing or broken. libcamera not supported.
Feb 27 22:15:52 debian systemd[3630]: Starting tracker-miner-fs-
3.service - Tracker file system data miner...
Feb 27 22:15:52 debian rtkit-daemon[1301]: Successfully made thread
3701 of process 3650 owned by '115' RT at priority 20.
Feb 27 22:15:52 debian rtkit-daemon[1301]: Supervising 6 threads of 3
processes of 1 users.
Feb 27 22:15:52 debian tracker-miner-f[3708]: Unable to get XDG user
directory path for special directory  Ignoring this
location.
Feb 27 22:15:52 debian tracker-miner-f[3708]: Unable to get XDG user
directory path for special directory  Ignoring this location.
Feb 27 22:15:52 debian tracker-miner-f[3708]: Unable to get XDG user
directory path for special directory  Ignoring this location.
Feb 27 22:15:52 debian tracker-miner-f[3708]: Unable to get XDG user
directory path for special directory  Ignoring this location.
Feb 27 22:15:52 debian tracker-miner-f[3708]: Unable to get XDG user
directory path for special directory  Ignoring this location.
Feb 27 22:15:52 debian tracker-miner-f[3708]: Unable to get XDG user
directory path for special directory  Ignoring this
location.
Feb 27 22:15:52 debian tracker-miner-f[3708]: Unable to get XDG user
directory path for special directory  Ignoring this location.
Feb 27 22:15:52 debian tracker-miner-f[3708]: Unable to get XDG user
directory path for special directory  Ignoring this location.
Feb 27 22:15:52 debian tracker-miner-f[3708]: Unable to get XDG user
directory path for special directory  Ignoring this location.
Feb 27 22:15:52 debian dbus-daemon[3652]: [session uid=115 pid=3652]
Activating via systemd: service name='org.gtk.vfs.UDisks2VolumeMonitor'
unit='gvfs-udisks2-volume-monitor.service' requested by ':1.11'
(uid=115 pid=3708 comm="/usr/libexec/tracker-miner-fs-3")
Feb 27 22:15:52 debian systemd[3630]: Starting gvfs-udisks2-volume-
monitor.service - Virtual filesystem service - disk device monitor...
Feb 27 22:15:52 debian gnome-shell[3688]: Device '/dev/dri/card0'
prefers shadow buffer
Feb 27 22:15:52 debian dbus-daemon[3652]: [session uid=115 pid=3652]
Successfully activated service 'org.gtk.vfs.UDisks2VolumeMonitor'
Feb 27 22:15:52 debian systemd[3630]: Started gvfs-udisks2-volume-
monitor.service - Virtual filesystem service - disk device monitor.
Feb 27 22:15:52 debian dbus-daemon[3652]: [session uid=115 pid=3652]
Activating via systemd: service name='org.gtk.vfs.MTPVolumeMonitor'
unit='gvfs-mtp-volume-monitor.service' requested by ':1.11' (uid=115
pid=3708 comm="/usr/libexec/tracker-miner-fs-3")
Feb 27 22:15:52 debian systemd[3630]: Starting gvfs-mtp-volume-
monitor.service - Virtual filesystem service - Media Transfer Protocol
monitor...
Feb 27 22:15:52 debian dbus-daemon[3652]: [session uid=115 pid=3652]
Successfully activated service 'org.gtk.vfs.MTPVolumeMonitor'
Feb 27 22:15:52 debian systemd[3630]: Started gvfs-mtp-volume-
monitor.service - Virtual filesystem service - Media Transfer Protocol
monitor.
Feb 27 22:15:52 debian dbus-daemon[3652]: [session uid=115 pid=3652]
Activating via systemd: service name='org.gtk.vfs.AfcVolumeMonitor'
unit='gvfs-afc-volume-monitor.service' requested by ':1.11' (uid=115
pid=3708 comm="/usr/libexec/tracker-miner-fs-3")
Feb 27 22:15:52 debian systemd[3630]: Starting gvfs-afc-volume-
monitor.service - Virtual filesystem service - Apple File Conduit
monitor...
Feb 27

Bug#992150: Please allow symlink in system extension

2023-02-27 Thread Bastien Roucariès

Package: firefox-esr
Version: 102.8.0esr-1
Followup-For: Bug #992150
Control: severity -1 important

Dear Maintainer,

punycode is still here duplicated from libjs-punycode...

webext-noscript: /usr/share/webext/noscript/lib/punycode.js
webext-noscript: /usr/share/webext/noscript/lib/punycode.js.LICENSE.txt
webext-ublock-origin-chromium: /usr/share/chromium/extensions/ublock-
origin/lib/punycode.js
webext-ublock-origin-firefox:
/usr/share/mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/ublo...@raymondhill.net/lib/punycode.js
webext-umatrix: /usr/share/webext/umatrix/lib/punycode.js

They are other and this should be avoided

Bastien


-- Package-specific info:


-- Addons package information

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armel

Kernel: Linux 6.1.0-3-rt-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 firefox-esr depends on:
ii  debianutils  5.7-0.4
ii  fontconfig   2.14.1-4
ii  libasound2   1.2.8-1+b1
ii  libatk1.0-0  2.46.0-5
ii  libc62.36-8
ii  libcairo-gobject21.16.0-7
ii  libcairo21.16.0-7
ii  libdbus-1-3  1.14.6-1
ii  libdbus-glib-1-2 0.112-3
ii  libevent-2.1-7   2.1.12-stable-5+b1
ii  libffi8  3.4.4-1
ii  libfontconfig1   2.14.1-4
ii  libfreetype6 2.12.1+dfsg-4
ii  libgcc-s112.2.0-14
ii  libgdk-pixbuf-2.0-0  2.42.10+dfsg-1+b1
ii  libglib2.0-0 2.74.5-1
ii  libgtk-3-0   3.24.36-4
ii  libnspr4 2:4.35-1
ii  libnss3  2:3.87.1-1
ii  libpango-1.0-0   1.50.12+ds-1
ii  libstdc++6   12.2.0-14
ii  libvpx7  1.12.0-1
ii  libx11-6 2:1.8.3-3
ii  libx11-xcb1  2:1.8.3-3
ii  libxcb-shm0  1.15-1
ii  libxcb1  1.15-1
ii  libxcomposite1   1:0.4.5-1
ii  libxdamage1  1:1.1.6-1
ii  libxext6 2:1.3.4-1+b1
ii  libxfixes3   1:6.0.0-2
ii  libxrandr2   2:1.5.2-2+b1
ii  libxtst6 2:1.2.3-1.1
ii  procps   2:4.0.2-3
ii  zlib1g   1:1.2.13.dfsg-1

Versions of packages firefox-esr recommends:
ii  libavcodec58  7:4.4.2-1+b3
ii  libavcodec59  7:5.1.2-2

Versions of packages firefox-esr suggests:
ii  fonts-lmodern  2.005-1
ii  fonts-stix [otf-stix]  1.1.1-4.1
ii  libcanberra0   0.30-10
ii  libgssapi-krb5-2   1.20.1-1
ii  pulseaudio 16.1+dfsg1-2+b1

-- no debconf information

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

2023-02-27 Thread Faidon Liambotis

On Mon, Feb 27, 2023 at 09:20:05PM +0100, Helge Deller wrote:
> Yes, you seem to be right. I missed the stat() calls.
> I wonder - do you know which files are monitored with the stat() calls?
> Could it be that those are just files from /dev or /proc, or are other
> standard files monitored too?

They are configuration files in /etc/gdnsd, state files in /run, as well
as user-configurable paths, as configured in /etc/gdnsd/config, cf.
gdnsd-plugin-extfile(8). So I see where you were going with this, but
I'm afraid that there's no shortcut here :/

What would you like to do with this bug? Would you like to file a bug
against libev and mark this bug as blocked by the libev one? Or
alternatively I can mark as wontfix and resolve?

(Quite honestly I'm not sure if I were the libev maintainer if I'd
bother with an ABI bump for this; but they might :)

Regards,
Faidon

Bug#1031780: tracker.debian.org: add information about patches

2023-02-27 Thread Raphael Hertzog

Hi Guillem & Holger,

On Sun, 26 Feb 2023, Guillem Jover wrote:
> The links for diaspora do not seem to be working though, as at least
> the «+» in the version string is not getting encoded, and UDD gives:

Duh, I forgot to urlencode the parameters, fixed. (That thought actually
popped up in my mind during my night... :-))

On Mon, 27 Feb 2023, Holger Levsen wrote:
> from #debian-qa a few minutes ago:
> 
> < h01ger> buxy: tracker.d.o/debian-edu-config says debian/patches: low
> < h01ger> Among the None debian patch available in version 2.12.31 of the 
> package, we noticed the following issues:
> < h01ger> while the package has no debian/patches/ ...

Fixed to properly skip packages using other source formats where UDD
puts "null" values in JSON instead of the 0 that the code expected.

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

Bug#1030906: taurus-pyqtgraph: FTBFS (failing tests)

2023-02-27 Thread Étienne Mollier

Hi s3v,

Thank you for the hints on taurus-pyqtgraph affected by #1030906
in Debian.  I could devise on patches to bring it back into
working conditions for bookworm; an upload will follow shortly.

Have a nice day,  :)
-- 
Étienne Mollier 
Fingerprint:  8f91 b227 c7d6 f2b1 948c  8236 793c f67e 8f0d 11da
Sent from /dev/pts/5, please excuse my verbosity.


signature.asc
Description: PGP signature

Bug#1032094: rclone: Missing /sbin/mount.rclone symlink

2023-02-27 Thread Leonard Lausen

Package: rclone
Version: 1.60.1+dfsg-2+b2
Severity: important
Tags: patch
X-Debbugs-Cc: leon...@lausen.nl

Dear Maintainer,

as of v1.57 rclone natively supports operation as mount helper and does
not need mount wrapper scripts anymore. Please symlink rclone binary to
/sbin/mount.rclone as described on
https://github.com/rclone/rclone/wiki/rclone-mount-helper-script
https://rclone.org/commands/rclone_mount/#rclone-as-unix-mount-helper
to facilitate using rclone with the /usr/bin/mount command.


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (500, 'testing'), (1, 'unstable')
Architecture: arm64 (aarch64)

Kernel: Linux 6.1.7-stb-cbq+ (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.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 rclone depends on:
ii  libc6  2.36-8

rclone recommends no packages.

Versions of packages rclone suggests:
ii  fuse3 [fuse]  3.13.0-2

-- no debconf information

Bug#1032095: calibre 6.11.0: TypeError: HistoryLineEdit.init() got an unexpected keyword argument 'parent'

2023-02-27 Thread Davide Prina

Package: calibre
Version: 6.11.0+dfsg-2
Severity: normal
X-Debbugs-Cc: davide.pr...@null.net

Dear Maintainer,

if I select two or more books and press Edit Metadata button I get the
following error:

calibre 6.11  embedded-python: False
Linux-6.1.0-3-amd64-x86_64-with-glibc2.36 Linux ('64bit', 'ELF')
('Linux', '6.1.0-3-amd64', '#1 SMP PREEMPT_DYNAMIC Debian 6.1.8-1 (2023-01-29)')
Python 3.11.2
Interface language: it
Traceback (most recent call last):
  File "/usr/lib/calibre/calibre/gui2/actions/edit_metadata.py", line 438, in 
edit_metadata
self.edit_metadata_for(row_list, ids, bulk=bulk)
  File "/usr/lib/calibre/calibre/gui2/actions/edit_metadata.py", line 443, in 
edit_metadata_for
return self.do_edit_bulk_metadata(rows, book_ids)
   ^^
  File "/usr/lib/calibre/calibre/gui2/actions/edit_metadata.py", line 547, in 
do_edit_bulk_metadata
dialog = MetadataBulkDialog(self.gui, rows,
 ^^
  File "/usr/lib/calibre/calibre/gui2/dialogs/metadata_bulk.py", line 497, in 
__init__
self.setupUi(self)
  File "/usr/lib/calibre/calibre/gui2/dialogs/metadata_bulk_ui.py", line 372, 
in setupUi
self.s_r_template = HistoryLineEdit(parent=self.tabWidgetPage3)
^^^
TypeError: HistoryLineEdit.__init__() got an unexpected keyword argument 
'parent'


I have see that there is a new version in Sid, but I don't have
understand if that one will go into the next stable.

If I don't mistake this bug is not present in the previous 6.11.0+dfsg-1 
version.

If you want I can test the Sid 6.13 version.

Ciao
Davide

-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'testing-debug'), (500, 'stable-security')
Architecture: amd64 (x86_64)

Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (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 calibre depends on:
ii  calibre-bin6.11.0+dfsg-2
ii  fonts-liberation2  2.1.5-1
ii  libjpeg-turbo-progs1:2.1.5-2
ii  libjxr-tools   1.2~git20170615.f752187-5
ii  libqt6webenginecore6-bin   6.4.2+dfsg-0rc0-2
ii  optipng0.7.7-2+b1
ii  poppler-utils  22.12.0-2+b1
ii  pyqt6-dev-tools6.4.2-1
ii  python33.11.2-1
ii  python3-apsw   3.40.0.0-2+b1
ii  python3-bs44.11.2-1
ii  python3-chm0.8.6-3+b4
ii  python3-css-parser 1.0.8-1
ii  python3-cssselect  1.2.0-2
ii  python3-dateutil   2.8.2-1
ii  python3-feedparser 6.0.10-1
ii  python3-html2text  2020.1.16-2
ii  python3-html5-parser   0.4.10-8+b1
ii  python3-html5lib   1.1-3
ii  python3-jeepney0.8.0-3
ii  python3-lxml   4.9.2-1+b1
ii  python3-markdown   3.4.1-2
ii  python3-mechanize  1:0.4.8+pypi-5
ii  python3-msgpack1.0.3-2+b1
ii  python3-netifaces  0.11.0-2+b1
ii  python3-pil9.4.0-1.1+b1
ii  python3-pkg-resources  66.1.1-1
ii  python3-py7zr  0.11.3+dfsg-4
ii  python3-pycryptodome   3.11.0+dfsg1-4
ii  python3-pygments   2.14.0+dfsg-1
ii  python3-pyparsing  3.0.9-1
ii  python3-pyqt6  6.4.2-1
ii  python3-pyqt6.qtquick  6.4.2-1
ii  python3-pyqt6.qtsvg6.4.2-1
ii  python3-pyqt6.qtwebengine  6.4.0-1
ii  python3-pyqt6.sip  13.4.1-1
ii  python3-regex  0.1.20221031-1+b1
ii  python3-routes 2.5.1-3
ii  python3-speechd0.11.4-2
ii  python3-zeroconf   0.47.1-2
ii  python3.11 3.11.2-4
ii  xdg-utils  1.1.3-4.1

Versions of packages calibre recommends:
ii  python3-dnspython  2.3.0-1
ii  python3-ipython8.5.0-4
ii  qt6-wayland6.4.2-1
ii  udisks22.9.4-4

Versions of packages calibre suggests:
pn  python3-unrardll  

-- no debconf information

Bug#1023255: NMU to fix

2023-02-27 Thread Matthew Vernon


Control: found -1 1:2.39.2-1
Control: tags -1 patch
quit

Hi,

I tripped over this on my bookworm system, and it's both a bit annoying 
and an easy fix.


I've prepared an NMU to fix this so it'll get into bookworm - OK for me 
to upload?


Thanks,

MatthewFrom 716d196b0c5dc9f3fe13a87d8010ae07048d4e7c Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Mon, 27 Feb 2023 20:13:22 +
Subject: [PATCH 1/2] Correct path to git index format doc (Closes: #1023255)

---
 debian/git-doc.doc-base.git-index-format | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/debian/git-doc.doc-base.git-index-format b/debian/git-doc.doc-base.git-index-format
index 245a1b5..00f9871 100644
--- a/debian/git-doc.doc-base.git-index-format
+++ b/debian/git-doc.doc-base.git-index-format
@@ -6,4 +6,4 @@ Abstract: The on-disk format of Git's staging area, merging area,
 Section: File Management
 
 Format: Text
-Files: /usr/share/doc/git-doc/technical/index-format.txt
+Files: /usr/share/doc/git-doc/gitformat-index.txt
-- 
2.39.2

From 5881f8267534637b591a079c7c284cbdc7d325e7 Mon Sep 17 00:00:00 2001
From: Matthew Vernon 
Date: Mon, 27 Feb 2023 20:13:37 +
Subject: [PATCH 2/2] Changelog for 1:2.39.2-1.1

---
 debian/changelog | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index a55b587..cb78cd1 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+git (1:2.39.2-1.1) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Correct path to git index format doc (Closes: #1023255)
+
+ -- Matthew Vernon   Mon, 27 Feb 2023 20:12:04 +
+
 git (1:2.39.2-1) unstable; urgency=medium
 
   * new upstream point release (see RelNotes/2.39.2.txt).  Addresses
-- 
2.39.2

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

2023-02-27 Thread Helge Deller


Hello Faidon,

On 2/27/23 18:36, Faidon Liambotis wrote:

2) the stat() calls, via ev_stat_init etc., in the mon and extfile plugins.
...

However, (2) is not self-contained, with stat structures crossing an ABI
boundary (libev's). Hence why the test suite (legitimately) fails when
building with future=+lfs.

My understanding is that patching (1) with the patch you attached, but
not building with future=+lfs, ill effectively still create a binary
that does not have large file/inode support, as the stat() calls that
the mon/extfile plugins make, will not work on 64-bit inode filesystems.


Yes, you seem to be right. I missed the stat() calls.
I wonder - do you know which files are monitored with the stat() calls?
Could it be that those are just files from /dev or /proc, or are other
standard files monitored too?

Helge

Bug#1032034: beagle: broken package on non arm64/amd64 architectures

2023-02-27 Thread Andreas Tille

Hi Vladimir,

thanks for this bug report.

Am Mon, Feb 27, 2023 at 09:35:31AM +1300 schrieb Vladimir Petko:
> 
> The following packages have unmet dependencies:
>  libhtsjdk-java : Depends: libngs-java but it is not installable
> E: Unable to correct problems, you have held broken packages.
> 
> The root cause is sra-sdk dependency which is only available for amd64
> and arm64 architectures.

Yes, that's correct.  It's due to


sra-sdk (3.0.3+dfsg-5) unstable; urgency=medium

  * Limit libngs-java to those architectures where libs are available
Closes: #1031853
  * ...

 -- Andreas Tille   Fri, 24 Feb 2023 11:52:27 +0100


The only way to keep this consistent seems to be to also restrict
libhtsjdk-java to the said architectures.

Kind regards
Andreas.

-- 
http://fam-tille.de

Bug#1031927: Handling the libsgutils2-2 #994758 bookworm-ignore

2023-02-27 Thread Paul Gevers


Control: tags 994758 - bookworm-ignore

Hi Adrian,

Thanks for caring.

On 25-02-2023 14:30, Adrian Bunk wrote:
With the bookworm-ignore for #994758, 


I'll admit that I misjudged that bug; with this message I'll clear the 
bookworm-ignore tag.



bullseye and bookworm
will ship libsgutils2-2 packages with different so-name.


Although the transition freeze has started long time ago, it seems that 
doing a proper transition is the best way to fix this issue. If somebody 
is up to the task to prepare the upload, we can ask ftp-master to 
process the upload swiftly. (Please upload to experimental to avoid the 
ftp-master from rejecting the package immediately and to enable 
reviewing if that's not done before the upload.)


Paul


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1032093: jameica: missing dependencies

2023-02-27 Thread Thomas Uhle


Package: jameica
Version: 2.10.3+dfsg-1
Severity: important
Tags: fixed-upstream
X-Debbugs-Cc: Jochen Sprickerhoff 

Dear maintainers,

Jameica dies with the following messages if it is started for the very 
first time, i.e., with an empty user profile directory $HOME/.jameica:


[Mon Feb 27 18:48:06 CET 
2023][INFO][main][de.willuhn.jameica.gui.SplashScreen$3.run]  generating new 
keys and certificates ...
[Mon Feb 27 18:48:06 CET 
2023][INFO][main][de.willuhn.jameica.security.SSLFactory.init]   generating rsa 
keypair
[Mon Feb 27 18:48:09 CET 
2023][INFO][main][de.willuhn.jameica.security.SSLFactory.init]   generating 
selfsigned x.509 certificate
[Mon Feb 27 18:48:09 CET 
2023][INFO][main][de.willuhn.jameica.security.SSLFactory.init]   using 
hostname: localhost
Exception in thread "main" java.lang.NoClassDefFoundError: 
org/bouncycastle/asn1/cms/CMSObjectIdentifiers
at 
org.bouncycastle.operator.DefaultSignatureNameFinder.(Unknown Source)
at org.bouncycastle.operator.jcajce.OperatorHelper.(Unknown 
Source)
at 
org.bouncycastle.operator.jcajce.JcaContentSignerBuilder.(Unknown Source)
at de.willuhn.jameica.security.SSLFactory.init(SSLFactory.java:291)
at de.willuhn.jameica.services.SSLService.init(SSLService.java:45)
at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139)
at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119)
at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119)
at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:72)
at de.willuhn.jameica.system.Application.init(Application.java:103)
at 
de.willuhn.jameica.system.Application.newInstance(Application.java:87)
at de.willuhn.jameica.Main.main(Main.java:78)
Caused by: java.lang.ClassNotFoundException: 
org.bouncycastle.asn1.cms.CMSObjectIdentifiers
at 
java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at 
java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
... 12 more

The reason is that in BouncyCastle version 1.69 some code was moved from 
bcprov.jar into the new bcutil.jar, and the class path of jameica.jar 
still references only bcprov.jar and bcpkix.jar but not bcutil.jar (please 
cf. https://github.com/willuhn/jameica/issues/42#issuecomment-1418240499). 
This is easily fixed by adding /usr/share/java/bcutil.jar to 
debian/patches/0001-Update-locations-of-Java-libraries.patch.  Maybe it 
makes sense to also add libbcutil-java to Jameica's package dependencies 
in debian/control because of its jar file being explicitly on the class 
path.



Another issue comes from switching default-jre to openjdk-17-jre which has 
been openjdk-11-jre before.  The bundled JavaScript engine has been 
removed in OpenJDK 15 which causes the following warning at the start:


[Mon Feb 27 19:05:01 CET 
2023][WARN][main][de.willuhn.jameica.services.ScriptingService.init] java does 
not support scripting (RhinoScript)

So Jameica's scripting service is no longer usable unless rhino.jar and 
rhino-engine.jar is added to the class path of jameica.jar (please cf. 
https://github.com/willuhn/jameica/issues/43).  Similar to the previous 
fix, you can simply add /usr/share/java/rhino.jar to 
debian/patches/0001-Update-locations-of-Java-libraries.patch and add 
librhino-java to Jameica's package dependencies in debian/control.  It 
might make sense to already add /usr/share/java/rhino-engine.jar to the 
class path as well although Debian's current version of librhino-java 
contains all the code in one single file js-1.7.7.2.jar that rhino.jar 
is linking to.



Best regards,

Thomas Uhle

Bug#1032078: lintian: False positive for debian-watch-could-verify-download test

2023-02-27 Thread Lucas Nussbaum

Hi,

On 27/02/23 at 10:24 -0500, Scott Kitterman wrote:
> Package: lintian
> Version: 2.116.3+reprocess
> Severity: normal
> 
> The UDD lintian report currently lists this warning as being applicable
> to dkimpy-milter [1], but the watch file does verify the download.  I
> downloaded a new version yesterday and the signature was verified.  The
> package's d/watch does include pgpsigurlmangle as recommended.
> 
> Scott K
> 
> [1] https://udd.debian.org/lintian/?packages=dkimpy-milter

That version '2.116.3+reprocess' on UDD is identical to 2.116.3.
(it's just a fake version to force a reprocessing of all packages
following a fix).

Lucas

Bug#1032074: libdbd-mysql-perl: SSL connection error: Enforcing SSL encryption is not supported

2023-02-27 Thread Florian Schlichting

Hi,

On Mon, Feb 27, 2023 at 01:34:49PM +0100, root wrote:
> In the meantime I installed the Debian updates e.g., mariadb and libssl. 
> Apparently, libgnutls
> was at least a day before that.

have you had a look at the changelog for these updates?

> 
> When I now try to connect I receive:
> 
> DBI 
> connect('database=MList;mysql_ssl=1;mysql_ssl_client_key=/etc/postfix/mlist.key.pem;mysql_ssl_client_cert=/etc/postfix/mlist.cert.pem;mysql_ssl_ca_file=/etc/certs/cacert.pem;host=mysql.example.com','mlist',...)
>  failed: SSL connection error: Enforcing SSL encryption is not supported at 
> /usr/local/lib/mlist/MListDB.pm line 189.

Looking up your error message in Google ("Enforcing SSL encryption is
not supported") turns up
https://github.com/perl5-dbi/DBD-mysql/issues/333

Do you use the "mysql_ssl_verify_server_cert=1" connection option? Have
you tried setting "mysql_ssl_optional=1"?

HTH, Florian

Bug#1032092: asterisk: CVE-2022-23537 CVE-2022-23547 CVE-2022-39269

Source: asterisk
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerabilities were published for asterisk.

CVE-2022-23537[0]:
| PJSIP is a free and open source multimedia communication library
| written in C language implementing standard based protocols such as
| SIP, SDP, RTP, STUN, TURN, and ICE. Buffer overread is possible when
| parsing a specially crafted STUN message with unknown attribute. The
| vulnerability affects applications that uses STUN including PJNATH and
| PJSUA-LIB. The patch is available as a commit in the master branch
| (2.13.1).

https://github.com/pjsip/pjproject/security/advisories/GHSA-9pfh-r8x4-w26w
https://github.com/pjsip/pjproject/commit/d8440f4d711a654b511f50f79c0445b26f9dd1e1

CVE-2022-23547[1]:
| PJSIP is a free and open source multimedia communication library
| written in C language implementing standard based protocols such as
| SIP, SDP, RTP, STUN, TURN, and ICE. This issue is similar to
| GHSA-9pfh-r8x4-w26w. Possible buffer overread when parsing a certain
| STUN message. The vulnerability affects applications that uses STUN
| including PJNATH and PJSUA-LIB. The patch is available as commit in
| the master branch.

https://github.com/pjsip/pjproject/security/advisories/GHSA-9pfh-r8x4-w26w
https://github.com/pjsip/pjproject/commit/d8440f4d711a654b511f50f79c0445b26f9dd1e1
https://github.com/pjsip/pjproject/security/advisories/GHSA-cxwq-5g9x-x7fr
https://github.com/pjsip/pjproject/commit/bc4812d31a67d5e2f973fbfaf950d6118226cf36

CVE-2022-39269[2]:
| PJSIP is a free and open source multimedia communication library
| written in C. When processing certain packets, PJSIP may incorrectly
| switch from using SRTP media transport to using basic RTP upon SRTP
| restart, causing the media to be sent insecurely. The vulnerability
| impacts all PJSIP users that use SRTP. The patch is available as
| commit d2acb9a in the master branch of the project and will be
| included in version 2.13. Users are advised to manually patch or to
| upgrade. There are no known workarounds for this vulnerability.

https://github.com/pjsip/pjproject/security/advisories/GHSA-wx5m-cj97-4wwg
https://github.com/pjsip/pjproject/commit/d2acb9af4e27b5ba75d658690406cec9c274c5cc


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-23537
https://www.cve.org/CVERecord?id=CVE-2022-23537
[1] https://security-tracker.debian.org/tracker/CVE-2022-23547
https://www.cve.org/CVERecord?id=CVE-2022-23547
[2] https://security-tracker.debian.org/tracker/CVE-2022-39269
https://www.cve.org/CVERecord?id=CVE-2022-39269

Please adjust the affected versions in the BTS as needed.

Bug#1032020: chromium: Missing character after Chromium AppArmor profile update opens up unrestricted system browsing.

2023-02-27 Thread Andres Salomon


Control: reassign -1 apparmor-profiles



On Mon, Feb 27 2023 at 08:15:37 PM +0100, Guillaume B. 
 wrote:

Hi,

It seems that the previous emails in our exchange got nuked out my 
account so apologies for not being able to reply using the usual 
channels.


The command 'find /etc/apparmor* -name "*hromium*" | xargs dpkg -S' 
returns the following -> "dpkg-query: no path found matching pattern 
/etc/apparmor.d/usr.bin.chromium

lightdm: /etc/apparmor.d/abstractions/lightdm_chromium-browser"

  ///

I'm using AppArmor profiles found in the "apparmor-profiles" package. 
Having recently updated from stable, I was able to keep the profiles 
without the package being installed; i.e., the update couldn't have 
come from an apparmor-profile package update.



Ah, okay, that makes more sense. Reassigning to the apparmor-profiles 
package, then.





Dealing with the issue, I have not made a backup of the updated 
Chromium AppArmor profile but simply did some file comparison and 
reverted to a previous profile, nuking the updated profile in the 
copying process.


The "updated" AppArmor profile was dated either january or february 
of this year and had been modified by an Ubuntu email.


TLDR; There was an update to the Chromium AppArmor profile, not sure 
how, but it happened.


I might just take it up with the Ubuntu Chromium AppArmor profile 
maintenance team, in which case, sorry to have wasted your time.


Regards




You mean Debian maintenance team, right? If you pulled in an Ubuntu 
apparmor package, that's a different story (and we should close this 
bug). If you're using Debian's apparmor-profiles package, then the bug 
and fix should go there. Although, if you're pulling in an Ubuntu 
package to get some kind of apparmor protection that Debian doesn't 
have, you also might want to open a wishlist bug on the Debian package 
asking for the feature so you don't have to mix-and-match packages 
across different distributions.

Bug#1032091: py7zr: CVE-2022-40152

Source: py7zr
X-Debbugs-CC: t...@security.debian.org
Severity: grave
Tags: security

Hi,

The following vulnerability was published for py7zr.

CVE-2022-40152[0]:
| Those using Woodstox to parse XML data may be vulnerable to Denial of
| Service attacks (DOS) if DTD support is enabled. If the parser is
| running on user supplied input, an attacker may supply content that
| causes the parser to crash by stackoverflow. This effect may support a
| denial of service attack.

https://github.com/miurahr/py7zr/commit/1bb43f17515c7f69673a1c88ab9cc72a7bbef406
 (v0.20.1)
https://lessonsec.com/cve/cve-2022-44900/


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-40152
https://www.cve.org/CVERecord?id=CVE-2022-40152

Please adjust the affected versions in the BTS as needed.

Bug#1032090: grave: CVE-2022-44900

Source: grave
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for grave.

CVE-2022-44900[0]:
| A directory traversal vulnerability in the SevenZipFile.extractall()
| function of the python library py7zr v0.20.0 and earlier allows
| attackers to write arbitrary files via extracting a crafted 7z file.

https://github.com/miurahr/py7zr/commit/1bb43f17515c7f69673a1c88ab9cc72a7bbef406
 (v0.20.1)
https://lessonsec.com/cve/cve-2022-44900/


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-44900
https://www.cve.org/CVERecord?id=CVE-2022-44900

Please adjust the affected versions in the BTS as needed.

Bug#1032089: libwoodstox-java: CVE-2022-40152

Source: libwoodstox-java
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libwoodstox-java.

CVE-2022-40152[0]:
| Those using Woodstox to parse XML data may be vulnerable to Denial of
| Service attacks (DOS) if DTD support is enabled. If the parser is
| running on user supplied input, an attacker may supply content that
| causes the parser to crash by stackoverflow. This effect may support a
| denial of service attack.

https://github.com/x-stream/xstream/issues/304
https://github.com/advisories/GHSA-3f7h-mf4q-vrm4


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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-40152
https://www.cve.org/CVERecord?id=CVE-2022-40152

Please adjust the affected versions in the BTS as needed.

Bug#1032088: https://rustsec.org/advisories/RUSTSEC-2022-0078.html

Source: rust-bumpalo
Version: 3.7.0-3
Severity: important
Tags: security
X-Debbugs-Cc: Debian Security Team 

https://rustsec.org/advisories/RUSTSEC-2022-0078.html

Bug#1032087: undertow: CVE-2022-4492

Source: undertow
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for undertow.

CVE-2022-4492[0]:
| The undertow client is not checking the server identity presented by
| the server certificate in https connections. This is a compulsory step
| (at least it should be performed by default) in https and in http/2. I
| would add it to any TLS client protocol.

https://bugzilla.redhat.com/show_bug.cgi?id=2153260 is currently the
only reference.

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

For further information see:

[0] https://security-tracker.debian.org/tracker/CVE-2022-4492
https://www.cve.org/CVERecord?id=CVE-2022-4492

Please adjust the affected versions in the BTS as needed.

Bug#1032086: Don't include in Bookworm

Source: golang-github-labstack-echo.v3
Version: 3.3.10-2
Severity: serious

This is an older version of src:golang-github-labstack-echo. None of the
reverse deps are currently in bookworm, so golang-github-labstack-echo.v3
should be dropped as well (and post freeze the reverse deps fixed and
the package removed)

Bug#1032085: Don't include in Bookworm

Source: golang-github-labstack-echo.v2
Version: 2.2.0-3
Severity: serious

This is an older version of src:golang-github-labstack-echo. None of the
reverse deps are currently in bookworm, so golang-github-labstack-echo.v2
should be dropped as well (and post freeze the reverse deps fixed and
the package removed)

Bug#1031131: open-iscsi: Lot of iscsi/kernel errors in dmesg with Fujitsu Eternus DX100S4 connected with 2 10Gb ethernet paths with multipathd.

2023-02-27 Thread Milan Oravec

hello Sarraf,

On Thu, Feb 23, 2023 at 2:44 PM Ritesh Raj Sarraf  wrote:

> On Thu, 2023-02-23 at 14:19 +0100, Milan Oravec wrote:
> > > >
> > >
> > > By KVM, do you mean just pure KVM ? Or the management suite too,
> > > libvirt ?
> > >
> >
> >
> > Yes, libvirt is used to manage KVM, and virt-manager on my desktop to
> > connect to it. It is simple setup without clustering.
> >
>
> Thanks for confirming.
>
> You should start with the hypervisor where libvirtd is running. Check
> if that hypervisor host is running normal.
>

No unusual errors reported.


>
> From all the symptoms you've shared, my wild arrow in the dark is that
> your hypervisor/guest network may be running into issues.
>
>
There is all ok with network.


> >
> >
> > Do you know someone who can help with this? Here is example of KVM
> > guest running configuration:
> >
> > libvirt+ 244533  1  5 Feb03 ?1-03:54:37 qemu-system-
> > x86_64 -enable-kvm -name guest=me_test,process=qemu:me_test,debug-
> > threads=on -S -object
> > secret,id=masterKey0,format=raw,file=/var/lib/libvirt/qemu/domain-
> > 108-me_test/master-key.aes -machine pc-1.1,accel=kvm,usb=off,dump-
> > guest-core=off -cpu host -m 8096 -realtime mlock=off -smp
> > 4,sockets=1,cores=4,threads=1 -uuid 1591f345-96b5-4077-9d32-
> > b2991003753d -no-user-config -nodefaults -chardev
> > socket,id=charmonitor,fd=57,server,nowait -mon
> > chardev=charmonitor,id=monitor,mode=control -rtc base=utc -no-
> > shutdown -boot strict=on -device piix3-usb-
> > uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-
> > pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,id=drive-
> > ide0-1-0,readonly=on -device ide-cd,bus=ide.1,unit=0,drive=drive-
> > ide0-1-0,id=ide0-1-0,bootindex=1 -drive
> > file=/dev/mapper/me_test,format=raw,if=none,id=drive-virtio-
> > disk0,cache=none,discard=unmap,aio=native -device virtio-blk-
> > pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-
> > disk0,bootindex=2,write-cache=on -netdev
> > tap,fd=60,id=hostnet0,vhost=on,vhostfd=61 -device virtio-net-
> > pci,netdev=hostnet0,id=net0,mac=aa:bb:cc:00:10:31,bus=pci.0,addr=0x3
> > -chardev pty,id=charserial0 -device isa-
> > serial,chardev=charserial0,id=serial0 -chardev
> > spicevmc,id=charchannel0,name=vdagent -device
> > virtserialport,bus=virtio-
> > serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice
> > .0 -spice port=5929,addr=0.0.0.0,disable-ticketing,seamless-
> > migration=on -device qxl-
> > vga,id=video0,ram_size=67108864,vram_size=67108864,vram64_size_mb=0,v
> > gamem_mb=16,max_outputs=1,bus=pci.0,addr=0x2 -device virtio-balloon-
> > pci,id=balloon0,bus=pci.0,addr=0x5 -sandbox
> > on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=de
> > ny -msg timestamp=on
> >
> > Maybe there is something undesirable for the iscsi target.
> >
>
> Seems like you are using host networking ? Have you validated that that
> part is working reliably ?
>

Yes, this is working fine too.

I've made some experiments with storage parameters passed to KVM, standard
disk created within virt-manager is running with following paramaters:

format=raw,cache=none,discard=unmap,aio=native.

I've removed cache  parameter (let hypervisor set its default) and now
running disk with:
format=raw,discard=unmap.

With this setup, there are no errors (connection1:0: pdu (op 0x5 itt 0x48)
rejected. Reason code 0x9) in logs. Virtual host was stressed with:

ns2:/home/migo# stress-ng -v -d 1
stress-ng: debug: [858] 2 processors online, 2 processors configured
stress-ng: info:  [858] defaulting to a 86400 second (1 day, 0.00 secs) run
per stressor
stress-ng: info:  [858] dispatching hogs: 1 hdd
stress-ng: debug: [858] cache allocate: default cache size: 262144K
stress-ng: debug: [858] starting stressors
stress-ng: debug: [858] 1 stressor started
stress-ng: debug: [859] stress-ng-hdd: started [859] (instance 0)
^Cstress-ng: debug: [859] stress-ng-hdd: exited [859] (instance 0)
stress-ng: debug: [858] process [859] terminated
stress-ng: info:  [858] successful run completed in 30377.75s (8 hours, 26
mins, 17.75 secs)
stress-ng: debug: [858] metrics-check: all stressor metrics validated and
sane

It seems that using hypervisors cache is filtering those bogus commands
(causing trouble for target) sent to the target. What do you think about it?

But running iscsi target with cache is not a good idea, and this is no real
solution. :(



>
> > >
> > > > > There will be errors in your system journal for this particular
> > > > > setup.
> > > > >
> > > > > Errors like:
> > > > >
> > > > > * connection drops
> > > > > * iscsi session drops/terminations
> > > > > * SCSI errors
> > > > > * multipath path checker errors
> > > > >
> > > > > All these will be errors which will be recovered eventually.
> > > > > That
> > > > > is
> > > > > why we have the need for close integration in between these
> > > > > layers,
> > > > > when building a storage solution on top.
> > > > >
> > > >
> > > >
> > > >

Bug#1021089: qrbackup ITP

Control: forwarded -1 https://github.com/za3k/qr-backup/issues/43

On 2022-11-11 12:41:50, Lance Lin wrote:
> retitle 1021089 ITP: qr-backup -- paper backups of files using QR codes

Hi Lance!

Do you still intend to package qr-backup?

Did you look at packaging the dependencies? It looks like at least
python-reedsolo needs to be packaged, according to upstream.

a.

-- 
If ease of use was the ultimate aim for a tool,
the bicycle would never have evolved beyond the tricycle.
— Doug Engelbart, 1925-2013

Bug#1021089: RFP: qr-backup -- paper backups of files using QR codes

On 2022-10-01 13:10:22, Zachary Vance wrote:

[...]

> - I am the author of this package. I do use this program, and believe an easy 
> install would benefit others.
> - Packaging should be easy (standard makefile, no compilation), for someone 
> experience with debian.
> - An example package which may help (for Arch linux) is at 
> https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=qr-backup

Hi Zachary!

Do you still intend on packaging your software for Debian? are you
looking for a sponsor?

a.

-- 
I would defend the liberty of consenting adult creationists to practice
whatever intellectual perversions they like in the privacy of their own
homes; but it is also necessary to protect the young and innocent.
- Arthur C. Clarke


signature.asc
Description: PGP signature

Bug#1032084: gourmand: Missing dependency to python3-extruct

2023-02-27 Thread Jack.R

Package: gourmand
Version: 1.1.0+really1.1.0~rc3-2
Severity: normal

Dear Maintainer,

After apt-get dist-upgrade in order to upgrade Gourmand:
  Dépaquetage de gourmand (1.1.0+really1.1.0~rc3-2) sur (1.1.0+really1.0.0-3) 
...
it failed to start.

Running it from command line as a standart user shows:

gourmand 
args = Namespace(db_url='', threads=False, gourmanddir='', 
thread_debug_interval=5.0, thread_debug=False, debug_file='', time=False, 
debug=None)
Traceback (most recent call last):
  File "/usr/bin/gourmand", line 33, in 
sys.exit(load_entry_point('gourmand==1.0.0', 'gui_scripts', 'gourmand')())
 ^^
  File "/usr/bin/gourmand", line 25, in importlib_load_entry_point
return next(matches).load()
   
  File "/usr/lib/python3.11/importlib/metadata/__init__.py", line 202, in load
module = import_module(match.group('module'))
 
  File "/usr/lib/python3.11/importlib/__init__.py", line 126, in import_module
return _bootstrap._gcd_import(name[level:], package, level)
   
  File "", line 1206, in _gcd_import
  File "", line 1178, in _find_and_load
  File "", line 1149, in _find_and_load_unlocked
  File "", line 690, in _load_unlocked
  File "", line 940, in exec_module
  File "", line 241, in _call_with_frames_removed
  File "/usr/lib/python3/dist-packages/gourmand/main.py", line 9, in 
from gourmand import (__version__, batchEditor, convert, plugin, plugin_gui,
  File "/usr/lib/python3/dist-packages/gourmand/reccard.py", line 33, in 

from gourmand.recindex import RecIndex
  File "/usr/lib/python3/dist-packages/gourmand/recindex.py", line 17, in 

from .importers.clipboard_importer import import_from_drag_and_drop
  File 
"/usr/lib/python3/dist-packages/gourmand/importers/clipboard_importer.py", line 
8, in 
from gourmand.importers.importManager import ImportManager
  File "/usr/lib/python3/dist-packages/gourmand/importers/importManager.py", 
line 10, in 
from gourmand.importers.web_importer import import_urls, supported_sites
  File "/usr/lib/python3/dist-packages/gourmand/importers/web_importer.py", 
line 6, in 
from recipe_scrapers import SCRAPERS, scrape_me
  File "/usr/lib/python3/dist-packages/recipe_scrapers/__init__.py", line 6, in 

from ._abstract import AbstractScraper
  File "/usr/lib/python3/dist-packages/recipe_scrapers/_abstract.py", line 12, 
in 
from ._schemaorg import SchemaOrg
  File "/usr/lib/python3/dist-packages/recipe_scrapers/_schemaorg.py", line 8, 
in 
import extruct
ModuleNotFoundError: No module named 'extruct'

This suggest a missing dependency to python3-extruct. 
I install it and now Gourmand start properly.

Best regards

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

Kernel: Linux 6.1.0-3-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.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 gourmand depends on:
ii  gir1.2-gtk-3.0   3.24.36-4
ii  python3  3.11.2-1
ii  python3-argcomplete  2.0.0-1
ii  python3-bs4  4.11.2-1
ii  python3-gi   3.42.2-3+b1
ii  python3-gi-cairo 3.42.2-3+b1
ii  python3-gst-1.0  1.22.0-2
ii  python3-keyring  23.9.3-2
ii  python3-lxml 4.9.2-1+b1
ii  python3-pil  9.4.0-1.1+b1
ii  python3-recipe-scrapers  14.32.0-1
ii  python3-reportlab3.6.12-1
ii  python3-requests 2.28.1+dfsg-1
ii  python3-sqlalchemy   1.4.46+ds1-1
ii  python3-toml 0.10.2-1

Versions of packages gourmand recommends:
ii  gir1.2-poppler-0.1822.12.0-2+b1
ii  python3-ebooklib   0.18-2
ii  python3-gtkspellcheck  4.0.5-3
ii  python3-pyglet 1.5.27+ds-2

gourmand suggests no packages.

-- no debconf information

Bug#1030284: nodejs: [arm64] RangeError: Maximum call stack size exceeded

2023-02-27 Thread Thorsten Glaser

James Addison dixit:

>Maybe it's rare to propose 'do nothing' as a technical suggestion but I think
>it is worth considering here, since we are not the arbiters of Node.

It’s still a release-critical bug in Debian which impacts arm64 builders
including reproducible-builds. I would see this fixed in bookworm, at
least by a band-aid (raising these limits by default); the proper fix
can be revisited after the release, and in coordination with upstream.

We know the default ulimits for users in Debian, and they are higher
than the 1 MiB assumed by v8, by quite some factor, so this won’t break
things which are not currently broken (by that exception). This will do
for the release I think.

If a proper, upstream-supported, fix arrives within $time it’s even
possible that a bookworm-security update includes that. Still thinking
along the line of getrlimit + subtract known arch-specific value for
the fix here, whatever makes sense with the v8 setting anyway…

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Bug#1024589: dislocker: FTBFS with ruby3.1: mv: cannot stat '/<>/debian/tmp/usr/lib/libdislocker*': No such file or directory

2023-02-27 Thread Eriberto Mota

Em seg., 27 de fev. de 2023 às 06:42, Santiago Vila
 escreveu:
>
> El 26/2/23 a las 0:04, Adrian Bunk escribió:
> > The Ubuntu diff has a fix for this issue caused by merged /usr
> > (untested).
>
> Note: Such diff was actually already in #1017937. I've just merged
> both bugs. Also, I've tested the diff and confirm that it works.
>
> Thanks.

Today I talked to Giovani, and he's a little busy because of a Masters
Course. It asked me to upload the fix. I'll do it. Thanks guys.

Regards,

Eriberto

Bug#1028083: plasma-discover: Discover tray app crashes kded5, causing other system tray icons to vanish

2023-02-27 Thread Jonas Arndt


This seems to fix it for me.

https://github.com/PackageKit/PackageKit-Qt/pull/45

Thanks,

// Jonas

Bug#1032060: puppetserver setup ca does not finish setup

2023-02-27 Thread Jérôme Charaoui

Control: severity -1 normal

Le 2023-02-27 à 11 h 29, Bastian Blank a écrit :

On Mon, Feb 27, 2023 at 10:14:33AM -0500, Jérôme Charaoui wrote:

Unfortunately I'm unable to reproduce this issue. Is this a new puppetserver
installation, or an upgrade from puppet-master 5.5?

This is a new installation.

However I found the reason.  The hostname setup is incomplete.  The
server considers the name for the certificate to be "debian-sid." and
uses files "debian-sid..crt" (aka it adds a trailing dot).

The agent seems to be not that kind and tries to get a new certificate,
which fails as the CN is already in use.

I'm curious to learn how one may reproduce this issue. Here in my test 
containers none of the machines' hostnames have a FQDN: only the host 
part exists, and neither do puppet agent nor puppetserver add a trailing 
dot to the client certificate.

Le 2023-02-27 à 11 h 46, Antoine Beaupré a écrit :
> Is not having a FQDN even supported in Puppet?

If a certificate can be generated for it, it works, so yes one can use 
puppet on machines without FQDNs.

> Maybe this could warrant a severity downgrade too... Seems like an 
edge case...

Downgraded to normal.

-- Jérôme

Bug#1031635: bullseye-pu: package snakeyaml/1.28-1

On Fri, Feb 24, 2023 at 10:29:07PM +0100, Markus Koschany wrote:
> Hi,
> 
> Am Freitag, dem 24.02.2023 um 16:01 +0100 schrieb Moritz Mühlenhoff:
> [...]
> > Could we also ship the README.Debian.security that was recently added
> > in unstable to bullseye/buster?
> 
> I've just uploaded a new revision of snakeyaml, 1.28.1+deb11u2. This one
> includes the README file. There have been no further changes to my previous
> upload.

Excellent, thanks.

Cheers,
Moritz

Bug#1031352: Chromium on Wayland: Cannot join a Microsoft Teams enterprise meeting

2023-02-27 Thread Amr Ibrahim

Am Mittwoch, dem 15.02.2023 um 12:23 -0500 schrieb Andres Salomon:
> Chromium 110.0.5481.77 is currently in stable and unstable (not yet
> in testing because of various delays). Please try with that instead.

Hallo,

The bug also exists in version 110.0.5481.77-2.

I have been experiencing this bug since many releases anyway, it's not
a recent regression.

Best,
Amr

Bug#1031821: libreswan: remote crash, CVE-2023-23009

2023-02-27 Thread Paul Wouters




Yes, the denial of service can only be triggered after the user has been
authenticated.

Bug#1030983: gdnsd may FTBFS on 32-bit platforms, e.g. on hppa

2023-02-27 Thread Faidon Liambotis

Hi Helge,

On Sun, Feb 26, 2023 at 01:06:16PM +0100, Helge Deller wrote:
> > So, from what I can tell, this is not something that I can fix locally
> > within gdnsd right now. AIUI what would need to happen is that libev
> > would need to be build with LFS support first, which would mean
> > rebuilding it with future=+lfs, breaking its ABI in the process,
> > requiring an ABI bump, and in turn a transition during which all of its
> > reverse dependencies will need sourceful uploads as to be modified to
> > also pass future=+lfs/-D_FILE_OFFSET_BITS=64, and then to be rebuilt
> > themselves (and possibly also affecting their reverse-dependency chains
> > as well).
> 
> Correct. Not something which is possible now.
> 
> But I have another idea.
> We don't need to touch libev for now.
> Instead the only thing which currently may fail is the readdir() in
> src/zsrc_rfc1035.c.  If we get this call to use the 64-bit variant we
> are done.
> 
> Attached is a proposed patch. It just changes this specific readdir()
> and is independend of libev.
> I've sucessfully tested it on the hppa architecture, and I hope it
> compiles the same way on all other platforms too.
> Could you check?

I don't think that's right. I think there are two independent LFS issues
with current builds of gdnsd:
1) the readdir() call in the rfc1035 zonefile parser (src/zsrc_rfc1035.c)
2) the stat() calls, via ev_stat_init etc., in the mon and extfile plugins.

These two issues are in different parts of gdnsd, and independent from
each other.

(1) is contained within gdnsd, and thus building with future=+lfs, as
you originally suggested, addresses this issue. Your readdir64() patch
also addresses this issue, and is functionally the same in that regard:
AIUI with _FILE_OFFSET_BITS=64, glibc implements readdir() with a
readdir64() system call.

However, (2) is not self-contained, with stat structures crossing an ABI
boundary (libev's). Hence why the test suite (legitimately) fails when
building with future=+lfs.

My understanding is that patching (1) with the patch you attached, but
not building with future=+lfs, ill effectively still create a binary
that does not have large file/inode support, as the stat() calls that
the mon/extfile plugins make, will not work on 64-bit inode filesystems.

Does this make sense?

Faidon

Bug#1032083: python-editor: New upstream version 1.0.4, BUT name conflict with PyPi

2023-02-27 Thread Andrew Chadwick

Source: python-editor
Version: 1.0.3-3
Severity: normal
X-Debbugs-Cc: a.t.chadw...@gmail.com

Dear Maintainer,

There is a new upstream version of this package available, version 1.0.4, 
released in Feb 2019. Please can it be packaged for Debian?

   Git: https://github.com/fmoo/python-editor
   PyPi: none?
   Interface: editor.edit()
   Author: fmoo


However, and perhaps more notably, there is an unrelated package called 
“editor” in PyPi that does the same thing, but which turns out to be 
significantly more modern and more regularly maintained.

   Git: https://github.com/rec/editor
   PyPi: https://pypi.org/project/editor/
   Interface: editor.editor()
   Author: rec (Tom Ritchford)

I suspect that *this* is what many Python application devs will be using 
when they need to launch an editor, because they’ll be looking in PyPi 
first. I’ve made that mistake myself, thinking it’s a newer version of the 
Debian packaged “editor”, then got worried by the apparently huge version 
bump and changed interface before twigging that the two projects are 
unrelated.


I suppose handling the name clash is really a policy matter for Debian’s 
Python team. Does it even matter? Do, or should, Debian builds of python 
packages generally have the same name as their PyPi equivalents? It’s 
pretty confusing if they don’t match up.

Perhaps the solution would be to rename “python-editor” to 
“python-editor-fmoo” or similar, with sensible migration headers, and 
package a new “python-editor” whose name matches PyPi. Or some virtual 
package or Alternatives mechanism, maybe.


Anyway, thanks for your consideration, whichever way this goes :)


   regards,
   Andrew

Bug#987008: please review this grub patch to fix LVM rename support

Hi Peter,

I'm writing to you as the author of this patch in grub:

https://git.savannah.gnu.org/cgit/grub.git/commit/?id=879c4a8342eacc0ba4b9dd11dc69d3ec3dbe73af

We've had a report of a release-critical bug (in CC) against grub in
Debian that claims boot failures after renaming a logical volume:

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

The suggested patch (author in CC) is quite short:

---
Index: grub2-2.02+dfsg1/grub-core/disk/lvm.c
===
--- grub2-2.02+dfsg1.orig/grub-core/disk/lvm.c
+++ grub2-2.02+dfsg1/grub-core/disk/lvm.c
@@ -253,7 +253,7 @@ error_parsing_metadata:

   p = q = (char *)ptr;

-  if (grub_add ((grub_size_t)metadatabuf, (grub_size_t)mda_size, ))
+  if (grub_add (ptr, (grub_size_t)grub_le_to_cpu64 (rlocn->size), ))
 goto error_parsing_metadata;

   mda_end = (char *)ptr;


I have tried to review the patch but quickly got lost in this long
function, so I'm not sure it's the right fix.

Could you expand on the rationale on why the rlocn->offset is checked
first but mda_size instead of rlocn->size in the second case?

Thank you for any input,

a.


signature.asc
Description: PGP signature

Bug#1031839: network devices do not work after kernel upgrade

2023-02-27 Thread Diederik de Haas

On Friday, 24 February 2023 00:28:33 CET Thorsten Alteholz wrote:
> upgrading from kernel 5.18.5-1 to 6.1.8-1 (and 6.1.12-1) network devices
> using driver module ixgbe stop working. The devices are recognized and can
> be configured but "ip a" shows "no-carrier" for them.
> With kernel 5.18.5-1 everthing works fine.

There have been quite a few Debian kernel between those version and it would 
be useful to narrow that range. You can find various deb files for amd64 here:
https://snapshot.debian.org/binary/linux-image-amd64/

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

Bug#1032082: sox: After security update, sox reports WAV file bits per sample is zero

2023-02-27 Thread Vidicode Support

Package: sox
Version: 14.4.2+git20190427-2+deb11u1
Severity: normal
X-Debbugs-Cc: t...@security.debian.org

Dear Maintainer,

We encounter an error that occurs after upgrading to 
14.4.2+git20190427-2+deb11u1,
and disappears when downgrading to version 14.4.2+git20190427-2.
Both sox and soxi report an error for wave files with GSM codec,
that were created using libsndfile.

$ soxi test.wav
soxi FAIL formats: can't open input file `test.wav': WAV file bits per sample 
is zero

After the error, it does not futher process the file.
Previously, it would output information about the file or process it (convert 
it).

The bits per sample in the wave file header is indeed zero.
The number of bits per sample is dynamic for the GSM codec.
Previously sox and soxi would parse and handle such files without problems.

-- System Information:
Debian Release: 11.6
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (100, 'bullseye-fasttrack')
Architecture: amd64 (x86_64)

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

Versions of packages sox depends on:
ii  libc6 2.31-13+deb11u5
ii  libsox-fmt-alsa   14.4.2+git20190427-2+deb11u1
ii  libsox-fmt-ao 14.4.2+git20190427-2+deb11u1
ii  libsox-fmt-base   14.4.2+git20190427-2+deb11u1
ii  libsox-fmt-oss14.4.2+git20190427-2+deb11u1
ii  libsox-fmt-pulse  14.4.2+git20190427-2+deb11u1
ii  libsox3   14.4.2+git20190427-2+deb11u1

sox recommends no packages.

Versions of packages sox suggests:
ii  libsox-fmt-all  14.4.2+git20190427-2+deb11u1

-- no debconf information

Bug#987008: grub LVM bug #987008: experimental package available, please test

2023-02-27 Thread Hoyer, David

I was not able to use the grub2 build as-is because we are running bullseye and 
the built image required newer versions of glibc.
However, I grabbed the original source code from Debian and the Debian code 
patch from https://people.debian.org/~anarcat/debian/sid/ and rebuilt it myself 
with minor tweaks so that it would build in bullseye (changed gcc-12 to gcc-10) 
and loaded it onto a system.
When running the test case Rogier which failed previously (fails within 120 
iterations), it is now passing with >1000 iterations.

Bug#1032060: [Pkg-puppet-devel] Bug#1032060: puppetserver setup ca does not finish setup