Bug#1082747: cod-tools: FTBFS (only) on riscv64

[Bernhard Übelacker]

On Fri, 27 Sep 2024 19:25:10 +0200 Aurelien Jarno  wrote:


TIL disorderfs. I have also been able to reproduce it with disorderfs.
In addition knowing the root of the issue, I have been able to
reproduce the issue on a riscv64 machine using tmpfs as a build
directory, just like on the build daemons.

> Didn't have time to debug it further yet.
> 
> Hope this helps,


Definitely, thanks a lot!




Hello everyone,
I am also amazed, I did not know about disorderfs before.

I could reproduce the failure with rr-debugger on top of
a disorderfs and compared it with a successful run (both on amd64).
In the unsuccessful run the iteration through the
predicted readdir does not return the expected file [1].

So in the bad case readdir of directory src/components/codcif
does "just" not return the file "cif_list_tags" in my example
and at least for the disorderfs case.

Even more bad is this file looks like it was created just before [2].
So does disorderfs some caching, which causes this readdir
not to return the already created file?
Or is there some caching on kernel side involved as this affects
also tmpfs (not just fuse)?

I would be happy to debug this further,
with some pointers to which parts are of interest...

Kind regard,
Bernhard




[1]
Breakpoint 22, dir_contents_file_exists_p (dir=0x55c8aa58a3c0, 
filename=filename@entry=0x55c8aba3cc66 "cif_list_tags") at ../../src/dir.c:713
713   if (!REAL_DIR_ENTRY (d))
7: x/i $pc
=> 0x55c8872cce20 : cmpq   $0x0,(%rax)
9: (char*)d->d_name = 0x55c8aa8abba3 "cif_options.c"
(rr) bt
#0  dir_contents_file_exists_p (dir=0x55c8aa58a3c0, 
filename=filename@entry=0x55c8aba3cc66 "cif_list_tags") at ../../src/dir.c:713
#1  0x55c8872cd2a1 in dir_contents_file_exists_p (filename=0x55c8aba3cc66 
"cif_list_tags", dir=) at ../../src/dir.c:849
#2  dir_file_exists_p (filename=0x55c8aba3cc66 "cif_list_tags", dirname=) at ../../src/dir.c:774
#3  file_exists_p (name=0x55c8aba3cc50 "src/components/codcif/cif_list_tags") 
at ../../src/dir.c:851
#4  0x55c8872d5f45 in pattern_search (file=file@entry=0x55c8aa595710, 
archive=archive@entry=0, depth=depth@entry=5, recursions=recursions@entry=0) at 
../../src/implicit.c:758
#5  0x55c8872d6aa3 in try_implicit_rule (file=file@entry=0x55c8aa595710, 
depth=depth@entry=5) at ../../src/implicit.c:45
#6  0x55c8872e49ac in update_file_1 (depth=, 
file=0x55c8aa595710) at ../../src/remake.c:506
#7  update_file (file=, depth=) at 
../../src/remake.c:336
#8  0x55c8872e5875 in check_dep (file=0x55c8aa595710, depth=4, 
depth@entry=3, this_mtime=this_mtime@entry=1, 
must_make_ptr=must_make_ptr@entry=0x7ffcf9a5c664) at ../../src/remake.c:1024
#9  0x55c8872e4676 in update_file_1 (depth=, 
file=0x55c8aa5958f0) at ../../src/remake.c:572
#10 update_file (file=, depth=) at 
../../src/remake.c:336
#11 0x55c8872e5875 in check_dep (file=0x55c8aa5958f0, depth=2, 
depth@entry=1, this_mtime=this_mtime@entry=1, 
must_make_ptr=must_make_ptr@entry=0x7ffcf9a5c7a4) at ../../src/remake.c:1024
#12 0x55c8872e4676 in update_file_1 (depth=, 
file=0x55c8aa589db0) at ../../src/remake.c:572
#13 update_file (file=file@entry=0x55c8aa589db0, depth=) at 
../../src/remake.c:336
#14 0x55c8872e5cd4 in update_goal_chain (goaldeps=) at 
../../src/remake.c:151
#15 0x55c8872c9ef5 in main (argc=, argv=, 
envp=) at ../../src/main.c:2589
(rr) print *dir->dirstream
$37 = {fd = 4, lock = 0, allocation = 32768, size = 1632, offset = 920, filepos = 1000, 
errcode = 0, data = 0x55c8aa8ab820 "1'\002"}
(rr)



[2]
...
sed 's/@VERSION@/3.10.0/' version.hin > version.h
gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/home/benutzer/source/cod-tools/tryC-disorderfs/cod-tools-3.10.0+dfsg=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wall -Wsign-compare -g -O3 -funroll-loops -fomit-frame-pointer -foptimize-register-move 
-DYYDEBUG=1 -D_YACC_ -I. -I../../externals/cexceptions -I../../externals/getoptions -fPIC 
-DSVN_VERSION="\"10068\""  -Wl,-z,relro -Wl,-z,now -o cif_list_tags 
programs/cif_list_tags.c obj/cif2_grammar.tab.o obj/cif_grammar.tab.o lib/libcodcif.a 
../../externals/cexceptions/lib/libcexceptions.a ../../externals/getoptions/lib/libgetoptions.a 
version.h -lm
gcc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration 
-ffile-prefix-map=/home/benutzer/source/cod-tools/tryC-disorderfs/cod-tools-3.10.0+dfsg=. 
-fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -fcf-protection 
-Wall -Wsign-compare -g -O3 -funroll-loops -fomit-frame-pointer -foptimize-register-move 
-DYYDEBUG=1 -D_YACC_ -I. -I../../externals/cexceptions -I../../externals/getoptions -fPIC 
-DSVN_VERSION="\"10068\""  -Wl,-z,relro -Wl,-z,now -o 

Bug#1079025: freerdp2: failing autopkgtests

[Bernhard Übelacker]

On Mon, 19 Aug 2024 07:10:13 +0200 Sebastian Ramacher  
wrote:

Source: freerdp2
Version: 2.11.7+dfsg1-2
Severity: serious
X-Debbugs-Cc: sramac...@debian.org

https://ci.debian.net/packages/f/freerdp2/testing/amd64/49289917/

 58s autopkgtest [21:09:03]: test compare: [---
 58s + screenshot=xrdp-screenshot.png
 58s + magickout=match-matrix
 58s + dirname 
/tmp/autopkgtest-lxc.n8yozz_a/downtmp/build.bj0/src/debian/tests/compare
 58s + testdir=/tmp/autopkgtest-lxc.n8yozz_a/downtmp/build.bj0/src/debian/tests
 58s + sudo systemctl start xrdp
 58s + xvfb-run -l 
/tmp/autopkgtest-lxc.n8yozz_a/downtmp/build.bj0/src/debian/tests/connect-and-capture
 xrdp-screenshot.png
 58s /usr/bin/xvfb-run: 184: 
/tmp/autopkgtest-lxc.n8yozz_a/downtmp/build.bj0/src/debian/tests/connect-and-capture:
 Permission denied
 58s + compare -metric RMSE -subimage-search xrdp-screenshot.png 
/usr/share/xrdp/xrdp_logo.bmp png:match-matrix
 58s compare-im6.q16: unable to open image `xrdp-screenshot.png': No such file 
or directory @ error/blob.c/OpenBlob/2967.
 58s + grep -qi #FF
 58s + convert match-matrix-1 -threshold 95% txt:
 58s convert-im6.q16: unable to open image `match-matrix-1': No such file or 
directory @ error/blob.c/OpenBlob/2967.
 58s convert-im6.q16: no decode delegate for this image format `' @ 
error/constitute.c/ReadImage/581.
 58s convert-im6.q16: no images defined `txt:' @ 
error/convert.c/ConvertImageCommand/3234.
 58s + printf %s\n Imagemagick did not find any occurence of the XRDP logo 
inside the screenshot of the remote desktop. This test therefore failed.
 58s + exit 2
 58s Imagemagick did not find any occurence of the XRDP
 58s logo inside the screenshot of the remote desktop.
 58s This test therefore failed.
 59s autopkgtest [21:09:04]: test compare: ---]
 59s compare  FAIL non-zero exit status 2

The change in -2 not enough to fix the failure.

Cheers
--
Sebastian Ramacher





Dear Maintainer,
I tried to have a look and I think there are multiple issues here.

One is the connect-and-capture file is missing the execute bit,
therefore the error "Permission denied".

Second I received a interactive question "Do you trust the above certificate? 
(Y/T/N)".
This can be avoided by the "/cert-tofu" parameter.

Third the compare does not find the logo in the screenshot of the login screen.
I could convince imagemagick to find it by resizeing the search logo to 50%.

And the fourth issue is the size of the screenshot makes the search taking 
quite long.
To get the screenshot size down the screen size could be given to the
xvfb-run command (xvfb-run --server-args=-screen 0 640x480x24).
Or another imagemagick call can automatically remove the border (the "mogrify" 
call below).

With following modifications I think the autopkgtest should be able pass.

Kind regards,
Bernhard


diff --git a/debian/tests/compare b/debian/tests/compare
index 9db5cd6..5dd3d31 100644
--- a/debian/tests/compare
+++ b/debian/tests/compare
@@ -12,6 +12,13 @@ sudo systemctl start xrdp
 # login screen.
 xvfb-run -l "$testdir/connect-and-capture" "$screenshot"
 
+# Try to remove the background to leave just the login window in the image

+cp -a "$screenshot" "${screenshot}.before.mogrify.png"
+mogrify -fuzz 4% -define trim:percent-background=0% -trim +repage -format png 
"$screenshot"
+
+# Resize the search image to match nearly the really displayed size
+convert -resize 50% /usr/share/xrdp/xrdp_logo.bmp xrdp_logo_50percent.png
+
 # Confirm that the XRDP logo is in the log in screen (so as to confirm that the
 # login screen is really there).
 # 
https://stackoverflow.com/questions/31867093/how-to-search-an-image-for-subimages-using-linux-console
@@ -21,7 +28,7 @@ xvfb-run -l "$testdir/connect-and-capture" "$screenshot"
 # will fail but we don't need to check that specifically, because so
 # will the if below.
 compare -metric RMSE -subimage-search \
-  "$screenshot" /usr/share/xrdp/xrdp_logo.bmp png:"$magickout"
+  "$screenshot" xrdp_logo_50percent.png png:"$magickout"
 # In case of match, output will be like
 # "520,347: (255,255,255)  #FF  gray(255)"
 # in which the first field is the coordinates of the match.
diff --git a/debian/tests/connect-and-capture b/debian/tests/connect-and-capture
old mode 100644
new mode 100755
index 9700676..5b98fd7
--- a/debian/tests/connect-and-capture
+++ b/debian/tests/connect-and-capture
@@ -1,4 +1,4 @@
 #!/bin/sh
-xfreerdp /f /v:localhost:3389 /p: /u: /d: &
+xfreerdp /f /v:localhost:3389 /p: /u: /d: /cert-tofu &
 sleep 12
 import -window root "$1"

Bug#1079572: libfabric ftbfs on i386

[Bernhard Übelacker]

On Sat, 24 Aug 2024 21:05:54 +0200 Matthias Klose  wrote:

Package: src:libfabric
Version: 1.17.0-3
Severity: serious
Tags: sid trixie

libfabric ftbfs at least on i386, there might be more follow-up errors:

[...]


prov/hook/src/hook_domain.c:124:54: error: passing argument 2 of 
‘domain->base_ops_flow_ctrl->set_send_handler’ from incompatible pointer 
type [-Wincompatible-pointer-types]
   124 | 
hook_credit_handler);
   | 
^~~



Dear Maintainer,
this seems to be reported upstream in [1] and [2].
The first one got fixed in [3], but the other seems unresolved.

Kind regards,
Bernhard


[1] https://github.com/ofiwg/libfabric/issues/7860
[2] https://github.com/ofiwg/libfabric/issues/9763
[3] 
https://github.com/ofiwg/libfabric/commit/cd607326318534eca4763f29882ada90c5935799

Bug#1057551: Chance for re-entry in testing?

[Bernhard]

Hello Dmitry

Thank you for maintaining this package.

At the homepage:
https://www.dxx-rebirth.com/

The original maintainer retired this project :-(
But there exists a C++ fork on Github:
https://github.com/dxx-rebirth/dxx-rebirth

Can you please, please try to fix this FTBFS?

Thank you for your support.
Bernhard

Bug#1079588: mandos-client postrm purge can mysteriously fail

[Bernhard Übelacker]

On Sun, 25 Aug 2024 00:16:33 +0200 Ben Hutchings  wrote:

Package: mandos-client
Version: 1.8.16-1
Severity: serious

mandos-client's postrm script can fail on purge with no obvious error
message.  dpkg reports that it exited with error code 128 but it's not
clear why.  I can reproduce this in a bookworm/amd64 or unstable/amd64
build chroot by running:

apt install -y mandos-client linux-image-amd64
apt purge -y mandos-client

Ben.




Dear Maintainer,
I just tried to get some more info about this.

By adding a "set -x" at the top of the postrm script I could watch
which commands get executed [2].
At the end it looks like the output of the earlier update-initramfs
gets into stdin of the db_purge call later.

At least when redirecting stdout to stderr [1] of the update-initramfs call
the removal completes without error.

Kind regards,
Bernhard




[1]
--- orig/mandos-client.postrm   2024-04-22 21:13:43.0 +0200
+++ redirect/mandos-client.postrm   2024-09-11 09:10:06.222806231 +0200
@@ -34,3 +34,3 @@ update_initramfs()
 if command -v update-initramfs >/dev/null; then
-   update-initramfs -k all -u
+   update-initramfs -k all -u 1>&2
 elif command -v dracut >/dev/null; then
EOF




[2]
root@debian:~# LANG=C apt purge -y mandos-client
The following packages were automatically installed and are no longer required:
  cryptsetup  cryptsetup-initramfs  libavahi-common-data  libavahi-common3  
libavahi-core7  libgpgme11t64  libnl-3-200  libnl-route-3-200  ssh
Use 'apt autoremove' to remove them.

REMOVING:
  mandos-client*

Summary:
  Upgrading: 0, Installing: 0, Removing: 1, Not Upgrading: 0
  Freed space: 577 kB

(Reading database ... 38713 files and directories currently installed.)
Removing mandos-client (1.8.16-1.2) ...
+ set -e
+ update_initramfs
+ command -v update-initramfs
+ update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-6.10.6-amd64
+ [ remove = purge ]
+ exit 0
(Reading database ... 38657 files and directories currently installed.)
Purging configuration files for mandos-client (1.8.16-1.2) ...
+ set -e
+ shred --remove /etc/keys/mandos/seckey.txt
+ rm --force /etc/mandos/plugin-runner.conf /etc/keys/mandos/pubkey.txt 
/etc/keys/mandos/seckey.txt /etc/keys/mandos/tls-privkey.pem 
/etc/keys/mandos/tls-pubkey.pem /etc/keys/mandos/dhparams.pem
+ update_initramfs
+ command -v update-initramfs
+ update-initramfs -k all -u
update-initramfs: Generating /boot/initrd.img-6.10.6-amd64
+ [ purge = purge ]
+ [ -e /usr/share/debconf/confmodule ]
+ . /usr/share/debconf/confmodule
+ [ !  ]
+ PERL_DL_NONLAZY=1
+ export PERL_DL_NONLAZY
+ [  ]
+ exec /usr/share/debconf/frontend /var/lib/dpkg/info/mandos-client.postrm purge
+ set -e
+ shred --remove /etc/keys/mandos/seckey.txt
+ :
+ rm --force /etc/mandos/plugin-runner.conf /etc/keys/mandos/pubkey.txt 
/etc/keys/mandos/seckey.txt /etc/keys/mandos/tls-privkey.pem 
/etc/keys/mandos/tls-pubkey.pem /etc/keys/mandos/dhparams.pem
+ update_initramfs
+ command -v update-initramfs
+ update-initramfs -k all -u
+ [ purge = purge ]
+ [ -e /usr/share/debconf/confmodule ]
+ . /usr/share/debconf/confmodule
+ [ ! 1 ]
+ [ -z  ]
+ exec
+ [  ]
+ exec
+ DEBCONF_REDIR=1
+ export DEBCONF_REDIR
+ db_purge
+ _db_cmd PURGE
+ _db_internal_IFS=

+ IFS=
+ printf %s\n PURGE
+ IFS=

+ read -r _db_internal_line
+ IFS=

+ RET=20 Unsupported command "update-initramfs:" (full line was "update-initramfs: 
Generating /boot/initrd.img-6.10.6-amd64") received from confmodule.
+ return 20
dpkg: error processing package mandos-client (--purge):
 installed mandos-client package post-removal script subprocess returned error 
exit status 128
Errors were encountered while processing:
 mandos-client
Error: Sub-process /usr/bin/dpkg returned an error code (1)
root@debian:~#

Bug#1076933: win32-loader: FTBFS: Error: Can't find IDC_LIST1 (1016) in the custom UI!

[Bernhard Übelacker]

Control: tag + upstream fixed-upstream

Another short addition:
A patch got discussed and commited upstream:

https://sourceware.org/pipermail/binutils/2024-August/136268.html
https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=8c1cd8603443ffeee6e9cc97b738527ea1e2b3e5

Bug#1077047: numba: FTBFS when running tests: Fatal Python error: Segmentation fault [arm64, mips64el]

[Bernhard Übelacker]

The package fails to build from source on arm64 and mips64el with
multiple test failures that look similar at first glance. For example,
on arm64:

Fatal Python error: Segmentation fault




Hello,
I tried to collect some more information.

I could just follow that far as a bogus pointer
gets written in NRT_MemInfo_new_varsize_dtor,
which gets later called in nrt_varsize_dtor.

Unfortunately I cannot see where this value originates from.
Below an example debugging session, after a failing build on arm64 hardware.
In below example the bogus pointer has a value of 0xf9000be0d10083ff.

Kind regards,
Bernhard




benutzer@chroot-13-trixie-arm64:~/source/numba/try1/numba-0.59.1+dfsg$ gdb -q 
--args python3.12
Reading symbols from python3.12...
Reading symbols from 
/usr/lib/debug/.build-id/d9/3d40f59d70863566375339beb0f380251a6436.debug...
(gdb) directory /home/benutzer/source/numba/try1/numba-0.59.1+dfsg
Source directories searched: 
/home/benutzer/source/numba/try1/numba-0.59.1+dfsg:$cdir:$cwd
(gdb) set width 0
(gdb) set pagination off
(gdb) set environment 
PYTHONPATH=/home/benutzer/source/numba/try1/numba-0.59.1+dfsg/debian/python3-numba/usr/lib/python3.12/dist-packages:/home/benutzer/source/numba/try1/numba-0.59.1+dfsg/.pybuild/cpython3_3.12_numba/build
(gdb) set environment NUMBA_DEBUGINFO=1
(gdb) set environment NUMBA_OPT=0
(gdb) b nrt.cpp:177
No source file named nrt.cpp.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (nrt.cpp:177) pending.
(gdb) b nrt_varsize_dtor
Function "nrt_varsize_dtor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (nrt_varsize_dtor) pending.
(gdb) run numba/tests/test_array_iterators.py
Starting program: /usr/bin/python3.12 numba/tests/test_array_iterators.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/aarch64-linux-gnu/libthread_db.so.1".

Breakpoint 1.4, NRT_MemInfo_init (mi=0x2056870, data=0x18d2510, size=0, 
dtor=0xf5901f28 , dtor_info=0xe93ae7f0, 
external_allocator=0x0) at numba/core/runtime/nrt.cpp:177
177 if (TheMSys.stats.enabled)
(gdb) disa 1.1
(gdb) disa 1.2
(gdb) disa 1.3
(gdb) disa 1.4
(gdb) disa 1.5
(gdb) disa 1.6
(gdb) disa 1.7
(gdb) disa 1.9
(gdb) disa 1.10
(gdb) disa 1.11
(gdb) disa 1.12
(gdb) ignore 1 1
Will ignore next crossing of breakpoint 1.
(gdb) ignore 2 1
Will ignore next crossing of breakpoint 2.
(gdb) cont
Continuing.
..
Breakpoint 1.8, NRT_MemInfo_init (mi=0x29cdbd0, data=0x29bfd90, size=24, 
dtor=, dtor_info=0x0, external_allocator=0x0) at 
numba/core/runtime/nrt.cpp:177
177 if (TheMSys.stats.enabled)
(gdb) print mi
$1 = (NRT_MemInfo *) 0x29cdbd0
(gdb) print *mi
$2 = {refct = std::atomic = { 1 }, dtor = 0xf5903580 
, dtor_info = 0x0, data = 0x29bfd90, size = 
24, external_allocator = 0x0}
(gdb) print &mi->dtor_info
$3 = (void **) 0x29cdbe0
(gdb) watch *(void **) 0x29cdbe0
Hardware watchpoint 3: *(void **) 0x29cdbe0
(gdb) display *(NRT_MemInfo *) 0x29cdbd0
1: *(NRT_MemInfo *) 0x29cdbd0 = {refct = std::atomic = { 1 }, dtor = 
0xf5903580 , dtor_info = 0x0, data = 
0x29bfd90, size = 24, external_allocator = 0x0}
(gdb) cont
Continuing.

Hardware watchpoint 3: *(void **) 0x29cdbe0

Old value = (void *) 0x0
New value = (void *) 0xf9000be0d10083ff
NRT_MemInfo_new_varsize_dtor (size=24, dtor=0xf9000be0d10083ff) at 
numba/core/runtime/nrt.cpp:472
472 return mi;
1: *(NRT_MemInfo *) 0x29cdbd0 = {refct = std::atomic = { 1 }, dtor = 
0xf5903580 , dtor_info = 
0xf9000be0d10083ff, data = 0x29bfd90, size = 24, external_allocator = 0x0}
(gdb) bt 6
#0  NRT_MemInfo_new_varsize_dtor (size=24, dtor=0xf9000be0d10083ff) at 
numba/core/runtime/nrt.cpp:472
#1  0xf6dbd0f0 in 
numba::cpython::listobj::list_constructor::_3clocals_3e::list_impl[abi:v39][abi:c8tJTC_2fWQI8IW1CiAAYKPM6RBFDjESZRVAJmaQIA](iter_28array_28int64_2c_201d_2c_20A_29_29)
 () at listobj.py:469
#2  0xf6db91f4 in 
__main__::array_iter_items[abi:v38][abi:c8tJTC_2fWwGaMLShh6CjAIxrKR0t9qKIYaQ0qDQwmMEsTAA_3d_3d](Array) (arr=...) at test_array_iterators.py:18
#3  0xf6db9540 in 
cpython::__main__::array_iter_items[abi:v38][abi:c8tJTC_2fWwGaMLShh6CjAIxrKR0t9qKIYaQ0qDQwmMEsTAA_3d_3d](Array) ()
#4  0xeb133e20 in call_cfunc (self=0xf6db9380 
)>, locals=, cfunc=, args=, kws=) at 
numba/_dispatcher.cpp:745
#5  Dispatcher_call (self=self@entry=0xe7e9d090, 
args=args@entry=(,), kws=kws@entry=0x0) 
at numba/_dispatcher.cpp:1037
(More stack frames follow...)
(gdb) up
#1  0xf6dbd0f0 in 
numba::cpython::listobj::list_constructor::_3clocals_3e::list_impl[abi:v39][abi:c8tJTC_2fWQI8IW1CiAAYKPM6RBFDjESZRVAJmaQIA](iter_28array_28int64_2c_201d_2c_20A_29_29)
 () at listobj.py:469
469 res = []
(gdb) list
464
465 @lower_builtin(list, types.IterableType)
466 def list_constructor(context, builder, sig, args):
467
468 def list_impl(iterable):
469 res =

Bug#1076933: win32-loader: FTBFS: Error: Can't find IDC_LIST1 (1016) in the custom UI!

[Bernhard Übelacker]

But I am not completely sure if the generated instdlg.o
is valid and expected, and nsis needs to be able to handle it.
Or GNU assembler should really generate object files in the old layout?



Just a short addition:

If GNU assembler and nsis is found to be working as expected
and there exists no other notation to create wide strings,
attached patch might be to considered for win32-loader,
which avoids the irpc by embedding the null bytes manually
in the ascii strings to mimic a wide string.

Kind regards,
Bernhard--- helpers/instdlg/instdlg.s.orig	2024-08-12 00:07:12.0 +0200
+++ helpers/instdlg/instdlg.s	2024-08-12 00:23:11.0 +0200
@@ -50,13 +50,6 @@ _WinMainCRTStartup:
 .set	WS_VISIBLE,		0x1000
 .set	WS_CHILD,		0x4000
 
-.macro WIDESTRING String
-.irpcCharacter,"\String"
-.asciz  "\Character"
-.endr
-.short 	0
-.endm
-
 .macro	IMAGE_RESOURCE_DIRECTORY Characteristics=0, TimeDateStamp=0, MajorVersion=0, MinorVersion=0, NumberOfNamedEntries=0, NumberOfIdEntries=0
 .long	\Characteristics
 .long	\TimeDateStamp
@@ -78,7 +71,7 @@ _WinMainCRTStartup:
 .long	\Reserved
 .endm
 
-.macro	DLGTEMPLATEEX_WITH_FONT dlgVer=1, signature=0x, helpID=0, exStyle=0, style=0, cDlgItems=0, x=0, y=0, cx=0, cy=0, menu=0, windowClass=0, title="", pointsize=0, weight=0, italic=0, charset=0, typeface=""
+.macro	DLGTEMPLATEEX_WITH_FONT dlgVer=1, signature=0x, helpID=0, exStyle=0, style=0, cDlgItems=0, x=0, y=0, cx=0, cy=0, menu=0, windowClass=0, title="\0", pointsize=0, weight=0, italic=0, charset=0, typeface="\0"
 .short	\dlgVer
 .short	\signature
 .long	\helpID
