Bug#1024376: [Pkg-rust-maintainers] Bug#1024376: rust-derive-builder: please update to to v0.11

[Peter Michael Green]

Please upgrade to newer upstream branch v0.11.
The new version depends on rust-derive-builder-macro which is not 
currently in Debian.

Bug#1024472: RM: jpeg-xl/experimental -- NVIU; Unstable version not available on s390x

[Bas Couwenberg]

Package: ftp.debian.org
Severity: normal

Please remove jpeg-xl from experimental, it has a newer version in unstable.

The version in experimental is built on s390x which the unstable version is not 
(#1023746).

Kind Regards,

Bas

Bug#1019645: ruby-otr-activerecord: diff for NMU version 2.1.1-0.1

[Adrian Bunk]

Control: tags 1019645 + patch
Control: tags 1019645 + pending

Dear maintainer,

I've prepared an NMU for ruby-otr-activerecord (versioned as 2.1.1-0.1) 
and uploaded it to DELAYED/14. Please feel free to tell me if I should 
cancel it.

cu
Adrian
diff -Nru ruby-otr-activerecord-2.0.3/CHANGELOG.md ruby-otr-activerecord-2.1.1/CHANGELOG.md
--- ruby-otr-activerecord-2.0.3/CHANGELOG.md	2021-10-23 04:51:04.0 +0300
+++ ruby-otr-activerecord-2.1.1/CHANGELOG.md	2022-01-30 20:26:56.0 +0200
@@ -1,3 +1,9 @@
+### 2.1.0 (2022-01-30)
+* Don't set logger - allows apps to do that - [PR #28](https://github.com/jhollinger/otr-activerecord/pull/28) - [anakinj](https://github.com/anakinj)
+
+### 2.0.4 (2022-01-20)
+* Fix YAML loading on Ruby 3.1 - [PR #39](https://github.com/jhollinger/otr-activerecord/pull/39) - [scudelletti](https://github.com/scudelletti)
+
 ### 2.0.3 (2021-10-22)
 * Preliminary support for ActiveRecord 7 (tested against 7.0.0.alpha2)
 
diff -Nru ruby-otr-activerecord-2.0.3/debian/changelog ruby-otr-activerecord-2.1.1/debian/changelog
--- ruby-otr-activerecord-2.0.3/debian/changelog	2021-12-02 20:00:23.0 +0200
+++ ruby-otr-activerecord-2.1.1/debian/changelog	2022-11-20 10:21:15.0 +0200
@@ -1,3 +1,11 @@
+ruby-otr-activerecord (2.1.1-0.1) unstable; urgency=low
+
+  * Non-maintainer upload.
+  * New upstream release.
+- Fixes FTBFS with Ruby 3.1. (Closes: #1019645)
+
+ -- Adrian Bunk   Sun, 20 Nov 2022 10:21:15 +0200
+
 ruby-otr-activerecord (2.0.3-3) unstable; urgency=medium
 
   * Team upload.
diff -Nru ruby-otr-activerecord-2.0.3/debian/patches/Fix-tests-for-AR-6.0.patch ruby-otr-activerecord-2.1.1/debian/patches/Fix-tests-for-AR-6.0.patch
--- ruby-otr-activerecord-2.0.3/debian/patches/Fix-tests-for-AR-6.0.patch	2021-12-02 20:00:23.0 +0200
+++ ruby-otr-activerecord-2.1.1/debian/patches/Fix-tests-for-AR-6.0.patch	1970-01-01 02:00:00.0 +0200
@@ -1,49 +0,0 @@
-From: Jordan Hollinger 
-Date: Wed, 1 Dec 2021 21:16:09 -0500
-Subject: Fix tests for AR 6.0
-
-https://github.com/jhollinger/otr-activerecord/commit/95e85f1a5429553548609cd08401c46c880ab36f.patch
-Bug: https://github.com/jhollinger/otr-activerecord/issues/38
-Forwarded: not-needed

- spec/otr-activerecord/activerecord_spec.rb | 20 
- 1 file changed, 8 insertions(+), 12 deletions(-)
-
-diff --git a/spec/otr-activerecord/activerecord_spec.rb b/spec/otr-activerecord/activerecord_spec.rb
-index a055f32..3005443 100644
 a/spec/otr-activerecord/activerecord_spec.rb
-+++ b/spec/otr-activerecord/activerecord_spec.rb
-@@ -7,12 +7,10 @@ RSpec.describe OTR::ActiveRecord do
- 
-   it 'configures active record' do
- described_class.configure_from_file!(config)
--
--expect(::ActiveRecord::Base.configurations['test']).to eq(
--  adapter: 'sqlite3',
--  database: 'tmp/simple.sqlite3',
--  migrations_paths: ['db/migrate']
--)
-+t = ::ActiveRecord::Base.configurations['test'].with_indifferent_access
-+expect(t[:adapter]).to eq 'sqlite3'
-+expect(t[:database]).to eq 'tmp/simple.sqlite3'
-+expect(t[:migrations_paths]).to eq ['db/migrate']
-   end
- end
- 
-@@ -21,12 +19,10 @@ RSpec.describe OTR::ActiveRecord do
- 
-   it 'configures active record' do
- described_class.configure_from_file!(config)
--
--expect(::ActiveRecord::Base.configurations['test']).to eq(
--  adapter: 'sqlite3',
--  database: 'tmp/multi.sqlite3',
--  migrations_paths: ['db/migrate']
--)
-+t = ::ActiveRecord::Base.configurations['test'].with_indifferent_access
-+expect(t[:adapter]).to eq 'sqlite3'
-+expect(t[:database]).to eq 'tmp/multi.sqlite3'
-+expect(t[:migrations_paths]).to eq ['db/migrate']
-   end
- end
-   end
diff -Nru ruby-otr-activerecord-2.0.3/debian/patches/series ruby-otr-activerecord-2.1.1/debian/patches/series
--- ruby-otr-activerecord-2.0.3/debian/patches/series	2021-12-02 20:00:23.0 +0200
+++ ruby-otr-activerecord-2.1.1/debian/patches/series	2022-11-20 10:21:15.0 +0200
@@ -1,2 +1 @@
 Require-bundler-for-tests.patch
-Fix-tests-for-AR-6.0.patch
diff -Nru ruby-otr-activerecord-2.0.3/examples/rack-activerecord7.0/config.ru ruby-otr-activerecord-2.1.1/examples/rack-activerecord7.0/config.ru
--- ruby-otr-activerecord-2.0.3/examples/rack-activerecord7.0/config.ru	1970-01-01 02:00:00.0 +0200
+++ ruby-otr-activerecord-2.1.1/examples/rack-activerecord7.0/config.ru	2022-01-30 20:26:56.0 +0200
@@ -0,0 +1,15 @@
+require_relative 'environment'
+
+use OTR::ActiveRecord::ConnectionManagement
+use OTR::ActiveRecord::QueryCache
+
+map '/' do
+  run ->(env) {
+body = Widget.all
+  .map { |w|
+{id: w.id, name: w.name}
+  }
+  .to_json
+[200, {'Content-Type' => 'application/json', 'Content-Length' => body.size.to_s}, [body]]
+  }
+end
diff -Nru ruby-otr-activerecord-2.0.3/examples/rack-a

Bug#1024473: RM: gimp/experimental [s390x] -- RoQA; jpeg-xl not available on s390x

[Bas Couwenberg]

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

Please remove gimp in experimental on s390x to unblock the removal of the old 
jpeg-xl version in experimental.

Kind Regards,

Bas

Bug#1022495: ufo-extractor: FTBFS: AttributeError: '_TTGlyphGlyf' object has no attribute '_glyph'

[s3v]

Control: forwarded -1 https://github.com/robotools/extractor/pull/52
thanks

Dear Maintainer,

after applying aforementioned commits, I was able to build your package
in a sid chroot environment.

Kind Regards

Bug#1024474: pacman-package-manager_6.0.2-2_mips64el-buildd.changes REJECTED

[Aurelien Jarno]

Source: pacman-package-manager
Version: 6.0.2-2
Severity: serious

On 2022-11-20 00:06, Debian FTP Masters wrote:
> Version check failed:
> Your upload included the binary package libalpm-dev, version 13.0.2-1, for 
> mips64el,
> however testing already has version 13.0.2-1.
> Uploads to unstable must have a higher version than present in testing.
> 
> Mapping sid to unstable.
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 
> 
> 

Bug#1022340: redmine: FTBFS: Could not find gem 'csv (~> 3.2.0)' in cached gems or installed locally. The source contains the following gems matching 'csv': csv-3.1.9

[Adrian Bunk]

Control: block -1 by 1023495

On Thu, Oct 27, 2022 at 12:18:13AM +0900, Marc Dequènes wrote:
> Quack,
> 
> Thanks for the report.
> 
> When I first read the logs I could not fathom what was going on: we B-D on
> ruby-csv (>= 3.2.0) and it's not even installed!
> So it happens that libruby3.0 provides ruby-csv but it explicitly specify
> ruby-csv (= 3.1.9).
> I seems the resolver is confused by the fact libruby3.0 also has to be
> present to satisfy another dep.
>...

The resolver is working as it should:
One package that fulfills the dependency is installed (libruby3.1).

The easiest way to resolve this would be to wait until 3.1 becomes the 
default soon (#1023495), which should fix this FTBFS.

> Regards.
> \_o<

cu
Adrian

Bug#1023124: How i fixed my system

[Salvo Tomaselli]

For anyone finding this after the fact.

I had to remove dpkg-fsys-usrunmess.

Use aptitude because apt's crap resolver won't do it.

aptitude --allow-remove-essential  install usrmerge
aptitude  remove dpkg-fsys-usrunmess

Then I manually (with a script) had to delete a bunch of duplicated
files, because I had older files in /lib and newer ones in /usr/lib.

This is the script, don't run it blindly

while /usr/lib/usrmerge/convert-usrmerge 2>&1 | grep Both | cut -d\
-fusrmerge; do
/usr/lib/usrmerge/convert-usrmerge 2>&1  | grep Both | cut -d\   -f 4
rm $(/usr/lib/usrmerge /convert-usrmerge 2>&1  | grep Both | cut -d\   -f 4)
done

After this, I could run again

aptitude install  usrmerge

After this, the system seems in an upgradable state again.

--
Salvo Tomaselli

"Io non mi sento obbligato a credere che lo stesso Dio che ci ha dotato di
senso, ragione ed intelletto intendesse che noi ne facessimo a meno."
-- Galileo Galilei

https://ltworf.github.io/

Bug#1024040: mariadb-10.6: FTBFS on alpha: relocation truncated to fit: GPREL16 against symbol `wsrep_debug'

[Michael Cree]

On Sun, Nov 13, 2022 at 02:49:11PM -0800, Otto Kekäläinen wrote:
> Source: mariadb-10.6
> Version: 1:10.6.7-1
> Tags: upstream, confirmed, ftbfs
> User: debian-al...@lists.debian.org
> Usertags: alpha
> X-Debbugs-CC: debian-al...@lists.debian.org
> 
> After upload of mariadb-10.6 1:10.6.7-1 I noticed that alpha builds
> at https://buildd.debian.org/status/package.php?p=mariadb-10.6 were
> failing:

[snip]

> ./builddir/sql/./sql/wsrep_client_service.cc:77:(.text+0x140):
> relocation truncated to fit: GPREL16 against symbol `wsrep_debug'
> defined in .sbss section in ../../sql/libwsrep.a(wsrep_mysqld.cc.o)
> ../../sql/libwsrep.a(wsrep_client_service.cc.o): in function
> `Wsrep_client_service::cleanup_transaction()':

There is a work around for this.  Linking with --no-relax fixes the
problem.  I have a patch for this somewhere.  Ah, yes, add to
/debian/rules the following:

fneq (,$(filter $(DEB_HOST_ARCH_CPU),alpha))
LDFLAGS+=-Wl,--no-relax
endif

Cheers,
Michael.

Bug#992409: prometheus-node-exporter-collectors: locale issue leads to an unparseable smartmon textfile

[Petter Reinholdtsen]

Control: found -1 0+git20210115.7d89f19-1
Control: tags -1 + patch

[Daniel Swarbrick]
> Sadly I am not able to reproduce this (in a de_DE.UTF-8 locale).

I ran into this on a machine using the nb_NO.UTF-8 locale.

My journald log swould show lines like tihs:

nov. 20 10:48:41 somehost prometheus-node-exporter[3154]: level=error 
ts=2022-11-20T09:48:41.802Z caller=textfile.go:209 collector=textfile 
msg="failed to collect textfile data" file=smartmon.prom err="failed to parse 
textfile data from \"/var/lib/prometheus/node-exporter/smartmon.prom\": text 
format parsing error in line 6: expected float as value, got \"1,00e+00\""

I fixed it by adding the following code snippet at the start of
/usr/share/prometheus-node-exporter-collectors/smartmon.sh:

  LC_ALL=C
  export LC_ALL


--- smartmon.sh.old2022-11-20 11:04:25.743602052 +0100
+++ smartmon.sh  2022-11-20 10:49:33.866521913 +0100
@@ -10,6 +10,9 @@
 # Formatting done via shfmt -i 2
 # https://github.com/mvdan/sh
 
+LC_ALL=C
+export LC_ALL
+
 parse_smartctl_attributes_awk="$(
   cat <<'SMARTCTLAWK'
 $1 ~ /^ *[0-9]+$/ && $2 ~ /^[a-zA-Z0-9_-]+$/ {

-- 
Happy hacking
Petter Reinholdtsen

Bug#1024355: opensysusers: fails to first-install

[Samuel Thibault]

Andrea Pappacoda, le sam. 19 nov. 2022 00:21:08 +0100, a ecrit:
> Strange... I too noticed that version 0.7.3-1 introduced a piuparts error,
> but the release is pretty much identical to 0.7.2-1, as 0.7.2-1 already
> contained the only new upstream commit in 0.7.3.

It seems it's install_init which in the newer version of debhelper added
these lines, which thus expected -u not to be set.

Samuel

Bug#1022262: src:g2clib: fails to migrate to testing for too long: FTBFS on i386

[Adrian Bunk]

Control: tags -1 patch

On Sun, Oct 23, 2022 at 09:04:03AM +0200, Paul Gevers wrote:
> Source: g2clib
> Version: 1.6.4-3
> Severity: serious
> Tags: sid bookworm ftbfs
> User: release.debian@packages.debian.org
> Usertags: out-of-sync
> 
> Dear maintainer(s),
> 
> The Release Team considers packages that are out-of-sync between testing and
> unstable for more than 60 days as having a Release Critical bug in testing
> [1]. Your package src:g2clib has been trying to migrate for 61 days [2].
> Hence, I am filing this bug. You latest upload failed to build on i386 while
> it built successfully there in the past.
>...

The problem is the excess precision of the x87 FPU, if exact results are 
required the patch below works around the isssue.

cu
Adrian

--- debian/rules.old2022-11-20 10:01:52.961269222 +
+++ debian/rules2022-11-20 10:02:10.997265167 +
@@ -6,6 +6,10 @@
 %:
dh $@ --buildsystem=cmake --builddirectory=debian/build
 
+ifeq ($(DEB_HOST_ARCH_CPU),i386)
+  export DEB_CFLAGS_MAINT_APPEND = -ffloat-store
+endif
+
 DESTDIR:=$(CURDIR)/debian/tmp/
 DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
 LIBDIR:=/usr/lib/$(DEB_HOST_MULTIARCH)

Bug#900928: RFP: fractal -- Matrix group messaging app

[Jonas Smedegaard]

5.0.0~~git20221105 draft 5 needs embedding 140 crates (73 missing, 3 broken, 49 
outdated, 15 ahead); works fine; newer code requires rustc 1.63.

Main task now is to wait for Rust team to upgrade rustc: GIO/GLIB crates v0.16 
and GStreamer crates v0.19 require rustc 1.63.

Here's how you can help:

As user running Debian, you can test this draft package: Either build it 
yourself from source or tell (by posting to this bugreport) if you prefer 
testing the binary packages I built - then I will share those.

As developer (but no need to be official member of Debian!), you can join the 
Debian Rust team and help package these missing crates: 
https://salsa.debian.org/matrix-team/fractal/-/blob/debian/latest/debian/TODO


 - Jonas

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

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

signature.asc
Description: signature

Bug#1022681: haskell-clientsession build depends on haskell-cipher-aes and haskell-cprng-aes

[Ilias Tsitsimpis]

Hi Adrian, Sean,

On Sun, Nov 20, 2022 at 01:44AM, Adrian Bunk wrote:
> Ilias, this bug is the reason why your removal notices for 
> haskell-{cipher,cprng}-aes are about to kick git-annex out
> of bookworm.
> 
> To keep git-annex in bookworm, it's either applying one of the two 
> upstream MRs for haskell-clientsessionor postponing the removal notices
> for haskell-{cipher,cprng}-aes.

We can postpone the removal notices (I will downgrade them to Important)
and keep git-annex in bookworm. But I would really like to see this
fixed. haskell-clientsession is clearly unmaintained (last upstream
commit is from 2016, and they have ignored both PRs).

Sean, can you please ask the author of git-annex to either remove the
dependency on clientsession, or consider a take over of this package?

Best,

-- 
Ilias

Bug#900821: Found working and failing 5.10 versions and got kernel crash, report from BSP Tilburg (https://deb.li/iiOID)

[Diederik de Haas]

Control: found -1 5.14.9-2 5.15.5-2
Control: fixed -1 5.15.15-2 5.16.11-1 5.18.16-1 6.0.3-1

On zaterdag 19 november 2022 21:22:46 CET Diederik de Haas wrote:
> found 900821 5.10.70-1
> fixed 900821 5.10.84-1

I continued testing with kernels from backports and updated metadata 
accordingly.

Interesting to note is that the 2 kernels that failed, did NOT show any 
message either in my ssh session nor in `dmesg`.

Also interesting is that when it failed, it *always* failed at the first run.

So in conclusion, in *current* Stable and Testing and Unstable the issue is 
fixed!diederik@prancing-pony:~/dev/debian/bugs/900821$ ssh vm-bullseye
Linux debian-bullseye 5.14.0-0.bpo.2-amd64 #1 SMP Debian 5.14.9-2~bpo11+1 
(2021-10-10) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Nov 20 11:22:02 2022 from 192.168.122.1
debian@debian-bullseye:~$ dpkg -l | grep linux-image
ii  linux-image-5.10.0-10-amd645.10.84-1  
amd64Linux 5.10 for 64-bit PCs (signed)
ii  linux-image-5.10.0-19-amd645.10.149-2 
amd64Linux 5.10 for 64-bit PCs (signed)
ii  linux-image-5.10.0-9-amd64 5.10.70-1  
amd64Linux 5.10 for 64-bit PCs (signed)
ii  linux-image-5.14.0-0.bpo.2-amd64   5.14.9-2~bpo11+1   
amd64Linux 5.14 for 64-bit PCs (signed)
ii  linux-image-5.15.0-0.bpo.2-amd64   5.15.5-2~bpo11+1   
amd64Linux 5.15 for 64-bit PCs (signed)
ii  linux-image-5.15.0-0.bpo.3-amd64   5.15.15-2~bpo11+1  
amd64Linux 5.15 for 64-bit PCs (signed)
ii  linux-image-5.16.0-0.bpo.3-amd64   5.16.11-1~bpo11+1  
amd64Linux 5.16 for 64-bit PCs (signed)
ii  linux-image-5.16.0-0.bpo.4-amd64   5.16.12-1~bpo11+1  
amd64Linux 5.16 for 64-bit PCs (signed)
ii  linux-image-5.18.0-0.bpo.1-amd64   5.18.2-1~bpo11+1   
amd64Linux 5.18 for 64-bit PCs (signed)
ii  linux-image-5.18.0-0.deb11.4-amd64 5.18.16-1~bpo11+1  
amd64Linux 5.18 for 64-bit PCs (signed)
ii  linux-image-6.0.0-0.deb11.2-amd64-unsigned 6.0.3-1~bpo11+1
amd64Linux 6.0 for 64-bit PCs
ii  linux-image-amd64  5.10.149-2 
amd64Linux for 64-bit PCs (meta-package)
debian@debian-bullseye:~$ mount /var/www/html/
debian@debian-bullseye:~$ sha256sum /var/www/html/100Mzero 
20492a4d0d84f8beb1767f6616229f85d44c2827b64bdbfb260ee12fa1109e0e  
/var/www/html/100Mzero
debian@debian-bullseye:~$ ./bug900821 
sha256sum should be:
   20492a4d0d84f8beb1767f6616229f85d44c2827b64bdbfb260ee12fa1109e0e

. 
Bug 900821 triggered! Calculated SHA256: 
5d9654b5f3258475e95313f7228fe142ad59f860e6d58ff4f47394bdc0b791ce
debian@debian-bullseye:~$ su -l
Password: 
root@debian-bullseye:~# reboot
Connection to 192.168.122.2 closed by remote host.
Connection to 192.168.122.2 closed.
diederik@prancing-pony:~/dev/debian/bugs/900821$ ssh vm-bullseye
Linux debian-bullseye 5.15.0-0.bpo.2-amd64 #1 SMP Debian 5.15.5-2~bpo11+1 
(2022-01-02) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Nov 20 11:24:06 2022 from 192.168.122.1
debian@debian-bullseye:~$ mount /var/www/html/
debian@debian-bullseye:~$ sha256sum /var/www/html/100Mzero 
20492a4d0d84f8beb1767f6616229f85d44c2827b64bdbfb260ee12fa1109e0e  
/var/www/html/100Mzero
debian@debian-bullseye:~$ ./bug900821 
sha256sum should be:
   20492a4d0d84f8beb1767f6616229f85d44c2827b64bdbfb260ee12fa1109e0e

. 
Bug 900821 triggered! Calculated SHA256: 
7f7320e116b21b9867e42d8317dfd28a7c102ad7f5d28903debea699a144
debian@debian-bullseye:~$ su -l
Password: 
root@debian-bullseye:~# reboot
Connection to 192.168.122.2 closed by remote host.
Connection to 192.168.122.2 closed.
diederik@prancing-pony:~/dev/debian/bugs/900821$ ssh vm-bullseye
Linux debian-bullseye 5.15.0-0.bpo.3-amd64 #1 SMP Debian 5.15.15-2~bpo11+1 
(2022-02-03) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Nov 20 11:30:30 2022 from 192.168.122.1
debian@debian-bullseye:~$ mount /var/www/html/
debian@debian-bullseye:~$ sha256sum /var/www/html/100Mzero 
20492a4d0d84f8beb1767f6616229f85d44c2827b64b

Bug#900821: Found working and failing 5.10 versions and got kernel crash, report from BSP Tilburg (https://deb.li/iiOID)

[Diederik de Haas]

Control: found -1 5.14.9-2 
Control: found -1 5.15.5-2
Control: fixed -1 5.15.15-2
Control: fixed -1 5.16.11-1
Control: fixed -1 5.18.16-1
Control: fixed -1 6.0.3-1

On zondag 20 november 2022 12:18:50 CET you wrote:
> Control: found -1 5.14.9-2 5.15.5-2
> Control: fixed -1 5.15.15-2 5.16.11-1 5.18.16-1 6.0.3-1

That doesn't seem to work and I probably should just use the last version
for 'found' and the first one for 'fixed', but I wanted to make sure (and log) 
that the latter ones *all* are fixed.

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

Bug#940511: Our mutual interest in /usr/bin/yarn

[Geert Stappers]

On Wed, Nov 09, 2022 at 09:21:15PM +0100, Geert Stappers wrote:
> Hello JavasScript people,
> Hello Python people,
> 
:-)

> 
> We both want to use /usr/bin/yarn for a program,
> unfortunately different programs.
> 
> What about agreeing on a disagreement?
> 
> So binary packages cmdtest and yarnpkg  conflict each other?
> 

After rethinking that:  It might work for a large part,
but it realy blocks the people who want to install both packages.


The plan is now to patch the debian yarnpkg package
so it has clearly visible that it provides `yarn`.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1024475: basket: Loses gpgme integration when rebuilt against gpgme 1.18.0-2

[Andreas Metzler]

Package: basket
Version: 2.49-1
Severity: important
User: pkg-gnupg-ma...@lists.alioth.debian.org
Usertags: gpgme-config-transition

Hello,

basket relies on gpgme-config to detect gpgme. gpgme-config has been
dropped and replaced by pkg-config pc files.

cu Andreas

Bug#1024476: RM: python-ipaddress -- ROM; py2 leftover

[Bastian Germann]

Package: ftp.debian.org

python-ipaddress is a backport of a Python 3 feature and is no longer needed.
The only reverse dependency is vanguards which needs to be converted to Python 3
anyway. Please remove python-ipaddress.

Bug#1024477: xserver-xorg-input-libinput: scrolling does not work anymore on elan touchpad

[Jens Rapp]

Package: xserver-xorg-input-libinput
Version: 1.2.1-1+b1
Severity: important
X-Debbugs-Cc: docjun...@web.de

Dear Maintainer,

I recently made some apt upgrade on my machine and after reboot, my touchpad
does not scroll anymore.
libinput debug-gui does not show any reaction on scrolling attempts.

Touchpad is now mentioned as generic mouse

$ sudo libinput list-devices
..
Device:   PS/2 Generic Mouse
Kernel:   /dev/input/event8
Group:7
Seat: seat0, default
Capabilities: pointer
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock:n/a
Left-handed:  disabled
Nat.scrolling:disabled
Middle emulation: disabled
Calibration:  n/a
Scroll methods:   *button
Click methods:none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles:   flat *adaptive
Rotation: n/a
..

My computer is a Lenovo e15 Gen 4 (21E6CTO1WW).
Concerning to https://linux-hardware.ru/?probe=ea83ab47fe (only hint i've found
on this)
my notebook uses an elan-001b ps2 touchpad.

I've found on internet some tips like trying to reload psmouse module via
# modprobe -r psmouse
# modprobe psmouse

which had the effect that my mouse didn't do anything anymore

I also found a hint that I should enable module elan_i2c which had no effect
either.

If there is any other useful information you need, tell me.


-- Package-specific info:
/etc/X11/X does not exist.
/etc/X11/X is not a symlink.
/etc/X11/X is not executable.

VGA-compatible devices on PCI bus:
--
00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-UP3 GT2 
[Iris Xe Graphics] [8086:46a8] (rev 0c)

/etc/X11/xorg.conf does not exist.

Contents of /etc/X11/xorg.conf.d:
-
total 0

/etc/modprobe.d contains no KMS configuration files.

Kernel version (/proc/version):
---
Linux version 6.0.0-4-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-9) 12.2.0, GNU ld (GNU Binutils for Debian) 2.39) #1 SMP PREEMPT_DYNAMIC 
Debian 6.0.8-1 (2022-11-11)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 34494 Nov 11 14:57 /var/log/Xorg.1.log
-rw-r--r-- 1 root root 34784 Nov 20 12:44 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[16.441] 
X.Org X Server 1.21.1.4
X Protocol Version 11, Revision 0
[16.441] Current Operating System: Linux tecdroid 6.0.0-4-amd64 #1 SMP 
PREEMPT_DYNAMIC Debian 6.0.8-1 (2022-11-11) x86_64
[16.441] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-6.0.0-4-amd64 
root=UUID=9d4030d2-f3ac-48e5-833f-a53962e78147 ro quiet
[16.441] xorg-server 2:21.1.4-3 (https://www.debian.org/support) 
[16.441] Current version of pixman: 0.42.2
[16.441]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[16.441] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[16.441] (==) Log file: "/var/log/Xorg.0.log", Time: Sun Nov 20 12:44:52 
2022
[16.442] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[16.443] (==) No Layout section.  Using the first Screen section.
[16.443] (==) No screen section available. Using defaults.
[16.443] (**) |-->Screen "Default Screen Section" (0)
[16.443] (**) |   |-->Monitor ""
[16.443] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[16.443] (==) Automatically adding devices
[16.443] (==) Automatically enabling devices
[16.443] (==) Automatically adding GPU devices
[16.443] (==) Automatically binding GPU devices
[16.443] (==) Max clients allowed: 256, resource mask: 0x1f
[16.444] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[16.444]Entry deleted from font path.
[16.445] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[16.445] (==) ModulePath set to "/usr/lib/xorg/modules"
[16.445] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[16.445] (II) Loader magic: 0x55e02b79bf00
[16.445] (II) Module ABI versions:
[16.445]X.Org ANSI C Emulation: 0.4
[16.445]X.Org Video Driver: 25.2
[16.445]X.Org XInput driver : 24.4
[16.445]X.Org Server Extension : 10.0
[16.445] (++) using VT number 7

[16.445] (II) systemd-logind: logind integration requires -keeptty and 

Bug#1023917: cpm: FTBFS against libgpgme-dev >= 1.18.0-2 [checking for gpgme-config... no]

[Andreas Metzler]

Better patch atttached.

cu Andreas
--- cpm-0.32.orig/configure.in
+++ cpm-0.32/configure.in
@@ -353,29 +353,12 @@ PKG_CHECK_MODULES([LIBXML], [libxml-2.0]
 LIBXML_XMLLINT="$exec_prefix/bin/xmllint"
 AC_SUBST(LIBXML_XMLLINT)
 
-AC_PATH_PROG([GPGME_CONFIG], [gpgme-config])
-if test -z "$ac_cv_path_GPGME_CONFIG"; then
-  AC_MSG_ERROR([Could not find gpgme anywhere.])
-fi
-
-LIBGPGME_VERSION="`$GPGME_CONFIG --version | cut -d '.' -f 1,2 | sed -e 's/\\.//g'`"
-if test $LIBGPGME_VERSION -lt 10; then
-  AC_MSG_ERROR([GPGME must be version 1.0 or higher.])
-fi
-if test $LIBGPGME_VERSION -lt 11; then
-  AC_MSG_NOTICE([GpgME version lower than 1.1 found, recipients can't be detected automatically.])
-  WRAPPER_NECESSARY=1
-else
-  AC_MSG_NOTICE([GpgME version 1.1+ found. Enabling automatic recipient detection.])
+PKG_CHECK_MODULES([LIBGPGME], [gpgme >= 1.1.0],
   CFLAGS="${CFLAGS} -DGPGME_HAS_RECIPIENT"
   WRAPPER_NECESSARY=0
-fi
+)
 AC_SUBST(WRAPPER_NECESSARY)
 
-LIBGPGME_LIBS="`$GPGME_CONFIG --libs`"
-LIBGPGME_CFLAGS="-D_FILE_OFFSET_BITS=64 `$GPGME_CONFIG --cflags`"
-AC_SUBST(LIBGPGME_LIBS)
-AC_SUBST(LIBGPGME_CFLAGS)
 
 # --
 

Bug#1024398: lintian-brush: suggests removing moving udebs to oldlibs

[Jelmer Vernooij]

tags 1024398 +pending
user debian-rele...@lists.debian.org
usertag 1024398 + bsp-2022-11-nl-tilburg 
thanks

On Fri, Nov 18, 2022 at 07:37:19PM +, Simon McVittie wrote:
> To reproduce: clone source package gdk-pixbuf, reset to
> debian/2.42.9+dfsg-1 and run lintian-brush.
> 
> Expected result: libgdk-pixbuf2.0-0-udeb remains in
> Section: debian-installer and is not moved to Section: oldlibs.
> 
> Actual result: lintian-brush suggests moving it to oldlibs,
> which causes a Lintian warning:
> 
> > W: libgdk-pixbuf2.0-0-udeb udeb: wrong-section-for-udeb oldlibs
> > N:
> > N:   udeb packages should have "Section: debian-installer".
> > ...
> 
> I think Lintian is correct here: I would interpret "udebs should be in
> Section: debian-installer" as a higher-precedence rule than "transitional
> packages should be in Section: oldlibs".

Thanks for the detailed bug report - I've committed a fix that should make it
into 0.137.

Jelmer

Bug#1024478: ecryptfs-utils: FTBFS against libgpgme-dev >= 1.18.0-2 [Cannot locate gpgme]

[Andreas Metzler]

Package: ecryptfs-utils
Version: 111-5
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: pkg-gnupg-ma...@lists.alioth.debian.org
Usertags: gpgme-config-transition

ecryptfs-utils relies on gpgme-config to detect gpgme. gpgme-config has
been dropped and replaced by pkg-config pc files.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'
--- ecryptfs-utils-111.orig/configure.ac
+++ ecryptfs-utils-111/configure.ac
@@ -135,13 +135,6 @@ AC_ARG_ENABLE(
 )
 
 AC_ARG_WITH(
-	[gpgme-prefix],
-	[AS_HELP_STRING([--with-gpgme-prefix=PATH],[Specify the directory where gpgme install, default /usr])],
-	,
-	[with_gpgme_prefix="/usr"]
-)
-
-AC_ARG_WITH(
 	[pamdir],
 	[AS_HELP_STRING([--with-pamdir=PATH],[Specify the directory where PAM modules are stored])],
 	[pamdir="${withval}"],
@@ -315,14 +308,7 @@ if test "${enable_tspi}" = "yes" ; then
 fi
 
 if test "${enable_gpg}" = "yes" ; then
-	AC_MSG_CHECKING([for gpgme])
-	if ! test -x "${with_gpgme_prefix}/bin/gpgme-config"; then
-		AC_MSG_ERROR([Cannot locate gpgme])
-	else
-		AC_MSG_RESULT([found])
-		GPGME_CFLAGS="`\"${with_gpgme_prefix}/bin/gpgme-config\" --cflags`"
-		GPGME_LIBS="`\"${with_gpgme_prefix}/bin/gpgme-config\" --libs`"
-	fi
+	PKG_CHECK_MODULES([GPGME], [gpgme >= 1.0.0])
 fi
 
 if test "${enable_pam}" = "yes" ; then
@@ -385,8 +371,6 @@ AC_SUBST([pamlibdir])
 AC_SUBST([pkgconfigdir])
 AC_SUBST([rootsbindir])
 AC_SUBST([ecryptfskeymoddir])
-AC_SUBST([GPGME_CFLAGS])
-AC_SUBST([GPGME_LIBS])
 AC_SUBST([CRYPTO_CFLAGS])
 AC_SUBST([CRYPTO_LIBS])
 AM_CONDITIONAL([BUILD_OPENSSL], [test "${enable_openssl}" = "yes"])

Bug#1024479: orca: Keyboard layout is always US when in laptop layout and X is invoked manually withs startx

[Julian Dreykorn]

Package: orca
Version: 43.0-1
Severity: important
X-Debbugs-Cc: dreykorn.jul...@gmail.com

Dear Maintainer,

   * What led up to the situation?
* My keyboard layout is set to Germen
* I prefer to invoke the GUI manually when needed, so switched default 
systemctl target to multi-user
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
* Log into the text console and enter startx to start a GUI
* Switch Orca to laptop keyboard layout
* Although previously German, keyboard layout is now American
* As soon as I switch Orca back to desktop layout, the keyboard layout 
becomes German again
* Quitting the X session by logging out of mate also brings the keyboard 
layout back to normal, until I start X again.
   * What was the outcome of this action?
* Orca laptop keyboard schemes affects localization of the keyboard layout
   * What outcome did you expect instead?
* Orca keyboard scheme and keyboard localization should be independent from 
each other.



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

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

Versions of packages orca depends on:
ii  gir1.2-glib-2.01.74.0-2
ii  gir1.2-gstreamer-1.0   1.20.3-1
ii  gir1.2-gtk-3.0 3.24.34-3
ii  gir1.2-pango-1.0   1.50.10+ds-1
ii  gir1.2-wnck-3.043.0-2
ii  gsettings-desktop-schemas  43.0-1
ii  gstreamer1.0-plugins-good  1.20.3-1+b1
ii  python33.10.6-1
ii  python3-brlapi 6.5-4+b1
ii  python3-cairo  1.20.1-4
ii  python3-gi 3.42.2-2
ii  python3-louis  3.23.0-1
ii  python3-pyatspi2.46.0-1
ii  python3-speechd0.11.4-1
ii  speech-dispatcher  0.11.4-1
ii  xkbset 0.6-2

Versions of packages orca recommends:
ii  xbrlapi  6.5-4+b1

Versions of packages orca suggests:
ii  brltty  6.5-4+b1

-- no debconf information

Bug#938509: Snowballz vanished upstream - do we have the power to port it to Python3?

[Bastian Germann]

Control: retitle -1 RM: snowballz -- ROM (team); unsatisfiable dependency
Control: reassign -1 ftp.debian.org

On Sun, 9 Feb 2020 12:12:09 +0100 Reiner Herrmann  wrote:

The only problem is that it depends on rabbyt, which
doesn't support Python 3 yet (see: #938328).
There seems to be a fork of it with Python3 support,
but I don't know how well it works.


rabbyt was never ported to Python 3, so please remove snowballz, which would 
need rabbyt as a dependency.

Bug#1023601: libgpgme-dev: removal of gpgme-config breaks the build of software relying on it

[Andreas Metzler]

On 2022-11-18 Andreas Metzler  wrote:
[...]
> Quick test: updating gpgme.m4 from gpgme GIT lets mutt 2.2.7-1 build
> successfully if mutt's local copy m4/gpgme.m4 is removed. Afaiu aclocal
> documentation there is nothing we can do more, the included outdated
> gpgme.m4 is preferred.

gpgme.m4 is now up to date in sid.

See
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=gpgme-config-transition;users=pkg-gnupg-ma...@lists.alioth.debian.org
for progressing buglist.

cu Andreas

Bug#990828: mutt can not delete mails due to access rights

[Juan Pedro Vallejo]

Package: mutt
Version: 2.2.9-1
Followup-For: Bug #990828
X-Debbugs-Cc: jn...@ya.com

Hi.

"mutt_dotlock" is the one to blame:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root root 13804 Nov 13 18:01 /usr/bin/mutt_dotlock

This works for me:

# chown root:mail /usr/bin/mutt_dotlock
# chmod 2755 /usr/bin/mutt_dotlock

Now:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root mail 13804 Nov 13 18:01 /usr/bin/mutt_dotlock

Bye.

Bug#1024480: bullseye-pu: package libvncserver/0.9.13+dfsg-2+deb11u1

[Mike Gabriel]

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

[ Reason ]
Provide CVE fix contributed by the Debian LTS team; resolve annoying
screensize limit for people using large resolutions via VNC.

[ Impact ]
CVE issue stays unfixed; people with large screens cannot export
them via VNC.

[ Tests ]
Manual test (locally). CVE-2020-29260 has also been tested for LTS.

[ Risks ]
Code changes are rather trivial and non-invasive.

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

[ Changes ]

+  [ Mike Gabriel ]
+  * debian/patches:
++ Trivially rebase patches 0001 and 0002.

-> So that patches cleanly apply, chrerry-picked from unstable.

++ Add 0003-rfb-increase-update-buf-size.patch. Allow larger screen sizes.
+  (Closes: #1010449).

Allows for larger screensizes (1x 8k, 2x 4k, etc.).

+  [ Thorsten Alteholz ]
++ CVE-2020-29260: Add CVE-2020-29260.patch. Resolve memory leak in function
+  rfbClientCleanup(). (Closes: #1019228).

-> CVE-2020-29260 (no-dsa)

[ Other info ]
None.
diff -Nru libvncserver-0.9.13+dfsg/debian/changelog 
libvncserver-0.9.13+dfsg/debian/changelog
--- libvncserver-0.9.13+dfsg/debian/changelog   2021-02-28 15:37:06.0 
+0100
+++ libvncserver-0.9.13+dfsg/debian/changelog   2022-11-20 13:18:12.0 
+0100
@@ -1,3 +1,17 @@
+libvncserver (0.9.13+dfsg-2+deb11u1) bullseye; urgency=medium
+
+  [ Mike Gabriel ]
+  * debian/patches:
++ Trivially rebase patches 0001 and 0002.
++ Add 0003-rfb-increase-update-buf-size.patch. Allow larger screen sizes.
+  (Closes: #1010449).
+
+  [ Thorsten Alteholz ]
++ CVE-2020-29260: Add CVE-2020-29260.patch. Resolve memory leak in function
+  rfbClientCleanup(). (Closes: #1019228).
+
+ -- Mike Gabriel   Sun, 20 Nov 2022 13:18:12 +0100
+
 libvncserver (0.9.13+dfsg-2) unstable; urgency=medium
 
   [ Marco Trevisan (Treviño) ]
diff -Nru 
libvncserver-0.9.13+dfsg/debian/patches/0001-libvncserver-don-t-NULL-out-internal-of-the-default-.patch
 
libvncserver-0.9.13+dfsg/debian/patches/0001-libvncserver-don-t-NULL-out-internal-of-the-default-.patch
--- 
libvncserver-0.9.13+dfsg/debian/patches/0001-libvncserver-don-t-NULL-out-internal-of-the-default-.patch
 2021-02-28 15:35:53.0 +0100
+++ 
libvncserver-0.9.13+dfsg/debian/patches/0001-libvncserver-don-t-NULL-out-internal-of-the-default-.patch
 2022-11-20 13:17:58.0 +0100
@@ -15,11 +15,9 @@
  libvncserver/main.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)
 
-diff --git a/libvncserver/main.c b/libvncserver/main.c
-index 6477ee8..06efe6e 100644
 --- a/libvncserver/main.c
 +++ b/libvncserver/main.c
-@@ -1021,7 +1021,8 @@ void rfbScreenCleanup(rfbScreenInfoPtr screen)
+@@ -1110,7 +1110,8 @@
FREE_IF(underCursorBuffer);
TINI_MUTEX(screen->cursorMutex);
  
@@ -29,6 +27,3 @@
  
  #ifdef LIBVNCSERVER_HAVE_LIBZ
rfbZlibCleanup(screen);
--- 
-2.25.1
-
diff -Nru 
libvncserver-0.9.13+dfsg/debian/patches/0002-zlib-Clear-buffer-pointers-on-cleanup.patch
 
libvncserver-0.9.13+dfsg/debian/patches/0002-zlib-Clear-buffer-pointers-on-cleanup.patch
--- 
libvncserver-0.9.13+dfsg/debian/patches/0002-zlib-Clear-buffer-pointers-on-cleanup.patch
2021-02-28 15:35:53.0 +0100
+++ 
libvncserver-0.9.13+dfsg/debian/patches/0002-zlib-Clear-buffer-pointers-on-cleanup.patch
2022-11-20 13:17:58.0 +0100
@@ -26,11 +26,9 @@
  libvncserver/zlib.c | 2 ++
  1 file changed, 2 insertions(+)
 
-diff --git a/libvncserver/zlib.c b/libvncserver/zlib.c
-index ac20c9c..6b7731e 100644
 --- a/libvncserver/zlib.c
 +++ b/libvncserver/zlib.c
-@@ -63,11 +63,13 @@ void rfbZlibCleanup(rfbScreenInfoPtr screen)
+@@ -64,11 +64,13 @@
  {
if (zlibBeforeBufSize) {
  free(zlibBeforeBuf);
@@ -44,6 +42,3 @@
}
  }
  
--- 
-2.25.1
-
diff -Nru 
libvncserver-0.9.13+dfsg/debian/patches/0003-rfb-increase-update-buf-size.patch 
libvncserver-0.9.13+dfsg/debian/patches/0003-rfb-increase-update-buf-size.patch
--- 
libvncserver-0.9.13+dfsg/debian/patches/0003-rfb-increase-update-buf-size.patch 
1970-01-01 01:00:00.0 +0100
+++ 
libvncserver-0.9.13+dfsg/debian/patches/0003-rfb-increase-update-buf-size.patch 
2022-11-20 13:17:58.0 +0100
@@ -0,0 +1,28 @@
+From fdf67fb31ed583549ae2f8827593ec4eb3dfed5c Mon Sep 17 00:00:00 2001
+From: Christian Beier 
+Date: Mon, 9 May 2022 15:56:11 +0200
+Subject: [PATCH] rfb/rfb.h: increase UPDATE_BUF_SIZE by 2768 bytes
+
+Simply raise the default to 32768 which is not an awful lot of an
+increase and should not hurt the embedded guys.
+
+If someone needs more, we can still go down the malloc() route and
+make the buffer size configurable, but leave this to the users to
+request and KISS for now.
+
+Closes #521
+---
+ rfb/rfb.h | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+

Bug#900821: Found working and failing 5.10 versions and got kernel crash, report from BSP Tilburg (https://deb.li/iiOID)

[Salvatore Bonaccorso]

Hi,

On Sun, Nov 20, 2022 at 12:30:53PM +0100, Diederik de Haas wrote:
> Control: found -1 5.14.9-2 
> Control: found -1 5.15.5-2
> Control: fixed -1 5.15.15-2
> Control: fixed -1 5.16.11-1
> Control: fixed -1 5.18.16-1
> Control: fixed -1 6.0.3-1
> 
> On zondag 20 november 2022 12:18:50 CET you wrote:
> > Control: found -1 5.14.9-2 5.15.5-2
> > Control: fixed -1 5.15.15-2 5.16.11-1 5.18.16-1 6.0.3-1
> 
> That doesn't seem to work and I probably should just use the last version
> for 'found' and the first one for 'fixed', but I wanted to make sure (and 
> log) 
> that the latter ones *all* are fixed.

Seems the BSP was productive :). If you have spare cycles, might you
check if dacb5d8875cc ("tcp: fix page frag corruption on page fault")
in 5.16-rc4 is the commit we are searching? That one was backported to
the 5.10.y series in 5.10.84 and in 5.15.y series in 5.15.7 which
would fall into your found ranges as well.

OTOH, it fixes 5640f7685831 ("net: use a per task frag allocator")
which is way much longer back as where the people noticed to be
introduced.

Regards,
Salvatore

Bug#1024481: fwknop: FTBFS against libgpgme-dev >= 1.18.0-2 [--with-gpgme was given, but test for gpgme failed]

[Andreas Metzler]

Source: fwknop
Version: 2.6.10-13
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: pkg-gnupg-ma...@lists.alioth.debian.org
Usertags: gpgme-config-transition

fwknop ships an outdated version of gpgme.m4 in m4/ which cannot handle
the transition from gpgme-config to gpgrt-config. Deleteing the outdated
copy lets the build succeed.

cu Andreas
--- fwknop-2.6.10.orig/m4/gpgme.m4
+++ /dev/null
@@ -1,307 +0,0 @@
-# gpgme.m4 - autoconf macro to detect GPGME.
-# Copyright (C) 2002, 2003, 2004 g10 Code GmbH
-#
-# This file is free software; as a special exception the author gives
-# unlimited permission to copy and/or distribute it, with or without
-# modifications, as long as this notice is preserved.
-#
-# This file is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
-# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
-
-AC_DEFUN([_AM_PATH_GPGME_CONFIG],
-[ AC_ARG_WITH(gpgme-prefix,
-AC_HELP_STRING([--with-gpgme-prefix=PFX],
-   [prefix where GPGME is installed (optional)]),
- gpgme_config_prefix="$withval", gpgme_config_prefix="")
-  if test "x$gpgme_config_prefix" != x ; then
-  GPGME_CONFIG="$gpgme_config_prefix/bin/gpgme-config"
-  fi
-  AC_PATH_PROG(GPGME_CONFIG, gpgme-config, no)
-
-  if test "$GPGME_CONFIG" != "no" ; then
-gpgme_version=`$GPGME_CONFIG --version`
-  fi
-  gpgme_version_major=`echo $gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
-  gpgme_version_minor=`echo $gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
-  gpgme_version_micro=`echo $gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
-])
-
-dnl AM_PATH_GPGME([MINIMUM-VERSION,
-dnl   [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
-dnl Test for libgpgme and define GPGME_CFLAGS and GPGME_LIBS.
-dnl
-AC_DEFUN([AM_PATH_GPGME],
-[ AC_REQUIRE([_AM_PATH_GPGME_CONFIG])dnl
-  tmp=ifelse([$1], ,1:0.4.2,$1)
-  if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_gpgme_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
- min_gpgme_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
-  else
- req_gpgme_api=0
- min_gpgme_version="$tmp"
-  fi
-
-  AC_MSG_CHECKING(for GPGME - version >= $min_gpgme_version)
-  ok=no
-  if test "$GPGME_CONFIG" != "no" ; then
-req_major=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
-req_minor=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
-req_micro=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
-if test "$gpgme_version_major" -gt "$req_major"; then
-ok=yes
-else 
-if test "$gpgme_version_major" -eq "$req_major"; then
-if test "$gpgme_version_minor" -gt "$req_minor"; then
-   ok=yes
-else
-   if test "$gpgme_version_minor" -eq "$req_minor"; then
-   if test "$gpgme_version_micro" -ge "$req_micro"; then
- ok=yes
-   fi
-   fi
-fi
-fi
-fi
-  fi
-  if test $ok = yes; then
- # If we have a recent GPGME, we should also check that the
- # API is compatible.
- if test "$req_gpgme_api" -gt 0 ; then
-tmp=`$GPGME_CONFIG --api-version 2>/dev/null || echo 0`
-if test "$tmp" -gt 0 ; then
-   if test "$req_gpgme_api" -ne "$tmp" ; then
- ok=no
-   fi
-fi
- fi
-  fi
-  if test $ok = yes; then
-GPGME_CFLAGS=`$GPGME_CONFIG --cflags`
-GPGME_LIBS=`$GPGME_CONFIG --libs`
-AC_MSG_RESULT(yes)
-ifelse([$2], , :, [$2])
-  else
-GPGME_CFLAGS=""
-GPGME_LIBS=""
-AC_MSG_RESULT(no)
-ifelse([$3], , :, [$3])
-  fi
-  AC_SUBST(GPGME_CFLAGS)
-  AC_SUBST(GPGME_LIBS)
-])
-
-dnl AM_PATH_GPGME_PTH([MINIMUM-VERSION,
-dnl   [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
-dnl Test for libgpgme and define GPGME_PTH_CFLAGS and GPGME_PTH_LIBS.
-dnl
-AC_DEFUN([AM_PATH_GPGME_PTH],
-[ AC_REQUIRE([_AM_PATH_GPGME_CONFIG])dnl
-  tmp=ifelse([$1], ,1:0.4.2,$1)
-  if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_gpgme_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
- min_gpgme_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
-  else
- req_gpgme_api=0
- min_gpgme_version="$tmp"
-  fi
-
-  AC_MSG_CHECKING(for GPGME Pth - version >= $min_gpgme_version)
-  ok=no
-  if test "$GPGME_CONFIG" != "no" ; then
-if `$GPGME_CONFIG --thread=pth 2> /dev/null` ; then
-  req_major=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
-  req_minor=`echo $min_gpgme_version | \
-   sed 's/\([[

Bug#1024482: opencv: embeds build path and running kernel version

[Victor Westerhuis]

Source: opencv
Version: 4.6.0+dfsg-7
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: buildpath uname
X-Debbugs-Cc: reproducible-b...@lists.alioth.debian.org

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi!

While working on the “reproducible builds” effort [1], we have noticed
that opencv's core module embeds the build path multiple times. It also
embeds the running kernel version and a build timestamp. The generated
Doxygen documentation also embeds the build path in multiple places.

I have opened a merge request on Salsa [2] to fix the above issues. Once
applied, it can be built reproducibly in our current experimental
framework.

Regards,

Victor Westerhuis

 [1]: https://wiki.debian.org/ReproducibleBuilds
 [2]: https://salsa.debian.org/science-team/opencv/-/merge_requests/4

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_NL.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_GB:en_US:en:nl_NL:nl
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

-BEGIN PGP SIGNATURE-

iQJHBAEBCAAxFiEE6OxII3T+o0Ujs6ECQz2Rq5dHQPsFAmN6JKYTHHZpY3RvckB3
ZXN0ZXJodS5pcwAKCRBDPZGrl0dA+wtGEACw8EEO2HV2W7gyhBRujYJUv2SMesTF
A0f6cAxVeaub4vJQnBYcJsVsIoXT95YiFwA+2YaVJibnZvD99w+v4ysBY7WHuNQf
DopiCzygInjL8o8MP65TfyRcV3b2jmmDXcRynJ0UDn78vY6PM5fv1DAdrlaNF47l
0/QkW0bSvsj4aZ7MyMiLblISQqU4kw+8EJPutXuzYwTQPQIdjIQldchqu0dLw55F
O/2tJvr0h/3jPT0d3v9Y6+0tQBcI9yN87AdwIeyOme0rDekm04avdfAeoUzOVMvb
Lyy3z5ZTDG6n2sEUmgUnIBWkoM9MlZ5uU9oyS1JafcHiDvkewAU5fh75EWL7b2im
3CYtsAC6rjJK94nVOBmTvTDLJeLj7IbSfd+wf4Spe6EjUKHt2xVIQ9AegyE8bt/R
hwkDrCsTMlzdWoipCa858fXlZc0Ct9833XxacIvave9rhlHzb241MfbyXvZMsIJs
sE+wSlMcoIcv14z142aZEnKl31pCsoMX789M5z11tnT2neqkpUxc+9NLm4Zu/oOQ
5vrOok0uMN+Zzk8axl9uVSC5wlGT3T51HVBfSUwVipcsD537nPNHROHtHzA3IgnP
dsQZa0PZ86iWUkGBtg3ORbiYRHNQzEzbWxwS/yyEkYPeXXjwtCI+CHfnifh8kCxZ
hKLdoA+sRML3Kg==
=JjzC
-END PGP SIGNATURE-

Bug#1024469: lib/debian/tests/test_debfile.py::TestDebFile::test_control fails when tar(1) is not GNU tar

[Stuart Prescott]

Hi Michał,

Thanks for the intriguing report.

The error is coming from the invocation of dpkg-deb which runs
["tar", "-x", "-m", "-f", "-", "--warning=no-timestamp"]

Do I take it that on your system dpkg-deb exists but is entirely 
non-functional because it can't actually work with any archives?


If that's the case, I guess the real solution is fixing dpkg-deb. In the 
meantime, I'll need to think about how the test can navigate its way 
around a broken dpkg-deb being installed — at present, it assumes that 
the tools it finds are not broken.


regards
Stuart

--
Stuart Prescotthttp://www.nanonanonano.net/   stu...@nanonanonano.net
Debian Developer   http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7

Bug#1023923: veyon-plugins: license conflict with libsasl2

[Mike Gabriel]

On  Sa 12 Nov 2022 14:27:53 CET, Bastian Germann wrote:


Package: veyon-plugins
Version: 4.7.4+repack1-1
Severity: serious

Hi,

libkldap-light.so depends on libsasl2-2, which is licensed under  
CMU's BSD-4-clause license and covered by the RSA-MD and OpenSSL  
licenses. All of them have an advertisement clause in place, which  
is known to be incompatible with the GPL. There are several possible  
solutions to this problem:


1) Build without the plugin.


Not optimal as a solution.


2) Support my request at #996892.


Will do.

3) Ask upstream to change this plugin's license or add a license  
exception for libsasl2-2, similar to the one that was required by  
Debian for OpenSSL for a long time.


I will contact upstream on this, as well. Opening up another pathway  
to fixing this.


Mike
--

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

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



pgp5mMfThdORh.pgp
Description: Digitale PGP-Signatur

Bug#996892: Seconding Bastian Germann's proposal to consider cyrus-sasl2 as a system library

[Mike Gabriel]

Hi all,

I second Bastian's proposal to consider cyrus-sasl2 as a system  
library. The package veyon is affected by this, but I can imagine  
various other packaging linking against libsasl2.


Thanks+Greets,
Mike
--

mike gabriel aka sunweaver (Debian Developer)
mobile: +49 (1520) 1976 148
landline: +49 (4351) 486 14 27

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: sunwea...@debian.org, http://sunweavers.net



pgpy9iAlaDIpp.pgp
Description: Digitale PGP-Signatur

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

[Salvatore Bonaccorso]

Control: tags -1 + moreinfo

Hi,

On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
> Package: src:linux
> Version: 6.0.7-1
> Severity: normal
> Tags: ipv6
> 
> Dear Maintainer,
> 
> This system has been operating for most of the last 12 months, using
> ProxyNDP on its external interface for eight addresses. After
> upgrading to the 6.0 kernel series, the kernel stops responding to ND
> solicitations for those addresses after startup... it does not happen
> immediately, but reliably occurs. When the system is in this state
> (not responding to ND solicitations for the proxy addresses), the
> proxy addresses are still shown in 'ip neigh show proxy', and the
> single non-proxy address on the same interface continues operating
> normally.
> 
> Booting the system with the 5.19.0-2 kernel package cures the problem,
> with no other changes.
> 
> Example output:
> 
> root@net22:~# ip neigh show proxy
> 2607:5300:203:9743::1 dev ve-diw20 proxy 
> 2607:5300:203:9743::1 dev ve-matrix20 proxy 
> 2607:5300:203:9743::1 dev ve-ns3 proxy 
> 2607:5300:203:9743::1 dev ve-ldl20 proxy 
> 2607:5300:203:9743::1 dev ve-quassel21 proxy 
> 2607:5300:203:9743::1 dev ve-mastodon22 proxy 
> 2607:5300:203:9743::1 dev ve-monica21 proxy 
> 2607:5300:203:9743::1 dev ve-mail20 proxy 
> 2607:5300:203:9743:4::1 dev enp1s0f0 proxy 
> 2607:5300:203:9743:1::1 dev enp1s0f0 proxy 
> 2607:5300:203:9743:8::1 dev enp1s0f0 proxy 
> 2607:5300:203:9743:5::1 dev enp1s0f0 proxy 
> 2607:5300:203:9743:3::1 dev enp1s0f0 proxy 
> 2607:5300:203:9743:2::1 dev enp1s0f0 proxy 
> 2607:5300:203:9743:6::1 dev enp1s0f0 proxy 
> 2607:5300:203:9743:7::1 dev enp1s0f0 proxy 
> 
> The addresses on enp1s0f0 are the ones which stop responding.

Does the following matches your problem?

https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/

Would you be able to test the mentioned patch to verify a fix for your
issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
proxy_queue.qlen limit per-device") introduced in 6.0-rc2.

Regards,
Salvatore

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

[Salvatore Bonaccorso]

Hi,

On Sun, Nov 20, 2022 at 02:13:11PM +0100, Salvatore Bonaccorso wrote:
> Control: tags -1 + moreinfo
> 
> Hi,
> 
> On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
> > Package: src:linux
> > Version: 6.0.7-1
> > Severity: normal
> > Tags: ipv6
> > 
> > Dear Maintainer,
> > 
> > This system has been operating for most of the last 12 months, using
> > ProxyNDP on its external interface for eight addresses. After
> > upgrading to the 6.0 kernel series, the kernel stops responding to ND
> > solicitations for those addresses after startup... it does not happen
> > immediately, but reliably occurs. When the system is in this state
> > (not responding to ND solicitations for the proxy addresses), the
> > proxy addresses are still shown in 'ip neigh show proxy', and the
> > single non-proxy address on the same interface continues operating
> > normally.
> > 
> > Booting the system with the 5.19.0-2 kernel package cures the problem,
> > with no other changes.
> > 
> > Example output:
> > 
> > root@net22:~# ip neigh show proxy
> > 2607:5300:203:9743::1 dev ve-diw20 proxy 
> > 2607:5300:203:9743::1 dev ve-matrix20 proxy 
> > 2607:5300:203:9743::1 dev ve-ns3 proxy 
> > 2607:5300:203:9743::1 dev ve-ldl20 proxy 
> > 2607:5300:203:9743::1 dev ve-quassel21 proxy 
> > 2607:5300:203:9743::1 dev ve-mastodon22 proxy 
> > 2607:5300:203:9743::1 dev ve-monica21 proxy 
> > 2607:5300:203:9743::1 dev ve-mail20 proxy 
> > 2607:5300:203:9743:4::1 dev enp1s0f0 proxy 
> > 2607:5300:203:9743:1::1 dev enp1s0f0 proxy 
> > 2607:5300:203:9743:8::1 dev enp1s0f0 proxy 
> > 2607:5300:203:9743:5::1 dev enp1s0f0 proxy 
> > 2607:5300:203:9743:3::1 dev enp1s0f0 proxy 
> > 2607:5300:203:9743:2::1 dev enp1s0f0 proxy 
> > 2607:5300:203:9743:6::1 dev enp1s0f0 proxy 
> > 2607:5300:203:9743:7::1 dev enp1s0f0 proxy 
> > 
> > The addresses on enp1s0f0 are the ones which stop responding.
> 
> Does the following matches your problem?
> 
> https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/
> 
> Would you be able to test the mentioned patch to verify a fix for your
> issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
> proxy_queue.qlen limit per-device") introduced in 6.0-rc2.

For reference, the commit would be v2 as applied in netdev as
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8207f253a097fe15c93d85ac15ebb73c5e39e1e1
.

Regards,
Salvatore

Bug#1024483: geany-plugins: FTBFS against libgpgme-dev >= 1.18.0-2

[Andreas Metzler]

Source: geany-plugins
Version: 1.38+dfsg-1.1
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: pkg-gnupg-ma...@lists.alioth.debian.org
Usertags: gpgme-config-transition

geany-plugins ships an outdated version of gpgme.m4 which cannot handle
the transition from gpgme-config to gpgrt-config. Deleting the outdated
copy lets the build succeed.

cu Andreas
--- geany-plugins-1.38+dfsg.orig/Makefile.am
+++ geany-plugins-1.38+dfsg/Makefile.am
@@ -1,4 +1,4 @@
-ACLOCAL_AMFLAGS = -I build/cache -I build -I build/bundled -I geanypy/m4 --install
+ACLOCAL_AMFLAGS = -I build/cache -I build -I geanypy/m4 --install
 AM_DISTCHECK_CONFIGURE_FLAGS = --with-geany-libdir='$${libdir}'
 
 SUBDIRS = po
--- geany-plugins-1.38+dfsg.orig/build/bundled/gpgme.m4
+++ /dev/null
@@ -1,307 +0,0 @@
-# gpgme.m4 - autoconf macro to detect GPGME.
-# Copyright (C) 2002, 2003, 2004 g10 Code GmbH
-#
-# This file is free software; as a special exception the author gives
-# unlimited permission to copy and/or distribute it, with or without
-# modifications, as long as this notice is preserved.
-#
-# This file is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
-# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
-
-AC_DEFUN([_AM_PATH_GPGME_CONFIG],
-[ AC_ARG_WITH(gpgme-prefix,
-AC_HELP_STRING([--with-gpgme-prefix=PFX],
-   [prefix where GPGME is installed (optional)]),
- gpgme_config_prefix="$withval", gpgme_config_prefix="")
-  if test "x$gpgme_config_prefix" != x ; then
-  GPGME_CONFIG="$gpgme_config_prefix/bin/gpgme-config"
-  fi
-  AC_PATH_PROG(GPGME_CONFIG, gpgme-config, no)
-
-  if test "$GPGME_CONFIG" != "no" ; then
-gpgme_version=`$GPGME_CONFIG --version`
-  fi
-  gpgme_version_major=`echo $gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
-  gpgme_version_minor=`echo $gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
-  gpgme_version_micro=`echo $gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
-])
-
-dnl AM_PATH_GPGME([MINIMUM-VERSION,
-dnl   [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
-dnl Test for libgpgme and define GPGME_CFLAGS and GPGME_LIBS.
-dnl
-AC_DEFUN([AM_PATH_GPGME],
-[ AC_REQUIRE([_AM_PATH_GPGME_CONFIG])dnl
-  tmp=ifelse([$1], ,1:0.4.2,$1)
-  if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_gpgme_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
- min_gpgme_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
-  else
- req_gpgme_api=0
- min_gpgme_version="$tmp"
-  fi
-
-  AC_MSG_CHECKING(for GPGME - version >= $min_gpgme_version)
-  ok=no
-  if test "$GPGME_CONFIG" != "no" ; then
-req_major=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
-req_minor=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
-req_micro=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
-if test "$gpgme_version_major" -gt "$req_major"; then
-ok=yes
-else 
-if test "$gpgme_version_major" -eq "$req_major"; then
-if test "$gpgme_version_minor" -gt "$req_minor"; then
-   ok=yes
-else
-   if test "$gpgme_version_minor" -eq "$req_minor"; then
-   if test "$gpgme_version_micro" -ge "$req_micro"; then
- ok=yes
-   fi
-   fi
-fi
-fi
-fi
-  fi
-  if test $ok = yes; then
- # If we have a recent GPGME, we should also check that the
- # API is compatible.
- if test "$req_gpgme_api" -gt 0 ; then
-tmp=`$GPGME_CONFIG --api-version 2>/dev/null || echo 0`
-if test "$tmp" -gt 0 ; then
-   if test "$req_gpgme_api" -ne "$tmp" ; then
- ok=no
-   fi
-fi
- fi
-  fi
-  if test $ok = yes; then
-GPGME_CFLAGS=`$GPGME_CONFIG --cflags`
-GPGME_LIBS=`$GPGME_CONFIG --libs`
-AC_MSG_RESULT(yes)
-ifelse([$2], , :, [$2])
-  else
-GPGME_CFLAGS=""
-GPGME_LIBS=""
-AC_MSG_RESULT(no)
-ifelse([$3], , :, [$3])
-  fi
-  AC_SUBST(GPGME_CFLAGS)
-  AC_SUBST(GPGME_LIBS)
-])
-
-dnl AM_PATH_GPGME_PTH([MINIMUM-VERSION,
-dnl   [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
-dnl Test for libgpgme and define GPGME_PTH_CFLAGS and GPGME_PTH_LIBS.
-dnl
-AC_DEFUN([AM_PATH_GPGME_PTH],
-[ AC_REQUIRE([_AM_PATH_GPGME_CONFIG])dnl
-  tmp=ifelse([$1], ,1:0.4.2,$1)
-  if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_gpgme_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
- min_gpgme_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
-  else
- req_gpgme_api=0
- min_gpgme_version="$tmp"
-  fi
-

Bug#1024484: gpa: FTBFS against libgpgme-dev >= 1.18.0-2

[Andreas Metzler]

Source: gpa
Version: 0.10.0-4
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: pkg-gnupg-ma...@lists.alioth.debian.org
Usertags: gpgme-config-transition

gpa ships an outdated version of gpgme.m4 which cannot handle
the transition from gpgme-config to gpgrt-config. Deleting the outdated
copy lets the build succeed.

cu Andreas
--- gpa-0.10.0.orig/m4/gpgme.m4
+++ /dev/null
@@ -1,307 +0,0 @@
-# gpgme.m4 - autoconf macro to detect GPGME.
-# Copyright (C) 2002, 2003, 2004 g10 Code GmbH
-#
-# This file is free software; as a special exception the author gives
-# unlimited permission to copy and/or distribute it, with or without
-# modifications, as long as this notice is preserved.
-#
-# This file is distributed in the hope that it will be useful, but
-# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the
-# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-
-
-AC_DEFUN([_AM_PATH_GPGME_CONFIG],
-[ AC_ARG_WITH(gpgme-prefix,
-AC_HELP_STRING([--with-gpgme-prefix=PFX],
-   [prefix where GPGME is installed (optional)]),
- gpgme_config_prefix="$withval", gpgme_config_prefix="")
-  if test "x$gpgme_config_prefix" != x ; then
-  GPGME_CONFIG="$gpgme_config_prefix/bin/gpgme-config"
-  fi
-  AC_PATH_PROG(GPGME_CONFIG, gpgme-config, no)
-
-  if test "$GPGME_CONFIG" != "no" ; then
-gpgme_version=`$GPGME_CONFIG --version`
-  fi
-  gpgme_version_major=`echo $gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
-  gpgme_version_minor=`echo $gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
-  gpgme_version_micro=`echo $gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
-])
-
-dnl AM_PATH_GPGME([MINIMUM-VERSION,
-dnl   [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
-dnl Test for libgpgme and define GPGME_CFLAGS and GPGME_LIBS.
-dnl
-AC_DEFUN([AM_PATH_GPGME],
-[ AC_REQUIRE([_AM_PATH_GPGME_CONFIG])dnl
-  tmp=ifelse([$1], ,1:0.4.2,$1)
-  if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_gpgme_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
- min_gpgme_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
-  else
- req_gpgme_api=0
- min_gpgme_version="$tmp"
-  fi
-
-  AC_MSG_CHECKING(for GPGME - version >= $min_gpgme_version)
-  ok=no
-  if test "$GPGME_CONFIG" != "no" ; then
-req_major=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
-req_minor=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
-req_micro=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
-if test "$gpgme_version_major" -gt "$req_major"; then
-ok=yes
-else 
-if test "$gpgme_version_major" -eq "$req_major"; then
-if test "$gpgme_version_minor" -gt "$req_minor"; then
-   ok=yes
-else
-   if test "$gpgme_version_minor" -eq "$req_minor"; then
-   if test "$gpgme_version_micro" -ge "$req_micro"; then
- ok=yes
-   fi
-   fi
-fi
-fi
-fi
-  fi
-  if test $ok = yes; then
- # If we have a recent GPGME, we should also check that the
- # API is compatible.
- if test "$req_gpgme_api" -gt 0 ; then
-tmp=`$GPGME_CONFIG --api-version 2>/dev/null || echo 0`
-if test "$tmp" -gt 0 ; then
-   if test "$req_gpgme_api" -ne "$tmp" ; then
- ok=no
-   fi
-fi
- fi
-  fi
-  if test $ok = yes; then
-GPGME_CFLAGS=`$GPGME_CONFIG --cflags`
-GPGME_LIBS=`$GPGME_CONFIG --libs`
-AC_MSG_RESULT(yes)
-ifelse([$2], , :, [$2])
-  else
-GPGME_CFLAGS=""
-GPGME_LIBS=""
-AC_MSG_RESULT(no)
-ifelse([$3], , :, [$3])
-  fi
-  AC_SUBST(GPGME_CFLAGS)
-  AC_SUBST(GPGME_LIBS)
-])
-
-dnl AM_PATH_GPGME_PTH([MINIMUM-VERSION,
-dnl   [ACTION-IF-FOUND [, ACTION-IF-NOT-FOUND ]]])
-dnl Test for libgpgme and define GPGME_PTH_CFLAGS and GPGME_PTH_LIBS.
-dnl
-AC_DEFUN([AM_PATH_GPGME_PTH],
-[ AC_REQUIRE([_AM_PATH_GPGME_CONFIG])dnl
-  tmp=ifelse([$1], ,1:0.4.2,$1)
-  if echo "$tmp" | grep ':' >/dev/null 2>/dev/null ; then
- req_gpgme_api=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\1/'`
- min_gpgme_version=`echo "$tmp" | sed 's/\(.*\):\(.*\)/\2/'`
-  else
- req_gpgme_api=0
- min_gpgme_version="$tmp"
-  fi
-
-  AC_MSG_CHECKING(for GPGME Pth - version >= $min_gpgme_version)
-  ok=no
-  if test "$GPGME_CONFIG" != "no" ; then
-if `$GPGME_CONFIG --thread=pth 2> /dev/null` ; then
-  req_major=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
-  req_minor=`echo $min_gpgme_version | \
-   sed 's/\([[0-9]]*\)\.\([[0-9]

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

[Kevin P. Fleming]

On Sun, Nov 20, 2022, at 08:15, Salvatore Bonaccorso wrote:
> Hi,
>
> On Sun, Nov 20, 2022 at 02:13:11PM +0100, Salvatore Bonaccorso wrote:
>> Control: tags -1 + moreinfo
>> 
>> Hi,
>> 
>> On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
>> > Package: src:linux
>> > Version: 6.0.7-1
>> > Severity: normal
>> > Tags: ipv6
>> > 
>> > Dear Maintainer,
>> > 
>> > This system has been operating for most of the last 12 months, using
>> > ProxyNDP on its external interface for eight addresses. After
>> > upgrading to the 6.0 kernel series, the kernel stops responding to ND
>> > solicitations for those addresses after startup... it does not happen
>> > immediately, but reliably occurs. When the system is in this state
>> > (not responding to ND solicitations for the proxy addresses), the
>> > proxy addresses are still shown in 'ip neigh show proxy', and the
>> > single non-proxy address on the same interface continues operating
>> > normally.
>> > 
>> > Booting the system with the 5.19.0-2 kernel package cures the problem,
>> > with no other changes.
>> > 
>> > Example output:
>> > 
>> > root@net22:~# ip neigh show proxy
>> > 2607:5300:203:9743::1 dev ve-diw20 proxy 
>> > 2607:5300:203:9743::1 dev ve-matrix20 proxy 
>> > 2607:5300:203:9743::1 dev ve-ns3 proxy 
>> > 2607:5300:203:9743::1 dev ve-ldl20 proxy 
>> > 2607:5300:203:9743::1 dev ve-quassel21 proxy 
>> > 2607:5300:203:9743::1 dev ve-mastodon22 proxy 
>> > 2607:5300:203:9743::1 dev ve-monica21 proxy 
>> > 2607:5300:203:9743::1 dev ve-mail20 proxy 
>> > 2607:5300:203:9743:4::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:1::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:8::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:5::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:3::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:2::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:6::1 dev enp1s0f0 proxy 
>> > 2607:5300:203:9743:7::1 dev enp1s0f0 proxy 
>> > 
>> > The addresses on enp1s0f0 are the ones which stop responding.
>> 
>> Does the following matches your problem?
>> 
>> https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/
>> 
>> Would you be able to test the mentioned patch to verify a fix for your
>> issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
>> proxy_queue.qlen limit per-device") introduced in 6.0-rc2.
>
> For reference, the commit would be v2 as applied in netdev as
> https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8207f253a097fe15c93d85ac15ebb73c5e39e1e1

While that description does not exactly match my problem, it is so similar as 
to almost certainly be the cause. I would be happy to try applying that patch, 
but it's been a while since I built a patched Debian kernel so it may take a 
couple of days :-)

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

[Salvatore Bonaccorso]

Hi Kevin,

On Sun, Nov 20, 2022 at 08:23:04AM -0500, Kevin P. Fleming wrote:
> On Sun, Nov 20, 2022, at 08:15, Salvatore Bonaccorso wrote:
> > Hi,
> >
> > On Sun, Nov 20, 2022 at 02:13:11PM +0100, Salvatore Bonaccorso wrote:
> >> Control: tags -1 + moreinfo
> >> 
> >> Hi,
> >> 
> >> On Mon, Nov 14, 2022 at 06:34:43AM -0500, Kevin P. Fleming wrote:
> >> > Package: src:linux
> >> > Version: 6.0.7-1
> >> > Severity: normal
> >> > Tags: ipv6
> >> > 
> >> > Dear Maintainer,
> >> > 
> >> > This system has been operating for most of the last 12 months, using
> >> > ProxyNDP on its external interface for eight addresses. After
> >> > upgrading to the 6.0 kernel series, the kernel stops responding to ND
> >> > solicitations for those addresses after startup... it does not happen
> >> > immediately, but reliably occurs. When the system is in this state
> >> > (not responding to ND solicitations for the proxy addresses), the
> >> > proxy addresses are still shown in 'ip neigh show proxy', and the
> >> > single non-proxy address on the same interface continues operating
> >> > normally.
> >> > 
> >> > Booting the system with the 5.19.0-2 kernel package cures the problem,
> >> > with no other changes.
> >> > 
> >> > Example output:
> >> > 
> >> > root@net22:~# ip neigh show proxy
> >> > 2607:5300:203:9743::1 dev ve-diw20 proxy 
> >> > 2607:5300:203:9743::1 dev ve-matrix20 proxy 
> >> > 2607:5300:203:9743::1 dev ve-ns3 proxy 
> >> > 2607:5300:203:9743::1 dev ve-ldl20 proxy 
> >> > 2607:5300:203:9743::1 dev ve-quassel21 proxy 
> >> > 2607:5300:203:9743::1 dev ve-mastodon22 proxy 
> >> > 2607:5300:203:9743::1 dev ve-monica21 proxy 
> >> > 2607:5300:203:9743::1 dev ve-mail20 proxy 
> >> > 2607:5300:203:9743:4::1 dev enp1s0f0 proxy 
> >> > 2607:5300:203:9743:1::1 dev enp1s0f0 proxy 
> >> > 2607:5300:203:9743:8::1 dev enp1s0f0 proxy 
> >> > 2607:5300:203:9743:5::1 dev enp1s0f0 proxy 
> >> > 2607:5300:203:9743:3::1 dev enp1s0f0 proxy 
> >> > 2607:5300:203:9743:2::1 dev enp1s0f0 proxy 
> >> > 2607:5300:203:9743:6::1 dev enp1s0f0 proxy 
> >> > 2607:5300:203:9743:7::1 dev enp1s0f0 proxy 
> >> > 
> >> > The addresses on enp1s0f0 are the ones which stop responding.
> >> 
> >> Does the following matches your problem?
> >> 
> >> https://lore.kernel.org/netdev/y295+9+jdjqrw...@x1.ze-it.at/
> >> 
> >> Would you be able to test the mentioned patch to verify a fix for your
> >> issue? The above changes fixes 0ff4eb3d5ebb ("neighbour: make
> >> proxy_queue.qlen limit per-device") introduced in 6.0-rc2.
> >
> > For reference, the commit would be v2 as applied in netdev as
> > https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/?id=8207f253a097fe15c93d85ac15ebb73c5e39e1e1
> 
> While that description does not exactly match my problem, it is so
> similar as to almost certainly be the cause. I would be happy to try
> applying that patch, but it's been a while since I built a patched
> Debian kernel so it may take a couple of days :-)

If that would be helpful, we have some instructions on "simple
patching and building" the kernel with a additional patches on top
here:

https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2

Hope this helps for it.

Regards,
Salvatore

Bug#1022344: Bug#1024383: luseradd username not getting parsed correctly

[Håvard F . Aasen]

On 18.11.2022 17:50, Baumann Edwin wrote:
> Package: libpopt0
> 
> Version: 1.19+dfsg-1 amd64
> Tags: bookworm
> Severity: normal
> 
>  
> 
> *The Problem:*
> 
>  
> 
> When trying to add a new user like this:
> 
> /luseradd -g 221 -u 219814 testuser/
> 
>  
> 
> Instead of using the given name it will use “default_useradd”
> 
> /vi /etc/passwd/
> 
> /default_useradd:x:219814:221:default_useradd:/home/default_useradd:/bin/bash/
> 
>  
> 
> The user also really doesn’t exist with the given name.
> 
> /deluser testuser/
> 
> //usr/sbin/deluser: The user `testuser' does not exist./
> 
> / /
> 
> *Versions:*
> 
> / /
> 
> libuser: 1:0.63~dfsg-4+b1 amd64
> 
> kernel: Debian 5.16.14-1 x86_64 GNU/Linux
> 
> libc: Version: 2.36-4
> 

Sorry for the late reply, but the message title was rather
non-descriptive, if the popt package is supposed to be targeted.

I looked at a solution upstream, and found one. It seems this was
fixed about two months ago [1], the fix provided by upstream will
also fix the failing testsuite reported as bug #1022344 [2].

I didn't test your specific testcase Baumann, but the package
compiles, and passes the upstream testsuite.

I have attached a patch that will close bug #1022344 and #1024383.
It's on the larger side, but this is what upstream is using. I can
also provide a MR on salsa if that is preferred.


Regards,
Håvard


[1] https://pagure.io/libuser/pull-request/55
[2] https://bugs.debian.org/1022344
From a34837a1ece65d3b1d22dc91102d6f61ca74aad2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?H=C3=A5vard=20F=2E=20Aasen?= 
Date: Sun, 20 Nov 2022 14:34:33 +0100
Subject: [PATCH] Patch to handle correct popt memory handling

---
 .../0005-correct-popt-memory-handling.patch   | 1515 +
 debian/patches/series |1 +
 2 files changed, 1516 insertions(+)
 create mode 100644 debian/patches/0005-correct-popt-memory-handling.patch

diff --git a/debian/patches/0005-correct-popt-memory-handling.patch b/debian/patches/0005-correct-popt-memory-handling.patch
new file mode 100644
index 000..38808e6
--- /dev/null
+++ b/debian/patches/0005-correct-popt-memory-handling.patch
@@ -0,0 +1,1515 @@
+From: Tomas Halman 
+Date: Tue, 27 Sep 2022 09:28:02 +
+Subject: Merge #55 `Correct popt memory handling`
+
+Origin: upstream, https://pagure.io/libuser/pull-request/55
+Bug-Debian: https://bugs.debian.org/1022344
+Bug-Debian: https://bugs.debian.org/1024383
+---
+ apps/lchage.c| 35 ++---
+ apps/lchfn.c | 38 +---
+ apps/lchsh.c | 36 +++---
+ apps/lgroupadd.c | 36 ++
+ apps/lgroupdel.c | 36 ++
+ apps/lgroupmod.c | 67 +++-
+ apps/lid.c   | 34 ++--
+ apps/lnewusers.c | 30 +++--
+ apps/lpasswd.c   | 49 ++---
+ apps/luseradd.c  | 60 +++---
+ apps/luserdel.c  | 51 +++---
+ apps/lusermod.c  | 63 +---
+ 12 files changed, 340 insertions(+), 195 deletions(-)
+
+diff --git a/apps/lchage.c b/apps/lchage.c
+index 1a4f048..3620e75 100644
+--- a/apps/lchage.c
 b/apps/lchage.c
+@@ -71,13 +71,14 @@ main(int argc, const char **argv)
+ 	long shadowMin = INVALID_LONG, shadowMax = INVALID_LONG,
+ 	 shadowLastChange = INVALID_LONG, shadowInactive = INVALID_LONG,
+ 	 shadowExpire = INVALID_LONG, shadowWarning = INVALID_LONG;
+-	const char *user;
+-	struct lu_context *ctx;
+-	struct lu_ent *ent;
++	const char *user = NULL;
++	struct lu_context *ctx = NULL;
++	struct lu_ent *ent = NULL;
+ 	struct lu_error *error = NULL;
+ 	int interactive = FALSE;
+ 	int list_only = FALSE;
+ 	int c;
++	int result;
+ 
+ 	poptContext popt;
+ 	struct poptOption options[] = {
+@@ -118,7 +119,8 @@ main(int argc, const char **argv)
+ 		fprintf(stderr, _("Error parsing arguments: %s.\n"),
+ 			poptStrerror(c));
+ 		poptPrintUsage(popt, stderr, 0);
+-		exit(1);
++		result = 1;
++		goto done;
+ 	}
+ 	user = poptGetArg(popt);
+ 
+@@ -126,11 +128,10 @@ main(int argc, const char **argv)
+ 	if (user == NULL) {
+ 		fprintf(stderr, _("No user name specified.\n"));
+ 		poptPrintUsage(popt, stderr, 0);
+-		return 1;
++		result = 1;
++		goto done;
+ 	}
+ 
+-	poptFreeContext(popt);
+-
+ 	/* Start up the library. */
+ 	ctx = lu_start(user, lu_user, NULL, NULL,
+ 		   interactive ? lu_prompt_console :
+@@ -138,7 +139,8 @@ main(int argc, const char **argv)
+ 	if (ctx == NULL) {
+ 		fprintf(stderr, _("Error initializing %s: %s.\n"), PACKAGE,
+ 			lu_strerror(error));
+-		return 1;
++		result = 1;
++		goto done;
+ 	}
+ 
+ 	ent = lu_ent_new();
+@@ -146,7 +148,8 @@ main(int argc, const char **argv)
+ 	/* Look up information about the user. */
+ 	if (lu_user_lookup_name(ctx, user, ent, &error) == FALSE) {
+ 		fprintf(stde

Bug#1024469: lib/debian/tests/test_debfile.py::TestDebFile::test_control fails when tar(1) is not GNU tar

[Michał Górny]

On Mon, 2022-11-21 at 00:03 +1100, Stuart Prescott wrote:
> Hi Michał,
> 
> Thanks for the intriguing report.
> 
> The error is coming from the invocation of dpkg-deb which runs
> ["tar", "-x", "-m", "-f", "-", "--warning=no-timestamp"]
> 
> Do I take it that on your system dpkg-deb exists but is entirely 
> non-functional because it can't actually work with any archives?

Ah, I didn't even realize I have dpkg installed!  I've never used it but
if you think it's broken, then it probably is ;-).

> If that's the case, I guess the real solution is fixing dpkg-deb. In the 
> meantime, I'll need to think about how the test can navigate its way 
> around a broken dpkg-deb being installed — at present, it assumes that 
> the tools it finds are not broken.

Indeed.  Should I file a new bug against dpkg, or can you "reassign"
this one then?

As for python-debian, please don't worry too much about it.  This setup
with bsdtar is quite experimental, and mostly meant to catch and report
potential issues right now.  I don't think you have to worry about real
users being affected right now.

-- 
Best regards,
Michał Górny

Bug#1024485: ITP: golang-github-twpayne-go-vfs -- easy-to-test abstraction of the os and io packages

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 
Control: block 1012721 by -1

* Package name: golang-github-twpayne-go-vfs
  Version : 4.1.0-1
  Upstream Author : Tom Payne
* URL : https://github.com/twpayne/go-vfs
* License : Expat
  Programming Lang: Go
  Description: easy-to-test abstraction of the os and io packages

 This library provides:
  * File system abstraction layer for commonly-used os and io functions
from the standard library.
  * Powerful and easy-to-use declarative testing framework, vfst. You
declare the desired state of the filesystem after your code has run, and
vfst tests that the filesystem matches that state.
 It is compatible with afero and go-billy.

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#1024486: ITP: golang-github-twpayne-go-xdg -- go library for XDG base directory specification

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 
Control: block 1012721 by -1

* Package name: golang-github-twpayne-go-xdg
  Version : 6.0.0-1
  Upstream Author : Tom Payne
* URL : https://github.com/twpayne/go-xdg
* License : Expat
  Programming Lang: Go
  Description: go library for XDG base directory specification

 This library provides functions for the freedesktop.org
 XDG Base Directory Specification.

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#1024487: ITP: golang-github-twpayne-go-pinentry -- go client library for GnuPG's pinentry

[Ryan Kavanagh]

Package: wnpp
Severity: wishlist
Owner: Ryan Kavanagh 
Control: block 1012721 by -1

* Package name: golang-github-twpayne-go-pinentry
  Version : 0.2.0-1
  Upstream Author : Tom Payne
* URL : https://github.com/twpayne/go-pinentry
* License : Expat
  Programming Lang: Go
  Description : go client library for GnuPG's pinentry

 This library provides an interface to GnuPG pinentry, a pass-phrase entry
 system. This library implements all pinentry features. It also implements a
 full parser of the underlying Assuan protocol for better compatibility with
 all pinentry implementations.

-- 
|)|/  Ryan Kavanagh  | 4E46 9519 ED67 7734 268F
|\|\  https://rak.ac | BD95 8F7B F8FC 4A11 C97A


signature.asc
Description: PGP signature

Bug#1024488: kaddressbook: Unused build-dependency on libgpgmepp-dev?

[Andreas Metzler]

Source: kaddressbook
Version: 4:22.08.3-1
Severity: minor

Hello,

afaict kaddressbook's b-d on libgpgmepp-dev is unused:
ametzler@argenau:/tmp/BUGS$ grep -ril gpgme kaddressbook-22.08.3/ 
buildlog.kaddressbook_22.08.3-1_amd64
kaddressbook-22.08.3/debian/control

Could you please doublecheck? - TIA!

cu Andreas

Bug#1024489: gvm-libs: Loses gpgme integration when rebuilt against gpgme 1.18.0-2

[Andreas Metzler]

Source: gvm-libs
Version: 21.4.4-1
Severity: important
User: pkg-gnupg-ma...@lists.alioth.debian.org
Usertags: gpgme-config-transition

the package relies on gpgme-config to detect gpgme. gpgme-config has been
dropped and replaced by pkg-config pc files. Fix looks straightforward,
just move over to cmake pkg_check_modules() in util/CMakeLists.txt.

cu Andreas

Bug#1024490: geary: Place signature at end of the message

[Alexandre Lymberopoulos]

Package: geary
Version: 43.0-1+b1
Severity: wishlist

Dear Maintainer,

It is usual (at least in my community) to write and comment "inline"
when answering an e-mail. I'm experimenting geary, coming from
mutt+emacs. I like Geary's interface and easy of use, but I would like
to have the signature field to be at the very end of the whole body of
the message, so I can reply and the signature isn't the first thing
recipient sees.

Thanks in advance.

Best, Alexandre

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

Kernel: Linux 6.0.0-4-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_WARN
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)

Versions of packages geary depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  gnome-keyring42.1-1+b1
ii  libatk1.0-0  2.46.0-3
ii  libc62.36-5
ii  libcairo21.16.0-6
ii  libenchant-2-2   2.3.3-1
ii  libfolks26   0.15.5-2+b1
ii  libgck-1-0   3.41.1-1+b1
ii  libgcr-base-3-1  3.41.1-1+b1
ii  libgdk-pixbuf-2.0-0  2.42.9+dfsg-1
ii  libgee-0.8-2 0.20.6-1
ii  libglib2.0-0 2.74.1-2
ii  libgmime-3.0-0   3.2.13+dfsg-2
ii  libgoa-1.0-0b3.46.0-1
ii  libgsound0   1.0.3-2
ii  libgspell-1-21.12.0-1+b1
ii  libgtk-3-0   3.24.34-3
ii  libhandy-1-0 1.8.0-1
ii  libicu72 72.1-2
ii  libjavascriptcoregtk-4.1-0   2.38.2-1+b1
ii  libjson-glib-1.0-0   1.6.6-1
ii  libmessaging-menu0   22.9.0-1+b1
ii  libpango-1.0-0   1.50.10+ds-1
ii  libpangocairo-1.0-0  1.50.10+ds-1
ii  libpeas-1.0-01.34.0-1
ii  libsecret-1-00.20.5-3
ii  libsoup-3.0-03.2.1-2
ii  libsqlite3-0 3.39.4-1
ii  libstemmer0d 2.2.0-2
ii  libunwind8   1.3.2-2
ii  libwebkit2gtk-4.1-0  2.38.2-1+b1
ii  libxml2  2.9.14+dfsg-1.1+b2
ii  libytnef02.0-1+b1

geary recommends no packages.

geary suggests no packages.

-- no debconf information

Bug#900821: Found working and failing 5.10 versions and got kernel crash, report from BSP Tilburg (https://deb.li/iiOID)

[Diederik de Haas]

Control: notfound -1 4.9.88-1+deb9u1
Control: found -1 4.9.88-1

On zondag 20 november 2022 13:55:09 CET Salvatore Bonaccorso wrote:
> Seems the BSP was productive :).

Yeah, once I set up the VM and created the script, it was actually quite easy.

> If you have spare cycles, might you
> check if dacb5d8875cc ("tcp: fix page frag corruption on page fault")
> in 5.16-rc4 is the commit we are searching?
> That one was backported to the 5.10.y series in 5.10.84 and in 5.15.y series
> in 5.15.7 which would fall into your found ranges as well.

IOW: that's your educated guess a git bisect could turn up?
I can try that*, although I'm not clear onto what I should apply it.
Should I apply it to linux/5.10.70-1 or 5.10.46-4 f.e.? Or onto an entirely 
different version?

> OTOH, it fixes 5640f7685831 ("net: use a per task frag allocator")
> which is way much longer back as where the people noticed to be
> introduced.

While the focus has been on the kernel (possibly rightly so), there were 2 
other packages (apache and samba) involved. It could be that on Buster f.e. 
the problem still exists (even with a backports kernel).
I actually did look for an oldstable (net-)installer, but I couldn't find one.
I later realized that maybe there are DVDs of old releases, but I doubt I'll 
do sth with that (at least wrt this bug).

*) I had plenty of cycles when I started this reply, but less so when I'm 
sending it. I may do this some other day though.

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

Bug#1024469: lib/debian/tests/test_debfile.py::TestDebFile::test_control fails when tar(1) is not GNU tar

[Michał Górny]

On Mon, 2022-11-21 at 00:03 +1100, Stuart Prescott wrote:
> The error is coming from the invocation of dpkg-deb which runs
> ["tar", "-x", "-m", "-f", "-", "--warning=no-timestamp"]
> 
> Do I take it that on your system dpkg-deb exists but is entirely 
> non-functional because it can't actually work with any archives?

Ah, I've just looked into dpkg and it seems to switch to `gtar`
invocation if such an executable is present.  So it failed only because
I haven't rebuilt dpkg after we've switched to installing GNU tar
as `gtar`.  In this case, there is nothing to be fixed in dpkg and we
just need to handle this on Gentoo end.

I'm sorry for the false report and thank you for all your guidance.

-- 
Best regards,
Michał Górny

Bug#1024491: dump1090-mutability: New upstream

[Bastian Germann]

Source: dump1090-mutability
Version: 1.15~20180310.4a16df3+dfsg-8
Severity: wishlist

The current upstream points to https://github.com/flightaware/dump1090 as a 
maintained version.
Please import that into Debian.

Bug#900821: Found working and failing 5.10 versions and got kernel crash, report from BSP Tilburg (https://deb.li/iiOID)

[Salvatore Bonaccorso]

Hi Diederik,

On Sun, Nov 20, 2022 at 04:26:45PM +0100, Diederik de Haas wrote:
> Control: notfound -1 4.9.88-1+deb9u1
> Control: found -1 4.9.88-1

Hmm this one I do not understand, as 4.9.88-1+deb9u1 was a very
targetted fix for two CVEs and reverting the "random: fix crng_ready()
test" changes re-opening CVE-2018-1108.

> On zondag 20 november 2022 13:55:09 CET Salvatore Bonaccorso wrote:
> > Seems the BSP was productive :).
> 
> Yeah, once I set up the VM and created the script, it was actually quite easy.

:-)

> > If you have spare cycles, might you
> > check if dacb5d8875cc ("tcp: fix page frag corruption on page fault")
> > in 5.16-rc4 is the commit we are searching?
> > That one was backported to the 5.10.y series in 5.10.84 and in 5.15.y series
> > in 5.15.7 which would fall into your found ranges as well.
> 
> IOW: that's your educated guess a git bisect could turn up?

Not really. I was more looking at between versions you are not able to
reproduce the issue, looking through the upstream changes commits and
noticing that dacb5d8875cc ("tcp: fix page frag corruption on page
fault") mentions:

[...]
Steffen reported a TCP stream corruption for HTTP requests
served by the apache web-server using a cifs mount-point
and memory mapping the relevant file.
[...]

and then noticing that the upstrema commit was backported to 5.10.84
an 5.15.7, which fall exactly in the ranges you have the switch of
result.

> I can try that*, although I'm not clear onto what I should apply it.
> Should I apply it to linux/5.10.70-1 or 5.10.46-4 f.e.? Or onto an entirely 
> different version?

Basically I wonder if c6f340a331fb72e5ac23a083de9c780e132ca3ae in
5.10.84 fixes the issue, and
c6f340a331fb72e5ac23a083de9c780e132ca3ae~1 still would show the
problem.

Alterntively if 5.10.70-1 + commit fixes the issue.

Regards,
Salvatore

Bug#1024084: tar: missing licenses - Excuses

[Mechtilde Stehmann]

Package: tar
Version: 1.34+dfsg-1
Followup-For: Bug #1024084
X-Debbugs-Cc: mechti...@debian.org

Sorry for missing the delay-queue.

I did it at the BSP in Tilburg

Sorry


-- System Information:
Debian Release: bookworm/sid
  APT prefers testing
  APT policy: (400, 'testing'), (300, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)

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

Versions of packages tar depends on:
ii  libacl1  2.3.1-1
ii  libc62.36-5
ii  libselinux1  3.4-1+b3

tar recommends no packages.

Versions of packages tar suggests:
ii  bzip21.0.8-5+b1
ii  ncompress4.2.4.6-6
pn  tar-doc  
pn  tar-scripts  
ii  xz-utils 5.2.7-0.1

-- no debconf information

Bug#1024492: libffi: large structs need to be passed by value on hppa

[John David Anglin]

Source: libffi
Version: 3.2.1-9
Severity: normal
Tags: patch

Dear Maintainer,

The following tests fail on hppa:
=== libffi tests ===

Schedule of variations:
unix

Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for 
target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../testsuite/config/default.exp as tool-and-target-specific interface 
file.
Running ../../testsuite/libffi.bhaible/bhaible.exp ...
Running ../../testsuite/libffi.call/call.exp ...
FAIL: libffi.call/struct_by_value_3.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct_by_value_3.c -W -Wall -Wno-psabi -O2 execution test
FAIL: libffi.call/struct_by_value_4.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct_by_value_4.c -W -Wall -Wno-psabi -O2 execution test
FAIL: libffi.call/struct_by_value_big.c -W -Wall -Wno-psabi -O0 execution test
FAIL: libffi.call/struct_by_value_big.c -W -Wall -Wno-psabi -O2 execution test
Running ../../testsuite/libffi.closures/closure.exp ...
Running ../../testsuite/libffi.complex/complex.exp ...
Running ../../testsuite/libffi.go/go.exp ...

=== libffi Summary ===

# of expected passes1482
# of unexpected failures6
# of unsupported tests  30
make[3]: *** [Makefile:466: check-DEJAGNU] Error 1

Full log is here:
https://buildd.debian.org/status/fetch.php?pkg=libffi&arch=hppa&ver=3.4.4-1&stamp=106326&raw=0

This is upstream issue #749:
https://github.com/libffi/libffi/issues/749

Attached is patch to fix the problem on hppa. It is similar to patch
applied to fix issue on sparc64.

Please apply until issue is fixed in upstream source.

Regards,
Dave Anglin

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

Kernel: Linux 6.0.9 (SMP w/4 CPU threads)
Locale: LANG=C, 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)
diff --git a/src/pa/ffi.c b/src/pa/ffi.c
index 95e6694..186bf69 100644
--- a/src/pa/ffi.c
+++ b/src/pa/ffi.c
@@ -376,10 +376,26 @@ extern void ffi_call_pa32(void (*)(UINT32 *, extended_cif 
*, unsigned),
 void ffi_call(ffi_cif *cif, void (*fn)(void), void *rvalue, void **avalue)
 {
   extended_cif ecif;
+  size_t i, nargs = cif->nargs;
+  ffi_type **arg_types = cif->arg_types;
 
   ecif.cif = cif;
   ecif.avalue = avalue;
 
+  /* If we have any large structure arguments, make a copy so we are passing
+ by value.  */
+  for (i = 0; i < nargs; i++)
+{
+  ffi_type *at = arg_types[i];
+  int size = at->size;
+  if (at->type == FFI_TYPE_STRUCT && size > 8)
+   {
+ char *argcopy = alloca (size);
+ memcpy (argcopy, avalue[i], size);
+ avalue[i] = argcopy;
+   }
+}
+
   /* If the return value is a struct and we don't have a return
  value address then we need to make one.  */
 

Bug#1015914: (no subject)

[Jelmer Vernooij]

tags 1015914 +patch
thanks

Hi Paul, Sandro,

I've verified that node-clipboard works too, and proposed a PR at 
https://salsa.debian.org/python-team/packages/sphinx-copybutton/-/merge_requests/2

Cheers,

Jelmer

Bug#1015914: Uploaded to DELAYED/10

[Jelmer Vernooij]

I've also uploaded a NMU to DELAYED/10, please feel free to cancel or
let me know here if you prefer not to see that go through.

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc

Bug#953630: openbabel autopkg tests fail on non-amd64 architectures

[Paul Gevers]

Control: tags -1 pending

Hi,

On Wed, 11 Mar 2020 13:33:44 +0100 Matthias Klose  wrote:

Attached is a patch which runs all tests, skips some problematic tests, and runs
all tests before failing.


From the BSP in Tilburg, I uploaded the attached NMU to DELAYED/5. 
Please let me know if I should delay more or cancel.


Paul
diff -Nru openbabel-3.1.1+dfsg/debian/changelog 
openbabel-3.1.1+dfsg/debian/changelog
--- openbabel-3.1.1+dfsg/debian/changelog   2022-09-08 14:29:09.0 
+0200
+++ openbabel-3.1.1+dfsg/debian/changelog   2022-11-20 10:24:49.0 
+0100
@@ -1,3 +1,20 @@
+openbabel (3.1.1+dfsg-7.1) unstable; urgency=medium
+
+  * Non-maintainer upload
+
+  [ Matthias Klose ]
+  * Make the autopkg tests more verbose, don't fail on the first failing test.
+  * Re-enable the tests on arm64.
+  * Skip the test/testroundtrip.py test on all architectures, times out
+(Closes: #953630)
+  * Skip the testbindings.py and testsym.py tests on non amd64 architectures.
+
+  [ Paul Gevers ]
+  * Run all tests that don't timeout, but ignore specific failures on
+specific architectures
+
+ -- Paul Gevers   Sun, 20 Nov 2022 10:24:49 +0100
+
 openbabel (3.1.1+dfsg-7) unstable; urgency=medium
 
   * Include  in obutil.h (Closes: #1016227)
diff -Nru openbabel-3.1.1+dfsg/debian/tests/python3 
openbabel-3.1.1+dfsg/debian/tests/python3
--- openbabel-3.1.1+dfsg/debian/tests/python3   2022-09-08 14:29:09.0 
+0200
+++ openbabel-3.1.1+dfsg/debian/tests/python3   2022-11-20 10:24:49.0 
+0100
@@ -1,10 +1,50 @@
 #!/bin/bash
 
-test "$(dpkg --print-architecture)" = arm64 && exit 77
-
 sed -i 's/"\.\."/"\/usr"/' test/testbabel.py
 
+arch=$(dpkg --print-architecture)
+fails=
 for TEST in test/test*.py
 do
-python3 ${TEST}
+fail_on_failure=true
+case $TEST in
+  test/testroundtrip.py)
+# timesout?
+echo "Skipping ${TEST} ..."
+continue;;
+  test/testdistgeom.py)
+case "$arch" in amd64)
+  # timesout on ci.d.n worker13
+ echo "Skipping ${TEST} ..."
+ continue;;
+   esac;;
+  test/testbindings.py)
+case "$arch" in arm64)
+  fail_on_failure=false;;
+esac;;
+  test/testsym.py)
+case "$arch" in arm64|armel|armhf|i386|ppc64el|s390x)
+  fail_on_failure=false;;
+esac;;
+  test/testobconv_writers.py)
+case "$arch" in arm64|i386|ppc64el|s390x)
+  fail_on_failure=false;;
+esac;;
+esac
+echo "Running ${TEST} ..."
+if python3 ${TEST}; then
+   :
+else
+   if [ $fail_on_failure = "false" ] ; then
+ echo "Ignoring ${TEST} on $arch ..."
+   else
+ fails="$fails $TEST"
+   fi
+fi
 done
+
+if [ -n "$fails" ]; then
+echo "Failing tests: $fails"
+exit 1
+fi
+exit 0


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024493: Proposed-RM: bs1770gain -- RoQA; inappropriate content

[Ansgar]

Source: bs1770gain
Version: 0.6.5-1
Severity: serious

Hi,

I proposed to remove bs1770gain from Debian. Besides the problem from
#913352, the upstream homepage and domain that we direct users to (via
Homepage: field and other places) contain extremist content.

I don't think it's worth distributing software that does this in
Debian.

If there are no objections from the maintainers, I'll reassign this to
ftp.d.o in the next days.

Ansgar

Bug#1020066: tt-rss: FTBFS: build-dependency not installable: libjs-prototype (= 1.7.1-3.1)

[Diederik de Haas]

user debian-rele...@lists.debian.org
usertag 1020066 + bsp-2022-11-nl-tilburg
tag 1020066 + pending
thanks

On Sun, 18 Sep 2022 08:18:31 +0200 Lucas Nussbaum  wrote:
> Source: tt-rss
> Version: 21~git20210204.b4cbc79+dfsg-1
> Severity: serious
> Justification: FTBFS

Merged "Relax libjs-prototype build dependency" MR, this is now pending.

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

Bug#1023413: dh-cargo: should prevent dh_clean from removing Cargo.toml.orig

[Daniel Kahn Gillmor]

Hi Niels--

Thanks for taking a look at this.

On Sat 2022-11-19 15:12:35 +0100, in #1023413, Niels Thykier wrote:
> On Thu, 03 Nov 2022 12:13:43 -0400 Daniel Kahn Gillmor 
>  wrote:
>> When packaging Rust crates, the rust-team typically packages from the
>> bundles published on crates.io.  Those are published with a modified
>> version of Cargo.toml, and the original upstream source for Cargo.toml
>> is present as Cargo.toml.orig.
>> 
>> debhelper's dh_clean by default removes all files matching *.orig, which
>> means that the upstream Cargo.toml.orig is getting stripped before the
>> build happens. (dh_clean is typically invoked before a build)
>
> Would it be possible to use a different name for it (like 
> Cargo.toml.upstream or even Cargo.toml.original)? Something that 
> dh_clean does not remove by default?

unfortunately, the name "Cargo.toml.orig" comes from the rust packaging
ecosystem (it's produced when a "crate" is generated from source).  So
this isn't something that the rust-team has any control over, and it
seems *very* unlikely that the upstream ecosystem will change this at
any point in the future.  afaict, the breakage described here is the
*only* peculiarity that has a negative impact on the ecosystem related
to the naming of Cargo.toml.orig.

> In theory, a dh addon *can* add an option to dh_clean by default (i.e., 
> if dh_clean is not overridden).  That said, it does mean that the 
> sequence can no longer be conditional (e.g., only used in 
> Build-Depends-Arch).

i'm not sure i fully understand the implications of this constraint, or
how i would go ahead and add that option via dh-cargo.  can you point me
to the right sort of way to do this thing in dh-cargo?

> Special-casing Cargo.toml.orig also feels weird to me. But also, I do 
> not want every language special-case to cascade into "core" debhelper - 
> then debhelper becomes an unmaintainable soup of random things I cannot 
> keep track (like are they still relevant).

I agree that this kind of "soup" isn't friendly or maintainable for
something as central as debhelper generally, and it's tough for
debhelper to know whether this kind of specific cleanup is appropriate
for a given package.

> The removal of .orig is been around for ages (to support cleaning up 
> after patches with merge conflicts). I am not inclined to remove that 
> from debhelper.
>
> I hope we can use another name for the file or that dh-cargo can handle 
> the special-casing via a debhelper add-on.

OK, sounds like putting this in dh-cargo is the right way to do it, so
this report is assigned to the right package.  If you could give me a
pointer to the safest way to do this, i would appreciate it!

Or maybe someone who knows dh-cargo better than i do can try to make
this change?

--dkg


signature.asc
Description: PGP signature

Bug#1024494: ITP: python3-fints -- python library for the FinTS protocol

[matthias . geiger1024]

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name    : python3-fints
  Version : 3.1.0
  Upstream Author : Raphael Michel 
* URL : https://pypi.org/project/fints/
* License : LGPL-3
  Programming Lang: Python
  Description : python library for the FinTS protocol

I intend to package python3-fints. This library is needed for #1013317
(banking). The intial packaging is already done and can be viewed at
https://salsa.debian.org/werdahias/fints .
CC debian-python:
This is the first python library I packaged. Please review and sponsor the
upload.

Thanks

werdahias
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmN6X18ACgkQGL0Qazts
VHUL7A//SquQi7VZ1ifZlAp8M3h3GjaHf8Exs1xmoXOwqg09qLbbB8V5eidwA1M1
EZUDS4e5K/ArC8dW1iZV2F4HoQ8dWw9EGrXuvd6Jl+ZeeVldMkbSdc+FQtLBWxQF
dcg+rSMGmiqptDUNFDW2ZzuM5gNOZkB37rnJ8pt7lejICG/N1oAayCe9ui85cko8
FcgBmwCRI9idltmMi+aWzJiL+o6POhVbmHflD3HOPhDD0hkBmif2ogbQlShccEwI
lTrcqpVeGKQZbS5lP9LG3x8oQaPsB2xpYCnW+/za11SML9bvT9a73NnSfPeMMlSK
nbJ1Xm5FGPhKUUwXXkEzMLDwDPMMIHQ8vHlkT84Qyu49ps5iwPZOkhijRbQUsNIR
2bITtHbMkJMNvFdyZq+MJI1DPOMS7Q9HIgQe8LT/qbr1Cq7sVptL+dkpPXVLKsH3
q6UqyLdpX9KtyKgywHskL2zXQZoHl4Syz2fs26rGhyaZ2YSpGf28O/OaaJp3AlU2
u/s9vtPrw0bN2NJGFnQV/ZhFROO/Zp1y36bVmORMSq9/iPlexawZ64KEr7M6Ocqm
9WqvpcstGaDEOuCIYQR0YygGcE9hHZn2+R0JS2f62N+WRvTeb/cmZWo+pnh9nl7w
rboj7IseLtbvA/w4nWDeKmITNe9SqfdBGJnwcI2Yh+9xHt8l1b4=
=OR4D
-END PGP SIGNATURE-
 -BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Matthias Geiger 
To: Debian Bug Tracking System 
Subject: ITP: python3-fints -- python library for the FinTS protocol
Bcc: Matthias Geiger 

Package: wnpp
Severity: wishlist
Owner: Matthias Geiger 
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: python3-fints
  Version : 3.1.0
  Upstream Author : Raphael Michel 
* URL : https://pypi.org/project/fints/
* License : LGPL-3
  Programming Lang: Python
  Description : python library for the FinTS protocol

I intend to package python3-fints. This library is needed for #1013317
(banking). The intial packaging is already done and can be viewed at
https://salsa.debian.org/werdahias/fints .
CC debian-python:
This is the first python library I packaged. Please review and sponsor the
upload.

Thanks

werdahias
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEwuGmy/3s5RGopBdtGL0QaztsVHUFAmN6X18ACgkQGL0Qazts
VHUL7A//SquQi7VZ1ifZlAp8M3h3GjaHf8Exs1xmoXOwqg09qLbbB8V5eidwA1M1
EZUDS4e5K/ArC8dW1iZV2F4HoQ8dWw9EGrXuvd6Jl+ZeeVldMkbSdc+FQtLBWxQF
dcg+rSMGmiqptDUNFDW2ZzuM5gNOZkB37rnJ8pt7lejICG/N1oAayCe9ui85cko8
FcgBmwCRI9idltmMi+aWzJiL+o6POhVbmHflD3HOPhDD0hkBmif2ogbQlShccEwI
lTrcqpVeGKQZbS5lP9LG3x8oQaPsB2xpYCnW+/za11SML9bvT9a73NnSfPeMMlSK
nbJ1Xm5FGPhKUUwXXkEzMLDwDPMMIHQ8vHlkT84Qyu49ps5iwPZOkhijRbQUsNIR
2bITtHbMkJMNvFdyZq+MJI1DPOMS7Q9HIgQe8LT/qbr1Cq7sVptL+dkpPXVLKsH3
q6UqyLdpX9KtyKgywHskL2zXQZoHl4Syz2fs26rGhyaZ2YSpGf28O/OaaJp3AlU2
u/s9vtPrw0bN2NJGFnQV/ZhFROO/Zp1y36bVmORMSq9/iPlexawZ64KEr7M6Ocqm
9WqvpcstGaDEOuCIYQR0YygGcE9hHZn2+R0JS2f62N+WRvTeb/cmZWo+pnh9nl7w
rboj7IseLtbvA/w4nWDeKmITNe9SqfdBGJnwcI2Yh+9xHt8l1b4=
=OR4D
-END PGP SIGNATURE-

Bug#1024495: mirror submission for mirror.creoline.net

[creoline GmbH]

Package: mirrors
Severity: wishlist
User: mirr...@packages.debian.org
Usertags: mirror-submission

Submission-Type: new
Site: mirror.creoline.net
Type: leaf
Archive-architecture: ALL amd64 arm64 armel armhf hurd-i386 i386 kfreebsd-amd64 
kfreebsd-i386 mips mips64el mipsel powerpc ppc64el s390x
Archive-http: /debian/
Archive-rsync: debian/
Maintainer: creoline GmbH 
Country: DE Germany
Location: Frankfurt am Main
Sponsor: creoline GmbH https://www.creoline.de
Comment: Uplink: 10 Gbit/s LACP
 Storage: All NVMe
 Full failover redundancy




Trace Url: http://mirror.creoline.net/debian/project/trace/
Trace Url: http://mirror.creoline.net/debian/project/trace/ftp-master.debian.org
Trace Url: http://mirror.creoline.net/debian/project/trace/mirror.creoline.net

Bug#1024496: qiskit-terra: FTBFS with Python 3.11 as a supported version

[Graham Inggs]

Source: qiskit-terra
Version: 0.12.0-4
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11

Hi Maintainer

qiskit-terra FTBFS during the recent rebuild adding Python 3.11 as a
supported version [1].  I've copied what I hope is the relevant part
of the log below.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=qiskit-terra


=== FAILURES ===
___ TestPassManagerRun.test_default_pass_manager_two ___
concurrent.futures.process._RemoteTraceback:
"""
Traceback (most recent call last):
  File "/usr/lib/python3.11/concurrent/futures/process.py", line 256,
in _process_worker
r = call_item.fn(*call_item.args, **call_item.kwargs)
^
  File "/usr/lib/python3.11/concurrent/futures/process.py", line 205,
in _process_chunk
return [fn(*args) for args in chunk]
   ^
  File "/usr/lib/python3.11/concurrent/futures/process.py", line 205,
in 
return [fn(*args) for args in chunk]
^
  File "/<>/.pybuild/cpython3_3.11/build/qiskit/tools/parallel.py",
line 69, in _task_wrapper
return task(value, *task_args, **task_kwargs)
   ^^
  File 
"/<>/.pybuild/cpython3_3.11/build/qiskit/transpiler/passmanager.py",
line 206, in _in_parallel
running_passmanager = dill.loads(pm_dill)._create_running_passmanager()
  ^^^
  File "/usr/lib/python3/dist-packages/dill/_dill.py", line 327, in loads
return load(file, ignore, **kwds)
   ^^
  File "/usr/lib/python3/dist-packages/dill/_dill.py", line 313, in load
return Unpickler(file, ignore=ignore, **kwds).load()
   ^
  File "/usr/lib/python3/dist-packages/dill/_dill.py", line 525, in load
obj = StockUnpickler.load(self)
  ^
  File "/usr/lib/python3/dist-packages/dill/_dill.py", line 659, in _create_code
if len(args) == 16: return CodeType(*args)
   ^^^
TypeError: code() argument 13 must be str, not int
"""

The above exception was the direct cause of the following exception:

self = 

def test_default_pass_manager_two(self):
"""Test default_pass_manager.run(circuitS).

circuit1 and circuit2:
qr0:-[H]--.  -> 1
  |
qr1:-(+)--.  -> 2
  |
qr2:-(+)--.  -> 3
  |
qr3:-(+)---  -> 5

device:
0  -  1  -  2  -  3  -  4  -  5  -  6

  | | | | | |

  13 -  12  - 11 -  10 -  9  -  8  -   7
"""
qr = QuantumRegister(4, 'qr')
circuit1 = QuantumCircuit(qr)
circuit1.h(qr[0])
circuit1.cx(qr[0], qr[1])
circuit1.cx(qr[1], qr[2])
circuit1.cx(qr[2], qr[3])

circuit2 = QuantumCircuit(qr)
circuit2.cx(qr[1], qr[2])
circuit2.cx(qr[0], qr[1])
circuit2.cx(qr[2], qr[3])

coupling_map = FakeMelbourne().configuration().coupling_map
basis_gates = FakeMelbourne().configuration().basis_gates
initial_layout = [None, qr[0], qr[1], qr[2], None, qr[3]]

pass_manager = level_1_pass_manager(TranspileConfig(
basis_gates=basis_gates,
coupling_map=CouplingMap(coupling_map),
initial_layout=Layout.from_qubit_list(initial_layout),
seed_transpiler=42,
optimization_level=1))
>   new_circuits = pass_manager.run([circuit1, circuit2])

test/python/transpiler/test_passmanager_run.py:112:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
qiskit/transpiler/passmanager.py:195: in run
return self._run_several_circuits(circuits)
qiskit/transpiler/passmanager.py:219: in _run_several_circuits
return parallel_map(PassManager._in_parallel, circuits,
qiskit/tools/parallel.py:134: in parallel_map
raise error
qiskit/tools/parallel.py:124: in parallel_map
results = list(future)
/usr/lib/python3.11/concurrent/futures/process.py:597: in
_chain_from_iterable_of_lists
for element in iterable:
/usr/lib/python3.11/concurrent/futures/_base.py:619: in result_iterator
yield _result_or_cancel(fs.pop())
/usr/lib/python3.11/concurrent/futures/_base.py:317: in _result_or_cancel
return fut.result(timeout)
/usr/lib/python3.11/concurrent/futures/_base.py:449: in result
return self.__get_result()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self = None

def __get_result(self):
if self._exception:
try:
>   raise self._exception
E   TypeError: code() argument 13 must be str, not int

/usr/lib/python3.11/concurrent/futures/_ba

Bug#893083: git pushed

[Geert Stappers]

user debian-rele...@lists.debian.org
usertag 893083 + bsp-2022-11-nl-tilburg   
tag 893083 + pending
thank you

|$ git push --set-upstream origin debian/main
|Enumerating objects: 332, done.
|Counting objects: 100% (332/332), done.
|Delta compression using up to 12 threads
|Compressing objects: 100% (327/327), done.
|Writing objects: 100% (332/332), 813.38 KiB | 9.68 MiB/s, done.
|Total 332 (delta 95), reused 0 (delta 0), pack-reused 0
|remote: Resolving deltas: 100% (95/95), done.
|To salsa.debian.org:debian/hello.git
| * [new branch]  debian/main -> debian/main
|branch 'debian/main' set up to track 'origin/debian/main'.
|$ git remote -v
|origin g...@salsa.debian.org:debian/hello.git (fetch)
|origin g...@salsa.debian.org:debian/hello.git (push)
|$ git show
|commit f55bbe9bcd1f3aa4632ded1f53eaff6ddd0dc52d (HEAD -> debian/main, 
origin/debian/main)
|Author: Geert Stappers 
|Date:   Sun Nov 20 17:50:33 2022 +0100
|
|Added Vcs URL to d/control
|
|diff --git a/debian/changelog b/debian/changelog
|index df4a850..fc1ca45 100644
|--- a/debian/changelog
|+++ b/debian/changelog
|@@ -1,3 +1,10 @@
|+hello (2.10-2.1) UNRELEASED; urgency=medium
|+
|+  * Non-maintainer upload.
|+  * Added Vcs-fields to d/control Closes: #893083.
|+
|+ -- Geert Stappers   Sun, 20 Nov 2022 17:47:38 +0100
|+
| hello (2.10-2) unstable; urgency=medium
| 
|   * Fix version skew. Closes: #928887.
|diff --git a/debian/control b/debian/control
|index fd41939..672a489 100644
|--- a/debian/control
|+++ b/debian/control
|@@ -5,6 +5,8 @@ Maintainer: Santiago Vila 
| Standards-Version: 4.3.0
| Build-Depends: debhelper-compat (= 9)
| Homepage: http://www.gnu.org/software/hello/
|+Vcs-Browser: https://salsa.debian.org/debian/hello
|+Vcs-Git: https://salsa.debian.org/debian/hello.git
| Rules-Requires-Root: no
| 
| Package: hello
|$ 

The 'tag 893083 + pending'-upload  will to delay queue twenty days.


Groeten
Geert Stappers
-- 
Silence is hard to parse

Bug#1024497: libcryptui: FTBFS against libgpgme-dev >= 1.18.0-2

[Andreas Metzler]

Source: libcryptui
Version: 3.12.2-6
Severity: serious
Tags: patch ftbfs
Justification: fails to build from source (but built successfully in the past)
User: pkg-gnupg-ma...@lists.alioth.debian.org
Usertags: gpgme-config-transition

The package relies on gpgme-config to detect gpgme. gpgme-config has been
dropped and replaced by pkg-config pc files.

cu Andreas
--- libcryptui-3.12.2.orig/configure.ac
+++ libcryptui-3.12.2/configure.ac
@@ -128,51 +128,12 @@ if test	"$DO_CHECK" = "yes"; then
 	fi
 fi
 
-ok="no"
-min_gpgme_version=1.0.0
-AC_PATH_PROG(GPGME_CONFIG, gpgme-config, "failed")
-if test $GPGME_CONFIG != "failed" ; then
-	AC_MSG_CHECKING(for GPGME - version >= $min_gpgme_version)
-	req_major=`echo $min_gpgme_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\1/'`
-	req_minor=`echo $min_gpgme_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\2/'`
-	req_micro=`echo $min_gpgme_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\)/\3/'`
-	gpgme_config_version=`$GPGME_CONFIG --version`
-	major=`echo $gpgme_config_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\1/'`
-	minor=`echo $gpgme_config_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\2/'`
-	micro=`echo $gpgme_config_version | \
-		sed 's/\([[0-9]]*\)\.\([[0-9]]*\)\.\([[0-9]]*\).*/\3/'`
-
-	if test "$major" -eq "$req_major"; then
-		if test "$minor" -ge "$req_minor"; then
-			if test "$micro" -ge "$req_micro"; then
-ok="yes"
-			fi
-		fi
-	fi
-fi
-
-if test $ok = "yes"; then
-	GPGME_CFLAGS=`$GPGME_CONFIG --cflags`
-	GPGME_LIBS=`$GPGME_CONFIG --libs`
-	AC_MSG_RESULT(yes)
-	have_gpgme="$gpgme_config_version"
-else
-	AC_MSG_RESULT(no)
-fi
+PKG_CHECK_MODULES([GPGME], [gpgme >= 1.0.0])
 
 if test -z "$have_gpg"; then
 	AC_MSG_ERROR([Appropriate version of GnuPG not found. Please install one of versions: $accepted_versions])
 fi
 
-if test -z "$have_gpgme"; then
-	AC_MSG_ERROR(GPGME $min_gpgme_version or later needed)
-fi
-
 SEAHORSE_CFLAGS="$SEAHORSE_CFLAGS $GPGME_CFLAGS"
 SEAHORSE_LIBS="$SEAHORSE_LIBS $GPGME_LIBS"
 
@@ -359,7 +320,7 @@ dnl 
 
 echo "
 GnuPG Version:  $have_gpg
-GPGME Version:  $have_gpgme
+GPGME Version:  $GPGME_VERSION
 Notification Support:   $enable_libnotify
 Build introspection data:   ${enable_introspection}
 "

Bug#1024498: pysph: FTBFS with Python 3.11 as a supported version

[Graham Inggs]

Source: pysph
Version: 1.0~b1-3
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11

Hi Maintainer

pysph FTBFS during the recent rebuild adding Python 3.11 as a
supported version [1].  I've copied what I hope is the relevant part
of the log below.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=pysph


 ERRORS 
_ ERROR collecting
.pybuild/cpython3_3.11/build/pysph/base/tests/test_device_helper.py _
pysph/base/tests/test_device_helper.py:4: in 
from pysph.base.utils import get_particle_array  # noqa: E402
pysph/base/utils.py:7: in 
from .particle_array import ParticleArray, \
pysph/base/particle_array.pyx:25: in init pysph.base.particle_array
from compyle.array import Array, get_backend, to_device
/usr/lib/python3/dist-packages/compyle/array.py:10: in 
from .template import Template
/usr/lib/python3/dist-packages/compyle/template.py:10: in 
inspect, 'getfullargspec', inspect.getargspec
E   AttributeError: module 'inspect' has no attribute 'getargspec'

Bug#1024499: pybdsf: FTBFS with Python 3.11 as a supported version

[Graham Inggs]

Source: pybdsf
Version: 1.10.1-1
Severity: serious
Tags: ftbfs
User: debian-pyt...@lists.debian.org
Usertags: python3.11

Hi Maintainer

pybdsf FTBFS during the recent rebuild adding Python 3.11 as a
supported version [1].  I've copied what I hope is the relevant part
of the log below.

Regards
Graham


[1] https://buildd.debian.org/status/package.php?p=pybdsf


==
ERROR: bdsf (unittest.loader._FailedTest.bdsf)
--
ImportError: Failed to import test module: bdsf
Traceback (most recent call last):
  File "/usr/lib/python3.11/unittest/loader.py", line 440, in _find_test_path
package = self._get_module_from_name(name)
  
  File "/usr/lib/python3.11/unittest/loader.py", line 350, in
_get_module_from_name
__import__(name)
  File "/<>/.pybuild/cpython3_3.11/build/bdsf/__init__.py",
line 21, in 
from .collapse import Op_collapse
  File "/<>/.pybuild/cpython3_3.11/build/bdsf/collapse.py",
line 11, in 
from . import _cbdsm
SystemError: initialization of _cbdsm raised unreported exception

Bug#1024500: libdnf: Loses gpgme integration when rebuilt against gpgme 1.18.0-2

[Andreas Metzler]

Source: libdnf
Version: 0.55.2-6
Severity: important
User: pkg-gnupg-ma...@lists.alioth.debian.org
Usertags: gpgme-config-transition

The package relies on gpgme-config to detect gpgme. gpgme-config has been
dropped and replaced by pkg-config pc files.


-- No usable gpgme flavours found.


I would suggest following #1024417 where the same cmake module seems to
be used.

cu Andreas

Bug#990828: mutt can not delete mails due to access rights

[Kevin J. McCarthy]

On Sun, Nov 20, 2022 at 01:50:41PM +0100, Juan Pedro Vallejo wrote:

"mutt_dotlock" is the one to blame:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root root 13804 Nov 13 18:01 /usr/bin/mutt_dotlock

This works for me:

# chown root:mail /usr/bin/mutt_dotlock
# chmod 2755 /usr/bin/mutt_dotlock

Now:

# ls -l /usr/bin/mutt_dotlock
-rwxr-sr-x 1 root mail 13804 Nov 13 18:01 /usr/bin/mutt_dotlock


Thanks for the information.  What architecture are you running on?  The 
amd64 package installs properly with sgid mail.


However, I did check the various packages for 2.2.9, and it looks like 
the i386 package does not.  Are you running i386 architecture, or did 
you install the i386 package on an amd64 architecture?


I don't know if this is a bug in the i386 packaging environment, or if 
the mail directories on i386 are different.  I'm Cc'ing Antonio to see 
if he has any input.


-Kevin


signature.asc
Description: PGP signature

Bug#1024501: fortune-mod: Remove fortune-off data files from fortune-mod as inappropriate for Bookworm release

[Andrew M.A. Cater]

Package: fortune-mod
Version: 1.99.1
Severity: important

Dear Maintainer,

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

   * What led up to the situation?

As mentioned on Debian-project mailing list:
This is no longer appropriate for Debian. Fortunes-off binary package has
been removed: can we remove the data files, please.

These were questioned by upstream as early as 1997. They contain ethnic and
homophobic content and also Nazism quotes from Mein Kampf - none of these
would fit Debian Codes of Conduct today. A complaint has been raised.

It would seem sensible to remove these quotes and content immediately prior
to the release of Debian Bookworm

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

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


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

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

Versions of packages fortune-mod depends on:
ii  libc6   2.31-13+deb11u5
pn  librecode0  

Versions of packages fortune-mod recommends:
pn  fortunes-min | fortune-cookie-db  

Versions of packages fortune-mod suggests:
pn  bsdmainutils  
pn  fortunes  
ii  x11-utils 7.7+5

Bug#1024502: RFS: freeipmi/1.6.10-1 -- GNU implementation of the IPMI protocol

[Fabio Fantoni]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : freeipmi
   Version  : 1.6.10-1
   Upstream contact : Albert Chu 
 * URL  : https://www.gnu.org/software/freeipmi/
 * License  : GPL-3+
 * Vcs  : https://salsa.debian.org/debian/freeipmi
   Section  : admin

The source builds the following binary packages:

  freeipmi - GNU implementation of the IPMI protocol
  freeipmi-bmc-watchdog - GNU implementation of the IPMI protocol - BMC 
watchdog

  freeipmi-common - GNU implementation of the IPMI protocol - common files
  freeipmi-ipmidetect - GNU IPMI - IPMI node detection tool
  freeipmi-ipmiseld - GNU IPMI - IPMI system event log daemon
  freeipmi-tools - GNU implementation of the IPMI protocol - tools
  libfreeipmi-dev - GNU IPMI - development package
  libfreeipmi17 - GNU IPMI - libraries
  libipmiconsole-dev - GNU IPMI - ipmiconsole development package
  libipmiconsole2 - GNU IPMI - Serial-over-Lan library
  libipmidetect-dev - GNU IPMI - ipmidetect development package
  libipmidetect0 - GNU IPMI - IPMI node detection library
  libipmimonitoring-dev - GNU IPMI - ipmimonitoring development package
  libipmimonitoring6 - GNU IPMI - Sensor monitoring library

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


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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/f/freeipmi/freeipmi_1.6.10-1.dsc


Hi, I already send 2 mail to bzed asking for upload but probably was 
busy or not received them.


Are only minor changes, nothing urgent but since it's been a long time 
now I uploaded it to mentors and opened this RFS.


Can someone upload it please?


Changes since the last upload:

 freeipmi (1.6.10-1) unstable; urgency=medium
 .
   * New upstream version 1.6.10
   * d/patches: remove 6 patches applied upstream
   * Bumped Standards-Version to 4.6.1, no needed changes
   * Update lintian overrides
   * Update symbols

Regards,
--
  Fabio Fantoni



OpenPGP_signature
Description: OpenPGP digital signature

Bug#1024070: linux-image-6.0.0-3-amd64: IPv6 ProxyNDP stops responding to ND solicitation some time after startup

[Kevin P. Fleming]

On Sun, Nov 20, 2022, at 08:38, Salvatore Bonaccorso wrote:

> If that would be helpful, we have some instructions on "simple
> patching and building" the kernel with a additional patches on top
> here:
>
> https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s4.2.2

I found those via another path, and used them :-) Had a few little issues along 
the way: failing to set DEBFULLNAME produces a broken changelog entry so then 
the build won't run (and leaves the tree in a broken state as well). Once I 
solved that problem I was able to make packages, but the linux-headers-common 
package didn't get produced, so I had to use --force-depends-version when 
installing the packages (which I knew was safe since the headers had not 
changed).

I now have the patched kernel in operation and should know whether the problem 
is solved in 24-48 hours.

Bug#1024504: libvirt FTCBFS: misdetects linux/kvm.h

[Helmut Grohne]

Source: libvirt
Version: 8.9.0-1
Tags: patch upstream
User: debian-cr...@lists.debian.org
Usertags: ftcbfs

libvirt fails to cross build from source when building on amd64 for
armhf or armel. It uses meson's has_header to figure out whether
linux/kvm.h exists and due to linux-libc-dev:amd64 being installed,
/usr/include/linux/kvm.h exists. has_header is able to figure this out
without actually including it. When libvirt actually #includes it,
asm/kvm.h is missing as that's a multiarch headers. Thus linux headers
should be tested with check_header, which actually #includes it. While
has_header may seem relatively useless at this point, it is far quicker
than check_header. Thus I'm proposing to only employ check_header for
linux headers. I'm attaching a patch for your convenience.

Helmut
--- libvirt-8.9.0.orig/meson.build
+++ libvirt-8.9.0/meson.build
@@ -623,7 +623,7 @@
 endif
 
 foreach name : headers
-  if cc.has_header(name)
+  if name.startswith('linux/') ? cc.check_header(name) : cc.has_header(name)
 conf.set('WITH_@0@'.format(name.underscorify().to_upper()), 1)
   endif
 endforeach

Bug#1016992: libdbd-oracle-perl: Built against unsupported Oracle Instant Client 12.1

[Alex Muntada]

Hi Daniel,

> libdbd-oracle-perl has been built against OIC 12.1
> since version 1.66-1 (Aug 30, 2013).
> 
> Oracle's "Release Schedule of Current Database Releases":
>   
> https://support.oracle.com/knowledge/Oracle%20Database%20Products/742060_1.html
> says "Patching End Dates" are:
>   * 12.1 - Jul 31, 2022
>   * 19c  - Apr 30, 2024
>   * 21c  - Apr 30, 2024

Thanks for sharing that URL above. After reading it, let me
expand on the support details for the record of this bug:

* 12.1.0.2 (Terminal Release) "Patching End Dates":
  - Jul 31, 2022 with paid ES, ULA, or EBS waiver
  - Dec 31, 2023 (with a Custom Market Driven Support Contract)
* 19c (Long Term Release)
  - April 30, 2025 with no ES/ULA
(see that you wrote **2024** here!)
  - April 30, 2027 with ES/ULA
* 21c (Innovation Release)
  - April 30, 2024

> Upstream DBD::Oracle 1.81 introduced support for OIC 21.
> 
> Could the following two changes be made?
>   1) Import upstream version 1.83
>   2) Build against OIC 19c (Version 19.16) or 21c (Version 21.7)
>
> However, two problems remain:
>   1) Bookworm will be supported well beyond Apr 30, 2024
>   2) Oracle may release higher 19.xx and 21.x versions

