Bug#1014630: diff for NMU version 0.1-1.3

2022-07-08 Thread Nilesh Patra
Package: m16c-flash
Version: 0.1-1.2
Severity: normal
Tags: patch

I have uploaded version 0.1-1.3 for m15-flash.
Please find the patch attached for the same.

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

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

Versions of packages m16c-flash depends on:
ii  libc6   2.33-7
ii  libgcc-s1   12-20220302-1
ii  libstdc++6  12-20220302-1

m16c-flash recommends no packages.

m16c-flash suggests no packages.
diff -u m16c-flash-0.1/debian/changelog m16c-flash-0.1/debian/changelog
--- m16c-flash-0.1/debian/changelog
+++ m16c-flash-0.1/debian/changelog
@@ -1,3 +1,10 @@
+m16c-flash (0.1-1.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Get package cross-building
+
+ -- Nilesh Patra   Sat, 09 Jul 2022 12:06:22 +0530
+
 m16c-flash (0.1-1.2) unstable; urgency=medium
 
   * Non-maintainer upload.
only in patch2:
unchanged:
--- m16c-flash-0.1.orig/debian/patches/12_cross.patch
+++ m16c-flash-0.1/debian/patches/12_cross.patch
@@ -0,0 +1,32 @@
+--- Makefile   2006-08-22 13:59:42.0 +0530
 /tmp/Makefile  2022-07-09 12:00:22.682792078 +0530
+@@ -1,3 +1,4 @@
++CXX?=g++
+ CFLAGS+=-g -Wall -pedantic
+ LFLAGS+=
+ 
+@@ -11,19 +12,19 @@
+   rm m16c-flash
+ 
+ ccomport.o: ccomport.cxx ccomport.h
+-  g++ $(CFLAGS) ccomport.cxx -c -o ccomport.o 
++  $(CXX) $(CFLAGS) ccomport.cxx -c -o ccomport.o 
+ 
+ cpage.o: cpage.cxx cpage.h
+-  g++ $(CFLAGS) cpage.cxx -c -o cpage.o
++  $(CXX) $(CFLAGS) cpage.cxx -c -o cpage.o
+ 
+ cmotfile.o: cmotfile.cxx cmotfile.h
+-  g++ $(CFLAGS) cmotfile.cxx -c -o cmotfile.o
++  $(CXX) $(CFLAGS) cmotfile.cxx -c -o cmotfile.o
+ 
+ cm16flash.o: cm16flash.cxx cm16flash.h
+-  g++ $(CFLAGS) cm16flash.cxx -c -o cm16flash.o
++  $(CXX) $(CFLAGS) cm16flash.cxx -c -o cm16flash.o
+ 
+ m16c-flash: flashm16.cxx cm16flash.o cmotfile.o cpage.o ccomport.o
+-  g++ $(CFLAGS) flashm16.cxx cm16flash.o cmotfile.o cpage.o ccomport.o -o 
m16c-flash
++  $(CXX) $(CFLAGS) flashm16.cxx cm16flash.o cmotfile.o cpage.o ccomport.o 
-o m16c-flash
+ 
+ install:
+   cp m16c-flash /usr/bin


Bug#1014605: [Pkg-javascript-devel] Bug#1014605: node-functional.js: FTBFS, missing build-dependencies

2022-07-08 Thread Yadd

On 08/07/2022 18:14, Steve Langasek wrote:

Source: node-functional.js
Version: 0.8.0-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Stephan,

The node-functional.js binary in unstable was not built in the archive, and
attempting to rebuild this package from source fails due to missing build
dependencies:

[...]
dh_auto_build --buildsystem=nodejs
No build command found, searching known files
cd ./. && gulp
Can't exec "gulp": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 524.
dh_auto_build: warning: ### Command "gulp" failed in .
[...]

However, if I add the missing build-dependency on gulp, the package build
still fails with:

[...]
[16:10:38] Using globally installed gulp
Error: Cannot find module 'gulp-jshint'
Require stack:
- /tmp/node-functional.js-0.8.0/gulpfile.js
- /usr/share/nodejs/gulp-cli/lib/shared/require-or-import.js
- /usr/share/nodejs/gulp-cli/lib/versioned/^4.0.0/index.js
- /usr/share/nodejs/gulp-cli/index.js
- /usr/share/nodejs/gulp/bin/gulp.js
 at Function.Module._resolveFilename 
(node:internal/modules/cjs/loader:933:15)
 at Function.Module._load (node:internal/modules/cjs/loader:778:27)
 at Module.require (node:internal/modules/cjs/loader:1005:19)
 at require (node:internal/modules/cjs/helpers:102:18)
 at Object. (/tmp/node-functional.js-0.8.0/gulpfile.js:2:14)
 at Module._compile (node:internal/modules/cjs/loader:1105:14)
 at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
 at Module.load (node:internal/modules/cjs/loader:981:32)
 at Function.Module._load (node:internal/modules/cjs/loader:822:12)
 at Module.require (node:internal/modules/cjs/loader:1005:19) {
   code: 'MODULE_NOT_FOUND',
   requireStack: [
 '/tmp/node-functional.js-0.8.0/gulpfile.js',
 '/usr/share/nodejs/gulp-cli/lib/shared/require-or-import.js',
 '/usr/share/nodejs/gulp-cli/lib/versioned/^4.0.0/index.js',
 '/usr/share/nodejs/gulp-cli/index.js',
 '/usr/share/nodejs/gulp/bin/gulp.js'
   ]
}
dh_auto_build: warning: ### Command "gulp" failed in .
[...]

I can't find this gulp-jshint anywhere in the archive, so it looks like
there's some work to be done here.


Hi,

gulp-jshint is not needed, just to patch gulpfile.js.
However, node-funtional.js was accepted to unstable 146 days ago, but:
 * never build cleanly
 * no source upload for 6 month
 * no git activity
 * no question/help asked to JS Team list

So this package looks unmaintained and shouldn't migrate to testing.

Same for: jquery-datetimepicker, jquery-sortablejs, 
libjs-php-date-formatter, node-base16, materialize, node-bash-color, 
node-blacklist, node-create-react-class, node-grunt-timer, node-is-wsl,...




Bug#1014629: diff for NMU version 1.33MR33-6.3

2022-07-08 Thread Nilesh Patra
Package: pccts
Version: 1.33MR33-6.2
Severity: normal
Tags: patch

Dear Maintainer

I had uploaded version 6.3 for pccts a couple of days
back. Please find the patch attached for the same.

Best,
Nilesh

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

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

Versions of packages pccts depends on:
ii  libc6  2.33-7

pccts recommends no packages.

pccts suggests no packages.
diff -Nru pccts-1.33MR33/debian/changelog pccts-1.33MR33/debian/changelog
--- pccts-1.33MR33/debian/changelog 2022-05-26 04:24:42.0 +0530
+++ pccts-1.33MR33/debian/changelog 2022-07-06 15:42:30.0 +0530
@@ -1,3 +1,10 @@
+pccts (1.33MR33-6.3) unstable; urgency=medium
+
+  * Non-maintainer upload.
+  * Fix FTCBFS: Set CC in accordance with buildtools.mk
+
+ -- Nilesh Patra   Wed, 06 Jul 2022 15:42:30 +0530
+
 pccts (1.33MR33-6.2) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru pccts-1.33MR33/debian/rules pccts-1.33MR33/debian/rules
--- pccts-1.33MR33/debian/rules 2022-05-26 04:19:24.0 +0530
+++ pccts-1.33MR33/debian/rules 2022-07-06 15:35:26.0 +0530
@@ -10,13 +10,14 @@
 #COPT+=-g
 #endif
 #
+include /usr/share/dpkg/buildtools.mk
 
 build build-arch: build-stamp
 build-stamp:
dh_testdir
 
# Add here commands to compile the package.
-   $(MAKE)
+   $(MAKE) CC="$(CC)"
 
touch build-stamp
 


Bug#1013080: dask: incompatibility with scipy 1.8

2022-07-08 Thread Diane Trout
On Sat, 2022-06-25 at 10:17 +0200, Graham Inggs wrote:
> Control: severity -1 serious
> Control: tags -1 + patch
> 
> Please see attached patch from Ubuntu for this issue.


Thank you for the patch it worked well. I wanted to give a status
update since it's been a while.

I haven't made as much progress as I should've I tried to update to
2022.6 but that depends on pyarrow and adding that looks like it will
requires packaging the full Apache arrow library

https://github.com/apache/arrow

That looks like it'll be a bit unpleasant to package because it's a
library designed to interact with a large number of other languages and
environments.

Then I went back and started updating and got discovered they'd added
the arrow dependency in 2022.03 which is the version with the fix you
need in it.

I have a version of 2022.02.0 that built with the patch and tested
correctly with scipy 1.8.1, but I need to clean up my repository some
before I push anything new to salsa.

There's also a few new simple sphinx build dependencies that look like
they were added in 2022.03 but those were pretty easy to package,
though I still need to upload them to NEW.

Hopefully I'll have something uploaded in a day or two.

Diane



Bug#1014628: src:git-annex: fails to migrate to testing for too long: FTBFS on armel and armhf

2022-07-08 Thread Paul Gevers

Source: git-annex
Version: 8.20211123-1
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:git-annex has been trying to migrate for 
61 days [2]. Hence, I am filing this bug. Your package failed to build 
from source on armel and armhf where it built successfully in the past.


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


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


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


Paul

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



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014627: maude: FTBFS with glibc 2.34

2022-07-08 Thread Steve Langasek
Package: maude
Version: 3.2-1
Severity: serious
Tags: patch
Justification: ftbfs
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear maintainers,

In Ubuntu, the maude package fails to build from source because it tries to
use SIGSTKSZ as a constant, and as of glibc 2.34 this is now defined as a
runtime call to sysconf() instead.

[...]
g++ -DHAVE_CONFIG_H -I. -I../..  -I../../src/Utility -I../../src/Temporal 
-I../../src/Interface -I../../src/Core -I../../src/Variable 
-I../../src/FullCompiler -I../../src/Higher -I../../src/CUI_Theory 
-I../../src/S_Theory -I../../src/NA_Theory -I../../src/FreeTheory 
-I../../src/ObjectSystem -I../../src/Mixfix -I../../src/BuiltIn 
-I../../src/Parser -I../../src/IO_Stuff -I../../src/ACU_Persistent 
-I../../src/ACU_Theory -I../../src/AU_Persistent -I../../src/AU_Theory 
-I../../src/Meta -I../../src/3rdParty -I../../src/FullCompiler 
-I../../src/StrategyLanguage -I../../src/SMT -Wdate-time -D_FORTIFY_SOURCE=2  
-g -O2 -ffile-prefix-map=/<>=. -flto=auto -ffat-lto-objects 
-flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat 
-Werror=format-security -fpermissive -c -o 
libmixfix_a-userLevelRewritingContext.o `test -f 'userLevelRewritingContext.cc' 
|| echo './'`userLevelRewritingContext.cc
In file included from userLevelRewritingContext.cc:75:
interact.cc: In static member function ‘static void 
UserLevelRewritingContext::setHandlers(bool)’:
interact.cc:120:15: error: storage size of ‘altStack’ isn’t constant
  120 |   static char altStack[SIGSTKSZ];
  |   ^~~~
make[6]: *** [Makefile:1019: libmixfix_a-userLevelRewritingContext.o] Error 1
[...]

  (https://launchpad.net/ubuntu/+source/maude/3.2-1/+build/23574061)

Debian currently only has glibc 2.34 in experimental, but at some point will
be updated, making this a critical build failure.

The attached patch has fixed the build failure for me.  Please consider
applying in Debian.

Thanks,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru maude-3.2/debian/patches/glibc-2.34.patch 
maude-3.2/debian/patches/glibc-2.34.patch
--- maude-3.2/debian/patches/glibc-2.34.patch   1969-12-31 16:00:00.0 
-0800
+++ maude-3.2/debian/patches/glibc-2.34.patch   2022-07-08 22:46:37.0 
-0700
@@ -0,0 +1,24 @@
+Description: handle non-constant SIGSTKSZ
+ As of glibc 2.34, SIGSTKSZ is no longer a constant, but rather a runtime
+ call to sysconf().  Allocate our stack at runtime instead of at compile
+ time.
+Author: Steve Langasek 
+Last-Update: 2022-07-08
+Forwarded: no
+
+Index: maude-3.2/src/Mixfix/interact.cc
+===
+--- maude-3.2.orig/src/Mixfix/interact.cc
 maude-3.2/src/Mixfix/interact.cc
+@@ -117,9 +117,9 @@
+   //  Stack overflows are reported as SIGSEGV signals and so we need to use 
the
+   //  libsigsegv library to heuristically distinguish the two conditions.
+   //
+-  static char altStack[SIGSTKSZ];
++  static char *altStack = malloc(SIGSTKSZ);
+   sigsegv_install_handler(sigsegvHandler);  // illegal memory access or stack 
overflow
+-  stackoverflow_install_handler(stackOverflowHandler, altStack, 
sizeof(altStack));
++  stackoverflow_install_handler(stackOverflowHandler, altStack, SIGSTKSZ);
+ #else
+   //
+   //  If we can't use the library we will will catch SIGSEGVs but not install
diff -Nru maude-3.2/debian/patches/series maude-3.2/debian/patches/series
--- maude-3.2/debian/patches/series 2022-02-19 12:29:38.0 -0800
+++ maude-3.2/debian/patches/series 2022-07-08 22:37:32.0 -0700
@@ -2,3 +2,4 @@
 getinput-size_t.patch
 strip-build-date.patch
 skip_failing_test.patch
+glibc-2.34.patch


Bug#1003397: ITP: rapidyaml -- a library to parse and emit YAML, and do it fast.

2022-07-08 Thread M. Zhou
Control: retitle -1 RFP: rapidyaml -- a library to parse and emit YAML, and do 
it fast.
Control: owner -1 w...@debian.org

I'm giving up this ITP bug. Any one who is interested in this ITP can take it 
over.



Bug#1014626: primer3: completely broken debian/rules handling of big-endian archs

2022-07-08 Thread Steve Langasek
Package: primer3
Version: 2.6.1-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Dear maintainers,

The primer3 package contains code in debian/rules whose purpose is to
monkeypatch the testsuite on big-endian architectures to disable certain
tests.

Instead, it mangles the files under test/ completely on big-endian archs,
causing the testsuite to fail to be run.

It seems that somewhere along the way it was decided to remove s390x
binaries from the Debian archive rather than fix debian/rules.  But the code
remains.

Attached is a patch that fixes the sed commands being used to mangle the
testsuite, which would let the package build on s390x again.

Please either apply this patch, or else drop the mangling code from
debian/rules to let the s390x build fail cleanly.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru primer3-2.6.1/debian/rules primer3-2.6.1/debian/rules
--- primer3-2.6.1/debian/rules  2022-02-19 08:57:05.0 -0800
+++ primer3-2.6.1/debian/rules  2022-07-08 22:18:02.0 -0700
@@ -29,9 +29,8 @@
cp -a test/Makefile test/Makefile~
# exclude tests known to fail on big endian
# See README.source for further explanation.
-   for tst in $(P3CORE_FAILED_TESTS) ; do sed -i "/$${tst}/d" 
test/p3test.pl ; done
-   sed -i "0,/$(FAILED_TESTS)/s///" test/Makefile
-   sed -i "/$(FAILED_TESTS)/,/endif/d" test/Makefile
+   for tst in $(P3CORE_FAILED_TESTS) ; do sed -i "/$${tst}.,/d" 
test/p3test.pl ; done
+   for tst in $(FAILED_TESTS); do sed -i "/^test:/s/$$tst//" 
test/Makefile; done
 endif
dh_auto_test --no-parallel --sourcedirectory=test
 ifneq ($(BUILDARCH),little)


Bug#1014625: xterm: screen corruption of scrollback buffer

2022-07-08 Thread Tim Connors
Package: xterm
Version: 372-1
Severity: normal

I'm getting screen corruption (scattered blocks of blackness) over
text in the xterm display when scrolling back.  The blocks move with
the contents of the scrollback when scrolling.  When that text is
eventually scrolled off the screen, scrolling back may induce a
different corruption pattern.  Forcing a redisplay of the contents of
the terminal by going to a different virtual desktop and back will get
rid of the corruption.

This has happened ever since I changed my hardware -- mostly updating
my video card to a radeon RX570 -- necessitating new versions of some
drivers and kernel.  While I would happily accept that the video card
might have some dodgy memory (note to self: find a GPU memory stress
tester), this corruption has not affected any other program other than
xterm's scrollback buffer, so I wonder if it's a bug instead.

Screengrabs of the symptom:

https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption.png
https://rather.puzzling.org/~tconnors/tmp/screengrab-xterm-scrollback-corruption2.png

radeon amdgpu drivers and firmware are the latest version allowed by
otherwise being on debian stable - ie,

firmware-amd-graphics/unstable=20210818-1
xserver-xorg-video-amdgpu/stable=19.1.0-2 (backporting requires upgrading libc)

kernel is bullseye-backports = 5.18.2-1~bpo11+1

Both xterm/stable and a backported xterm/unstable exhibit the same symptoms.

Video card is:
02:00.0 0300: 1002:67df (rev ef) (prog-if 00 [VGA controller])
02:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
Ellesmere [Radeon RX 470/480/570/570X/580/580X/590] (rev ef) (prog-if 00 [VGA 
controller])
Subsystem: ASRock Incorporation Ellesmere [Radeon RX 
470/480/570/570X/580/580X/590]



-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable'), (5, 'testing'), (2, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.16.0-0.bpo.4-amd64 (SMP w/20 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages xterm depends on:
ii  libc6   2.31-13+deb11u3
ii  libfontconfig1  2.13.1-4.2
ii  libfreetype62.10.4+dfsg-1
ii  libice6 2:1.0.10-1
ii  libtinfo6   6.2+20201114-2
ii  libutempter01.2.1-2
ii  libx11-62:1.7.2-1
ii  libxaw7 2:1.0.13-1.1
ii  libxext62:1.3.3-1.1
ii  libxft2 2.3.2-2
ii  libxinerama12:1.1.4-2
ii  libxmu6 2:1.1.2-2+b3
ii  libxpm4 1:3.5.12-1
ii  libxt6  1:1.2.0-1
ii  xbitmaps1.1.1-2.1

Versions of packages xterm recommends:
ii  x11-utils  7.7+5

Versions of packages xterm suggests:
pn  xfonts-cyrillic  

-- no debconf information



Bug#1014624: FTCBFS: uses build compiler instead of host

2022-07-08 Thread Nilesh Patra
Package: verse
Version: 0.22.8
Severity: normal
Tags: patch

Hi,

verse fails to cross build because:

- It hardcodes gcc in the Makefile rather than using
$(CC) which the cross build system could pass the host compiler
- It strips the verse binary using build architecture's strip.
IMHO this is not needed as we can simply let dh_strip do the job.

Please consider applying the attached patch.

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

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

Versions of packages verse depends on:
pn  dialog  
ii  libc6   2.33-7

verse recommends no packages.

verse suggests no packages.
diff --git a/Makefile b/Makefile
index 5f2f8b0..c9b9a1e 100644
--- a/Makefile
+++ b/Makefile
@@ -6,6 +6,7 @@ CFLAGS = -Wall -g -O2 -ansi $(shell dpkg-buildflags --get 
CFLAGS)
 CPPFLAGS = $(shell dpkg-buildflags --get CPPFLAGS)
 LDFLAGS = $(shell dpkg-buildflags --get LDFLAGS)
 MAN_DIR = /usr/share/man/man1
+CC ?= gcc
 
 all : verse
 
@@ -15,8 +16,7 @@ clean :
 distclean : clean
 
 verse : verse.c
-   gcc $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) 
-DVERSE_LIB=\"$(VERSE_LIB)$(VERSE_NAME)\" -o verse verse.c
-   strip verse
+   $(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) 
-DVERSE_LIB=\"$(VERSE_LIB)$(VERSE_NAME)\" -o verse verse.c
 
 install : verse $(VERSE_NAME)
install -m 755 -d debian/verse/$(BIN_DIR)


Bug#1014623: xjig: build-depends on obsolete libnetpbm10-dev, ftbfs with libnetpbm11-dev

2022-07-08 Thread Steve Langasek
Source: xjig
Version: 2.4-14.2
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Dave,

The xjig package build-depends on libnetpbm10-dev, which is obsolete. 
Unfortunately, updating the package to build-depend on libnetpbm11-dev is
not enough, as the package fails to build:

[...]
c++ -g -Wall -Wdate-time -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wl,-z,now 
-DUSE_MIT_SHM  -Wdate-time -D_FORTIFY_SOURCE=2  -c -o ppm_image.o ppm_image.C
ppm_image.C:5:10: fatal error: ppm.h: No such file or directory
5 | #include 
  |  ^~~
compilation terminated.
make[2]: *** [: ppm_image.o] Error 1
[...]

Building with -I/usr/include/netpbm also doesn't work:

$ c++ -g -Wall -I/usr/include/netpbm -Wdate-time -D_FORTIFY_SOURCE=2 
-Wl,-z,relro -Wl,-z,now -DUSE_MIT_SHM  -Wdate-time -D_FORTIFY_SOURCE=2  -c -o 
ppm_image.o ppm_image.C
ppm_image.C:7:1: error: expected declaration before '}' token
7 | }
  | ^