@@ -91,15 +84,15 @@ _WinMainCRTStartup:
 .short	\cy
 .short	\menu
 .short	\windowClass
-WIDESTRING "\title"
+.asciz	"\title"
 .short	\pointsize
 .short	\weight
 .byte	\italic
 .byte	\charset
-WIDESTRING "\typeface"
+.asciz	"\typeface"
 .endm
 
-.macro	DLGITEMTEMPLATEEX helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, windowClass=0, title="", extraCount=0
+.macro	DLGITEMTEMPLATEEX helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, windowClass=0, title="\0", extraCount=0
 .long	\helpID
 .long	\exStyle
 .long	\style
@@ -110,11 +103,11 @@ WIDESTRING "\typeface"
 .long	\id
 .short	0x
 .short	\windowClass
-WIDESTRING "\title"
+.asciz	"\title"
 .short	\extraCount
 .endm
 
-.macro	DLGITEMTEMPLATEEX_SZCLASS helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, windowClass="", title="", extraCount=0
+.macro	DLGITEMTEMPLATEEX_SZCLASS helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, windowClass="\0", title="\0", extraCount=0
 .long	\helpID
 .long	\exStyle
 .long	\style
@@ -123,17 +116,19 @@ WIDESTRING "\title"
 .short	\cx
 .short	\cy
 .long	\id
-WIDESTRING "\windowClass"
-WIDESTRING "\title"
+.asciz	"\windowClass"
+.asciz	"\title"
 .short	\extraCount
 .endm
 
-.macro	DLGITEMTEMPLATEEX_PROGRESSBAR helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, title="", extraCount=0
-DLGITEMTEMPLATEEX_SZCLASS helpID=\helpID, exStyle=\exStyle, style=\style, x=\x, y=\y, cx=\cx, cy=\cy, id=\id, windowClass="MSCTLS_PROGRESS32", title=\title, extraCount=\extraCount
+.macro	DLGITEMTEMPLATEEX_PROGRESSBAR helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, title="\0", extraCount=0
+DLGITEMTEMPLATEEX_SZCLASS helpID=\helpID, exStyle=\exStyle, style=\style, x=\x, y=\y, cx=\cx, cy=\cy, id=\id, windowClass="M\0S\0C\0T\0L\0S\0_\0P\0R\0O\0G\0R\0E\0S\0S\0\x33\0\x32\0\0", title=\title, extraCount=\extraCount
+/*windowClass="MSCTLS_PROGRESS32"*/
 .endm
 
-.macro	DLGITEMTEMPLATEEX_LISTVIEW helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, title="", extraCount=0
-DLGITEMTEMPLATEEX_SZCLASS helpID=\helpID, exStyle=\exStyle, style=\style, x=\x, y=\y, cx=\cx, cy=\cy, id=\id, windowClass="SYSLISTVIEW32", title=\title, extraCount=\extraCount
+.macro	DLGITEMTEMPLATEEX_LISTVIEW helpID=0, exStyle=0, style=0, x=0, y=0, cx=0, cy=0, id=0, title="\0", extraCount=0
+DLGITEMTEMPLATEEX_SZCLASS helpID=\helpID, exStyle=\exStyle, style=\style, x=\x, y=\y, cx=\cx, cy=\cy, id=\id, windowClass="S\0Y\0S\0L\0I\0S\0T\0V\0I\0E\0W\0\x33\0\x32\0\0", title=\title, extraCount=\extraCount
+/*windowClass="SYSLISTVIEW32"*/
 .endm
 
 .section .rsrc
@@ -158,7 +153,8 @@ rsrc_dialog_content:
 
 .align 4, 0
 rsrc_dialog_data:
-	DLGTEMPLATEEX_WITH_FONT style=(DS_FIXEDSYS|DS_SETFONT|DS_CONTROL|WS_CHILD), cDlgItems=6, x=0, y=0, cx=300, cy=140, pointsize=8, charset=1, typeface="MS Shell Dlg"
+	DL

Bug#1076933: win32-loader: FTBFS: Error: Can't find IDC_LIST1 (1016) in the custom UI!

[Bernhard Übelacker]

On Wed, 24 Jul 2024 12:50:23 +0200 Santiago Vila  wrote:

Package: src:win32-loader
Version: 0.10.6
Severity: serious
Tags: ftbfs



During a rebuild of all packages in unstable, your package failed to build:



i686-w64-mingw32-as --defsym IMAGE_BASE=0x40 -march=i486  -o instdlg.o 
/<>/helpers/instdlg/instdlg.s
/<>/helpers/instdlg/instdlg.s: Assembler messages:
/<>/helpers/instdlg/instdlg.s:161: Warning: end of file in string; 
'"' inserted
/<>/helpers/instdlg/instdlg.s:94:   Info: macro invoked from here
/<>/helpers/instdlg/instdlg.s:161:Info: macro invoked from here



makensis -V3 "-XUnicode True" -DVERSION=0.10.6 -D4DIGITS_DATE=2022.03.21.2258 
-D_OUTFILE_NAME=build/win32-loader_0.10.6_all.exe -DBUILD_DIR=build -DNOCD=yes -DPXE=yes -DNOCD=yes 
-DOPTIONS_TXT="+net +pxe" main.nsi
MakeNSIS v3.10-2 - Copyright 1999-2023 Contributors
See the file COPYING for license details.
Credits can be found in the Users Manual.

Command line defined: "VERSION=0.10.6"
Command line defined: "4DIGITS_DATE=2022.03.21.2258"
Command line defined: "_OUTFILE_NAME=build/win32-loader_0.10.6_all.exe"
Command line defined: "BUILD_DIR=build"
Command line defined: "NOCD=yes"
Command line defined: "PXE=yes"
Command line defined: "NOCD=yes"
Command line defined: "OPTIONS_TXT=+net +pxe"
Processing config: /etc/nsisconf.nsh
Processing script file: "main.nsi" (UTF8)
Error: Can't find IDC_LIST1 (1016) in the custom UI!
!include: error in script: "download.nsi" on line 42
Error in script "main.nsi" on line 127 -- aborting creation process





Dear Maintainer,
I tried to have a look at this failure.

It looks like makensis is failing to manipulate
an executable build/helpers/instdlg/instdlg.exe.
This seems to happen because the layout/content
of instdlg.o is different than expected.
The object instdlg.o get generated from helpers/instdlg/instdlg.s.

It starts to get visible since binutils-mingw-w64-i686
migrated into Trixie/testing at 2024-07-08.

I did a git-bisect of sourceware.org/git/binutils-gdb.git and
found below commit [1] to be the first which shows this different behaviour.

The file instdlg.s also uses nested macros with string parameters [3].
This looks like it should generate UTF16 wide strings in the object file.
And since the new gas version there are plenty of warnings related to it 
visible.

The layout of the generated binary instdlg.o is with the new version
different [2], and I assume therefore nsis is failing.


But I am not completely sure if the generated instdlg.o
is valid and expected, and nsis needs to be able to handle it.
Or GNU assembler should really generate object files in the old layout?


I hope it is ok to CC Jan as author of the commit in GNU assembler.

Kind regards,
Bernhard



[1]
69cab370cf666f2e7692158ac7dffc6a65207f4a is the first broken commit
commit 69cab370cf666f2e7692158ac7dffc6a65207f4a
Author: Jan Beulich 
Date:   Fri May 24 12:22:54 2024 +0200

gas: adjust handling of quotes for .irpc

The present handling of inner double quotes can lead to very strange

diagnostics. Follow one of the two possible interpretations of the doc:
@dots{} referring to possibly multiple white space separated
@var{values}, each of which may be quoted. The original implementation,
prior to 465e5617233f ("PR gas/3856"), hints at the other possible
interpretation: When quoted there's only a single @var{values}, with
inner quotes taken as ordinary characters. That, however, seems overall
less useful to me.

While touching the documentation, mirror the (inverse) spelling

correction (@section line inconsistent with actual description) to .irp
as well.

 gas/doc/as.texi   | 15 ---
 gas/macro.c   | 20 ++--
 gas/testsuite/gas/macros/irpc-quote.l | 18 ++
 gas/testsuite/gas/macros/irpc-quote.s |  6 ++
 gas/testsuite/gas/macros/macros.exp   |  2 ++
 5 files changed, 40 insertions(+), 21 deletions(-)
 create mode 100644 gas/testsuite/gas/macros/irpc-quote.l
 create mode 100644 gas/testsuite/gas/macros/irpc-quote.s


[2]
build/helpers/instdlg/instdlg.o
2.42-4+11.5   | 
2.42.50.20240625-1+11.6
0120  48 04 00 40 06 00 00 00  00 00 2c 01 8c 00 00 00  |H..@..,.|| 
48 04 00 40 06 00 00 00  00 00 2c 01 8c 00 00 00  |H..@..,.|
0130  00 00 00 00 08 00 00 00  00 01 4d 00 53 00 20 00  |..M.S. .|| 00 00 0a 
00 00 00 08 00  00 00 00 01 4d 00 53 00  |M.S.| <<<
0140  53 00 68 00 65 00 6c 00  6c 00 20 00 44 00 6c 00  |S.h.e.l.l. .D.l.|| 
20 00 53 00 68 00 65 00  6c 00 6c 00 20 00 44 00  | .S.h.e.l.l. .D.|
0150  67 00 00 00 00 00 00 00  00 00 00 00 00 00 01 50  |g..

Bug#1040375: /usr/lib/x86_64-linux-gnu/simplescreenrecorder/libssr-glinject.so: Segmentation fault when used with anything

[Bernhard Übelacker]

On Sat, 10 Feb 2024 11:01:54 +0100 Petter Reinholdtsen  wrote:

[Petter Reinholdtsen]
> I do not use ssr much myself, and have not had time to test.

I applied the upstream commit in git branch fix-1040375-glinject and
tested it on Bookworm, but alas, the .so file still segfaults with a
useless backtrace.  I might have applied the commit incorrectly, as it
did not apply without changes, but hope not.  Perhaps someone
who understand what is happening can have a look?

--
Happy hacking
Petter Reinholdtsen




Hello,
looking through some bugs about crashes I came to this one
and found found it interesting.

If a proper backtrace is still helping one can get one by using
systemd-coredump.

Another nice way to debug early startup is using rr debugger.
(Plus the ability to debug back and forth.)


As far as I see the crash happens because it wants to print this message:

57  GLINJECT_PRINT("Error: Can't open libdl.so!");

But unfortunately libstdc++ seems not yet prepared to output the error.


(rr) bt
#0  0x7fbf7ff2fd9a in std::basic_ostream 
>::sentry::sentry(std::basic_ostream >&) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x7fbf7ff3074c in std::basic_ostream >& std::__ostream_insert >(std::basic_ostream >&, char const*, long) () 
from /lib/x86_64-linux-gnu/libstdc++.so.6
#2  0x7fbf7ff30bdb in std::basic_ostream >& std::operator<< 
 >(std::basic_ostream >&, char const*) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x7fbf805cef6f in InitGLInject () at ./glinject/Hook.cpp:57
#4  0x7fbf805cf13f in dlsym (handle=0x7fbf8060d2e0, symbol=0x7fbf80185f7a 
"pthread_create") at ./glinject/Hook.cpp:231
#5  0x7fbf80136dd7 in glvndSetupPthreads () at 
../src/util/glvnd_pthread.c:452
#6  0x7fbf801351a9 in __glDispatchOnLoadInit () at 
../src/GLdispatch/GLdispatch.c:174
#7  0x7fbf805de9ce in call_init (env=0x7ffeea4b1538, argv=0x7ffeea4b1528, argc=1, 
l=) at ./elf/dl-init.c:74
#8  call_init (l=, argc=1, argv=0x7ffeea4b1528, 
env=0x7ffeea4b1538) at ./elf/dl-init.c:26
#9  0x7fbf805deab4 in _dl_init (main_map=0x7fbf8060d2e0, argc=1, 
argv=0x7ffeea4b1528, env=0x7ffeea4b1538) at ./elf/dl-init.c:121
#10 0x7fbf805f4a70 in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#11 0x0001 in ?? ()
#12 0x7ffeea4b25ea in ?? ()
#13 0x in ?? ()
(rr)

(For some reason with libstdc++6-dbgsym the backtrace gets less good.)



I guess upstream discussed this issue here:

  https://github.com/MaartenBaert/ssr/issues/947


And a package built from `fix-1040375-glinject` did no
longer show this crash to me.


Attached file shows my actions inside a minimal bookworm VM.

Kind regards,
Bernhard
# 2024-05-07 Bookworm/stable amd64 qemu VM

apt update
apt dist-upgrade
apt install systemd-coredump mc gdb rr mesa-utils git simplescreenrecorder-lib 
simplescreenrecorder-lib-dbgsym libglvnd0-dbgsym libstdc++6-dbgsym appstream
apt build-dep simplescreenrecorder-lib






mkdir /home/benutzer/source/simplescreenrecorder/orig -p
cd/home/benutzer/source/simplescreenrecorder/orig
apt source simplescreenrecorder







benutzer@debian:~$ 
LD_PRELOAD=/usr/lib/x86_64-linux-gnu/simplescreenrecorder/libssr-glinject.so 
/usr/bin/true
Speicherzugriffsfehler (Speicherabzug geschrieben)
benutzer@debian:~$ 


benutzer@debian:~$ coredumpctl list
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
TIME PID  UID  GID SIG COREFILE EXESIZE
Tue 2024-05-07 00:10:28 CEST 994 1000 1000 SIGSEGV present  /usr/bin/true 89.0K
benutzer@debian:~$ 



benutzer@debian:~$ coredumpctl gdb --debugger-argument=-q 994
Hint: You are currently not seeing messages from other users and the system.
  Users in groups 'adm', 'systemd-journal' can see all messages.
  Pass -q to turn off this notice.
   PID: 994 (true)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Tue 2024-05-07 00:10:28 CEST (1min 26s ago)
  Command Line: /usr/bin/true
Executable: /usr/bin/true
 Control Group: /user.slice/user-1000.slice/session-3.scope
  Unit: session-3.scope
 Slice: user-1000.slice
   Session: 3
 Owner UID: 1000 (benutzer)
   Boot ID: 4df23299079540e38e42560b3966b576
Machine ID: 55a5ad9df1d547f38d7696343d9fde7d
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.true.1000.4df23299079540e38e42560b3966b576.994.171503342800.zst
 (present)
  Size on Disk: 89.0K
   Message: Process 994 (true) of user 1000 dumped core.

Stack trace of thread 994:
#0  0x7f988d92fd9a _ZNSo6sentryC1ERSo (libstdc++.so.6 + 
0x12fd9a)
#1  0x7

Bug#1054661: blastem: Segfault when trying to open rom or access system settings

[Bernhard Übelacker]

On Sat, 28 Oct 2023 12:52:30 +0200 Tobias Frost  wrote:

Control: tags -1 confirmed

Here's a backtrace when clicking on Settings -> System. 
Thread 1 "blastem" received signal SIGSEGV, Segmentation fault.

tern_foreach_int (head=, fun=0x555c12a0 , 
data=0x7fffd7f0, keybuf=0x7fffd8c0 "\020", pos=0)
at /build/blastem-kipVNx/blastem-0.6.3.4/tern.c:268
268 if (!head->el) {
(gdb) bt
#0  tern_foreach_int (head=, fun=0x555c12a0 , 
data=0x7fffd7f0, keybuf=0x7fffd8c0 "\020", pos=0) at 
/build/blastem-kipVNx/blastem-0.6.3.4/tern.c:268
#1  0x555c7e15 in tern_foreach (data=0x7fffd7f0, fun=0x555c12a0 
, head=) at 
/build/blastem-kipVNx/blastem-0.6.3.4/tern.c:291
#2  get_models (num_out=0x557a8ba0 ) at 
nuklear_ui/blastem_nuklear.c:1873
#3  view_system_settings (context=0x55611ab8 ) at 
nuklear_ui/blastem_nuklear.c:1907
#4  0x555c8354 in blastem_nuklear_render () at 
nuklear_ui/blastem_nuklear.c:2049
#5  0x55589e1b in render_update_display () at 
/build/blastem-kipVNx/blastem-0.6.3.4/render_sdl.c:1783
#6  0x555caeeb in ui_idle_loop () at nuklear_ui/blastem_nuklear.c:2075
#7  0xdefa in blastem_nuklear_init (file_loaded=0 '\000') at 
nuklear_ui/blastem_nuklear.c:2332
#8  main (argc=, argv=) at 
/build/blastem-kipVNx/blastem-0.6.3.4/blastem.c:714
(gdb) 


Did not investigate further.



Hello,
tried to take a little deeper look.
And it seems it is just a missing packaged config file:


(rr)
0x55c0356f0361  1012return NULL;
1: x/i $pc
=> 0x55c0356f0361 :  xor%r13d,%r13d
10: /x $r13 = 0x0
(rr) bt
#0  0x55c0356f0361 in read_bundled_file (name=name@entry=0x55c03574ae4a 
"systems.cfg", sizeret=sizeret@entry=0x7ffc07889c88) at 
/build/blastem-kipVNx/blastem-0.6.3.4/util.c:1012
#1  0x55c0356f0a2d in parse_bundled_config (config_name=0x55c03574ae4a 
"systems.cfg") at /build/blastem-kipVNx/blastem-0.6.3.4/config.c:217
#2  0x55c03571ff56 in get_systems_config () at 
/build/blastem-kipVNx/blastem-0.6.3.4/config.c:331
#3  get_models (num_out=0x55c035900ba0 ) at 
nuklear_ui/blastem_nuklear.c:1866
#4  view_system_settings (context=0x55c035769ab8 ) at 
nuklear_ui/blastem_nuklear.c:1907
#5  0x55c035720354 in blastem_nuklear_render () at 
nuklear_ui/blastem_nuklear.c:2049
#6  0x55c0356e1e1b in render_update_display () at 
/build/blastem-kipVNx/blastem-0.6.3.4/render_sdl.c:1783
#7  0x55c035722eeb in ui_idle_loop () at nuklear_ui/blastem_nuklear.c:2075
#8  0x55c0356b5efa in blastem_nuklear_init (file_loaded=0 '\000') at 
nuklear_ui/blastem_nuklear.c:2332
#9  main (argc=, argv=) at 
/build/blastem-kipVNx/blastem-0.6.3.4/blastem.c:714


Function `read_bundled_file` does not find "systems.cfg",
therefore returns NULL,
therefore `parse_bundled_config` returns also NULL,
which is then also returned by `get_systems_config`.

This NULL is given unconditionally into tern_foreach in blasem_nuklear.c line 
1873,
and gets dereferenced.


Following change would add systems.cfg to the Debian package,
and did avoid the crash in a short test.

Kind regards,
Bernhard


diff -Nurp orig/blastem-0.6.3.4/debian/blastem.install 
try2/blastem-0.6.3.4/debian/blastem.install
--- orig/blastem-0.6.3.4/debian/blastem.install 2021-09-24 22:14:33.0 
+0200
+++ try2/blastem-0.6.3.4/debian/blastem.install 2024-05-06 14:31:55.277695226 
+0200
@@ -6,3 +6,4 @@ gamecontrollerdb.txtusr/share/games/bl
 images usr/share/games/blastem
 rom.db usr/share/games/blastem
 shadersusr/share/games/blastem
+systems.cfgusr/share/games/blastem

Bug#1064372: evolution: segfault during startup

[Bernhard Übelacker]

Hello,
just tried to extract the backtrace from the attached core dump.

Kind regards,
Bernhard


Core was generated by `/usr/bin/evolution'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()

(gdb) bt
#0  0x in ?? ()
#1  0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598
#2  0x7f5ad98dac0c in ref_unix_signal_handler_unlocked (signum=15) at 
../../../glib/gmain.c:5726
#3  _g_main_create_unix_signal_watch (signum=15) at ../../../glib/gmain.c:5834
#4  0x7f5ad992f8de in g_unix_signal_add_full (priority=priority@entry=0, 
signum=signum@entry=15, handler=handler@entry=0x556725eb22e0 
, user_data=user_data@entry=0x0, notify=notify@entry=0x0) 
at ../../../glib/glib-unix.c:231
#5  0x556725eb1b08 in main (argc=, argv=) at 
./src/shell/main.c:729
(gdb) up
#1  0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598
6598  pthread_sigmask (SIG_SETMASK, &all, &prev_mask);
(gdb)
# 2024-04-26 Trixie/testing amd64 qemu VM

apt update
apt dist-upgrade
apt install systemd-coredump wget zstd ncdu gdb evolution-dbgsym 
libglib2.0-0-dbgsym
apt build-dep glib2.0


mkdir /home/benutzer/source/glib2.0/orig -p
cd/home/benutzer/source/glib2.0/orig
apt source glib2.0


wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=1064372;filename=core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800.zst;msg=5";
 -O 
core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800.zst
unzstd --keep 
core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800.zst


export DEBUGINFOD_URLS="https://debuginfod.debian.net";
echo "set debuginfod enabled on" >> .gdbinit

gdb -q --core 
core.evolution.1000.1a4c16b6b1594876901650d63de977bc.12161.170846511800 
/usr/bin/evolution

set width 0
set pagination off
directory /home/benutzer/source/glib2.0/orig/glib2.0-2.78.4/glib/tests/markups


Core was generated by `/usr/bin/evolution'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x in ?? ()
(gdb) set width 0
(gdb) set pagination off
(gdb) directory 
/home/benutzer/source/glib2.0/orig/glib2.0-2.78.4/glib/tests/markups
Source directories searched: 
/home/benutzer/source/glib2.0/orig/glib2.0-2.78.4/glib/tests/markups:$cdir:$cwd
(gdb) bt
#0  0x in ?? ()
#1  0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598
#2  0x7f5ad98dac0c in ref_unix_signal_handler_unlocked (signum=15) at 
../../../glib/gmain.c:5726
#3  _g_main_create_unix_signal_watch (signum=15) at ../../../glib/gmain.c:5834
#4  0x7f5ad992f8de in g_unix_signal_add_full (priority=priority@entry=0, 
signum=signum@entry=15, handler=handler@entry=0x556725eb22e0 
, user_data=user_data@entry=0x0, notify=notify@entry=0x0) 
at ../../../glib/glib-unix.c:231
#5  0x556725eb1b08 in main (argc=, argv=) at 
./src/shell/main.c:729
(gdb) up
#1  0x7f5ad98da8b6 in g_get_worker_context () at ../../../glib/gmain.c:6598
6598  pthread_sigmask (SIG_SETMASK, &all, &prev_mask);
(gdb)

Bug#1064613: vtun: Segmentation fault with default config

[Bernhard Übelacker]

On Sat, 24 Feb 2024 23:55:18 + =?utf-8?q?Lucas_L=C3=B3pez?= 
 wrote:

I copied the example server file /usr/share/doc/vtun/examples/vtund-server.conf 
into
/etc/vtund.conf and enabled server mode in /etc/default/vtun. When I start the 
service
with systemctl I get the following error on the dmesg log:

[343358.769324] vtund[3002]: segfault at 0 ip 5572cac05e34 sp 
7ffc9a47f610 error 4 in vtund[5572cabff000+b000] likely on CPU 0 (core 0, 
socket 0)
[343358.769342] Code: 24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 10 48 
89 44 24 08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 7d 00 
0f 85 d1 00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff

I checked the config and the manual but I haven't been able to use the package 
due to the segfault.
BTW, the autogenerated systemd unit has the attributes RemainAfterExit=yes, 
SuccessExitStatus=5 6,
so even on failure the unit appears as "active (exited)". Hence it needs a 
"systemctl restart",
"systemctl start" won't do anything which is a bit counterintuitive.



Hello,
I am not the maintainer of vtun, just tried to find some more informations 
about the crash.
I was not able to reproduce it inside a minimal VM, but I think
from the dmesg lines it happened in netlib.c line 156.

This looks like ifa->ifa_addr is no valid pointer but gets dereferenced.
I guess it might be related to the network configuration of this specific host,
maybe containing an interface without having an address assigned.

Kind regards,
Bernhard