Seeing the above end dates, my bet is on 19c right now for two
reasons: 1) is the longest supported version right now, and 2)
is a Long Term Release, which means that they may extend its
support longer as they did with 12.1.

Cheers,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁   Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer 🍥 log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature

Bug#1024505: musl-dev: missing printf.h

[Helmut Grohne]

Package: musl-dev
Tags: upstream
User: helm...@debian.org
Usertags: rebootstrap

Hi Reiner,

I got quite a bit further with a musl bootstrap, but now it fails
building systemd and this one is hard. It probably requires some
discussion.

The immediate issue is that #include  does not work. This is a
known problem, has been filed on the systemd side, rejected there, has
been filed on the musl side, rejected there, carried as a patch among
many patches in a number of distros.

I suppose the best musl + systemd patchset is the one from the
OpenEmbedded people at:
https://git.openembedded.org/openembedded-core/tree/meta/recipes-core/systemd/systemd
You quickly notice that this is not for the faint of heart. It's
probably around 100kb worth of patches. NixOS also uses exactly these
patches.

In most of them the issue goes like this:

musl people (Rich Felker in particular) say that the requested
functionality is not specified by POSIX and thus not included in musl.
Get it specified and musl will add it.

systemd people say that it doesn't make sense to ship copies of the
relevant functions and that the C library should provide it.