ppm_image.C: In member function 'virtual int ppmImage::LoadImageFile(FILE*)':
ppm_image.C:30:28: warning: ISO C++ forbids converting a string constant to 
'char*' [-Wwrite-strings]
   30 | char *fake_argv[]={"xjig-ppm-loader", 0};
  |^
$

So it looks like this package needs some attention.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature


Bug#922396: webext-noscript: version out of date -- does not work with current Firefox

2022-07-08 Thread Witold Barylulk
Package: webext-noscript
Followup-For: Bug #922396
X-Debbugs-Cc: witold.bary...@gmail.com

Just a personal opinion, but I tried switching to webext-umatrix, and was
not able to use it effectively. It is way more obtrusive, more complex
and harder to use compared to NoScript.

NoScript upstream is actively maintained, with regular releases, about 1
or 2 times per months (not that it requires many updates). Latest:

Version 11.4.6
Released May 27, 2022 - 894.5 KB
Works with firefox 59.0 and later, android 59.0 and later


Regards,
Witold

-- System Information:
Debian Release: bookworm/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.19.0-rc5 (SMP w/32 CPU threads; PREEMPT)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)



Bug#955763: python3-coverage: Entry point error on some supported Python versions

2022-07-08 Thread Ben Finney
Control: tags -1 - moreinfo + confirmed
Control: retitle -1 python3-coverage: Entry point error on some supported 
Python versions
Control: found -1 python3-coverage/6.2+dfsg1-2
Control: summary -1 0

The upstream install script does not handle all Debian supported
Python versions.

This is caused by the hard-coding of only the default Python
interpreter during installation of console scripts. The result is that
any other Python version does not have a working entry point:

$ python3-coverage --version
Coverage.py, version 6.2 with C extension
Full documentation is at https://coverage.readthedocs.io

$ python3.9-coverage --version
Coverage.py, version 6.2 with C extension
Full documentation is at https://coverage.readthedocs.io

$ python3.10-coverage --version
Traceback (most recent call last):
  File "/usr/bin/python3.10-coverage", line 33, in 
sys.exit(load_entry_point('coverage==6.2', 'console_scripts', 
'python3.10-coverage')())
  File "/usr/bin/python3.10-coverage", line 25, in 
importlib_load_entry_point
return next(matches).load()
StopIteration

On 04-Apr-2020, Uwe Hermann wrote:

> Adding the following line to
> /usr/lib/python3/dist-packages/coverage-4.5.2.egg-info/entry_points.txt
> seems to fix it:
> 
> python3.8-coverage = coverage.cmdline:main

That would get a command that runs, yes; but it does not specifically
target Python 3.8 as intended.

Instead, the installation procedure needs to be changed so that it
specifically installs console scripts with each correct Python
interpreter shebang line.