148 int getifaddr(struct sockaddr_storage *addr, char * ifname, sa_family_t 
af)
...
154
155  for (ifa = ifas; ifa; ifa = ifa->ifa_next) {
156 if( ifa->ifa_addr->sa_family != af ||
157strcmp(ifname, ifa->ifa_name) )

https://sources.debian.org/src/vtun/3.0.4-2/netlib.c/#L156
https://man7.org/linux/man-pages/man3/getifaddrs.3.html
# 2024-04-22 Trixie/testing amd64 qemu VM

apt update
apt install systemd-coredump mc htop gdb

# with unstable
apt install vtun vtun-dbgsym devscripts
apt build-dep vtun



mkdir /home/benutzer/source/vtun/orig -p
cd/home/benutzer/source/vtun/orig
dget 
https://snapshot.debian.org/archive/debian-debug/20191112T220504Z/pool/main/v/vtun/vtun_3.0.4-2.dsc
dpkg-source -x vtun_3.0.4-2.dsc


cp -a /usr/share/doc/vtun/examples/vtund-server.conf /etc/vtund.conf

cp -a /etc/default/vtun /etc/default/vtun.orig
sed -i 's/# RUN_SERVER=no/RUN_SERVER=yes/g' /etc/default/vtun


wget 
https://snapshot.debian.org/archive/debian/20220514T093947Z/pool/main/v/vtun/vtun_3.0.4-2%2Bb1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20220514T091215Z/pool/main/v/vtun/vtun-dbgsym_3.0.4-2%2Bb1_amd64.deb
dpkg -i *.deb

systemctl start vtun.service

-> Could not reproduce the crash




[343358.769324] vtund[3002]: segfault at 0 ip 5572cac05e34 sp 
7ffc9a47f610 error 4 in vtund[5572cabff000+b000] likely on CPU 0 (core 0, 
socket 0)
[343358.769342] Code: 24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 
10 48 89 44 24 08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 
7d 00 0f 85 d1 00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff

# https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash

error 4
0b0100
 *   bit 0 ==0: no page found
 *   bit 1 ==0: read access
 *   bit 2 ==1: user-mode access

 
echo -n "find /b ..., ..., 0x" && \
echo "24 10 e8 2f 96 ff ff 85 c0 0f 88 0d 01 00 00 48 8b 44 24 10 48 89 44 24 
08 48 85 c0 0f 84 f0 00 00 00 48 89 c3 90 48 8b 6b 18 <66> 44 39 7d 00 0f 85 d1 
00 00 00 48 8b 73 08 4c 89 ef e8 55 97 ff" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



gdb -q --pid $(pgrep vtund)
(gdb) pipe info target | grep -E ".text$"
0x55c1fbd0f7f0 - 0x55c1fbd19ba1 is .text
(gdb) find /b 0x55c1fbd0f7f0, 0x55c1fbd19ba1, 0x24, 0x10, 0xe8, 0x2f, 
0x96, 0xff, 0xff, 0x85, 0xc0, 0x0f, 0x88, 0x0d, 0x01, 0x00, 0x00, 0x48, 0x8b, 
0x44, 0x24, 0x10, 0x48, 0x89, 0x44, 0x24, 0x08, 0x48, 0x85, 0xc0, 0x0f, 0x84, 
0xf0, 0x00, 0x00, 0x00, 0x48, 0x89, 0xc3, 0x90, 0x48, 0x8b, 0x6b, 0x18, 0x66, 
0x44, 0x39, 0x7d, 0x00, 0x0f, 0x85, 0xd1, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x73, 
0x08, 0x4c, 0x89, 0xef, 0xe8, 0x55, 0x97, 0xff
0x55c1fbd15e0a 
1 pattern found.
(gdb) b * (0x55c1fbd15e0a + 42)
Breakpoint 1 at 0x55c1fbd15e34: file ./netlib.c, line 156.
(gdb) info b
Num Type   Disp Enb AddressWhat
1   breakpoint keep y   0x55c1fbd15e34 in getifaddr at 
./netlib.c:156
(gdb) disassemble /r 0x55c1fbd15e0a, 0x55c1fbd15e0a + 62
Dump of assembler code from 0x55c1fbd15e0a to 0x55c1fbd15e48:
   0x55c1fbd15e0a :   24 10   and$0x10,%al
   0x55c1fbd15e0c :   e8 2f 96 ff ff  call   
0x55c1fbd0f440 
   0x55c1fbd15e11 :   85 c0   test   %eax,%eax
   0x55c1fbd15e13 :   0f 88 0d 01 

Bug#1067691: FTBFS: double free or corruption

[Bernhard Übelacker]

Hello,
I found this one interesting and tried to reproduce it,
and hit this issue quite reliable with an unstable armel chroot,
inside an armhf unstable qemu VM,
or with a Android/LineageOS with real arm CPU.

Unfortunately valgrind is no longer built for armel, and a local armel rebuild
shows issues with latest "-fstack-protector-strong -fstack-clash-protection".

Finally I found this issue leads not to a crash at amd64, but
valgrind uncovers it there reliable [1].

dpkg-buildpackage with valgrind installed uses it automatically.
Therefore the change in [2] might be an improvement?


Increasing the allocation of the input buffer like in [3]
makes the valgrind errors go away.
Unfortunately I don't know what exact size this buffer is expected to have.

Kind regards,
Bernhard




[1]
...
fft const
==1105453== Invalid write of size 4
==1105453==at 0x60BFC25: ??? (in 
/usr/lib/x86_64-linux-gnu/libavutil.so.58.29.100)
==1105453==by 0x4CE1880: av_rdft_calc (in 
/usr/lib/x86_64-linux-gnu/libavcodec.so.60.31.102)
==1105453==by 0x11246F: FFTPlanImpl::execute() (spek-fft.cc:38)
==1105453==by 0x110A76: test_const() (test-fft.cc:21)
==1105453==by 0x1105F5: test_fft() (test-fft.cc:77)
==1105453==by 0x10BF5C: main (test.cc:11)
==1105453==  Address 0x11a828c4 is 4 bytes after a block of size 64 alloc'd
==1105453==at 0x4845DA0: memalign (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1105453==by 0x4845F01: posix_memalign (in 
/usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==1105453==by 0x608CC14: av_malloc (in 
/usr/lib/x86_64-linux-gnu/libavutil.so.58.29.100)
==1105453==by 0x1126A0: FFTPlan (spek-fft.h:29)
==1105453==by 0x1126A0: FFTPlanImpl::FFTPlanImpl(int) (spek-fft.cc:27)
==1105453==by 0x112745: FFT::create(int) (spek-fft.cc:24)
==1105453==by 0x1109AE: test_const() (test-fft.cc:13)
==1105453==by 0x1105F5: test_fft() (test-fft.cc:77)
==1105453==by 0x10BF5C: main (test.cc:11)
...


[2]
--- debian/control.orig 2023-01-11 07:25:51.0 +0100
+++ debian/control  2024-04-21 16:30:57.545576734 +0200
@@ -11,3 +11,4 @@ Build-Depends: debhelper-compat (= 13),
libwxgtk3.2-dev,
-   wx-common
+   wx-common,
+   valgrind-if-available
 Standards-Version: 4.6.2


[3]
--- src/spek-fft.h.orig 2023-01-10 05:00:39.0 +0100
+++ src/spek-fft.h  2024-04-21 16:28:07.0 +0200
@@ -28,3 +28,3 @@ public:
 // input data to be aligned by up to 32 bytes (e.g. AVX)
-this->input = (float*) av_malloc(sizeof(float) * input_size);
+this->input = (float*) av_malloc(sizeof(float) * (input_size + 2));
 }

Bug#1053142: chromium cannot startup after libfreetype6 upgrade to 2.12.1+dfsg-5+deb12u1

[Bernhard Schmidt]

Control: affects -1 src:freetype

Technically it probably should be the other way around, but I fear this
will be missed otherwise. Marking freetype as affected to at least it
shows up there.

Bug#1051355: chromium: Segmentation fault

[Bernhard Reutner-Fischer]

Hi!

I'm seeing the same thing with chromium-116.0.5845.180-1



$ chromium --temp-profile -g
Using temporary profile: /tmp/tmp.ZOHJkTVKhC
# Env:
# LD_LIBRARY_PATH=
#
PATH=/home/x/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
#GTK_PATH=
#  CHROMIUM_FLAGS= --show-component-extension-options
--enable-gpu-rasterization --no-default-browser-check --disable-pings
--media-router=0 --enable-remote-extensions --load-extension=
--user-data-dir=/tmp/tmp.ZOHJkTVKhC
/usr/bin/gdb /usr/lib/chromium/chromium -x /tmp/chromiumargs.Tusmrb
GNU gdb (Debian 13.2-1) 13.2
Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/chromium/chromium...
Reading symbols from
/usr/lib/debug/.build-id/90/89ffc7f99a6ffa21e9daf64ff6d58ef8bdec78.debug...
(gdb) r
Starting program: /usr/lib/chromium/chromium
--show-component-extension-options --enable-gpu-rasterization
--no-default-browser-check --disable-pings --media-router=0
--enable-remote-extensions --load-extension=
--user-data-dir=/tmp/tmp.ZOHJkTVKhC --single-process
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after fork from child process 13922]
[New Thread 0x717ff6c0 (LWP 13927)]
[Detaching after fork from child process 13928]
[Detaching after fork from child process 13929]
[Detaching after fork from child process 13930]
[New Thread 0x70ffe6c0 (LWP 13933)]
[New Thread 0x7fffe6c0 (LWP 13934)]
[New Thread 0x7fffef7fe6c0 (LWP 13935)]
[New Thread 0x7fffeeffd6c0 (LWP 13936)]
[New Thread 0x7fffee7fc6c0 (LWP 13937)]
[New Thread 0x7fffedffb6c0 (LWP 13938)]
[New Thread 0x7fffed7fa6c0 (LWP 13939)]
[New Thread 0x7fffecff96c0 (LWP 13940)]
[New Thread 0x7fffec7f86c0 (LWP 13941)]
[New Thread 0x7fffebff76c0 (LWP 13942)]
[New Thread 0x7fffea9866c0 (LWP 13943)]
[New Thread 0x7fffea1856c0 (LWP 13944)]
[New Thread 0x7fffe99846c0 (LWP 13945)]
[New Thread 0x7fffe91836c0 (LWP 13946)]
[Thread 0x7fffe91836c0 (LWP 13946) exited]
[New Thread 0x7fffe91836c0 (LWP 13947)]
[New Thread 0x7fffe7dff6c0 (LWP 13948)]
[New Thread 0x7fffe75fe6c0 (LWP 13949)]
[New Thread 0x7fffe65fc6c0 (LWP 13950)]
[New Thread 0x7fffe6dfd6c0 (LWP 13951)]
[New Thread 0x7fffe5dfb6c0 (LWP 13952)]
[New Thread 0x7fffe55fa6c0 (LWP 13953)]
[New Thread 0x7fffe4df96c0 (LWP 13954)]
[New Thread 0x7fffe45f86c0 (LWP 13955)]
[New Thread 0x7fffe3df76c0 (LWP 13956)]
[New Thread 0x7fffdf5b56c0 (LWP 13957)]
[New Thread 0x7fffdedb46c0 (LWP 13958)]
[New Thread 0x7fffde5816c0 (LWP 13959)]
[13919:13919:0907/101433.143667:ERROR:system_network_context_manager.cc(749)]
Cannot use V8 Proxy resolver in single process mode.
[13919:13919:0907/101433.146331:ERROR:chrome_browser_cloud_management_controller.cc(163)]
Cloud management controller initialization aborted as CBCM is not
enabled.
[13919:13919:0907/101433.16:ERROR:system_network_context_manager.cc(749)]
Cannot use V8 Proxy resolver in single process mode.
[New Thread 0x7fffdd7ff6c0 (LWP 13962)]
[New Thread 0x7fffdcffe6c0 (LWP 13963)]
[New Thread 0x7fffdc7fd6c0 (LWP 13964)]
[New Thread 0x7fffdbffc6c0 (LWP 13965)]
[New Thread 0x7fffdb7fb6c0 (LWP 13969)]
[New Thread 0x7fffdaffa6c0 (LWP 13970)]
[New Thread 0x7fffd9f3f6c0 (LWP 13972)]
[New Thread 0x7fffda7406c0 (LWP 13971)]
[13919:13919:0907/101433.172400:ERROR:object_proxy.cc(590)] Failed to
call method: org.freedesktop.portal.Settings.Read: object_path=
/org/freedesktop/portal/desktop:
org.freedesktop.DBus.Error.UnknownMethod: No such interface
“org.freedesktop.portal.Settings” on object at path
/org/freedesktop/portal/desktop
[New Thread 0x7fffd96cf6c0 (LWP 13975)]
[New Thread 0x7fffd87ff6c0 (LWP 13976)]
[New Thread 0x7fffcd5ff6c0 (LWP 13977)]
[New Thread 0x7fffccdfe6c0 (LWP 13978)]

Thread 41 "import_thread" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffccdfe6c0 (LWP 13978)]
0x5d5e21bb in WTF::Partitions::BufferPotentialCapacity(unsigned long) ()
(gdb) bt f
#0  0x5d5e21bb in
WTF::Partitions::BufferPotentialCapacity(unsigned long) ()
#1  0x5ab35a65 in WTF::Vector::ExpandCapacity(unsigned int, char*) ()
#2  0x5d5e55b6 in WTF::SharedBuffer::SharedBuffer(char const*,
unsigned int) ()
#3  0x5f953aff in blink::WebData::Assign(char const*, unsigned long) ()
#4  0x61b9fb5a in content::DecodeImage(unsigne

Bug#1040447: odbc-mariadb cannot set up odcb-mariadb

[Bernhard Schmidt]

Control: severity -1 important
Control: tags -1 unreproducible

Same as Tuukka I cannot reproduce this. 

Bug#1040830: ESNET-SECADV-2023-0001: iperf3 memory allocation hazard and crash

[Bernhard Schmidt]

Source: iperf3
Version: 3.13-2
Severity: serious
Tags: security upstream
X-Debbugs-Cc: Debian Security Team 

A security advisory for iperf3 has been issued.

https://downloads.es.net/pub/iperf/esnet-secadv-2023-0001.txt.asc

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

ESnet Software Security Advisory
ESNET-SECADV-2023-0001

Topic:  iperf3 memory allocation hazard and crash
Issued: 7 July 2023
Credits:@someusername123 via GitHub
Affects:iperf-3.13 and earlier
Corrected:  iperf-3.14
Cross-references:   esnet/iperf#1542 on GitHub

I.  Background

iperf3 is a utility for testing network performance using TCP, UDP,
and SCTP, running over IPv4 and IPv6.  It uses a client/server model,
where a client and server communicate the parameters of a test,
coordinate the start and end of the test, and exchange results.  This
message exchange takes place over a TCP "control connection".

II.  Problem Description

The iperf3 server and client will, at various times, exchange
JSON-formatted messages containing parameters and test results. By
convention, the actual JSON representation is preceded by a four-byte
integer that gives the length of the JSON message.

iperf3 uses the length to determine the size of a dynamically
allocated memory buffer in which to store the incoming message. If the
length equals 0x, an integer overflow can be triggered in the
receiving iperf3 process (typically the server), which can in turn
cause heap corruption and an abort/crash. While this is unlikely to
happen during normal iperf3 operation, a suitably crafted client
program could send a sequence of bytes on the iperf3 control channel
to cause an iperf3 server to crash.

III.  Impact

A malicious process can connect to an iperf3 server and, by sending a
malformed message on the control channel, cause the server process to
abort due to heap corruption. A malicious iperf3 server could
potentially mount a similar attack on an iperf3 client.

Among the officially supported platforms, this problem has only been
observed on Linux. So far, it has not been reproduced with iperf3
running under Linux or macOS.

iperf2, an older version of the iperf utility, uses a different model
of interaction between client and server, and is not affected by this
issue.

IV.  Workaround

There is no workaround for this issue, however as best practice
dictates, iperf3 should not be run with root privileges, to minimize
possible impact.

V.  Solution

Update iperf3 to a version containing the fix (i.e. iperf-3.14 or
later).

VI.  Correction details

The bug causing this vulnerability has been fixed by the following
commit in the esnet/iperf Github repository:

master  0ef151550d96cc4460f98832df84b4a1e87c65e9

All released versions of iperf3 issued on or after the date of this
advisory incorporate the fix.
-BEGIN PGP SIGNATURE-

iQEzBAEBCgAdFiEE+Fo4IENp9xo01E6DSYSRCoyq7ooFAmSogHEACgkQSYSRCoyq
7orOGwgAwoF1S8ta/be1y90NYif36DnXDLjEvgcPwnFy4YadG4bI5Rx3btO73NGH
Xp/T/PXROtU40Qu3TaQsmEGFn46I+hgbGyzd11oxX1mysK6n0U3BUPCdgn7+JA5A
vpFfL4mo1efYe5cBEEUy6fnY7PipC4ltYv6I0jb4zprQalKZaPaP4TVm4si+vNKT
TViLgOZzvelIatKPl0SY7SEEQj7vkJDNw89kxQG9jZExeS1qLgPwRsmyR0b4TTDc
MMtUjn4Zl/uR2vCPeEmxTmh+QutY35vOw4N6vaqaUcHspNGJrWy5XW4QuIGEsbBq
KLsKmkzHa/fYp+1SesgNMrJkutOo2g==
=puru
-END PGP SIGNATURE-

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Schmidt, Bernhard]

Am Mittwoch, dem 07.06.2023 um 15:28 +0200 schrieb Bernhard Schmidt:

Hi Utkarsh,


> > > Yep, I'm taking a look to prep something for 2.5.
> > 
> > I've prepared a fix for the regression and uploaded the binaries
> > at:
> > https://people.debian.org/~utkarsh/lts/ruby2.5/
> > 
> > Can you please give these a try and see if that fixes the
> > regression you're seeing?
> 
> Looking good!

Any news here?

Bernhard

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Bernhard Schmidt]

Hi Utkarsh,


I've actually managed to prepare a final update that I'm ready to
upload - this has quite some fixes plus 2 new CVE fixes. Would you
please test the new resulting binaries and make sure they look sane
enough? :)

The binaries can be found at
https://people.debian.org/~utkarsh/lts/ruby2.5/. Many thanks!


I don't use ruby outside of puppet, but my puppet problem is fixed with 
these binaries. So from my POV you can release it.


Many thanks!
Bernhard

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Schmidt, Bernhard]

Am Mittwoch, dem 07.06.2023 um 18:47 +0530 schrieb Utkarsh Gupta:

Hi,

> > Yep, I'm taking a look to prep something for 2.5.
> 
> I've prepared a fix for the regression and uploaded the binaries at:
> https://people.debian.org/~utkarsh/lts/ruby2.5/
> 
> Can you please give these a try and see if that fixes the regression
> you're seeing?

Looking good!

# puppet agent --test
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Error: /File[/var/lib/puppet/facts.d]: Failed to generate additional
resources using 'eval_generate': Failed to open TCP connection to :8140
(Connection refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not
retrieve file metadata for puppet:///pluginfacts: Failed to open TCP
connection to :8140 (Connection refused - connect(2) for "" port 8140)
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Failed to generate additional
resources using 'eval_generate': Failed to open TCP connection to :8140
(Connection refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not
retrieve file metadata for puppet:///plugins: Failed to open TCP
connection to :8140 (Connection refused - connect(2) for "" port 8140)
Info: Retrieving locales
[..]


# dpkg -i libruby2.5_2.5.5-3+deb10u6_amd64.deb
(Reading database ... 69723 files and directories currently installed.)
Preparing to unpack libruby2.5_2.5.5-3+deb10u6_amd64.deb ...
Unpacking libruby2.5:amd64 (2.5.5-3+deb10u6) over (2.5.5-3+deb10u5) ...
Setting up libruby2.5:amd64 (2.5.5-3+deb10u6) ...
Processing triggers for libc-bin (2.28-10+deb10u2) ...

# puppet agent --test
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for xxx.lrz.de
Info: Applying configuration version 'master-3a083818c9e2'
Notice: Applied catalog in 3.86 seconds

Bernhard

Bug#1037178: puppet does not sync files anymore after recent ruby2.5 security upload

[Bernhard Schmidt]

Package: libruby2.5
Version: 2.5.5-3+deb10u5
Severity: grave

Hi,

I can't quite figure out why, but the latest security upload of ruby2.5 in
Buster breaks the ability of the puppet agent to pull files from the master

With 2.5.5-3+deb10u4:
# puppet agent --onetime --server puppet-kom.srv.lrz.de  --test  --no-daemonize
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Info: Retrieving plugin
Info: Retrieving locales
Info: Loading facts
Info: Caching catalog for simrad3.slb.lrz.de
Info: Applying configuration version 'master-70189ef6ab5a'


# apt dist-upgrade
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Calculating upgrade... Done
The following packages will be upgraded:
  libruby2.5 ruby2.5
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 3841 kB of archives.
After this operation, 2048 B of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://debian.mirror.lrz.de/debian-security buster/updates/main amd64 
libruby2.5 amd64 2.5.5-3+deb10u5 [3440 kB]
Get:2 http://debian.mirror.lrz.de/debian-security buster/updates/main amd64 
ruby2.5 amd64 2.5.5-3+deb10u5 [401 kB]
Fetched 3841 kB in 0s (30.3 MB/s)
Reading changelogs... Done
(Reading database ... 58907 files and directories currently installed.)
Preparing to unpack .../libruby2.5_2.5.5-3+deb10u5_amd64.deb ...
Unpacking libruby2.5:amd64 (2.5.5-3+deb10u5) over (2.5.5-3+deb10u4) ...
Preparing to unpack .../ruby2.5_2.5.5-3+deb10u5_amd64.deb ...
Unpacking ruby2.5 (2.5.5-3+deb10u5) over (2.5.5-3+deb10u4) ...
Setting up libruby2.5:amd64 (2.5.5-3+deb10u5) ...
Setting up ruby2.5 (2.5.5-3+deb10u5) ...
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for libc-bin (2.28-10+deb10u2) ...

# puppet agent --onetime --server puppet-kom.srv.lrz.de  --test  --no-daemonize
Info: Using configured environment 'production'
Info: Retrieving pluginfacts
Error: /File[/var/lib/puppet/facts.d]: Failed to generate additional resources 
using 'eval_generate': Failed to open TCP connection to :8140 (Connection 
refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/facts.d]: Could not evaluate: Could not retrieve 
file metadata for puppet:///pluginfacts: Failed to open TCP connection to :8140 
(Connection refused - connect(2) for "" port 8140)
Info: Retrieving plugin
Error: /File[/var/lib/puppet/lib]: Failed to generate additional resources 
using 'eval_generate': Failed to open TCP connection to :8140 (Connection 
refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/lib]: Could not evaluate: Could not retrieve file 
metadata for puppet:///plugins: Failed to open TCP connection to :8140 
(Connection refused - connect(2) for "" port 8140)
Info: Retrieving locales
Error: /File[/var/lib/puppet/locales]: Failed to generate additional resources 
using 'eval_generate': Failed to open TCP connection to :8140 (Connection 
refused - connect(2) for "" port 8140)
Error: /File[/var/lib/puppet/locales]: Could not evaluate: Could not retrieve 
file metadata for puppet:///locales: Failed to open TCP connection to :8140 
(Connection refused - connect(2) for "" port 8140)
Info: Loading facts
Info: Caching catalog for simrad3.slb.lrz.de
Info: Applying configuration version 'master-70189ef6ab5a'
Error: 
/Stage[main]/Lrz_kom_radius::Radiussimrad/File[/etc/freeradius/.git/hooks/post-commit]:
 Could not evaluate: Could not retrieve file metadata for 
puppet:///modules/lrz_kom/classes/radius/git_post-commit_hook: Failed to open 
TCP connection to :8140 (Connection refused - connect(2) for "" port 8140)
Error: 
/Stage[main]/Lrz_common::Distributions::Debian::Vim/File[/etc/vim/vimrc.lrz-puppet]:
 Could not evaluate: Could not retrieve file metadata for 
puppet:///modules/lrz_common/vimrc.lrz-puppet: Failed to open TCP connection to 
:8140 (Connection refused - connect(2) for "" port 8140)
Error: 
/Stage[main]/Lrz_common::Distributions::Debian::Emacs/File[//etc/emacs/site-start.d/99lrz.el]:
 Could not evaluate: Could not retrieve file metadata for 
puppet:///modules/lrz_common/emacs/99lrz.el: Failed to open TCP connection to 
:8140 (Connection refused - connect(2) for "" port 8140)
Error: 
/Stage[main]/Lrz_common::Distributions::Debian/File[/etc/apt/trusted.gpg.d/debian-lrz.asc]:
 Could not evaluate: Could not retrieve file metadata for 
puppet:///modules/lrz_common/debian/debian-lrz.asc: Failed to open TCP 
connection to :8140 (Connection refused - connect(2) for "" port 8140)
Error: /Stage[main]/Puppetclient::Config/File[/usr/bin/waitrandom]: Could not 
evaluate: Could not retrieve file metadata for 
puppet:///modules/puppetclient/waitrandom: Failed to open TCP connection to 
:8140 (Connection refused - connect(2) for "" port 8140)
Notice: Applied catalog in 1.82 seconds

Note the empty servername in the "Failed to open TCP connection" messages.

Bernhard

Bug#1032510: packagekit: pkcon what-provides application/x-keepass2 makes PK crash

[Bernhard Übelacker]

On Wed, 08 Mar 2023 10:47:25 +0100 Laurent Bigonville  wrote:

$ pkcon what-provides application/x-keepass2
Getting provides[=]
Loading cache   [=]
Querying[=] e 
daemon crashed mid-transaction!
Finished[ ] (0%)

   Stack trace of thread 10447:
#0  0x7faf3ef75ccc __pthread_kill_implementation (libc.so.6 
+ 0x8accc)
#1  0x7faf3ef26ef2 __GI_raise (libc.so.6 + 0x3bef2)
#2  0x7faf3ef11472 __GI_abort (libc.so.6 + 0x26472)
#3  0x7faf3c89d919 
_ZN9__gnu_cxx27__verbose_terminate_handlerEv (libstdc++.so.6 + 0x9d919)
#4  0x7faf3c8a8e1a _ZN10__cxxabiv111__terminateEPFvvE 
(libstdc++.so.6 + 0xa8e1a)
#5  0x7faf3c8a8e85 _ZSt9terminatev (libstdc++.so.6 + 
0xa8e85)
#6  0x7faf3c8a90d8 __cxa_throw (libstdc++.so.6 + 0xa90d8)
#7  0x7faf3c8a00e4 _ZSt19__throw_logic_errorPKc 
(libstdc++.so.6 + 0xa00e4)
#8  0x7faf3e96cb3a 
_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC4IS3_EEPKcRKS3_ 
(libpk_backend_apt.so + 0x2cb3a)
#9  0x7faf3e95d122 backend_what_provides_thread 
(libpk_backend_apt.so + 0x1d122)
#10 0x5644cb0c7aca pk_backend_job_thread_setup (packagekitd 
+ 0x23aca)
#11 0x7faf3f5dbcfd g_thread_proxy (libglib-2.0.so.0 + 
0x7ecfd)
#12 0x7faf3ef73fd4 start_thread (libc.so.6 + 0x88fd4)
#13 0x7faf3eff466c __clone3 (libc.so.6 + 0x10966c)