This is not the first time we face missing functionality in musl. An
earlier example was the fts library. Back then, we agreed that Debian's
musl should include fts and you added it to the Debian packaging.

Now does the same work for printf.h? And strndupa? And basename? And
probably more?

I think we need a decision on how to deal with these issues in future to
avoid conflict.

Constraints:
 * musl upstream will not include these patches.
 * Neither systemd upstream nor Debian systemd will include the
   OpenEmbedded patchset. It is way too big.
 * On Debian, we expect a system libc to provide more than musl
   provides.

Possibly there can be some kind of addon library that fills in the
missing pieces and also gains the fts functionality? Maybe such a
library could be shared with OpenEmbedded and NixOS to reduce their
patch stack?

What do you think?

I've attached a demo patch to show how to include printf.h in a way that
works practically. However, since it is LGPL-licensed, you cannot
include it in the package as is.

Helmut
--- a/debian/clean
+++ b/debian/clean
@@ -4,4 +4,6 @@
 include/crypt.h
 src/crypt/
 include/fts.h
+include/printf.h
 src/fts/
+src/printf/
--- a/debian/musl-printf/printf.c
+++ b/debian/musl-printf/printf.c
@@ -0,0 +1,273 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Emil Renner Berthing 
+
+  With parts from the musl C library
+  Copyright 2005-2014 Rich Felker, et al.
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see .
+***/
+
+#include 
+
+#include 
+#include 
+
+static const char *consume_nonarg(const char *fmt)
+{
+do {
+if (*fmt == '\0')
+return fmt;
+} while (*fmt++ != '%');
+return fmt;
+}
+
+static const char *consume_num(const char *fmt)
+{
+for (;*fmt >= '0' && *fmt <= '9'; fmt++)
+/* do nothing */;
+return fmt;
+}
+
+static const char *consume_argn(const char *fmt, size_t *arg)
+{
+const char *p = fmt;
+size_t val = 0;
+
+if (*p < '1' || *p > '9')
+return fmt;
+do {
+val = 10*val + (*p++ - '0');
+} while (*p >= '0' && *p <= '9');
+
+if (*p != '$')
+return fmt;
+*arg = val;
+return p+1;
+}
+
+static const char *consume_flags(const char *fmt)
+{
+while (1) {
+switch (*fmt) {
+case '#':
+case '0':
+case '-':
+case ' ':
+case '+':
+case '\'':
+case 'I':
+fmt++;
+continue;
+}
+return fmt;
+}
+}
+
+enum state {
+BARE,
+LPRE,
+LLPRE,
+HPRE,
+HHPRE,
+BIGLPRE,
+ZTPRE,
+JPRE,
+STOP
+};
+
+enum type {
+NONE,
+PTR,
+INT,
+UINT,
+ULLONG,
+LONG,
+ULONG,
+SHORT,
+USHORT,
+CHAR,
+UCHAR,
+LLONG,
+SIZET,
+IMAX,
+UMAX,
+PDIFF,
+UIPTR,
+DBL,
+LDBL,
+ 

Bug#897275: closed by Debian FTP Masters (Bug#1000941: Removed package(s) from unstable)

[Helmut Grohne]

Control: reopen -1
Control: reassign -1 llvm-10,llvm-13,llvm-14,llvm-15,llvm-16

On Sat, Nov 19, 2022 at 03:39:49PM +, Debian Bug Tracking System wrote:
> llvm-6.0 ships a llvm-config tool for discovering aspects such as
> libdir. I have no clue what prevented upstream from using the
> well-established pkg-config mechanism, but the present llvm-config is
> completely unusable for cross compilation:
>  * You cannot query the build llvm-config, because it gives you the
>wrong values.
>  * You cannot query the host llvm-config, because Exec format error.
> 
> Others have recognized that llvm-config is a repetition of a widley
> known mistake:
>  * https://bugs.llvm.org/show_bug.cgi?id=9405
>  * https://bugs.chromium.org/p/chromium/issues/detail?id=219369
> 
> Others are implementing workarounds now:
>  * https://github.com/voidlinux/void-packages/issues/1531
>  * https://github.com/mesonbuild/meson/issues/3327
> 
> There even is a tool to derive the .pc file from llvm-config:
>  * https://hackage.haskell.org/package/llvm-pkg-config
> 
> Helmut


The problem remains fully unsolved.

Helmut

Bug#1022681: clientsession

[Sean Whitton]

Hello Joey,

Would it be possible to replace git-annex's usage of clientsession, do
you think, or alternatively for you to start maintaining a fork, or
similar?  The Debian Haskell Team would like to remove clientsession as
unmaintained.  Ilias points out that the last upstream commit is from
2016, and there are PRs sitting there seemingly ignored.  Thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#1024488: kaddressbook: Unused build-dependency on libgpgmepp-dev?

[Patrick Franz]

Hi Andreas,

On Sun, 20 Nov 2022 16:12:33 +0100 Andreas Metzler  
wrote:
> Source: kaddressbook
> Version: 4:22.08.3-1
> Severity: minor
> 
> Hello,
> 
> afaict kaddressbook's b-d on libgpgmepp-dev is unused:
> ametzler@argenau:/tmp/BUGS$ grep -ril gpgme kaddressbook-22.08.3/ 
buildlog.kaddressbook_22.08.3-1_amd64
> kaddressbook-22.08.3/debian/control
> 
> Could you please doublecheck? - TIA!

It seems that the following commit removed it:
https://invent.kde.org/pim/kaddressbook/-/commit/
eb9dad153f199c925ac60c0a33eca6ff0c1f9f44

Will try not to forget to remove it before the next upload.


-- 
Med vänliga hälsningar

Patrick Franz

Bug#1024506: docker.io: FTBFS: FAIL: builder/remotecontext/git TestCheckoutGit

[Mathias Gibbens]

Source: docker.io
Version: 20.10.19+dfsg1-1
Severity: serious
Justification: FTBFS
Tags: bookworm sid ftbfs

  In a clean sid schroot, docker.io has a test that fails:

> make[1]: Entering directory '/<>'
> ## Test engine:
> cd /<>/_build/src/github.com/docker/docker \
> && TESTFLAGS='-test.short' ./hack/test/unit
> 
> [snip]
> 
> === Failed
> === FAIL: builder/remotecontext/git TestCheckoutGit (0.59s)
> gitutils_test.go:263: assertion failed: error is not nil: exit status 128
> 
> 
> DONE 2203 tests, 120 skipped, 1 failure in 63.763s
> make[1]: *** [debian/rules:129: override_dh_auto_test] Error 1

  The same error is occurring in the reproducible builds, for example
at 
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/docker.io_20.10.19+dfsg1-1.rbuild.log.gz


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

Bug#1024380: transition: simdjson

[M. Zhou]

Uploaded to unstable. Successfully built on all release archs:
https://buildd.debian.org/status/package.php?p=simdjson

On Sat, 2022-11-19 at 20:19 +0100, Sebastian Ramacher wrote:
> Control: tags -1 confirmed
> 
> On 2022-11-18 09:42:10 -0500, M. Zhou wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Dear release team,
> > 
> > There was some minor API updates in the latest version of simdjson,
> > which resulted an SOVERSION bump from 13 to 14. I've tried to build
> > its reverse dependencies locally on an amd64 host, and the results
> > are all good:
> > 
> > cloudflare-ddns [ok]
> > pcm [ok]
> > 
> > I'd like to transit and let the next stable release
> > ship the latest version.
> 
> Please go ahead.
> 
> Cheers

Bug#1024507: opencv: FTBFS (before_dh_strip_nondeterminism doesn't support binary-arch builds)

[Bas Couwenberg]

Source: opencv
Version: 4.6.0+dfsg-8
Severity: serious
Tags: ftbfs
Control: block 1023647 by -1

Dear Maintainer,

Your package FTBFS because the change for #1024482 doesn't support binary-arch 
builds:

 make[1]: Entering directory '/<>'
 # This can be deleted after https://github.com/doxygen/doxygen/pull/9227 is
 # in the version of Doxygen in Debian. It won't hurt afterwards, because
 # there will be nothing to strip anymore.
 sed -i -e 's,/<>/\(obj-x86_64-linux-gnu/\)\?,,g' \
debian/opencv-doc/usr/share/doc/opencv-doc/opencv4/html/opencv.tag
 sed: can't read 
debian/opencv-doc/usr/share/doc/opencv-doc/opencv4/html/opencv.tag: No such 
file or directory
 make[1]: *** [debian/rules:221: execute_before_dh_strip_nondeterminism] Error 2

https://buildd.debian.org/status/fetch.php?pkg=opencv&arch=amd64&ver=4.6.0%2Bdfsg-8&stamp=1668962551&raw=0

Only the arch:all build succeeded because the docs are built there:

 https://buildd.debian.org/status/package.php?p=opencv&suite=sid

Kind Regards,

Bas

Bug#893083: git pushed

[Santiago Vila]

El 20/11/22 a las 18:27, Geert Stappers escribió:

user debian-rele...@lists.debian.org
usertag 893083 + bsp-2022-11-nl-tilburg
tag 893083 + pending
thank you


Please don't. While I agree that it would be better to use git, forcing 
it via NMUs is unwelcome.

Bug#848055: golang-github-go-chef-chef: FTBFS randomly (failing tests)

[Mathias Gibbens]

Control: severity -1 serious

  Re-raising the severity of this bug, since I encountered the random
test failures today while working on updating another package that this
one depends upon.

  Given there are currently no rdeps on this package itself, and that
it was packaged to support packaging terraform (currently a RFP, see
#808940), I would argue this package in its current state should be
allowed to be removed from testing.

Mathias


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

Bug#1024508: RFS: kmscon/9.0.0-3 -- Simple terminal emulator based on Kernel Mode Setting

[Victor Westerhuis]

Package: sponsorship-requests
Severity: normal

Dear mentors,

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

 * Package name : kmscon
   Version  : 9.0.0-3
   Upstream contact : https://github.com/Aetf/kmscon/issues
 * URL  : https://github.com/Aetf/kmscon
 * License  : Expat and HPND, public-domain, Expat, LGPL-2.1+, GPL-2 
with Font exception
 * Vcs  : https://salsa.debian.org/viccie30/kmscon
   Section  : utils

The source builds the following binary packages:

  kmscon - Simple terminal emulator based on Kernel Mode Setting

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

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

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

  dget -x 
https://mentors.debian.net/debian/pool/main/k/kmscon/kmscon_9.0.0-3.dsc

Changes since the last upload:

 kmscon (9.0.0-3) unstable; urgency=medium
 .
   * Depend on init-system-helpers >= 1.65
   * Fix Built-Using calculation in d/rules
   * Register exception with needrestart (Closes: 1024345)
   * Update d/watch

Regards,
-- 
  Victor Westerhuis

Bug#1024509: ITP: minetest-mod-meshport -- Minetest mod - export areas to meshes for 3D rendering

[Ying-Chun Liu (PaulLiu)]

Package: wnpp
X-Debbugs-Cc: debian-de...@lists.debian.org
Owner: "Ying-Chun Liu (PaulLiu)" 
Severity: wishlist

* Package name: minetest-mod-meshport
  Version : 0.2.2
  Upstream Author : random-geek (https://github.com/random-geek)
* URL : https://github.com/random-geek/meshport
* License : LGPL-3.0+
  Programming Lang: Lua
  Description : Minetest mod - export areas to meshes for 3D rendering.
 Meshport is a mod which allows easy exporting of scenes from Minetest to
 obj files, complete with materials and textures. These models can be 
imported

 directly into Blender or another 3D program for rendering and animation.


OpenPGP_0x44173FA13D05.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Bug#1023846: transition: gdal

[Sebastiaan Couwenberg]

On 11/19/22 20:18, Sebastian Ramacher wrote:

On 2022-11-11 11:55:45 +0100, Bas Couwenberg wrote:

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition
X-Debbugs-Cc: pkg-grass-de...@lists.alioth.debian.org
Control: forwarded -1 https://release.debian.org/transitions/html/auto-gdal.html
Control: block -1 by 1023480 1023506 1004795 998833 984398 1023520 1012950

For the Debian GIS team I'd like to transition to GDAL 3.6.0.


Please go ahead
Thanks. gdal (3.6.0+dfsg-2) has been uploaded to unstable and took a 
while to get built on s390x, but is not built & installed on all release 
architectures.


Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

Bug#1020903: pipewire-pulse: Is the conflict with pulseaudio necessary?

[alain]

Package: pipewire-pulse
Followup-For: Bug #1020903
X-Debbugs-Cc: compte.perso.de-al...@bbox.fr

Thank you Dylan.

Indeed, as you have noticed, I have made some mistakes in the maintenance of my
sid.

When I broke my gnome desktop (with a full-upgrade) a few months ago, I
couldn't find a better solution than reinstalling the testing version.
It was blocking some of the updates.
phenomenon that you have highlighted very well.
I corrected it and (finally!) gnome is fully functional and up to date again.

I have nothing against pipewire . I have against the conflict that existed
until now with pulse audio .

I followed your advice, I rectified my big mistake and finally, not only, now
gnome is up to date but also, as you recommend, wireplumber and pipewire-pulse
are installed without worry.

Thanks for your comments and support.

you can close my intervention.


Translated with www.DeepL.com/Translator (free version)

merci Dylan .

en effet , comme tu l'as très bien remarqué , j'ai fait quelques erreurs  dans
la maintenance de ma sid .

quand j'ai cassé mon bureau gnome (avec un full-upgrade) il y a quelque mois ,
je n'ai pas trouvé de meilleure solution que de réinstaller la version testing
.
cela bloquait pour partie les mises à jour .
phénomène que tu as très bien mis en évidence .
je l'ai rectifié et (enfin !) gnome est à nouveau pleinement fonctionnel  et  à
jour .

je n'ai rien contre pipewire . j' en ai par contre contre le conflit qui
existait jusqu'ici avec pulse audio .

j'ai suivi tes conseils , j'ai rectifié ma grosse erreur et enfin , non
seulement , maintenant gnome est à jour mais en plus , comme tu le recommandes
, wireplumber et pipewire-pulse sont installés sans souci .

merci pour tes remarques et ton soutien .

tu peux clore mon intervention  .

alain@sid:~$ apt policy gnome-core wireplumber pipewire-pulse
gnome-core:
  Installé : 1:42+8
  Candidat : 1:42+8
 Table de version :
 *** 1:42+8 500
100 http://deb.debian.org/debian bookworm/main amd64 Packages
100 http://deb.debian.org/debian testing/main amd64 Packages
500 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
wireplumber:
  Installé : 0.4.12-1+b1
  Candidat : 0.4.12-1+b1
 Table de version :
 *** 0.4.12-1+b1 500
100 http://deb.debian.org/debian bookworm/main amd64 Packages
100 http://deb.debian.org/debian testing/main amd64 Packages
500 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status
pipewire-pulse:
  Installé : 0.3.60-2
  Candidat : (aucun)
 Table de version :
 *** 0.3.60-2 -1
100 http://deb.debian.org/debian bookworm/main amd64 Packages
100 http://deb.debian.org/debian testing/main amd64 Packages
500 http://deb.debian.org/debian unstable/main amd64 Packages
100 /var/lib/dpkg/status


note : et oui , c'est bien moi sur debian-facile (tu m'as bien trouvé) .
pourquoi ?


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/24 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 pipewire-pulse depends on:
ii  init-system-helpers  1.65.2
ii  pipewire 0.3.60-2

Versions of packages pipewire-pulse recommends:
ii  pulseaudio-utils  16.1+dfsg1-2+b1

Versions of packages pipewire-pulse suggests:
ii  libspa-0.2-bluetooth  0.3.60-2

-- no debconf information

Bug#900821: Found working and failing 5.10 versions and got kernel crash, report from BSP Tilburg (https://deb.li/iiOID)

[Diederik de Haas]

Control: found -1 4.9.88-1+deb9u1
Control: notfound -1 4.9.88-1

Hi Salvatore,

On zondag 20 november 2022 16:38:25 CET Salvatore Bonaccorso wrote:
> On Sun, Nov 20, 2022 at 04:26:45PM +0100, Diederik de Haas wrote:
> > Control: notfound -1 4.9.88-1+deb9u1
> > Control: found -1 4.9.88-1
> 
> Hmm this one I do not understand, as 4.9.88-1+deb9u1 was a very
> targetted fix for two CVEs and reverting the "random: fix crng_ready()
> test" changes re-opening CVE-2018-1108.

Oh, I thought that the +debXYZ thing confuses the bug tracker and therefor 
shouldn't be there*. All the notfound/found versions I reported were tested 
with a backports kernel, so +debXYZ, but I marked them without that suffix.
I thought that the 4.9.88-1+deb9u1 should therefor be corrected to be without 
the suffix.
(I don't see how that affects the CVEs though as that has nothing to do with 
this bug? But it's (very) possible I'm too tired atm)

*) The dependency graph at the top doesn't show the 4.9 version; later I 
realized that another 4.9 version was already there and that wasn't reflected 
in that graph either, so I reverted the change.

I don't know if the other found/notfound versions should be corrected.

> > IOW: that's your educated guess a git bisect could turn up?
> 
> Not really. I was more looking at between versions you are not able to
> reproduce the issue, looking through the upstream changes commits and
> noticing that dacb5d8875cc ("tcp: fix page frag corruption on page
> fault") mentions:
> 
> [...]
> Steffen reported a TCP stream corruption for HTTP requests
> served by the apache web-server using a cifs mount-point
> and memory mapping the relevant file.
> [...]
> 
> and then noticing that the upstrema commit was backported to 5.10.84
> an 5.15.7, which fall exactly in the ranges you have the switch of
> result.

That was what I actually meant, but I now realize that git bisect finds the 
cause while your educated guess is about the solution :-)

> > I can try that*, although I'm not clear onto what I should apply it.
> > Should I apply it to linux/5.10.70-1 or 5.10.46-4 f.e.? Or onto an
> > entirely
> > different version?
> 
> Basically I wonder if c6f340a331fb72e5ac23a083de9c780e132ca3ae in
> 5.10.84 fixes the issue, and
> c6f340a331fb72e5ac23a083de9c780e132ca3ae~1 still would show the
> problem.
> 
> Alterntively if 5.10.70-1 + commit fixes the issue.

It won't be tonight, but I'll likely try that :-)