-- 
 \  “Earth gets its price for what Earth gives us.” —James Russell |
  `\Lowell |
_o__)  |
Ben Finney 


signature.asc
Description: PGP signature


Bug#995692: please increase severity

2022-07-08 Thread James McCoy
On Mon, Jul 04, 2022 at 02:08:15PM +0200, debb...@igor2.repo.hu wrote:
> Dear packager!
> 
> This is biting me more and more often. It's real annoying that I have to 
> compile from source with such extensive dependencies because of this one 
> missing configure setting. For me, severity of this bug is becoming major.

Thanks for your patience.  I intended to follow up on this, but then it
fell off my radar.  I'll get back to this in the next few days.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB



Bug#1014394: linux kernel 5.10.0-15 on virtualbox host causes random process crashes in guests

2022-07-08 Thread Mike Kupfer
Bastian Blank wrote:

> As Virtualbox uses it's own kernel module, we can't provide any help.
> You need to ask them for a fixed version to work with that kernel
> version.

FWIW, I'm running a test build[1] of VirtualBox with the -15 kernel on
the host.  I, too, had the problem of Firefox crashing regularly with
VirtualBox 6.1.34, but things seem stable with VirtualBox 6.1.35
r151864.

mike
[1] https://www.virtualbox.org/wiki/Testbuilds



Bug#1014594: muse: FTBFS on riscv64

2022-07-08 Thread Paul Wise
On Fri, 2022-07-08 at 13:46 +, Ileana Dumitrescu wrote:

> The attached patch fixes the issue, and I will create a merge request
> on the salsa repo at https://salsa.debian.org/multimedia-team/muse.

This patch introduces an embedded copy of CheckAtomic.cmake from the
extra-cmake-modules package but such copies are against Debian policy.

https://wiki.debian.org/EmbeddedCopies

Instead the package should build-depend on extra-cmake-modules and add
the relevant changes to the cmake files to load the CheckAtomic
functionality installed in the extra-cmake-modules package.
The ECM documentation mentions how to load the modules.

https://api.kde.org/ecm/manual/ecm.7.html

You can find examples of packages using ECM via Debian Code Search:

https://codesearch.debian.net/search?q=find_package.*ECM&literal=0

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


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


Bug#1014619: libstdc++-arm-none-eabi: dpkg-buildflags leak into target build

2022-07-08 Thread Steve Langasek
Package: libstdc++-arm-none-eabi
Version: 20
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Keith,

libstdc++-arm-none-eabi has been stuck in Ubuntu since version 18, with all
related autopkgtests failing.  Tracking this down, I find that the problem
is g++ is trying to call lto1:

[...]
arm-none-eabi-g++ multiram.cc ../../startup/startup_ARMCM0.S -mthumb 
-mcpu=cortex-m0 -D__NO_SYSTEM_INIT -Os -flto -ffunction-sections 
-fdata-sections -D__STARTUP_COPY_MULTIPLE -D__STARTUP_CLEAR_BSS_MULTIPLE 
-fno-exceptions --specs=nano.specs --specs=rdimon.specs -L. -L../../ldscripts 
-T multi-ram.ld -Wl,--gc-sections -Wl,-Map=multiram.map -o multiram-CM0.axf
during IPA pass: inline
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
lto-wrapper: fatal error: arm-none-eabi-g++ returned 1 exit status
compilation terminated.
/usr/lib/gcc/arm-none-eabi/10.3.1/../../../arm-none-eabi/bin/ld: error: 
lto-wrapper failed
[...]

  
(https://autopkgtest.ubuntu.com/results/autopkgtest-kinetic/kinetic/amd64/b/binutils-arm-none-eabi/20220621_090851_aa0ae@/log.gz)

The issue is that Ubuntu uses LTO by default *on amd64*, and the change to
include the output of dpkg-buildflags somehow has the effect that LTO is now
being used for the target.

This does not currently cause a problem in Debian because Debian is not
doing LTO by default; but there is discussion about changing this, so this
will likely become a problem in Debian as well within the current release
cycle.

One way to solve this would be to set DEB_BUILD_OPTIONS=optimize=-lto, to
exclude the LTO flags specifically so that they don't leak into the target
builds.  Another thought I had was to use the dpkg-buildflags for armhf as a
target architecture, since there could be other per-arch flags in the future
that cause further problems.  I've tried the latter approach in the attached
patch, which fixes the problem of lto being incorrectly used for the
arm-none-eabi target.  I've verified that the resulting libstdc++ is usable
again with this change.

Thanks for considering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libstdc++-arm-none-eabi-20/debian/rules 
libstdc++-arm-none-eabi-20ubuntu1/debian/rules
--- libstdc++-arm-none-eabi-20/debian/rules 2022-03-25 15:22:56.0 
-0700
+++ libstdc++-arm-none-eabi-20ubuntu1/debian/rules  2022-07-08 
12:25:35.0 -0700
@@ -12,6 +12,9 @@
 include /usr/share/dpkg/pkg-info.mk
 include /usr/share/dpkg/buildflags.mk
 
+CFLAGS := $(shell env DEB_HOST_ARCH=armhf dpkg-buildflags --get CFLAGS)
+CXXFLAGS := $(shell env DEB_HOST_ARCH=armhf dpkg-buildflags --get CXXFLAGS)
+
 SVERSION := $(shell dpkg-query -W -f="\$${Version}\n" $(GCC_PACKAGE)-source)
 DVERSION := $(SVERSION)+$(DEB_VERSION)
 UVERSION := $(shell echo $(DVERSION) | cut -d- -f1)


Bug#1014618: tpot: FTBFS in unstable

2022-07-08 Thread Steve Langasek
Source: tpot
Version: 0.11.7+dfsg-3
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Christian,

While trying to get the tpot package built in Ubuntu, I've found that it
fails to build in both Debian and Ubuntu:

[...]
==
FAIL: Assert that the TPOTClassifier score function outputs a known score for a 
fixed pipeline.
--
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/nose/case.py", line 197, in runTest
self.test(*self.arg)
  File 
"/tmp/tpot-0.11.7+dfsg/.pybuild/cpython3_3.10_tpot/build/tests/tpot_tests.py", 
line 642, in test_score_2
assert np.allclose(known_score, score)
AssertionError

--
Ran 249 tests in 87.864s

FAILED (SKIP=1, failures=1)
E: pybuild pybuild:369: test: plugin distutils failed with: exit code=1: cd 
/tmp/tpot-0.11.7+dfsg/.pybuild/cpython3_3.10_tpot/build; python3.10 -m nose -v 
--ignore-files nn_tests.py --exclude test_log_file_verbose_3 --exclude 
test_sample_weight_func
dh_auto_test: error: pybuild --test -i python{version} -p "3.9 3.10" returned 
exit code 13
[...]

  (https://launchpad.net/ubuntu/+source/tpot/0.11.7+dfsg-3/+build/23574118)

I have no insights into the cause of this build regression, sorry!

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature


Bug#1014537: unnamed packaging files in a multibinary package should be an error

2022-07-08 Thread gregor herrmann
On Thu, 07 Jul 2022 08:48:36 -0700, Steve Langasek wrote:

> This kind of packaging, with some packaging files under debian/ having an
> associated binary package name and some not, is an antipattern.

+1

(I also don't like packaging files without binary package name for
single-binary source package, but that's just a matter of taste.)
 
> I would like to suggest that in the next debhelper compat level, debhelper
> should consider it an error when debian/control lists more than one binary
> package, but contains unnamed packaging files under debian/.  

Or maybe start with a warning (maybe immediately) and then proceed to
an error?

I also wonder if a lintian warning might be helpful to get this
going.
(And I admit that I haven't checked if such a lintian tag exists but
I can't remember seeing one.)


Cheers,
gregor

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


signature.asc
Description: Digital Signature


Bug#1014617: libfcgi-perl: perl is segfaulting and I think it's CGI::Fast

2022-07-08 Thread Ian Jackson
Hi.  What a quick reply!

gregor herrmann writes ("Re: Bug#1014617: libfcgi-perl: perl is segfaulting and 
I think it's CGI::Fast"):
> You're filing this bug against libfcgi-perl, and in the subject you
> say "I think it's CGI::Fast".
> 
> I'd just like to mention that CGI::Fast is in the libcgi-fast-perl
> package.

I am obviously confused.

...

Ah I see.  I mean that I think it's FCGI.so which is in libfcgi-perl
which is loaded by CGI::Fast.  And CGI::Fast, aka libcgi-fast-perl, is
pure perl so I doubt it is reponsible.

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.



Bug#1014617: libfcgi-perl: perl is segfaulting and I think it's CGI::Fast

2022-07-08 Thread gregor herrmann
On Fri, 08 Jul 2022 22:38:34 +0100, Ian Jackson wrote:

> Package: libfcgi-perl
> Version: 0.79+ds-2
> Severity: normal

You're filing this bug against libfcgi-perl, and in the subject you
say "I think it's CGI::Fast".

I'd just like to mention that CGI::Fast is in the libcgi-fast-perl
package.

Cheers,
gregor

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


signature.asc
Description: Digital Signature


Bug#1008092: antiword: Buffer overflow in the vAnalyseSummaryInfo function in summary.c in Antiword 0.37

2022-07-08 Thread Olly Betts
Control: tag -1 +moreinfo
Control: severity -1 normal

On Thu, Mar 24, 2022 at 04:00:23AM +, Olly Betts wrote:
> On Tue, Mar 22, 2022 at 06:56:23PM +0800, Jieyong Ma @ tdhxkj.com wrote:
> > Backtraces:
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x00449515 in vAnalyseSummaryInfo (aucBuffer=0x6928f0 "t\001") at 
> > summary.c:225
> > 225 switch (tPropID) {
> 
> That seems a surprising line to segfault on as there's no dereference
> happening.  Maybe optimisation has lead to misleading debug line numbers
> though.
> 
> > (gdb) bt
> > #0  0x00449515 in vAnalyseSummaryInfo (aucBuffer=0x6928f0 "t\001") 
> > at summary.c:225
> > #1  vSetSummaryInfoOLE (pFile=0x68f2e0, pFile@entry=0x37, 
> > pPPS=0x7fffbb10, pPPS@entry=0x68f2e0, aulBBD=0x68fb00, 
> > aulBBD@entry=0x7fffbb80, tBBDLen=55, tBBDLen@entry=37, 
> > aulSBD=aulSBD@entry=0x68fe80, tSBDLen=tSBDLen@entry=2)
> > at summary.c:628
> > #2  0x00449bcf in vSet8SummaryInfo (pFile=0xff7f013c, 
> > pFile@entry=0x68f2e0, pPPS=0x692a08, pPPS@entry=0x7fffbb10, aulBBD=0xb, 
> > aulBBD@entry=0x68fb00, tBBDLen=10, tBBDLen@entry=55, aulSBD=0x692820, 
> > aulSBD@entry=0x68fe80,
> > tSBDLen=29113347658312010, tSBDLen@entry=2, aucHeader=0x2  > Cannot access memory at address 0x2>) at summary.c:686
> > #3  0x00442126 in vGetPropertyInfo (pFile=pFile@entry=0x68f2e0, 
> > pPPS=0x7fffbb10, pPPS@entry=0x7fffbb00, 
> > aulBBD=aulBBD@entry=0x68fb00, tBBDLen=, tBBDLen@entry=55, 
> > aulSBD=0x68fe80, aulSBD@entry=0x68fb00,
> > tSBDLen=2, tSBDLen@entry=0, aucHeader=0x7fffbb80 "\354\245\301", 
> > iWordVersion=8) at properties.c:145
> > #4  0x00458464 in iInitDocumentOLE (pFile=, 
> > pFile@entry=0x68f2e0, lFilesize=, lFilesize@entry=28672) at 
> > wordole.c:792
> > #5  0x004552fb in iInitDocument (pFile=, 
> > pFile@entry=0x68f2e0, lFilesize=, lFilesize@entry=28672) at 
> > wordlib.c:325
> > #6  0x0044ce1f in bWordDecryptor (pFile=pFile@entry=0x68f2e0, 
> > lFilesize=lFilesize@entry=28672, pDiag=0x68fac0) at word2text.c:665
> > #7  0x00403ef3 in bProcessFile (szFilename=) at 
> > main_u.c:214
> > #8  main (argc=2, argv=0x7fffe558) at main_u.c:310
> > 
> > Ref: https://bugzilla.redhat.com/show_bug.cgi?id=2064638
> 
> "Red Hat Bugzilla – Bug Access Denied"

I still can't access this bug report.

I assume that's where `vAnalyseSummaryInfo.poc.doc` can be found (you
didn't attach it to this bug report), so all I have to go on is the
backtrace which points to a line where there's no dereference.

There aren't any patches in Fedora that we don't have an equivalent of,
except for antiword-0.32-fix-flags.patch which isn't relevant to us:

https://src.fedoraproject.org/rpms/antiword/tree/rawhide

There doesn't seem to be a CVE for this (only ones from 2005 and 2014):

https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=antiword

So as it stands, I don't see I can do anything useful with your report.

> There's no active upstream for antiword so someone needs to come up with
> a patch.  If someone already has that'd be helpful (and better for the
> various Linux distros to all use the same fix than each come up with
> their own).

This is also very much still true.

Tagging appropriately.  I've lowered the severity since failing to
process a single example file is not "a bug which has a major effect on
the usability of a package, without rendering it completely unusable to
everyone".

As best I can make out this is a segfault while reading, so there
doesn't seem there's a security implication either.

Cheers,
Olly



Bug#1014617: libfcgi-perl: perl is segfaulting and I think it's CGI::Fast

2022-07-08 Thread Ian Jackson
Package: libfcgi-perl
Version: 0.79+ds-2
Severity: normal

I recently upgraded my system from jessie i386 to bullseye amd64.
Since I did this, a long-established web application has become flaky
(returning no output from requests).  Associated with its failures I
see log messages like this:

Jul  8 21:59:42 chiark kernel: [354982.615451] perl[7671]: segfault at 22 ip 
55b443da11b1 sp 7ffe01ca1e50 error 6 in perl[55b443d9d000+185000]

The same hardware has been running an amd64 kernel (albeit i386
userland) forever with no unexplained problems, so I trust the
hardware.  Other Perl programs on the system are fine.

I looked through the memory map of a relevant perl process (see below)
and I think it very likely that the problem is a bug in libfcgi or in
FCGI.so.  The failures are intermittent and I don't have a reliable
repro.

Due to the convoluted arrangements by which this webapp is invoked in
my environment, it is not entirely straightforward to get coredumps or
stack traces, etc.  I can try to provide better information if it is
likely to be useful.

But first I thought I would ask: is this at all a plausible theory ?
Is it worth my time upending everything so that I can get a stack
trace or attach a debugger ?

My alternative is to reorganise my invocation method entirely.  My
webapp is in Mason 1 (libhtml-mason-perl), so I think my options may
be limited.

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

Kernel: Linux 5.10.0-15-amd64 (SMP w/8 CPU threads)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)
LSM: AppArmor: enabled

Versions of packages libfcgi-perl depends on:
ii  libc6   2.31-13+deb11u3
ii  libfcgi0ldbl2.4.2-2
ii  perl5.32.1-4+deb11u2
ii  perl-base [perlapi-5.32.0]  5.32.1-4+deb11u2

libfcgi-perl recommends no packages.

libfcgi-perl suggests no packages.

-- no debconf information


55a3d95e8000-55a3d962f000 r--p  fe:09 106888 
/usr/bin/perl
55a3d962f000-55a3d97b4000 r-xp 00047000 fe:09 106888 
/usr/bin/perl
55a3d97b4000-55a3d9959000 r--p 001cc000 fe:09 106888 
/usr/bin/perl
55a3d995a000-55a3d9969000 r--p 00371000 fe:09 106888 
/usr/bin/perl
55a3d9969000-55a3d996c000 rw-p 0038 fe:09 106888 
/usr/bin/perl
55a3d996c000-55a3d9972000 rw-p  00:00 0 
55a3dafe6000-55a3dc656000 rw-p  00:00 0  [heap]
7fcfcd97e000-7fcfcde0a000 r--p  fe:09 213000 
/usr/lib/locale/locale-archive
7fcfcde0a000-7fcfcde1a000 r--p  fe:09 234768 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fcfcde1a000-7fcfcdf12000 r-xp 0001 fe:09 234768 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fcfcdf12000-7fcfcdf46000 r--p 00108000 fe:09 234768 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fcfcdf46000-7fcfcdf4a000 r--p 0013b000 fe:09 234768 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fcfcdf4a000-7fcfcdf4d000 rw-p 0013f000 fe:09 234768 
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0.8.6
7fcfcdf7-7fcfcdf75000 r--p  fe:09 306657 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBD/SQLite/SQLite.so
7fcfcdf75000-7fcfcdf8e000 r-xp 5000 fe:09 306657 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBD/SQLite/SQLite.so
7fcfcdf8e000-7fcfcdf99000 r--p 0001e000 fe:09 306657 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBD/SQLite/SQLite.so
7fcfcdf99000-7fcfcdf9a000 r--p 00028000 fe:09 306657 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBD/SQLite/SQLite.so
7fcfcdf9a000-7fcfcdf9b000 rw-p 00029000 fe:09 306657 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBD/SQLite/SQLite.so
7fcfcdf9b000-7fcfcdfbc000 rw-p  00:00 0 
7fcfcdfbc000-7fcfcdfbf000 r--p  fe:09 241993 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBI/DBI.so
7fcfcdfbf000-7fcfcdfd7000 r-xp 3000 fe:09 241993 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBI/DBI.so
7fcfcdfd7000-7fcfcdfdd000 r--p 0001b000 fe:09 241993 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBI/DBI.so
7fcfcdfdd000-7fcfcdfde000 r--p 0002 fe:09 241993 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBI/DBI.so
7fcfcdfde000-7fcfcdfdf000 rw-p 00021000 fe:09 241993 
/usr/lib/x86_64-linux-gnu/perl5/5.32/auto/DBI/DBI.so
7fcfcdfdf000-7fcfcdfe1000 r--p  fe:09 231616 
/usr/lib/x86_64-linux-gnu/perl/5.32.1/auto/Data/Dumper/Dumper.so
7fcfcdfe1000-7fcfcdfe7000 r-xp 2000 fe:09 231616 
/usr/lib/x86

Bug#1014616: extrepo update fails with "uninitialized value" error

2022-07-08 Thread Adam Dinwoodie
Package: extrepo
Version: 0.10~bpo11+1
Severity: normal

Dear Maintainer,

The `update` command for extrepo appears to be broken.  I see the
following output from running it:

```
$ sudo extrepo update jellyfin
Use of uninitialized value in join or string at 
/usr/share/perl5/Debian/ExtRepo/Data.pm line 22.
Use of uninitialized value in join or string at 
/usr/share/perl5/Debian/ExtRepo/Data.pm line 22.
Use of uninitialized value in join or string at 
/usr/share/perl5/Debian/ExtRepo/Data.pm line 22.
Could not download index YAML file:
400 URL must be absolute at /usr/share/perl5/Debian/ExtRepo/Data.pm line 27.
...propagated at /usr/bin/extrepo line 187.
```

I got half-way to offering a patch -- it looks like the immediate issue
is simply that the `run` function in Update.pm doesn't pass all the
necessary variables when it calls the corresponding function in
Update.pm -- but looking a bit closer, it looks like the function is
more fundamentally broken than that.  As best I can tell from code
reading, the only thing the `update` command does is disable the warning
about nothing actually being updated!

-- System Information:
Debian Release: 11.3
  APT prefers stable-updates
  APT policy: (990, 'stable-updates'), (990, 'stable-security'), (990, 
'stable'), (850, 'testing'), (500, 'unstable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.15.32-v8+ (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_CRAP
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages extrepo depends on:
ii  gpgv  2.2.27-2+deb11u2
ii  libcryptx-perl0.069-1+b1
ii  libdpkg-perl  1.20.10
ii  libwww-perl   6.52-1
ii  libyaml-libyaml-perl  0.82+repack-1+b1
ii  perl  5.32.1-4+deb11u2

Versions of packages extrepo recommends:
ii  apt [apt-transport-https]  2.2.4

extrepo suggests no packages.

-- Configuration Files:
/etc/extrepo/config.yaml changed:
---
url: https://extrepo-team.pages.debian.net/extrepo-data
dist: debian
version: bullseye
enabled_policies:
- main
- contrib
- non-free


-- no debconf information



Bug#900821: linux-image-4.9.0-6-amd64: apache reads wrong data over cifs filesystems served by samba

2022-07-08 Thread Timo Lindfors

Hi,

just as a random exercise to learn debbisect I tried it against this bug. 
I hope this might be useful, or not :)


Early on I noticed that the issue can demonstrate itself in two different 
ways:


1) wget fails with "200 No headers, assuming HTTP/0.9". The original steps
   to reproduce included "2>/dev/null" which was hiding this. This is
   apparently bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930574

2) kernel reports a bug in dmesg and sets /proc/sys/kernel/tainted to a
   non-zero value. This is the case I started to investigate.

Using

$ debbisect --qemu=defaults --depends=linux-image-amd64 --verbose  
--cache=./cache 2019-06-01 2022-06-05 ./script2.sh

I see that the issue occurs with 4.19.0-5-amd64 but does not occur anymore 
with 5.2.0-2-amd64.


The helper scripts I used are below. Note that I had to negate the "good" 
status to find the version that fixes the bug instead of finding the 
version that introduces it.


 script2.sh
#!/bin/sh

echo "script2.sh starting as $(whoami)"

ssh_config="$1"

scp -F "$ssh_config" script3.sh qemu:

ssh -F "$ssh_config" qemu ./script3.sh


 script3.sh
#!/bin/sh
set -exu

echo "script3.sh starting as $(whoami)"

env APT_LISTCHANGES_FRONTEND=none DEBIAN_FRONTEND=noninteractive apt-get -o 
Dpkg::Options::="--force-confold" -o Dpkg::Options::="--force-confdef" install 
-y -q samba apache2 cifs-utils curl

tee -a /etc/samba/smb.conf 

Bug#916189: xapian-bindings: please package Lua bindings

2022-07-08 Thread Olly Betts
Control: tags +help

On Tue, Dec 11, 2018 at 04:03:41AM +, Eric Wong wrote:
> I noticed Lua bindings are provided with Xapian upstream;
> but there's no Debian package for it.
> 
> I'm not a Lua programmer, yet, but the availability of Xapian
> bindings would influence my choice to try it.

I've not packaged any Lua modules for Debian before, and never seem to
find the time to try to sort this out.  I've tagged the bug "help" in
the hope that some Debian Lua packaging expert might step in here...

Cheers,
Olly



Bug#1014615: networkd-dispatcher: don't start networkd-dispatcher if it has nothing to do

2022-07-08 Thread Steve Langasek
Package: networkd-dispatcher
Version: 2.1-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Julian,

Since Ubuntu installs networkd-dispatcher by default as part of a complete
replacement for the ifupdown user experience (i.e. support for post-up hook
scripts), the fact that networkd-dispatcher is running by default even when
it has nothing to do has a significant impact on the memory footprint of the
smallest Ubuntu deployments (VMs and containers): it is the fourth largest
process in 'top' output in a pristine Ubuntu container sorted by memory
usage.

I've therefore applied the attached patch to networkd-dispatcher in Ubuntu,
so that the systemd unit for networkd-dispatcher will only start if
networkd-dispatcher has been configured on the system.

Although Debian doesn't use networkd-dispatcher by default, I think it's
good practice to not start systemd units when they are not useful.

The only notable difference vs existing behavior is that this patch does not
watch the contents of the config directories; so on first configuration, the
user will have to either reboot the system, or manually start the
networkd-dispatcher service, in order for the changes to take effect.

If you think this difference is important, I am happy to prepare an
additional .path unit which would watch these directories for additions and
start the service dynamically.

Thanks for consdering,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru networkd-dispatcher-2.1/debian/patches/no-start-by-default.patch 
networkd-dispatcher-2.1/debian/patches/no-start-by-default.patch
--- networkd-dispatcher-2.1/debian/patches/no-start-by-default.patch
1969-12-31 16:00:00.0 -0800
+++ networkd-dispatcher-2.1/debian/patches/no-start-by-default.patch
2022-07-08 13:33:54.0 -0700
@@ -0,0 +1,19 @@
+Description: Don't start the daemon if there's nothing to do
+ If there are no configuration files for networkd-dispatcher, then do not
+ start the (relatively heavyweight) process.
+Author: Steve Langasek 
+Last-Update: 2022-07-08
+Forwarded: no
+
+Index: networkd-dispatcher-2.1/networkd-dispatcher.service
+===
+--- networkd-dispatcher-2.1.orig/networkd-dispatcher.service
 networkd-dispatcher-2.1/networkd-dispatcher.service
+@@ -1,5 +1,7 @@
+ [Unit]
+ Description=Dispatcher daemon for systemd-networkd
++ConditionPathExistsGlob=|/etc/networkd-dispatcher/*/*
++ConditionPathExistsGlob=|/usr/lib/networkd-dispatcher/*/*
+ 
+ [Service]
+ Type=notify
diff -Nru networkd-dispatcher-2.1/debian/patches/series 
networkd-dispatcher-2.1/debian/patches/series
--- networkd-dispatcher-2.1/debian/patches/series   2022-05-04 
06:29:24.0 -0700
+++ networkd-dispatcher-2.1/debian/patches/series   2022-07-08 
13:32:37.0 -0700
@@ -6,3 +6,4 @@
 CVE-2022-29800-1.patch
 CVE-2022-29800-2.patch
 CVE-2022-29799-regression.patch
+no-start-by-default.patch


Bug#1013895: RTL8188EUS 802.11n Wireless Network Adapter not working on 5.18

2022-07-08 Thread Vincent Blut
Control: tags -1 moreinfo

Hi,

Le 2022-06-26 23:53, Santiago Ruano Rincón a écrit :
> Package: src:linux
> Version: 5.18.5-1
> Severity: important
> 
> Dear linux maintainers,
> 
> Not sure if this should be filed against firmware-realtek, and sorry if
> that is the case. I have a WiFi USB dongle that doesn't work on linux
> 5.18, but it does work on 5.15.
> 
> You can see this error in the logs below during boot, or when I replug
> the dongle:
> 
>  r8188eu 1-1.2:1.0: _rtw_init_xmit_priv failed
> 
> Maybe this is relevant:
> https://lkml.org/lkml/2022/5/21/527

This patch has been applied upstream to Linux 5.19-rc3 and backported to Linux
5.18.6. While the latter is not yet available in Debian, we have Linux 5.19-rc4
in experimental. Could you please check if it fixes this issue?
 
> Thanks for your work,
> 
>  -- Santiago

Cheers,
Vincent


signature.asc
Description: PGP signature


Bug#1014394: Stable Proposed Updates Kernel

2022-07-08 Thread Diederik de Haas
On Tuesday, 5 July 2022 21:37:40 CEST Richard Laysell wrote:
> these tab crashes also happened with 5.10.0-15-amd64 -
> 5.10.120.1 but not with 5.10.0-14-amd64 - 5.10.113-1.
> 
> Happy to do more testing and send more logs if it helps.

https://wiki.debian.org/DebianKernel/GitBisect describe a/the way to narrow 
down the specific commit that caused the regression.
Knowing that *really* helps to pinpoint the issue and would also help to 
determine which upstream (sub)project to contact about this issue.

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


Bug#1014613: debcargo: omit features declaratively

2022-07-08 Thread Daniel Kahn Gillmor
Package: debcargo
Version: 2.5.0-3+b3
Severity: wishlist

I'd like to be able to specify declaratively in debcargo.toml that a 
specific feature of the crate i'm packaging should be ignored.

i currently do this on a few different crates, because there are
features that either aren't relevant for debian, or because those
features require much more packaging work for dependencies and i'd
rather get the crate -- without that feature -- into debian before the
feature's dependencies are ready.

So i'm proposing new syntax in debcargo.toml:

   ignore_features = foo,bar

This would indicate that those features would not be packaged for debian
at all.

On IRC, f_g notes:

  >> question is whether to only remove them from d/control et al, or
  >> also automatically modify Cargo.toml to remove them there and make
  >> them practically unusable

I think a first pass at this would be simply to remove them from
d/control, and see what kinds of breakage we run into.

   --dkg


signature.asc
Description: PGP signature


Bug#1014524: mutt: Mutt depends on moreutils package, but, it is not listed on dependencies, nor suggestions

2022-07-08 Thread Kevin J. McCarthy

On Thu, 7 Jul 2022 08:17:26 -0300 Marcelo Laia  wrote:

Mutt depends on moreutils package, but, it is not listed on dependencies, nor
suggestions.

I see that pee is necessary to open html messages.

With out moreutils package, when I try to open a html messages, it shows:

sh: 1: pee not found


This is most likely a system or user configuration issue.  Mutt uses 
mailcap to decide how to deal with attachments.  See the section in the 
manual  for more details about 
how that works.


AFAIK, nothing internal to Mutt (or its default shipped configuration) 
is trying to use "pee".  I would check the system mailcap /etc/mailcap 
for the first text/html entry, and also your ~/.mailcap file (if 
present) to see if that gives any hints about what is going on in your 
case.


-Kevin



Bug#1012196: buglist

2022-07-08 Thread André Flechs

Got it so far.

But there is one lintian error I have no idea about.

There is an error about missing source of d3.js. For this I added (I 
hope) the source file to missing sources.
But the error does not dissappear. I think it's because of one very long 
line 7796.


How can I handle this? Just reformat?



Bug#502315: No equivalent to XMoveWindow

2022-07-08 Thread Emmanuel Arias
Hi,

Please take a look to https://github.com/python-xlib/python-xlib/issues/197

You can use configure for that
https://github.com/python-xlib/python-xlib/blob/master/Xlib/xobject/drawable.py#L407

Cheers,
Emmanuel


Bug#1014611: docbook-xml and docbook-xsl failed to update their catalogs in /etc/xml when interrupted

2022-07-08 Thread Daniel Kahn Gillmor
Package: docbook-xml
Version: 4.5-12
Control: affects -1 src:libreswan xmlto
Control: clone -1 -2
Control: reassign docbook-xsl 1.79.2+dfsg-2

I have a debian/unstable system on amd64.

I installed a pile of software on it, including docbook-xml and
docbook-xsl.  Part of the software installation failed due to
circumstances outside the machine (the VM was terminated on the host),
but after rebooting i picked up with "dpkg --reconfigure -a" and "apt
install -f".  All seemed fine.

However, when i then tried to build documentation (from the libreswan
package, fwiw, which uses xmlto to generate manpages), i got failures
due to the following files being empty:

/etc/xml/catalog
/etc/xml/docbook-xml.xml
/etc/xml/docbook-xsl.xml

The errors resulted in messages like:

> I/O error : Attempt to load network entity 
> http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd

When i did:

dpkg-reconfigure docbook-xml docbook-xsl

then tried to rebuild, there was no problem.

So something about the commands that rebuild these files in /etc/xml is
dangerous, because it can be interrupted, and leave the system in a
state that appears to be correct, but is in fact non-functional.

perhaps the rebuild that's happening needs to happen somewhere else, and
then get moved into place correctly, rather than leaving an empty file?

Sorry to not have a more specific way to replicate the issue.

 --dkg


signature.asc
Description: PGP signature


Bug#1014610: ITP: ott -- Ott tool

2022-07-08 Thread Julien Puydt
Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: ott
  Version : 0.32
  Upstream Author : Peter Sewell, Francesco Zappa Nardelli, Scott Owens et al
* URL : https://github.com/ott-lang/ott
* License : BSD-3-clause
  Programming Lang: OCaml
  Description : Ott tool
 Ott is a tool to write definitions of programming
 languages and calculi. From the definition of a
 language syntex and semanticsin a concise and readable
 notation close to informal mathematics, it can
 provide LaTeX, Coq, HOL, Isabelle/HOL, Lem or OCaml
 versions of the definition.
 .
 Coq is a proof assistant for higher-order logic.

I plan to maintain it within the Debian OCaml Maintainers team, along with the
other Coq-related packages.

Cheers,

J.Puydt



Bug#987729: inetutils-telnet: provide upgrade path for orphan netkit-telnet

2022-07-08 Thread Guillem Jover
Hi!

On Wed, 2021-04-28 at 19:11:11 +0200, Simon Josefsson wrote:
> Package: inetutils-telnet
> Severity: wishlist

> As discussed in https://bugs.debian.org/982253 netkit-telnet is not
> (actively) maintained upstream or in Debian.  Inetutils may not be the
> state of the art as a well-maintained project, but at least there are
> upstream releases and good packaging in Debian.
> 
> I believe 'apt-get install telnet' should install inetutils-telnet
> rather than netkit-telnet going forward.  Once bullseye is released it
> is a good time to make the switch.  I'm opening this bug to find out
> what needs to be done in order to make this happen, if there is
> agreement that this is a good idea.

Discussed this with Simon off-bts, and it seems I had dropped the ball
here because I thought this was blocked on something else or similar.

> 1) What needs to be done in d/control for the inetutils-telnet package?
> Should it 'Provides: telnet' and 'Replaces: telnet'?  Anything more?

I think the proper way to do this, would be for src:inetutils to grow
(and take over) a couple of telnet (and ideally telnetd) transitional
binary packages, that depend on inetutilds counterparts. The
inetutils-telnet (and also inetutils-telnetd) to then also gain telnet
(and telnetd Provides).

Because telnet is managed through alternatives, once netkit-telnet
becomes a transitional package, then there's not much to do, the
upgrade will take care of cleaning things up.

For telnetd this is a bit more tricky, as the programs are named
differently so inetd or other init system hooks might be lost during
a transition and this needs to be accounted for. We could always start
with telnet, and then do telnetd, but I'd rather do both TBH.

There are packages that depend only on telnet or telnetd (instead of
in addition to the the virtual telnet-client and telnet-server). Those
should get bug reports to switch to the «telnet | telnet-client» and
«telnetd | telnet-server» forms, so that alternative implementations
can be used. But otherwise we can simply use telnet and telnetd as
a form of default- virtual package, as used in other parts
of the archive.

We'd need to send a mail to debian-devel, announcing the transition,
to check whether there's any objection. I can prepare something during
the weekend.

> 2) Is it required for 1) that the netkit-telnet package is removed from
> Debian?  Maybe the package could live on and ship 'netkit-telnet'
> instead of the 'telnet' package?  Perhaps that package could continue to
> live on in unstable, but never ship with a future release in favor of
> inetutils-telnet.

That's something I was wondering, after you adopted netkit-telnet. If
you'd like to keep the netkit packages, then renaming the binary packages
would be the way to go, yes. If so, then we have two options, either
netkit keeps the telnet/telnetd packages and turns them into
transitional dummy packages pointing at the inetutils ones, and then
ships the real things in netkit- namespaced ones, or src:inetutils
takes them over, which does not require going through NEW, but then
the src:netkit-telnet might get garbage collected. But given that it
would need to go through NEW anyway, that might be the quickest way to
go about it.

> 3) The implementations needs to be analyzed for compatibility.  The
> --usage outputs are like this:

> A quick comparison indicates that inetutils-telnet is missing the '-b
> addr' command.  I'll try to verify that the parameter actually does the
> intended thing in netkit-telnet, and then see if I can implement that
> upstream in inetutils.

Which you implemented subsequently! Thanks.

> Further feature comparisons would be welcome though.

Sure.

> Similar thoughts applies to inetutils-telnetd vs netkit-telnetd too, but
> I wanted to start with something simple so I chose inetutils-telnet.
> Since telnet and telnetd is shipped from the same netkit-telnet source
> package, it may that if 2) is involved above, something needs to happen
> to inetutils-telnetd too, and then so be it.

I'm fine with doing this step-wise or wholesale. If doing telnetd at
the same time might look like blocking telnet, then we can start with
just that one, but that would require going through NEW twice, which
does not look ideal.

Given the above open questions, I think I'm just going to update to
the latest upstream now, and then we can check how to proceed in the
coming days.

Thanks,
Guillem



Bug#1014609: pulseaudio: No soundcard after reboot

2022-07-08 Thread Mark Brandis
Package: pulseaudio
Version: 15.0+dfsg1-4+b1
Severity: important
X-Debbugs-Cc: mark.bran...@posteo.de

Since an upgrade on the 2022-07-04 pulseaudio on XFCE no longer shows any
soundcards after boot. I found out, that I can reinstate the soundcards with

rm -rf ~/.config/pulse /tmp/pulse-* && systemctl --user restart
pulseaudio.service

This is happening on three different computers all running Debian
Testing/Unstable after upgrading with every reboot.


-- Package-specific info:
File '/etc/default/pulseaudio' does not exist


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.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 pulseaudio depends on:
ii  adduser 3.121
ii  init-system-helpers 1.64
ii  libasound2  1.2.7.1-1
ii  libasound2-plugins  1.2.7.1-1
ii  libc6   2.33-7
ii  libcap2 1:2.44-1
ii  libdbus-1-3 1.14.0-1
ii  libfftw3-single33.3.8-2
ii  libgcc-s1   12.1.0-5
ii  libglib2.0-02.72.3-1
ii  libgstreamer-plugins-base1.0-0  1.20.3-2
ii  libgstreamer1.0-0   1.20.3-1
ii  libice6 2:1.0.10-1
ii  libltdl72.4.7-4
ii  liborc-0.4-01:0.4.32-2
ii  libpulse0   15.0+dfsg1-4+b1
ii  libsm6  2:1.2.3-1
ii  libsndfile1 1.0.31-2
ii  libsoxr00.1.3-4
ii  libspeexdsp11.2.0-1
ii  libstdc++6  12.1.0-5
ii  libsystemd0 251.2-8
ii  libtdb1 1.4.6-3
ii  libudev1251.2-8
ii  libwebrtc-audio-processing1 0.3-1+b1
ii  libx11-62:1.7.5-1
ii  libx11-xcb1 2:1.7.5-1
ii  libxcb1 1.14-3
ii  libxtst62:1.2.3-1.1
ii  lsb-base11.2
ii  pulseaudio-utils15.0+dfsg1-4+b1

Versions of packages pulseaudio recommends:
ii  dbus-user-session1.14.0-1
ii  libpam-systemd [logind]  251.2-8
ii  rtkit0.13-4

Versions of packages pulseaudio suggests:
ii  paprefs  1.2-1
ii  pavucontrol  5.0-2
pn  pavumeter
ii  udev 251.2-8

-- no debconf information
# This file is part of PulseAudio.
#
# PulseAudio 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 of the License, or
# (at your option) any later version.
#
# PulseAudio 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
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for PulseAudio clients. See pulse-client.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; default-sink =
; default-source =
; default-server =
; default-dbus-server =

; autospawn = yes
; daemon-binary = /usr/bin/pulseaudio
; extra-arguments = --log-target=syslog

; cookie-file =

; enable-shm = yes
; shm-size-bytes = 0 # setting this 0 will use the system-default, usually 64 
MiB

; auto-connect-localhost = no
; auto-connect-display = no
# This file is part of PulseAudio.
#
# PulseAudio 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 of the License, or
# (at your option) any later version.
#
# PulseAudio 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
# General Public License for more details.
#
# You should have received a copy of the GNU Lesser General Public License
# along with PulseAudio; if not, see .

## Configuration file for the PulseAudio daemon. See pulse-daemon.conf(5) for
## more information. Default values are commented out.  Use either ; or # for
## commenting.

; daemonize = no
; fail = yes
; all

Bug#678615: "users" group is empty

2022-07-08 Thread Marc Haber
On Tue, Jul 05, 2022 at 09:37:28AM -0400, Matt Barry wrote:
> On Tue, 2022-07-05 at 15:34 +0200, Marc Haber wrote:
> > On Tue, Jul 05, 2022 at 09:07:11AM -0400, Matt Barry wrote:
> > > On Tue, 2022-07-05 at 12:46 +0200, Marc Haber wrote:
> > > > (1) Augment the USERS_GID with a USERS_GROUP setting, throwing a
> > > > warning
> > > >     if both are set.
> > > > (2) Set the primary group of a new non-system user created with
> > > >     USERGROUPS=no to the USERS_GID or the GID of the USERS_GROUP
> > > > (3) Set USERS_GROUP or the Group that has USERS_GID as
> > > > supplementary
> > > >     group of newly created non-system users with USERGROUPS=yes
> > > 
> > > if USERS_GID and USERS_GROUP are empty, and USERGROUPS is no... the
> > > user gets the "users" group as before?
> > 
> > If USERGROUPS is no, then currently the new user gets group 100,
> > which
> > is "users" as per base-passwd. USERS_GID is documented as having 100
> > as
> > default.
> 
> Yup, sounds good.

I have created a Draft MR
https://salsa.debian.org/debian/adduser/-/merge_requests/39 to implement
this. Currently, it's just documentation changes.

Please review and comment.

Next steps: Code tests, code code.

Greetings
Marc



Bug#1014608: pipewire-{alsa,jack} are not Multi-Arch: same

2022-07-08 Thread Jesse Pullinen
Source: pipewire
Version: 0.3.54-2
Severity: important
X-Debbugs-Cc: jesse12p+deb...@gmail.com

pipewire-audio-client-libraries was Multi-Arch: same, as it contained shared
libraries. When split to pipewire-{alsa,jack} they were set Multi-Arch:
foreign, apparently since some part of the control file section was copied from
pipewire-pulse, which contains a binary. This prevents for example installing
the amd64 and i386 packages concurrently, which was possible with pipewire-
audio-client-libraries. This breaks using ALSA and Jack applications with
differing architectures concurrently.

The pipewire-v4l2 package could maybe also be Multi-Arch: same.


-- System Information:
Debian Release: bookworm/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (980, 'testing'), (500, 'unstable-debug'), 
(500, 'buildd-unstable'), (120, 'experimental'), (1, 'experimental-debug'), (1, 
'buildd-experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386, armhf, armel

Kernel: Linux 5.18.0-2-amd64 (SMP w/16 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=fi:en_GB:en_US
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled



Bug#1014582: Acknowledgement (Build failure with googletest 1.12)

2022-07-08 Thread Mattias Ellert
Here is a possible patch.

With this patch it builds both on testing (googletest 1.11.0) and
unstable (googletest 1.12.1).

The patch need some tweaks to be upstreamable since it used the Debian
path to the googletest source.

Mattias

diff -ur seqan3-3.2.0+ds.orig/test/unit/test/CMakeLists.txt seqan3-3.2.0+ds/test/unit/test/CMakeLists.txt
--- seqan3-3.2.0+ds.orig/test/unit/test/CMakeLists.txt	2022-06-20 13:58:01.0 +
+++ seqan3-3.2.0+ds/test/unit/test/CMakeLists.txt	2022-07-08 12:24:37.678861725 +
@@ -1,3 +1,17 @@
+include (CheckCXXSourceCompiles)
+
+set (CMAKE_REQUIRED_INCLUDES /usr/src/googletest/googletest/include)
+
+check_cxx_source_compiles ("
+#include 
+decltype(testing::internal::Nullopt()) x();
+int main() {}
+" GTEST_HAS_NULLOPT)
+
+if (GTEST_HAS_NULLOPT)
+add_definitions (-DGTEST_HAS_NULLOPT)
+endif()
+
 seqan3_test (expect_range_eq_test.cpp)
 seqan3_test (expect_same_type_test.cpp)
 seqan3_test (file_access_test.cpp)
diff -ur seqan3-3.2.0+ds.orig/test/unit/test/pretty_printing_test.cpp seqan3-3.2.0+ds/test/unit/test/pretty_printing_test.cpp
--- seqan3-3.2.0+ds.orig/test/unit/test/pretty_printing_test.cpp	2022-06-20 13:58:01.0 +
+++ seqan3-3.2.0+ds/test/unit/test/pretty_printing_test.cpp	2022-07-08 12:24:37.678861725 +
@@ -67,7 +67,11 @@
 EXPECT_EQ(gtest_str(std::vector>{{0, 1}, {2, 3}, {1, 2}, {0}}), "[[0,1],[2,3],[1,2],[0]]"s);
 EXPECT_EQ(debug_str(std::vector>{{0, 1}, {2, 3}, {1, 2}, {0}}), "[[0,1],[2,3],[1,2],[0]]"s);
 
+#ifdef GTEST_HAS_NULLOPT
+EXPECT_EQ(gtest_str(std::nullopt), "(nullopt)"s);
+#else
 EXPECT_EQ(gtest_str(std::nullopt), ""s);
+#endif
 EXPECT_EQ(debug_str(std::nullopt), ""s);
 }
 


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


Bug#1014503: bind9-libs: please provide libraries that enable reverse dependencies to use them

2022-07-08 Thread Ondřej Surý
Ok, that should work if it doesn’t bother you much.

Also generally speaking, the upstream has 3rd Wednesday in a month release 
schedule. Obviously, there are exceptions, but we try to adhere to the schedule 
and it works ok for everyone. I tried to bring transparency and predictability 
to the BIND 9 development. Others will need to judge me if I succeeded.

Ondřej
--
Ondřej Surý  (He/Him)

> On 7. 7. 2022, at 10:51, Paul Gevers  wrote:
> 
> Hi,
> 
>> On 07-07-2022 10:14, Ondřej Surý wrote:
>> As a immediate remedy, I can do the babysitting with each bind9 release.
> 
> If you can *actively* ping the Release Team to do the binNMU'ing, I think 
> that's fine for now. It's just that we don't have tooling to detect this 
> automatically. (That could miss binNMU's for bind9 to go undetected for a 
> while, but maybe as the maintainer you are most of the time aware of those 
> too)
> 
> Paul


OpenPGP_signature
Description: Binary data


Bug#1014607: [vim]

2022-07-08 Thread Falo Castro
Package: vim
Version:
Severity: 
Tags: 
X-Debbugs-CC: 
Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

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

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


Bug#1013186: python3-geopandas: geopandas is missing PROJ data directory

2022-07-08 Thread Sebastiaan Couwenberg

On 7/8/22 18:41, Akkana Peck wrote:

So anyone who wants to use the Debian geopandas package but needs
a venv for packages that aren't in Debian will see this warning.


With a venv you're already diverging from Debian packages, why not use 
conda or other Python solutions for manage all dependencies in your venv?



Could pyproj on Debian possibly try /usr/share/proj/ if it doesn't
find a proj dir in the virtualenv?


No, that's out of scope for the Debian package.

If pyproj needs changes to better support virtualenv, that is something 
you need to take up with pyproj upstream.


Kind Regards,

Bas

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



Bug#1014606: cssc: the sccsdiff command leaves empty get.xxxxx files hanging around

2022-07-08 Thread John Hughes
Package: cssc
Version: 1.4.0-6jh2
Severity: normal

Dear Maintainer,

   * What led up to the situation?
did an "sccs sccsdiff command"

   * What was the outcome of this action?
an empty get.x file was created in the current directory

   * What outcome did you expect instead?
no useless empty files

Problem is in the sccsdiff shell script, it contains the useless
line:

getprefix=$(mktemp get.XXX).

which makes the temporary file.  getprefix is mentioned nowhere else
in the script.  Removing this line gets rid of the problem.

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

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

Versions of packages cssc depends on:
ii  libc6   2.28-10+deb10u1
ii  libgcc1 1:8.3.0-6
ii  libstdc++6  8.3.0-6

cssc recommends no packages.

Versions of packages cssc suggests:
pn  groff  

-- no debconf information



Bug#1014605: node-functional.js: FTBFS, missing build-dependencies

2022-07-08 Thread Steve Langasek
Source: node-functional.js
Version: 0.8.0-1
Severity: serious
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic

Hi Stephan,

The node-functional.js binary in unstable was not built in the archive, and
attempting to rebuild this package from source fails due to missing build
dependencies:

[...]
   dh_auto_build --buildsystem=nodejs
No build command found, searching known files
cd ./. && gulp
Can't exec "gulp": No such file or directory at 
/usr/share/perl5/Debian/Debhelper/Dh_Lib.pm line 524.
dh_auto_build: warning: ### Command "gulp" failed in .
[...]

However, if I add the missing build-dependency on gulp, the package build
still fails with:

[...]
[16:10:38] Using globally installed gulp
Error: Cannot find module 'gulp-jshint'
Require stack:
- /tmp/node-functional.js-0.8.0/gulpfile.js
- /usr/share/nodejs/gulp-cli/lib/shared/require-or-import.js
- /usr/share/nodejs/gulp-cli/lib/versioned/^4.0.0/index.js
- /usr/share/nodejs/gulp-cli/index.js
- /usr/share/nodejs/gulp/bin/gulp.js
at Function.Module._resolveFilename 
(node:internal/modules/cjs/loader:933:15)
at Function.Module._load (node:internal/modules/cjs/loader:778:27)
at Module.require (node:internal/modules/cjs/loader:1005:19)
at require (node:internal/modules/cjs/helpers:102:18)
at Object. (/tmp/node-functional.js-0.8.0/gulpfile.js:2:14)
at Module._compile (node:internal/modules/cjs/loader:1105:14)
at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
at Module.load (node:internal/modules/cjs/loader:981:32)
at Function.Module._load (node:internal/modules/cjs/loader:822:12)
at Module.require (node:internal/modules/cjs/loader:1005:19) {
  code: 'MODULE_NOT_FOUND',
  requireStack: [
'/tmp/node-functional.js-0.8.0/gulpfile.js',
'/usr/share/nodejs/gulp-cli/lib/shared/require-or-import.js',
'/usr/share/nodejs/gulp-cli/lib/versioned/^4.0.0/index.js',
'/usr/share/nodejs/gulp-cli/index.js',
'/usr/share/nodejs/gulp/bin/gulp.js'
  ]
}
dh_auto_build: warning: ### Command "gulp" failed in .
[...]

I can't find this gulp-jshint anywhere in the archive, so it looks like
there's some work to be done here.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature


Bug#1009195: blueprint-compiler: The homepage address leads to 404

2022-07-08 Thread James Westman
The upstream homepage is 
.




Bug#1014604: libeconf: FTBFS with newer toolchain due to false-positive compiler error

2022-07-08 Thread Steve Langasek
Package: libeconf
Version: 0.4.4+dfsg1-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu kinetic ubuntu-patch

Hi Andreas,

libeconf is failing to build in Ubuntu with a format string error from gcc:

[...]
cc -Ieconftool.p -I. -I.. -I../include -fdiagnostics-color=always 
-D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -Wpedantic -O0 
-D_GNU_SOURCE=1 -DXTSTRINGDEFINES -Werror -fstack-protector-strong 
-funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection 
-Werror=return-type -flto=8 -Wbad-function-cast -Wcast-align -Wcast-qual 
-Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wshadow 
-Wstrict-prototypes -Wundef -g -O2 -ffile-prefix-map=/<>=. 
-flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -fPIE -MD -MQ econftool.p/util_econftool.c.o -MF 
econftool.p/util_econftool.c.o.d -o econftool.p/util_econftool.c.o -c 
../util/econftool.c
../util/econftool.c: In function ‘main’:
../util/econftool.c:591:84: error: ‘__snprintf_chk’ output may be truncated 
before the last format character [-Werror=format-truncation=]
  591 | snprintf(conf_basename, strlen(argv[optind + 1]) - 
strlen(conf_suffix) + 1, "%s", argv[optind + 1]);
  | 
   ^
[...]

  (https://launchpad.net/ubuntu/+source/libeconf/0.4.4+dfsg1-1/+build/23574046)

I've looked over the code and I think there's no real problem with what the
code's doing, it's just defying gcc's static analysis for format-truncation.

To get the package building in Ubuntu, rather than refactoring the code to
make gcc happy, I've suppressed the warning as in the attached patch.

This build failure doesn't currently affect Debian, so I've marked this bug
report severity 'minor'; but I expect at some point this will start to
affect Debian as well, possibly when glibc is updated to 2.34.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
diff -Nru libeconf-0.4.4+dfsg1/debian/rules libeconf-0.4.4+dfsg1/debian/rules
--- libeconf-0.4.4+dfsg1/debian/rules   2022-02-05 14:15:28.0 -0800
+++ libeconf-0.4.4+dfsg1/debian/rules   2022-07-08 08:41:11.0 -0700
@@ -13,6 +13,7 @@
 # package maintainers to append LDFLAGS
 #export DEB_LDFLAGS_MAINT_APPEND = -Wl,--as-needed
 
+export DEB_CFLAGS_MAINT_APPEND = -Wno-error=format-truncation
 
 %:
dh $@ --buildsystem=meson


Bug#1011688: Thank you for the synaptic NMU

2022-07-08 Thread Boyuan Yang
Hi,

在 2022-07-08星期五的 13:01 +0200,Michael Vogt写道:
> Hey,
> 
> just wanted to send a quick THANK YOU note for the NMU diff. I uploaded a
> new version of synaptic with it and various other collected fixes/changes.
> But I realized I did not reply with a thank you :)

My pleasure. Having a quick yet effective fix is beneficial to all users.

Cheers,
Boyuan


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


Bug#362012: tdsodbc: improved debconf handling for driver registration

2022-07-08 Thread Joseph Nahmias
Package: tdsodbc
Version: 1.3.6-1.1
Followup-For: Bug #362012
X-Debbugs-Cc: j...@nahmias.net

Hello,

I recently got bit by this when setting up a new machine to connect to MSSQL.

On Tue, 11 Apr 2006 14:02:02 -0700 Steve Langasek  wrote:
> I agree that the ODBC driver handling needs to be reworked.  I would like
> the drivers to be managed by default, but there are currently some bugs in
> the handling and I also have to make sure I'm handling this in a
> policy-compliant manner.

It's been a while now, any updates?

Can you list your specific concerns?
I'd be happy to work on a patch for this if I knew what would be acceptable.

Thanks,
--Joe



Bug#1014603: iusql fails if password contains semicolon

2022-07-08 Thread Joe Nahmias
Package: unixodbc
Version: 2.3.11-2
Severity: normal
File: /usr/bin/iusql
X-Debbugs-Cc: j...@nahmias.net

Hello,

I was trying to connect to an MSSQL database using unixodbc/iusql with
the FreeTDS driver. The password for the login was randomly generated
and contained a semicolon ";" in it. This worked fine when using the
FreeTDS tools tsql and fisql. However, the iusql tool from unixodbc
failed as follows:

$ iusql myDSN myLogin 'Y&MI%4VtL?C@OuUwmWkksL;+!#V$JSo6' -v
[FreeTDS][SQL Server]Unable to connect to data source
[FreeTDS][SQL Server]Login failed for user 'myLogin'.
[ISQL]ERROR: Could not SQLDriverConnect

Changing the password in the database worked around the issue, but I
guess iusql needs to do better escaping of special characters in the
password.

--Joe


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

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

Versions of packages unixodbc depends on:
ii  libc6 2.33-7
ii  libodbc2  2.3.11-2
ii  libodbcinst2  2.3.11-2
ii  libreadline8  8.1.2-1.2

unixodbc recommends no packages.

unixodbc suggests no packages.

-- no debconf information



Bug#166028: Copy of: 使用GP入款立享5%充值优惠!!166...@bugs.debian.org

2022-07-08 Thread Niduki Consulting
Copy of:

This is an enquiry e-mail via http://niduki-consulting.com/ from:
蒋公王 <166...@bugs.debian.org>

【澳门金沙】开户即送38元: www.014836.com/?  老板太任性了,存8元还送18元,100起存多少送多少!



Bug#1014523: strawberry: Fails to index a few songs

2022-07-08 Thread Peter B

Hi Alberto,

One more thought,
assuming there is nothing useful so far in the database

deleting the sql file
~/.local/share/strawberry/strawberry/strawberry.db

and allowing strawberry to recreate it, might help


Cheers,
Peter



Bug#1014602: ITP: coq-menhirlib -- support library for verified Menhir parsers

2022-07-08 Thread Julien Puydt
Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: coq-menhirlib
  Version : 20220210
  Upstream Author : Jacques-Henri Jourdan
* URL : https://coquelicot.inria.fr/fpottier/menhir
* License : LGPL-3+
  Programming Lang: Coq
  Description : support library for verified Menhir parsers
 This package provides a support library for verified
 Coq parsers produced by Menhir.
 .
 Menhir is a LR(1) parser generator for the OCaml programming
 language and Coq is a proof assistant for higher-order logic.

I plan to maintain this package within the Debian OCaml Maintainers team along
with the other Coq-related packages.

Cheers,

J.Puydt



Bug#1014601: RFS: python-pook/1.0.2-1 [ITP] -- HTTP traffic mocking and testing made easy

2022-07-08 Thread Guilherme de Paula Xavier Segundo
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "python-pook":

 * Package name: python-pook
   Version : 1.0.2-1
   Upstream Author : https://github.com/h2non/pook/issues
 * URL : https://github.com/h2non/pook
 * License : Expat
 * Vcs : https://salsa.debian.org/python-team/packages/python-pook
   Section : python

The source builds the following binary packages:

  python3-pook - HTTP traffic mocking and testing made easy (Python 3)
  python-pook-doc - HTTP traffic mocking and testing made easy (common 
documentation)

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

  https://mentors.debian.net/package/python-pook/

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

  dget -x 
https://mentors.debian.net/debian/pool/main/p/python-pook/python-pook_1.0.2-1.dsc

Changes for the initial release:

 python-pook (1.0.2-1) experimental; urgency=medium
 .
   * Initial release. (Closes: #1014562)

* Please, I request to create the repository in the team repository. I'm not a 
member yet.

Regards,
--
Guilherme de Paula Xavier Segundo


signature.asc
Description: PGP signature


Bug#1014600: gdk-pixbuf: CVE-2021-44648

2022-07-08 Thread Moritz Mühlenhoff
Source: gdk-pixbuf
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for gdk-pixbuf.

CVE-2021-44648[0]:
| GNOME gdk-pixbuf 2.42.6 is vulnerable to a heap-buffer overflow
| vulnerability when decoding the lzw compressed stream of image data in
| GIF files with lzw minimum code size equals to 12.

https://sahildhar.github.io/blogpost/GdkPixbuf-Heap-Buffer-Overflow-in-lzw_decoder_new/
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/issues/136
https://gitlab.gnome.org/GNOME/gdk-pixbuf/-/merge_requests/130

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-2021-44648
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44648

Please adjust the affected versions in the BTS as needed.



Bug#1014599: svgpp: CVE-2021-44960

2022-07-08 Thread Moritz Mühlenhoff
Source: svgpp
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for svgpp.

CVE-2021-44960[0]:
| In SVGPP SVG++ library 1.3.0, the XMLDocument::getRoot function in the
| renderDocument function handled the XMLDocument object improperly,
| returning a null pointer in advance at the second if, resulting in a
| null pointer reference behind the renderDocument function.

https://github.com/svgpp/svgpp/issues/101

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-2021-44960
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44960

Please adjust the affected versions in the BTS as needed.



Bug#1014598: jsonnet: please add support for riscv64

2022-07-08 Thread Bo YU
Source: jsonnet
Version: 0.17.0+ds-2
Severity: wishlist
Tags: ftbfs, patch, upstream
User: debian-ri...@lists.debian.org
Usertags: riscv64
X-Debbugs-Cc: debian-ri...@lists.debian.org

Dear jsonnet Maintainer,

Please add support for riscv64 with patch attached.
I have built riscv64 package on my real riscv64 hardware(Unmatched board)
with it.

Please let me know if you need my assistant.

PS: the patch is for rapidyaml only. So don't forget to add 
riscv64 arch in d/control :)

Bo
-- 
Best Regards,

--- a/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/cpu.hpp
+++ b/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/cpu.hpp
@@ -84,6 +84,12 @@
 #   define C4_CPU_PPC
 #   define C4_WORDSIZE 4
 #   endif
+
+#elif defined(__riscv) && __riscv_xlen == 64
+#   define C4_CPU_RV64
+#   define C4_WORDSIZE 8
+#   define C4_BYTE_ORDER _C4EL
+
 #elif defined(SWIG)
 #else
 #   error "unknown CPU architecture"
--- a/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/ext/fast_float/include/fast_float/float_common.h
+++ b/third_party/rapidyaml/rapidyaml/ext/c4core/src/c4/ext/fast_float/include/fast_float/float_common.h
@@ -9,7 +9,8 @@
|| defined(__amd64) || defined(__aarch64__) || defined(_M_ARM64) \
|| defined(__MINGW64__)  \
|| defined(__s390x__)\
-   || (defined(__ppc64__) || defined(__PPC64__) || defined(__ppc64le__) || defined(__PPC64LE__)))
+   || (defined(__ppc64__) || defined(__PPC64__) || defined(__ppc64le__) \
+   || defined(__PPC64LE__) || defined(__riscv) && __riscv_xlen == 64))
 #define FASTFLOAT_64BIT
 #elif (defined(__i386) || defined(__i386__) || defined(_M_IX86)   \
  || defined(__arm__)\
@@ -337,4 +338,4 @@
   return out;
 }
 
-#endif
\ No newline at end of file
+#endif


signature.asc
Description: PGP signature


Bug#1014597: libitext5-java: new version 5.5.13.3 addresses CVE-2021-43113

2022-07-08 Thread Thomas Uhle

Package: libitext5-java
Version: 5.5.13.2-1
Severity: serious
Tags: security upstream
X-Debbugs-Cc: t...@security.debian.org
Control: found -1 5.5.13-1

Dear maintainers,

there is a new bugfix release upstream for iText 5. In particular, it 
addresses CVE-2021-43113. The new version 5.5.13.3 has been announced on 
Maven as well as on Github at https://github.com/itext/itextpdf/releases 
for instance. Please consider to also update the binary package for 
bullseye and perhaps for buster too.


Could you please also pay attention to my other bug ticket #983715 and 
consider to package itext-xtra along with the other jar files, at least 
for bookworm.


Thank you in advance!

Best regards,

Thomas Uhle


-- System Information:
Debian Release: 11.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: arm64 (aarch64)
Foreign Architectures: armhf

Kernel: Linux 5.10.0-16-arm64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL 
set to en_US.UTF-8), LANGUAGE=en_US.UTF-8
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

libitext5-java depends on no packages.

libitext5-java recommends no packages.

Versions of packages libitext5-java suggests:
ii  libbcpkix-java1.68-2
ii  libbcprov-java1.68-2
pn  libitext5-java-doc
ii  libxml-security-java  2.0.10-2+deb11u1



Bug#1014596: curl FTBFS: missing #include

2022-07-08 Thread Helmut Grohne
Source: curl
Version: 7.84.0-1
Severity: serious
Tags: ftbfs patch upstream
User: helm...@debian.org
Usertags: rebootstrap

Hi,

curl fails to build from source on architectures other than any-x86 and
arm64 due to a missing #include . Please consider applying the
attached patch to fix that.

Helmut
--- curl-7.84.0.orig/lib/easy_lock.h
+++ curl-7.84.0/lib/easy_lock.h
@@ -37,6 +37,10 @@
 #elif defined (HAVE_ATOMIC)
 #include 
 
+#if !defined(__i386__) && !defined(__x86_64__) && !defined(__aarch64__) && defined(HAVE_SCHED_YIELD)
+#include 
+#endif
+
 #define curl_simple_lock atomic_bool
 #define CURL_SIMPLE_LOCK_INIT false
 


Bug#1014595: linux-image-5.19.0-rc4-amd64: Enable CONFIG_SND_SOC_INTEL_SOF_ES8336_MACH=m

2022-07-08 Thread Giovanni Caligaris
Package: src:linux
Version: 5.19~rc4-1~exp1
Severity: normal
X-Debbugs-Cc: giovannicaliga...@gmail.com

Dear Maintainer,

Please enable CONFIG_SND_SOC_INTEL_SOF_ES8336_MACH=m. This will enable sound on 
all Chuwi Hi10 Go N5100 tablets

Thanks,

-- Package-specific info:
** Version:
Linux version 5.19.0-rc4-amd64 (debian-ker...@lists.debian.org) (gcc-11 (Debian 
11.3.0-4) 11.3.0, GNU ld (GNU Binutils for Debian) 2.38.50.20220627) #1 SMP 
PREEMPT_DYNAMIC Debian 5.19~rc4-1~exp1 (2022-07-01)

** Command line:
BOOT_IMAGE=/vmlinuz-5.19.0-rc4-amd64 
root=UUID=3f54a2bb-e3c0-451d-8253-770c09e73f18 ro quiet

** Tainted: W (512)
 * kernel issued warning

** Kernel log:
[7.696875] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. 
Quota mode: none.
[7.726742] mei_me :00:16.0: enabling device ( -> 0002)
[7.727246] iTCO_vendor_support: vendor-support=0
[7.727417] usb 1-3: Found UVC 1.00 device Back Camera (0bda:5876)
[7.728156] cfg80211: Loading compiled-in X.509 certificates for regulatory 
database
[7.728415] cfg80211: Loaded X.509 cert 'b...@debian.org: 
577e021cb980e0e820821ba7b54b4961b8b4fadf'
[7.728649] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 
3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[7.728886] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[7.730815] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db
[7.732282] platform regulatory.0: firmware: direct-loading firmware 
regulatory.db.p7s
[7.734833] input: Back Camera: Back Camera as 
/devices/pci:00/:00:14.0/usb1/1-3/1-3:1.0/input/input10
[7.736385] usb 1-4: Found UVC 1.00 device Front Camera (0bda:5842)
[7.755764] input: Front Camera: Front Camera as 
/devices/pci:00/:00:14.0/usb1/1-4/1-4:1.0/input/input11
[7.755828] usbcore: registered new interface driver uvcvideo
[7.816113] iTCO_wdt iTCO_wdt: Found a Intel PCH TCO device (Version=6, 
TCOBASE=0x0400)
[7.817191] iTCO_wdt iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
[7.888235] input: PC Speaker as /devices/platform/pcspkr/input/input12
[7.896632] pstore: Using crash dump compression: deflate
[7.896651] pstore: Registered efi as persistent store backend
[7.930254] Intel(R) Wireless WiFi driver for Linux
[7.930727] iwlwifi :01:00.0: enabling device ( -> 0002)
[7.941831] iwlwifi :01:00.0: firmware: direct-loading firmware 
iwlwifi-7265D-29.ucode
[7.941861] iwlwifi :01:00.0: Found debug destination: EXTERNAL_DRAM
[7.941864] iwlwifi :01:00.0: Found debug configuration: 0
[7.942454] iwlwifi :01:00.0: loaded firmware version 29.4063824552.0 
7265D-29.ucode op_mode iwlmvm
[7.948245] cryptd: max_cpu_qlen set to 1000
[8.044607] SSE version of gcm_enc/dec engaged.
[8.049731] audit: type=1400 audit(1657288784.499:2): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe" pid=455 
comm="apparmor_parser"
[8.049739] audit: type=1400 audit(1657288784.499:3): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="nvidia_modprobe//kmod" 
pid=455 comm="apparmor_parser"
[8.050854] audit: type=1400 audit(1657288784.503:4): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="lsb_release" pid=454 
comm="apparmor_parser"
[8.051618] audit: type=1400 audit(1657288784.503:5): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="/usr/bin/man" pid=457 
comm="apparmor_parser"
[8.051624] audit: type=1400 audit(1657288784.503:6): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_filter" pid=457 
comm="apparmor_parser"
[8.051626] audit: type=1400 audit(1657288784.503:7): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="man_groff" pid=457 
comm="apparmor_parser"
[8.062205] audit: type=1400 audit(1657288784.511:8): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="ioq3ded" pid=475 
comm="apparmor_parser"
[8.064971] audit: type=1400 audit(1657288784.515:9): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/snapd/snap-confine" pid=477 comm="apparmor_parser"
[8.064980] audit: type=1400 audit(1657288784.515:10): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" pid=477 
comm="apparmor_parser"
[8.068895] snd_hda_intel :00:1f.3: DSP detected with PCI 
class/subclass/prog-if info 0x040100
[8.070625] audit: type=1400 audit(1657288784.523:11): apparmor="STATUS" 
operation="profile_load" profile="unconfined" name="ioquake3" pid=476 
comm="apparmor_parser"
[8.152689] Bluetooth: Core ver 2.22
[8.152731] NET: Registered PF_BLUETOOTH protocol family
[8.152733] Bluetooth: HCI device and connection manager initialized
[8.152739] Bluetooth: HCI socket layer initialized
[8.152742] Bluetooth: L2CAP socket layer init

Bug#1014594: muse: FTBFS on riscv64

2022-07-08 Thread John Paul Adrian Glaubitz
Hi Ileana!

On 7/8/22 15:46, Ileana Dumitrescu wrote:
> The package muse, version 4.1.0-1, has a FTFBS issue for riscv.
> (...)
> The attached patch fixes the issue, and I will create a merge request on
> the salsa repo at https://salsa.debian.org/multimedia-team/muse.

Great, thanks for fixing this. Have you submitted your patch upstream as
well?

I'm seeing a lot of people submitting patches to this mailing list and I
really hope these are all also submitted upstream so other distributions
can profit from these improvements as well.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913



Bug#1011629: minidlna: can't access localhost:8200 - DNS rebinding attack suspected

2022-07-08 Thread Diederik de Haas
On vrijdag 8 juli 2022 15:50:32 CEST Marcos Raúl Carot wrote:
> On Fri, 8 Jul 2022 at 21:06, Diederik de Haas  wrote:
> > On 25 May 2022 22:13:27 +0800 Marcos Carot  wrote:
> > > Please note, this seems to be a security issue:
> > > https://security.snyk.io/vuln/SNYK-UNMANAGED-MINIDLNA-2419090
> > 
> > Isn't that the result of the patch that addresses that specific issue?
> > IIUC version 1.3.0+dfsg-2.2 was specifically to address that.
> 
> Oh, so there is no way now to access the web page from minidlna? Cheers.

I was only asking a question to make the issue more clear.
If that's the result, I can see that could be an unwanted side effect.

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


Bug#1011629: minidlna: can't access localhost:8200 - DNS rebinding attack suspected

2022-07-08 Thread Marcos Raúl Carot
Oh, so there is no way now to access the web page from minidlna? Cheers.

On Fri, 8 Jul 2022 at 21:06, Diederik de Haas  wrote:

> On 25 May 2022 22:13:27 +0800 Marcos Carot  wrote:
> > Package: minidlna
> > Version: 1.3.0+dfsg-2.2
> >
> >* What led up to the situation? browse localhost:8200
> >* What was the outcome of this action? "not found" page shown -
> >logs show upnphttp.c:922: error: DNS rebinding attack suspected
> >* What outcome did you expect instead? page shown.
> >
> > Please note, this seems to be a security issue:
> > https://security.snyk.io/vuln/SNYK-UNMANAGED-MINIDLNA-2419090
>
> Isn't that the result of the patch that addresses that specific issue?
> IIUC version 1.3.0+dfsg-2.2 was specifically to address that.
>
>
> https://tracker.debian.org/news/1315039/accepted-minidlna-130dfsg-22-source-into-unstable/
>
> Changes:
>  minidlna (1.3.0+dfsg-2.2) unstable; urgency=medium
>  .
>* Non-maintainer upload.
>* CVE-2022-26505
>  Validate HTTP requests to protect against DNS rebinding, thus forbid
>  a remote web server to exfiltrate media files.
>  (Closes: #1006798)
>
>
> https://salsa.debian.org/debian/minidlna/-/commit/9017019ac446b945c92a976a8dcebab3d7789927
> is the commit in the salsa repo for this.



-- 
Marcos R Carot


Bug#1014593: amd64-microcode: Updated version for bullseye/stable?

2022-07-08 Thread Michael Prokop
Package: amd64-microcode
Version: 3.20191218.1
Severity: wishlist

Hi,

quoting from
https://wiki.debian.org/Microcode#Microcode_update_support_for_current_and_older_Debian_releases:

| Debian 11, codename "Bullseye" is supported, and will receive
| updates both through the bullseye-backports official backports
| repository (faster than point-releases), and through Debian stable
| point-releases and security updates.

Users seem to be relying on this (as I was just asked about policies
when microcode updates are updated/backported).

Would you please consider updating the package in stable? :)
Thanks!

regards
-mika-



Bug#1005219: minidlna: Floods logfile with 'minidlna.c:166: error: accept(http): Too many open files'

2022-07-08 Thread Diederik de Haas
Control: tag -1 upstream

On Wed, 09 Feb 2022 08:42:27 +0100 Nicolas Schier  wrote:
> Package: minidlna
> Version: 1.3.0+dfsg-2
> 
> When I let minidlna run for some weeks, it eventually starts flooding its
> logfile with endlessly repeated 
> 
>minidlna.c:166: error: accept(http): Too many open files
> 
> until the filesystem is full.  (Which is a quite annoying behaviour to me.)

This sounds like an issue that should be reported (and fixed) upstream.

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


Bug#1014522: pipewire: Regressions in 0.3.53-1

2022-07-08 Thread Dylan Aïssi
Hi,

Le jeu. 7 juil. 2022 à 17:03,  a écrit :

> - I haven't tested version 0.3.52-1, so I'm not sure if the regression was
>   introduced in 0.3.53 or 0.3.52.
>

The new pipewire version 0.3.54, available in sid, fixes some critical bugs.
It would be nice if you could test it.

Best,
Dylan



Bug#798077: minidlna: segfault libc-2.19

2022-07-08 Thread Diederik de Haas
On Wed, 9 Sep 2015 13:15:10 +0300 Alexander Gerasiov  wrote:
> fixed 798077 1.1.4+dfsg-1
> thanks
> 
> On Tue, 8 Sep 2015 21:34:36 +0200 fhobbies  wrote:
> > after an update of packages without minidlna backport and rebooting
> > (and update of libc), the running is the same … crash. But
> > effectively after migration of minidlna to jessie-backports, the
> > process running without crash (segfault).
>
> Ok, then I mark this bug as fixed in 1.1.4+dfsg-1 and put the problem
> on hold until someone prove this is really critical and patch should be
> backported (security etc).

I guess this bug can be closed now?

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


Bug#1004016: pipewire 0.3.43 upgrade automatically selects broken profile

2022-07-08 Thread Dylan Aïssi
Hi Alexander,

Le ven. 1 juil. 2022 à 17:49, Alexander Clausen  a écrit :
>
> It seems that the issue is kind-of fixed: the "Pro Audio" profile is
> still selected, but it now works and is selectable as a default input
> device. Feel free to close this bug.
>

I am glad you get back your microphone working.
But, the "Pro Audio" profile is not something you should use and even
more by default.
So, I think there is still something wrong, I will keep this bug open,
it would be nice to obtain advice from upstream.

Best,
Dylan



Bug#1011629: minidlna: can't access localhost:8200 - DNS rebinding attack suspected

2022-07-08 Thread Diederik de Haas
On 25 May 2022 22:13:27 +0800 Marcos Carot  wrote:
> Package: minidlna
> Version: 1.3.0+dfsg-2.2
> 
>* What led up to the situation? browse localhost:8200
>* What was the outcome of this action? "not found" page shown - 
>logs show upnphttp.c:922: error: DNS rebinding attack suspected
>* What outcome did you expect instead? page shown.
> 
> Please note, this seems to be a security issue:
> https://security.snyk.io/vuln/SNYK-UNMANAGED-MINIDLNA-2419090

Isn't that the result of the patch that addresses that specific issue?
IIUC version 1.3.0+dfsg-2.2 was specifically to address that.

https://tracker.debian.org/news/1315039/accepted-minidlna-130dfsg-22-source-into-unstable/

Changes:
 minidlna (1.3.0+dfsg-2.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * CVE-2022-26505
 Validate HTTP requests to protect against DNS rebinding, thus forbid
 a remote web server to exfiltrate media files.
 (Closes: #1006798)

https://salsa.debian.org/debian/minidlna/-/commit/9017019ac446b945c92a976a8dcebab3d7789927
is the commit in the salsa repo for this.

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


Bug#1014394: linux kernel 5.10.0-15 on virtualbox host causes random process crashes in guests

2022-07-08 Thread Bastian Blank
Control: tags -1 unreproducible

On Tue, Jul 05, 2022 at 12:09:00PM +0200, Michael wrote:
> i am running virtualbox 6.1.34 from the virtualbox.org repo on a debian 11.3
> host. the guest also runs debian 11.3.

As Virtualbox uses it's own kernel module, we can't provide any help.
You need to ask them for a fixed version to work with that kernel
version.

Or you can use the included kvm support.

Bastian

-- 
Yes, it is written.  Good shall always destroy evil.
-- Sirah the Yang, "The Omega Glory", stardate unknown



Bug#1014591: ITP: tofi -- fast and simple dmenu / rofi replacement for wlroots-based Wayland compositors

2022-07-08 Thread Birger Schacht
Package: wnpp
Severity: wishlist
Owner: Birger Schacht 
X-Debbugs-Cc: debian-de...@lists.debian.org, bir...@debian.org

* Package name: tofi
  Version : 0.1.1
  Upstream Author : Philip Jones
* URL : https://github.com/philj56/tofi
* License : MIT
  Programming Lang: C
  Description : fast and simple dmenu / rofi replacement for wlroots-based 
Wayland compositors

An extremely fast and simple dmenu / rofi replacement for wlroots-based
Wayland compositors such as Sway. When configured correctly, tofi can get on
screen within a single frame.

I plan to maintain this package in the swaywm-team.



Bug#1014394: linux kernel 5.10.0-15 on virtualbox host causes random process crashes in guests

2022-07-08 Thread Walter Schweizer
Package: src:linux
Version: 5.10.120-1
Followup-For: Bug #1014394
X-Debbugs-Cc: s...@users.sourceforge.net

Dear Maintainer,

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

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

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

I am also affected by this issue.

I cannot use my VM images anymore on this kernel version.
The Windows10 guest randomly crashes with:
00:35:44.190732 GIM: HyperV: Guest indicates a fatal condition! P0=0x1e
P1=0xc005 P2=0xf80732849020 P3=0x0 P4=0x
00:35:44.190795 GIMHv: BugCheck 1e {c005, f80732849020, 0,
}
00:35:44.190795 KMODE_EXCEPTION_NOT_HANDLED
00:35:44.190796 P1: c005 - exception code - STATUS_ACCESS_VIOLATION
00:35:44.190796 P2: f80732849020 - EIP/RIP
00:35:44.190796 P3:  - Xcpt param #0
00:35:44.190796 P4:  - Xcpt param #1
00:35:45.515885 AHCI#0: Reset the HBA
00:35:45.515902 VD#0: Cancelling all active requests
00:35:45.516175 AHCI#0: Port 0 reset
00:35:45.517213 VD#0: Cancelling all active requests
00:35:47.317356 VMMDev: vmmDevHeartbeatFlatlinedTimer: Guest seems to be
unresponsive. Last heartbeat received 4 seconds ago
00:35:55.668680 VMMDev: Guest Log: VBoxGuest: BugCheck! P0=0x1e
P1=0xc005 P2=0xf80732849020 P3=0x0 P4=0x

When I downgrade the kernel to linux-image-5.10.0-14-amd64 (5.10.113-1)
the VM runs well!



-- Package-specific info:
** Kernel log: boot messages should be attached

** Model information
sys_vendor: FUJITSU
product_name: CELSIUS H760
product_version: 10601186099
chassis_vendor: FUJITSU
chassis_version: CELSIUS H760
bios_vendor: FUJITSU // Insyde Software Corp.
bios_version: Version 1.32
board_vendor: FUJITSU
board_name: FJNB29A
board_version: D4

** Network interface configuration:
*** /etc/network/interfaces:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th 
Gen Core Processor Host Bridge/DRAM Registers [8086:1910] (rev 07)
Subsystem: Fujitsu Limited. Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
Processor Host Bridge/DRAM Registers [10cf:1937]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: skl_uncore

00:01.0 PCI bridge [0604]: Intel Corporation 6th-10th Gen Core Processor PCIe 
Controller (x16) [8086:1901] (rev 07) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- TAbort- Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: 
Kernel driver in use: pcieport

00:14.0 USB controller [0c03]: Intel Corporation 100 Series/C230 Series Chipset 
Family USB 3.0 xHCI Controller [8086:a12f] (rev 31) (prog-if 30 [XHCI])
Subsystem: Fujitsu Limited. 100 Series/C230 Series Chipset Family USB 
3.0 xHCI Controller [10cf:1937]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
SERR- 
Kernel driver in use: xhci_hcd
Kernel modules: xhci_pci

00:16.0 Communication controller [0780]: Intel Corporation 100 Series/C230 
Series Chipset Family MEI Controller #1 [8086:a13a] (rev 31)
Subsystem: Fujitsu Limited. 100 Series/C230 Series Chipset Family MEI 
Controller [10cf:1937]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: mei_me
Kernel modules: mei_me

00:16.3 Serial controller [0700]: Intel Corporation 100 Series/C230 Series 
Chipset Family KT Redirection [8086:a13d] (rev 31) (prog-if 02 [16550])
Subsystem: Fujitsu Limited. 100 Series/C230 Series Chipset Family KT 
Redirection [10cf:1937]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 
Kernel driver in use: serial

00:17.0 SATA controller [0106]: Intel Corporation HM170/QM170 Chipset SATA 
Controller [AHCI Mode] [8086:a103] (rev 31) (prog-if 01 [AHCI 1.0])
Subsystem: Fujitsu Limited. HM170/QM170 Chipset SATA Controller [AHCI 
Mode] [10cf:1937]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB

Bug#1014590: qemu: CVE-2022-0216

2022-07-08 Thread Moritz Mühlenhoff
Source: qemu
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for qemu.

https://starlabs.sg/advisories/22-0216
https://gitlab.com/qemu-project/qemu/-/issues/972

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-0216
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-0216

Please adjust the affected versions in the BTS as needed.



Bug#1014589: qemu: CVE-2022-1050

2022-07-08 Thread Moritz Mühlenhoff
Source: qemu
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for qemu.

CVE-2022-1050[0]:
| A flaw was found in the QEMU implementation of VMWare's paravirtual
| RDMA device. This flaw allows a crafted guest driver to execute HW
| commands when shared buffers are not yet allocated, potentially
| leading to a use-after-free condition.

Proposed patch at 
https://lists.nongnu.org/archive/html/qemu-devel/2022-03/msg05197.html
but not merged yet. 

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-1050
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-1050

Please adjust the affected versions in the BTS as needed.



Bug#1014523: strawberry: Fails to index a few songs

2022-07-08 Thread Peter B

raised upstream at

https://forum.strawberrymusicplayer.org/topic/679/fails-to-index-a-few-songs



Bug#1014586: giflib: CVE-2021-40633

2022-07-08 Thread Moritz Mühlenhoff
Source: giflib
X-Debbugs-CC: t...@security.debian.org
Severity: normal
Tags: security

Hi,

The following vulnerability was published for giflib.

CVE-2021-40633[0]:
| A memory leak (out-of-memory) in gif2rgb in util/gif2rgb.c in giflib
| 5.1.4 allows remote attackers trigger an out of memory exception or
| denial of service via a gif format file.

https://sourceforge.net/p/giflib/bugs/157/

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-2021-40633
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-40633

Please adjust the affected versions in the BTS as needed.



Bug#1014584: lintian: False positive binary-nmu-debian-revision-in-source and source-nmu-has-incorrect-version-number with Ubuntu version

2022-07-08 Thread Axel Beckert
Hi,

Alberto Contreras wrote:
> When I invoke `lintian` over a package with a version like
> `22.2-64-g1fcd55d6-0ubuntu1~22.10.1` it emits
> `binary-nmu-debian-revision-in-source` and
> `source-nmu-has-incorrect-version-number` source warnings.  This looks like
> a false positive.
[…]
> We think it could be related to the following
> detection:
> https://salsa.debian.org/lintian/lintian/-/blob/ecc04980869462c5c71f4f71e9b8a71bd5b944b5/lib/Lintian/Check/Fields/Version.pm#L87
> regex:
> https://salsa.debian.org/lintian/lintian/-/blob/ecc04980869462c5c71f4f71e9b8a71bd5b944b5/lib/Lintian/Check/Fields/Version.pm#L65

Nope, it's likely
https://salsa.debian.org/lintian/lintian/-/blob/ecc04980869462c5c71f4f71e9b8a71bd5b944b5/lib/Lintian/Check/Fields/Version.pm#L70
which needs to be updated.

Note to myself: There's a similar albeit not identical issue reported
in https://bugs.debian.org/1001399.

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



Bug#1014511: sysvinit: debian/copyright reports incorrect licenses

2022-07-08 Thread Axel Beckert
Hi,

binh1.tran...@toshiba.co.jp wrote:
> > debian/copyright _IS_ the canonical place for copyright statements about 
> > debian/*
> > So this is wrong and MUST NOT be changed as it would mean we would LOOSE 
> > the copyright statements for the remaining files in debian/*.
>
> Thank you for your sharing.
> 
> In the original debian/copyright file, debian/* paragraph is missing
> copyright of some files as below:

Ok, that's very possible.

> I'd like to send you the new copyright without removing debian/* at
> the attachment.

Thanks.

> Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ 
>   

Hmmm, this should be HTTPS nowadays. (Likely not your fault. :-)

> Files: debian/*
> Copyright: 2015 Adam Conrad 
>2018 Dmitry Bogatov 
>2018 Vincenzo (KatolaZ) Nicosia 
>2006 Henrique de Moraes Holschuh 
>2017 Ian Jackson 
>2014 Robert Millan 
>2014 Thomas Goirand 
>2006 Thomas Hood 
>2015-2016 Andreas Henriksson 
>2011,2016 Ben Hutchings 
>2010-2012 Christian Perrier 
>2015-2016 Martin Pitt 
>2014-2018 Michael Biebl 
>1996-2004 Miquel van Smoorenburg 
>2005-2010, 2014 Petter Reinholdtsen 
>2011-2013 Roger Leigh 
>2006-2007 Steinar H. Gunderson 
>2012-2013 Steve Langasek 
>2009 Adriano Rafael Gomes , 2009-2020.
>2019 sysvinit & Joe Hansen.
>2009 Software in the Public Interest
>2012 Martin Bagge 
>2012 Debian French l10n Team
>2009 Hideki Yamane 
> License: GPL-2.0+

Generally looks fine that way.

I'd though leave the decision if the additions should be listed
separately for these files or in summary as above to the actual
package maintainers. (I'm just generally interested in the shape of
this package as I'm a heavy user of it. And I did a lot of
debian/copyright conversions to the machine-readable format in the
past.)

Additionally I would recommend to the package maintainers to sort this
list in some way. Usually they're sorted by the first contribution,
e.g. sorted alphabetically like this:

  Copyright: 1996-2004 Miquel van Smoorenburg 
 2005-2010, 2014 Petter Reinholdtsen 
 2006 Henrique de Moraes Holschuh 
 2006 Thomas Hood 
 2006-2007 Steinar H. Gunderson 
 2009 Adriano Rafael Gomes , 2009-2020.
 2009 Hideki Yamane 
 2009 Software in the Public Interest
 2010-2012 Christian Perrier 
 2011,2016 Ben Hutchings 
 2011-2013 Roger Leigh 
 2012 Debian French l10n Team
 2012 Martin Bagge 
 2012-2013 Steve Langasek 
 2014 Robert Millan 
 2014 Thomas Goirand 
 2014-2018 Michael Biebl 
 2015 Adam Conrad 
 2015-2016 Andreas Henriksson 
 2015-2016 Martin Pitt 
 2017 Ian Jackson 
 2018 Dmitry Bogatov 
 2018 Vincenzo (KatolaZ) Nicosia 
 2019 sysvinit & Joe Hansen.

> Files: debian/po/vi.po
> Copyright: 2009 Free Software Foundation, Inc. Clytie Siddall 
> , 2009.

The 2009 at the beginning and end looks odd. This probably should
better be:

  Copyright: 2009 Free Software Foundation, Inc.
 2009 Clytie Siddall 

> License:
   ^^^

Here's the license name missing. Just an empty "License:" field
without value is not valid syntax (nor valid semantic).

But I do see that the file has a copyright statement without a license
statement.

Actually having an explicit copyright statement in that file without
having a license declared actually makes the file's license situation
a bit being in limbo.

Then again, seeing no license in combination with a copyright
statement of the FSF is very odd. It is very likely that the license
statement got lost at some point in time. Unfortunately this must have
happened before the import into Debian in 2009 as the file got
committed to git with that statement as it is today:
https://bugs.debian.org/550220 — I guess the only way to find out is
to contact Clytie Siddall and ask for clarification.

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



Bug#1011688: Thank you for the synaptic NMU

2022-07-08 Thread Michael Vogt
Hey,

just wanted to send a quick THANK YOU note for the NMU diff. I uploaded a new 
version of synaptic with it and various other collected fixes/changes. But I 
realized I did not reply with a thank you :)

Cheers,
 Michael



Bug#1014523: strawberry: Fails to index a few songs

2022-07-08 Thread Peter B

On 07/07/2022 16:11, Alberto Fuentes wrote:

Package: strawberry
Version: 1.0.5-1
Severity: normal
X-Debbugs-Cc: paj...@gmail.com

Dear Maintainer,

When i try to index my music collection i get this error

Unable to execute SQL query: NOT NULL constraint failed: songs.ctime Unable to
fetch rowFailed query: INSERT INTO songs (title, album, artist,
albumartist, track, disc, year, originalyear, genre, compilation, composer,
performer, grouping, comment, lyrics, artist_id, album_id, song_id, beginning,
length, bitrate, samplerate, bitdepth, source, directory_id, url, filetype,
filesize, mtime, ctime, unavailable, fingerprint, playcount, skipcount,
lastplayed, lastseen, compilation_detected, compilation_on, compilation_off,
compilation_effective, art_automatic, art_manual, effective_albumartist,
effective_originalyear, cue_path, rating) VALUES (The Ecstacy Of Gold, S&M with
the San Francisco Symphony, Metallica, S&M with the San Francisco
Symphonyartist, 1, 1, 1999, -1, Rock, 0, , Metallica, , 0, , Metallica_id, S&M
with the San Francisco Symphony_id, , 0, 15067400, 320, 44100, -1, 2, 1,
file:///home/pajaro/Music/onerandomsong.mp3, 8, 6029210, 1335652082, , 0, , 0,
0, -1, 1657206086, 0_detected, 0_on, 0_off, 0_effective, , , Metallica, 1999, ,
-1)

And the then indexing stops

It happened with a few songs and i try removing them, but then another diffrent
song fails

`$ stats /home/pajaro/Music/onerandomsong.mp3` Give proper values for the file.
I dont know what can be happening here



Hi Alberto,

Please state exactly what you did to experience this problem. I cannot find 'index' or 'indexing' in the menus or 
command line options.

Did you mean a Collection Scan? There's nothing much I can do here without 
being able to reproduce.


Please check obvious things like disc space in the home partition and invalid 
mp3 files.

It would be interesting to know if the same problem occurs with upstream's 
build.
https://files.strawberrymusicplayer.org/strawberry_1.0.5-bookworm_amd64.deb

or Clementine which is similar
https://tracker.debian.org/pkg/clementine


Problems can also be reported at
https://forum.strawberrymusicplayer.org/category/5/technical-help


Cheers,
Peter



Bug#992637: same here

2022-07-08 Thread Thomas Braun
I've experienced a similiar issue. After an upgrade to debian bullseye most of 
the USB ports stopped working. Whenever I used a USB device the PC crashed. As 
they work on Windows it is not a hardware issue.

Removing the power saving with powertop did the trick!

Thanks for posting that!

Mainboard: Asus P9X79



Bug#1014585: ITP: coq-stdpp -- Extended standard library for Coq

2022-07-08 Thread Julien Puydt
Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: coq-stdpp
  Version : 1.7.0
  Upstream Author : std++ team
* URL : https://gitlab.mpi-sws.org/iris/stdpp
* License : BSD-3-clause
  Programming Lang: Coq
  Description : Extended standard library for Coq
 This package provides an extended standard library
 for Coq, for instance:
 - a great number of definitions and lemmas for common data
 structures like lists, finite maps and finite multisets ;
 - type classes for common properties like decidable equality,
 finiteness or countability ;
 - various tactics for common tasks ;
 all of this dependency-free and axiom-free.
 .
 Coq is a proof assistant for higher-order logic.


I plan to maintain this package within the Debian OCaml Maintainers team, along
with the rest of the Coq-related packages.

Cheers,

J.Puydt



Bug#1014584: lintian: False positive binary-nmu-debian-revision-in-source and source-nmu-has-incorrect-version-number with Ubuntu version

2022-07-08 Thread Alberto Contreras
Package: lintian
Version: 2.115.2

When I invoke `lintian` over a package with a version like
`22.2-64-g1fcd55d6-0ubuntu1~22.10.1` it emits
`binary-nmu-debian-revision-in-source` and
`source-nmu-has-incorrect-version-number` source warnings.  This looks like
a false positive.
Here is a transcript:

$ wget -q \

https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/cloud-init/22.2-64-g1fcd55d6-0ubuntu1~22.10.1/cloud-init_22.2-64-g1fcd55d6.orig.tar.gz
\

https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/cloud-init/22.2-64-g1fcd55d6-0ubuntu1~22.10.1/cloud-init_22.2-64-g1fcd55d6-0ubuntu1~22.10.1.debian.tar.xz
\

https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/cloud-init/22.2-64-g1fcd55d6-0ubuntu1~22.10.1/cloud-init_22.2-64-g1fcd55d6-0ubuntu1~22.10.1.dsc
> /dev/null

$ lintian cloud-init_22.2-64-g1fcd55d6-0ubuntu1~22.10.1.dsc
...
W: cloud-init source: binary-nmu-debian-revision-in-source
22.2-64-g1fcd55d6-0ubuntu1~22.10.1
W: cloud-init source: source-nmu-has-incorrect-version-number
22.2-64-g1fcd55d6-0ubuntu1~22.10.1
...

We think it could be related to the following
detection:
https://salsa.debian.org/lintian/lintian/-/blob/ecc04980869462c5c71f4f71e9b8a71bd5b944b5/lib/Lintian/Check/Fields/Version.pm#L87
regex:
https://salsa.debian.org/lintian/lintian/-/blob/ecc04980869462c5c71f4f71e9b8a71bd5b944b5/lib/Lintian/Check/Fields/Version.pm#L65

The warnings happen in:
- Debian 12, lintian 2.115.2
- Debian 11, lintian 2.104.0
- Debian 10, lintian 2.15.0
- Debian 9, lintian 2.5.50.4

I have created a pastebin with a full reproducer:
https://pastebin.ubuntu.com/p/85q7kXbZTW/


Bug#1006724: network-manager: DNS information not cleaned correctly when switching of networks

2022-07-08 Thread Baptiste Jonglez
Hello,

I can confirm that this bug still happens with Network-Manager 1.38.2 in 
bookworm.

Upstream has recently merged the fix mentioned by Visti, and has
backported it to 1.36 and 1.38.

So, here is the recap:

- the bug has been introduced in 1.35.1-dev
- the bug has been fixed in 1.39.8-dev
- the backported fix will be released in 1.38.4 (not yet released)
- the backported fix will be released in 1.36.6 (not yet released)

For bookworm, Debian can either backport the patch manually, or wait for
1.38.4 to be released and pull that in.

I notice that bullseye-backports has 1.38.0, it will probably also need an
update or a manual backport.

Thanks,
Baptiste



Bug#1014376: openvpn: Using unreleased version with backwards incompatible changes is not a good idea

2022-07-08 Thread Raphael Hertzog
On Wed, 06 Jul 2022, Bernhard Schmidt wrote:
> > As such I really believe that this git snapshot should have stayed in
> > experimental. Why was it uploaded to unstable before its upstream
> > release?
> 
> I respectfully disagree. This is what unstable/testing is for. 2.6 is to be
> released really soon, it contains breaking changes which we need to iron out
> / document with both upstream and Debian packaging. This can't wait until
> the last minute before the freeze. The 2.6 upload was influenced by OpenSSL
> 3.0, but this was definitely not the only reason to do this.

If you were aware of regressions to iron out, it would have made sense to
file an RC bug to avoid the migration to testing until it has matured in
unstable.

I understand it's always a trade off and that not all Debian developers
put the bar at the same level, but keeping testing "constantly usable"
has been something of a goal for a long time.

> This could be discussed with upstream.

I certainly encourage you to discuss with upsream on whether they believe
a git snapshot ought to be delivered to unstable/testing (and thus
ultimately ubuntu too).

Cheers,
-- 
Raphaël Hertzog ◈ Freexian SARL ◈ Tel: +33 (0)6 88 21 35 47
https://www.freexian.com



Bug#1014583: ITP: coq-equations -- Coq library to work with functions defined by equations

2022-07-08 Thread Julien Puydt
Package: wnpp
Severity: wishlist
Owner: Julien Puydt 
X-Debbugs-Cc: Debian OCaml Maintainers , 
jpu...@debian.org

* Package name: coq-equations
  Version : 1.3-8.15
  Upstream Author : Matthieu Sozeau and Cyprien Mangin
* URL : https://github.com/mattam82/Coq-Equations
* License : LGPL-2.1+
  Programming Lang: Coq
  Description : Coq library to work with functions defined by equations
 This library provides a notation to write programs using dependent
 pattern-matching and well-founded recursion in Coq.
 .
 Coq is a proof assistant for higher-order logic.

I plan to maintain this package within the Debian OCaml Maintainers team, along
with the rest of the coq-related packages.

Cheers,

J.Puydt



Bug#1014114: installation of crypt.h in the multiarch location breaks the GCC and LLVM multilib builds

2022-07-08 Thread Matthias Klose

On 30.06.22 14:21, Marco d'Itri wrote:

On Jun 30, Matthias Klose  wrote:


installation of crypt.h in the multiarch location breaks the GCC and LLVM
multilib builds.

For libsanitizer, crypt.h is needed to determine the size of a struct, the
library itself is not needed.  Moving it to the MA location makes it
unavailable for the non-multilib builds.

Unfortunately the changelog doesn't mention anything why it was moved.

So either it should be moved back to /usr/include, or we need multilib
builds for libxcrypt.

It was discussed in #1004102 (and is documented in the git commit),
where Helmut was positive that this would not cause any issues. Helmut?

(Why can't we retire multilib for good?)


because it's still needed, and we don't have the cross compilers as a 
replacement ready. As Helmut suggested, we need support for foreign dependencies 
and build dependencies.


Please can we revert this?

Matthias



Bug#1014582: Build failure with googletest 1.12

2022-07-08 Thread Mattias Ellert
Source: seqan3
Version: 3.2.0+ds-1
Severity: serious

The package fails to build in unstable due to a failing test.
The failure is due to a change in googletest 1.12


7451/8534 Test #7451: test/pretty_printing_test::pretty_printing.std_output 
..***Failed
0.16 sec
Running main() from /usr/src/googletest/googletest/src/gtest_main.cc
Note: Google Test filter = pretty_printing.std_output
[==] Running 1 test from 1 test suite.
[--] Global test environment set-up.
[--] 1 test from pretty_printing
[ RUN  ] pretty_printing.std_output
/tmp/autopkgtest-lxc.y_bdsw4i/downtmp/autopkgtest_tmp/unit/test/pretty_printing_test.cpp:70:
 Failure
Expected equality of these values:
  gtest_str(std::nullopt)
Which is: "(nullopt)"
  ""s
Which is: ""
[  FAILED  ] pretty_printing.std_output (0 ms)
[--] 1 test from pretty_printing (0 ms total)

[--] Global test environment tear-down
[==] 1 test from 1 test suite ran. (0 ms total)
[  PASSED  ] 0 tests.
[  FAILED  ] 1 test, listed below:
[  FAILED  ] pretty_printing.std_output

 1 FAILED TEST


The following tests FAILED:
7451 - test/pretty_printing_test::pretty_printing.std_output (Failed)


The fix is something like this:


diff -ur seqan3-3.2.0+ds/test/unit/test/pretty_printing_test.cpp 
seqan3-3.2.0+ds.new/test/unit/test/pretty_printing_test.cpp
--- seqan3-3.2.0+ds/test/unit/test/pretty_printing_test.cpp 2022-07-08 
10:35:03.98400 +0200
+++ seqan3-3.2.0+ds.new/test/unit/test/pretty_printing_test.cpp 2022-07-08 
10:22:40.12400 +0200
@@ -67,7 +67,11 @@
 EXPECT_EQ(gtest_str(std::vector>{{0, 1}, {2, 3}, {1, 2}, 
{0}}), "[[0,1],[2,3],[1,2],[0]]"s);
 EXPECT_EQ(debug_str(std::vector>{{0, 1}, {2, 3}, {1, 2}, 
{0}}), "[[0,1],[2,3],[1,2],[0]]"s);
 
+#if [condition that indicates googletest version is >= 1.12]
+EXPECT_EQ(gtest_str(std::nullopt), "(ynullopt)"s);
+#else
 EXPECT_EQ(gtest_str(std::nullopt), ""s);
+#endif
 EXPECT_EQ(debug_str(std::nullopt), ""s);
 }
 

I don't know the best way to define the [condition that indicates
googletest version is >= 1.12]

The seqan build is used as a autopkgtest for googletest, so this
failure is blocking the migration to testing for the googletest
package. (Can this be overridden somehow, if seqan is not fixed?)

Mattias




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


Bug#1014581: systemd-boot: kernel hook schould use conforming name

2022-07-08 Thread Norbert Lange
Package: systemd-boot
Version: 251.2-7
Severity: normal
X-Debbugs-Cc: nolang...@gmail.com

Dear Maintainer,

The kernel hook in /etc/kernel/{post,pre}inst.d should
be named correctly, to quote the kernel-handbook [1]:

>   hook scripts for boot loaders must be named using
the prefix zz- and no other packages may use this prefix

so zz-systemd-boot whould be correct.


[1] - https://kernel-team.pages.debian.net/kernel-handbook/ch-update-hooks.html


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

Kernel: Linux 5.18.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, 
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages systemd-boot depends on:
ii  libc6  2.33-7
ii  libsystemd-shared  251.2-7
ii  systemd-boot-efi   251.2-7

Versions of packages systemd-boot recommends:
pn  efibootmgr  

systemd-boot suggests no packages.

-- no debconf information



Bug#1014452: pyresample: Test failures with rasterio 1.3.0

2022-07-08 Thread Sebastiaan Couwenberg

Control: tags -1 - ftbfs

On 7/8/22 09:03, Antonio Valentino wrote:

I'm not able to reproduce the issue in sid.


I cannot reproduce the FTBFS anymore either, tagging accordingly.


Both the package build and autopkgtest seem to work with rasterionv1.3.0


I can reproduce it in bookworm chroot with python3-rasterio from 
unstable like the debci environment.


Start with an uptodate bookworm chroot and login to it:

 sudo cowbuilder --update \
 --basepath /var/cache/pbuilder/base-bookworm.cow/
 sudo cowbuilder --login \
 --basepath /var/cache/pbuilder/base-bookworm.cow/

Get the source package and install dependencies:

 cd /tmp/buildd
 sed -i 's/^#deb/deb/g' /etc/apt/sources.list
 apt update && apt source pyresample
 cd pyresample-1.23.0/
 apt build-dep pyresample
 apt install python3-pyresample python-pyresample-test python3-all

Install autopkgtest packages:

 apt install autopkgtest newpid

Run autopkgtest with only testing versions of packages:

 newpid autopkgtest --no-built-binaries \
--output-dir ../autopkgtest.out \
--summary ../autopkgtest.summary \
-- autopkgtest-virt-null

This autopkgtest run succeeds.

Now add python3-rasterio from unstable:

 echo "deb http://ftp.nl.debian.org/debian/ unstable main" \
 >> /etc/apt/sources.list
 apt update && apt install python3-rasterio

Run autopkgtest again:

 rm -rfv ../autopkgtest.*
 newpid autopkgtest --no-built-binaries \
--output-dir ../autopkgtest.out \
--summary ../autopkgtest.summary \
-- autopkgtest-virt-null

This run fails like the one on debci.

Just importing rasterio fails:

 python3
 >>> import rasterio
 Traceback (most recent call last):
   File "", line 1, in 
   File "/usr/lib/python3/dist-packages/rasterio/__init__.py", line 14, 
in 

 from rasterio.crs import CRS
   File "rasterio/crs.pyx", line 1, in init rasterio.crs
   File "rasterio/_base.pyx", line 22, in init rasterio._base
   File "/usr/lib/python3/dist-packages/rasterio/dtypes.py", line 10, 
in 

 from rasterio.env import GDALVersion
   File "/usr/lib/python3/dist-packages/rasterio/env.py", line 16, in 


 from rasterio._env import (
   File "rasterio/_env.pyx", line 1, in init rasterio._env
 ImportError: 
/usr/lib/python3/dist-packages/rasterio/_filepath.cpython-310-x86_64-linux-gnu.so: 
undefined symbol: VSIAllocFilesystemPluginCallbacksStruct


But it succeeds once libgdal31 from unstable is also used:

 apt install libgdal31
 python3
 >>> import rasterio
 >>> rasterio._show_versions.show_versions()
 rasterio info:
   rasterio: 1.3.0
   GDAL: 3.5.1
   PROJ: 9.0.1
   GEOS: 3.11.0
  PROJ DATA: /root/.local/share/proj:/usr/share/proj
  GDAL DATA: None

 System:
 python: 3.10.5 (main, Jun  8 2022, 09:26:22) [GCC 11.3.0]
 executable: /usr/bin/python3
machine: Linux-5.10.0-15-amd64-x86_64-with-glibc2.33

 Python deps:
 affine: 2.3.1
  attrs: None
certifi: 2020.06.20
  click: 8.0.3
  cligj: 0.7.2
 cython: 0.29.30
  numpy: 1.21.5
 snuggs: 1.4.7
 click-plugins: None
 setuptools: 59.6.0

 >  E   ImportError: 
/usr/lib/python3/dist-packages/rasterio/_filepath.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: VSIAllocFilesystemPluginCallbacksStruct


could it be a problem related to a mismatch with the GDAL version?


That's possible, the undefined symbols issue has been reported upstream:

 https://github.com/rasterio/rasterio/issues/2507


Any idea on how to proceed?


Rebuilding rasterio with GDAL 3.5.1 seems to fix the symbol issue, let's 
start there.


Kind Regards,

Bas

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



Bug#1013284: ITA: grub-customizer -- GUI to configure GRUB2 and BURG

2022-07-08 Thread 肖盛文

control: owner -1 atzli...@sina.com
control: retitle -1 ITA: grub-customizer -- GUI to configure GRUB2 and BURG

--
肖盛文 xiao sheng wen
https://www.atzlinux.com 《铜豌豆 Linux》基于 Debian 的 Linux 中文 桌面 操作系统
Debian QA page: https://qa.debian.org/developer.php?login=atzlinux%40sina.com
Debian salsa: https://salsa.debian.org/atzlinux-guest
GnuPG Public Key: 0x00186602339240CB



OpenPGP_signature
Description: OpenPGP digital signature


Bug#1014579: RFP: librust-glium-dev -- Easy-to-use, high-level, OpenGL3+ wrapper.

2022-07-08 Thread Dorota Czaplejewicz
Package: wnpp
Severity: wishlist

* Package name: librust-glium-dev
  Version : 0.31.0
  Upstream Author : glium authors 
* URL : https://github.com/glium/
* License : Apache 2.0
  Programming Lang: Rust
  Description : Easy-to-use, high-level, OpenGL3+ wrapper.

Glium is an intermediate layer between OpenGL and your application. You
still need to manually handle the graphics pipeline, but without having
to use OpenGL's old and error-prone API.

I'm using it for developing an extension to libcamera downstream in
PureOS. Without default features, I don't need glutin (also missing from 
Debian). It's way simpler to use this compared to using the naked OpenGL APIs.
The other missing dependency (required) is genmesh.

I'm not skilled enough to maintain packages.


pgpmIrcQ5hmhR.pgp
Description: OpenPGP digital signature


Bug#1013245: RFS: flask-session/0.3.2-1 [ITP] -- Extension for Flask

2022-07-08 Thread Bastian Germann

Am 08.07.22 um 05:30 schrieb Nilson Silva:

I'm not allowed to create repository in Team python.


Then you are not a team member. You should become one when handing in 
team-maintained packages:
https://salsa.debian.org/python-team/tools/python-modules/blob/master/policy.rst#joining-the-team



Bug#1014577: libsdl1.2: CVE-2021-33657

2022-07-08 Thread Moritz Mühlenhoff
Source: libsdl1.2
X-Debbugs-CC: t...@security.debian.org
Severity: important
Tags: security

Hi,

The following vulnerability was published for libsdl1.2.

CVE-2021-33657[0]:
| There is a heap overflow problem in video/SDL_pixels.c in SDL (Simple
| DirectMedia Layer) 2.x to 2.0.18 versions. By crafting a malicious
| .BMP file, an attacker can cause the application using this library to
| crash, denial of service or Code execution.

This fixed in SDL2 in
https://github.com/libsdl-org/SDL/commit/8c91cf7dba5193f5ce12d06db1336515851c9ee9
 (release-2.0.20)

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-2021-33657
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-33657

Please adjust the affected versions in the BTS as needed.



Bug#1014511: sysvinit: debian/copyright reports incorrect licenses

2022-07-08 Thread binh1.tranhai
Hi Beckert,

>debian/copyright _IS_ the canonical place for copyright statements about 
>debian/*
>So this is wrong and MUST NOT be changed as it would mean we would LOOSE the 
>copyright statements for the remaining files in debian/*.
Thank you for your sharing.

In the original debian/copyright file, debian/* paragraph is missing copyright 
of some files as below:

Files: debian/po/pt_BR.po
Copyright: 2009 Adriano Rafael Gomes , 2009-2020.

Files: debian/po/da.po
Copyright: 2019 sysvinit & Joe Hansen.

Files: debian/po/es.po
Copyright: 2009 Software in the Public Interest

Files: debian/po/sv.po
Copyright: 2012 Martin Bagge 

Files: debian/po/fr.po
Copyright: 2012 Debian French l10n Team

Files: debian/po/ja.po
Copyright: 2009 Hideki Yamane 

I'd like to update some missing copyright of debian/* paragraph from the 
original debian/copyright to new copyright.
I'd like to send you the new copyright without removing debian/* at the 
attachment.

If you have any comment/suggestion about my changes, Please let me know.
Thanks.Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/   
Upstream-Name: sysvinit
Upstream-Contact: sysvinit-de...@nongnu.org
Source: https://download.savannah.gnu.org/releases/sysvinit/

Files: *
Copyright: 2009, 2011, 2012 the sysvinit's copyright holder
   2010 Michael Krapp
   2003 Theodore Ts'o.
   1989, 1991 Free Software Foundation, Inc.
   2011 SuSE LINUX Products GmbH,
   2017-2019 Jesse Smith
   1998 Danek Duvall.
License: GPL-2.0+

Files: debian/*
Copyright: 2015 Adam Conrad 
   2018 Dmitry Bogatov 
   2018 Vincenzo (KatolaZ) Nicosia 
   2006 Henrique de Moraes Holschuh 
   2017 Ian Jackson 
   2014 Robert Millan 
   2014 Thomas Goirand 
   2006 Thomas Hood 
   2015-2016 Andreas Henriksson 
   2011,2016 Ben Hutchings 
   2010-2012 Christian Perrier 
   2015-2016 Martin Pitt 
   2014-2018 Michael Biebl 
   1996-2004 Miquel van Smoorenburg 
   2005-2010, 2014 Petter Reinholdtsen 
   2011-2013 Roger Leigh 
   2006-2007 Steinar H. Gunderson 
   2012-2013 Steve Langasek 
   2009 Adriano Rafael Gomes , 2009-2020.
   2019 sysvinit & Joe Hansen.
   2009 Software in the Public Interest
   2012 Martin Bagge 
   2012 Debian French l10n Team
   2009 Hideki Yamane 
License: GPL-2.0+

Files: contrib/sysd2v.sh
Copyright: 2019 Trek http://www.trek.eu.org/devel/sysd2v
License: GPL-3.0

Files: doc/Install
   man/fstab-decode.8
   man/initctl.5
   src/fstab-decode.c
   src/runlevellog.h
   src/runlevellog.c
Copyright: 2006 Red Hat, Inc.
   2018 Jesse Smith
License: GPL-2.0

Files: debian/po/vi.po
Copyright: 2009 Free Software Foundation, Inc. Clytie Siddall 
, 2009.
License:

License: GPL-2.0+
 This program is free software; you can redistribute it and/or modify it under 
the terms of the GNU General Public License as published by the Free Software 
Foundation; either version 2 of the License, or (at your option) any later 
version.
 .
 This program 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 General Public License for more details.
 .
 You should have received a copy of the GNU General Public License along with 
this program; if not, write to the Free Software Foundation, Inc., 51 Franklin 
Street, Fifth Floor, Boston, MA 02110-1301, USA.
 .
 On Debian systems you can find a local copy of the GNU General Public License
 in /usr/share/common-licenses/GPL-2.

License: GPL-3.0
 This program is free software: you can redistribute it and/or modify it under 
the terms of the GNU General Public License as published by the Free Software 
Foundation, version 3.
 .
 This program 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 General Public License for more details.
 .
 You should have received a copy of the GNU General Public License along with 
this program. If not, see .
 .
 On Debian systems you can find a local copy of the GNU General Public License
 in /usr/share/common-licenses/GPL-3.

License: GPL-2.0
 This program is free software; you can redistribute it and/or modify it under 
the terms of the GNU General Public License as published by the Free Software 
Foundation; version 2.
 .
 This program 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 General Public License for more details.
 .
 You should have received a copy of the GNU General Public L

Bug#1014578: coq-doc: FTBFS on some architectures

2022-07-08 Thread Andreas Beckmann
Source: coq-doc
Version: 8.15.2-2
Severity: important

Hi,

coq-doc FTBFS on some architectures (e.g. arm64, armhf, ppc64el) while
it succeeds on others (e.g. amd64, i386). This is probably a problem in
one of the (transitive) build dependencies, but I don't know how to
pinpoint it. If you reassign this bug, please add an Affects: src:coq-doc.

Running[3870]: (cd _build/default/doc && /usr/bin/env sphinx-build -q -q -b 
html sphinx refman-html)
Running[3871]: (cd _build/default/doc && /usr/bin/env sphinx-build -q -q -b 
latex sphinx refman-pdf)
Command [3870] exited with code 2:
$ (cd _build/default/doc && /usr/bin/env sphinx-build -q -q -b html sphinx 
refman-html)

Extension error:
/build/coq-doc-8.15.2/_build/default/doc/sphinx/proof-engine/ltac.rst:2509: 
Error while sending the following to coqtop:
tac.
  coqtop output:

  Full error text:
Timeout exceeded.

command: /build/coq-doc-8.15.2/_build/install/default/bin/coqtop
args: [b'/build/coq-doc-8.15.2/_build/install/default/bin/coqtop', b'-q', 
b'-color', b'on']
buffer (last 100 chars): ''
before (last 100 chars): ''
after: 
match: None
match_index: None
exitstatus: None
flag_eof: False
pid: 1213
child_fd: 5
closed: False
timeout: 30
delimiter: 
logfile: None
logfile_read: None
logfile_send: None
maxread: 2000
ignorecase: False
searchwindowsize: None
delaybeforesend: 0
delayafterclose: 0.1
delayafterterminate: 0.1
searcher: searcher_re:
0: re.compile('\r\n[^< \r\n]+ < ')
ANTLR runtime and generated code versions disagree: 4.9.1!=4.7.2
Duplicate cmd name:  Extraction
Duplicate exn name:  Not equal
Duplicate exn name:  Not equal (due to universes)
Command [3871] exited with code 2:
$ (cd _build/default/doc && /usr/bin/env sphinx-build -q -q -b latex sphinx 
refman-pdf)

Extension error:
/build/coq-doc-8.15.2/_build/default/doc/sphinx/proof-engine/ltac.rst:2509: 
Error while sending the following to coqtop:
tac.
  coqtop output:

  Full error text:
Timeout exceeded.

command: /build/coq-doc-8.15.2/_build/install/default/bin/coqtop
args: [b'/build/coq-doc-8.15.2/_build/install/default/bin/coqtop', b'-q', 
b'-color', b'on']
buffer (last 100 chars): ''
before (last 100 chars): ''
after: 
match: None
match_index: None
exitstatus: None
flag_eof: False
pid: 4350
child_fd: 5
closed: False
timeout: 30
delimiter: 
logfile: None
logfile_read: None
logfile_send: None
maxread: 2000
ignorecase: False
searchwindowsize: None
delaybeforesend: 0
delayafterclose: 0.1
delayafterterminate: 0.1
searcher: searcher_re:
0: re.compile('\r\n[^< \r\n]+ < ')
ANTLR runtime and generated code versions disagree: 4.9.1!=4.7.2
Duplicate cmd name:  Extraction
Duplicate exn name:  Not equal
Duplicate exn name:  Not equal (due to universes)
make[1]: *** [debian/rules:9: override_dh_auto_build] Error 1
make[1]: Leaving directory '/build/coq-doc-8.15.2'
make: *** [debian/rules:4: binary] Error 2


Andreas


coq-doc_8.15.2-2.log.gz
Description: application/gzip


Bug#1014576: firefox: Crashes on startup (@0x0 | vl_compositor_cleanup_state)

2022-07-08 Thread Paul Menzel

Package: firefox
Version: 102.0-1
Severity: normal


Dear Debian folks,


Two days ago upgrading the packages in Debian sid/unstable also updated 
*firefox* to version 102.0-1. Firefox under GNOME (Wayland) then failed 
to start with a segmentation fault:


```
$ firefox
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: VA-API version 1.15.0
libva info: Trying to open 
/usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so