Hello Laurent,
I am just looking at some random crash reports.
Unfortunately I cannot reproduce the crash in a
current QEMU VM, neither minimal nor with a Gnome desktop.
I cannot even convince the pkcon processes to load the
library libpk_backend_apt.so.

Can you still reproduce it. And do you probably have
done some changes to the configuration?
It looks like the system wide packagekitd is contacted,
maybe that shows something in the journal.

Kind regards,
Bernhard

Bug#919234: ttls fails with tls 1.3, enabled by default

[Bernhard Schmidt]

Control: tags -1 + pending

Hi Fabio,

Am 07.03.23 um 17:00 schrieb Fabio PEDRETTI:

Hi, 3.2.1 currently in testing fixed most issues, however there is
still an issue preventing freeradius working with TLS 1.3.

The issue was reported upstream at:
https://github.com/FreeRADIUS/freeradius-server/issues/4878
and the commit fixing it is:
https://github.com/FreeRADIUS/freeradius-server/commit/0812bc1768cedc420adc03e86893d798fa19e872

That commit is already included in upstream 3.2.2.

So please consider upgrading to 3.2.2 (suggested, given this release
also fixes some other bugs), or apply the mentioned commit.

I updated the severity and forwarded bug reflecting this.


Thanks a lot for the investigation.

I have just uploaded 3.2.1-2 to the archive, could you please test this 
version? Importing the new 3.2.2 upstream version at this stage of the 
release freeze is not possible, see 
https://release.debian.org/testing/freeze_policy.html .


Bernhard

Bug#877106: pinta: Pinta 1.6-2 crashes on image scaling and other image manipulation.

[Bernhard Übelacker]

  at  <0x>
  at (wrapper managed-to-native) GLib.SList.g_free (intptr) <0x0005f>
  at GLib.ListBase.Empty () <0x0013c>
  at GLib.ListBase.Dispose (bool) <0xf>
  at GLib.ListBase.Finalize () <0x0001d>
  at (wrapper runtime-invoke) 
object.runtime_invoke_virtual_void__this__(object,intptr,intptr,intptr) 
<0x00068>





Dear Maintainer,
I took a look at the bug report [1] and guess this crash in Pinta
could be caused by the same error.

Therefore it might be interesting if this crash in Pinta could
also be fixed by rebuilding the gtk-sharp2 package with
the upstream patch [2] applied?





[1] https://bugs.debian.org/1028220
[2] 
https://github.com/mono/gtk-sharp/commit/72637de6f2e519592f946a5acdf29a334c7bff75

Bug#1027952: pcre2 causes crashes in link-grammar

[Bernhard Übelacker]

Dear Maintainer,
I tried to reproduce this segfault.
Unfortunately this did not work as expected.
The segfault in multi-thread did not show up.
But I received one in multi-dict (in e.g. 3 of 6 runs).

This was done in a up-to-date unstable amd64 VM,
running at a AMD cpu, 16 threads given to the VM.

The segfault did manifest in each case in libhunspell.
This seems to be caused by the static variable "utf_tbl"
possibly being shared between threads, and being freed and
initialized while maybe used in another thread.

Kind regards,
Bernhard


(gdb) bt
#0  0x7f56b5b3159b in unicodetolower(unsigned short, int) () from 
/lib/x86_64-linux-gnu/libhunspell-1.7.so.0
#1  0x7f56b5b317ae in get_captype_utf8(std::vector 
> const&, int) () from /lib/x86_64-linux-gnu/libhunspell-1.7.so.0
#2  0x7f56b5b385bc in ?? () from /lib/x86_64-linux-gnu/libhunspell-1.7.so.0
...
(gdb) bt
#0  0x7f56b5b3159b in unicodetolower (c=c@entry=116, 
langnum=langnum@entry=0) at ./src/hunspell/csutil.cxx:2482
#1  0x7f56b5b317ae in get_captype_utf8 (word=std::vector of length 6, 
capacity 64 = {...}, langnum=0) at ./src/hunspell/csutil.cxx:2538
#2  0x7f56b5b385bc in HashMgr::get_clen_and_captype (workbuf=std::vector of length 6, 
capacity 64 = {...}, captype=, word="tenant", 
this=0x7f568eb64d90) at ./src/hunspell/hashmgr.cxx:468
#3  HashMgr::get_clen_and_captype (workbuf=..., captype=, 
word=..., this=0x7f568eb64d90) at ./src/hunspell/hashmgr.cxx:464
#4  HashMgr::load_tables (this=0x7f568eb64d90, tpath=, 
key=) at ./src/hunspell/hashmgr.cxx:690
#5  0x7f56b5b38dfc in HashMgr::HashMgr (this=this@entry=0x7f568eb64d90, 
tpath=tpath@entry=0x7f56adffa800 "/usr/share/hunspell/en_US.dic", 
apath=apath@entry=0x7f56adffa400 "/usr/share/hunspell/en_US.aff", key=key@entry=0x0) at 
./src/hunspell/hashmgr.cxx:101
#6  0x7f56b5b43616 in HunspellImpl::HunspellImpl (this=0x7f568fb8c850, affpath=0x7f56adffa400 
"/usr/share/hunspell/en_US.aff", dpath=0x7f56adffa800 
"/usr/share/hunspell/en_US.dic", key=0x0) at ./src/hunspell/hunspell.cxx:179
#7  0x7f56b5b43a27 in Hunspell_create (affpath=affpath@entry=0x7f56adffa400 
"/usr/share/hunspell/en_US.aff", dpath=dpath@entry=0x7f56adffa800 
"/usr/share/hunspell/en_US.dic") at ./src/hunspell/hunspell.cxx:2164
#8  0x7f56b60decc1 in spellcheck_create (lang=0x7f568d0e22c0 "en") at 
tokenize/spellcheck-hun.c:101
#9  0x7f56b60af6e5 in dictionary_six_str (lang=lang@entry=0x560b8f8ac37a "en", input=input@entry=0x7f568f9bc460 "\n %", '*' , 
"%\n %", ' ' , "%\n %   Copyright (C) 1991-1998  Daniel "..., dict_name=dict_name@entry=0x7f568fa3e630 "en/4.0.dict", 
pp_name=pp_name@entry=0x7f568fa3e6f0 "en/4.0.knowledge", cons_name=cons_name@entry=0x7f568fa3e8e0 "en/4.0.constituent-knowledge", 
affix_name=affix_name@entry=0x7f568fa3e930 "en/4.0.affix", regex_name=0x7f568fa3e070 "en/4.0.regex") at dict-file/dictionary.c:159
#10 0x7f56b60afc28 in dictionary_six (regex_name=0x7f568fa3e070 "en/4.0.regex", affix_name=0x7f568fa3e930 
"en/4.0.affix", cons_name=0x7f568fa3e8e0 "en/4.0.constituent-knowledge", pp_name=0x7f568fa3e6f0 
"en/4.0.knowledge", dict_name=0x7f568fa3e630 "en/4.0.dict", lang=0x560b8f8ac37a "en") at 
dict-file/dictionary.c:281
#11 dictionary_create_from_file (lang=0x560b8f8ac37a "en") at 
dict-file/dictionary.c:307
#12 0x560b8f8ab598 in parse_one_sent (sent_str=0x560b8f8ac248 "The line extends 
10 miles offshore.") at ./tests/multi-dict.cc:28
#13 parse_sents (thread_id=, niter=30) at 
./tests/multi-dict.cc:82
#14 0x7f56b5ed44a3 in std::execute_native_thread_routine 
(__p=0x560b90a39a70) at ../../../../../src/libstdc++-v3/src/c++11/thread.cc:82
#15 0x7f56b5ca7fd4 in start_thread (arg=) at 
./nptl/pthread_create.c:442
#16 0x7f56b5d2866c in clone3 () at 
../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

2482  return (utf_tbl) ? utf_tbl[c].clower : c;

=> 0x7f56b5b3159b <_Z14unicodetolowerti+27>:movzwl 0x4(%rdx,%rax,2),%eax
(gdb) print/x $rdx
$49 = 0x7f56ac614010
(gdb) print/x $rax
$50 = 0x15c
(gdb) x/1xg ($rdx + $rax * 2) + 0x4
0x7f56ac6142cc: Cannot access memory at address 0x7f56ac6142cc
(gdb) print utf_tbl
$51 = (unicode_info2 *) 0x0
# Unstable amd64 qemu VM 2023-01-20

apt update
apt dist-upgrade

apt install systemd-coredump mc gdb valgrind rr autopkgtest dpkg-dev 
libhunspell-1.7-0-dbgsym libstdc++6-dbgsym
apt build-dep link-grammar

autopkgtest --shell-fail link-grammar -- null



PASS: mem-leak
PASS: multi-java
PASS: dict-reopen
../test-driver: Zeile 112: 12435 Speicherzugriffsfehler  (Speicherabzug 
geschrieben) "$@" >> "$log_file" 2>&1
FAIL: multi-dict
PASS: multi-thread
===
  

Bug#1026069: scrcpy: Bug#1026069: Cannot find symbols during build

[Bernhard Übelacker]

On Wed, 14 Dec 2022 10:07:27 +0100 martin f krafft  
wrote:

Package: scrcpy
Version: 1.24-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)

Running `apt build-dep scrcpy` and `fakeroot debian/rules binary` 
results in plenty of unresolvable symbols.



Hello Martin,
I could not reproduce an issue inside a minimal unstable VM.

The package builds with "fakeroot debian/rules binary" and
"dpkg-buildpackage" without showing an error.

Can you still reproduce it?

Kind regards,
Bernhard

Bug#1025498: scrcpy: Bug#1025498: Links to old libavdevice58

[Bernhard Übelacker]

On Mon, 5 Dec 2022 21:33:03 +0100 martin f krafft  wrote:

Package: scrcpy
Version: 1.24-1
Severity: grave

The package depends on libavdevice59, but it's apparently built 
against libavdevice58:


lotus:~% ldd =scrcpy | grep libavdevice
  libavdevice.so.58 => not found



Hello Martin,
can you still reproduce this issue?

I have installed scrcpy inside a minimal unstable VM,
and receive the output below [1].

Also the build log [2] seems to show that libavdevice59
was installed during package build.

Your ldd shows "=scrcpy" instead of an absolute path,
does it really point to the binary from the package?

Kind regards,
Bernhard


[1]
benutzer@debian:~$ ldd /usr/bin/scrcpy | grep libavdevice
libavdevice.so.59 => /lib/x86_64-linux-gnu/libavdevice.so.59 
(0x7fa06f9cd000)
benutzer@debian:~$ dpkg -l | grep scrcpy
ii  scrcpy1.24-1 amd64  
  Display and control your Android device
ii  scrcpy-server 1.24-1 all
  Display and control your Android device - server binary


[2] 
https://buildd.debian.org/status/fetch.php?pkg=scrcpy&arch=amd64&ver=1.24-1&stamp=1658088686&raw=0
Unpacking libavdevice59:amd64 (7:5.0.1-3+b1) ...
Unpacking libavdevice-dev:amd64 (7:5.0.1-3+b1) ...

Bug#1011437: Should bind9-libs be shipped in bookworm?

[Bernhard Schmidt]

Hi,

not about src:bind9, building the bind9-libs binary package (yes, this 
is totally confusing, even to Debian tooling)


I though that had been already removed: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011538 
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011538>


But I guess something went wrong and perhaps **just** binary bind9-libs 
was removed instead.


Eheehe, this explains 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1018016


Unless you beat me to it, I'll give it another RM stab.

Bernhard

Bug#1011437: Should bind9-libs be shipped in bookworm?

[Bernhard Schmidt]

Am 09.01.23 um 14:30 schrieb Ondřej Surý:

Hi Ondrej,


Looking at #942501 and #942502, the intention seems to be to not
ship bind9-libs in bookworm.


I agree, Ccing Ondrej who has done the heavy lifting on this package.

AFAICT there is no binary reverse dependency in unstable, and #942501
"just" needs a NMU for the removed build-dep.

Ondrej, what do you think?


No, not really. The bind9-libs package contains shared libraries for

bind9, bind9-dnsutils, bind9-host and bind9-utils package.

We could drop bind9-dev, but that was required by the bind9-dyndb-ldap
plugin - that's the thing that might be useful to solve, but then again, 
RedHat

chose GPL for the project, so there's little we can do in both upstream and
downstream - we certainly don't want to re-licence whole BIND 9 to GPL
because of the bundled plugin. I would rather keep them separate even
if it's painful.


Hum, either I got something totally wrong or we are talking about 
different things.


This thread is about src:bind9-libs, still on the 9.11 code train and 
building


libbind-dev
libbind-export-dev
libbind9-161
libdns-export1110
libdns-export1110-udeb
libdns1110
libirs-export161
libirs-export161-udeb
libirs161
libisc-export1105
libisc-export1105-udeb
libisc1105
libisccc-export161
libisccc-export161-udeb
libisccc161
libisccfg-export163
libisccfg-export163-udeb
libisccfg163
liblwres161

not about src:bind9, building the bind9-libs binary package (yes, this 
is totally confusing, even to Debian tooling)


Bernhard

Bug#1011437: Should bind9-libs be shipped in bookworm?

[Bernhard Schmidt]

On 22/05/22 11:47 PM, Adrian Bunk wrote:

> Looking at #942501 and #942502, the intention seems to be to not
> ship bind9-libs in bookworm.

I agree, Ccing Ondrej who has done the heavy lifting on this package.

AFAICT there is no binary reverse dependency in unstable, and #942501
"just" needs a NMU for the removed build-dep.

Ondrej, what do you think?

Bernhard

Bug#1004154: Fwd: Bug#1004154: xserver-xorg-video-qxl: XOrg frequently crashes when using qxl driver: qxl(0): error doing QXL_ALLOC

[Bernhard Übelacker]

Forwarding, as the email from TJ possibly did not reach Felix.


On Fri, 21 Oct 2022 11:43:07 +0100 TJ  wrote:

On Sat, 12 Feb 2022 08:21:55 + Felix Leimbach  wrote:
> I noticed that vgamem_mb was still low (32 MB).
> So I changed to this (slightly wasteful) command-line and am now running the 
latest kernel (5.15.0-3-amd64):
> 
> -vga none -device qxl-vga,ram_size_mb=256,vgamem_mb=256,vram_size_mb=256,vram64_size_mb=256,max_outputs=1
> 
> Will report back if that helps.


Did the vgamem_mb change fix the issue?

This bug is currently keeping the package out of bookworm and, if it was 
a user-specific issue, ought to be closed and the package reintroduced 
to bookworm.


I'm currently doing a full-upgrade bullseye to bookworm and this removal 
is a blocker for VMs.

Bug#1016963: Tests was successfully at BananaPi M3

[Bernhard]

Hello Vagrant

I tested the following versions successfully at the BananaPi M3:
- bookworm/testing: 2022.04+dfsg-2+b1
- sid/unstable: 2022.10+dfsg-2
- experimental: 2023.01~rc4+dfsg-1
I also updated the Wiki page.

Best regards
Bernhard


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

Bug#1027379: nfdump: FTBFS in bullseye (missing build-depends on tzdata)

[Bernhard Schmidt]

Control: tags -1 + pending
Control: tags -1 - moreinfo

Hi,

I have no problem fixing this up in unstable, but I think this does 
not warrant a stable update.


That would be unfortunate, as it means we will probably never have a 
stable release without FTBFS bugs.


"Never" is too hard, I will fix it in unstable targetting bookworm, so 
the next release should have it.


Since backporting those kind of bugs is completely trivial, I'm still 
aiming at having a stable distribution which is free from FTBFS bugs (of 
any kind). You are of course free not to help me in my goal, but it would
help immensely if every maintainer ensured that their own packages are 
free from FTBFS bugs in stable.


I somehow have my doubt that the release-team would be happy to have a 
lot of stable updates fixing just a FTBFS that does not happen with the 
default buildd configuration. I totally agree about the severity of 
other FTBFS bugs in stable.


Bernhard

Bug#1027379: nfdump: FTBFS in bullseye (missing build-depends on tzdata)

[Bernhard Schmidt]

Hi,

That's an odd one. I cannot reproduce it in any version, because in 
all my attempts (1.6.22-2 in a bullseye sbuild, in an sid sbuild, as 
well as in the build logs of the official buildds for all of 1.6.22-2, 
1.6.25-1 and 1.7.1-1) tzdata is actually installed in the build 
environment, even without additional build-dep.


tzdata is not really build essential, you should not install it in a 
chroot used to build packages from scratch. It follows from this that if 
you want to be sure that you don't miss build-dependencies, you should 
not accept debootstrap defaults when creating a chroot, as it installs

several packages which are not build-essential.

To reproduce, try building the package in a chroot which does not 
contain tzdata.


Both the official buildds and schroots created using the documented 
sbuild-createchroot then apparently do not follow recommended procedure?


I have no problem fixing this up in unstable, but I think this does not 
warrant a stable update.


BTW, it is reproducible using "sbuild --add-conflicts=tzdata"

Bernhard

Bug#1027379: nfdump: FTBFS in bullseye (missing build-depends on tzdata)

[Bernhard Schmidt]

Control: tags -1 + moreinfo

Hi Santiago,


During a rebuild of all packages in bullseye, your package failed to build:


[...]


Note: I'm using the "patch" tag because there is an obvious fix > (indicated in 
the subject).


That's an odd one. I cannot reproduce it in any version, because in all 
my attempts (1.6.22-2 in a bullseye sbuild, in an sid sbuild, as well as 
in the build logs of the official buildds for all of 1.6.22-2, 1.6.25-1 
and 1.7.1-1) tzdata is actually installed in the build environment, even 
without additional build-dep.


Bernhard

Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Bernhard Übelacker]

Am 01.01.23 um 16:55 schrieb Uecker, Martin:


This is likely a numerical error caused by reordering a
floating point sum by parallelization. It is not worth
spending time on it.

I can apply the patch, but I do not have much time now.
Is there some urgency?


Not from my side, I just tried to help debugging the issue.

Kind regards,
Bernhard

Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Bernhard Übelacker]

Hello,
thanks for your immediate responses.


Am 01.01.23 um 15:55 schrieb Uecker, Martin:


One could just relax (or simply remove) the test from bullseye
or packport the version bookworm.


I guess that would be applying 0003-relax-failing-unit-test.patch
to the Bullseye version.



The wine code is broken (it violates the effective types
rules of ISO C).


Ok, just wanted to offer an option.



Am 01.01.23 um 16:02 schrieb Santiago Vila:


Hi. Such failure rate differs a lot from what I get, which is
about 50% in some systems (which is why I believe we should fix this
in bullseye).

Maybe this is an issue of tests optimized for Intel and failing
a lot on AMD or viceversa (there was another package for which that
happened).



If it might be of any help - my system is a "AMD Ryzen 7 1700",
the qemu VM runs with "-enable-kvm -cpu host -smp 16".

By locking the process to just a single cpu I do not get any failures:
  taskset -c 0 bash -c "while true; do ./test_nufft ; done"

If I allow two cpus the failure rate is at 77%:
  taskset -c 0,1 bash -c "while true; do ./test_nufft ; done"


This still does not affect a Bookworm VM, no failures even with
the relax patch removed.


Kind regards,
Bernhard

Bug#1026061: bart: FTBFS randomly in bullseye (failing test)

[Bernhard Übelacker]

Dear Maintainer,
I could reproduce this failure in a bullseye VM.
There the "test_nufft_adjoint" fails in about 1.2 % of the runs.

Attached diff helps to make it more visible.

It looks like the float comparison fails because the
limit of "1.E-6f" is slightly not enough.

If interpret following floating point comparison document right,
then the failing cases are just 8 representable floats "ULPs"
away from the expected value, below 8 it does not fail.

  
https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/

Maybe upstream could consider changing that
float comparison to something like this:

  
https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ddraw/tests/ddraw7.c#l61


In the newer Bookworm package I have found following patch,
which does relax exactly this test:

  
https://salsa.debian.org/med-team/bart/-/blob/master/debian/patches/0003-relax-failing-unit-test.patch

But for some reason it does still not fail if I remove that
patch in the Bookworm version.

Kind regards,
Bernhard



make utest
while true; do ./test_nufft ; done


Bullseye/stable/bart-0.6.00:
- -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198080e+01 
sc2=6.3619926397041880e+01 diff=9.6109602054639254e-07 diff_ulp=7
adjoint diff: 0.01 9.6109602054639254e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.

- -1.067273+3.247030i - -1.067273+3.247030i - sc1=6.3619926397041830e+01 
sc2=6.3619926397041880e+01 diff=8.3446502685546875e-07 diff_ulp=7
adjoint diff: 0.01 8.3446502685546875e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.

- -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198087e+01 
sc2=6.3619926397041880e+01 diff=8.5963040419301251e-07 diff_ulp=6
adjoint diff: 0.01 8.5963040419301251e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.

- -1.067272+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198073e+01 
sc2=6.3619926397041880e+01 diff=1.0662403155947686e-06 diff_ulp=8
adjoint diff: 0.01 1.0662403155947686e-06, limit: 9.999747524271e-07
ERROR: ./test_nufft:  0/ 1 passed.

- -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198087e+01 
sc2=6.3619926397041880e+01 diff=8.5963040419301251e-07 diff_ulp=6
adjoint diff: 0.01 8.5963040419301251e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.

- -1.067273+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198080e+01 
sc2=6.3619926397041880e+01 diff=9.6109602054639254e-07 diff_ulp=7
adjoint diff: 0.01 9.6109602054639254e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.


Bookworm/testing/bart-0.8.00:
- -1.067272+3.247031i - -1.067273+3.247030i - sc1=6.3619987432198073e+01 
sc2=6.3619926397041880e+01 diff=1.0662403155947686e-06 diff_ulp=8
adjoint diff: 0.00 3.1195452265819767e-07, limit: 9.999747524271e-07
./test_nufft:  1/ 1 passed.diff --git a/src/linops/lintest.c b/src/linops/lintest.c
index c1d1ebc..b0e3bc1 100644
--- a/src/linops/lintest.c
+++ b/src/linops/lintest.c
@@ -59,7 +59,7 @@ static float linop_test_adjoint_generic(const struct linop_s* op, bool rvc)
 	md_free(tmp3);
 	md_free(tmp4);
 
-	debug_printf(DP_DEBUG4, "- %f%+fi - %f%+fi -\n", crealf(sc1), cimagf(sc1), crealf(sc2), cimagf(sc2));
+	debug_printf(DP_INFO, "- %f%+fi - %f%+fi - sc1=%.16e sc2=%.16e diff=%.16e diff_ulp=%d\n", crealf(sc1), cimagf(sc1), crealf(sc2), cimagf(sc2), sc1, sc2, cabsf(sc1 - sc2), abs(*(int*)&sc1 - *(int*)&sc2));
 
 	return cabsf(sc1 - sc2);
 }
diff --git a/utests/test_nufft.c b/utests/test_nufft.c
index ec02762..54163dc 100644
--- a/utests/test_nufft.c
+++ b/utests/test_nufft.c
@@ -112,7 +112,7 @@ static bool test_nufft_adjoint(void)
 
 	float diff = linop_test_adjoint(op);
 
-	debug_printf(DP_DEBUG1, "adjoint diff: %f\n", diff);
+	debug_printf(DP_INFO, "adjoint diff: %f %.16e, limit: %.16e\n", diff, diff, 1.E-6f);
 
 	bool ret = (diff < 1.E-6f);
 
@@ -231,13 +231,6 @@ static bool test_nufft_basis_toeplitz(void)
 
 
 
-UT_REGISTER_TEST(test_nufft_forward);
 UT_REGISTER_TEST(test_nufft_adjoint);
-UT_REGISTER_TEST(test_nufft_normal);
-UT_REGISTER_TEST(test_nufft_toeplitz_weights);
-UT_REGISTER_TEST(test_nufft_toeplitz_noweights);
-UT_REGISTER_TEST(test_nufft_basis_adjoint);
-UT_REGISTER_TEST(test_nufft_basis_normal);
-UT_REGISTER_TEST(test_nufft_basis_toeplitz);
 
 

Bug#1016963: Tests was successfully at BananaPi M2 Ultra

[Bernhard]

Hello Vagrant

Thank you for remind me to test.

I tested the following versions successfully at the BananaPi M2 Ultra:
- bookworm/testing: 2022.04+dfsg-2+b1
- sid/unstable: 2022.10+dfsg-2
- experimental: 2023.01~rc4+dfsg-1
I also updated the Wiki page.

Currently, i don't have access to my BananaPi M3.
I'll test this next week CW01/2023 and report back.

Thank you for the great work and a happy new year.

Best regards
Bernhard



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

Bug#1027094: FTBFS against bind9 9.18.10

[Bernhard Schmidt]

On 27/12/22 09:43 PM, Santiago Vila wrote:

> > bind-dyndb-ldap has a tight dependency on the upstream version of bind9-libs
> > (built by src:bind9) and needs to be rebuilt on every new upstream version
> > until https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 is fixed.
> 
> Hello. I suppose this is the reason it does not build in stable either.
> 
> Should we use the "found" directive with this bug,
> or it is better to file it as a separate bug?