Cheers,
  Diederik

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

Bug#1024510: do not include yet in a Debian stable release

[Bdale Garbee]

Package: sch-rnd
Version: 0.9.3-1
Severity: serious

Upstream was happy for me to package sch-rnd for Debian unstable, but
would prefer we not include it in a stable release until he makes a
stable upstream 1.0 release.

Bdale



signature.asc
Description: PGP signature

Bug#1024493: Proposed-RM: bs1770gain -- RoQA; inappropriate content

[Christoph Berg]

Re: Ansgar
> I proposed to remove bs1770gain from Debian. Besides the problem from
> #913352, the upstream homepage and domain that we direct users to (via
> Homepage: field and other places) contain extremist content.
> 
> I don't think it's worth distributing software that does this in
> Debian.

+1. The homepage is full of nazi symbols. Let's get rid of it.

> If there are no objections from the maintainers, I'll reassign this to
> ftp.d.o in the next days.

Might be worth considering removal from stable as well.

Christoph

Bug#893083: Hello Vcs fields

[Geert Stappers]

On Sun, Nov 20, 2022 at 07:48:04PM +0100, Santiago Vila wrote:
> El 20/11/22 a las 18:27, Geert Stappers escribió:
> > tag 893083 + pending
> 
> Please don't.


> While I agree that it would be better to use git,
> forcing it via NMUs is unwelcome.