libva info: Found init function __vaDriverInit_1_15
ATTENTION: default value of option mesa_glthread overridden by environment.
libva info: va_openDriver() returns 0
ExceptionHandler::GenerateDump cloned child 8933
ExceptionHandler::SendContinueSignalToChild sent continue signal to child
ExceptionHandler::WaitForContinueSignal waiting for continue signal...
```

The crash is not showing up in the output of `coredumpctl`, but – after 
getting Firefox running again, it’s listed in `about:crashes`. as crash 
report 23476e43-d4b1-4cf6-994f-03deb0220708 [1].


Upgrading the packages today fixed the issue:

```
$ sudo apt full-upgrade
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Paketaktualisierung (Upgrade) wird berechnet… Fertig
Die folgenden Pakete werden aktualisiert (Upgrade):
  alsa-ucm-conf binutils binutils-common binutils-x86-64-linux-gnu gdb
  gstreamer1.0-pipewire libasound2-plugins libbinutils libctf-nobfd0 
libctf0

  libegl-mesa0 libgbm1 libgl1-mesa-dri libgl1-mesa-dri-dbgsym libglapi-mesa
  libglx-mesa0 libgprofng0 libpipewire-0.3-0 libpipewire-0.3-common
  libpipewire-0.3-modules libspa-0.2-modules pipewire pipewire-bin
  pipewire-pulse signal-desktop xserver-xorg-video-amdgpu