I suspect this is a different bug (possibly for the same reason, changed
API within a stable release of bind9, but since the breaking code is
very fresh I doubt the same thing affects stable). So better file a new
one.

Bernhard

Bug#1027094: FTBFS against bind9 9.18.10

[Bernhard Schmidt]

Control: forwarded -1 https://pagure.io/bind-dyndb-ldap/issue/216

On 27/12/22 06:16 PM, Bernhard Schmidt wrote:

Hi,

so this is really massively broken :-(


> ../../src/log.h:21:9: error: too few arguments to function ‘isc_error_fatal’
>21 | isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__)
>   | ^~~

That one has been introduced in 9.18.9+. There is an open pull request
upstream at https://pagure.io/bind-dyndb-ldap/pull-request/215 , which
(together with bumping LIBDNS_VERSION_MAJOR in
d/p/hardcode-version.diff) fixes the logging errors.

> ../../src/ldap_driver.c: In function ‘allrdatasets’:
> ../../src/ldap_driver.c:474:71: error: passing argument 5 of 
> ‘dns_db_allrdatasets’ makes integer from pointer without a cast 
> [-Werror=int-conversion]
>   474 | return dns_db_allrdatasets(ldapdb->rbtdb, node, version, now, 
> iteratorp);
>   |   
> ^
>   |   
> |
>   |   
> dns_rdatasetiter_t ** {aka struct dns_rdatasetiter **}

Those appear to be new issues in 9.18.10. I have filed a new upstream
bugreport at https://pagure.io/bind-dyndb-ldap/issue/216 . Both
dns_db_allrdatasets and dns_zt_apply gained an additional argument

https://gitlab.isc.org/isc-projects/bind9/-/commit/1de9c052107a6f24e565441f53e4d8b33bb2e30a
https://gitlab.isc.org/isc-projects/bind9/-/commit/6f998bbe518ae629685404bcfddcfd6067176660

and while my attempts to monkeypatch the additional 0 argument into
dns_db_allrdatasets cleared most of the warnings I'm lost with the
remaining errors. Does not really help that I barely know C, my
knowledge ends pretty much here and I have no idea how to go further.

In file included from ../../src/zone_register.h:8,
 from ../../src/ldap_convert.c:28:
/usr/include/dns/zt.h:171:28: error: unknown type name ‘isc_rwlocktype_t’; did 
you mean ‘isc_rwlock_t’?
  171 | dns_zt_apply(dns_zt_t *zt, isc_rwlocktype_t lock, bool stop, 
isc_result_t *sub,
  |^~~~
  |isc_rwlock_t


libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../src -I.. -Wdate-time 
-D_FORTIFY_SOURCE=2 -Wall -Wextra -Werror -std=gnu99 -O2 -g -O2 
-ffile-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wno-uninitialized -fvisibility=hidden 
-fno-delete-null-pointer-checks -std=gnu11 -c ../../src/ldap_helper.c  -fPIC 
-DPIC -o .libs/ldap_la-ldap_helper.o
../../src/ldap_driver.c:950:9: error: initialization of ‘isc_result_t 
(*)(dns_db_t *, dns_dbnode_t *, dns_dbversion_t *, unsigned int,  
isc_stdtime_t,  dns_rdatasetiter_t **)’ {aka ‘enum isc_result (*)(struct dns_db 
*, void *, void *, unsigned int,  unsigned int,  struct dns_rdatasetiter **)’} 
from incompatible pointer type ‘isc_result_t (*)(dns_db_t *, dns_dbnode_t *, 
dns_dbversion_t *, isc_stdtime_t,  dns_rdatasetiter_t **)’ {aka ‘enum 
isc_result (*)(struct dns_db *, void *, void *, unsigned int,  struct 
dns_rdatasetiter **)’} [-Werror=incompatible-pointer-types]
  950 | allrdatasets,
  | ^~~~
../../src/ldap_driver.c:950:9: note: (near initialization for 
‘ldapdb_methods.allrdatasets’)

Bug#1027094: FTBFS against bind9 9.18.10

[Bernhard Schmidt]

Source: bind-dyndb-ldap
Version: 11.10-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: team+...@tracker.debian.org

bind-dyndb-ldap has a tight dependency on the upstream version of bind9-libs
(built by src:bind9) and needs to be rebuilt on every new upstream version
until https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014503 is fixed.

This worked fine until bind9 9.18.8, but fails in 9.18.10

https://buildd.debian.org/status/fetch.php?pkg=bind-dyndb-ldap&arch=amd64&ver=11.10-1%2Bb5&stamp=1671812545&raw=0

This is rather serious as it prevents the migration of 9.18.10 to testing
which includes systemd notify support and upstream bugfixes. Also bind9 has
followed upstream security releases during bullseye already, so it will
break later if 9.18.10 misses the freeze due to this issue.

Possible commits:
https://gitlab.isc.org/isc-projects/bind9/-/compare/v9_18_8...v9_18_10?from_project_id=1

In file included from ../../src/zone_register.h:8,
 from ../../src/ldap_convert.c:28:
/usr/include/dns/zt.h:171:28: error: unknown type name ‘isc_rwlocktype_t’; did 
you mean ‘isc_rwlock_t’?
  171 | dns_zt_apply(dns_zt_t *zt, isc_rwlocktype_t lock, bool stop, 
isc_result_t *sub,
  |^~~~
  |isc_rwlock_t
make[3]: *** [Makefile:592: ldap_la-ldap_convert.lo] Error 1
make[3]: *** Waiting for unfinished jobs
In file included from ../../src/util.h:17,
 from ../../src/bindcfg.h:10,
 from ../../src/ldap_driver.c:39:
../../src/ldap_driver.c: In function ‘beginload’:
../../src/log.h:21:9: error: too few arguments to function ‘isc_error_fatal’
   21 | isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__)
  | ^~~
../../src/ldap_driver.c:220:9: note: in expansion of macro ‘fatal_error’
  220 | fatal_error("ldapdb: method beginload() should never be 
called");
  | ^~~
In file included from /usr/include/isc/util.h:312,
 from /usr/include/isc/atomic.h:22,
 from /usr/include/isc/refcount.h:19,
 from ../../src/ldap_driver.c:16:
/usr/include/isc/error.h:42:1: note: declared here
   42 | isc_error_fatal(const char *, int, const char *, const char *, ...)
  | ^~~
../../src/ldap_driver.c: In function ‘endload’:
../../src/log.h:21:9: error: too few arguments to function ‘isc_error_fatal’
   21 | isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__)
  | ^~~
../../src/ldap_driver.c:237:9: note: in expansion of macro ‘fatal_error’
  237 | fatal_error("ldapdb: method endload() should never be called");
  | ^~~
/usr/include/isc/error.h:42:1: note: declared here
   42 | isc_error_fatal(const char *, int, const char *, const char *, ...)
  | ^~~
../../src/ldap_driver.c: In function ‘dump’:
../../src/log.h:21:9: error: too few arguments to function ‘isc_error_fatal’
   21 | isc_error_fatal(__FILE__, __LINE__, __VA_ARGS__)
  | ^~~
../../src/ldap_driver.c:266:9: note: in expansion of macro ‘fatal_error’
  266 | fatal_error("ldapdb: method dump() should never be called");
  | ^~~
/usr/include/isc/error.h:42:1: note: declared here
   42 | isc_error_fatal(const char *, int, const char *, const char *, ...)
  | ^~~
../../src/ldap_driver.c: In function ‘allrdatasets’:
../../src/ldap_driver.c:474:71: error: passing argument 5 of 
‘dns_db_allrdatasets’ makes integer from pointer without a cast 
[-Werror=int-conversion]
  474 | return dns_db_allrdatasets(ldapdb->rbtdb, node, version, now, 
iteratorp);
  |   
^
  |   |
  |   
dns_rdatasetiter_t ** {aka struct dns_rdatasetiter **}
In file included from ../../src/ldap_driver.c:22:
/usr/include/dns/db.h:1162:57: note: expected ‘isc_stdtime_t’ {aka ‘unsigned 
int’} but argument is of type ‘dns_rdatasetiter_t **’ {aka ‘struct 
dns_rdatasetiter **’}
 1162 | unsigned int options, isc_stdtime_t now,
  |   ~~^~~
../../src/ldap_driver.c:474:16: error: too few arguments to function 
‘dns_db_allrdatasets’
  474 | return dns_db_allrdatasets(ldapdb->rbtdb, node, version, now, 
iteratorp);
  |^~~
/usr/include/dns/db.h:1161:1: note: declared here
 1161 | dns_db_allrdatasets(dns_db_t *db, dns_dbnode_t *node, dns_dbversion_t 
*version,
  | ^~~
../../src/ldap_driver.c: In function ‘node_isempty’:
../../src/ldap_driver.c:517:62: error: passing argument 5 of 
‘dns_db_allrdatasets’ makes integer from po

Bug#1024438: mutter: autopkgtest regression: segfault in workspace-basic.metatest

[Bernhard Übelacker]

Am 18.12.22 um 16:58 schrieb Simon McVittie:


I was unable to reproduce this in a test VM, ...
..., but it is reproducible
on my laptop. Perhaps it's only reproducible if mutter has access to
some resource that my ssh login session to my test VM lacks, or perhaps
there's a race condition that makes this timing-dependent?



Hello Simon,
I forgot to mention that I had to add to
my qemu test VM this graphics configuration:

   -device virtio-vga-gl -display gtk,gl=on

Kind regards,
Bernhard

Bug#1024824: The software outputs: "No access to printer device file" ...

[Bernhard Übelacker]

The software outputs: "No access to printer device file".

Normal user should be added to lp group to make `mtink` work
and it has been added to it indeed, so it is in the /etc/group file
beside the `lp` and `lpadmin` groups, yet the software seems
to be unable to access device file from the USB-conncted EPSON XP-2100. 


Dependencies and suggestions are installed in the system.

I have experienced this package to be working on Ubuntu 22.04 a month ago.




Hello Nicholas,
I guess the Maintainer would need more information about this issue.
A first step might be to provide a "strace" of a mtink startup.

Therefore please install the packages: bsdutils strace

Then execute following line in a terminal:
  script -c "LANG=C strace -f mtink" -a "mtink-strace_$(date 
+%Y-%m-%d_%H-%M-%S).log"

This will create a file like mtink-strace_2022-12-11_14-16-46.log
Maybe you could compress this file and attach it to your answer to this mail?
(Please use the "reply all", to have the bug in CC in your answer.)

Kind regards,
Bernhard

Bug#1025659: libgl1-mesa-dri: mesa causes xorg segfault; regression against 22.2.0-1

[Bernhard Übelacker]

After updating mesa from 22.2.0-1 to 22.3.0-2 (according to dpkg.log)
earlier today U.S. time as part of a routine upgrade to up-to-date sid,
the greeter stopped appearing, and over the course of the last two hours
we chased it down to that upgrade, which made X.org die with
  iris_dri.so (nouveau_drm_screen_create+[three addresses])
  iris_dri.so (?+0x0)
  iris_dri.so (__driDriverGetExtensions_d3d12+[three addresses])
in the backtrace of a segfault at 0x20.

This may be tangentially related to other d3d12 fuckups in 22.3.0,
like #1025312, given the timeline and d3d12ness.



00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 630 
[8086:591b] (rev 04)



Dear Maintainer,
I tried to reconstruct a better backtrace with the
help of the dbgsym packages.

What I find strange is the system has a Intel GPU, but
is calling in some nouveau functions?

Kind regards,
Bernhard


...ebc in nouveau_pushbuf_destroy at 
../src/gallium/drivers/nouveau/nouveau_screen.c:244  
(nouveau_drm_screen_create+0x4406c)
...319 in nvc0_screen_destroy at 
../src/gallium/drivers/nouveau/nvc0/nvc0_screen.c:740
(nouveau_drm_screen_create+0x1e4c9)
...0b6 in nouveau_drm_screen_create at 
../src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:133 
(nouveau_drm_screen_create+0x266)
...df6 in pipe_nouveau_create_screen at 
../src/gallium/auxiliary/target-helpers/drm_helper.h:144  (0x7f205d0a9df6)
...0c4 in pipe_loader_create_screen_vk at 
../src/gallium/auxiliary/pipe-loader/pipe_loader.c:175  
(__driDriverGetExtensions_d3d12+0x60ad84)
...dd3 in dri2_init_screen at ../src/gallium/frontends/dri/dri2.c:2265  
  (__driDriverGetExtensions_d3d12+0x1a93)
...4b5 in driCreateNewScreen2 at ../src/gallium/frontends/dri/dri_util.c:143
  (__driDriverGetExtensions_d3d12+0xa175)
...eae in dri_screen_create_dri2 at ../src/gbm/backends/dri/gbm_dri.c:434   
  (gbm_format_get_name+0xf2e)
...678 in dri_screen_create at ../src/gbm/backends/dri/gbm_dri.c:511
  (gbm_format_get_name+0x16f8)
...74c in backend_create_device at ../src/gbm/main/backend.c:101
  (0x7f205edc274c)
...884 in gbm_create_device at ../src/gbm/main/gbm.c:138
  (gbm_create_device+0x44)
...3c1 in glamor_egl_init at ../../../../../../glamor/glamor_egl.c:947  
  (glamor_egl_init+0x61)
...733 in try_enable_glamor at 
../../../../../../../hw/xfree86/drivers/modesetting/driver.c:945   
(0x7f205f118733)
...56a in InitOutput at ../../../../../../hw/xfree86/common/xf86Init.c:490  
  (InitOutput+0xa2a)
...


The crashing instruction:  (the 0x20 offset matches, maybe NULL given to 
nouveau_pushbuf_destroy?)

   0x75f56ebc : mov0x20(%rax),%rdi


https://sources.debian.org/src/mesa/22.3.0-2/src/gallium/drivers/nouveau/nouveau_screen.c/#L244
241 void
242 nouveau_pushbuf_destroy(struct nouveau_pushbuf **push)
243 {
244FREE((*push)->user_priv);
245nouveau_pushbuf_del(push);
246 }

Bug#1024438: mutter: autopkgtest regression: Segmentation fault

[Bernhard Übelacker]

Hello,
I tried to collect some informations.

The segfault happens because "workspace" contains a null pointer.
This null originates from "window->workspace".

Kind regards,
Bernhard



Core was generated by 
`/usr/libexec/installed-tests/mutter-11/mutter-test-runner --all'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xb7ce33f4 in meta_workspace_index (workspace=0x0) at 
../src/core/workspace.c:722
722   ret = g_list_index (workspace->manager->workspaces, workspace);
[Current thread is 1 (Thread 0xb5082980 (LWP 11034))]
(gdb) bt
#0  0xb7ce33f4 in meta_workspace_index (workspace=0x0) at 
../src/core/workspace.c:722
#1  0xb2e96606 in switch_workspace (plugin=0xe9f200 [MetaDefaultPlugin], 
from=0, to=1, direction=META_MOTION_RIGHT) at 
../src/compositor/plugins/default.c:572
#2  0xb7c9e3a0 in meta_plugin_manager_switch_workspace (plugin_mgr=0xe9b3e0, 
from=0, to=1, direction=META_MOTION_RIGHT) at 
../src/compositor/meta-plugin-manager.c:272
#3  0xb7c94a98 in meta_compositor_switch_workspace (compositor=0xc0e9c0 
[MetaCompositorNative], from=0xe7a320 [MetaWorkspace], to=0xe7a370 
[MetaWorkspace], direction=META_MOTION_RIGHT) at 
../src/compositor/compositor.c:682
#4  0xb7ce5a2f in meta_workspace_activate_with_focus (workspace=0xe7a370 
[MetaWorkspace], focus_this=0x0, timestamp=492883) at 
../src/core/workspace.c:684
#5  0xb7ce5c1e in meta_workspace_activate (workspace=0xe7a370 [MetaWorkspace], 
timestamp=492883) at ../src/core/workspace.c:714
#6  0x0047d8a5 in test_case_do (error=0xbfeb8408, argv=, 
argc=, test=0xece680) at ../src/tests/test-runner.c:1068
#7  run_test (index=, filename=0xac7e20 
"/usr/share/mutter-11/tests/stacking/workspace-basic.metatest", context=) at ../src/tests/test-runner.c:1280
#8  run_tests (context=0xaa4c58 [MetaContextTest], info=0xbfeb8934) at 
../src/tests/test-runner.c:1361
#9  0xb5de77d8 in ffi_call_i386 () at ../src/x86/sysv.S:121
#10 0xb5de6d97 in ffi_call_int (cif=, fn=, rvalue=, rvalue@entry=0xbfeb8570, avalue=, closure=) at 
../src/x86/ffi.c:406
#11 0xb5de7001 in ffi_call (cif=, fn=, 
rvalue=0xbfeb8570, avalue=0xbfeb8530) at ../src/x86/ffi.c:415
#12 0xb7a6f8d5 in g_cclosure_marshal_generic_va (closure=, return_value=, 
instance=, args_list=, marshal_data=, 
n_params=, param_types=) at ../../../gobject/gclosure.c:1650
#13 0xb7a6eed6 in _g_closure_invoke_va (closure=0xab5eb0, return_value=0xbfeb8718, 
instance=0xaa4c58, args=0xbfeb87bc "ȇ\353\277\005", n_params=0, 
param_types=0x0) at ../../../gobject/gclosure.c:895
#14 0xb7a87e4a in g_signal_emit_valist (instance=, signal_id=, detail=, var_args=) at 
../../../gobject/gsignal.c:3456
#15 0xb7a88005 in g_signal_emit (instance=0xaa4c58, signal_id=3, detail=0) at 
../../../gobject/gsignal.c:3606
#16 0xb7eecdb8 in run_tests_idle (user_data=0xaa4c58) at 
../src/tests/meta-context-test.c:221
#17 0xb76fb41e in g_main_dispatch (context=0xaa93f0) at 
../../../glib/gmain.c:3444
#18 g_main_context_dispatch (context=0xaa93f0) at ../../../glib/gmain.c:4162
#19 0xb76fb819 in g_main_context_iterate (context=0xaa93f0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4238
#20 0xb76fbb31 in g_main_loop_run (loop=) at 
../../../glib/gmain.c:4438
#21 0xb7cc2c33 in meta_context_run_main_loop (context=0xaa4c58 
[MetaContextTest], error=0xbfeb88e8) at ../src/core/meta-context.c:453
#22 0xb7eed30c in meta_context_test_run_tests (context_test=0xaa4c58 
[MetaContextTest], flags=META_TEST_RUN_FLAG_NONE) at 
../src/tests/meta-context-test.c:283
#23 0x0047aa29 in main (argc=, argv=) at 
../src/tests/test-runner.c:1483

(gdb) print workspace
$1 = 0x0

(gdb) list meta_workspace_index
716
717 int
718 meta_workspace_index (MetaWorkspace *workspace)
719 {
720   int ret;
721
722   ret = g_list_index (workspace->manager->workspaces, workspace);
723   g_return_val_if_fail (ret >= 0, -1);





(gdb) up
#1  0xb2e96606 in switch_workspace (plugin=0xe9f200 [MetaDefaultPlugin], 
from=0, to=1, direction=META_MOTION_RIGHT) at 
../src/compositor/plugins/default.c:572
572   win_workspace = meta_workspace_index (workspace);

(gdb) print window->on_all_workspaces
$2 = 0
(gdb) print window->workspace
$3 = 0x0

(gdb) list switch_workspace
...
567 {
568   MetaWorkspace *workspace;
569   gint   win_workspace;
570
571   workspace = meta_window_get_workspace (window);
572   win_workspace = meta_workspace_index (workspace);
573
574   if (win_workspace == to || win_workspace == from)

Bug#1024169: csound breaks csound-plugins autopkgtest: *** stack smashing detected ***: terminated

[Bernhard Übelacker]

Just a short addition:
There is already an upstream bug reported:

https://github.com/csound/csound/issues/1651

Kind regards,
Bernhard

Bug#1024169: csound breaks csound-plugins autopkgtest: *** stack smashing detected ***: terminated

[Bernhard Übelacker]

Dear Maintainer,
this looks like caused by a disaggrement about the size of type OPARMS.
In libcsound64-6.0 it has 264 bytes, but in csound-plugins
only 260 bytes.

This difference is caused by the last member "mp3_mode", that is missing
in the OPARMS type used in csound-plugins.
It got introduced in commit [1] and caused this ABI break.

Attached are relevant parts of the debugging.

Kind regards,
Bernhard

[1] 
https://github.com/csound/csound/commit/11df83f60d6afa51e5e0d25dc5efe5b2beec621e

(rr) bt
#0  0xb7a1e4f6 in memcpy (__len=264, __src=0x10d3de0, __dest=0xbfb5aee8) at 
/usr/include/i386-linux-gnu/bits/string_fortified.h:29
#1  csoundGetOParms (csound=, p=0xbfb5aee8) at ./Top/csound.c:230
#2  0xb51310c0 in csoundModuleInit (csound=0x10c61a0) at ./widgets/winFLTK.c:73
#3  0xb7b6388a in csoundInitModule (csound=csound@entry=0x10c61a0, 
m=m@entry=0x11baed8) at ./Top/csmodule.c:249
#4  0xb7b63a51 in csoundInitModules (csound=0x10c61a0) at ./Top/csmodule.c:825
#5  0xb7a233f5 in csoundReset (csound=) at ./Top/csound.c:3554
#6  0xb7a23af4 in csoundCreate (hostdata=0x0) at ./Top/csound.c:1361
#7  0x004c24c7 in main (argc=3, argv=0xbfb5b224) at 
./Frontends/csound/csound_main.c:322
# Unstable i386 qemu VM 2022-11-15

apt update
apt dist-upgrade

apt install systemd-coredump gdb rr autopkgtest dpkg-dev csound csound-plugins 
python3-csound csound-plugins-dbgsym libcsound64-6.0-dbgsym csound-dbgsym





$ autopkgtest csound-plugins --shell-fail -- null
autopkgtest [23:05:23]: starting date and time: 2022-11-15 23:05:23+0100
autopkgtest [23:05:23]: version 5.27
autopkgtest [23:05:23]: host debian; command line: /usr/bin/autopkgtest 
csound-plugins --shell-fail -- null
autopkgtest [23:05:23]: testbed dpkg architecture: i386
autopkgtest [23:05:23]: testbed running kernel: Linux 6.0.0-4-686-pae #1 SMP 
PREEMPT_DYNAMIC Debian 6.0.8-1 (2022-11-11)
autopkgtest [23:05:23]:  apt-source csound-plugins
gpgv: unknown type of key resource 'trustedkeys.kbx'
gpgv: Schlüsselblockhilfsmittel`/tmp/dpkg-verify-sig.OC9zItqO/trustedkeys.kbx': 
General error
gpgv: Signatur vom Mi 28 Sep 2022 09:29:57 CEST
gpgv:mittels RSA-Schlüssel 
7405E745574809734800156DB65019C47F7A36F8
gpgv: Signatur kann nicht geprüft werden: No public key
dpkg-source: Warnung: Signatur ./csound-plugins_1.0.2~dfsg1-2.dsc kann nicht 
überprüft werden
autopkgtest [23:05:24]: testing package csound-plugins version 1.0.2~dfsg1-2
autopkgtest [23:05:24]: build not needed
autopkgtest [23:05:24]: test command1: preparing testbed
autopkgtest [23:05:24]: test command1: csound --nosound 
py/examples/embeddedCtcsound.csd
autopkgtest [23:05:24]: test command1: [---
*** stack smashing detected ***: terminated

csound command: Aborted

csound command: Segmentation fault
autopkgtest [23:05:25]: test command1: ---]
autopkgtest [23:05:25]: test command1:  - - - - - - - - - - results - - - - - - 
- - - -
command1 FAIL non-zero exit status 1
autopkgtest [23:05:25]:  - - - - - - - - - - running shell - - - - - - - - - -
benutzer@debian:/tmp/autopkgtest.2VfrCV/build.Tvx/src$ rr record csound 
--nosound py/examples/embeddedCtcsound.csd
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/csound-0'.
*** stack smashing detected ***: terminated

csound command: Aborted

csound command: Segmentation fault
$ rr replay -o -q csound-0
Reading symbols from /usr/bin/csound...
(No debugging symbols found in /usr/bin/csound)
Really redefine built-in command "restart"? (y or n) [answered Y; input not 
from terminal]
Really redefine built-in command "jump"? (y or n) [answered Y; input not from 
terminal]
Remote debugging using 127.0.0.1:3587
Reading symbols from /lib/ld-linux.so.2...
Reading symbols from 
/usr/lib/debug/.build-id/9b/f5ef863480886a4c2159e109d63c656ca30739.debug...
BFD: warning: system-supplied DSO at 0x6fffd000 has a section extending past 
end of file
0xb7f40450 in _start () from /lib/ld-linux.so.2
(rr) cont
Continuing.
*** stack smashing detected ***: terminated

Program received signal SIGABRT, Aborted.
0x7002 in syscall_traced ()
(rr) bt
#0  0x7002 in syscall_traced ()
#1  0xb7f1513d in _raw_syscall () at 
/build/rr-Rm2x32/rr-5.6.0/src/preload/raw_syscall.S:34
#2  0xb7f10b33 in traced_raw_syscall (call=0x681fffd8) at 
./src/preload/syscallbuf.c:338
#3  0xb7f12c4d in sys_recvfrom (call=) at 
./src/preload/syscallbuf.c:2952
#4  syscall_hook_internal (call=0x681fffd8) at ./src/preload/syscallbuf.c:3843
#5  syscall_hook (call=0x681fffd8) at ./src/preload/syscallbuf.c:3949
#6  syscall_hook (call=) at ./src/preload/syscallbuf.c:3933
#7  0xb7f10361 in _syscall_hook_trampoline () at 
/build/rr-Rm2x32/rr-5.6.0/src/preload/syscall_hook.S:131
#8  0xb7f103d2 in _syscall_hook_trampoline_90_90_90 () at 
/build/rr-Rm2x32/rr-5.6.0/src/preload/syscall_hook.S:211
#9  0x6005 in __kernel_vsyscall ()
#10 0xb768a1d7 in __pth

Bug#1021125: Bug#1021576: linphone-desktop: Core dumped: Program terminated with signal SIGABRT, Aborted.

[Bernhard Schmidt]

Hi,

I think this Bug can be downgraded and/or closed.

We've rebuilt both dependencies in Debian (liblime and linphone). Since 
soci is not using shlibs the generated dependency is on the 4.0.3 anyway.


I don't see a way to fix this without breaking lime/linphone again.

Bernhard

Bug#1022282: staden-io-lib: FTBFS: ./data/9827_rand3.cram.fai: No such file or directory

[Bernhard Übelacker]

Dear Maintainer,
the original staden-io-lib seems to be built with
libhtscodecs2 in version 1.2.2-1 [1].

The rebuild seems to be using libhtscodecs2 in version 1.3.0-4.

Unfortunately htscodecs upstream integrated this commit [3],
which renamed e.g. function encode_names to tok3_encode_names.
It added a compatibility function encode_names, but does not
declare it in the header file.
Therefore in the build of staden-io-lib the function encode_names
is implicitly declared - therefore seems to default to
a return type of int [4] - and therefore the returned pointer
gets truncated to the lower 4 bytes [5].
This get through unnoticed until the pointer is freed and
produces a segfault there [6].

I guess the right thing would be to have the short function name
in the header file of htscodecs, therefore solve this issue for
other packages using htscodecs.

A short term solution might be the patch in [7] which makes
the build and tests succeed without "implicit declarations".

Kind regards,
Bernhard



[1] 
https://buildd.debian.org/status/fetch.php?pkg=staden-io-lib&arch=amd64&ver=1.14.14%2Bdfsg-1%2Bb1&stamp=1663567926&raw=0
[2] https://tracker.debian.org/pkg/htscodecs
[3] 
https://github.com/jkbonfield/htscodecs/commit/6211b208d2bd21e93f3f62c0cd0d8c43546f98b5

[4]
cram_io.c: In function ‘cram_compress_by_method’:
cram_io.c:2420:23: warning: implicit declaration of function 
‘encode_names’; did you mean ‘tok3_encode_names’? 
[-Wimplicit-function-declaration]
2420 | uint8_t *cp = encode_names(in, in_size, lev, strat, 
&out_len, NULL);
|   ^~~~
|   tok3_encode_names
cram_io.c:2420:23: warning: initialization of ‘uint8_t *’ {aka ‘unsigned 
char *’} from ‘int’ makes pointer from integer without a cast [-Wint-conversion]


[5]
(rr) bt
#0  tok3_encode_names (blk=, len=, level=, 
use_arith=, out_len=, last_start_p=) at 
./htscodecs/tokenise_name3.c:1540
#1  0x7f281aa34454 in cram_compress_by_method (s=s@entry=0x55e9af757e50, in=0x7f281000e930 
"s0", in_size=9, out_size=out_size@entry=0x7f2819611730, method=method@entry=TOK3, 
level=, strat=0, content_id=) at ./io_lib/cram_io.c:2420
#2  0x7f281aa38ebe in cram_compress_block (fd=fd@entry=0x55e9af71f930, 
s=s@entry=0x55e9af757e50, b=0x55e9af758830, metrics=0x55e9af731f50, 
method=65794, level=level@entry=5) at ./io_lib/cram_io.c:2562
#3  0x7f281aa22d75 in cram_compress_slice (s=0x55e9af757e50, c=, fd=0x55e9af71f930) at ./io_lib/cram_encode.c:951
#4  cram_encode_slice (fd=fd@entry=0x55e9af71f930, 
c=c@entry=0x55e9af73c270, h=h@entry=0x55e9af73c520, s=0x55e9af757e50) at 
./io_lib/cram_encode.c:1219
#5  0x7f281aa27881 in cram_encode_container (fd=, 
c=) at ./io_lib/cram_encode.c:2119
#6  0x7f281aa33fb0 in cram_flush_thread (arg=0x55e9af4d0500) at 
./io_lib/cram_io.c:4328
#7  0x7f281aa44272 in t_pool_worker (arg=0x55e9af737460) at 
./io_lib/thread_pool.c:434
#8  0x7f281a68784a in start_thread (arg=) at 
./nptl/pthread_create.c:442
#9  0x7f281a70a530 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:100
(rr) print out
$6 = (uint8_t *) 0x7f2810010320 "\t"
(rr) finish
Run till exit from #0  tok3_encode_names (blk=, len=, 
level=, use_arith=, out_len=, 
last_start_p=) at ./htscodecs/tokenise_name3.c:1540
0x7f281aa34454 in cram_compress_by_method (s=s@entry=0x55e9af757e50, in=0x7f281000e930 
"s0", in_size=9, out_size=out_size@entry=0x7f2819611730, method=method@entry=TOK3, 
level=, strat=0, content_id=) at ./io_lib/cram_io.c:2420
2420uint8_t *cp = encode_names(in, in_size, lev, strat, 
&out_len, NULL);
Value returned is $8 = (uint8_t *) 0x7f2810010320 "\t"
(rr) stepi
2421*out_size = out_len;
(rr) print cp
$7 = (uint8_t *) 0x10010320 
(rr) list
2416int out_len;
2417int lev = level;
2418if (method == NAME_TOK3 && lev > 3)
2419lev = 3;
2420uint8_t *cp = encode_names(in, in_size, lev, strat, 
&out_len, NULL);
2421*out_size = out_len;
2422return (char *)cp;
2423}
2424
2425case RAW:


[6]
Thread 2 received signal SIGSEGV, Segmentation fault.
0x7f281a69788a in __GI___libc_free (mem=0x10010320) at 
./malloc/malloc.c:3363
3363./malloc/malloc.c: Datei oder Verzeichnis nicht gefunden.
(rr) bt
#0  0x7f281a69788a in __GI___libc_free (mem=0x10010320) at 
./malloc/malloc.c:3363
#1  0x7f281aa39238 in cram_compress_block (fd=fd@entry=0x55e9af71f930, 
s=s@entry=0x55e9af757e50, b=0x55e9af758830, metrics=0x55e9af731f50, 
method=65794, level=level@entry=5) at ./io_lib/cram_io.c:2575
#2  0x7f281aa22d75 in cram_compress_slice (s=0x55e9af757e50, c=, fd=0x55e9af71f930) at ./i

Bug#1019233: conserver FTBFS on IPV6-only buildds

[Bernhard Schmidt]

After some thoughts on it I've decided to make the test-suite non-fatal
in the pending 8.2.7-2 upload. 

The root cause of the test-suite error appears to be that conserver is
using AI_ADDRCONFIG, and fails to resolve localhost to 127.0.0.1 on
machines that do not have non-local IPv4 connectivity.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=952740
https://lists.debian.org/debian-devel/2022/02/msg00070.html

I have briefly tried to make the test-suite cope with both situations,
but was not successful. I don't want to make any code changes breaking
some real-world application while beating the testsuite into submission,
so for now I'll ignore the failure.

Bug#1021125: Bug#1021576: linphone-desktop: Core dumped: Program terminated with signal SIGABRT, Aborted.

[Bernhard Schmidt]

Am 11.10.22 um 18:19 schrieb Dennis Filder:


The change in 5.0.37-6 was tiny and I doubt it broke something.  But
maybe you're running into #1021125: liblinphone10:amd64 5.0.37-6 is
already linked against soci/4.0.3-1, but liblime0 5.0.37+dfsg-4 is
still linked against soci/4.0.1-5 and there was an ABI break.  You'd
have to downgrade to 5.0.37-5 and soci 4.0.1-5 and wait until either
that bug gets fixed or lime will be rebuilt and reuploaded.


Shall we just do a new upload of liblime0 then?

liblime and linphone are the only reverse dependencies in the archive, 
and linphone has already been rebuilt against the new version/ABI. I 
doubt one can fix the soci ABI bump without breaking linphone again, so 
we could just go forward and rebuild lime.


Bernhard

Bug#1020702: prusa-slicer: SEGV on start

[Bernhard Übelacker]

Hello,
it looks like following line should expect the Get() call returning a nullptr,
which wxWidget documentation explicitly notes.

   2079
wxTranslations::Get()->SetLanguage(wxLANGUAGE_DEFAULT);


I have raised this question to upstream here:

   https://github.com/prusa3d/PrusaSlicer/issues/9024

Kind regards,
Bernhard


Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f2589f565f3 in std::__cxx11::basic_string, 
std::allocator >::_M_data (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:234
234 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:
 Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x7f2589f565f3 in std::__cxx11::basic_string, 
std::allocator >::_M_data (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:234
#1  std::__cxx11::basic_string, 
std::allocator >::_M_is_local (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:274
#2  std::__cxx11::basic_string, 
std::allocator >::capacity (this=) at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.h:1134
#3  std::__cxx11::basic_string, std::allocator 
>::_M_assign (this=this@entry=0x0, __str=L"") at 
/build/gcc-12-GwPmq4/gcc-12-12.2.0/build/x86_64-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:279
#4  0x7f258896e05a in std::__cxx11::basic_string, 
std::allocator >::assign (__str=L"", this=0x0) at 
/usr/include/c++/12/bits/basic_string.h:1540
#5  0x7f258896e0c6 in wxTranslations::SetLanguage (this=0x0, 
lang=lang@entry=wxLANGUAGE_DEFAULT) at ./src/common/translation.cpp:1384
#6  0x563e57fb8e26 in Slic3r::GUI::GUI_App::load_language (this=0x563e59d29200, 
language=..., initial=) at ./src/slic3r/GUI/GUI_App.cpp:2079
#7  0x563e57fbaaf5 in Slic3r::GUI::GUI_App::on_init_inner 
(this=0x563e59d29200) at ./src/slic3r/GUI/GUI_App.cpp:1093
#8  0x563e57fbd4c6 in Slic3r::GUI::GUI_App::OnInit (this=) 
at ./src/slic3r/GUI/GUI_App.cpp:1035
#9  0x7f258891feda in wxEntry (argc=, argv=) 
at ./src/common/init.cpp:487
#10 0x563e57f9f7b9 in Slic3r::GUI::GUI_Run (params=...) at 
./src/slic3r/GUI/GUI_Init.cpp:54
#11 0x563e577605de in Slic3r::CLI::run (this=, argc=, argv=) at ./src/PrusaSlicer.cpp:618
#12 0x563e57735bf4 in main (argc=, argv=) at 
./src/PrusaSlicer.cpp:844


https://docs.wxwidgets.org/3.0/classwx_translations.html#ab384ea68c44e74cfd2cd59e782529540

Bug#1020677: httraqt: Segfault upon mirroring initiation

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look and found unfortunately the dbgsym package
not containing useful files.

This seems related to CMAKE_CXX_FLAGS getting reset,
therefore loosing Qt related flags.

Before the application crashed already when trying to open
one leaf in the tree view, with the Qt flags this crash did not happen,
so this might be related.

The second patch just removes a leftover CMakeLists.txt.rej from a previous 
patch.

Kind regards,
Bernhard


Before:
-- CMAKE_CXX_FLAGS -O3 -DNDEBUG -Wall

After:
-- CMAKE_CXX_FLAGS -g -O2 
-ffile-prefix-map=/home/benutzer/source/httraqt/git/httraqt=. 
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time 
-D_FORTIFY_SOURCE=2 -O3 -DNDEBUG -Wall -DQT_NO_DEPRECATED_WARNINGSFrom 1349c117855ba576dd9eb7aea2612550c58a1727 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 9 Oct 2022 16:29:40 +0200
Subject: Remove CMakeLists.txt.rej from 10_reproducible_build.patch.

---
 debian/patches/10_reproducible_build.patch | 27 --
 1 file changed, 27 deletions(-)

diff --git a/debian/patches/10_reproducible_build.patch b/debian/patches/10_reproducible_build.patch
index 22f5ebb..7a620e5 100644
--- a/debian/patches/10_reproducible_build.patch
+++ b/debian/patches/10_reproducible_build.patch
@@ -17,30 +17,3 @@ Last-Update: 2017-07-18
  MESSAGE("-- Version build date: ${BUILD_DATE}")
  
  configure_file (
 /dev/null
-+++ httraqt-1.4.9/CMakeLists.txt.rej
-@@ -0,0 +1,24 @@
-+--- CMakeLists.txt
- CMakeLists.txt
-+@@ -6,7 +6,7 @@ CMAKE_POLICY(SET CMP0003 OLD)
-+ CMAKE_POLICY(SET CMP0015 OLD)
-+ 
-+ # if you use the version 5, please change it to 5
-+-SET(USE_QT_VERSION 4)
-++SET(USE_QT_VERSION 5)
-+ 
-+ MESSAGE("Qt version for compiling: " ${USE_QT_VERSION})
-+ 
-+@@ -62,12 +62,6 @@ set(APP_RESOURCES  "${PROJECT_SOURCE_DIR
-+ MESSAGE("-- Version info: ${HTTRAQT_VERSION}") 
-+ SET(VERSION ${HTTRAQT_VERSION})
-+ 
-+-EXECUTE_PROCESS (
-+-  COMMAND date +"%d %b %Y"
-+-  COMMAND sed -e "s/\"//g"
-+-  OUTPUT_VARIABLE BUILD_DATE
-+-  OUTPUT_STRIP_TRAILING_WHITESPACE)
-+-
-+ MESSAGE("-- Version build date: ${BUILD_DATE}")
-+ 
-+ configure_file (
-- 
2.35.1

From a678025eece455ffcc3916c65bfac194b5747b1a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Bernhard=20=C3=9Cbelacker?= 
Date: Sun, 9 Oct 2022 16:34:36 +0200
Subject: Do not override CMAKE_CXX_FLAGS.

Adds additionally QT_NO_DEPRECATED_WARNINGS as those warnings
might be mostly useful for upstream developers.
---
 .../30_do_not_override_CMAKE_CXX_FLAGS.patch  | 21 +++
 debian/patches/series |  1 +
 2 files changed, 22 insertions(+)
 create mode 100644 debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch

diff --git a/debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch b/debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch
new file mode 100644
index 000..b11608a
--- /dev/null
+++ b/debian/patches/30_do_not_override_CMAKE_CXX_FLAGS.patch
@@ -0,0 +1,21 @@
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 1310490..a51d391 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -26,11 +26,14 @@ OPTION (USE_PROFILER "Include in binary file profiling information" OFF)
+ 
+ 
+ IF(${USE_DEBUGGER})
+-  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_DEBUG} -Wall")
++  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_DEBUG} -Wall")
+ ELSE()
+-  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS_RELEASE} -Wall")
++  SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${CMAKE_CXX_FLAGS_RELEASE} -Wall")
+ ENDIF()
+ 
++SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -DQT_NO_DEPRECATED_WARNINGS")
++
++
+ MESSAGE(STATUS "CMAKE_CXX_FLAGS ${CMAKE_CXX_FLAGS}")
+ 
+ 
diff --git a/debian/patches/series b/debian/patches/series
index 8d027f0..43c04ea 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
 10_reproducible_build.patch
 20_cross.patch
+30_do_not_override_CMAKE_CXX_FLAGS.patch
-- 
2.35.1

Bug#1019340: tucnak: Segfaults on startup

[Bernhard Übelacker]

Hello Christoph, hello tony,


#12 0x5586f25c0438 tucnak_crash (tucnak + 0xb0438)
#13 0x7febdc3589d4 z_sig_segv (libzia-4.36.so + 0x169d4)
#14 0x7febdaa3daf0 __restore_rt (libc.so.6 + 0x3daf0)
#15 0x7febd5ead5ee n/a (crocus_dri.so + 0xad5ee)
#16 0x7febd80836e6 glPrimitiveBoundingBox (libGLX_mesa.so.0 
+ 0x4e6e6)


The crash looks like it happened in crocus_dri.so.
Could the possible difference be the gpu driver that is in use on your systems.
As far as I see crocus is for Intel gpus, and arrived just last year in Mesa.
Therefore it might be just reproducible with this hardware.

From [1] it might be possible to use another driver.
Maybe MESA_LOADER_DRIVER_OVERRIDE=i965 could work for this hardware?

Kind regards,
Bernhard

[1] https://wiki.archlinux.org/title/OpenGL#Installation

Bug#1017148: soci: FTBFS: catch.hpp:6490:33: error: size of array ‘altStackMem’ is not an integral constant-expression

[Bernhard Schmidt]

Control: tags -1 + patch upstream fixed-upstream
Control: forwarded -1 https://github.com/SOCI/soci/pull/886

On 14/08/22 09:18 AM, Lucas Nussbaum wrote:

> During a rebuild of all packages in sid, your package failed to build
> on amd64.
> 
> > /<>/tests/catch.hpp:6490:33: error: size of array 
> > ‘altStackMem’ is not an integral constant-expression
> >  6490 | static char altStackMem[SIGSTKSZ];
> >   | ^~~~
> > /<>/tests/catch.hpp:6541:45: error: size of array 
> > ‘altStackMem’ is not an integral constant-expression
> >  6541 | char FatalConditionHandler::altStackMem[SIGSTKSZ] = {};
> >   | ^~~~

This is likely fixed with a new upstream release

Version 4.0.3 differs from 4.0.2 in the following ways:

Changes affecting all or multiple backends:
 - Fix opening sessions from pool (#891).
 - Fix default backend search path (#928).
>- Fix build with latest glibc versions where SIGSTKSZ is not constant
   (#886).
 - Document using SOCI as a CMake subdirectory (#925).
 - Document using SOCI with Conan (#877).

The fix looks easy enough

https://github.com/SOCI/soci/pull/886/commits/7719b5a8242a5ec016f73666a51e80b3bd7f8956

@William: Any opinion on targeted fix vs. new upstream version?

As one of the package I somewhat care about (linphone) is affected by
this removal from testing I would NMU a targeted fix end of September.

Bernhard

Bug#1018016: bind9-libs not found for sid

[Bernhard Schmidt]

Hi,


I’ve recently moved, so everything is in but of disarray including my
builder machine. The git repository should be up to date, so if this
cannot wait a day or two until I connect rest of my network, anybody
should be able to build and upload new upstream version using
git-buildpackage. Alternatively, just wait a few days, I am almost
there re-connecting stuff…


I just came back from vacation and stumbled over this, sorry I couldn't 
help earlier.


You had uploaded 9.18.6-1, but somehow this ended up as an amd64 upload 
binary to unstable, so it did not migrate. And it did not migrate 
because a binNMU to bind-dyndb-ldap is necessary, see #1014503.


I have just made a no-change source-only upload, so the first problem 
should be resolved. For the second I have filed Bug#1019220 .


Now, I'm still utterly confused how this problem could have happened at 
all. I was able to verify at this point that sid was indeed lacking 
bind9-libs:amd64.


But it was built on the buildds

https://buildd.debian.org/status/fetch.php?pkg=bind9&arch=amd64&ver=1%3A9.18.4-2&stamp=1657022678&raw=0

and (due to the migration issues) the package version that was lacking 
in sid is still present in testing, including bind9-libs:amd64


bind9-libs | 1:9.18.4-2  | testing| amd64, 
arm64, armel, armhf, i386, mips64el, mipsel, ppc64el, s390x


https://packages.debian.org/bookworm/bind9-libs
http://ftp.de.debian.org/debian/pool/main/b/bind9/bind9-libs_9.18.4-2_amd64.deb

http://snapshot.debian.org/package/bind9/1%3A9.18.4-2/#bind9-libs_1:3a:9.18.4-2

Bernhard

Bug#1012587: Chance to bring back to testing?

[Bernhard]

Dear maintainer

Only a careful question:
Is there a chance to bring this package back to testing?
I need this package to maintain my YubiKey.

Thank you for the support
Bernhard

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

[Bernhard Turmann]

Paul, Ondřej,
you mentioned bug 1004729 which is marked as done. That might be indeed 
the case for unstable/testing.


Unfortunately, this is not the case for the version 
bind-dyndb-ldap/11.6-3 in bullseye stable after several newer bind9 
releases merged into stable with 9.16.27 being the latest.


Means, currently, bind-dyndb-ldap is broken in stable. What is the 
correct way to get this resolved and maintain it like that?


For now, I use apt mark of older bind9 9.16.15 as an emergency 
workaround until a solution is found.


Thanks
Berni

Bug#1014133: asterisk: Asterisk fails to build from source

[Bernhard Schmidt]

Control: severity -1 important
Control: found -1 1:16.16.1~dfsg-1
Control: fixed -1 1:16.16.1~dfsg+~2.10-1

Hi Ralf,

I am not very familiar with asterisk as packaged for Bullseye - only
know that it was pretty unusually done.

Maybe try build in a pristine build-environment.


What do you mean by this?


As Jonas already wrote, please use something like sbuild/cowbuilder. The 
packages for Bullseye have been built from source by the buildd, so 
generally they should work just fine.


I might have a look later, but since Jonas changed the packaging for 
Bullseye (in a way I don't grasp anymore :-) ) this is definitely not 
affecting the next release and it's definitely not stable-update 
material. So downgrading.


Bernhard

Bug#1002237: Any chance of re-introduction?

[Bernhard]

Der maintainer

I wanted to ask for a re-introduction in bookworm oft course.
In bullseye, gnome-packagekit is available.

Best regards and thank you.
Bernhard

Bug#1012059: bind9: autopkgtest regression on amd64 and armhf: connection refused

[Bernhard Schmidt]

Control: tags -1 pending

Hi,
With a recent upload of bind9 the autopkgtest of bind9 fails in 
testing on amd64 and armhf when that autopkgtest is run with the 
binary packages of bind9 from unstable. It passes when run with only 
packages from testing. In tabular form:


I have had a brief look and it seems we are just too quick. Adding a 
sleep 1 into the setup function makes the test succeed.


However, I cannot figure out the current repository layout anymore. 
debian/main appears to be outdated. The closest thing that matches 
Debian sid right now is the isc/9.18 branch.

 > Could you please tell me how to handle this repository?


Since you have changed the structure of the repo again and I'm now 
reasonably sure that I have to look at the debian/9.18 branch I've 
pushed a commit fixing the autopkgtest regression in there. Not sure 
when it will land, since there is already a 9.18.4-1 tagged in there but 
not yet uploaded.


Bernhard

Bug#1012059: bind9: autopkgtest regression on amd64 and armhf: connection refused

[Bernhard Schmidt]

Control: tags -1 pending

Hi,
With a recent upload of bind9 the autopkgtest of bind9 fails in 
testing on amd64 and armhf when that autopkgtest is run with the 
binary packages of bind9 from unstable. It passes when run with only 
packages from testing. In tabular form:


I have had a brief look and it seems we are just too quick. Adding a 
sleep 1 into the setup function makes the test succeed.


However, I cannot figure out the current repository layout anymore. 
debian/main appears to be outdated. The closest thing that matches 
Debian sid right now is the isc/9.18 branch.

 > Could you please tell me how to handle this repository?


Since you have changed the structure of the repo again and I'm now 
reasonably sure that I have to look at the debian/9.18 branch I've 
pushed a commit fixing the autopkgtest regression in there. Not sure 
when it will land, since there is already a 9.18.4-1 tagged in there but 
not yet uploaded.


Bernhard

Bug#1002237: Any chance of re-introduction?

[Bernhard]

Dear maintainer

Is there a chance of re-introduction in bullseye?

The package "package-update-indicator" recommends "gnome-packagekit".
For this, i created the bug #1010802:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010802

Best regards and thank you
Bernhard

Bug#1012059: bind9: autopkgtest regression on amd64 and armhf: connection refused

[Bernhard Schmidt]

Hi Ondrej,

With a recent upload of bind9 the autopkgtest of bind9 fails in testing 
on amd64 and armhf when that autopkgtest is run with the binary packages 
of bind9 from unstable. It passes when run with only packages from 
testing. In tabular form:


I have had a brief look and it seems we are just too quick. Adding a 
sleep 1 into the setup function makes the test succeed.


However, I cannot figure out the current repository layout anymore. 
debian/main appears to be outdated. The closest thing that matches 
Debian sid right now is the isc/9.18 branch.


Could you please tell me how to handle this repository?

Bernhard

Bug#1008015: Bugfix might break some setups

[Bernhard Schmidt]

Hi,

this is definitely not an issue with the fix for Bug#1008015, which was 
a very minor security bugfix targeted for


You are running unstable, therefor you have been upgraded to OpenVPN 2.6 
and OpenSSL 3.0.


Could you please file a new bug about this with as much information as 
available about your configuration? I have never used PKCS#12 
certificates before. I guess this is more an issue of OpenSSL 3.0 than 
OpenVPN 2.6.


> 2022-05-23 08:47:47 OpenSSL: error:0308010C:digital envelope 
routines::unsupported
> 2022-05-23 08:47:47 OpenSSL: error:0308010C:digital envelope 
routines::unsupported
> 2022-05-23 08:47:47 Decoding PKCS12 failed. Probably wrong password 
or unsupported/legacy encryption


Bernhard

Am 23.05.22 um 09:31 schrieb Peter Keel:

Hi

Apparently since the fix for #1008015 openvpn now demands a password,
even though none was needed before.

2022-05-23 08:47:47 OpenVPN 2.6_git x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] 
[LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on May 20 2022
2022-05-23 08:47:47 library versions: OpenSSL 3.0.3 3 May 2022, LZO 2.10
🔐 Enter Private Key Password:
2022-05-23 08:47:47 OpenSSL: error:0308010C:digital envelope 
routines::unsupported
2022-05-23 08:47:47 OpenSSL: error:0308010C:digital envelope 
routines::unsupported
2022-05-23 08:47:47 Decoding PKCS12 failed. Probably wrong password or 
unsupported/legacy encryption
2022-05-23 08:47:47 Error: private key password verification failed
2022-05-23 08:47:47 Exiting due to fatal error

The p12 comes by default from an OPNsense, I can't see how it's
generated, much less how to set or even enter a password there.

Cheers
Seegras

Bug#1006519: Already fixed in 2.6.0~git20220510+dco-1 in experimental

[Bernhard Schmidt]

Hi Michael,

Am 19.05.22 um 16:03 schrieb Michael Biebl:

On Sun, 15 May 2022 16:02:48 +0300 Adrian Bunk  wrote:

Version: 2.6.0~git20220510+dco-1

openvpn (2.6.0~git20220510+dco-1) experimental; urgency=medium
...
  * Build against OpenSSL 3.0

 -- Bernhard Schmidt   Fri, 13 May 2022 00:01:35 +0200


Berni, would you mind uploading this version to unstable?




Uploaded and accepted.

Bernhard

Bug#1001669: closed by Debian FTP Masters (reply to Aniol Martí ) (Bug#1001669: fixed in openvpn-auth-ldap 2.0.4-2)

[Bernhard Schmidt]

Hi,

unfortunately this is still happening in 2.0.4-2

https://ci.debian.net/packages/o/openvpn-auth-ldap/unstable/amd64/

Right now this would be preventing the new version of openvpn to migrate
(I can retry of course).

Bernhard

Bug#983985: bctoolbox: ftbfs with GCC-11

[Bernhard Schmidt]

Hi,


bctoolbox 5.0.37 builds perfectly with mbedtls 2.28.0-0.1 here, I will
test with 2.28.0-0.2 ASAP.


4.4.13-3 (just uploaded) builds fine against mbedtls 2.28.0-0.2 in 
experimental, so go ahead and sorry for the delay.


Bernhard

Bug#996761: kwin-x11: KWin crashes and doesn't start

[Bernhard Übelacker]

Hello Francisco, hello Albert,
this might be the same as in bug #996726
and not directly related to the nvidia driver.

I hit a crash in kwin_x11 with an AMD graphics card
and could workaround by installing
libkdecorations2-5v5_5.21.5-2_amd64.deb like
mentioned in #996726.

Kind regards,
Bernhard

https://bugs.debian.org/996726

Bug#995242: isc-dhcp-server: omshell returns inconsistent results or segfaults

[Bernhard Übelacker]

On Tue, 28 Sep 2021 15:01:22 +0200 uninsubria.it 
 wrote:


example from 'dmesg' output:
[Tue Sep 28 11:05:22 2021] omshell[4604]: segfault at 0 ip 55623cdd06dc sp 
7ffd5a2c7c78 error 4 in omshell[55623cd97000+45000]




Hello,
maybe you can add a few pairs of the
dmesg "segfault" and "code" lines.
This would make it possible to locate the crashing instruction,
and therefore maybe point to a source code line.

Kind regards,
Bernhard

Bug#991931: CVE-2021-32686 / AST-2021-009: pjproject/pjsip: crash when SSL socket destroyed during handshake

[Bernhard Schmidt]

Package: src:asterisk
Severity: serious
Tags: security upstream patch

https://downloads.asterisk.org/pub/security/AST-2021-009.html

Summary:pjproject/pjsip: crash when SSL socket destroyed during 
handshake
Nature of Advisory: Denial of service
Susceptibility: Remote unauthenticated sessions
Severity:   Major
Exploits Known: Yes

Description
| Depending on the timing, it’s possible for Asterisk to crash when using a TLS
| connection if the underlying socket parent/listener gets destroyed during the
| handshake.

Bug#986692: crash at startup

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look, but got no clue why a Unwind should take place
until I saw the old build log [1].

There I found this warning:
  Levels.cpp: In member function ‘bool Levels::addLevel(const string&, int, 
int)’:
  Levels.cpp:118:1: warning: no return statement in function returning non-void 
[-Wreturn-type]
118 | }
| ^

So I assume g++ puts no ret instruction to this method
and therefore the Unwind gets executed because of this.
I wonder why this is just a warning ...

Attached patch contains a few changes for these warnings:
  warning: no return statement in function returning non-void [-Wreturn-type]
  warning: control reaches end of non-void function [-Wreturn-type]
  warning: attempt to free a non-heap object ‘host’ [-Wfree-nonheap-object]

A build with this patch applied does not crash at startup.
(Testing if it really starts up took longer than the actual error ;-) )

Kind regards,
Bernhard

[1] 
https://buildd.debian.org/status/fetch.php?pkg=numptyphysics&arch=amd64&ver=0.2%2Bsvn157-0.4&stamp=1573519484&raw=0
Bug-Debian: https://bugs.debian.org/986692
Forwarded: no
Last-Update: 2021-04-22

--- numptyphysics-0.2+svn157.orig/Game.h
+++ numptyphysics-0.2+svn157/Game.h
@@ -58,7 +58,7 @@ struct GameControl
   virtual ~GameControl() {}
   virtual bool save( const char *file=NULL ) =0;
   virtual bool send() =0;
-  virtual bool load( const char* file ) {};
+  virtual bool load( const char* file ) { return false; };
   virtual void gotoLevel( int l, bool replay=false ) =0;
   virtual void clickMode(int cm) =0;
   Levels& levels() { return *m_levels; }
--- numptyphysics-0.2+svn157.orig/Http.cpp
+++ numptyphysics-0.2+svn157/Http.cpp
@@ -114,7 +114,6 @@ bool Http::get( const char* uri,
   }
 
   fclose ( m_file );
-  free( host );
   return m_size > 0;
 }
 
@@ -175,6 +174,7 @@ bool Http::post( const char* uri, const
   fprintf(stderr,"http_get wobbly: %s\n",w.what());
 }
   }
+  return true;
 }
 
 
--- numptyphysics-0.2+svn157.orig/Levels.cpp
+++ numptyphysics-0.2+svn157/Levels.cpp
@@ -114,7 +114,7 @@ bool Levels::addPath( const char* path )
 
 bool Levels::addLevel( const string& file, int rank, int index )
 {
-  addLevel( getCollection(MISC_COLLECTION), file, rank, index );
+  return addLevel( getCollection(MISC_COLLECTION), file, rank, index );
 }
 
 bool Levels::addLevel( Collection* collection,
@@ -248,6 +248,7 @@ int Levels::collectionFromLevel( int i,
   }
 }
   }