Which way will it be?


Groeten
Geert Stappers
-- 
Silence is hard to parse


signature.asc
Description: PGP signature

Bug#1024511: freerdp2: CVE-2022-39316 CVE-2022-39317 CVE-2022-39318 CVE-2022-39319 CVE-2022-39320 CVE-2022-39347

[Salvatore Bonaccorso]

Source: freerdp2
Version: 2.8.1+dfsg1-1
Severity: important
Tags: security upstream
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerabilities were published for freerdp2.

CVE-2022-39316[0]:
| FreeRDP is a free remote desktop protocol library and clients. In
| affected versions there is an out of bound read in ZGFX decoder
| component of FreeRDP. A malicious server can trick a FreeRDP based
| client to read out of bound data and try to decode it likely resulting
| in a crash. This issue has been addressed in the 2.9.0 release. Users
| are advised to upgrade.


CVE-2022-39317[1]:
| FreeRDP is a free remote desktop protocol library and clients.
| Affected versions of FreeRDP are missing a range check for input
| offset index in ZGFX decoder. A malicious server can trick a FreeRDP
| based client to read out of bound data and try to decode it. This
| issue has been addressed in version 2.9.0. There are no known
| workarounds for this issue.


CVE-2022-39318[2]:
| FreeRDP is a free remote desktop protocol library and clients.
| Affected versions of FreeRDP are missing input validation in `urbdrc`
| channel. A malicious server can trick a FreeRDP based client to crash
| with division by zero. This issue has been addressed in version 2.9.0.
| All users are advised to upgrade. Users unable to upgrade should not
| use the `/usb` redirection switch.