26 aktualisiert, 0 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen noch 117 MB von 180 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 1.504 kB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n]
Holen:1 https://updates.signal.org/desktop/apt xenial/main amd64 
signal-desktop amd64 5.49.0 [117 MB]

Es wurden 7.434 kB in 1 s geholt (5.048 kB/s).
(Lese Datenbank ... 240455 Dateien und Verzeichnisse sind derzeit 
installiert.)

Vorbereitung zum Entpacken von .../00-alsa-ucm-conf_1.2.7.1-1_all.deb ...
Entpacken von alsa-ucm-conf (1.2.7.1-1) über (1.2.6.3-1) ...
Vorbereitung zum Entpacken von 
.../01-libgprofng0_2.38.50.20220707-1_amd64.deb .

..
Entpacken von libgprofng0:amd64 (2.38.50.20220707-1) über 
(2.38.50.20220629-4) .

..
Vorbereitung zum Entpacken von 
.../02-libctf0_2.38.50.20220707-1_amd64.deb ...
Entpacken von libctf0:amd64 (2.38.50.20220707-1) über 
(2.38.50.20220629-4) ...
Vorbereitung zum Entpacken von 
.../03-libctf-nobfd0_2.38.50.20220707-1_amd64.deb

 ...
Entpacken von libctf-nobfd0:amd64 (2.38.50.20220707-1) über 
(2.38.50.20220629-4)

 ...