+  return -1;
 }
 
 std::string Levels::collectionName( int i, bool pretty )
--- numptyphysics-0.2+svn157.orig/Scene.cpp
+++ numptyphysics-0.2+svn157/Scene.cpp
@@ -616,6 +616,7 @@ bool Scene::activateStroke( Stroke *s )
 {
   activate(s);
   m_recorder.activateStroke( m_strokes.indexOf(s) );
+  return true;
 }
 
 void Scene::getJointCandidates( Stroke* s, Path& pts )
--- numptyphysics-0.2+svn157.orig/Ui.cpp
+++ numptyphysics-0.2+svn157/Ui.cpp
@@ -1081,7 +1081,7 @@ bool Dialog::onEvent( Event& ev )
   return Panel::onEvent(ev);
 }
 
-bool Dialog::close()
+void Dialog::close()
 {
   if (m_parent) {
 //fprintf(stderr,"close dialog\n");
--- numptyphysics-0.2+svn157.orig/Ui.h
+++ numptyphysics-0.2+svn157/Ui.h
@@ -321,7 +321,7 @@ class Dialog : public Panel
   void onTick( int tick );
   bool processEvent( SDL_Event& ev );
   bool onEvent( Event& ev );
-  bool close();
+  void close();
   virtual Container* content() { return m_content; }
   Button* leftControl() { return m_left; }
   Button* rightControl() { return m_right; }
--- numptyphysics-0.2+svn157.orig/Worker.cpp
+++ numptyphysics-0.2+svn157/Worker.cpp
@@ -64,4 +64,5 @@ int WorkerBase::startThread(void* wbase)
   event.user.data1 = wbase;
   event.user.data2 = 0;
   SDL_PushEvent(&event);
+  return 0;
 }

Bug#986692: crash at startup

[Bernhard Übelacker]

Just for reference, why g++ does not error here,
this gcc bug might be interesting:
  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43943

Kind regards,
Bernhard

Bug#984953: libgtkmm-3.0-1v5: GParted crashes on Gdk::Pixbuf::get_width() const ()

[Bernhard Übelacker]

Dear Maintainer,
I tried to have a look at the core file and a backtrace
with all needed symbols looks like in [1].

In the end it looks like in refresh_combo_devices [2] it
is attempted to load a harddisk icon.

This failed for some reason in [3], therefore a local variable
"theme_icon" contains a null pointer, which gets unconditionally
called member function get_width on and therefore
crashes a few lines later.

A wild guess would be that the harddisk icon file
is missing or is not accessible.
Possibly there is some hint written to stdout before the crash.

Kind regards,
Bernhard


[1]
(gdb) bt
#0  Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389
#1  Gdk::Pixbuf::get_width (this=0x0) at pixbuf.cc:517
#2  0xaab89ca4 in GParted::Utils::mk_pixbuf (widget=..., 
stock_id=..., icon_size=..., icon_size@entry=...) at 
/usr/include/glibmm-2.4/glibmm/refptr.h:259
#3  0xaab92020 in GParted::Win_GParted::refresh_combo_devices 
(this=0xe960) at /usr/include/gtkmm-3.0/gtkmm/enums.h:2870
#4  0xaab95980 in GParted::Win_GParted::menu_gparted_refresh_devices 
(this=) at Win_GParted.cc:1674
#5  0xaab95e2c in GParted::Win_GParted::initial_device_refresh 
(data=) at Win_GParted.cc:1605
#6  0xf6b8dab4 in g_main_dispatch (context=0xaaca6f10) at 
../../../glib/gmain.c:3325
#7  g_main_context_dispatch (context=0xaaca6f10) at 
../../../glib/gmain.c:4043
#8  0xf6b8de5c in g_main_context_iterate (context=0xaaca6f10, 
block=block@entry=1, dispatch=dispatch@entry=1, self=) at 
../../../glib/gmain.c:4119
#9  0xf6b8e1b0 in g_main_loop_run (loop=loop@entry=0xabb23860) 
at ../../../glib/gmain.c:4317
#10 0xf70b98f0 in gtk_main () at ../../../../gtk/gtkmain.c:1328
#11 0xaab2138c in main (argc=, argv=) 
at main.cc:62

[2]
https://gitlab.gnome.org/GNOME/gparted/-/blob/master/src/Win_GParted.cc#L727

[3]
https://gitlab.gnome.org/GNOME/gparted/-/blob/master/src/Utils.cc#L109

# Bullseye/testing arm64 qemu VM 2021-03-25

echo "set enable-bracketed-paste off" >> /etc/inputrc; bash
apt update

# to speedup testing
mv /etc/manpath.config /etc/manpath.config.renamed
apt install libeatmydata1
export LD_PRELOAD=/usr/lib/$(uname -m)-linux-gnu/libeatmydata.so

apt dist-upgrade
apt install gdb zstd mc gparted \
gparted-dbgsym libgtk-3-0-dbgsym libgtkmm-3.0-1v5-dbgsym 
libglib2.0-0-dbgsym
apt build-dep gparted





mkdir /home/benutzer/source/gparted/orig -p
cd/home/benutzer/source/gparted/orig
apt source gparted
cd





wget 
"https://bugs.debian.org/cgi-bin/bugreport.cgi?att=2;bug=984953;filename=gpartedbin.core.tar.zstd;msg=10";
 -O gpartedbin.core.tar.zstd
tar axf gpartedbin.core.tar.zstd

gdb -q --core gpartedbin.core
gdb -q /usr/sbin/gpartedbin --core gpartedbin.core

set width 0
set pagination off


Core was generated by `/usr/sbin/gpartedbin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0xf794d760 in Gdk::Pixbuf::get_width() const () from 
/usr/lib/aarch64-linux-gnu/libgdkmm-3.0.so.1
[Current thread is 1 (Thread 0xf51947a0 (LWP 9937))]
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  0xf794d760 in Gdk::Pixbuf::get_width() const () from 
/usr/lib/aarch64-linux-gnu/libgdkmm-3.0.so.1
#1  0xaab89ca4 in ?? ()
#2  0xaab92020 in ?? ()
#3  0xaab95e2c in ?? ()
#4  0xf6b8dab4 in g_main_context_dispatch () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#5  0xf6b8de5c in ?? () from /usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#6  0xf6b8e1b0 in g_main_loop_run () from 
/usr/lib/aarch64-linux-gnu/libglib-2.0.so.0
#7  0xf70b98f0 in gtk_main () from 
/usr/lib/aarch64-linux-gnu/libgtk-3.so.0
#8  0xaab2138c in ?? ()
#9  0xf6707218 in __libc_start_main (main=0xaab21290, argc=1, 
argv=0xf4e8, init=, fini=, 
rtld_fini=, stack_end=) at ../csu/libc-start.c:308
#10 0xaab219ec in ?? ()
Backtrace stopped: not enough registers or memory available to unwind further


Core was generated by `/usr/sbin/gpartedbin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389
389 ../gdkmm/pixbuf.h: No such file or directory.
[Current thread is 1 (Thread 0xf51947a0 (LWP 9937))]
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
#0  Gdk::Pixbuf::gobj (this=0x0) at ../gdkmm/pixbuf.h:389
#1  Gdk::Pixbuf::get_width (this=0x0) at pixbuf.cc:517
#2  0xaab89ca4 in GParted::Utils::mk_pixbuf (widget=..., stock_id=..., 
icon_size=..., icon_size@entry=...) at 
/usr/include/glibmm-2.4/glibmm/refptr.h:259
#3  0xaab92020 in GParted::Win_GParted::refresh_combo_devices 
(this=0xe960) at /usr/include/gtkmm-3.0/gtkmm/enums.h:2870
#4  0xaab95980 in GParted::Win_GParted::menu_gparted_refresh_devices 
(this=) at Win_GParted.cc:1674

Bug#983365: [PATCH] Re: Bug#983365: linphone-desktop: chat messages

[Bernhard Schmidt]

Dear David,

>>> I finally found the bug: ...
> 
> Excellent!
> 
> Please make sure you also test a file transfer, which is part of the
> chat message interface [I couldn't try since the chat msgs itself
> didn't work ...], The file transfer functionality is absolutely
> essential as well, afaic at least 

soci 4.0.1-5 has migrated to testing yesterday. The bug should be fixed
now for a fully up-to-date Bullseye system.

Bernhard

Bug#982332: Status regarding Dahdi RC bugs?

[Bernhard Schmidt]

Hi Tzafrir,

what are your plans regarding the three RC bugs filed against dahdi-*
(Bug#982332, Bug#982334, Bug#982389)? They would case Asterisk's removal
from Bullseye if they are not fixed. Since Asterisk would need to drop a
binary package they are not easily reintroduced either.

Bernhard

Bug#983365: [PATCH] Re: Bug#983365: linphone-desktop: chat messages

[Bernhard Schmidt]

Am 03.03.21 um 18:55 schrieb Dennis Filder:

Hi Dennis,

> On Sun, Feb 28, 2021 at 11:07:31PM +0100, Bernhard Schmidt wrote:
>> an updated liblinphone has been uploaded to sid yesterday. Could you
>> please try liblinphone10 and liblinphone++10 from sid (4.4.21-2) and
>> report back? If it does not work you might need libsoci-core4.0 and
>> libsoci-sqlite3-4.0 from unstable as well (4.0.1-4).
> 
> I finally found the bug: libsoci_sqlite3 sometimes returns string
> where liblinphone unconditionally expects int, long, double etc. which
> led to silent std::bad_cast exceptions.  I can't say who is actually
> to blame (I feel soci should do that conversion already as it knows
> what type the user requested, or at least not throw silently), but the
> attached patches remedy the issue through some conditional string
> conversion and make chat history actually work again in the GUI.  They
> should really have separated the sqlite3 database code better from the
> MySQL code.
> 
> I put this in two separate patches to make it easier to remove the
> changes to the code for the legacy DB migration in case it causes
> problems.

Cool, thanks. Would you mind discussing your findings with upstream at
https://gitlab.linphone.org/BC/public/liblinphone ? We will need a
freeze exception for this, having this bug confirmed by upstream would
help a lot, cherry-picking a commit from upstream would be even better.

Right now I don't plan to upload src:linphone before 4.4.21-2 has
migrated to testing, in order to have a minimum amount of changes to be
discussed for the freeze exception.

Bernhard

Bug#983365: Info received (Bug#983365: linphone-desktop: chat messages)

[Bernhard Schmidt]

Hi David,

Am 01.03.21 um 20:24 schrieb David Pirotte:

> Thanks all for having worked on this. Sorry for the little delay in
> answering, I actually thought the packages would 'find their way' to
> bullseye, so I was (and still am) updating daily, a few times per day
> actually, but now I see you said sid, not bullseye ...
> 
>> an updated liblinphone has been uploaded to sid yesterday. Could you
>> please try liblinphone10 and liblinphone++10 from sid (4.4.21-2) and
>> report back? If it does not work you might need libsoci-core4.0 and
>> libsoci-sqlite3-4.0 from unstable as well (4.0.1-4).
> 
> I am using bullseye (n idea why reportbug says bullseye/sid), so I
> don't have the right config to pick those 2 from sid, and so many years
> I haven't done this that I forgot my 'apt/preferencesfu' to do that -
> but by all means, the bug is in bullseye, won't you make these packages
> available in bullseye?

There is a ten day migration period from sid to bullseye. If no
regression shows up th new linphone version should migrate to bullseye
about March 9th. I hope it doesn't get delayed, because on 10th the
freeze starts for real.

The easiest way to just install one or two packages from sid would
probably be

- duplicate bullseye line in /etc/apt/sources.list and replace bullseye
with sid
- apt update
- apt install liblinphone10 liblinphone++10
- disable new line from /etc/apt/sources.list
- apt update

Bernhard

Bug#983365: Info received (Bug#983365: linphone-desktop: chat messages)

[Bernhard Schmidt]

Hi,

an updated liblinphone has been uploaded to sid yesterday. Could you
please try liblinphone10 and liblinphone++10 from sid (4.4.21-2) and
report back? If it does not work you might need libsoci-core4.0 and
libsoci-sqlite3-4.0 from unstable as well (4.0.1-4).

Thanks,
Bernhard

Bug#972339: armhf: hpcups crashes with free() invalid pointer for some printers

[Bernhard Übelacker]

Hello Didier,
I have retried with the patch in #974828, but it still
crashed with the test files from this bug, therefore
I guess #974828 is similar but unrelated.


Then I took another look at the valgrind runs and found
that these invalid reads and writes also appear at amd64.

After some digging I gave up to understand the pointer
calculations and such and tried to just increase the
allocations and came up with the attached three patches.

(While working at #974828 I found one such "+ 32" in
HPCupsFilter.cpp which might be already a workaround by upstream?)


With these three applied a valgrind run shows no more errors
with amd64 or armhf, and also does not abort at armhf.

As this just allocates a few extra bytes I assume that the
print result should not be different by these patches.
And I hope that memset'ing these buffers has no security
related effects.

For the crash is just the Halftoner patch important.
The other two are currently just for valgrind, but that
might change in future with compiler changes or similar.

What do you think?

Kind regards,
Bernhard

Description: Workaround: Add 32 bytes to allocation ColorMatcher

Bug-Debian: https://bugs.debian.org/972339
Bug-Ubuntu: https://launchpad.net/bugs/1901209
Last-Update: 2021-02-27

==12899== Invalid read of size 1
==12899==at 0x1174D6: Backward16PixelsNonWhite (Halftoner.h:106)
==12899==by 0x1174D6: Halftoner::HTEDiffOpen(Halftoner::THTDitherParms*, unsigned short) (Halftoner.cpp:734)
==12899==by 0x117C67: Halftoner::Process(RASTERDATA*) (Halftoner.cpp:548)
==12899==by 0x115D5F: Process (Pipeline.cpp:72)
==12899==by 0x115D5F: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:79)
==12899==by 0x115D81: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:83)
==12899==by 0x10D151: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:779)
==12899==by 0x10D651: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==12899==by 0x4B9BA1F: (below main) (libc-start.c:308)
==12899==  Address 0x55f8ed2 is 6 bytes after a block of size 12,100 alloc'd
==12899==at 0x48416F4: operator new[](unsigned int) (vg_replace_malloc.c:425)
==12899==by 0x116011: ColorMatcher::ColorMatcher(ColorMap_s, unsigned int, unsigned int) (ColorMatcher.cpp:63)
==12899==by 0x11101B: Pcl3::Configure(Pipeline**) (Pcl3.cpp:90)
==12899==by 0x115B71: Job::Configure() (Job.cpp:248)
==12899==by 0x115C07: Job::Init(SystemServices*, JobAttributes_s*, Encapsulator*) (Job.cpp:63)
==12899==by 0x10C9C1: HPCupsFilter::startPage(cups_page_header2_s*) (HPCupsFilter.cpp:481)
==12899==by 0x10D273: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:668)
==12899==by 0x10D651: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==12899==by 0x4B9BA1F: (below main) (libc-start.c:308)

--- hplip-3.20.11+dfsg0.orig/prnt/hpcups/ColorMatcher.cpp
+++ hplip-3.20.11+dfsg0/prnt/hpcups/ColorMatcher.cpp
@@ -60,7 +60,8 @@ ColorMatcher::ColorMatcher
 EndPlane = K;
 }
 
-Contone = (BYTE *) new BYTE[InputWidth * ColorPlaneCount];
+Contone = (BYTE *) new BYTE[InputWidth * ColorPlaneCount + 32];
+memset(Contone, 0, InputWidth * ColorPlaneCount + 32);
 if (Contone == NULL)
 {
 goto MemoryError;
Description: Workaround: Add 32 bytes to allocation Halftoner

Bug-Debian: https://bugs.debian.org/972339
Bug-Ubuntu: https://launchpad.net/bugs/1901209
Last-Update: 2021-02-27

==144269== Invalid read of size 1
==144269==at 0x114577: Mode9::Process(RASTERDATA*) (Mode9.cpp:332)
==144269==by 0x11EDA4: Process (Pipeline.cpp:72)
==144269==by 0x11EDA4: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:79)
==144269==by 0x11EDDF: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:83)
==144269==by 0x11EDDF: Pipeline::Execute(RASTERDATA*) (Pipeline.cpp:83)
==144269==by 0x112677: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:779)
==144269==by 0x112DE8: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==144269==by 0x4C17D09: (below main) (libc-start.c:308)
==144269==  Address 0x5a8cc0b is 0 bytes after a block of size 379 alloc'd
==144269==at 0x483950F: operator new[](unsigned long) (vg_replace_malloc.c:431)
==144269==by 0x12047B: Halftoner::Halftoner(PrintMode_s*, unsigned int, int*, int, bool) (Halftoner.cpp:184)
==144269==by 0x11817B: Pcl3::Configure(Pipeline**) (Pcl3.cpp:92)
==144269==by 0x11EA30: Job::Configure() (Job.cpp:248)
==144269==by 0x11EB67: Job::Init(SystemServices*, JobAttributes_s*, Encapsulator*) (Job.cpp:63)
==144269==by 0x111A35: HPCupsFilter::startPage(cups_page_header2_s*) (HPCupsFilter.cpp:481)
==144269==by 0x112792: HPCupsFilter::processRasterData(_cups_raster_s*) (HPCupsFilter.cpp:668)
==144269==by 0x112DE8: HPCupsFilter::StartPrintJob(int, char**) (HPCupsFilter.cpp:597)
==144269==by 0x4C17D09: (below main) (libc-start.c:308)

--- hplip-3.20.

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Bernhard Übelacker]

Hello Ian,

Am 27.02.21 um 08:49 schrieb Ian Campbell:

On Fri, 2021-02-26 at 15:41 +0100, Bernhard Übelacker wrote:

The attached patch is an attempt to grow the buffer size
if the header changes on a new page.
This is just tested for the given crash, nothing more, therefore
there might be side effects on replacing this buffer?


It doesn't look unreasonable to me, although the related shuffling of
pointers between rgbRaster, kRaster and m_pPrinterBuffer makes my head
hurt a bit (this code could really do with a dollop of modern c++
memory management idiom).

Do you think there is a need to preserve the current contents (e.g.
something approximating realloc rather than delete+new)? Or maybe it is
fine to simply unconditionally allocate a new buffer each time round
the loop? It could almost be a local variable like *Raster at that
point... But I think if you are looking for a minimal fix your patch
seems pretty sensible to me (speaking as a competent enough C/C++
programmer but not someone familiar with this codebase before today).

Ian.


I guess I am similar unfamiliar with this code as you - so I am not 
really sure if there is any interaction with the old content or pointers 
stored to the old memory for later use ...

(I was just doing the debugging fun ;-) )
I had hoped, now as we could point to a source location,
that upstream could judge about it ...

Kind regards,
Bernhard

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Bernhard Übelacker]

Dear Maintainer,
with the original PPD and input files from Ian I could
reproduce the issue and with the help of rr-debugger
this is what I assume what happens:

- The buffer m_pPrinterBuffer is allocated here with
  the current sizes inside cups_header. [1]