CVE-2022-39319[3]:
| FreeRDP is a free remote desktop protocol library and clients.
| Affected versions of FreeRDP are missing input length validation in
| the `urbdrc` channel. A malicious server can trick a FreeRDP based
| client to read out of bound data and send it back to the server. This
| issue has been addressed in version 2.9.0 and all users are advised to
| upgrade. Users unable to upgrade should not use the `/usb` redirection
| switch.


CVE-2022-39320[4]:
| FreeRDP is a free remote desktop protocol library and clients.
| Affected versions of FreeRDP may attempt integer addition on too
| narrow types leads to allocation of a buffer too small holding the
| data written. A malicious server can trick a FreeRDP based client to
| read out of bound data and send it back to the server. This issue has
| been addressed in version 2.9.0 and all users are advised to upgrade.
| Users unable to upgrade should not use the `/usb` redirection switch.


CVE-2022-39347[5]:
| FreeRDP is a free remote desktop protocol library and clients.
| Affected versions of FreeRDP are missing path canonicalization and
| base path check for `drive` channel. A malicious server can trick a
| FreeRDP based client to read files outside the shared directory. This
| issue has been addressed in version 2.9.0 and all users are advised to
| upgrade. Users unable to upgrade should not use the `/drive`,
| `/drives` or `+home-drive` redirection switch.