Vorbereitung zum Entpacken von 
.../04-binutils-x86-64-linux-gnu_2.38.50.20220707

-1_amd64.deb ...
Entpacken von binutils-x86-64-linux-gnu (2.38.50.20220707-1) über 
(2.38.50.20220

629-4) ...
Vorbereitung zum Entpacken von 
.../05-libbinutils_2.38.50.20220707-1_amd64.deb .

..
Entpacken von libbinutils:amd64 (2.38.50.20220707-1) über 
(2.38.50.20220629-4) .

..
Vorbereitung zum Entpacken von 
.../06-binutils_2.38.50.20220707-1_amd64.deb ...

Entpacken von binutils (2.38.50.20220707-1) über (2.38.50.20220629-4) ...
Vorbereitung zum Entpacken von 
.../07-binutils-common_2.38.50.20220707-1_amd64.d

eb ...
Entpacken von binutils-common:amd64 (2.38.50.20220707-1) über 
(2.38.50.20220629-

4) ...
Vorbereitung zum Entpacken von .../08-gdb_12.1-3_amd64.deb ...
Entpacken von gdb (12.1-3) über (12.1-2) ...
Vorbereitung zum Entpacken von .../09-pipewire-pulse_0.3.54-1_amd64.deb ...
Entpacken von pipewire-pulse (0.3.54-1) über (0.3.53-1) ...
Vorbereitung zum Entpacken von 
.../10-gstreamer1.0-pipewire_0.3.54-1_amd64.deb .