- The first page got processed and for the second page
  a new cups_header record gets copied. [2]
  Unfortunately now the header contains higher sizes,
  but the buffer is not grown accordingly.

- Now to this buffer is written by a read function, and beyond
  where the management information of malloc got overwritten for
  some other random memory. [3]

- The defect in the management information of malloc is detected
  and the process is aborted. [4]


The attached patch is an attempt to grow the buffer size
if the header changes on a new page.
This is just tested for the given crash, nothing more, therefore
there might be side effects on replacing this buffer?


Kind regards,
Bernhard


[1]
500 m_pPrinterBuffer = new BYTE[cups_header->cupsWidth * 4 + 32];
(rr) bt
#0  HPCupsFilter::startPage (this=0x556369c551c0 , 
cups_header=0x7ffe94b8e030) at prnt/hpcups/HPCupsFilter.cpp:500
#1  0x556369bf4793 in HPCupsFilter::processRasterData 
(this=this@entry=0x556369c551c0 , cups_raster=, 
cups_raster@entry=0x55636ac39d00) at prnt/hpcups/HPCupsFilter.cpp:668
#2  0x556369bf4de9 in HPCupsFilter::StartPrintJob (this=0x556369c551c0 
, argc=, argv=0x7ffe94b8ecf8) at 
prnt/hpcups/HPCupsFilter.cpp:597
...
(rr) when
Current event: 898

[2]
#0  0x7f504dcaa190 in memcpy (__len=1796, __src=0x564615c8cd1c, 
__dest=0x7ffc2a13f080) at 
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:34
#1  cupsRasterReadHeader2 (r=0x564615c8cd00, h=h@entry=0x7ffc2a13f080) at 
raster-stubs.c:209
#2  0x5646141d356d in HPCupsFilter::processRasterData 
(this=this@entry=0x5646142341c0 , cups_raster=, 
cups_raster@entry=0x564615c8cd00) at prnt/hpcups/HPCupsFilter.cpp:661
#3  0x5646141d3de9 in HPCupsFilter::StartPrintJob (this=0x5646142341c0 
, argc=, argv=0x7ffc2a13fd48) at 
prnt/hpcups/HPCupsFilter.cpp:597
#4  0x7f504d83fd0a in __libc_start_main (main=0x5646141d0e10 , argc=6, 
argv=0x7ffc2a13fd48, init=, fini=, rtld_fini=, stack_end=0x7ffc2a13fd38) at ../csu/libc-start.c:308
#5  0x5646141d0efa in _start ()
(rr) when
Current event: 1230

[3]
...
#9  0x7f504dcaa00d in read (__nbytes=19220, __buf=0x564615cb1ca0, 
__fd=0) at /usr/include/x86_64-linux-gnu/bits/unistd.h:44
#10 cups_read_fd (ctx=, buf=0x564615cb1ca0 '\377' ..., bytes=19220) at raster-stubs.c:323
#11 0x7f504dca9340 in cups_raster_io (bytes=19220, buf=0x564615cb1ca0 '\377' 
..., r=0x564615c8cd00) at raster-stream.c:1372
#12 _cupsRasterReadPixels (r=0x564615c8cd00, p=0x564615cb1ca0 '\377' ..., len=19220) at raster-stream.c:782
#13 0x7f504dcaa1e5 in cupsRasterReadPixels (r=, p=, len=) at raster-stubs.c:228
#14 0x5646141d36e8 in HPCupsFilter::processRasterData 
(this=this@entry=0x5646142341c0 , cups_raster=, 
cups_raster@entry=0x564615c8cd00) at prnt/hpcups/HPCupsFilter.cpp:758
#15 0x5646141d3de9 in HPCupsFilter::StartPrintJob (this=0x5646142341c0 
, argc=, argv=0x7ffc2a13fd48) at 
prnt/hpcups/HPCupsFilter.cpp:597
...

[4]
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f504d83e537 in __GI_abort () at abort.c:79
#2  0x7f504d897768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f504d9a5e31 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x7f504d89ea5a in malloc_printerr (str=str@entry=0x7f504d9a8258 "free(): 
invalid next size (normal)") at malloc.c:5347
#4  0x7f504d89ff2c in _int_free (av=0x7f504d9d7b80 , 
p=0x564615cb1c90, have_lock=) at malloc.c:4322
#5  0x5646141d15c6 in HPCupsFilter::cleanup (this=this@entry=0x5646142341c0 
) at prnt/hpcups/HPCupsFilter.cpp:227
#6  0x5646141d3e1b in HPCupsFilter::closeFilter (this=0x5646142341c0 
) at prnt/hpcups/HPCupsFilter.cpp:221
#7  HPCupsFilter::StartPrintJob (this=0x5646142341c0 , argc=, argv=0x7ffc2a13fd48) at prnt/hpcups/HPCupsFilter.cpp:617
...

Description: Grow m_pPrinterBuffer if needed on each page

Author: Bernhard Übelacker 
Bug-Debian: https://bugs.debian.org/974828
Bug-Ubuntu: https://launchpad.net/bugs/1904318
Last-Update: 2021-02-26

Index: hplip-3.20.11+dfsg0/prnt/hpcups/HPCupsFilter.cpp
===
--- hplip-3.20.11+dfsg0.orig/prnt/hpcups/HPCupsFilter.cpp
+++ hplip-3.20.11+dfsg0/prnt/hpcups/HPCupsFilter.cpp
@@ -199,7 +199,7 @@ void HPCupsFilter::WriteKBMPRaster (FILE
 fwrite (black_raster, 1, adj_k_width, fp);
 }
 
-HPCupsFilter::HPCupsFilter() : m_pPrinterBuffer(NULL)
+HPCupsFilter::HPCupsFilter() : m_pPrinterBuffer(NULL), m_PrinterBufferSize(0)
 {
 setbuf (stderr, NULL);
 
@@ 

Bug#983365: linphone-desktop: chat messages

[Bernhard Schmidt]

Am 26.02.21 um 15:19 schrieb Bill Blough:

Hi Bill,

> Hi,
> 
>> Have you reached out to the SOCI maintainer in private already? I don't
>> see a bug report on this. If we can get a targeted fix uploaded for this
>> within the next days (next step of the freeze is on March 10th, with a
>> migration time of 10 days right now) I will attempt to push through a
>> new src:linphone upload. Do you know whether we need a new
>> src:linphone-desktop upload as well?
> 
> I'm the SOCI maintainer.   Dennis did email me and explain the
> situation, and I don't see an issue making the change.
> 
> I'll prepare the upload today.  If someone would please file a bug
> against SOCI regarding this, I would appreciate it.

Thanks, I've opened Bug#983572 for this.

Bernhard

Bug#983365: linphone-desktop: chat messages

[Bernhard Schmidt]

Hi Dennis,

thanks a lot for debugging this! BTW, linphone is in desperate need of
co-maintainers :-)   That's a lot more useful than complaining about the
package not being tested (it is, but I do not know anyone using the Chat
feature, and I certainly don't).

Honestly I don't know why there is ENABLE_DB_STORAGE=NO, it sneaked in
during the packaging attempts. Possibly because libsoci wasn't usable
without the C++11 option you found.

Have you reached out to the SOCI maintainer in private already? I don't
see a bug report on this. If we can get a targeted fix uploaded for this
within the next days (next step of the freeze is on March 10th, with a
migration time of 10 days right now) I will attempt to push through a
new src:linphone upload. Do you know whether we need a new
src:linphone-desktop upload as well?

Have you confirmed already that the whole soci/linphone dance really
fixes this issue?

Bernhard

Am 25.02.21 um 18:58 schrieb Dennis Filder:
> Control: tag -1 + confirmed sid bullseye
> 
> I looked into this the past days, and I think this is actually a bug
> in d/rules in src:linphone.  I'm beginning to suspect that this is due
> to this line:
> 
>   -DENABLE_DB_STORAGE=NO \
> 
> Apparently the code for the once separate chat history and call
> history DBs has been merged into a single DB with special logic to
> handle the migration -- since I have no files from a previous version
> linphone-desktop 4.2.5 here does not even create anymore the sqlite3
> database linphone.db in ~/.local/share/linphone/ that David mentions,
> only call-history.db and friends.db are created (which matches the
> source code).  However, if the database storage isn't configured and
> compiled in then that new database is not going to work of course.
> Was there a specific reason for disabling this?  I could get
> linphone-4.4.21 to build with -DENABLE_DB_STORAGE=YES, but I had to
> first build+install a version of libsoci-dev that was compiled with
> -DSOCI_CXX11=YES.  I'll contact the soci maintainer to see if he can
> change that in time.
> 
> linphone-4.4.21/cmake/FindSoci.cmake calls the soci support
> experimental, but the official appimage ships with both libsoci_core.0
> and libsoci_sqlite3.0, so it should be stable enough for us, too.
> That warning is probably outdated.  I attached a diff of the linked-in
> shared libraries in Debian's and the AppImage's /usr/bin/linphone
> (4.2.5) to illustrate where else we deviate.
> 
> Another issue I ran into: during dh_auto_configure a CMake macro tries
> to invoke "git describe" to look up the tag for the build's branch.
> Setting GIT_EXECUTABLE to a shell script that emits the expected tag
> worked around that.  I used $(shell pwd) there to point to the script,
> but I don't know if this is the right way to do it.  Fix it if it's
> wrong.
> 
> I'll keep digging into this and let you know if I learn something new.
> 
> Regards,
> Dennis
> 

Bug#974828: Fwd: Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Bernhard Übelacker]

Sorry missed your email.


 Weitergeleitete Nachricht 
Betreff: Re: Bug#974828: printer-driver-hpcups: SIGABRT with "free(): 
invalid next size (normal)" in HPCupsFilter::cleanup

Datum: Thu, 25 Feb 2021 17:03:02 +0100
Von: Bernhard Übelacker 
An: 974...@bugs.debian.org



Hello Ian,
I tried to collect some informations for the
maintainer in the other report #972339.
Therefore I tried to reproduce this issue now too, because
my amd64 hardware is much faster as my armhf systems...

But I failed to reproduce maybe because I use the wrong ppd file,
or something else might be different here.

Do you still see this issue?

Maybe you could make your
/etc/cups/ppd/HP_Officejet_Pro_8610.ppd public?

Or maybe this issue might be reproducible just with
one of your print_step_2.raster file,
if size permits and its possible to make it public?

Kind regards,
Bernhard

Bug#974828: printer-driver-hpcups: SIGABRT with "free(): invalid next size (normal)" in HPCupsFilter::cleanup

[Bernhard Übelacker]

Hello Ian,
I tried to collect some informations for the
maintainer in the other report #972339.
Therefore I tried to reproduce this issue now too, because
my amd64 hardware is much faster as my armhf systems...

But I failed to reproduce maybe because I use the wrong ppd file,
or something else might be different here.

Do you still see this issue?

Maybe you could make your
/etc/cups/ppd/HP_Officejet_Pro_8610.ppd public?

Or maybe this issue might be reproducible just with
one of your print_step_2.raster file,
if size permits and its possible to make it public?

Kind regards,
Bernhard

Bug#983365: linphone-desktop: chat messages

[Bernhard Schmidt]

Control: tags -1 help

Dear David,

> 1- chat messages (history) are not displayed when I launch the app,
> although I can see they are in the .local/share/linphone/linphone.db
> file (using sqliteb or sqlitebrowser);
> 
> 2- when someone sends me a message, it 'pops' a notification with the
> message text (even if I am in front of the app) but the message is not
> displayed by the application itself, nor the little numbered circle that
> appears (on the appimage 4.2.5 version, to compare) i the left panel,
> in(on top of) the user 'entry', nor in the user chat 'room'.
> 
> I also verified that the message isn't added in the chat_message_content
> of the linphone.db table, and i can see the following 'trace' in the
> terminal i used to launchh the app:
> 
> [22:11:12:653][0x1ff9eb0][Info]components/sip-addresses/SipAddressesModel.cpp:485:
>  "Update (`sip:sender.na...@sip.linphone.org`, 
> `sip:my.n...@sip.linphone.org`) from chat message."

Thanks for your report. Unfortunately I'm extremely swamped for the next
couple of weeks. I have also never used the Chat feature. For this
reason I'm tagging this bug as "help".

Two short questions:
In Bug#983369 a few minutes later you wrote the date in the history is
wrong, although in this bug it reads like you cannot display the history
at all. Which one is correct?

Did you start a fresh linphone profile or is the sqlite database
upgraded from an older version? Could you (for a test) move it away to
have it recreated?

I fully understand choosing an RC severity, but I'm at a loss debugging
this and I lack the time to dig into it, so this bug might make
linphone-desktop miss the Bullseye release unless someone steps up to
debug this.

Bernhard

Bug#978616: mediastreamer2: doesn't build correct libraries with cmake?

[Bernhard Schmidt]

Dear Gianfranco,

Thanks for filing this bug report. I’m away for the next couple of days and 
could not check, but wouldn’t just patching the pkgconfig file (your second 
option) be a lot easier? Upstream merged both libraries and they probably just 
forgot to change the pkgconfig file as well.

In the end linphone upstream does not seem to care much about other programs 
using their library. 

Bernhard

> Am 29.12.2020 um 11:00 schrieb Gianfranco Costamagna 
> :
> Source: mediastreamer2
> Version: 1:4.4.21-2
> Severity: serious
> 
> Hello, looks like with autotools, the library provides libmediastreamer_base 
> and libmediastreamer_voip,
> while with cmake it doesn't.
> 
> the pkgconfig file is obviously wrong, but I don't know which solution you 
> prefer (and if you are aware of this issue).
> 
> I propose two solutions:
> 1) implement the library split in cmake, and upstream it (this might be the 
> preferred and easier solution to this issue)
> 2) patch pkgconfig file and cmake helpers to provide only one library to link.
> 
> if we choose 1, we should probably also change the ABI, so call it 
> libmediastreamer11a or similar, to trigger a rebuild of reverse dependencies.
> 
> If you agree with 1) I can try to provide a patch as soon as possible.
> 
> thanks
> 
> Gianfranco

Bug#978489: QML QtQuick dependencies

[Bernhard Schmidt]

Hi,

I've recently packaged a QML based application (linphone-desktop) and I
have been hit with a couple of missing qml-module-* dependencies in the
resulting binary package which caused RC bugs.

The latest one
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=978489) I cannot even
reproduce locally, but the crash is pretty obvious

[00:50:46:566][0x5618e548aed0][Info]app/App.cpp:784: "Open Linphone app."
[00:50:46:566][0x5618e548aed0][Info]app/App.cpp:225: "Creating
subwindow: `qrc:/ui/views/App/Calls/CallsWindow.qml`."
[00:50:46:608][0x5618e548aed0][Warning]app/App.cpp:229:
(qrc:/ui/views/App/Calls/CallsWindow.qml:191:9: Type Chat unavailable
Chat {
^, qrc:/ui/modules/Linphone/Chat/Chat.qml:215:7: Type
DroppableTextArea unavailable
  DroppableTextArea {
  ^, qrc:/ui/modules/Common/Form/DroppableTextArea.qml:108:5:
Type FileDialog unavailable
FileDialog {
^,
file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:42:1:
module "QtQuick.Controls" version 1.2 is not installed
import QtQuick.Controls 1.2
^)

As far as I can tell DefaultFileDialog.qml (from
qml-module-qtquick-dialogs) is using QtQuick.Controls 1.2 (from
qml-module-qtquick-controls) without declaring a dependency, so the
issue is actually not with linphone but with
qtquickcontrols-opensource-src . Am I reading this correctly?

Is there any debhelper or other tool to check/set the qml dependencies
at build time? The only way I could find so far is to run something
alike to

git grep -h "import QtQuick" | sort | uniq | sort

in the source directory and map all of them to package names. But that's
error prone.

Thanks,
Bernhard

Bug#978489: missing dependency on qml-module-qtquick-controls

[Bernhard Schmidt]

Control: tags -1 + pending

Hi Marco,

Am 28.12.20 um 01:00 schrieb Marco d'Itri:
> Package: linphone-desktop
> Version: 4.2.5-2
> Severity: grave
> 
> Or else linphone will crash with:
> 
> [00:50:46:566][0x5618e548aed0][Info]app/App.cpp:784: "Open Linphone app."
> [00:50:46:566][0x5618e548aed0][Info]app/App.cpp:225: "Creating subwindow: 
> `qrc:/ui/views/App/Calls/CallsWindow.qml`."
> [00:50:46:608][0x5618e548aed0][Warning]app/App.cpp:229: 
> (qrc:/ui/views/App/Calls/CallsWindow.qml:191:9: Type Chat unavailable
> Chat {
> ^, qrc:/ui/modules/Linphone/Chat/Chat.qml:215:7: Type 
> DroppableTextArea unavailable
>   DroppableTextArea {
>   ^, qrc:/ui/modules/Common/Form/DroppableTextArea.qml:108:5: Type 
> FileDialog unavailable
> FileDialog {
> ^, 
> file:///usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Dialogs/DefaultFileDialog.qml:42:1:
>  module "QtQuick.Controls" version 1.2 is not installed
> import QtQuick.Controls 1.2
> ^)

*sigh*

I have no reason to doubt you, but it works fine in a fresh Bullseye VM
with Xfce installed and then "apt --no-install-recommends install
linphone-desktop/unstable". qml-module-qtquick-controls is definitely
not installed.

I'll add that dependency with the next upload, but I need to find a way
to enumerate all possible dependencies at build time.

Bernhard

Bug#957480: libsrtp2: ftbfs with GCC-10

[Bernhard Schmidt]

Control: tags -1 patch

This might fix it...

https://github.com/cisco/libsrtp/commit/716a73862b387a2107f37398c0fb7d9a754c0ccd

Bug#977590: freeradius: After upgrade to buster, freeradius doesn't talk over the network anymore

[Bernhard Schmidt]

Control: severity -1 important
Control: tags -1 moreinfo

Hi Harald,

I'm going to downgrade this because

- it does not break unrelated software ... The radius server not running
might cause other software not to be able to authenticate anymore, but
Radius can be easily made redundant.
- this is the first report received from oldstable to stable (which has
been out for 1,5 years), so I don't think it's widespread.

That being said...

> I then copied the whole /etc/freeradius directory from the previous
> setup, and started freeradius -X again. The output is now as it should;

[...]

> I have a recursive diff of both config dirs, but haven't been
> able to see what has done what. I still have a test-server so
> I can help with providing more info is so needed. 

Please attach the diff to this bug report.

Bernhard

Bug#925775: mediastreamer2: ftbfs with GCC-9

[Bernhard Schmidt]

Am 06.12.20 um 21:33 schrieb Paul Gevers:

Hi Paul,

> On Wed, 27 Mar 2019 19:47:03 + Matthias Klose  wrote:
>> The package fails to build in a test rebuild on at least amd64 with
>> gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The
>> severity of this report will be raised before the bullseye release,
>> so nothing has to be done for the buster release.
> 
> Do you intent to fix this in unstable soon too? The freeze is getting
> closer and we'd like to have this fixed in bullseye too.

Yes, sorry about that.

The whole linphone stack has to be updated at once. I have staged the
latest upstream releases in experimental. As soon as linphone and
linphone-desktop clear the NEW queue I think we are ready. The
transition is mostly self-contained and should be easy.

Bernhard

Bug#925638: Bug#892325: Bug#925638: closed by Debian FTP Masters (reply to Bernhard Schmidt ) (Bug#925638: fixed in belle-sip 4.3.1+dfsg-1)

[Bernhard Schmidt]

Am 04.12.20 um 23:45 schrieb Bernhard Schmidt:
> Hi,
> 
> 
> Am 04.12.20 um 19:23 schrieb Bernhard Schmidt:
>> Dear Mika,
>>
>>> belle-sip is currently missing in Debian/testing AKA bullseye
>>> because of this issue (which is only fixed in experimental yet):
>>>
>>> | Migration status for belle-sip (- to 1.6.3-5): BLOCKED: Rejected/violates 
>>> migration policy/introduces a regression
>>> | Issues preventing migration:
>>> | Updating belle-sip introduces new bugs: #925638.
>>>
>>> I'm aware that "This package will soon be part of the auto-belle-sip
>>> transition", but given that the bullseye freeze is coming closer,
>>> I'm just wondering if there are any plans to upload belle-sip
>>> v4.3.1+dfsg-1 towards unstable and whether we might see it in
>>> bullseye?
>>
>> yes, I have been dragging this far too long, sorry :-(
>>
>> The problem is, the whole linphone library stack is ready, but I did not
>> manage yet to build a package for linphone(-desktop), the Qt successor
>> of the old Gtk client in src:linphone. The build system is weird, with a
>> lot of fiddling I can get it to build something, but it is installed in
>> weird paths relative to the buildpath and I cannot figure out why. Nor
>> have I managed to workaround this.
> 
> I have sat down and did another stab at it. The repositories for
> OpenSuSE and Arch Linux were very helpful to find the necessary
> settings, but it still looks messy.
> 
> The code is at
> https://salsa.debian.org/pkg-voip-team/linphone-stack/linphone-desktop .
> Together with the packages already in experimental this COULD work. I
> can't test right now because I'm running out of time and I am sitting in
> front of a stable system, so no easy way to run experimental.
> 
> Anyone willing to take a look?

Both linphone and linphone-desktop have now been updated and are
currently in NEW (linphone already is, linphone-desktop should be within
the next hour). Hopefully we will have them accepted soon.

Bernhard

Bug#925638: closed by Debian FTP Masters (reply to Bernhard Schmidt ) (Bug#925638: fixed in belle-sip 4.3.1+dfsg-1)

[Bernhard Schmidt]

Hi,


Am 04.12.20 um 19:23 schrieb Bernhard Schmidt:
> Dear Mika,
> 
>> belle-sip is currently missing in Debian/testing AKA bullseye
>> because of this issue (which is only fixed in experimental yet):
>>
>> | Migration status for belle-sip (- to 1.6.3-5): BLOCKED: Rejected/violates 
>> migration policy/introduces a regression
>> | Issues preventing migration:
>> | Updating belle-sip introduces new bugs: #925638.
>>
>> I'm aware that "This package will soon be part of the auto-belle-sip
>> transition", but given that the bullseye freeze is coming closer,
>> I'm just wondering if there are any plans to upload belle-sip
>> v4.3.1+dfsg-1 towards unstable and whether we might see it in
>> bullseye?
> 
> yes, I have been dragging this far too long, sorry :-(
> 
> The problem is, the whole linphone library stack is ready, but I did not
> manage yet to build a package for linphone(-desktop), the Qt successor
> of the old Gtk client in src:linphone. The build system is weird, with a
> lot of fiddling I can get it to build something, but it is installed in
> weird paths relative to the buildpath and I cannot figure out why. Nor
> have I managed to workaround this.

I have sat down and did another stab at it. The repositories for
OpenSuSE and Arch Linux were very helpful to find the necessary
settings, but it still looks messy.

The code is at
https://salsa.debian.org/pkg-voip-team/linphone-stack/linphone-desktop .
Together with the packages already in experimental this COULD work. I
can't test right now because I'm running out of time and I am sitting in
front of a stable system, so no easy way to run experimental.

Anyone willing to take a look?

Bernhard

Bug#925638: closed by Debian FTP Masters (reply to Bernhard Schmidt ) (Bug#925638: fixed in belle-sip 4.3.1+dfsg-1)

[Bernhard Schmidt]

Dear Mika,

> belle-sip is currently missing in Debian/testing AKA bullseye
> because of this issue (which is only fixed in experimental yet):
> 
> | Migration status for belle-sip (- to 1.6.3-5): BLOCKED: Rejected/violates 
> migration policy/introduces a regression
> | Issues preventing migration:
> | Updating belle-sip introduces new bugs: #925638.
> 
> I'm aware that "This package will soon be part of the auto-belle-sip
> transition", but given that the bullseye freeze is coming closer,
> I'm just wondering if there are any plans to upload belle-sip
> v4.3.1+dfsg-1 towards unstable and whether we might see it in
> bullseye?

yes, I have been dragging this far too long, sorry :-(

The problem is, the whole linphone library stack is ready, but I did not
manage yet to build a package for linphone(-desktop), the Qt successor
of the old Gtk client in src:linphone. The build system is weird, with a
lot of fiddling I can get it to build something, but it is installed in
weird paths relative to the buildpath and I cannot figure out why. Nor
have I managed to workaround this.

With this crucial last element missing, I am not convinced that a) the
whole linphone stack works and b) the migration path for upgrades has
been sufficiently well laid out to get it into unstable.

I'll try to find some time to work on this.

Bernhard

Bug#957470: FTBFS Bugs in Debian revdeps dahdi-tools and libpri

[Bernhard Schmidt]

Hi Tzafrir,
>>
>> could you have a look at Bug#957117 and #957470? They are causing
>> Asterisk to be removed from testing.
> 
> Uploaded a fix for dahdi-tools. As for libpri: this is basically using
> index from data[0] that is the end of the header.
> 
> My "fix" is to silence those checks (see patches). There hopefully seems
> to be some upstream work, but I'm not sure how long it would take.

Sorry to bug you again, but those bugs still affect unstable (libpri fix
was never uploaded and dahdi-tools FTBFS on armel/mipsel).

With the freeze upcoming I fear we have to remove dahdi support at some
time. Note that this would involve dropping the asterisk-dahdi binary
package, so a reintroduction would need a trip through NEW.

Bernhard

Bug#943396: FTBFS on armhf: testsuite segfault

[Bernhard Übelacker]

Dear Maintainer,
a short addition.
The backtrace that I received building with CC=gcc-10 seems
to be the same as in #972665, therefore they might be related?

Kind regards,
Bernhard