CVE-2022-41877[6]:
| FreeRDP is a free remote desktop protocol library and clients.
| Affected versions of FreeRDP are missing input length validation in
| `drive` channel. A malicious server can trick a FreeRDP based client
| to read out of bound data and send it back to the server. This issue
| has been addressed in version 2.9.0 and all users are advised to
| upgrade. Users unable to upgrade should not use the drive redirection
| channel - command line options `/drive`, `+drives` or `+home-drive`.


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-39316
https://www.cve.org/CVERecord?id=CVE-2022-39316
[1] https://security-tracker.debian.org/tracker/CVE-2022-39317
https://www.cve.org/CVERecord?id=CVE-2022-39317
[2] https://security-tracker.debian.org/tracker/CVE-2022-39318
https://www.cve.org/CVERecord?id=CVE-2022-39318
[3] https://security-tracker.debian.org/tracker/CVE-2022-39319
https://www.cve.org/CVERecord?id=CVE-2022-39319
[4] https://security-tracker.debian.org/tracker/CVE-2022-39320
https://www.cve.org/CVERecord?id=CVE-2022-39320
[5] https://security-tracker.debian.org/tracker/CVE-2022-39347
https://www.cve.org/CVERecord?id=CVE-2022-39347
[6] https://security-tracker.debian.org/tracker/CVE-2022-41877
https://www.cve.org/CVERecord?id=CVE-2022-41877