..
Entpacken von gstreamer1.0-pipewire:amd64 (0.3.54-1) über (0.3.53-1) ...
Vorbereitung zum Entpacken von 
.../11-libpipewire-0.3-modules_0.3.54-1_amd64.deb

 ...
Entpacken von libpipewire-0.3-modules:amd64 (0.3.54-1) über (0.3.53-1) ...
Vorbereitung zum Entpacken von .../12-pipewire_0.3.54-1_amd64.deb ...
Entpacken von pipewire:amd64 (0.3.54-1) über (0.3.53-1) ...
Vorbereitung zum Entpacken von .../13-pipewire-bin_0.3.54-1_amd64.deb ...
Entpacken von pipewire-bin (0.3.54-1) über (0.3.53-1) ...
Vorbereitung zum Entpacken von 
.../14-libpipewire-0.3-0_0.3.54-1_amd64.deb ...

Entpacken von libpipewire-0.3-0:amd64 (0.3.54-1) über (0.3.53-1) ...
Vorbereitung zum Entpacken von 
.../15-libspa-0.2-modules_0.3.54-1_amd64.deb ...

Entpacken von libspa-0.2-modules:amd64 (0.3.54-1) über (0.3.53-1) ...
Vorbereitung zum Entpacken von 
.../16-libasound2-plugins_1.2.7.1-1_amd64.deb ...

Entpacken von libasound2-plugins:amd64 (1.2.7.1-1) über (1.2.6-1+b1) ...
Vorbereitung zum Entpacken von .../17-libegl-mesa0_22.1.3-1_amd64.deb ...
Entpacken von libegl-mesa0:amd64 (22.1.3-1) über (22.0.5-1) ...
Vor

Bug#1014452: pyresample: Test failures with rasterio 1.3.0

2022-07-08 Thread Antonio Valentino

Dear Bas,

On Wed, 06 Jul 2022 13:04:41 +0200 Bas Couwenberg  
wrote:

Source: pyresample
Version: 1.23.0-1
Severity: serious
Tags: ftbfs upstream

Dear Maintainer,

Your package FTBFS with rasterio 1.3.0 due to test failures which also affect 
the autopkgtests:

  TestMisc.test_get_area_def_from_raster 

 
 self = 
 
 def test_get_area_def_from_raster(self):

 from affine import Affine
 >   from rasterio.crs import CRS as RCRS
 
 /usr/lib/python3/dist-packages/pyresample/test/test_utils.py:441: 
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
 /usr/lib/python3/dist-packages/rasterio/__init__.py:14: in 

 from rasterio.crs import CRS
 rasterio/crs.pyx:1: in init rasterio.crs
 ???
 rasterio/_base.pyx:22: in init rasterio._base
 ???
 /usr/lib/python3/dist-packages/rasterio/dtypes.py:10: in 
 from rasterio.env import GDALVersion
 /usr/lib/python3/dist-packages/rasterio/env.py:16: in 
 from rasterio._env import (
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
 
 >   ???

 E   ImportError: 
/usr/lib/python3/dist-packages/rasterio/_filepath.cpython-39-x86_64-linux-gnu.so:
 undefined symbol: VSIAllocFilesystemPluginCallbacksStruct
 
 rasterio/_env.pyx:1: ImportError

 ___ TestMisc.test_get_area_def_from_raster_extracts_proj_id 

 
 self = 
 
 def test_get_area_def_from_raster_extracts_proj_id(self):

 >   from rasterio.crs import CRS as RCRS
 
 /usr/lib/python3/dist-packages/pyresample/test/test_utils.py:465: 
 _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
 
 """Rasterio"""
 
 from collections import namedtuple

 from contextlib import ExitStack
 import logging
 from logging import NullHandler
 import os
 import warnings
 
 import rasterio._loading

 >   with rasterio._loading.add_gdal_dll_directories():
 E   AttributeError: partially initialized module 'rasterio' has no attribute 
'_loading' (most likely due to a circular import)

 /usr/lib/python3/dist-packages/rasterio/__init__.py:11: AttributeError


I'm not able to reproduce the issue in sid.
Both the package build and autopkgtest seem to work with rasterionv1.3.0

Also rasterio seems to properly load the '_loading' module:

$ python3

Python 3.10.5 (main, Jun  8 2022, 09:26:22) [GCC 11.3.0] on linux

Type "help", "copyright", "credits" or "license" for more information.

>>> import rasterio

>>> rasterio.__version__

'1.3.0'

>>> rasterio._loading

'/usr/lib/python3/dist-packages/rasterio/_loading.py'>




I see

>  E   ImportError: 
/usr/lib/python3/dist-packages/rasterio/_filepath.cpython-39-x86_64-linux-gnu.so: 
undefined symbol: VSIAllocFilesystemPluginCallbacksStruct


could it be a problem related to a mismatch with the GDAL version?

Any idea on how to proceed?


kind regards
--
Antonio Valentino