Regards,
Salvatore

Bug#1024512: pillow: CVE-2022-45199: Limit SAMPLESPERPIXEL to avoid runtime DOS

[Salvatore Bonaccorso]

Source: pillow
Version: 9.2.0-1.1
Severity: important
Tags: security upstream
Forwarded: https://github.com/python-pillow/Pillow/pull/6700
X-Debbugs-Cc: car...@debian.org, Debian Security Team 

Hi,

The following vulnerability was published for pillow.

CVE-2022-45199[0]:
| Pillow before 9.3.0 allows denial of service via SAMPLESPERPIXEL.


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-45199
https://www.cve.org/CVERecord?id=CVE-2022-45199
[1] https://github.com/python-pillow/Pillow/pull/6700

Regards,
Salvatore

Bug#983912: grub2: consider renaming signed source packages to grub2-signed-*

[Salvatore Bonaccorso]

Hi,

On Wed, Mar 03, 2021 at 10:52:39AM +0100, Ansgar wrote:
> Source: grub2
> Version: 2.04-16
> Severity: normal
> X-Debbugs-Cc: ftpmas...@debian.org, debian-rele...@lists.debian.org
> 
> grub2 currently uses grub-efi-signed-* as source package names for the
> Secure Boot signed packages.  While releasing the last security update
> we found a small issue with these names:
> 
> dak processes source packages in lexiographic order, so it would
> process grub-efi-signed-* before grub2 when accepting all packages at
> once from the "embargoed" policy queue.  But the grub-efi-signed-*
> binary packages have Built-Using: grub2; as grub2 is not accepted from
> embargoed at this point in time, the /binary/ uploads will be rejected
> in this case.  (This problem exists in principle with all Built-Using
> relations.)
> 
> We could avoid this particular problem if the source package names of
> the signed packages sort after grub2, i.e., if they were named
> grub2-signed-* or grub2-efi-signed-*.  With linux this is already the
> case (src:linux and src:linux-signed-*).
> 
> (As a minor thing, I think the changelog entry in the signed packages
> should also use the grub maintainer's name, not ftpmaster@ similar to
> what src:linux-signed-* has, but that is just cosmetics.)
> 
> I've Cc'ed debian-release@ as it is already past soft freeze, but I
> think just renaming the source packages would be unlikely to break
> anything.

As we were hit by this issue in the last DSA (DSA 5280-1) again,
should we attempt to have this changed at least for bookworm?

Regards,
Salvatore

Bug#1024513: ITP: golang-github-influxdata-influxdb1-client -- Old clientv2 for InfluxDB 1.x

[Mathias Gibbens]

Package: wnpp
Severity: wishlist
Owner: Mathias Gibbens 
X-Debbugs-CC: debian-de...@lists.debian.org, debian...@lists.debian.org

* Package name: golang-github-influxdata-influxdb1-client
  Version : 0.0~git20220302.a9ab567-1
  Upstream Author : InfluxData
* URL : https://github.com/influxdata/influxdb1-client
* License : Expat
  Programming Lang: Go
  Description : Old clientv2 for InfluxDB 1.x
 influxdb1-clientv2 is the current Go client API for InfluxDB 1.x. For
 connecting to InfluxDB 2.x see the influxdb-client-go client library.
 .
 InfluxDB is an open-source distributed time series database, find more
 about InfluxDB at https://docs.influxdata.com/influxdb/latest

This is a dependency for packaging golang-github-uber-jaeger-lib
(ITP#942525) and will be team-maintained within the Go Packaging Team.


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

Bug#1024296: debhelper: makefile buildsystem: allow buildsystems to inherit cross-building powers

[Debian/GNU]

On 11/17/22 10:08, Helmut Grohne wrote:


How about replacing the check

 ref(this) eq '...::makefile'

with

 $this->can('configure') == Debian::Debhelper::Buildsystem->can('configure')

which is totally untested


not any longer :-)

i tested my use-case ('dh-sequence-pd-lib-builder'), and it does indeed 
produce the expected result. hooray.


i haven't done any testing beyond that :-/

gfmadsr
fIOhannes

OpenPGP_0xB65019C47F7A36F8.asc
Description: OpenPGP public key

Bug#1024493: Proposed-RM: bs1770gain -- RoQA; inappropriate content

[Petter Reinholdtsen]

I do not buy into the cancel culture.  I further do not find the guilt by
association argument (his web page is full of bad stuff, so his software
is bad) convincing.  In short, I fail to see it as an argument for
removing bs1770gain from Debian.

I removed the controversial text from the running program in response to
#913352, and see no point is doing anything more with that issue.

The bs1770gain program is an excellent tool to adjust the sound level of
media files, and I do not care much about any real or percived political
views of its author.  I see no need to spend time studying it, nor
comment on my view of it, in a Debian context.

-- 
Happy hacking
Petter Reinholdtsen

Bug#1024412: claws-mail: reproducible builds: Embeds timezone-dependent build date in manpages

[Ricardo Mones]

Hi Vagrant!

On Fri, 18 Nov 2022 13:32:24 -0800
Vagrant Cascadian  wrote:

> The attached patch to debian/rules fixes this by setting ISO_DATE
> using the UTC timezone.

Applied, thanks!

> According to my local tests, With this patch applied claws-mail should
> build reproducibly on tests.reproducible-builds.org!
> 
> Thanks for maintaining claws-mail!

Thank you for your work at reproducible builds! :)
-- 
 Ricardo Mones
 http://people.debian.org/~mones
 «Your true value depends entirely on what you are compared with.»


pgpSL4TaXtHnV.pgp
Description: OpenPGP digital signature

Bug#1024514: scribus: Need an easier way to maintain PDF annotations as internal links in a document

[Gary Dale]

Package: scribus
Version: 1.5.8+dfsg-3+b2
Severity: wishlist

Dear Maintainer,

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

   * What led up to the situation?
I have a document that uses a lot of PDF annotations to link other locations in 
the document. Unfortunately
there doesn't appear to be a way to keep them synchronized with their 
destinations as objects move around 
during editing.

   * What exactly did you do (or not do) that was effective (or ineffective)?
Currently I don't set the destination for the links until the document is 
nearly finalized. However the
document is public and is updated both before and after "finalization" which 
means links are either
missing or may need to changed.

   * What was the outcome of this action?
Even creating the links is a big job. Ensuring the remain accurate is tediosu 
and error prone.

   * What outcome did you expect instead?
Rather than pointing the links to a position on a page, I'd like to be able to 
point them to a specific
object (usually a text frame or box shape). Having a tool similar to the Table 
of Contents generator to 
set the actual link destinations based on the object location would then make 
life a lot simpler.


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


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

Kernel: Linux 6.0.0-4-amd64 (SMP w/24 CPU threads; PREEMPT)
Locale: LANG=iu_CA.UTF-8, LC_CTYPE=C.UTF-8 (charmap=locale: Cannot set 
LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
UTF-8), LANGUAGE=en_GB
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages scribus depends on:
ii  ghostscript  10.0.0~dfsg-6
ii  libc62.36-5
ii  libcairo21.16.0-6
ii  libcdr-0.1-1 0.1.6-2+b2
ii  libcups2 2.4.2-1+b2
ii  libfontconfig1   2.13.1-4.5
ii  libfreehand-0.1-10.1.2-3
ii  libfreetype6 2.12.1+dfsg-3
ii  libgcc-s112.2.0-9
ii  libgraphicsmagick-q16-3  1.4+really1.3.38+hg16739-1+b1
ii  libharfbuzz-icu0 5.2.0-2+b1
ii  libharfbuzz0b5.2.0-2+b1
ii  libhunspell-1.7-01.7.1-1
ii  libicu72 72.1-2
ii  libjpeg62-turbo  1:2.1.2-1+b1
ii  liblcms2-2   2.13.1-1+b1
ii  libmspub-0.1-1   0.1.4-3+b3
ii  libopenscenegraph161 3.6.5+dfsg1-8
ii  libopenthreads21 3.6.5+dfsg1-8
ii  libpagemaker-0.0-0   0.0.4-1
ii  libpng16-16  1.6.38-2
ii  libpodofo0.9.8   0.9.8+dfsg-3
ii  libpoppler12322.08.0-2.1
ii  libpython3.103.10.8-3
ii  libqt5core5a 5.15.6+dfsg-2+b1
ii  libqt5gui5   5.15.6+dfsg-2+b1
ii  libqt5network5   5.15.6+dfsg-2+b1
ii  libqt5opengl55.15.6+dfsg-2+b1
ii  libqt5printsupport5  5.15.6+dfsg-2+b1
ii  libqt5widgets5   5.15.6+dfsg-2+b1
ii  libqt5xml5   5.15.6+dfsg-2+b1
ii  libqxp-0.0-0 0.0.2-1+b3
ii  librevenge-0.0-0 0.0.4-6+b1
ii  libstdc++6   12.2.0-9
ii  libtiff5 4.4.0-5+b1
ii  libvisio-0.1-1   0.1.7-1+b3
ii  libxml2  2.9.14+dfsg-1.1+b2
ii  libzmf-0.0-0 0.0.2-1+b5
ii  scribus-data 1.5.8+dfsg-3
ii  zlib1g   1:1.2.11.dfsg-4.1

Versions of packages scribus recommends:
ii  cups-bsd2.4.2-1+b2
ii  fonts-dejavu2.37-2
ii  fonts-liberation1:1.07.4-11
ii  hyphen-en-us [hyphen-hyphenation-patterns]  2.8.8-7
ii  hyphen-sh [hyphen-hyphenation-patterns] 1:3.3.0-4
ii  icc-profiles-free   2.0.1+dfsg-1.1
ii  xfonts-scalable 1:1.0.3-1.2

Versions of packages scribus suggests:
ii  icc-profiles   2.1-2
pn  scribus-doc
pn  scribus-template   
ii  texlive-latex-recommended  2022.20220923-2

-- debconf information excluded

-- debsums errors found:
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "en_GB",
LC_ALL = (unset),
LC_TIME = "en_CA.UTF-8",
LC_MONETARY = "en_CA.UTF-8",
LC_CTYPE = "C.UTF-8",
LC_COLLATE = "en_CA.UTF-8",
LC_MEASUREMENT = "en_CA.UTF-8",
LC_NUMERIC = "en_CA.UTF-8",
LANG = "iu_CA.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").

Bug#990249: Giving it a try

[Leo Antunes]

Hi,

I'll give this a try for #1019518.
I'll start with the library to solve the dep, but try to get the binary while 
I'm at it.
Can't make any promises on the time frame :/

--
Leo