Bug#1067023: ITP: vaultwarden -- Bitwarden compatible server written in Rust

[Bernhard Dick]

Hi,

currently I'm working on getting the rust libraries from the dependency 
tree from vaultwarden into Debian. This is a requirement to build the 
final binary "the Debian way".
Help on that side would be very much appreciated as there is a high 
amount of packages needed. So please let me know if you want to build 
part of that tree.
Problems with the approach in the referenced buildspecs are now already 
answered by the maintainer within the issue you mentioned.


  Best Regards,
    Bernhard

Bug#1070687: systemsettings: received signal SIGSEGV, Segmentation fault

[Bernhard Übelacker]

On Tue, 07 May 2024 11:30:41 +0200 antonio  wrote:


Dear Maintainer,
when I try to add a online account (Systemsettings->Pesonalization->Online
Accounts->Add new account... button) I get this error:

Thread 1 "systemsettings" received signal SIGSEGV, Segmentation fault.
0x7fffc40f8765 in Accounts::Provider::~Provider() () from
/usr/lib/x86_64-linux-gnu/libaccounts-qt5.so.1

where:
libaccounts-qt5-1=1.17-1



Dear Maintainer,
I still can reproduce this with current Trixie/testing [1] [2].

The crash seems to happen because for some reason the member m_tags
contains an invalid pointer 0x1 [3].

With rr-debugger I could record such a crash and reverse execute to
where m_tags got overwritten with this 0x1 [4].

Unfortunately I still cannot tell the exact reason,
because the crash no longer happens with a locally rebuilt
package libkaccounts2.

Therefore, might this be an ABI break?
And could be solved by a binNMU of libkaccounts2?

Kind regards,
Bernhard


[1]
#4  
#5  0x7f1fb43a2765 in Accounts::Provider::~Provider() () from 
/lib/x86_64-linux-gnu/libaccounts-qt5.so.1
#6  0x7f1fb43bf198 in ProvidersModel::data(QModelIndex const&, int) const 
() from /lib/x86_64-linux-gnu/libkaccounts.so.2
#7  0x7f1fce9d44f0 in ?? () from /lib/x86_64-linux-gnu/libQt5QmlModels.so.5


[2]
With debug symbols:
#4  
#5  std::__atomic_base::load (__m=std::memory_order_relaxed, this=) at 
/usr/include/c++/13/bits/atomic_base.h:503
#6  QAtomicOps::loadRelaxed (_q_value=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qatomic_cxx11.h:239
#7  QBasicAtomicInteger::loadRelaxed (this=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qbasicatomic.h:107
#8  QtPrivate::RefCount::deref (this=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qrefcount.h:66
#9  QHash::~QHash (this=0x1, __in_chrg=) at /usr/include/x86_64-linux-gnu/qt5/QtCore/qhash.h:250
#10 QSet::~QSet (this=0x1, __in_chrg=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qset.h:53
#11 Accounts::Provider::~Provider (this=, __in_chrg=) at ./Accounts/provider.cpp:93
#12 0x7f1fb43bf198 in ProvidersModel::data (this=, index=..., 
role=) at ./src/lib/providersmodel.cpp:105
#13 0x7f1fce9d44f0 in QModelIndex::data (arole=261, this=0x7ffddfe29ce0) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qabstractitemmodel.h:460


[3]
93  delete m_tags;
(rr) print this
$1 = (Accounts::Provider * const) 0x7ffc316dca20
(rr) print *this
$2 = {m_provider = 0x55b1af209730, m_tags = 0x1}
(rr) print >m_tags
$4 = (QSet **) 0x7ffc316dca28


[4]
(rr) watch *0x7ffc316dca28
Hardware watchpoint 1: *0x7ffc316dca28
(rr) reverse-cont
Continuing.
Thread 1 hit Hardware watchpoint 1: *0x7ffc316dca28
Old value = 1
New value = 0
0x7f97bc1bc223 in ProvidersModel::data (this=0x55b1af23c460, index=..., 
role=261) at ./src/lib/providersmodel.cpp:86
86  data.setValue(!provider.isSingleAccount());
(rr) bt
#0  0x7f97bc1bc223 in ProvidersModel::data(QModelIndex const&, int) const 
(this=0x55b1af23c460, index=, role=261) at 
./src/lib/providersmodel.cpp:86
#1  0x7f97c8a6f4f0 in QModelIndex::data(int) const (arole=261, 
this=0x7ffc316dcac0) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qabstractitemmodel.h:460
#2  QQmlDMAbstractItemModelData::value(int) const (role=261, 
this=0x55b1af0f5610) at ./src/qmlmodels/qqmladaptormodel.cpp:414
#3  QQmlDMCachedModelData::metaCall(QMetaObject::Call, int, void**) (this=0x55b1af0f5610, 
call=, id=, arguments=0x7ffc316dcb70) at 
./src/qmlmodels/qqmladaptormodel.cpp:282
#4  0x7f97cada4fd6 in  () at /lib/x86_64-linux-gnu/libQt5Qml.so.5

Bug#1070220: jbig2: broken manual page: src/jbig2: error while loading shared libraries: libjbig2enc.so.0: cannot open shared object file: No such file or directory

[Bernhard Übelacker]

On Thu, 02 May 2024 12:28:29 +0800 Paul Wise  wrote:


The jbig2 manual page is broken. Looks like it was generated via
help2man using the binary in the build tree but without using
LD_LIBRARY_PATH so the binary could not find libraries it uses,
so jbig2 could not start, so it didn't print the usage statement
and help2man did not convert the usage statement to a manual page.
The help2man conversion in debian/rules may have some kind of problem.




Hello,
it looks like make is not exporting the variable by default
to the environment of subprocesses.

This could be achieved by adding the below export [1].

Another way would be to move the LD_LIBRARY_PATH assignment
to the same line of help2man [2].

Kind regards,
Bernhard



[1]
--- orig/jbig2enc-0.29/debian/rules 2024-02-28 14:02:09.0 +0100
+++ try5/jbig2enc-0.29/debian/rules 2024-05-18 11:13:29.796407931 +0200
@@ -53,2 +53,3 @@ override_dh_installchangelogs:
 jbig2.1: LD_LIBRARY_PATH = src/.libs
+export LD_LIBRARY_PATH
 jbig2.1: %.1: src/%


[2]
--- orig/jbig2enc-0.29/debian/rules 2024-02-28 14:02:09.0 +0100
+++ try2/jbig2enc-0.29/debian/rules 2024-05-18 10:07:46.877615011 +0200
@@ -52,5 +52,4 @@ override_dh_installchangelogs:
 # build manpages
-jbig2.1: LD_LIBRARY_PATH = src/.libs
 jbig2.1: %.1: src/%
-   help2man --section 1 --no-info --no-discard-stderr \
+   LD_LIBRARY_PATH=src/.libs help2man --section 1 --no-info 
--no-discard-stderr \
--name "encoder for JBIG2" \

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  0x7f988d93074c 
_ZSt16__ostream_insertIcSt11char

Bug#1054080: stlcmd: stl_boolean segfaults on some inputs

[Bernhard Übelacker]

Hello,
I am not maintainer of stlcmd, just tried to collect some more information.

This crash seems to be a stack overflow because of a recursive function call.

There is a comment near that recursive call, which could be interesting here.
And this issue seems not to be a packaging issue in Debian, therefore it
might be better to report this issue upstream in [2].

Kind regards,
Bernhard

[1] 
https://github.com/AllwineDesigns/stl_cmd/blob/7c2582864df1c10d11f5acb4901fb04c55ea7492/src/csgjs/Trees.cpp#L44-L55
[2] https://github.com/AllwineDesigns/stl_cmd/issues


Core was generated by `stl_boolean -a one.stl -b intersection.stl -d 
one-additions.stl'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fe2a95c855e in _int_malloc (av=av@entry=0x7fe2a9712b80 , 
bytes=bytes@entry=512) at malloc.c:3637
3637malloc.c: Datei oder Verzeichnis nicht gefunden.
(gdb) bt
#0  0x7fe2a95c855e in _int_malloc (av=av@entry=0x7fe2a9712b80 , 
bytes=bytes@entry=512) at malloc.c:3637
#1  0x7fe2a95c9de4 in __GI___libc_malloc (bytes=512) at malloc.c:3058
#2  0x7fe2a991c0b5 in operator new(unsigned long) () from 
/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x56309140a744 in __gnu_cxx::new_allocator::allocate 
(this=, __n=) at 
/usr/include/c++/7/ext/new_allocator.h:111
#4  std::allocator_traits >::allocate 
(__a=..., __n=) at /usr/include/c++/7/bits/alloc_traits.h:436
#5  std::_Vector_base 
>::_M_allocate (this=0x210, this@entry=0x7fff7ccf8470, __n=) at 
/usr/include/c++/7/bits/stl_vector.h:172
#6  std::vector 
>::_M_realloc_insert (this=this@entry=0x7fff7ccf8470, 
__position=, __args#0=@0x7fff7ccf82a0: 
0x563093c75b00) at /usr/include/c++/7/bits/vector.tcc:406
#7  0x56309140a84b in std::vector >::emplace_back 
(this=this@entry=0x7fff7ccf8470, __args#0=@0x7fff7ccf82a0: 0x563093c75b00) at 
/usr/include/c++/7/bits/vector.tcc:105
#8  0x563091409a9a in std::vector >::push_back (__x=@0x7fff7ccf82a0: 
0x563093c75b00, this=0x7fff7ccf8470) at /usr/include/c++/7/bits/stl_vector.h:954
#9  csgjs::PolygonTreeNode::splitPolygonByPlane 
(this=this@entry=0x563093c75b00, plane=..., coplanarFrontNodes=std::vector of 
length 0, capacity 0, coplanarBackNodes=std::vector of length 32, capacity 32 = 
{...},  frontNodes=std::vector of length 0, capacity 0, backNodes=std::vector 
of length 32, capacity 32 = {...}) at src/csgjs/Trees.cpp:298
#10 0x563091409d7c in csgjs::PolygonTreeNode::splitLeafByPlane 
(this=0x563093c75b00, plane=..., coplanarFrontNodes=std::vector of length 0, 
capacity 0,  coplanarBackNodes=std::vector of length 32, capacity 32 = {...}, 
frontNodes=std::vector of length 0, capacity 0, backNodes=std::vector of length 
32, capacity 32 = {...}) at src/csgjs/Trees.cpp:239
#11 0x563091409f67 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390cc0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:40
#12 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390a50, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#13 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x5630963907e0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#14 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390570, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#15 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563096390300, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
...
#65433 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99510, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65434 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c994b0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65435 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99880, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65436 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99820, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65437 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c997c0, polyTreeNodes=std::vector of length 60, 
capacity 64 = {...}) at src/csgjs/Trees.cpp:54
#65438 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c99720, polyTreeNodes=std::vector of length 113, 
capacity 128 = {...}) at src/csgjs/Trees.cpp:54
#65439 0x56309140a061 in csgjs::Node::addPolygonTreeNodes 
(this=this@entry=0x563093c68e20, polyTreeNodes=std::vector of length 497, 
capacity 512 = {...}) at src/csgjs/Trees.cpp:54
#65440 0x563091409ff8

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#1069598: cifs-utils: When mounting a samba-share by a client with kernel 6.1.0-20-amd64, some subdirectories and files within the mounted share are missing

[Bernhard Übelacker]

Hello,
this seems to be the same issue as here:

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

And the fix seems to be prepared here:
https://salsa.debian.org/kernel-team/linux/-/commit/37a0ac93027302ffbfae41ddc844312e88e72eef

Kind regards,
Bernhard

Bug#1057620: doomsday: Crashes on startup

[Bernhard Übelacker]

On Tue, 05 Dec 2023 23:39:39 + Witold Baryluk  
wrote:


Thread 1 "doomsday" received signal SIGSEGV, Segmentation fault.
0x75419e83 in _XFlush () from /lib/x86_64-linux-gnu/libX11.so.6
(gdb) bt
#0  0x75419e83 in _XFlush () at /lib/x86_64-linux-gnu/libX11.so.6
#1  0x7541cb3d in _XGetRequest () at /lib/x86_64-linux-gnu/libX11.so.6
#2  0x7540fa57 in XQueryExtension () at 
/lib/x86_64-linux-gnu/libX11.so.6
#3  0x75402b16 in XInitExtension () at /lib/x86_64-linux-gnu/libX11.so.6
#4  0x753cdc9b in XextAddDisplay () at 
/lib/x86_64-linux-gnu/libXext.so.6
#5  0x7538a860 in  () at /lib/x86_64-linux-gnu/libXrandr.so.2
#6  0x7538afc0 in XRRQueryExtension () at 
/lib/x86_64-linux-gnu/libXrandr.so.2
#7  0x7798bae4 in de::internal::RRInfo::RRInfo() () at 
/lib/x86_64-linux-gnu/libdeng_gui.so.2.3
#8  0x7798b02d in DisplayMode_Native_Init () at 
/lib/x86_64-linux-gnu/libdeng_gui.so.2.3
#9  0x7791fd11 in DisplayMode_Init () at 
/lib/x86_64-linux-gnu/libdeng_gui.so.2.3
#10 0x5573eb1d in ClientApp::initialize() ()
#11 0x5572175d in main ()
(gdb) 



Running under gnome shell.

xwayland 2:23.2.2-1



Hello,
I am not maintainer of the doomsday package, just tried to collect some
more information.

Bug 1062969 / Bug 1065714 mentions a workaround
to be able to run doomsday with wayland:

SDL_VIDEODRIVER=x11 QT_QPA_PLATFORM=xcb doomsday


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


It looks like upstream removed the relevant code and relies just
on SDL functions, but unfortunately did not release a new version yet.


https://github.com/skyjake/Doomsday-Engine/commit/5cc4995861


Kind regards,
Bernhard
# 2024-05-05 Trixie/testing amd64 qemu VM

apt update
apt dist-upgrade
apt install systemd-coredump task-gnome-desktop tmux git gdb rr doomsday 
doomsday-dbgsym doomsday-common-dbgsym libxrandr2-dbgsym libxext6-dbgsym 
libx11-6-dbgsym
apt build-dep libx11-6




mkdir /home/benutzer/source/libx11-6/orig -p
cd/home/benutzer/source/libx11-6/orig
apt source libx11-6




benutzer@debian:~$ doomsday
QSocketNotifier: Can only be used with threads started with QThread
Speicherzugriffsfehler (Speicherabzug geschrieben)


benutzer@debian:~$ coredumpctl list
TIME  PID  UID  GID SIG COREFILE EXE
   SIZE
Sun 2024-05-05 16:04:00 CEST 2967 1000 1000 SIGSEGV present  
/usr/games/doomsday-2.3.1 2.7M


benutzer@debian:~$ coredumpctl gdb --debugger-arguments=-q 2967
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: 2967 (doomsday)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Sun 2024-05-05 16:04:00 CEST (1min 51s ago)
  Command Line: doomsday
Executable: /usr/games/doomsday-2.3.1
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-org.gnome.Terminal.slice/vte-spawn-1c8dc387-bf63-4b3f-9404-fea9f4d9f742.scope
  Unit: user@1000.service
 User Unit: vte-spawn-1c8dc387-bf63-4b3f-9404-fea9f4d9f742.scope
 Slice: user-1000.slice
 Owner UID: 1000 (benutzer)
   Boot ID: 13ee1fcd8e5043bf91db85c4d1c72a51
Machine ID: 16e4d7437c19482b8c85581d3feaba09
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.doomsday.1000.13ee1fcd8e5043bf91db85c4d1c72a51.2967.171491784000.zst
 (present)
  Size on Disk: 2.7M
   Message: Process 2967 (doomsday) of user 1000 dumped core.

Module libblkid.so.1 from deb util-linux-2.40-8.amd64
Module libmount.so.1 from deb util-linux-2.40-8.amd64
Module libsystemd.so.0 from deb systemd-255.5-1.amd64
Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Stack trace of thread 2967:
#0  0x7effce83 _XFlush (libX11.so.6 + 0x44e83)
#1  0x7effc0003b3d _XGetRequest (libX11.so.6 + 0x47b3d)
#2  0x7effbfff6a57 XQueryExtension (libX11.so.6 + 0x3aa57)
#3  0x7effbffe9b16 XInitExtension (libX11.so.6 + 0x2db16)
#4  0x7effc1b9bc9b XextAddDisplay (libXext.so.6 + 0xdc9b)
#5  0x7effc0ce484f n/a (libXrandr.so.2 + 0x284f)
#6  0x7effc0ce4f88 XRRQueryExtension (libXrandr.so.2 + 
0x2f88)
#7  0x7effc25af3b1 _ZN2de8internal6RRInfoC1Ev 
(libdeng_gui.so.2.3 + 0xe03b1)
#8  0x7effc25ae7ef DisplayMode_Native_Init 
(libdeng_gui.so.2.3 + 0xdf7ef)
#9  0x7effc253e619 DisplayMode_Init (libdeng_gui.so.2.3 + 
0x6f619)
#10 0x560786a6520d _ZN9ClientApp10initializeEv 
(doomsday-2.3.1 + 0x1fc20d)
#11 0x560786a

Bug#1053128: smbclient: "smbtree -N" causes a segfault when "server min protocol = NT1"

[Bernhard Übelacker]

Hello,
I am not a samba maintainer, just trying to collect some more information.

As far as I see the crash happens
because "cli_credentials_get_password(creds)" in line 62
returns a null pointer, which gets forwarded to
the call to strlcpy without further check.

Kind regards,
Bernhard



(rr) reverse-finish
Run back to call of #0  strlcpy (dst=0x7fff875c0640 "", src=0x0, dsize=) at ./src/strlcpy.c:36
0x5574e9c43c8c in get_auth_data_with_context_fn (context=, server=, 
share=, domain=, domain_len=, user=, 
user_len=256, password=0x7fff875c0640 "", password_len=256) at source3/utils/smbtree.c:61
61  len = strlcpy(
(rr) bt
#0  0x5574e9c43c8c in get_auth_data_with_context_fn (context=, server=, 
share=, domain=, domain_len=, user=, 
user_len=256, password=0x7fff875c0640 "", password_len=256) at source3/utils/smbtree.c:61
#1  0x7f9851ec6510 in SMBC_call_auth_fn (ctx=ctx@entry=0x5574eb8ba610, 
context=context@entry=0x5574eb8b7900, server=server@entry=0x5574eb8c9fe0 "10.0.2.15", 
share=share@entry=0x7f9851ed46a4 "IPC$", pp_workgroup=pp_workgroup@entry=0x7fff875c09b8, 
pp_username=pp_username@entry=0x7fff875c09a0, pp_password=0x7fff875c09a8) at 
source3/libsmb/libsmb_server.c:171
...

(rr) list smbtree.c:42
37
38  static void get_auth_data_with_context_fn(
39  SMBCCTX *context,
40  const char *server,
41  const char *share,
42  char *domain,
43  int domain_len,
44  char *user,
45  int user_len,
46  char *password,
47  int password_len)
48  {
49  struct cli_credentials *creds = samba_cmdline_get_creds();
50  size_t len;
51
52  len = strlcpy(domain, cli_credentials_get_domain(creds), 
domain_len);
53  if ((int)len >= domain_len) {
54  return;
55  }
56  len = strlcpy(
57  user, cli_credentials_get_username(creds), user_len);
58  if ((int)len >= user_len) {
59  return;
60  }
61  len = strlcpy(
62  password, cli_credentials_get_password(creds), 
password_len);
63  if ((int)len >= password_len) {
64  /* pointless, but what can you do... */
65  return;
66  }

# 2024-05-04 Trixie/testing amd64 qemu VM

apt install systemd-coredump mc gdb rr samba smbclient smbclient-dbgsym 
libsmbclient0-dbgsym libbsd0-dbgsym
apt build-dep samba



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



mc -e /etc/samba/smb.conf
 [global]
+server min protocol = NT1
 

testparm -s
systemctl enable --now smb
systemctl enable --now nmb
systemctl restart smbd nmbd
# Maybe a minute waiting is needed or this message appears "main: This is 
utility doesn't work if netbios name resolution is not configured."
smbtree -N --option="client min protocol = NT1"






benutzer@debian:~$ rr record smbtree -N --option="client min protocol = NT1"
rr: Saving execution to trace directory 
`/home/benutzer/.local/share/rr/smbtree-0'.
===
INTERNAL ERROR: Signal 11: Speicherzugriffsfehler in smbtree () () pid 9884 
(4.19.6-Debian)
If you are running a recent Samba version, and if you think this problem is not 
yet fixed in the latest versions, please consider reporting this bug, see 
https://wiki.samba.org/index.php/Bug_Reporting
===
PANIC (pid 9884): Signal 11: Speicherzugriffsfehler in 4.19.6-Debian
BACKTRACE: 14 stack frames:
 #0 
/usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(log_stack_trace+0x32) 
[0x7f9851a105c2]
 #1 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(smb_panic+0xd) 
[0x7f9851a1085d]
 #2 /usr/lib/x86_64-linux-gnu/samba/libgenrand-samba4.so.0(+0x28f5) 
[0x7f9851a108f5]
 #3 /lib/x86_64-linux-gnu/libc.so.6(+0x3c510) [0x7f9851acd510]
 #4 /lib/x86_64-linux-gnu/libbsd.so.0(strlcpy+0x10) [0x7f9851c7f900]
 #5 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14510) [0x7f9851ec6510]
 #6 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14ab1) [0x7f9851ec6ab1]
 #7 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x14bdb) [0x7f9851ec6bdb]
 #8 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0x156e4) [0x7f9851ec76e4]
 #9 /lib/x86_64-linux-gnu/libsmbclient.so.0(+0xd37f) [0x7f9851ebf37f]
 #10 smbtree(main+0x262) [0x5574e9c43692]
 #11 /lib/x86_64-linux-gnu/libc.so.6(+0x276ca) [0x7f9851ab86ca]
 #12 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x85) [0x7f9851ab8785]
 #13 smbtree(_start+0x21) [0x5574e9c43b21]
smb_panic(): calling panic action [/usr/share/samba/panic-action 9884]
smb_panic(): action returned status 0
Can not dump core: corepath not set up
benutzer@debian:~$


benutzer@debian:~$ rr replay --debugger-o

Bug#1057172: baloo-kf5: Baloo Service Crashes After Enabling 'Index File Contents' Option

[Bernhard Übelacker]

On Fri, 1 Dec 2023 00:26:27 +0100 Lucy  wrote:


#3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0)
#4 0x557d83358770 n/a (baloo_file + 0x13770)
#5 0x557d8335885d n/a (baloo_file + 0x1385d)
#6 0x557d83365bf1 n/a (baloo_file + 0x20bf1)
#7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0)



Hello,
I am not maintainer of baloo-kf5,
just just tried to collect some more information.

The interesting lines above in the stacktrace translate to this:
...
#3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0)  |
#4 0x557d83358770 n/a (baloo_file + 0x13770)  | in 
QString::QString(QString const&) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qstring.h:1093
#5 0x557d8335885d n/a (baloo_file + 0x1385d)  | in 
QList::append(QString const&) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qlist.h:623
#6 0x557d83365bf1 n/a (baloo_file + 0x20bf1)  | in 
Baloo::FileContentIndexer::slotFinishedIndexingFile(QString const&, bool) at 
./src/file/filecontentindexer.cpp:125
#7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0) | 

...


Unfortunately this leads just to some upstream bugs,
which are not showing much more information.

https://bugs.kde.org/show_bug.cgi?id=441860
https://bugs.kde.org/show_bug.cgi?id=443483
https://bugs.kde.org/show_bug.cgi?id=476479


Kind regards,
Bernhard

Stack trace of thread 1876:
#0 0x7fbe9c2a9d3c __pthread_kill_implementation (libc.so.6 + 0x8ad3c)
#1 0x7fbe9c25af32 __GI_raise (libc.so.6 + 0x3bf32)
#2 0x7fbe9cfabb46 _ZN6KCrash19defaultCrashHandlerEi (libKF5Crash.so.5 + 
0x5b46)
#3 0x7fbe9c25afd0 __restore_rt (libc.so.6 + 0x3bfd0)
#4 0x557d83358770 n/a (baloo_file + 0x13770)
#5 0x557d8335885d n/a (baloo_file + 0x1385d)
#6 0x557d83365bf1 n/a (baloo_file + 0x20bf1)
#7 0x7fbe9cadd6f0 _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2dd6f0)
#8 0x7fbe9cab16cd _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent 
(libQt5Core.so.5 + 0x2b16cd)
#9 0x7fbe9cab4681 
_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData 
(libQt5Core.so.5 + 0x2b4681)
#10 0x7fbe9cb0a153 n/a (libQt5Core.so.5 + 0x30a153)
#11 0x7fbe9b11e7a9 g_main_context_dispatch (libglib-2.0.so.0 + 0x547a9)
#12 0x7fbe9b11ea38 n/a (libglib-2.0.so.0 + 0x54a38)
#13 0x7fbe9b11eacc g_main_context_iteration (libglib-2.0.so.0 + 0x54acc)
#14 0x7fbe9cb09836 
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE
 (libQt5Core.so.5 + 0x309836)
#15 0x7fbe9cab017b _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE 
(libQt5Core.so.5 + 0x2b017b)
#16 0x7fbe9cab82d6 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x2b82d6)
#17 0x557d83353982 n/a (baloo_file + 0xe982)
#18 0x7fbe9c2461ca __libc_start_call_main (libc.so.6 + 0x271ca)
#19 0x7fbe9c246285 __libc_start_main_impl (libc.so.6 + 0x27285)
#20 0x557d83353b61 n/a (baloo_file + 0xeb61)

Thread 1 (Thread 0x7fbe9ac86540 (LWP 1876)):
[KCrash Handler]
#5 0x557d83358770 in ?? ()
#6 0x557d8335885d in ?? ()
#7 0x557d83365bf1 in ?? ()
#8 0x7fbe9cadd6f0 in QObject::event(QEvent*) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#9 0x7fbe9cab16cd in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5
#10 0x7fbe9cab4681 in QCoreApplicationPrivate::sendPostedEvents(QObject*, 
int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#11 0x7fbe9cb0a153 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5
#12 0x7fbe9b11e7a9 in g_main_context_dispatch () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#13 0x7fbe9b11ea38 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#14 0x7fbe9b11eacc in g_main_context_iteration () from 
/lib/x86_64-linux-gnu/libglib-2.0.so.0
#15 0x7fbe9cb09836 in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /lib/x86_64-linux-gnu/libQt5Core.so.5
#16 0x7fbe9cab017b in 
QEventLoop::exec(QFlags) () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#17 0x7fbe9cab82d6 in QCoreApplication::exec() () from 
/lib/x86_64-linux-gnu/libQt5Core.so.5
#18 0x557d83353982 in ?? ()
#19 0x7fbe9c2461ca in __libc_start_call_main 
(main=main@entry=0x557d833536e0, argc=argc@entry=1, 
argv=argv@entry=0x7ffd6ffbbe18) at ../sysdeps/nptl/libc_start_call_main.h:58
#20 0x7fbe9c246285 in __libc_start_main_impl (main=0x557d833536e0, argc=1, 
argv=0x7ffd6ffbbe18, init=, fini=, 
rtld_fini=, stack_end=0x7ffd6ffbbe08) at ../csu/libc-start.c:360
#21 0x557d83353b61 in ?? ()




# 2024-05-04 Bookworm/stable amd64 qemu VM



apt install --no-install-recommends --no-install-suggests gdb baloo-kf5 
baloo-kf5-dbgsym
apt build-dep baloo-kf5



mkdir /home/benutzer/source/baloo-kf5/orig -p
cd/home/benutzer/source/baloo-kf5/orig
apt source baloo-kf5



gdb -q
set width 0
set pagination off
directory /home/benutzer/

Bug#1059041: Xorg segfault when unlocking from Xscreensaver while video playback

[Bernhard Übelacker]

On Tue, 19 Dec 2023 20:22:43 +0100 Eduard Bloch  wrote:


#7  0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510)
#8  0x7fb149186702 n/a (amdgpu_drv.so + 0x16702)
#9  0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96)
#10 0x5577d8e75a6b xf86DPMSSet (Xorg + 0xd3a6b)



Hello,
I am not maintainer of xserver-xorg-video-amdgpu,
just tried to collect some more information.

The interesting lines above in the stacktrace translate to this:

Stack trace of thread 1011552:
...
#7  0x7fb14945a510 __restore_rt (libc.so.6 + 0x3c510) |
#8  0x7fb149186702 n/a (amdgpu_drv.so + 0x16702)  | in drmmode_set_mode at 
../../src/drmmode_display.c:1267
#9  0x7fb149186c96 n/a (amdgpu_drv.so + 0x16c96)  | in 
drmmode_set_mode_major at ../../src/drmmode_display.c:1371
#10 0x5577d8e75a6b xf86DPMSSet (Xorg + 0xd3a6b)   | in xf86DPMSSet
...

This leads to this [1] upstream issue and merge request [2].
Unfortunately this is not yet part of an upstream release.

A workaround could be a local build of xserver-xorg-video-amdgpu
containing the two commits. They are the first commits after the 23.0.0 release.

Kind regards,
Bernhard

[1] https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/issues/70
[2] 
https://gitlab.freedesktop.org/xorg/driver/xf86-video-amdgpu/-/merge_requests/85
# 2024-05-04 Trixie/testing amd64 qemu VM



apt install gdb xserver-xorg xserver-xorg-video-amdgpu xserver-xorg-core-dbgsym 
xserver-xorg-video-amdgpu-dbgsym
apt build-dep xserver-xorg-video-amdgpu



mkdir /home/benutzer/source/xserver-xorg-video-amdgpu/orig -p
cd/home/benutzer/source/xserver-xorg-video-amdgpu/orig
apt source xserver-xorg-video-amdgpu



gdb -q
set width 0
set pagination off
directory 
/home/benutzer/source/xserver-xorg-video-amdgpu/orig/xserver-xorg-video-amdgpu-23.0.0/debian/patches
file /usr/lib/xorg/Xorg
tb main
run
call dlopen("/usr/lib/xorg/modules/drivers/amdgpu_drv.so",0x101)
print (int)getpid()
shell cat /proc/2535/maps | grep amdgpu_drv | head -n1
b *(0x774f9000 + 0x16c96)
b *(0x774f9000 + 0x16702)
info b
pipe disassemble drmmode_set_mode_major | grep -i c96 -C3
pipe disassemble drmmode_set_mode | grep -i 702 -C3
list drmmode_display.c:1371
list drmmode_display.c:1267



benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) directory 
/home/benutzer/source/xserver-xorg-video-amdgpu/orig/xserver-xorg-video-amdgpu-23.0.0/debian/patches
Source directories searched: 
/home/benutzer/source/xserver-xorg-video-amdgpu/orig/xserver-xorg-video-amdgpu-23.0.0/debian/patches:$cdir:$cwd
(gdb) file /usr/lib/xorg/Xorg
Reading symbols from /usr/lib/xorg/Xorg...
Reading symbols from 
/usr/lib/debug/.build-id/77/6f662cfdbd2d0952921614575518e7c1b90261.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x4d260: file ../../../../dix/stubmain.c, line 33.
(gdb) run
Starting program: /usr/lib/xorg/Xorg 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe478, envp=0x7fffe488) 
at ../../../../dix/stubmain.c:33
33  ../../../../dix/stubmain.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call dlopen("/usr/lib/xorg/modules/drivers/amdgpu_drv.so",0x101)
$1 = (void *) 0x55803a80
(gdb) info inferior
  Num  Description   Connection   Executable
* 1process 2535  1 (native)   /usr/lib/xorg/Xorg 
(gdb) print (int)getpid()
$2 = 2535
(gdb) shell cat /proc/2535/maps | grep amdgpu_drv | head -n1
774f9000-7750 r--p  08:12 681046 
/usr/lib/xorg/modules/drivers/amdgpu_drv.so
(gdb) b *(0x774f9000 + 0x16c96)
Breakpoint 2 at 0x7750fc96: file ../../src/drmmode_display.c, line 1371.
(gdb) b *(0x774f9000 + 0x16702)
Breakpoint 3 at 0x7750f702: file ../../src/drmmode_display.c, line 1267.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x7750fc96 in drmmode_set_mode_major at 
../../src/drmmode_display.c:1371
3   breakpoint keep y   0x7750f702 in drmmode_set_mode at 
../../src/drmmode_display.c:1267
(gdb) pipe disassemble drmmode_set_mode_major | grep -i c96 -C3
   0x7750fc8b <+955>:   mov%r14,%rsi
   0x7750fc8e <+958>:   mov%rbx,%rdi
   0x7750fc91 <+961>:   call   0x7750f650 
   0x7750fc96 <+966>:   test   %eax,%eax
   0x7750fc98 <+968>:   jne0x7750fef8 

   0x7750fc9e <+974>:   mov0x30(%rsp),%rdi
   0x7750fca3 <+979>:   lea0x60(%rsp),%rsi
(gdb) pipe disassemble drmmode_set_mode | grep -i 702 -C3
   0x7750f6f8 <+168>:   jne0x7750f710 
   0x7750f6fa <+170>:   mov0x78(%rsi),%rsi
   0x7750f6fe <+174>:   mov0x10(%rsi),%rsi
   0x7

Bug#1059874: libuhd4.6.0: Segfault in gqrx related to libuhd 4.6.0

[Bernhard Übelacker]

Am 04.05.24 um 13:46 schrieb Bernhard Übelacker:

These end in some boost::asio functions:
   boost::asio::detail::scheduler::concurrency_hint() const at 
/usr/include/boost/asio/detail/scheduler.hpp:142



Forgot to attach how I got there:
  debugging.txt


And for reference the upstream ticket:
  https://github.com/gqrx-sdr/gqrx/issues/1331



[17674.068551] gqrx[3226752]: segfault at f4 ip 7f5fee944cd6 sp 
7f5f967f8870 error 4
[17674.068551] gqrx[3226753]: segfault at f4 ip 7f5fee944cd6 sp 
7f5f95ff7870 error 4 in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068558]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068557] traps: gqrx[3226749] general protection fault ip:7f5fee944cd6 
sp:7f5f977fb7d0 error:0
[17674.068558] gqrx[3226751]: segfault at f4 ip 7f5fee944cd6 sp 
7f5f96ff9870 error 4
[17674.068560]  likely on CPU 9 (core 1, socket 0)
[17674.068560]  likely on CPU 10 (core 2, socket 0)
[17674.068563]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068562] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 
bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 
f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89
[17674.068563] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 
bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 
f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89
[17674.068564]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068569] traps: gqrx[3226745] general protection fault ip:7f5fee944cd6 
sp:7f5fbe7f99d0 error:0
[17674.068571] gqrx[3226754]: segfault at f4 ip 7f5fee944cd6 sp 
7f5f957f6870 error 4
[17674.068575]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068576]  in libuhd.so.4.6.0[7f5fee721000+a5e000]
[17674.068578]  likely on CPU 12 (core 4, socket 0)
[17674.068580]  likely on CPU 14 (core 6, socket 0)
[17674.068580] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 
bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 
f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89
[17674.068583] Code: ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 
bf c0 00 00 00 00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 
f4 00 00 00 48 85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89


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 "ec 78 64 48 8b 04 25 28 00 00 00 48 89 44 24 68 31 c0 80 bf c0 00 00 00 
00 0f 85 ed 00 00 00 48 8b 45 30 48 8b 9d d0 00 00 00 <44> 8b b8 f4 00 00 00 48 
85 db 0f 84 3a 01 00 00 48 8b 43 18 48 89" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



# 2024-05-03 trixie/testing amd64 qemu VM

apt dist-upgrade
apt install systemd-coredump xserver-xorg slim jwm xterm gdb pipewire gqrx-sdr 
gqrx-sdr-dbgsym libuhd4.6.0-dbgsym
systemctl start slim




gdb -q 
set width 0
set pagination off
file /usr/bin/gqrx
tb main
run
pipe info target | grep -E "\.text.*libuhd"
find /b 0x743274a0, 0x74d7ee0a, 0xec, 0x78, 0x64, 0x48, 0x8b, 
0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 0x24, 0x68, 0x31, 0xc0, 
0x80, 0xbf, 0xc0, 0x00, 0x00, 0x00, 0x00, 0x0f, 0x85, 0xed, 0x00, 0x00, 0x00, 
0x48, 0x8b, 0x45, 0x30, 0x48, 0x8b, 0x9d, 0xd0, 0x00, 0x00, 0x00, 0x44, 0x8b, 
0xb8, 0xf4, 0x00, 0x00, 0x00, 0x48, 0x85, 0xdb, 0x0f, 0x84, 0x3a, 0x01, 0x00, 
0x00, 0x48, 0x8b, 0x43, 0x18, 0x48, 0x89
b * (0x74544cac + 42)
info b
disassemble /r 0x74544cac, 0x74544cac + 62



benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/gqrx
Reading symbols from /usr/bin/gqrx...
Reading symbols from 
/usr/lib/debug/.build-id/99/990c9578178123477597a27d771c5793452e95.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x9b8a0: file ./src/applications/gqrx/main.cpp, line 
49.
(gdb) run
Starting program: /usr/bin/gqrx 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffeea006c0 (LWP 18355)]
[New Thread 0x7fffee0006c0 (LWP 18356)]
[New Thread 0x7fffed6006c0 (LWP 18357)]
[New Thread 0x7fffecc006c0 (LWP 18358)]
[New Thread 0x7fffec2006c0 (LWP 18359)]
[New Thread 0x7fffeb8006c0 (LWP 18360)]
[New Thread 0x7fffeae006c0 (LWP 18361)]
[New Thread 0x7fffea4006c0 (LWP 18362)]
[New Thread 0x7fffe9a006c0 (LWP 18363)]
[New Thread 0x7fffe90006c0 (LWP 18364)]

Thread 1 "gqrx" hit Temporary breakpoint 1, main (argc=1, argv=0x7fffe488) 
at ./src/applications/gqrx/main.cpp:49
49  ./src/applications/gqrx/main.cpp: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep -E "\.text.*libuhd"
0x743274a0 - 0x74d7ee0a is .text in 
/lib/x86_64-linux-gnu/libuhd.so.4.6.0
(gdb) fin

Bug#1059874: libuhd4.6.0: Segfault in gqrx related to libuhd 4.6.0

[Bernhard Übelacker]

Hello,
I am not the maintainer of libuhd, just tried to get some more
information from the provided dmesg Code lines.

These end in some boost::asio functions:
  boost::asio::detail::scheduler::concurrency_hint() const at 
/usr/include/boost/asio/detail/scheduler.hpp:142

Unfortunately this allows no guess to where exactly this is called in libuhd.


When I start qgrx inside a minimal VM I could not see a crash,
but guess this needs some special hardware?


If this is still an issue please provide
- the exact steps until you receive a crash.
- maybe the output which gets written when starting qgrx from a terminal
- install systemd-coredump. This should produce in the journal some more 
information.

A lot more information about how to retrieve a backtrace could be found here:
  https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#1060293: gnome-nettool: Aborts with assert failure: *** stack smashing detected ***

[Bernhard Übelacker]

Hello,
I am not maintainer of gnome-nettool, just tried to debug this issue.

gnome-nettool collects the information from an execution
of a dig command [1] and parses the output.
Unfortunately the parsing is done into some fixed size arrays
and the dig output overflows those.
E.g. the destination buffer is 128 bytes,
but 419 bytes from the line get written to it.

This parsing is done here [2] with the format string from here [3].

The stack canary is overwritten with this backtrace [4].

Kind regards,
Bernhard


[1] dig +nocomments +search +nocmd +nostats +noadditional codethink.co.uk ANY

[2] https://sources.debian.org/src/gnome-nettool/42.0-1/src/lookup.c/#L260

[3] https://sources.debian.org/src/gnome-nettool/42.0-1/src/lookup.h/#L25

[4]
  (rr) bt
  #0  0x7f28a2aa5735 in __vfscanf_internal (s=s@entry=0x7fff90ce11c0, 
format=format@entry=0x5572c3ef6a71 "%s %d %s %s %[^\n]", 
argptr=argptr@entry=0x7fff90ce11a8, mode_flags=mode_flags@entry=2) at 
./stdio-common/vfscanf-internal.c:2896
  #1  0x7f28a2a9791d in __GI___isoc99_sscanf (s=0x5572c5b75e70 
"codethink.co.uk.\t20762\tIN\tRRSIG\tSOA 10 3 86400 20240531041601 20240501031601 19848 
codethink.co.uk. m9sD9b/i+u7lOqOp/I/DSSxR8XoF8nA4bjCkHKdx3w8RdvFUGjOwsH77 
5t2+sFagf7qZ2YLcABs+mDpOe3UFzrGcMbNGRkXGYcW"..., format=format@entry=0x5572c3ef6a71 "%s 
%d %s %s %[^\n]") at ./stdio-common/isoc99_sscanf.c:31
  #2  0x5572c3ef1f1d in strip_line (data=0x7fff90ce1400, line=) at ../src/lookup.c:260
  #3  lookup_foreach_with_tree (netinfo=, line=, 
len=, user_data=) at ../src/lookup.c:189
  #4  0x5572c3eeb7f2 in netinfo_io_text_buffer_dialog (channel=, 
condition=, data=0x5572c59204a0) at ../src/nettool.c:409
  #5  0x7f28a2c7e0d9 in g_main_dispatch 
(context=context@entry=0x5572c552dbd0) at ../../../glib/gmain.c:3476
  #6  0x7f28a2c81317 in g_main_context_dispatch_unlocked 
(context=0x5572c552dbd0) at ../../../glib/gmain.c:4284
  #7  g_main_context_iterate_unlocked (context=0x5572c552dbd0, block=block@entry=1, 
dispatch=dispatch@entry=1, self=) at ../../../glib/gmain.c:4349
  #8  0x7f28a2c81c1f in g_main_loop_run (loop=loop@entry=0x5572c568a510) at 
../../../glib/gmain.c:4551
  #9  0x7f28a33fd65d in gtk_main () at ../../../gtk/gtkmain.c:1329
  #10 0x5572c3ee95ba in main (argc=, argv=) 
at ../src/main.c:231
# 2024-05-01 trixie/testing amd64 qemu VM

apt install systemd-coredump task-gnome-desktop mc tmux htop git gdb valgrind 
rr gnome-nettool gnome-nettool-dbgsym libglib2.0-0t64-dbgsym 
libgtk-3-0t64-dbgsym
apt build-dep gnome-nettool
apt build-dep rr


mkdir /home/benutzer/source/gnome-nettool/orig -p
cd/home/benutzer/source/gnome-nettool/orig
apt source gnome-nettool


mkdir /home/benutzer/source/net-tools/orig -p
cd/home/benutzer/source/net-tools/orig
apt source net-tools





root@debian:~# journalctl -e
Mai 01 17:56:52 debian gnome-nettool.desktop[4366]: *** stack smashing detected 
***: terminated
Mai 01 17:56:52 debian systemd[1]: Created slice 
system-systemd\x2dcoredump.slice - Slice /system/systemd-coredump.
Mai 01 17:56:52 debian systemd[1]: Started systemd-coredump@0-4400-0.service - 
Process Core Dump (PID 4400/UID 0).
Mai 01 17:56:52 debian systemd-coredump[4401]: [] Process 4366 (gnome-nettool) 
of user 1000 dumped core.



root@debian:~# coredumpctl list
TIME  PID  UID  GID SIG COREFILE EXE
SIZE
Wed 2024-05-01 17:56:52 CEST 4366 1000 1000 SIGABRT present  
/usr/bin/gnome-nettool 1.8M



root@debian:~# coredumpctl gdb --debugger-arguments=-q 4366
   PID: 4366 (gnome-nettool)
   UID: 1000 (benutzer)
   GID: 1000 (benutzer)
Signal: 6 (ABRT)
 Timestamp: Wed 2024-05-01 17:56:52 CEST (4min 14s ago)
  Command Line: /usr/bin/gnome-nettool
Executable: /usr/bin/gnome-nettool
 Control Group: 
/user.slice/user-1000.slice/user@1000.service/app.slice/app-gnome-gnome\x2dnettool-4366.scope
  Unit: user@1000.service
 User Unit: app-gnome-gnome\x2dnettool-4366.scope
 Slice: user-1000.slice
 Owner UID: 1000 (benutzer)
   Boot ID: 7408197c36284bc295b6d821669a3071
Machine ID: 16e4d7437c19482b8c85581d3feaba09
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.gnome-nettool.1000.7408197c36284bc295b6d821669a3071.4366.171457901200.zst
 (present)
  Size on Disk: 1.8M
   Message: Process 4366 (gnome-nettool) of user 1000 dumped core.

Module libzstd.so.1 from deb libzstd-1.5.5+dfsg2-2.amd64
Module libsystemd.so.0 from deb systemd-255.4-1.amd64
Stack trace of thread 4366:
#0  0x7fdb1d71a16c n/a (libc.so.6 + 0x8a16c)
#1  0x7fdb1d6cc472 raise (libc.so.6 + 0x3c472)
#2  0x7fdb1d6b64b2 abort (libc.so.6 + 0x264b2)
#3  0x7fdb1d6b71ed n/a (libc.so.6 + 0x271ed)
#4  0x7fdb1d7a8465 __fortify_fail (libc.so.6 

Bug#1060224: bluetoothd started segfaulting

[Bernhard Übelacker]

Hello,
I am just trying to get the source line from the dmesg code line.



[   97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 
7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 
(core 5, socket 0)
[   97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 
f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 
8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08



And it points to function a2dp_suspend_complete, [transport.c:431].

This function leads to upstream report [701],
which should be fixed since release 5.72 [83cfad1].

Kind regards,
Bernhard

[transport.c:431] 
https://sources.debian.org/src/bluez/5.71-1/profiles/audio/transport.c/#L431
[701] https://github.com/bluez/bluez/issues/701
[83cfad1] 
https://github.com/bluez/bluez/commit/83cfad1badee6aae77eb15177ccc917249ab9bb3
[   97.073761] bluetoothd[838]: segfault at 561314652a23 ip 56167406a375 sp 
7fffb128a200 error 4 in bluetoothd[561674048000+ec000] likely on CPU 11 
(core 5, socket 0)
[   97.073799] Code: 00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 
66 90 f3 0f 1e fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 
20 4c 8b ad 88 00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08

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
.






# 2024-05-01 trixie/testing amd64 qemu VM

apt dist-upgrade
apt install gdb bluez bluez-dbgsym
apt build-dep bluez


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



echo -n "find /b ..., ..., 0x" && \
echo "00 31 c0 e9 54 ff ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e 
fa 41 55 41 54 55 53 48 83 ec 08 48 8b 2a 48 8b 7a 08 <48> 8b 45 20 4c 8b ad 88 
00 00 00 4c 8b 20 48 85 ff 74 19 c7 47 08" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

gdb -q
set width 0
set pagination off
file /usr/sbin/bluetoothd
tb main
run
pipe info target | grep -E "\.text$"

find /b 0x555798f0, 0x55663b30, 0x00, 0x31, 0xc0, 0xe9, 0x54, 
0xff, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x66, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 0x41, 0x55, 0x41, 0x54, 0x55, 0x53, 
0x48, 0x83, 0xec, 0x08, 0x48, 0x8b, 0x2a, 0x48, 0x8b, 0x7a, 0x08, 0x48, 0x8b, 
0x45, 0x20, 0x4c, 0x8b, 0xad, 0x88, 0x00, 0x00, 0x00, 0x4c, 0x8b, 0x20, 0x48, 
0x85, 0xff, 0x74, 0x19, 0xc7, 0x47, 0x08
b * (0x5559a34b + 42)
info b
disassemble /r 0x5559a34b, 0x5559a34b + 62
directory /home/benutzer/source/bluez/orig/bluez-5.71




benutzer@debian:~$ gdb -q
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/bluetoothd
Reading symbols from /usr/sbin/bluetoothd...
Reading symbols from 
/usr/lib/debug/.build-id/b3/ec9634ecf4f0995fa44119b844150cc8d98db5.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x25bd0: file src/main.c, line 1355.
(gdb) run
Starting program: /usr/sbin/bluetoothd 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe478) at src/main.c:1355
1355src/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep -E "\.text$"
0x555798f0 - 0x55663b30 is .text
(gdb) find /b 0x555798f0, 0x55663b30, 0x00, 0x31, 0xc0, 0xe9, 
0x54, 0xff, 0xff, 0xff, 0x66, 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 
0x00, 0x00, 0x66, 0x90, 0xf3, 0x0f, 0x1e, 0xfa, 0x41, 0x55, 0x41, 0x54, 0x55, 
0x53, 0x48, 0x83, 0xec, 0x08, 0x48, 0x8b, 0x2a, 0x48, 0x8b, 0x7a, 0x08, 0x48, 
0x8b, 0x45, 0x20, 0x4c, 0x8b, 0xad, 0x88, 0x00, 0x00, 0x00, 0x4c, 0x8b, 0x20, 
0x48, 0x85, 0xff, 0x74, 0x19, 0xc7, 0x47, 0x08
0x5559a34b 
1 pattern found.
(gdb) b * (0x5559a34b + 42)
Breakpoint 2 at 0x5559a375: file profiles/audio/transport.c, line 431.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x5559a375 in a2dp_suspend_complete at 
profiles/audio/transport.c:431
(gdb) disassemble /r 0x5559a34b, 0x5559a34b + 62
Dump of assembler code from 0x5559a34b to 0x5559a389:
...
   0x5559a360 :f3 0f 1e fa 
endbr64
   0x5559a364 :41 55   
push   %r13
   0x5559a366 :41 54   
push   %r12
   0x5559a368 :55  
push   %rbp
   0x5559a369 :53  
push   %rbx
   0x5559a36a :   48 83 ec 08 
sub$0x8,%rsp
   0x5559a36e :   48 8b 2a
mov(%rdx),%rbp
   0x5559a371 :   48 8b 7a 08 
mov0x8(%rdx),%rdi
   0x5559a375 :   48 8b 45 20 
mo

Bug#1062205: Crashes desktop when attempting to make a network display

[Bernhard Übelacker]

On Fri, 2 Feb 2024 00:58:31 -0800 Josh Triplett  wrote:


Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 
sp 7ffc5ad85ed8 error 4 in 
libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, 
socket 0)
Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 d2 7e 
05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 
47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f



Hello,
I am not involved in maintaining this package, just looking through some crash 
reports.

My attempt to resolve the dmesg lines from the crash to a source line 
information led me here:

  clutter_paint_context_get_redraw_clip at 
../clutter/clutter/clutter-paint-context.c:140

  
https://sources.debian.org/src/mutter/44.8-3.1/clutter/clutter/clutter-paint-context.c/#L140
  137 const cairo_region_t *
  138 clutter_paint_context_get_redraw_clip (ClutterPaintContext 
*paint_context)
  139 {
  140   return paint_context->redraw_clip;
  141 }

This function name leads to following bug report, which sounds interesting:
  https://gitlab.gnome.org/GNOME/mutter/-/issues/2876

And which got fixed by this merge request:
  https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/3283

First upstream release containing this fix would be 45.1,
unfortunately not yet in unstable or testing.


But a proper backtrace might still help to confirm, if this crash is
really the same which is described in the mentioned mutter bug report.
  https://wiki.debian.org/HowToGetABacktrace
Simplest version could be to install systemd-coredump
and inspecting the journal after a crash.

Kind regards,
Bernhard
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1062205
https://wiki.debian.org/HowToGetABacktrace
https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


Feb 02 00:28:37 o kernel: gnome-shell[1083]: segfault at 20 ip 7fececdf8f04 
sp 7ffc5ad85ed8 error 4 in 
libmutter-clutter-12.so.0.0.0[7fececda5000+9] likely on CPU 3 (core 4, 
socket 0)
Feb 02 00:28:37 o kernel: Code: c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 
d2 7e 05 00 48 8d 3d 4e f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa 
<48> 8b 47 20 c3 0f 1f 80 00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f


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





# 2024-04-28 Trixie/testing amd64 qemu VM

apt update
apt dist-upgrade
apt build-dep libmutter-12-0

apt install systemd-coredump gdb libmutter-12-0 libmutter-12-0-dbgsym 
coreutils-dbgsym



mkdir /home/benutzer/source/libmutter-12-0/orig -p
cd/home/benutzer/source/libmutter-12-0/orig
apt source libmutter-12-0



echo -n "find /b ..., ..., 0x" && \
echo "c3 0f 1f 44 00 00 48 8d 15 e1 1a 04 00 48 8d 35 d2 7e 05 00 48 8d 3d 4e 
f4 03 00 e9 d6 f2 fa ff 66 0f 1f 44 00 00 f3 0f 1e fa <48> 8b 47 20 c3 0f 1f 80 
00 00 00 00 f3 0f 1e fa 48 8b 47 28 c3 0f" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'



gdb -q 
set width 0
set pagination off
file /usr/bin/true
tb main
run
call 
dlopen("/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0",0x102)
pipe info target | grep "\.text.*libmutter-clutter"
find /b 0x77cf0f30, 0x77d7a6de, 0xc3, 0x0f, 0x1f, 0x44, 0x00, 
0x00, 0x48, 0x8d, 0x15, 0xe1, 0x1a, 0x04, 0x00, 0x48, 0x8d, 0x35, 0xd2, 0x7e, 
0x05, 0x00, 0x48, 0x8d, 0x3d, 0x4e, 0xf4, 0x03, 0x00, 0xe9, 0xd6, 0xf2, 0xfa, 
0xff, 0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00, 0xf3, 0x0f, 0x1e, 0xfa, 0x48, 0x8b, 
0x47, 0x20, 0xc3, 0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00, 0xf3, 0x0f, 0x1e, 
0xfa, 0x48, 0x8b, 0x47, 0x28, 0xc3, 0x0f
b * (0x77d3eeda + 42)
info b
disassemble /r 0x77d3eeda, 0x77d3eeda + 62
directory /home/benutzer/source/libmutter-12-0/orig/mutter-44.8/clutter



benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/true
Reading symbols from /usr/bin/true...
Reading symbols from 
/usr/lib/debug/.build-id/04/6669aefa60ba9f99cc1c829bf6aac6e0d05d4c.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x2310: file src/true.c, line 56.
(gdb) run
Starting program: /usr/bin/true 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe488) at src/true.c:56
56  src/true.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call 
dlopen("/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0",0x102)
$1 = (void *) 0xe340
(gdb) pipe info target | grep "\.text.*libmutter-clutter"
0x77cf0f30 - 0x77d7a6de is .text in 
/usr/lib/x86_64-linux-gnu/mutter-12/libmutter-clutter-12.so.0.0.0
(gdb) find /b 0x77cf0f30, 0x77d7a6de, 0xc3, 0x0f, 0x1f, 0x44, 
0x00, 0x00, 0x48, 0x8d, 0x15, 0xe1, 0x1a, 0x04, 0x

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, , _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, , _mask);
(gdb)

Bug#1068680: din: Process 166294 (din) of user 1000 dumped core

[Bernhard Übelacker]

Hello Cláudio,
I am not maintainer of the din package, just reading through some crash reports.

Unfortunately I cannot follow your claim "The crash occurred in the module 
libzstd.so.1".
None of the 5 threads show a frame inside libzstd.
It seems just listed in the Module list.

Thread 166294 shows all the last frames in the din executable,
all other visible threads may just be "waiting", therefore the epoll_wait frame.

I would suggest to install systemd-coredump and gdb if not happened yet.

If it was, following sequence of command should enable the debugger to load
debug information for involved executables and print out function names
with source file and line number information.

export DEBUGINFOD_URLS="https://debuginfod.debian.net;
coredumpctl gdb 166294
  y
  thread apply all bt full
  quit

This downloads several megabytes into $HOME/.cache/debuginfod_client.

And would show way more details for the maintainer to look at.


I tried to reconstruct the line information to your first thread,
which I suspect is the crashing one.


More information about debugging crashes can be found in this page:
https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard




Stack trace of thread 166294:
#0  0x5617dbae42ab n/a (din + 0xc02ab)in font::draw_char(char, int, 
int, int) at ./src/font.cc:203
#1  0x5617dbae4a75 n/a (din + 0xc0a75)in draw_string(std::__cxx11::basic_string, std::allocator > const&, int, int, int) at 
./src/font.cc:220
#2  0x5617dba8c2e4 n/a (din + 0x682e4)in options_list::draw() at 
./src/options_list.h:93
#3  0x5617dbb73b55 n/a (din + 0x14fb55)   in settings::draw() at 
./src/settings.cc:281
#4  0x5617dbb8aab0 n/a (din + 0x166ab0)   in ui_list::draw() at 
./src/ui.cc:151
#5  0x5617dba5a15b main (din + 0x3615b)   in main(int, char**) at 
./src/main.cc:1606

https://sources.debian.org/src/din/56-1/src/font.cc/#L203

Bug#1064347: openssh-server: sshd crashes under heavy traffic

[Bernhard Übelacker]

Hello,
I am no maintainer, just tried to reproduce this issue which I could
inside a minimal Bullseye amd64 qemu VM with the instructions
from the linked Ubuntu bug.

I could not reproduce it within Bookworm or Trixie/testing.

Without "LogLevel DEBUG" it was also not observable.

Unfortunately did also not happen with a ssh package built with asan enabled.

And I upgraded step by step via snapshot.d.o, around 2021-11-15 it
stopped to be an issue. This step brought openssh 8.7p1-1.
Downgrading just openssh 8.4p1-6 in this exact VM showed it again.

Therefore I assume this issue got fixed between openssh 8.4p1-6 and 8.7p1-1.

Kind regards,
Bernhard


#13 
#14 malloc_consolidate (av=av@entry=0x7faa3b64cb80 ) at 
malloc.c:4518
#15 0x7faa3b5023d5 in _int_malloc (av=av@entry=0x7faa3b64cb80 , 
bytes=bytes@entry=8193) at malloc.c:3699
#16 0x7faa3b503063 in malloc_check (sz=8192, caller=) at 
hooks.c:239
#17 0x7faa3b504cea in __libc_calloc (n=n@entry=1, 
elem_size=elem_size@entry=8192) at malloc.c:3387
#18 0x7faa3b4f6ef4 in __GI___open_memstream 
(bufloc=bufloc@entry=0x7ffe636eb6e0, sizeloc=sizeloc@entry=0x7ffe636eb6e8) at 
memstream.c:83
#19 0x7faa3b5726e1 in __vsyslog_internal (pri=39, fmt=0x55b451dcb150 
"%.500s", ap=0x7ffe636eb7d0, mode_flags=2) at ../misc/syslog.c:181
#20 0x7faa3b572d5f in __syslog_chk (pri=pri@entry=7, flag=flag@entry=1, 
fmt=fmt@entry=0x55b451dcb150 "%.500s") at ../misc/syslog.c:136
#21 0x55b451d87e16 in syslog (__fmt=0x55b451dcb150 "%.500s", __pri=7) at 
/usr/include/x86_64-linux-gnu/bits/syslog.h:31
#22 do_log (level=level@entry=SYSLOG_LEVEL_DEBUG1, fmt=fmt@entry=0x55b451dba421 
"Forked child %ld.", args=args@entry=0x7ffe636ec110) at ../../log.c:484
#23 0x55b451d88254 in debug (fmt=fmt@entry=0x55b451dba421 "Forked child 
%ld.") at ../../log.c:229
#24 0x55b451d3c86e in server_accept_loop (config_s=0x7ffe636ec270, newsock=, sock_out=, sock_in=) at 
../../sshd.c:1377
#25 main (ac=, av=) at ../../sshd.c:2089
# 2024-04-23 Bullseye/stable amd64 qemu VM


apt update
apt dist-upgrade
apt install systemd-coredump moreutils parallel htop fakeroot mc ccache gdb 
openssh-server-dbgsym
apt build-dep glibc
apt build-dep openssh-server


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

mkdir /home/benutzer/source/openssh-server/orig -p
cd/home/benutzer/source/openssh-server/orig
apt source openssh-server



sed -i.bak 's/#LogLevel INFO/LogLevel DEBUG/g' /etc/ssh/sshd_config
systemctl restart sshd



ssh-keygen -b 4096
ssh-copy-id -i .ssh/id_rsa.pub benutzer@localhost
parallel -j 32 -N0 "ssh benutzer@localhost 'true'" ::: {1..2}







benutzer@debian:~/.ssh$ ssh-keygen -b 4096
Generating public/private rsa key pair.
Enter file in which to save the key (/home/benutzer/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/benutzer/.ssh/id_rsa
Your public key has been saved in /home/benutzer/.ssh/id_rsa.pub
The key fingerprint is:
SHA256:Hgx6dUtFBhKiI0wBYKtXMkwZeRcP/eEZCUsU69bbO+o benutzer@debian
The key's randomart image is:
+---[RSA 4096]+
|+o==  ++B+.++|
|.=+ ...=.++o |
| .*.+.. =oo+ |
|.  = o = ++. |
|. . . . S o  |
| .   . o . o |
|. . .|
|..   |
| .E...   |
+[SHA256]-+


benutzer@debian:~$ ssh-copy-id -i .ssh/id_rsa.pub benutzer@localhost
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: ".ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter 
out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are 
prompted now it is to install the new keys
benutzer@localhost's password: 

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'benutzer@localhost'"
and check to make sure that only the key(s) you wanted were added.





parallel -j 800 -N0 "ssh benutzer@localhost 'mount; sleep 1; cat /proc/cpuinfo; 
free -h; dd if=/dev/zero of=/dev/null bs=1 count=8192; mount -av; sleep 
$(($RANDOM % 5)); lscpu'" ::: {1..1}
# AMD Ryzen 1700, VM, 16 threads















root@debian:~# coredumpctl list
TIMEPID   UID   GID SIG COREFILE  EXE
Tue 2024-04-23 00:20:53 CEST 124297 0 0   6 present   /usr/sbin/sshd
Tue 2024-04-23 00:23:02 CEST 159284 0 0   6 present   /usr/sbin/sshd
Tue 2024-04-23 00:23:47 CEST 229261 0 0  11 present   /usr/sbin/sshd
Tue 2024-04-23 00:24:32 CEST 277265 0 0  11 present   /usr/sbin/sshd
Tue 2024-04-23 00:24:54 CEST 301567 0 0   6 present   /usr/sbin/sshd





root@debian:~# coredumpctl gdb 301567
   PID: 301567 (sshd)
   UID: 0 (root)
   GID: 0 (root)
Signal: 6 (ABRT)
 Timestamp: Tue 2024-04-23 00:24:53 CEST (47s ago)
  

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 00 00   js 
0x55c1fbd15f26 
   0

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#1067907: flam3-utils: flam3-genome randomly segfaults on ppc64el

[Bernhard Übelacker]

Hello,
tried to reproduce the issue and got on a first run this stack:

(gdb) bt
#0  iter_thread_int (fth=0x157681210) at rect.c:500
#1  0x7fffaa36bad0 in iter_thread_float () at rect.c:253
#2  0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at 
pthread_create.c:444
#3  0x7fffa9d3e364 in .LY__clone () at 
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107
(gdb)

More details in attached file.

Kind regards,
Bernhardhttps://people.debian.org/~gio/dqib/
https://gitlab.com/giomasce/dqib/-/jobs/6565595570/artifacts/download?file_type=archive


echo "set enable-bracketed-paste off" >> /etc/inputrc
echo "deb-src http://deb.debian.org/debian/ unstable main" >> 
/etc/apt/sources.list
apt update
apt install systemd-coredump flam3-utils htop gdb libflam3-0-dbgsym 
flam3-utils-dbgsym
apt build-dep flam3


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


benutzer@debian:~$ env seed=$RANDOM issac_seed=$RANDOM flam3-genome > /dev/null
Segmentation fault (core dumped)
benutzer@debian:~$ 


benutzer@debian:~$ coredumpctl list -q
TIMEPID  UID  GID SIG COREFILE EXE  
 SIZE
Sat 2024-04-13 08:59:01 UTC 819 1001 1001 SIGSEGV present  
/usr/bin/flam3-genome 1.8M


export DEBUGINFOD_URLS="https://debuginfod.debian.net;
echo "set debuginfod enabled on" >> .gdbinit
cd /home/benutzer/source/flam3/orig/flam3-3.1.1+ds2

benutzer@debian:~$ coredumpctl gdb --debugger-arguments=-q 819 
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: 819 (flam3-genome)
   UID: 1001 (benutzer)
   GID: 1001 (benutzer)
Signal: 11 (SEGV)
 Timestamp: Sat 2024-04-13 08:58:58 UTC (8min ago)
  Command Line: flam3-genome
Executable: /usr/bin/flam3-genome
 Control Group: /system.slice/ssh.service
  Unit: ssh.service
 Slice: system.slice
   Boot ID: 264b6d6ac02b49fcbf29cf0bda4825ba
Machine ID: 9d83830458974e43a3f2f91f73a6969d
  Hostname: debian
   Storage: 
/var/lib/systemd/coredump/core.flam3-genome.1001.264b6d6ac02b49fcbf29cf0bda4825ba.819.171299873800.zst
 (present)
  Size on Disk: 1.8M
   Message: Process 819 (flam3-genome) of user 1001 dumped core.

Stack trace of thread 1051:
#0  0x7fffaa36b444 n/a (libflam3.so.0 + 0x2b444)
#1  0x7fffaa36bad0 n/a (libflam3.so.0 + 0x2bad0)
#2  0x7fffa9c9b010 n/a (libc.so.6 + 0x9b010)
#3  0x7fffa9d3e364 __clone (libc.so.6 + 0x13e364)
ELF object binary architecture: PowerPC64

Reading symbols from /usr/bin/flam3-genome...
(No debugging symbols found in /usr/bin/flam3-genome)   

 
[New LWP 1051]
[New LWP 819]
[Thread debugging using libthread_db enabled]   

 
Using host libthread_db library "/lib/powerpc64-linux-gnu/libthread_db.so.1".
Core was generated by `flam3-genome '.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fffaa36b444 in ?? () from /lib/powerpc64-linux-gnu/libflam3.so.0
[Current thread is 1 (Thread 0x7fffa740f100 (LWP 1051))]
(gdb) bt
#0  0x7fffaa36b444 in ?? () from /lib/powerpc64-linux-gnu/libflam3.so.0
#1  0x7fffaa36bad0 in ?? () from /lib/powerpc64-linux-gnu/libflam3.so.0
#2  0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at 
pthread_create.c:444
#3  0x7fffa9d3e364 in .LY__clone () at 
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107
(gdb) 

(gdb) noshare
(gdb) share
...
(gdb) bt
#0  iter_thread_int (fth=0x157681210) at rect.c:500
#1  0x7fffaa36bad0 in iter_thread_float () at rect.c:253
#2  0x7fffa9c9b010 in start_thread (arg=0x7fffa740f100) at 
pthread_create.c:444
#3  0x7fffa9d3e364 in .LY__clone () at 
../sysdeps/unix/sysv/linux/powerpc/powerpc64/clone.S:107
(gdb) 

(gdb) directory /home/benutzer/source/flam3/orig/flam3-3.1.1+ds2
Source directories searched: 
/home/benutzer/source/flam3/orig/flam3-3.1.1+ds2:$cdir:$cwd

(gdb) list iter_thread_int
248  pthread_exit((void *)0);
249#endif
250
251 }
252
253 static void iter_thread(void *fth) {
254double sub_batch;
255int j;
256flam3_thread_helper *fthp = (flam3_thread_helper *)fth;
257flam3_iter_constants *ficp = fthp->fic;
258struct timespec pauset;
259int SBS = ficp->spec->sub_batch_size;
260int fuse;
261int cmap_size = ficp->cmap_size;
262int cmap_size_m1 = ficp->cmap_size-1;
263
264double eta = 0.0;

Bug#1067639: sasl2-bin: terminates with smashed stack and kills qemu-user?!

[Bernhard Übelacker]

Hello,
I tried to find some more information, with the help of a prebuilt full-system 
VM image.


On Thu, 4 Apr 2024 21:00:59 + (UTC) Thorsten Glaser  wrote:

Sometimes, it does not crash with a smashed stack but instead:

Setting up sasl2-bin (2.1.28+dfsg1-6+b1) ...
BDB0002 __fop_file_setup:  Retry limit (100) exceeded
saslpasswd2: generic failure


This looks to be a result of the pre-existing /etc/__db.sasldb2.
If this file gets removed the stack smashing occurs again.

By some experimenting I could convince gdb to load the debug symbols.
And the stack seems to point into function __os_unique_id from libdb-5.3.so.

Unfortunately I am not sure where the canary gets overwritten.

Kind regards,
Bernhard





https://people.debian.org/~gio/dqib/
https://gitlab.com/giomasce/dqib/-/artifacts
https://gitlab.com/giomasce/dqib/-/jobs/6565595565/artifacts/download?file_type=archive


apt install gdb sasl2-bin sasl2-bin-dbgsym libsasl2-2-dbgsym 
libsasl2-modules-db-dbgsym
apt install libc6-dbg libc6-dbgsym db-util db5.3-util libldap-2.5-0 
libldap-common libsasl2-2 libsasl2-2-dbgsym libsasl2-modules libsasl2-modules-db


export DEBUGINFOD_URLS="https://debuginfod.debian.net;

rm /etc/__db.sasldb2
echo -e "test\ntest" > exclam

gdb -q
file /usr/sbin/saslpasswd2
run -c 'no:such:user' https://debuginfod.debian.net>
Enable debuginfod for this session? (y or [n]) y
Debuginfod has been enabled.
To make this setting permanent, add 'set debuginfod enabled on' to .gdbinit.
Downloading separate debug info for /usr/sbin/saslpasswd2
(No debugging symbols found in /usr/sbin/saslpasswd2)
(gdb) run -c 'no:such:user' , fname=0xc0605cb9 
"/etc/sasldb2", dname=0x0, type=DB_HASH, flags=1, mode=432) at 
../src/db/db_iface.c:1193
#13 0xc0604248 in ?? ()
#14 0xd00087b0 in ?? ()
#15 0x in ?? ()
(gdb) shell objdump --all-headers 
/usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25 | grep .text
 11 .text 27f0  138c  138c  138c  2**2
(gdb) print/x 0x138c + 0xc0602000
$4 = 0xc060338c

(gdb) add-symbol-file /usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25 
0xc060338c
add symbol table from file "/usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25" 
at
.text_addr = 0xc060338c
(y or n) y
Reading symbols from /usr/lib/m68k-linux-gnu/sasl2/libsasldb.so.2.0.25...
Reading symbols from 
/usr/lib/debug/.build-id/29/c8e688eb61b57bcd21794b5403feefe1272dfd.debug...
(gdb) bt
...
#15 0xc0603572 in sasldb_auxprop_store (glob_context=0x0, sparams=0xd00077b8, 
ctx=0xd0007a58, user=0xeed9 "no:such:user", ulen=12) at 
../../plugins/sasldb.c:258
#16 0xc002d26c in ?? ()
#17 0x in ?? ()
(gdb) shell cat /proc/10276/maps | grep -i -E "^c00"
c000-c002 r-xp  08:01 535730 /usr/lib/m68k-linux-gnu/ld.so.1
c002-c0021000 rw-p  00:00 0
c0021000-c0022000 r--p 00021000 08:01 535730 /usr/lib/m68k-linux-gnu/ld.so.1
c0022000-c0024000 rw-p 00022000 08:01 535730 /usr/lib/m68k-linux-gnu/ld.so.1
c0028000-c003c000 r-xp  08:01 539155 
/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25
c003c000-c003d000 ---p 00014000 08:01 539155 
/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25
c003d000-c003e000 r--p 00015000 08:01 539155 
/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25
c003e000-c003f000 rw-p 00016000 08:01 539155 
/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25
c004-c01b1000 r-xp  08:01 535733 
/usr/lib/m68k-linux-gnu/libc.so.6
(gdb) shell objdump --all-headers /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 | 
grep .text
 12 .text e284  3db0  3db0  3db0  2**2
(gdb) print/x 0x3db0 + 0xc0028000
$5 = 0xc002bdb0
(gdb) add-symbol-file /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25 0xc002bdb0
add symbol table from file "/usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25" at
.text_addr = 0xc002bdb0
(y or n) y
Reading symbols from /usr/lib/m68k-linux-gnu/libsasl2.so.2.0.25...
Reading symbols from 
/usr/lib/debug/.build-id/0f/8954c0644d1a9efec7973fb3198b8fd7649d5f.debug...
(gdb) set width 0
(gdb) set pagination off
(gdb) bt
...
#17 0xc00366dc in sasl_setpass (conn=0xd0006670, user=0xeed9 "no:such:user", 
pass=0xd0006608 "test\ntest", passlen=9, oldpass=0x0, oldpasslen=0, flags=1) at 
../../lib/server.c:186
#18 0xd0001534 in ?? ()
...
(gdb) shell cat /proc/10276/maps | grep -i -E "^d00"
d000-d0002000 r-xp  08:01 539212 /usr/sbin/saslpasswd2
d0003000-d0004000 r--p 3000 08:01 539212 /usr/sbin/saslpasswd2
d0004000-d0005000 rw-p 4000 08:01 539212 /usr/sbin/saslpasswd2
d0005000-d0026000 rwxp  00:00 0  [heap]
(gdb) shell objdump --all-headers /usr/sbin/saslpasswd2 | grep .text
 13 .text 0950  10b8  10b8  10b8  2**2
(gdb) print/x 0x10b8 + 0xd000
$6 = 0xd00010b8

(gdb) add-symbol-file /usr/sbin/saslpasswd2 0xd00010b8
add symbol table from file "/usr/sbin/saslpasswd2" at

Bug#1056555: thunar: segfault when ejecting drive

[Bernhard Übelacker]

Hello ng,


On Wed, 22 Nov 2023 22:47:01 -0300 ng  wrote:


[18950.426861] Thunar[3027]: segfault at 0 ip 5615a96c98cc sp 
7ffd2dbd7320 error 4 in thunar[5615a964+92000] likely on CPU 7 (core 3, 
socket 0)
[18950.426895] Code: f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 
48 c7 44 24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 0f 84 
f1 01 00 00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb


This lines point to following source location:

thunar/thunar-window.c, line 4000

https://sources.debian.org/src/thunar/4.18.4-1/thunar/thunar-window.c/#L4000
3999   /* if the view already has the correct type then just return */
4000   if (view != NULL && G_TYPE_FROM_INSTANCE (view) == view_type)
4001 return;


Unfortunately this might yet not be enough for the maintainer to fix the issue.

Following link contains a few pointers how to get a backtrace of a crash:
https://wiki.debian.org/HowToGetABacktrace


Kind regards,
Bernhard


https://wiki.debian.org/InterpretingKernelOutputAtProcessCrash


[18950.426861] Thunar[3027]: segfault at 0 ip 5615a96c98cc sp 
7ffd2dbd7320 error 4 in thunar[5615a964+92000] likely on CPU 7 (core 3, 
socket 0)
[18950.426895] Code: f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 
31 c0 48 c7 44 24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 
0f 84 f1 01 00 00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb

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 "f3 48 83 ec 38 64 48 8b 04 25 28 00 00 00 48 89 44 24 28 31 c0 48 c7 44 
24 20 00 00 00 00 48 85 f6 0f 84 77 02 00 00 48 8b 06 <48> 39 10 0f 84 f1 01 00 
00 4c 8b bf 28 01 00 00 4c 39 fe 0f 84 cb" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'





# Bookworm/stable amd64 qemu VM 2024-04-09

apt update
apt install gdb thunar thunar-dbgsym

gdb -q 
set width 0
set pagination off
file /usr/bin/thunar
tb main
run 
pipe info target | grep "\.text"
find /b 0x5557fdb0, 0x5560bad9, 0xf3, 0x48, 0x83, 0xec, 0x38, 
0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 0x24, 
0x28, 0x31, 0xc0, 0x48, 0xc7, 0x44, 0x24, 0x20, 0x00, 0x00, 0x00, 0x00, 0x48, 
0x85, 0xf6, 0x0f, 0x84, 0x77, 0x02, 0x00, 0x00, 0x48, 0x8b, 0x06, 0x48, 0x39, 
0x10, 0x0f, 0x84, 0xf1, 0x01, 0x00, 0x00, 0x4c, 0x8b, 0xbf, 0x28, 0x01, 0x00, 
0x00, 0x4c, 0x39, 0xfe, 0x0f, 0x84, 0xcb
b * (0x556038a2 + 42)
info b
disassemble /r 0x556038a2, 0x556038a2 + 62





benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/bin/thunar
Reading symbols from /usr/bin/thunar...
Reading symbols from 
/usr/lib/debug/.build-id/1c/0053bee14d3fb731923319e68ac183a810d9db.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x2bdd0: file ./thunar/main.c, line 49.
(gdb) run 
Starting program: /usr/bin/thunar 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe4d8) at ./thunar/main.c:49
49  ./thunar/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) pipe info target | grep "\.text"
0x5557fdb0 - 0x5560bad9 is .text
...
(gdb) find /b 0x5557fdb0, 0x5560bad9, 0xf3, 0x48, 0x83, 0xec, 
0x38, 0x64, 0x48, 0x8b, 0x04, 0x25, 0x28, 0x00, 0x00, 0x00, 0x48, 0x89, 0x44, 
0x24, 0x28, 0x31, 0xc0, 0x48, 0xc7, 0x44, 0x24, 0x20, 0x00, 0x00, 0x00, 0x00, 
0x48, 0x85, 0xf6, 0x0f, 0x84, 0x77, 0x02, 0x00, 0x00, 0x48, 0x8b, 0x06, 0x48, 
0x39, 0x10, 0x0f, 0x84, 0xf1, 0x01, 0x00, 0x00, 0x4c, 0x8b, 0xbf, 0x28, 0x01, 
0x00, 0x00, 0x4c, 0x39, 0xfe, 0x0f, 0x84, 0xcb
0x556038a2 
1 pattern found.
(gdb) b * (0x556038a2 + 42)
Breakpoint 2 at 0x556038cc: file ./thunar/thunar-window.c, line 4000.
(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x556038cc in 
thunar_window_replace_view at ./thunar/thunar-window.c:4000
(gdb) disassemble /r 0x556038a2, 0x556038a2 + 62
Dump of assembler code from 0x556038a2 to 0x556038e0:
   0x556038a2 :  f3 48 83 ec 38  
repz sub $0x38,%rsp
   0x556038a7 :  64 48 8b 04 25 28 00 00 
00  mov%fs:0x28,%rax
   0x556038b0 :  48 89 44 24 28  
mov%rax,0x28(%rsp)
   0x556038b5 :  31 c0   
xor%eax,%eax
   0x556038b7 :  48 c7 44 24 20 00 00 00 
00  movq   $0x0,0x20(%rsp)
   0x556038c0 :  48 85 f6
test   %rsi,%rsi
   0x556038c3 :  0f 84 77 02 00 00   
je 0x55603b40 
   0x556038c9 :  48 8b 06
mov(%rsi),%rax
   0x556038cc :  48 39 10
cmp%rdx,(%rax)<<<
   0x556038cf :  0f

Bug#1053433: mate-panel: mate-clock segfaults on return from hibernation

[Bernhard Übelacker]

Hello Olly,



(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7fa84248315f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7fa842435472 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7fa84241f4b2 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7fa84276d5dd in  ()
#5  0x in  ()

I read that as it's already aborting when it segfaults, so maybe that's
not helpful in knowing the root cause.  I'm happy to debug further if
someone tells me what to try.




This means the instruction just before 0x7fa84276d5dd
is most probably a call to function abort.
Usually this is done if some assertion fails.
Therefore there might something like "assertion failed" in the
logs at this time.

Unfortunately 0x7fa84276d5dd might be inside of a shared object.
And for it is no -dbgsym package installed.

To find out which shared object you might have a look into the
output of `info share`.

If you receive such a crash you could create a core dump with
gdb command `generate-core-file`.

Or install some core dump collector, e.g. systemd-coredump.
With this after a crash happened one can inspect it via
  coredumpctl list
  coredumpctl gdb

This link contains some more ways to debug
and to install the dbgsym packages:

https://wiki.debian.org/HowToGetABacktrace

Kind regards,
Bernhard

Bug#1052561: bookworm-pu: package nfdump/1.7.3-1 (pre-discussion)

[Bernhard Schmidt]

On 08/10/23 10:19 PM, Bernhard Schmidt wrote:

Hi,

> > On Sun, Sep 24, 2023 at 09:36:00PM +0200, Bernhard Schmidt wrote:
> > > [ Other info ]
> > > I did not attach the debdiff because it would be too large and only 
> > > consist
> > > of upstream changes. No changes to debian/ (except dropping a backported 
> > > fix
> > > already in 12.1) are necessary.
> > 
> > What does diffstat look like, possibly with translations and tests
> > excluded? Let's see what sort of scale we're talking here.
> 
> Plain debdiff
> 
>  185 files changed, 25810 insertions(+), 28068 deletions(-)

Gentle ping about this. I'm totally fine if you think this is too risky,
I would go for bookworm-backports then.

[...]

> I'll reach out to upstream about those embedded lz4 copy, right now it does
> not look like one could build against an external library, in contrast to
> zstd and bz2 support.

Upstream has released 1.7.4 which supports building against the system
lz4 copy. I don't want to upload this to unstable until it's clear how
to proceed with this bug. So

1.) Drop this request and keep the old version in bookworm, upload
1.7.3+ to bookworm-backports
2.) Upload 1.7.3 to one of the next bookworm point releases
3.) Upload 1.7.4 to unstable, then target that for one of the next
bookworm point releases (but the diff will become even larger)

What's your take on this?

Thanks,
Bernhard

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

> > > Considering the version in unstable is currently
> > > 
> > > 0.0+git20231103-1
> > > 
> > > should the upload be versioned
> > > 
> > > 0.0+git20231103-0+deb12u1 (like originally proposed) or
> > > 0.0+git20231103-1~deb12u1
> > 
> > As originally proposed please. You're not backporting 0.0+git20231103-1
> > directly as far as I know, because you have intermediate changes which
> > should not be included (correct me if I'm wrong about that).
> 
> There have been no changes in unstable other than the new upstream version,
> so technically it would be a backport of 0.0+git20231103-1. This is a diff
> between 0.0+git20230324-1 and 0.0+git20231103-1.
> 
>  Makefile| 13 ++---
>  compat-include/net/gso.h| 20 
>  debian/changelog| 21 +
>  debian/rules|  2 +-
>  drivers/net/ovpn-dco/ovpn.c |  1 +
>  drivers/net/ovpn-dco/tcp.c  | 14 +++---
>  linux-compat.h  |  4 ++--
>  7 files changed, 66 insertions(+), 9 deletions(-)
> 
> The change in d/rules is a new directory in the new upstream version.
> 
> I would just add a d/gbp.conf for the bookworm branch.
> 
> So 0.0+git20231103-1~deb12u1 ?

Uploaded as this version.

Final diff against the version in bookworm is attached

 Makefile| 13 ++---
 compat-include/net/gso.h| 20 
 debian/changelog| 28 
 debian/gbp.conf |  2 ++
 debian/rules|  2 +-
 drivers/net/ovpn-dco/ovpn.c |  1 +
 drivers/net/ovpn-dco/tcp.c  | 14 +++---
 linux-compat.h  |  4 ++--
 8 files changed, 75 insertions(+), 9 deletions(-)

FTR, the diff between 0.0+git20231103-1 and 0.0+git20231103-1~deb12u1 is

 debian/changelog | 7 +++
 debian/gbp.conf  | 2 ++
 2 files changed, 9 insertions(+)

Bernhard
diffstat for openvpn-dco-dkms-0.0+git20230324 openvpn-dco-dkms-0.0+git20231103

 Makefile|   13 ++---
 compat-include/net/gso.h|   20 
 debian/changelog|   28 
 debian/gbp.conf |2 ++
 debian/rules|2 +-
 drivers/net/ovpn-dco/ovpn.c |1 +
 drivers/net/ovpn-dco/tcp.c  |   14 +++---
 linux-compat.h  |4 ++--
 8 files changed, 75 insertions(+), 9 deletions(-)

diff -Nru openvpn-dco-dkms-0.0+git20230324/compat-include/net/gso.h openvpn-dco-dkms-0.0+git20231103/compat-include/net/gso.h
--- openvpn-dco-dkms-0.0+git20230324/compat-include/net/gso.h	1970-01-01 01:00:00.0 +0100
+++ openvpn-dco-dkms-0.0+git20231103/compat-include/net/gso.h	2023-11-11 22:20:11.0 +0100
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0-only */
+/* OpenVPN data channel accelerator
+ *
+ *  Copyright (C) 2023 OpenVPN, Inc.
+ *
+ *  Author:	Antonio Quartulli 
+ */
+
+#ifndef _NET_OVPN_COMPAT_NET_GSO_H
+#define _NET_OVPN_COMPAT_NET_GSO_H
+
+#include 
+
+#if LINUX_VERSION_CODE >= KERNEL_VERSION(6, 4, 10)
+#include_next 
+#else
+#include 
+#endif
+
+#endif /* _NET_OVPN_COMPAT_NET_GSO_H */
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/changelog openvpn-dco-dkms-0.0+git20231103/debian/changelog
--- openvpn-dco-dkms-0.0+git20230324/debian/changelog	2023-04-13 09:47:41.0 +0200
+++ openvpn-dco-dkms-0.0+git20231103/debian/changelog	2024-04-07 15:20:37.0 +0200
@@ -1,3 +1,31 @@
+openvpn-dco-dkms (0.0+git20231103-1~deb12u1) bookworm; urgency=medium
+
+  * Upload 0.0+git20231103-1 to Debian Bookworm
+  * Add d/gbp.conf for debian/bookworm branch
+
+ -- Bernhard Schmidt   Sun, 07 Apr 2024 15:20:37 +0200
+
+openvpn-dco-dkms (0.0+git20231103-1) unstable; urgency=medium
+
+  * New upstream version 0.0+git20231103
+- fixes refcount imbalance ("waiting for tunxxx to become free") seen
+  on heavy loaded TCP servers
+
+ -- Bernhard Schmidt   Sat, 11 Nov 2023 22:20:21 +0100
+
+openvpn-dco-dkms (0.0+git20230816-2) unstable; urgency=medium
+
+  * Install compat-include directory (Closes: #1050211)
+
+ -- Bernhard Schmidt   Tue, 22 Aug 2023 18:00:24 +0200
+
+openvpn-dco-dkms (0.0+git20230816-1) unstable; urgency=medium
+
+  * New upstream version 0.0+git20230816
+- fix build error on kernel 6.5+ (Closes: #1043116)
+
+ -- Bernhard Schmidt   Mon, 21 Aug 2023 22:51:04 +0200
+
 openvpn-dco-dkms (0.0+git20230324-1) unstable; urgency=medium
 
   * Release to unstable targetting bookworm.
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf openvpn-dco-dkms-0.0+git20231103/debian/gbp.conf
--- openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf	1970-01-01 01:00:00.0 +0100
+++ openvpn-dco-dkms-0.0+git20231103/debian/gbp.conf	2024-04-07 15:20:37.0 +0200
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch=debian/bookworm
diff -Nru openvpn-dco

Bug#993018: valgrind: vgcore files unusable in gdb / does not load debug symbols

[Bernhard Übelacker]

control: forwarded 993018 https://bugs.kde.org/show_bug.cgi?id=485134
control: found 993018 1:3.20.0-2.1


Hello,
I got recently remembered about this bug and patch.
So I try to find out what upstream thinks about this.

It can still be observed with current version in Trixie/testing.

Kind regards,
Bernhard

Bug#1040496: qt6-virtualkeyboard FTBFS with parallel=1: qmlcachegen segfaults

[Bernhard Übelacker]

Hello,
I tried to reproduce this inside a minimal stable/bookworm VM
and received a qmlcachegen crash.

See attached file for details.
The resulting backtrace is quite similar to that found in:
  https://bugreports.qt.io/browse/QTBUG-117361

Might avoid the crash, but cannot say if this would make the build succeed.

Kind regards,
Bernhard


# 2024-04-02 stable/bookworm amd64 qemu VM

apt install systemd-coredump gdb libqt6qmlcompiler6-dbgsym
apt build-dep qt6-virtualkeyboard

mkdir /home/benutzer/source/qt6-virtualkeyboard/orig -p
cd/home/benutzer/source/qt6-virtualkeyboard/orig
apt source qt6-virtualkeyboard


cd /home/benutzer/source/qt6-virtualkeyboard
cp orig try1 -a
cd try1/qt6-virtualkeyboard-6.4.2+dfsg
DEB_BUILD_OPTIONS=parallel=1 dpkg-buildpackage


...
[110/301] cd 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components
 && /usr/bin/cmake -E make_directory 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache
 && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path 
/qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml
 -I /usr/lib/x86_64-linux-gnu/qt6/qml -i 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc
 -o 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp
 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/src/components/Keyboard.qml
FAILED: src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp
 
cd 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components
 && /usr/bin/cmake -E make_directory 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache
 && /usr/lib/qt6/libexec/qmlcachegen --bare --resource-path 
/qt-project.org/imports/QtQuick/VirtualKeyboard/Components/Keyboard.qml -I 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml
 -I /usr/lib/x86_64-linux-gnu/qt6/qml -i 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/lib/x86_64-linux-gnu/qt6/qml/QtQuick/VirtualKeyboard/Components/qmldir
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmake_QtQuick_VirtualKeyboard_Components.qrc
 --resource 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qtvkbcomponentsplugin_raw_qml_0.qrc
 -o 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/obj-x86_64-linux-gnu/src/components/.rcc/qmlcache/qtvkbcomponentsplugin_Keyboard_qml.cpp
 
/home/benutzer/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg/src/components/Keyboard.qml
Segmentation fault (core dumped)
ninja: build stopped: subcommand failed.
dh_auto_build: error: cd obj-x86_64-linux-gnu && LC_ALL=C.UTF-8 ninja -j1 -v 
returned exit code 1
make: *** [debian/rules:8: binary] Fehler 1
dpkg-buildpackage: Fehler: Unterprozess debian/rules binary lieferte Exitstatus 
2
benutzer@debian:~/source/qt6-virtualkeyboard/try1/qt6-virtualkeyboard-6.4.2+dfsg$



dmesg
[  431.390156] qmlcachegen[5680]: segfault at 0 ip 7fde080d0672 sp 
7ffe33185b60 error 4 in libQt6QmlCompiler.so.6.4.2[7fde0804d000+106000] 
likely on CPU 5 (core 5, socket 0)
[  431.390173] Code: 64 cd f7 ff 0f 1f 40 00 41 57 41 56 41 55 41 54 55 48 89 
fd 53 48 89 f3 48 83 ec 28 64 48 8b 04 25 28 00 00 00 48 89 44 24 18 <48> 8b 06 
48 c7 06 00 00 00 00 4c 8b 27 48 89 07 4d 85 e4 74 10 4c



journalctl -e
Apr 02 22:45:36 debian systemd-coredump[5682]: [] Process 5680 (qmlcachegen) 
of user 1000 dumped core.
   
   Stack trace of thread 5680:
   #0  0x7fde0

Bug#1040382: slapd: debian12 ships with slapd-2.5.13+dfsg-5 which crashes (segfault in dynlist.la).

[Bernhard Übelacker]

On Wed, 24 Jan 2024 15:07:46 +0100 wouldsmina  wrote:

2024-01-24T09:38:16.810558+01:00 ldap kernel: [ 1553.168747] slapd[13335]: 
segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error 4 in 
dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0, socket 2)
2024-01-24T09:38:16.810568+01:00 ldap kernel: [ 1553.168761] Code: 48 29 d0 48 89 d7 
48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02 00 00 4c 89 ef c7 84 24 
a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 73 64 74 09 45 84 e4 0f 85 22 
03 00 00 48


Hello,
I tried to get back to the source line of this dmesg output, maybe it is of any 
help.

It points to:
dynlist_search at ../../../../../servers/slapd/overlays/dynlist.c:1817
1817(void)o.o_bd->be_search( ,  );

This is the same line shown in the attachment of the upstream bug report.

Attached file shows how I got to this line.

Kind regards,
Bernhardslapd[13335]: segfault at 0 ip 7fc2370b49c1 sp 7fbd359fc0c0 error 4 in 
dynlist-2.5.so.0.1.8[7fc2370b1000+6000] likely on CPU 1 (core 0, socket 2)
Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 
10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 
73 64 74 09 45 84 e4 0f 85 22 03 00 00 48


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 "48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 
10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 
73 64 74 09 45 84 e4 0f 85 22 03 00 00 48" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'

find /b ..., ..., 0x48, 0x29, 0xd0, 0x48, 0x89, 0xd7, 0x48, 0x89, 0xc1, 0x31, 
0xc0, 0x83, 0xc1, 0x6c, 0xc1, 0xe9, 0x03, 0xf3, 0x48, 0xab, 0x48, 0x8b, 0x84, 
0x24, 0x10, 0x02, 0x00, 0x00, 0x4c, 0x89, 0xef, 0xc7, 0x84, 0x24, 0xa0, 0x00, 
0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x48, 0x8b, 0x00, 0xff, 0x50, 0x78, 0x44, 
0x39, 0x73, 0x64, 0x74, 0x09, 0x45, 0x84, 0xe4, 0x0f, 0x85, 0x22, 0x03, 0x00, 
0x00, 0x48



# 2024-04-02 stable/bookworm amd64 qemu VM

apt install gdb slapd slapd-dbgsym

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


gdb -q 
set width 0
set pagination off
file /usr/sbin/slapd
tb main
run 
call dlopen("/usr/lib/ldap/dynlist-2.5.so.0.1.8",0x102)
pipe info target | grep "\.text"
find /b 0x774874a0, 0x7748ccaa, 0x48, 0x29, 0xd0, 0x48, 0x89, 
0xd7, 0x48, 0x89, 0xc1, 0x31, 0xc0, 0x83, 0xc1, 0x6c, 0xc1, 0xe9, 0x03, 0xf3, 
0x48, 0xab, 0x48, 0x8b, 0x84, 0x24, 0x10, 0x02, 0x00, 0x00, 0x4c, 0x89, 0xef, 
0xc7, 0x84, 0x24, 0xa0, 0x00, 0x00, 0x00, 0x03, 0x00, 0x00, 0x00, 0x48, 0x8b, 
0x00, 0xff, 0x50, 0x78, 0x44, 0x39, 0x73, 0x64, 0x74, 0x09, 0x45, 0x84, 0xe4, 
0x0f, 0x85, 0x22, 0x03, 0x00, 0x00, 0x48
b * (0x7748a997 + 42)
info b
disassemble /r 0x7748a997, 0x7748a997 + 62
directory 
/home/benutzer/source/slapd/orig/openldap-2.5.13+dfsg/servers/slapd/overlays



benutzer@debian:~$ gdb -q 
(gdb) set width 0
(gdb) set pagination off
(gdb) file /usr/sbin/slapd
Reading symbols from /usr/sbin/slapd...
Reading symbols from 
/usr/lib/debug/.build-id/40/63a68f1de0ddfe5b5d68cb4f6869587bda460a.debug...
(gdb) tb main
Temporary breakpoint 1 at 0x20b50: file ../../../../servers/slapd/main.c, line 
408.
(gdb) run 
Starting program: /usr/sbin/slapd 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Temporary breakpoint 1, main (argc=1, argv=0x7fffe4d8) at 
../../../../servers/slapd/main.c:408
408 ../../../../servers/slapd/main.c: Datei oder Verzeichnis nicht gefunden.
(gdb) call dlopen("/usr/lib/ldap/dynlist-2.5.so.0.1.8",0x102)
$1 = (void *) 0x557231f0
(gdb) pipe info target | grep "\.text"
0x55574aa0 - 0x556375c4 is .text
0x77fcc060 - 0x77ff0d51 is .text in 
/lib64/ld-linux-x86-64.so.2
0x77fc96b0 - 0x77fc9ced is .text in system-supplied DSO 
at 0x77fc9000
0x77f72260 - 0x77fa8f06 is .text in 
/lib/x86_64-linux-gnu/libldap-2.5.so.0
0x77f53670 - 0x77f5a22a is .text in 
/lib/x86_64-linux-gnu/liblber-2.5.so.0
0x77f365b0 - 0x77f47005 is .text in 
/lib/x86_64-linux-gnu/libsasl2.so.2
0x77ef9040 - 0x77f0e33c is .text in 
/lib/x86_64-linux-gnu/libcrypt.so.1
0x77edf010 - 0x77eeefdd is .text in 
/lib/x86_64-linux-gnu/libslapi-2.5.so.0
0x77ecb490 - 0x77ecf5e6 is .text in 
/lib/x86_64-linux-gnu/libltdl.so.7
0x77ec06e0 - 0x77ec415e is .text in 
/lib/x86_64-linux-gnu/libwrap.so.0
0x77d02380 - 0x77e55f2d is .text in 
/lib/x86_64-linux-gnu/libc.so.6
0x77a3aac0 - 0x77b69520 is .text 

Bug#1035595: gl-117: Crash on exit

[Bernhard Übelacker]

> malloc(): unsorted double linked list corrupted
> abort


Hello,
I could not reproduce this in a minimal bullseye or trixie amd64 VM,
and also not in a bookworm i386 VM.

But valgrind shows a few "Mismatched free() / delete / delete []"
or "Conditional jump or move depends on uninitialised value(s)".
Maybe those are responsible for the malloc abort.

Attached file fixes most of the issues shown by valgrind entering the 
main menu.


Kind regards,
BernhardDescription: Fix a few delete and uninitilised values shown by valgrind

Author: Bernhard Übelacker 
Last-Update: 2024-03-30

Index: gl-117-1.3.2/src/3ds.cpp
===
--- gl-117-1.3.2.orig/src/3ds.cpp
+++ gl-117-1.3.2/src/3ds.cpp
@@ -69,7 +69,7 @@ BinaryFile::BinaryFile (char *filename)
 
 BinaryFile::~BinaryFile ()
 {
-  delete data;
+  delete[] data;
 }
 
 int BinaryFile::readFloat (float *f)
@@ -503,7 +503,7 @@ void CLoad3DS::ReadUVCoordinates (CObjec
   
   for (int i = 0; i < object->numTexVertex; i ++)
 object->vertex [i].tex.take ( [i]);
-  delete p;
+  delete[] p;
 }
 
 void CLoad3DS::ReadVertices (CObject *object, Chunk *previousChunk)
@@ -532,7 +532,7 @@ void CLoad3DS::ReadVertices (CObject *ob
 object->vertex [i].vector.y = object->vertex [i].vector.z;
 object->vertex [i].vector.z = -fTempY;
   }
-  delete p;
+  delete[] p;
 }
 
 void CLoad3DS::ReadObjectMaterial (CModel *model, CObject *object, Chunk 
*previousChunk)
Index: gl-117-1.3.2/src/model.cpp
===
--- gl-117-1.3.2.orig/src/model.cpp
+++ gl-117-1.3.2/src/model.cpp
@@ -616,7 +616,7 @@ CModel::~CModel ()
 delete object [i];
   if (refpoint)
   {
-delete refpoint;
+delete[] refpoint;
   }
 }
 
Index: gl-117-1.3.2/src/gl.cpp
===
--- gl-117-1.3.2.orig/src/gl.cpp
+++ gl-117-1.3.2/src/gl.cpp
@@ -239,10 +239,11 @@ void GL::shadeSmooth ()
 
 void GL::enableFog (float view)
 {
-  float fcol [3];
+  float fcol [4];
   fcol [0] = fogcolor [0] * foglum;
   fcol [1] = fogcolor [1] * foglum;
   fcol [2] = fogcolor [2] * foglum;
+  fcol [3] = 0.0;
   glEnable (GL_FOG);
   glFogfv (GL_FOG_COLOR, fcol);
   glFogf (GL_FOG_DENSITY, 0.1);
Index: gl-117-1.3.2/src/aiobject.cpp
===
--- gl-117-1.3.2.orig/src/aiobject.cpp
+++ gl-117-1.3.2/src/aiobject.cpp
@@ -87,6 +87,7 @@ void DynamicObj::dinit ()
   forcex = 0; forcez = 0; forcey = 0;
   maxthrust = 0.3; braking = 0/*0.99*/; manoeverability = 0.5;
   thrust = maxthrust; recthrust = thrust; recheight = 5.0;
+  realspeed = 1.0;
   ttl = -1;
   shield = 0.01F; maxshield = 0.01F;
   immunity = 0;

Bug#1034685: glob2: Clicking “Settings” and then clicking “Ok” crashes/hangs glob2

[Bernhard Übelacker]

Hello,
this issue is still present with current testing.

For some weird reason this loop in line 195 is never left.
Putting a printf into this loop confirms that n counts correctly,
but the loop is not left when it reaches 13 (NB_BUILDING).

Strangely a similar loop with the same condition in line 186 works.

Not being able to explain it, I wonder if this might be a GCC issue?

Upstream made a change to this line in [1], changing the condition from
"n, filename=) at /usr/include/c++/13/bits/basic_string.h:222
222   _M_data() const
(gdb) bt
#0  0x55723317 in Settings::save (this=, 
filename=) at /usr/include/c++/13/bits/basic_string.h:222
#1  0x5572d613 in SettingsScreen::onAction (this=0x7fff93c0, source=, 
action=, par1=, par2=) at 
src/SettingsScreen.cpp:373
#2  0x557d1445 in GAGGUI::Screen::dispatchEvents 
(this=this@entry=0x7fff93c0, event=event@entry=0x7fff9260) at 
libgag/src/GUIBase.cpp:596
#3  0x557d185b in GAGGUI::Screen::execute 
(this=this@entry=0x7fff93c0, gfx=0x55920560, 
stepLength=stepLength@entry=40) at libgag/src/GUIBase.cpp:506
#4  0x5566cfb0 in Glob2::run (this=this@entry=0x7fffe357, argc=, argv=) at src/Glob2.cpp:348
#5  0x555b58fa in main (argc=, argv=) at 
src/Glob2.cpp:409

(gdb) print n
$2 = 8331033
(gdb) print keyname
$3 = "defaultFlagRadius[8331033]"

src/Settings.cpp:
195 for(int n=0; n(n)+"]";
198 Utilities::streamprintf(stream, "%s=%i\n", 
keyname.c_str(), defaultFlagRadius[n]);
199 }



[1] 
https://github.com/Globulation2/glob2/commit/30d272363d14cb2f3494e8dc7ef86e147b6b

Bug#1033222: libgl1-mesa-dri: Segmentation fault with nouveau_dri.so

[Bernhard Übelacker]

On Mon, 20 Mar 2023 11:34:43 +0100 Christophe Lohr 
 wrote:

Package: libgl1-mesa-dri
Version: 22.3.3-1
Severity: normal
X-Debbugs-Cc: christophe.l...@cegetel.net

Dear Maintainer,
  Xorg is carshing with a segfault:

(EE) Backtrace:
(EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x55c365ce4cf9]
(EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x40) [0x7f00ef25af90]
(EE) 2: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x4406c) [0x7f00ed75999c]
(EE) 3: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x1e4c9) [0x7f00ed733df9]
(EE) 4: /usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so 
(nouveau_drm_screen_create+0x266) [0x7f00ed715b96]
(EE) unw_get_proc_name failed: no unwind info found [-10]
../..
Fatal server error:
(EE) Caught signal 11 (Segmentation fault). Server aborting
(EE)



Hello,
tried to get some symbols for the given backtrace.


2:   0x76b5999c : mov0x20(%rax),%rdi
   in nouveau_pushbuf_destroy at 
../src/gallium/drivers/nouveau/nouveau_screen.c:244

3:0x76b33df4 :call   0x76b59950 

   in nvc0_screen_destroy at 
../src/gallium/drivers/nouveau/nvc0/nvc0_screen.c:740

4:0x76b15b93 :  call   *0x10(%rax)
   in nouveau_drm_screen_create at 
../src/gallium/winsys/nouveau/drm/nouveau_drm_winsys.c:133


An internet search leads to:
  https://docs.mesa3d.org/relnotes/22.3.7.html
Sam Edwards (1):
nouveau: Fix null dereference in nouveau_pushbuf_destroy


So this looks exactly like the place of above frame 2,
and the issue might be fixed by this commit:
  
https://gitlab.freedesktop.org/mesa/mesa/-/commit/4585f21de47af5e2b1a018a052ac0aaf5f1f3ac5
  
https://gitlab.freedesktop.org/italove/mesa/-/commit/9de997bde67df43a9e10a05f9b48419ee4cfec25
  https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/21611


Unfortunately stable/bookworm seems to just have received mesa 22.3.6:
  
https://sources.debian.org/src/mesa/22.3.6-1%2Bdeb12u1/src/gallium/drivers/nouveau/nouveau_screen.c/#L244

A workaround might be to locally rebuild mesa with this patch applied.
And testing/trixie might no longer be affected with a mesa version above 22.3.7.

Kind regards,
Bernhard
# 2024-03-26 Debian stable/bookworm qemu x86_64 VM


apt install libgl1-mesa-dri gdb coreutils-dbgsym


wget 
https://snapshot.debian.org/archive/debian/20230113T215719Z/pool/main/m/mesa/libgl1-mesa-dri_22.3.3-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian/20230113T215719Z/pool/main/m/mesa/libglapi-mesa_22.3.3-1_amd64.deb
wget 
https://snapshot.debian.org/archive/debian-debug/20230113T151646Z/pool/main/m/mesa/libglapi-mesa-dbgsym_22.3.3-1_amd64.deb
dpkg -i *22.3.3*


gdb -q --args /bin/true
set pagination off
set width 0
set environment LD_DEBUG = libs
tb main
run
call dlopen("/usr/lib/x86_64-linux-gnu/dri/nouveau_dri.so",0x101)
disassemble 
nouveau_drm_screen_create+0x266-20,nouveau_drm_screen_create+0x266+20
b *nouveau_drm_screen_create+611
disassemble 
nouveau_drm_screen_create+0x1e4c9-20,nouveau_drm_screen_create+0x1e4c9+20
b* 0x76b33df4
disassemble 
nouveau_drm_screen_create+0x4406c-20,nouveau_drm_screen_create+0x4406c+20
b *0x76b5999c
info b

Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens

[Bernhard Schmidt]

Hi,


Many of the man page URLs link into an access-restricted walled
garden. E.g. all openvpn.net links go to a Cloudflare site that is not
open to all people. It’s an injustice for a Debian man page to refer
users to exclusive resources that may exclude them. This is perhaps
something that should be fixed in the Debian version as the upstream
project has no duty to the users. Debian has a quality standard as
well as a social contract and users to give equitable treatment
to. Therefore IMO the Debian project should remove the
access-restricted links from the man page and ideally replace them
with openly accessible links. The most convenient way to do that would
be to find mirrored versions of the pages in the Wayback Machine.

This one-liner would perhaps do the job well enough:

   sed -e 
'/http.*.openvpn.net/s@https://\([[:alnum:].]*openvpn.net\)@https://web.archive.org/web/\1@'

ietf.org has the same problem.


For this, while I share your concerns about the unmindful use of 
Cloudflare reverse proxy for basically everything I don't agree to call 
this a "walled garden".  Certainly not enough to call the mentioning of 
an URL that just _now_ happens to be "protected" by Cloudflare a policy 
violation (or social contract violation) and alter the URLs to 
web.archive.org, which to my experience is broken quite often, dog-slow 
and not necessarily up-to-date. I think this would be more of a disservice.


Most of the interesting content should be in the manpage and in 
/usr/share/doc/packages/openvpn anyway.


If you have concerns about the use of Cloudflare, please raise this 
upstream. I know there are some devs sensitive to these concerns listening.


Bernhard

Bug#1065879: openvpn: protocol configs have contradictory and confusing meanings in the man page + broken link + links to walled gardens

[Bernhard Schmidt]

Control: tags -1 upstream

Hi,


Users can perhaps experiment to work out which of the various possible
behaviors result, but the man page should be written unambiguously.


I completely agree, but this is not something the Debian OpenVPN 
maintainers can do. Please check the latest version at the upstream 
Github repository https://github.com/OpenVPN/openvpn and file issues 
there, if the issue is still present.


Bernhard

Bug#1067023: ITP: vaultwarden -- Bitwarden compatible server written in Rust

[Bernhard Dick]

Package: wnpp
Severity: wishlist
Owner: Bernhard Dick 
X-Debbugs-Cc: debian-de...@lists.debian.org, bernh...@bdick.de

* Package name: vaultwarden
  Version : 1.30.5
  Upstream Contact: Daniel García 
* URL : https://github.com/dani-garcia/vaultwarden
* License : AGPL
  Programming Lang: Rust
  Description : Bitwarden compatible server written in Rust

Alternative implementation of the Bitwarden server API written in Rust
and compatible with upstream Bitwarden clients*, perfect for self-hosted
deployment where running the official resource-heavy service might not
be ideal.


OpenPGP_0xD61E22D000471E9B.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

Hi,

Considering the version in unstable is currently

0.0+git20231103-1

should the upload be versioned

0.0+git20231103-0+deb12u1 (like originally proposed) or
0.0+git20231103-1~deb12u1


As originally proposed please. You're not backporting 0.0+git20231103-1
directly as far as I know, because you have intermediate changes which
should not be included (correct me if I'm wrong about that).


There have been no changes in unstable other than the new upstream 
version, so technically it would be a backport of 0.0+git20231103-1. 
This is a diff between 0.0+git20230324-1 and 0.0+git20231103-1.


 Makefile| 13 ++---
 compat-include/net/gso.h| 20 
 debian/changelog| 21 +
 debian/rules|  2 +-
 drivers/net/ovpn-dco/ovpn.c |  1 +
 drivers/net/ovpn-dco/tcp.c  | 14 +++---
 linux-compat.h  |  4 ++--
 7 files changed, 66 insertions(+), 9 deletions(-)

The change in d/rules is a new directory in the new upstream version.

I would just add a d/gbp.conf for the bookworm branch.

So 0.0+git20231103-1~deb12u1 ?

Bernhard

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

Hi Jonathan,


On Tue, Nov 14, 2023 at 11:26:54PM +0100, Bernhard Schmidt wrote:

[ Reason ]
openvpn-dco-dkms packages an accelerator kernel module for OpenVPN (OpenVPN
data channel offload). There is one annoying bug tracked as Bug#1055809 where on
heavily loaded TCP servers a refcount issue might occur and the module will
become unusable.


This request was approved but not uploaded in time for the previous point
release (12.5). Should it be included in 12.6, or should this request be
abandoned and closed?


Sorry, my bad, I'm getting old. I'm still interested.

Considering the version in unstable is currently

0.0+git20231103-1

should the upload be versioned

0.0+git20231103-0+deb12u1 (like originally proposed) or
0.0+git20231103-1~deb12u1

?

Bernhard

Bug#1060379: reportbug: Crashes while scrolling with mousewheel or touchpad

[Bernhard Koschicek-Krombholz]

Package: reportbug
Version: 12.0.0
Severity: normal
X-Debbugs-Cc: bernhard.koschicek-krombh...@oeaw.ac.at

Dear Maintainer,

When I use the mousewheel or the touchpad to scroll, mostly in IDEs like 
PyCharm, the screen freezes, mouse symbol freezes but mouse is moveable. 
After that, sometimes the laptop restarts, or just the whole desktop GUI 
restarts or nothing happens until I force shut down the laptop. 
dmesg log:
[Wed Jan 10 10:20:03 2024] usb 1-5: USB disconnect, device number 5
[Wed Jan 10 10:20:03 2024] usb 1-5: new full-speed USB device number 8 using 
xhci_hcd
[Wed Jan 10 10:20:03 2024] usb 1-5: New USB device found, idVendor=27c6, 
idProduct=6594, bcdDevice= 1.00
[Wed Jan 10 10:20:03 2024] usb 1-5: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[Wed Jan 10 10:20:03 2024] usb 1-5: Product: Goodix USB2.0 MISC
[Wed Jan 10 10:20:03 2024] usb 1-5: Manufacturer: Goodix Technology Co., Ltd.
[Wed Jan 10 10:20:03 2024] usb 1-5: SerialNumber: UIDAF3A23C5__MOC_B0
[Wed Jan 10 10:20:06 2024] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring 
gfx_0.0.0 timeout, signaled seq=70746, emitted seq=70748
[Wed Jan 10 10:20:06 2024] [drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process 
information: process Xorg pid 1019 thread Xorg:cs0 pid 1180
[Wed Jan 10 10:20:06 2024] amdgpu :c3:00.0: amdgpu: GPU reset begin!
[Wed Jan 10 10:20:06 2024] 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=3
[Wed Jan 10 10:20:06 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[Wed Jan 10 10:20:06 2024] 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=3
[Wed Jan 10 10:20:06 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[Wed Jan 10 10:20:06 2024] 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=3
[Wed Jan 10 10:20:06 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[Wed Jan 10 10:20:06 2024] 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=3
[Wed Jan 10 10:20:06 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[Wed Jan 10 10:20:06 2024] 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=3
[Wed Jan 10 10:20:06 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[Wed Jan 10 10:20:07 2024] 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=3
[Wed Jan 10 10:20:07 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[Wed Jan 10 10:20:07 2024] 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=3
[Wed Jan 10 10:20:07 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[Wed Jan 10 10:20:07 2024] 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=3
[Wed Jan 10 10:20:07 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[Wed Jan 10 10:20:07 2024] 
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES 
failed to response msg=3
[Wed Jan 10 10:20:07 2024] [drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* 
failed to unmap legacy queue
[Wed Jan 10 10:20:07 2024] [drm:gfx_v11_0_hw_fini [amdgpu]] *ERROR* failed to 
halt cp gfx
[Wed Jan 10 10:20:07 2024] amdgpu :c3:00.0: amdgpu: MODE2 reset
[Wed Jan 10 10:20:07 2024] amdgpu :c3:00.0: amdgpu: GPU reset succeeded, 
trying to resume
[Wed Jan 10 10:20:07 2024] [drm] PCIE GART of 512M enabled (table at 
0x00800090).
[Wed Jan 10 10:20:07 2024] amdgpu :c3:00.0: amdgpu: SMU is resuming...
[Wed Jan 10 10:20:07 2024] amdgpu :c3:00.0: amdgpu: SMU is resumed 
successfully!
[Wed Jan 10 10:20:07 2024] [drm] DMUB hardware initialized: version=0x08000500
[Wed Jan 10 10:20:08 2024] [drm] kiq ring mec 3 pipe 1 q 0
[Wed Jan 10 10:20:08 2024] [drm] VCN decode and encode initialized 
successfully(under DPG Mode).
[Wed Jan 10 10:20:08 2024] amdgpu :c3:00.0: [drm:jpeg_v4_0_hw_init 
[amdgpu]] JPEG decode initialized successfully.
[Wed Jan 10 10:20:08 2024] amdgpu :c3:00.0: amdgpu: ring gfx_0.0.0 uses VM 
inv eng 0 on hub 0
[Wed Jan 10 10:20:08 2024] amdgpu :c3:00.0: amdgpu: ring comp_1.0.0 uses VM 
inv eng 1 on hub 0
[Wed Jan 10 10:20:08 2024] amdgpu :c3:00.0: amdgpu: ring comp_1.1.0 uses VM 
inv eng 4 on hub 0
[Wed Jan 10 10:20:08 2024] amdgpu :c3:00.0: amdgpu: ring comp_1.2.0 uses VM 
inv eng 6 on hub 0
[Wed Jan 10 10:20:08 2024] amdgpu :c3:00.0: amdgpu: ring comp_1.3.0 uses VM 
inv eng 7 on hub 0
[Wed Jan 10 10:20:08 2024] amdgpu :c3:00.0: amdgpu: ring comp_1.0.1 uses VM 
inv eng 8 on hub 0

Bug#1056984: bind9: regression: the branch 9.19 misses some commits from the branch 9.18

[Bernhard Schmidt]

Control: forwarded -1 
https://salsa.debian.org/dns-team/bind9/-/merge_requests/26

On 27/11/23 09:12 PM, Arnaud Rebillout wrote:

Hi,

> In https://bugs.debian.org/1025519 was reported a bug in bind9 apparmor
> configuration. It was fixed on the branch `debian/9.18`, with commit
> https://salsa.debian.org/dns-team/bind9/-/commit/5c03f25e, and released
> version `1:9.18.10-2` of bind9 (released in December 2022).
> 
> However today the issue is back. The regression is due to the fact that
> the commit 5c03f25e was not applied in the branch `debian/9.19`, which
> is currently in Debian unstable.
> 
> Looking at the changelog (on branch `debian/9.19`), it jumps straight
> from `9.18.2-1` to `9.19.0-1`, makes me wonder how many good commits
> from the branch 9.18 are missing in the branch 9.19... Please have a
> look, and at least apply 5c03f25e, it's a must!

I have taken a look and identified four missing commits. 

@Ondrej: Could you have a look at
https://salsa.debian.org/dns-team/bind9/-/merge_requests/26 ?

Bernhard

Bug#1055607: gmemusage crashes immediately

[Bernhard Übelacker]

Hello,

On Wed, 08 Nov 2023 20:17:49 +0100 =?utf-8?q?Andr=C3=A9_Offringa?= 
 wrote:


$ gmemusage
realloc(): invalid next size
Aborted


Looks like caused by having not enough space
for process names longer than 13 characters.

A package built with the modification below
shows no longer this crash.

Kind regard,
Bernhard




(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7f43d244b15f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f43d23fd472 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7f43d23e74b2 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7f43d23e81ed in __libc_message (fmt=fmt@entry=0x7f43d255a78c "%s\n") 
at ../sysdeps/posix/libc_fatal.c:150
#5  0x7f43d2454a75 in malloc_printerr (str=str@entry=0x7f43d2558326 "realloc(): 
invalid next size") at ./malloc/malloc.c:5658
#6  0x7f43d245876c in _int_realloc (av=av@entry=0x7f43d2594c80 
, oldp=oldp@entry=0x564149c00680, oldsize=oldsize@entry=912, 
nb=nb@entry=1808) at ./malloc/malloc.c:4836
#7  0x7f43d2459596 in __GI___libc_realloc 
(oldmem=oldmem@entry=0x564149c00690, bytes=bytes@entry=1792) at 
./malloc/malloc.c:3477
#8  0x564148a039a5 in addProc (procname=procname@entry=0x7fffa8056900 
"cpuhp/3", mem=0, rss=0) at hash.c:89
#9  0x564148a03f20 in makeProcs () at proc.c:215
#10 0x564148a02e32 in draw_window () at gmemusage.c:489
#11 0x564148a02b85 in main (argc=, argv=) at 
gmemusage.c:300



benutzer@debian:~$ valgrind gmemusage
==1246== Memcheck, a memory error detector
==1246== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1246== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1246== Command: gmemusage
==1246==
==1246== Invalid write of size 1
==1246==at 0x48468E4: strcpy (vg_replace_strmem.c:553)
==1246==by 0x10B958: addProc (hash.c:101)
==1246==by 0x10BF1F: makeProcs (proc.c:215)
==1246==by 0x10AE31: draw_window (gmemusage.c:489)
==1246==by 0x10AB84: main (gmemusage.c:300)
==1246==  Address 0x4e6b740 is 0 bytes after a block of size 3,584 alloc'd
==1246==at 0x484582F: realloc (vg_replace_malloc.c:1437)
==1246==by 0x10B9A4: addProc (hash.c:89)
==1246==by 0x10BF1F: makeProcs (proc.c:215)
==1246==by 0x10AE31: draw_window (gmemusage.c:489)
==1246==by 0x10AB84: main (gmemusage.c:300)
==1246==



--- hash.c.orig 1998-01-14 17:43:13.0 +0100
+++ hash.c  2023-11-25 11:26:06.292932169 +0100
@@ -10,2 +10,3 @@
 #include 
+#include 
 #include "common.h"
@@ -73,3 +74,4 @@ addProc ( char *procname , int mem , int
   thisproc = nextproc = procs ;
-  strcpy ( thisproc -> procname , procname ) ;
+  strncpy ( thisproc -> procname , procname , sizeof(thisproc -> procname) 
) ;
+  thisproc -> procname[sizeof(thisproc -> procname)-1] = '\0';
   thisproc -> totMem = mem ;
@@ -100,3 +102,4 @@ addProc ( char *procname , int mem , int
   thisproc = procs + nProcs ;
-  strcpy ( thisproc -> procname , procname ) ;
+  strncpy ( thisproc -> procname , procname , sizeof(thisproc -> procname) 
) ;
+  thisproc -> procname[sizeof(thisproc -> procname)-1] = '\0';
   thisproc -> totMem = mem ;

Bug#1055966: bookworm-pu: package openvpn-dco-dkms/0.0+git20230324-1+deb12u1 (or 0.0+git20231103-0+deb12u1?)

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: openvpn-dco-d...@packages.debian.org
Control: affects -1 + src:openvpn-dco-dkms

[ Reason ]
openvpn-dco-dkms packages an accelerator kernel module for OpenVPN (OpenVPN
data channel offload). There is one annoying bug tracked as Bug#1055809 where on
heavily loaded TCP servers a refcount issue might occur and the module will
become unusable.

The bug has been fixed upstream. The new upstream snapshot is already in sid.

Apart from that change there is a fix for compilation with Kernel >= 6.5 that
we might want to have in stable for backport kernels. Tracked as Bug#1043116.
That patch could be backported, but needs some fixup.

Apart from that there are only changes for building with RHEL9, which is a noop
on Debian.

https://github.com/OpenVPN/ovpn-dco/compare/1c2c84e99d0c1513db38ac7a3858f21229906fd7..master

Backporting the build fix would actually make the diff larger than the new
upstream version and harder to maintain, so I'm proposing two options:

a) backport only the fix for Bug#1055809 and upload as
openvpn-dco-dkms/0.0+git20230324-1+deb12u1

 changelog|9 
 gbp.conf |2 +
 patches/fix-refcount-imbalance.patch |   38 +++
 patches/series   |1 
 4 files changed, 50 insertions(+)

b) upload the new upstream snapshot as 0.0+git20231103-0+deb12u1, fixing the
build error on kernel 6.5

 Makefile|   13 ++---
 compat-include/net/gso.h|   20 
 debian/changelog|   21 +
 debian/rules|2 +-
 drivers/net/ovpn-dco/ovpn.c |1 +
 drivers/net/ovpn-dco/tcp.c  |   14 +++---
 linux-compat.h  |4 ++--
 7 files changed, 66 insertions(+), 9 deletions(-)

[ Impact ]
If neither update is allowed the kernel module will hang on busy servers

If we only fix the refcount imbalance the module will not build on future
backports kernels. Backporting that fix as well would be possible, but actually
the diff would be larger and we cannot be sure whether new fixes would apply
cleanly.

[ Tests ]
The code fix is trivial enough and has been verified upstream. The new module
is currently running on my employers eduVPN server.

[ Risks ]
The changes are pretty trivial and the vast majority of them is a noop on
Bookworm or Debian as a whole

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

[ Changes ]
See the explaination above for the minimal version and the github diff link for
the new upstream version
diffstat for openvpn-dco-dkms-0.0+git20230324 openvpn-dco-dkms-0.0+git20230324

 changelog|9 
 gbp.conf |2 +
 patches/fix-refcount-imbalance.patch |   38 +++
 patches/series   |1 
 4 files changed, 50 insertions(+)

diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/changelog 
openvpn-dco-dkms-0.0+git20230324/debian/changelog
--- openvpn-dco-dkms-0.0+git20230324/debian/changelog   2023-04-13 
09:47:41.0 +0200
+++ openvpn-dco-dkms-0.0+git20230324/debian/changelog   2023-11-14 
22:18:17.0 +0100
@@ -1,3 +1,12 @@
+openvpn-dco-dkms (0.0+git20230324-1+deb12u1) bookworm; urgency=medium
+
+  * Import upstream patch to fix refcount imbalance (Closes: 1055809)
+- fixes "waiting for tunxxx to become free" seen on heavy loaded TCP
+  servers
+  * Add d/gbp.conf for debian/bookworm branch
+
+ -- Bernhard Schmidt   Tue, 14 Nov 2023 22:18:17 +0100
+
 openvpn-dco-dkms (0.0+git20230324-1) unstable; urgency=medium
 
   * Release to unstable targetting bookworm.
diff -Nru openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf 
openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf
--- openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf1970-01-01 
01:00:00.0 +0100
+++ openvpn-dco-dkms-0.0+git20230324/debian/gbp.conf2023-11-14 
22:18:17.0 +0100
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch=debian/bookworm
diff -Nru 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch
--- 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch
1970-01-01 01:00:00.0 +0100
+++ 
openvpn-dco-dkms-0.0+git20230324/debian/patches/fix-refcount-imbalance.patch
2023-11-14 22:18:17.0 +0100
@@ -0,0 +1,38 @@
+From 7b7a28fcb0c244c7182922f7c83cb09bcd840c84 Mon Sep 17 00:00:00 2001
+From: Antonio Quartulli 
+Date: Wed, 1 Nov 2023 23:49:39 +0100
+Subject: [PATCH] ovpn-dco: fix refcount imbalance up

Bug#1055809: Kernel module hangs with "waiting for tunxxx to become free"

[Bernhard Schmidt]

Source: openvpn-dco-dkms
Version: 0.0+git20230324-1
Severity: important
Tags: upstream

The dco module sometimes hangs on stopping/crashing OpenVPN processes with

unregister_netdevice: waiting for tun321 to become free. Usage count = 1

This has been tracked in https://github.com/OpenVPN/ovpn-dco/issues/18

Bug#1052561: bookworm-pu: package nfdump/1.7.3-1 (pre-discussion)

[Bernhard Schmidt]

Am 07.10.23 um 13:14 schrieb Jonathan Wiltshire:

Hi,


On Sun, Sep 24, 2023 at 09:36:00PM +0200, Bernhard Schmidt wrote:

[ Other info ]
I did not attach the debdiff because it would be too large and only consist
of upstream changes. No changes to debian/ (except dropping a backported fix
already in 12.1) are necessary.


What does diffstat look like, possibly with translations and tests
excluded? Let's see what sort of scale we're talking here.


Plain debdiff

 185 files changed, 25810 insertions(+), 28068 deletions(-)

There are no translation changes and not many tests to exclude, but a 
few things stand out. Dropping quite a bit from m4 buildfiles as part of 
commits


https://github.com/phaag/nfdump/commit/488e2136bb97f5ae45900fd93e390e1be25cb91e
https://github.com/phaag/nfdump/commit/93f1af69d15dec0600d7ac311bd33c15556dee25

(remove autogen m4 files from repo)

 m4/libtool.m4  | 8400 
---

 m4/ltoptions.m4|  437 --
 m4/ltsugar.m4  |  124 --
 m4/ltversion.m4|   24 -
 m4/lt~obsolete.m4  |   99 --

a few renames

 src/lib/{ => compress}/lzoconf.h   |0
 src/lib/{ => compress}/lzodefs.h   |0
 src/lib/{ => compress}/minilzo.c   |0
 src/lib/{ => compress}/minilzo.h   |0
 src/{ => lib}/conf/nfconf.c|   38 +-
 src/{ => lib}/conf/nfconf.h|2 +
 src/{ => lib}/conf/nfdump.conf.dist|   19 +-
 src/{ => lib}/conf/toml.c  |2 +-
 src/{ => lib}/conf/toml.h  |0
 src/{nfcapd/netflow_pcapd.c => netflow/nfd_raw.c}  |   96 +-
 src/{include/netflow_pcapd.h => netflow/nfd_raw.h} |   18 +-

and the move and update of the embedded lz4 code

https://github.com/phaag/nfdump/commit/99dc96e8433637ef1d62edbf13f26655a3815982

 src/lib/compress/lz4.c | 2751 
++

 src/lib/compress/lz4.h |  862 
 src/lib/lz4.c  | 1564 
--

 src/lib/lz4.h  |  483 ---

and the addition of the High Compression Mode of LZ4

 src/lib/compress/lz4hc.c   | 1637 
+++

 src/lib/compress/lz4hc.h   |  413 ++

https://github.com/phaag/nfdump/commit/cb254b1730b3abc39627b16d4c04b97cdcd62de0

I'll reach out to upstream about those embedded lz4 copy, right now it 
does not look like one could build against an external library, in 
contrast to zstd and bz2 support.


If you exclude all

git diff upstream/1.7.1 upstream/1.7.3 --stat -- . ':!*.m4' 
':!src/lib/compress/lz4.*' ':!src/lib/compress/lz4hc.*' ':!src/lib/lz4.*'


that you get down to

 .github/FUNDING.yml|   1 +
 .github/workflows/c-cpp.yml|  23 +
 .gitignore |   1 +
 ChangeLog  | 171 ++
 Makefile.am|   2 +-
 README.md  | 112 +++-
 configure.ac   |  64 +-
 extra/CreateSubHierarchy.pl|   6 +-
 extra/docker/Dockerfile.alpine |   2 +-
 extra/docker/Dockerfile.ubuntu |   2 +-
 extra/nfsen/nfsen-1.6-stats-influxdb.patch |   2 +-
 extra/nfsen/nfsen-trunk-stats-influxdb.patch   |   2 +-
 man/geolookup.1|   2 +-
 man/nfanon.1   |   4 +-
 man/nfcapd.1   |  49 +-
 man/nfdump.1   |  97 ++-
 man/nfexpire.1 |   6 +-
 man/nfpcapd.1  |  32 +-
 man/nfreplay.1 |   5 +-
 man/sfcapd.1   |  35 +-
 src/collector/Makefile.am  |   5 +-
 src/collector/bookkeeper.c |  28 +-
 src/collector/bookkeeper.h |  15 +-
 src/collector/collector.c  |  74 ++-
 src/collector/collector.h  |  30 +-
 src/collector/expire.c |  23 +-
 src/collector/launch.c | 329 ++
 src/collector/launch.h |  11 +-
 src/collector/metric.c |   8 +-
 src/collector/nfnet.c  |  92 ++-
 src/collector/nfnet.h  

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#1052561: bookworm-pu: package nfdump/1.7.3-1 (pre-discussion)

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nfd...@packages.debian.org
Control: affects -1 + src:nfdump

[ Reason ]
I am proposing updating updating the nfdump package to a new _upstream_ release
in bookworm.

I made the judgement to switch to the new nfdump 1.7 series in the bookworm
release cycle. This has turned out to be premature. The 1.7.1 release we
shipped in bookworm was under rapid development.

One of the most popular applications for nfdump is to run it together with
nfsen, a PHP based webfrontend to collect and analyze netflows. This one also
has been under rapid development during the bookworm freeze.

It turns out that at least in some cases nfdump does not work well with recent
nfsen versions, see Bug#1042535. The likely commit has been identified, but it
was impossible to backport it due to the major source restructuring nfdump
1.7.x went through. Between 1.7.1 and 1.7.3 there were 169 commits, with bugfix
commits touching core parts of the code.

Things however appear to have stabilized now. The 1.7.3 release is a couple of
weeks old, with no bad bug reports appearing. It has been tested both by the
reporter of Bug#1042535 and by me, and it fixes all known errors with nfdump
1.7.x.

Therefor I'd like to update nfdump in bookworm from 1.7.1 to 1.7.3, same as in
testing.

The alternative would be to use backports to provide a better nfdump version
for bookworm users, but in this case I'm sure that 1.7.3 would be the better
fit for all users. If you reject updating to 1.7.3 I will do this instead.

I'm open to uploading that into -proposed early after the next point release to
give it the maximum possible coverage.

[ Impact ]
Users using nfsen (a popular framework for nfsen) will not get usable profiles.

[ Tests ]
There is an upstream testsuite ran during build, but this did not detect the
nfprofile issue earlier.

[ Risks ]
New upstream version always carries some risk, but the package is low popcon
and most of the times used with nfsen. Which is from the same author who
heartily recommends the latest 1.7.3

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

[ Changes ]
169 upstream commits.

[ Other info ]
I did not attach the debdiff because it would be too large and only consist
of upstream changes. No changes to debian/ (except dropping a backported fix
already in 12.1) are necessary.

Bug#904044: OpenVPN3

[Bernhard Schmidt]

Hi Marc,

Because our company decided "there will be no impact" to use multifactor 
authentication, I was forced to package openvpn3.


I don't know if you were planning anything in that direction, but my 
current work can be found here:


https://salsa.debian.org/televic-team/openvpn3 
<https://salsa.debian.org/televic-team/openvpn3>


It's rough, I need to go through the finer details.

If you are nog planning anything, I can open an ITP.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044 
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904044>


Thanks for letting us know. I haven't taken a deep look at it, but it 
looks pretty sane and I'm not aware of any work other than the upstream 
repository. You are certainly welcome to package it.


I can review and sponsor the first uploads if noone beats me to it 
(anyone: feel free to do so, there is no need of the OpenVPN2 
maintainers to specifically review anything in OpenVPN3, and they will 
continue to be used in parallel for years to come).


I've seen you have applied for DM, so I would be happy to give you 
uploader rights when things have settled.


Bernhard

Bug#1051801: document DEB_BUILD_OPTIONS value nopgo

[Bernhard M. Wiedemann]

On 11/09/2023 09.25, Helmut Grohne wrote:

It also
is unclear how it affects reproducible builds since such builds depend
on the performance characteristics of the system performing the build.


It is worth noting that the performance (execution time) of a 
build-system does not matter for profiling, so it is possible to achieve 
reproducible builds with PGO enabled. It is just hard.


See https://build.opensuse.org/request/show/499887
linked in 
https://github.com/bmwiedemann/theunreproduciblepackage/tree/master/pgo


In that gzip patch we even had to hide the name of the temporary file 
from gzip to not get variations from a 'tolower' call that would be 
optimized for different amounts of upper/lower-case letters.


Parallel builds and variations in ordering are also problematic, because 
some of the performance-counter-logic in gcc is not commutative, so 
running A and B calls produces different results from first calling B 
and then A.



With all that said, in openSUSE we also have a %do_profiling value to 
disable PGO for gcc, python and some others, because these profiling 
runs are too large to make deterministic.


Ciao
Bernhard M.

Bug#1050180: bookworm-pu: package freeradius/3.2.1+dfsg-4+deb12u1

[Bernhard Schmidt]

Hi,

Control: tag -1 confirmed

On Mon, Aug 21, 2023 at 04:16:12PM +0200, Bernhard Schmidt wrote:

[ Reason ]
I would like to fix a regression in the bookworm release of FreeRADIUS where
the TLS-Client-Cert-Common-Name attribute contains the wrong value, breaking
some use-cases (Bug#1043282)

It has been fixed in the new upstream version in sid, the two relevant commits
apply cleanly. The reporter has confirmed that this fixes his problem.


Please go ahead.


Thanks, the package has been uploaded and accepted.

Bernhard

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 

Bug#1050180: bookworm-pu: package freeradius/3.2.1+dfsg-4+deb12u1

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: freerad...@packages.debian.org
Control: affects -1 + src:freeradius

[ Reason ]
I would like to fix a regression in the bookworm release of FreeRADIUS where
the TLS-Client-Cert-Common-Name attribute contains the wrong value, breaking
some use-cases (Bug#1043282)

It has been fixed in the new upstream version in sid, the two relevant commits
apply cleanly. The reporter has confirmed that this fixes his problem.

[ Impact ]
Attribute not usable for filtering/policy decisions

[ Tests ]
no additional CI tests covering _this_ specific feature. Reporter has confirmed
the fix.

[ Risks ]
Change is small and has been part of two upstream releases

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

[ Changes ]
See above + d/gbp.conf for the correct stable branch

[ Other info ]
none
diff -Nru freeradius-3.2.1+dfsg/debian/changelog 
freeradius-3.2.1+dfsg/debian/changelog
--- freeradius-3.2.1+dfsg/debian/changelog  2023-05-16 00:04:23.0 
+0200
+++ freeradius-3.2.1+dfsg/debian/changelog  2023-08-19 00:26:34.0 
+0200
@@ -1,3 +1,11 @@
+freeradius (3.2.1+dfsg-4+deb12u1) bookworm; urgency=medium
+
+  * Add d/gbp.conf for bookworm stable branch
+  * Cherry-Pick two upstream commits to fix TLS-Client-Cert-Common-Name
+contains incorrect value (Closes: #1043282)
+
+ -- Bernhard Schmidt   Sat, 19 Aug 2023 00:26:34 +0200
+
 freeradius (3.2.1+dfsg-4) unstable; urgency=medium
 
   * Don't install symlink for cache_eap module no longer shipped
diff -Nru freeradius-3.2.1+dfsg/debian/gbp.conf 
freeradius-3.2.1+dfsg/debian/gbp.conf
--- freeradius-3.2.1+dfsg/debian/gbp.conf   1970-01-01 01:00:00.0 
+0100
+++ freeradius-3.2.1+dfsg/debian/gbp.conf   2023-08-19 00:26:34.0 
+0200
@@ -0,0 +1,2 @@
+[DEFAULT]
+debian-branch = debian/bookworm
diff -Nru 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch
--- 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch
1970-01-01 01:00:00.0 +0100
+++ 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-1.patch
2023-08-19 00:26:34.0 +0200
@@ -0,0 +1,40 @@
+From d23987cbf55821dc56ab70d5ce6af3305cf83289 Mon Sep 17 00:00:00 2001
+From: "Alan T. DeKok" 
+Date: Tue, 25 Oct 2022 10:51:02 -0400
+Subject: [PATCH] set partial chain always.  Helps with #4785
+
+---
+ src/main/tls.c | 11 ---
+ 1 file changed, 8 insertions(+), 3 deletions(-)
+
+diff --git a/src/main/tls.c b/src/main/tls.c
+index aa6395d8391f..a33699cbb66e 100644
+--- a/src/main/tls.c
 b/src/main/tls.c
+@@ -3546,6 +3546,11 @@ X509_STORE *fr_init_x509_store(fr_tls_server_conf_t 
*conf)
+   if (conf->check_all_crl)
+   X509_STORE_set_flags(store, X509_V_FLAG_CRL_CHECK_ALL);
+ #endif
++
++#if defined(X509_V_FLAG_PARTIAL_CHAIN)
++  X509_STORE_set_flags(store, X509_V_FLAG_PARTIAL_CHAIN);
++#endif
++
+   return store;
+ }
+ 
+@@ -4011,11 +4016,11 @@ SSL_CTX *tls_init_ctx(fr_tls_server_conf_t *conf, int 
client, char const *chain_
+   if (conf->ca_file || conf->ca_path) {
+   if ((certstore = fr_init_x509_store(conf)) == NULL ) return 
NULL;
+   SSL_CTX_set_cert_store(ctx, certstore);
+-  }
+-
++  } else {
+ #if defined(X509_V_FLAG_PARTIAL_CHAIN)
+-  X509_STORE_set_flags(SSL_CTX_get_cert_store(ctx), 
X509_V_FLAG_PARTIAL_CHAIN);
++  X509_STORE_set_flags(SSL_CTX_get_cert_store(ctx), 
X509_V_FLAG_PARTIAL_CHAIN);
+ #endif
++  }
+ 
+   if (conf->ca_file && *conf->ca_file) SSL_CTX_set_client_CA_list(ctx, 
SSL_load_client_CA_file(conf->ca_file));
+ 
diff -Nru 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch
--- 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch
1970-01-01 01:00:00.0 +0100
+++ 
freeradius-3.2.1+dfsg/debian/patches/fix-tls-client-cert-common-name-2.patch
2023-08-19 00:26:34.0 +0200
@@ -0,0 +1,29 @@
+From 3d08027f30c6d9c1eaccf7d60c68c8f7d78017c3 Mon Sep 17 00:00:00 2001
+From: "Alan T. DeKok" 
+Date: Wed, 26 Oct 2022 07:31:43 -0400
+Subject: [PATCH] fix cert order only for lookup=0.  Fixes #4785
+
+---
+ src/main/tls.c | 9 -
+ 1 file changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/src/main/tls.c b/src/main/tls.c
+index a33699cbb66e..c67148cf12c7 100644
+--- a/src/main/tls.c
 b/src/main/tls.c
+@@ -3015,7 +3015,14 @@ int cbtls_verify(int ok, X509_STORE_CTX *ctx)
+*/
+   if (lookup

Bug#1043282: freeradius: TLS-Client-Cert-Common-Name contains incorrect value

[Bernhard Schmidt]

Control: forward -1 https://github.com/FreeRADIUS/freeradius-server/issues/4785
Control: fixed -1 3.2.3+dfsg-1

On 08/08/23 02:59 PM, Åke Holmlund wrote:

> We have a setup with TLS authentication where we use the CN of the
> client certificate ti check in LDAP if that CN has access to our VPN
> service. This was working fine in bullseye but breaks in bookworm. The
> reason is that TLS-Client-Cert-Common-Name no longer contains the CN
> from the client certificate but the CN from the CA certificate.
> 
> This is a known bug in freeradius 3.2.1 (see
> https://github.com/FreeRADIUS/freeradius-server/issues/4785) and is
> fixed in 3.2.2. I REALLY hope this can be fixed ASAP in bookworm
> because we have had to skip the LDAP check to get our VPN working
> again and that is not a good thing.

I have cherry-picked both commits mentioned in the GH issue, could you
please try the binaries at

https://people.debian.org/~berni/freeradius/

Thanks,
Bernhard

Bug#1042535: Acknowledgement (nfdump doesn't work with profiles using nfsen 1.3.9)

[Bernhard Schmidt]

Control: tags -1 confirmed upstream
Control: forward -1 https://github.com/phaag/nfsen/issues/19
Control: found -1 1.7.1-1

On 31/07/23 08:16 AM, Marcelo Gondim wrote:

Hi,

> > The commit you mention is quite intrusive (a lot of source cleanup mixed
> > with the bugfix) and does not apply to 1.7.1

So, I tested some more.

With my installation (still on Bullseye) the official backport of 1.7.1
somewhat works. A few random channels in a profile sometimes show 0 and
throw errors like

Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Unable to read appendix block of file: 
/opt/nfsen/profiles-data/ECIX/ECIX-BER-in/2023/08/18/nfcapd.202308181520
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Unable to read appendix block of file: 
/opt/nfsen/profiles-data/ECIX/ECIX-MUC-in/2023/08/18/nfcapd.202308181520
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
Uncompress_Block_LZO() error decompression failed in nffile.c line 342: LZO 
error: -6
ptr error - elementHeader > eor

when running a query against it, but it mostly works.

The patch you mentioned can be applied with just a single manually fixed
reject, it builds cleanly and the testsuite also works. But with this
patch it actually is worse, no data is ever created by nfprofile. No
error in the logs.

Plain 1.7.2 does not work either, same issue.

On 1.7.2 the patch you mentioned does not apply either, it has other
rejects. Looking at the changes src/lib/nffile.c had since 1.7.2 has
been released I would not be comfortable to do this.

The current git head appears to work fine, but that's not an option for
stable.

Looking at the commits I think it's virtually impossible to get a clean
"this minimally intrusive commit fixes the bug on top of the 1.7.1 in
stable", so I believe the only viable option would be 

- upload current snapshot to unstable fixing this bug
- as soon as there is a 1.7.3 release, upload that and provide a
  bookworm-backport for people using nfsen

Bernhard

Bug#1024129: ITP: tacacs+ -- TACACS+ authentication daemon

[Bernhard Schmidt]

On 28/06/23 11:01 PM, Daniel Gröber wrote:

Hi,

> I'm also interested in having tacacs+ available in Debian. I wanted to test
> your packages but unfortunately mentors removes packages after a while and
> so they are gone from there now.
> 
> The git repo you linked to doesn't seem to contain debian packaging. Could
> you re-upload to mentors or push your packaging/debian branch?

I was also looking at this, Pawel any chance you could upload your
previous work somewhere?

There are multitude of issues with the current codebase and so far I'm
not sure whether all of them can be solved.

- latest Debian package had 4.0.4.27a from 2013
- latest official release is 4.0.4.28 from January 2015
- there is a 4.0.4.29a from March 2015 in the alpha/ directory of the
  upstream FTP server

There is at least one known fork of 4.0.4.28 from Facebook at
https://github.com/facebook/tac_plus . The project started good but
looks dead. There are however a few interesting open pull requests that
appear to fix errors on RHEL9, that should be sufficiently close to us.

The thing that lead to the removal from Debian was python2. Glancing at
the code I could not figure out the reason for the build-time
dependency. There is a python script installed in the tacacs+ binary
package (do_auth.py). Not everyone uses that. We don't, so I cannot
fully test it. But at first glance it appears to be able to be run on
python3 by just dropping the future imports. And there is an official
python3 port by it's original author at https://www.tacacs.org/

So I think using the Facebook fork with a few imported pull-requests and
maybe switching to the newer do_auth.py (in a seperate binary package
while we are at it) could do the trick.

Bernhard

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#1041349: transition: linphone-stack

[Bernhard Schmidt]

Am 31.07.23 um 21:25 schrieb Sebastian Ramacher:

Hi

On 2023-07-30 11:09:08 +0200, Bernhard Schmidt wrote:

We need a rebuild of src:libosmo-abis against the new version of libortp and
trx will be removed, see Bug#1026042


Why is the rebuild of libosmo-abis required?


https://tracker.debian.org/pkg/ortp

migrating libortp16/1:5.2.0-2/amd64 to testing makes 
libosmotrau2/1.3.0-2+b1/amd64 uninstallable


linphone-stack upstream does not really support mixing the branches of 
the various libraries, so we don't use symbols and generate shlis 
dependencies like this


libortp16 (>= 1:5.1.64), libortp16 (<< 1:5.2.0)

and for the new version of libortp

libortp16 (>= 1:5.2.0-1), libortp16 (<< 1:5.3.0-1)

BTW, the RM bug for src:trx is Bug#1042534

Bernhard

Bug#1042535: Acknowledgement (nfdump doesn't work with profiles using nfsen 1.3.9)

[Bernhard Schmidt]

Hi Marcelo,

I asked Peter which commit solved the problem and I'm waiting for a 
response from him. While waiting for his response, I looked at the 
1.7.2 release commits at 
https://github.com/phaag/nfdump/compare/v1.7.2...master and saw this line:


Update nfprofile:
phaag committed on May 5
https://github.com/phaag/nfdump/commit/18a34c16b6d070323d3d44cb22af48a85ac9b0c5

But I can't tell you exactly if it was this commit that solved the 
problem.


Have you tested with the plain 1.7.2 release and it was still broken? So 
the commit that fixes _your_ issue was introduced after 1.7.2 has been 
released?


The commit you mention is quite intrusive (a lot of source cleanup mixed 
with the bugfix) and does not apply to 1.7.1


patching file src/lib/nffile.c
Hunk #2 FAILED at 39.
Hunk #3 succeeded at 50 (offset -1 lines).
Hunk #4 succeeded at 180 (offset -6 lines).
Hunk #5 succeeded at 210 (offset -6 lines).
Hunk #6 succeeded at 233 (offset -6 lines).
Hunk #7 succeeded at 256 (offset -6 lines).
Hunk #8 succeeded at 285 (offset -6 lines).
Hunk #9 succeeded at 318 (offset -6 lines).
Hunk #10 FAILED at 890.
Hunk #11 succeeded at 911 (offset -4 lines).
2 out of 11 hunks FAILED
patching file src/nfdump/nfdump.c
patching file src/nfsen/nfprofile.c
Hunk #1 succeeded at 100 (offset 1 line).
Hunk #2 succeeded at 122 (offset 1 line).
Hunk #3 succeeded at 164 (offset 1 line).
Hunk #4 succeeded at 176 (offset 1 line).
Hunk #5 succeeded at 191 (offset 1 line).
Hunk #6 succeeded at 205 (offset 1 line).
Hunk #7 succeeded at 218 (offset 1 line).
Hunk #8 succeeded at 244 (offset 1 line).
Hunk #9 FAILED at 292.
Hunk #10 succeeded at 317 (offset 1 line).
1 out of 10 hunks FAILED
patching file src/nfsen/profile.c

There are so many code changes between 1.7.1 and this commit that I 
would feel _very_ uncomfortable beating this specific commit into applying.


Bernhard

Bug#1041349: transition: linphone-stack

[Bernhard Schmidt]

Control: block -1 by 1026042

Am 27.07.23 um 00:33 schrieb Sebastian Ramacher:

Control: tags -1 confirmed

On 2023-07-17 21:38:47 +0200, Bernhard Schmidt wrote:

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

Hi,

I would like to upload a new release of the linphone-stack to unstable.


Please go ahead.


Stack has been uploaded and built on almost all architectures (except 
for riscv64)


We need a rebuild of src:libosmo-abis against the new version of libortp 
and trx will be removed, see Bug#1026042


Bernhard

Bug#1042535: Acknowledgement (nfdump doesn't work with profiles using nfsen 1.3.9)

[Bernhard Schmidt]

Hi Marcelo,


Just to complement, using the recent version of nfdump from github, the 
bug does not occur.


Thanks for the report. Do you by any chance know which exact commit 
fixes this issue? Is the fix in 1.7.2 or post-1.7.2 (only in git master)?


I can update unstable to 1.7.2 or even the latest git snapshot, but I 
need a specific commit to backport the fix to bullseye.


Bernhard

Bug#1026042: trx: License is incompatible with that of up-coming ortp 5.2.0

[Bernhard Schmidt]

Control: severity -1 serious

On 08/02/23 08:55 AM, Kyle Robbertze wrote:

Hi Kyle,

> > With the recently released version 5.2 ortp has been relicensed to GNU
> > AGPL-3+.  Since your package is GPL-2 it is my understanding that it
> > may not link in ortp 5.2 until it is relicensed to either GPL-3 or
> > AGPL-3.
> As there has not been any development upstream in several years, I think we
> will need to remove trx from Debian once the new ortp version is released.

ortp 5.2 has now been uploaded to unstable. 

Bernhard

Bug#1041349: transition: linphone-stack

[Bernhard Schmidt]

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

Hi,

I would like to upload a new release of the linphone-stack to unstable.

It consists of a number of packages that have been staged in experimental

  bctoolbox
  belr
  bcmatroska2
  bzrtp
  ortp
  belcard
  belle-sip
  lime
  mediastreamer2
  linphone
  linphone-desktop

The only external hit will be on src:trx which is not compatible with the new
license. The maintainer has agreed for it to be removed in #1026042. Other than
that the linphone stack is self-contained these days.

It will fix two RC bugs in unstable (ftbfs with GCC-13).

Automatic transition trackers for some of the libraries involved are

https://release.debian.org/transitions/html/auto-belle-sip.html
https://release.debian.org/transitions/html/auto-linphone.html
https://release.debian.org/transitions/html/auto-mediastreamer2.html
https://release.debian.org/transitions/html/auto-bzrtp.html

Bernhard

Bug#1041303: inadyn: /etc/ppp/ip-up.d/inadyn fails with "unrecognized option '--iterations'"

[Bernhard Geier]

Package: inadyn
Version: 2.10.0-1
Severity: important

Dear Maintainer,

the script /etc/ppp/ip-up.d/inadyn calls inadyn with option "--iterations".

inadyn does not support this option, so the script fails and the dynamic DNS
service does not get the new IP address.


-- System Information:
Debian Release: 12.0
  APT prefers stable-security
  APT policy: (992, 'stable-security'), (991, 'stable-updates'), (990, 
'stable'), (500, 'oldstable-updates'), (500, 'oldstable-security'), (500, 
'oldstable'), (240, 'testing'), (220, 'unstable'), (200, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-0.deb11.7-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages inadyn depends on:
ii  adduser  3.134
ii  init-system-helpers  1.65.2
ii  libc62.36-9
ii  libconfuse2  3.3-3
ii  libgnutls30  3.7.9-2
ii  libnettle8   3.8.1-2
ii  sysvinit-utils   3.06-4

inadyn recommends no packages.

inadyn suggests no packages.

-- Configuration Files:
/etc/inadyn.conf [Errno 13] Keine Berechtigung: '/etc/inadyn.conf'

-- no debconf information

Bug#1039695: libtracker-sparql-3.0-0: keeps segfaulting and restarting endlessly

[Bernhard Übelacker]

Hell Mulas,
I tried to get to the source line of you dmesg output:



[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 
7fff0ca38e10 error 4 in 
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, 
socket 0)
[254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 
24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 
c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb



I think this relates to this source line:

https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050

g_critical ("Could not set up interface : %s",
error->message);


But a full backtrace is probably still needed by the maintainer.
You could probably collect one by installing systemd-coredump.
Then journalctl should contain a more detailed information on
which functions are involved.

Kind regards,
Bernhard



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

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




[254868.778098] tracker-miner-f[1916712]: segfault at 8 ip 7f9bf641bc18 sp 
7fff0ca38e10 error 4 in 
libtracker-sparql-3.0.so.0.402.0[7f9bf63f9000+6a000] likely on CPU 2 (core 2, 
socket 0)
[254868.778109] Code: 18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 
8b 44 24 10 48 8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 
08 31 c0 e8 5d de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb



echo -n "find /b ..., ..., 0x" && \
echo "18 64 48 2b 04 25 28 00 00 00 75 35 48 83 c4 20 5b c3 48 8b 44 24 10 48 
8d 15 84 dd 04 00 be 08 00 00 00 48 8d 3d fd 77 04 00 <48> 8b 48 08 31 c0 e8 5d 
de fd ff 48 8b 7c 24 10 e8 03 da fd ff eb" \
 | sed 's/[<>]//g' | sed 's/ /, 0x/g'
#





apt install gdb tracker-miner-fs tracker-miner-fs-dbgsym 
libtracker-sparql-3.0-0-dbgsym



gdb -q --args /usr/libexec/tracker-miner-fs-3

set width 0
set pagination off
tb main
run

pipe info share | grep libtracker-sparql-3.0

find /b 0x77b4e120,  0x77bb49f2, 0x18, 0x64, 0x48, 0x2b, 0x04, 
0x25, 0x28, 0x00, 0x00, 0x00, 0x75, 0x35, 0x48, 0x83, 0xc4, 0x20, 0x5b, 0xc3, 
0x48, 0x8b, 0x44, 0x24, 0x10, 0x48, 0x8d, 0x15, 0x84, 0xdd, 0x04, 0x00, 0xbe, 
0x08, 0x00, 0x00, 0x00, 0x48, 0x8d, 0x3d, 0xfd, 0x77, 0x04, 0x00, 0x48, 0x8b, 
0x48, 0x08, 0x31, 0xc0, 0xe8, 0x5d, 0xde, 0xfd, 0xff, 0x48, 0x8b, 0x7c, 0x24, 
0x10, 0xe8, 0x03, 0xda, 0xfd, 0xff, 0xeb

b * (0x77b6dbee + 42)

(gdb) info b
Num Type   Disp Enb AddressWhat
2   breakpoint keep y   0x77b6dc18 in setup_interface_cb at 
../src/libtracker-sparql/core/tracker-data-manager.c:4050
(gdb) disassemble /r 0x77b6dbee, 0x77b6dbee + 62
Dump of assembler code from 0x77b6dbee to 0x77b6dc2c:
   0x77b6dbee :  18 64 48 2b sbb
%ah,0x2b(%rax,%rcx,2)
   0x77b6dbf2 :  04 25   add
$0x25,%al
   0x77b6dbf4 :  28 00   sub
%al,(%rax)
   0x77b6dbf6 :  00 00   add
%al,(%rax)
   0x77b6dbf8 :  75 35   jne
0x77b6dc2f 
   0x77b6dbfa :  48 83 c4 20 add
$0x20,%rsp
   0x77b6dbfe :  5b  pop
%rbx
   0x77b6dbff :  c3  ret
   0x77b6dc00 :  48 8b 44 24 10  mov
0x10(%rsp),%rax
   0x77b6dc05 : 48 8d 15 84 dd 04 00lea
0x4dd84(%rip),%rdx# 0x77bbb990
   0x77b6dc0c : be 08 00 00 00  mov
$0x8,%esi
   0x77b6dc11 : 48 8d 3d fd 77 04 00lea
0x477fd(%rip),%rdi# 0x77bb5415
>>>0x77b6dc18 : 48 8b 48 08 mov
>>>0x8(%rax),%rcx
   0x77b6dc1c : 31 c0   xor
%eax,%eax
   0x77b6dc1e : e8 5d de fd ff  call   
0x77b4ba80 
   0x77b6dc23 : 48 8b 7c 24 10  mov
0x10(%rsp),%rdi
   0x77b6dc28 : e8 03 da fd ff  call   
0x77b4b630 
End of assembler dump.


https://sources.debian.org/src/tracker/3.4.2-3/src/libtracker-sparql/core/tracker-data-manager.c/#L4050

g_critical ("Could not set up interface : %s",
error->message);

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#1037481: Bug #1037481: outguess: Stack smashing detected and SIGABRT during finding of best embedding

[Bernhard Übelacker]

Hello,
just tried to get some more information where this stack smashing happens.

The stack canary gets at least overwritten here:

165 memmove(detect + n + 1, detect + n,
166 (j - n) * sizeof(int));

The variable detect has a size of 12.
The parameter to memove is the second element,
therefore the size parameter to memove should be <= 8.

But actually the size parameter to memove is 12,
therefore memove writes beyond the variable detect.

Attached file shows some debugging attempts.

Kind regards,
Bernhard

# 2023-07-11 bookworm/stable amd64 qemu VM

apt update
apt dist-upgrade

apt install systemd-coredump gdb rr valgrind outguess outguess-dbgsym
apt build-dep outguess



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





benutzer@debian:~$ wget -q 
https://upload.wikimedia.org/wikipedia/commons/3/3f/JPEG_example_flower.jpg
benutzer@debian:~$ echo msg1 > msg1.txt
benutzer@debian:~$ echo msg2 > msg2.txt
benutzer@debian:~$ outguess -k "key1" -d msg1.txt -E -K "key2" -D msg2.txt -p 
100 JPEG_example_flower.jpg JPEG_example_flower.steg.jpg
Initialize encoding/decoding tables
Reading JPEG_example_flower.jpg
JPEG compression quality set to 100
Extracting usable bits:   70325 bits
Correctable message size: 17434 bits, 24.79%
Encoded 'msg1.txt': 40 bits, 5 bytes
Finding best embedding...
0:33(45.8%)[82.5%], bias28(0.85), saved:-1, total:  0.05%
1:28(38.9%)[70.0%], bias25(0.89), saved:-1, total:  0.04%
6:30(42.3%)[75.0%], bias19(0.63), saved:-1, total:  0.04%
   11:28(38.9%)[70.0%], bias13(0.46), saved:-1, total:  0.04%
11, 41: Embedding data: 40 in 70325
Bits embedded: 72, changed: 28(38.9%)[70.0%], bias: 13, tot: 68673, skip: 68601
Encoded 'msg2.txt' with ECC: 96 bits, 12 bytes
Finding best embedding...
*** stack smashing detected ***: terminated
Abgebrochen (Speicherabzug geschrieben)


cd /home/benutzer/source/outguess/orig/outguess-0.4

coredumpctl list
TIME  PID  UID  GID SIG COREFILE EXE
 SIZE
Tue 2023-07-11 10:00:02 CEST 1136 1000 1000 SIGABRT present  /usr/bin/outguess 
412.4K

coredumpctl gdb --debugger-argument=-q 1136

(gdb) bt
#0  __pthread_kill_implementation (threadid=, 
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1  0x7f83ca05bd2f in __pthread_kill_internal (signo=6, threadid=) at ./nptl/pthread_kill.c:78
#2  0x7f83ca00cef2 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/posix/raise.c:26
#3  0x7f83c9ff7472 in __GI_abort () at ./stdlib/abort.c:79
#4  0x7f83ca0502d0 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x7f83ca16a210 "*** %s ***: terminated\n") at 
../sysdeps/posix/libc_fatal.c:155
#5  0x7f83ca0e8e82 in __GI___fortify_fail (msg=msg@entry=0x7f83ca16a1f8 
"stack smashing detected") at ./debug/fortify_fail.c:26
#6  0x7f83ca0e8e60 in __stack_chk_fail () at ./debug/stack_chk_fail.c:24
#7  0x5627c3781422 in steg_adjust_errors 
(bitmap=bitmap@entry=0x7ffda38f0c30, flags=flags@entry=8) at 
./src/outguess.c:187
#8  0x5627c37814ba in steg_embedchunk (bitmap=bitmap@entry=0x7ffda38f0c30, 
iter=iter@entry=0x7ffda38f0670, data=0, bits=1, bits@entry=8, 
embed=embed@entry=8) at ./src/outguess.c:206
#9  0x5627c3781aa8 in steg_embed (bitmap=bitmap@entry=0x7ffda38f0c30, 
iter=iter@entry=0x7ffda38f0670, as=as@entry=0x7ffda38f0560, 
data=data@entry=0x5627c4d96b30 "BU\026\330E\315>ۆL\260\246\203\177", 
datalen=datalen@entry=12, seed=seed@entry=0, embed=8) at ./src/outguess.c:285
#10 0x5627c3781e44 in steg_find (bitmap=bitmap@entry=0x7ffda38f0c30, 
iter=iter@entry=0x7ffda38f0a30, as=as@entry=0x7ffda38f0810, siter=, siterstart=, data=data@entry=0x5627c4d96b30 
"BU\026\330E\315>ۆL\260\246\203\177", datalen=12, flags=8) at 
./src/outguess.c:444
#11 0x5627c3782a04 in do_embed (bitmap=bitmap@entry=0x7ffda38f0c30, 
filename=filename@entry=0x7ffda38f16ec "msg2.txt", key=key@entry=0x7ffda38f0fe0 
"key2", klen=, cfg=cfg@entry=0x7ffda38f0c24, 
result=result@entry=0x7ffda38f0c08) at ./src/outguess.c:719
#12 0x5627c3780d12 in main (argc=, argv=0x7ffda38f1488) at 
./src/outguess.c:1025

(gdb) up
#7  0x5627c3781422 in steg_adjust_errors 
(bitmap=bitmap@entry=0x7ffda38f0c30, flags=flags@entry=8) at 
./src/outguess.c:187
187 }

(gdb) list 138, 188
138 void
139 steg_adjust_errors(bitmap *bitmap, int flags)
140 {
141 int i, j, n, many, flag;
142 int priority[ERRORBITS], detect[ERRORBITS];
143
144 many = ERRORBITS - steg_errors;
145 for (j = 0; j < many && j < steg_err_cnt; j++) {
146 priority[j] = steg_err_buf[j];
147 detect[j] = bitmap->detect[priority[j]];
148 }
149
150   

Bug#1038899: bookworm-pu: package nfdump/1.7.1-2+deb12u1

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: nfd...@packages.debian.org
Control: affects -1 + src:nfdump

[ Reason ]
This update fixes two errors reported in #1038644
- a segfault when using a particular option
- a wrong 'failed' indication in the sysvinit initscript

The segfault fix is straight forward and just an error in the option
parsing.

[ Impact ]
nfcapd cannot repeat the packets received to another receiver

[ Tests ]
The same fix has been uploaded to 1.7.1-3 in unstable and the reporter
has verified the fix.

[ Risks ]
Fairly minor risk, the option parsing change has been part of an upstream
release (but mixed with a complete rewrite of the actual repeater code, so
it cannot be cherry-picked).

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

[ Changes ]
In addition debian/gbp.conf has been changed to point to the debian/bullseye
branch.

[ Other info ]
-
diff -Nru nfdump-1.7.1/debian/changelog nfdump-1.7.1/debian/changelog
--- nfdump-1.7.1/debian/changelog   2023-01-05 12:35:34.0 +0100
+++ nfdump-1.7.1/debian/changelog   2023-06-22 22:18:53.0 +0200
@@ -1,3 +1,12 @@
+nfdump (1.7.1-2+deb12u1) bookworm; urgency=medium
+
+  * [8554dec3] Fix init script to return success when process has started.
+Thanks to Yury Shevchuk
+  * [c9d7e789] Fix segfault in getopt parsing for -R (Closes: #1038644)
+  * [eb140f97] d/gbp.conf: set debian branch
+
+ -- Bernhard Schmidt   Thu, 22 Jun 2023 22:18:53 +0200
+
 nfdump (1.7.1-2) unstable; urgency=medium
 
   * [64bef089] Add tzdata build dependency (Closes: #1027379)
diff -Nru nfdump-1.7.1/debian/gbp.conf nfdump-1.7.1/debian/gbp.conf
--- nfdump-1.7.1/debian/gbp.conf2023-01-05 12:35:34.0 +0100
+++ nfdump-1.7.1/debian/gbp.conf2023-06-22 22:18:53.0 +0200
@@ -2,7 +2,7 @@
 
 [DEFAULT]
 # the default branch for the debian patch:
-debian-branch = unstable
+debian-branch = debian/bookworm
 # use pristine-tar:
 pristine-tar = True
 
diff -Nru nfdump-1.7.1/debian/nfdump.init nfdump-1.7.1/debian/nfdump.init
--- nfdump-1.7.1/debian/nfdump.init 2023-01-05 12:35:34.0 +0100
+++ nfdump-1.7.1/debian/nfdump.init 2023-06-22 22:18:53.0 +0200
@@ -58,19 +58,27 @@
 fi
 
 local PIDFILE="$PIDDIR$INSTANCE.pid"
+# Check if process is already running
 start-stop-daemon --start --quiet \
 --pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
 || return 1
+
+# Start process
 start-stop-daemon --start --quiet \
 --pidfile "$PIDFILE" \
 --exec "$NFCAPD" -- \
 -D -P "$PIDFILE" \
 $options \
 || return 2
+
+# Wait for 1 sec and check again if process has started successfully
 sleep 1
 start-stop-daemon --start --quiet \
 --pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
 && return 2
+
+# All good, return 0
+return 0
 }
 
 # Stop a nfcapd instance
diff -Nru nfdump-1.7.1/debian/patches/fix-segfault-in-getopt.patch 
nfdump-1.7.1/debian/patches/fix-segfault-in-getopt.patch
--- nfdump-1.7.1/debian/patches/fix-segfault-in-getopt.patch1970-01-01 
01:00:00.0 +0100
+++ nfdump-1.7.1/debian/patches/fix-segfault-in-getopt.patch2023-06-22 
22:18:53.0 +0200
@@ -0,0 +1,11 @@
+--- a/src/nfcapd/nfcapd.c
 b/src/nfcapd/nfcapd.c
+@@ -605,7 +605,7 @@
+ metricSocket = NULL;
+ metricInterval = 60;
+ 
+-while ((c = getopt(argc, argv, 
"46B:b:C:DeEf:g:hI:i:jJ:l:m:M:n:p:P:rRs:S:t:T:u:vVw:x:yzZ")) != EOF) {
++while ((c = getopt(argc, argv, 
"46B:b:C:DeEf:g:hI:i:jJ:l:m:M:n:p:P:rR:s:S:t:T:u:vVw:x:yzZ")) != EOF) {
+ switch (c) {
+ case 'h':
+ usage(argv[0]);
diff -Nru nfdump-1.7.1/debian/patches/series nfdump-1.7.1/debian/patches/series
--- nfdump-1.7.1/debian/patches/series  1970-01-01 01:00:00.0 +0100
+++ nfdump-1.7.1/debian/patches/series  2023-06-22 22:18:53.0 +0200
@@ -0,0 +1 @@
+fix-segfault-in-getopt.patch

Bug#1038824: bookworm-pu: package openvpn/2.6.3-1+deb12u1

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
Tags: bookworm
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: open...@packages.debian.org
Control: affects -1 + src:openvpn

This -pu cherry-picks two fixes from upstream. One fixing a memory
leak that is noticable on long running servers, and one dangling pointer that
might lead to crashes. Both have been in 2.6.3-2 for about a month now,
migrated to testing flawlessly and are part of the recent upstream stable
release. 

There is nothing else in 2.6.3-2 that is not suitable for bookworm, I have just
changed the version and set the correct branch in gbp.conf

[ Reason ]
Bugfix

[ Impact ]
Memory leak

[ Tests ]
Upstream has an extensive testsuite/CI coverage. Part of it is ran during
build.

[ Risks ]
Isolated fixes that have been vetted upstream and have been part of an upstream
release

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

Bernhard
diff -Nru openvpn-2.6.3/debian/changelog openvpn-2.6.3/debian/changelog
--- openvpn-2.6.3/debian/changelog  2023-04-13 09:19:40.0 +0200
+++ openvpn-2.6.3/debian/changelog  2023-06-21 21:41:33.0 +0200
@@ -1,3 +1,12 @@
+openvpn (2.6.3-1+deb12u1) bookworm; urgency=medium
+
+  * Cherry-pick two bugfix commits from upstream
+- Memory leak in dco_get_peer_stats_multi for Linux
+- dangling pointer passed to pkcs11-helper
+  * d/gbp.conf: set branch to bookworm
+
+ -- Bernhard Schmidt   Wed, 21 Jun 2023 21:41:33 +0200
+
 openvpn (2.6.3-1) unstable; urgency=medium
 
   * New upstream version 2.6.2
diff -Nru openvpn-2.6.3/debian/gbp.conf openvpn-2.6.3/debian/gbp.conf
--- openvpn-2.6.3/debian/gbp.conf   2023-04-13 09:19:40.0 +0200
+++ openvpn-2.6.3/debian/gbp.conf   2023-06-21 21:41:33.0 +0200
@@ -1,2 +1,3 @@
 [DEFAULT]
 pristine-tar = True
+debian-branch = debian/bookworm
diff -Nru openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch 
openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch
--- openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch   
1970-01-01 01:00:00.0 +0100
+++ openvpn-2.6.3/debian/patches/fix-dangling-pointer-in-pkcs11.patch   
2023-06-21 21:41:33.0 +0200
@@ -0,0 +1,37 @@
+From 7e4becb4cd8be7f0d5ff80cf80877ea152f99830 Mon Sep 17 00:00:00 2001
+From: Selva Nair 
+Date: Tue, 9 May 2023 13:05:17 -0400
+Subject: [PATCH] Bugfix: dangling pointer passed to pkcs11-helper
+
+Github: Fixes OpenVPN/openvpn#323
+
+Signed-off-by: Selva Nair 
+Acked-by: Gert Doering 
+Message-Id: <20230509170517.2637245-1-selva.n...@gmail.com>
+URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26640.html
+Signed-off-by: Gert Doering 
+(cherry picked from commit f4850745709c5b80ab7d09c03a86c5ceea6d10a2)
+---
+ src/openvpn/pkcs11_openssl.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/openvpn/pkcs11_openssl.c b/src/openvpn/pkcs11_openssl.c
+index eee86e17b6f..9b0ab39f9cf 100644
+--- a/src/openvpn/pkcs11_openssl.c
 b/src/openvpn/pkcs11_openssl.c
+@@ -165,6 +165,7 @@ xkey_pkcs11h_sign(void *handle, unsigned char *sig,
+ {
+ pkcs11h_certificate_t cert = handle;
+ CK_MECHANISM mech = {CKM_RSA_PKCS, NULL, 0}; /* default value */
++CK_RSA_PKCS_PSS_PARAMS pss_params = {0};
+ 
+ unsigned char buf[EVP_MAX_MD_SIZE];
+ size_t buflen;
+@@ -203,7 +204,6 @@ xkey_pkcs11h_sign(void *handle, unsigned char *sig,
+ }
+ else if (!strcmp(sigalg.padmode, "pss"))
+ {
+-CK_RSA_PKCS_PSS_PARAMS pss_params = {0};
+ mech.mechanism = CKM_RSA_PKCS_PSS;
+ 
+ if (!set_pss_params(_params, sigalg, cert))
diff -Nru 
openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch 
openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch
--- openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch  
1970-01-01 01:00:00.0 +0100
+++ openvpn-2.6.3/debian/patches/fix-memleak-in-dco_get_peer_stats_multi.patch  
2023-06-21 21:41:33.0 +0200
@@ -0,0 +1,33 @@
+From 5e8a571af165c867ccb9c4c9e6334620f42013ac Mon Sep 17 00:00:00 2001
+From: Frank Lichtenheld 
+Date: Mon, 15 May 2023 16:21:16 +0200
+Subject: [PATCH] DCO: fix memory leak in dco_get_peer_stats_multi for Linux
+
+Leaks a small amount of memory every 15s.
+
+Signed-off-by: Frank Lichtenheld 
+Acked-by: Antonio Quartulli 
+Message-Id: <20230515142116.33135-1-fr...@lichtenheld.com>
+URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg26659.html
+Signed-off-by: Gert Doering 
+(cherry picked from commit 276f7c86d70666bc2ab4e6192ef5f1dcbd6a230f)
+---
+ src/openvpn/dco_linux.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/src/openvpn/dco_linux.c b/src/open

Bug#1038644: nfdump: segfault if started with -R option

[Bernhard Schmidt]

On 19/06/23 05:25 PM, Yury Shevchuk wrote:

> # /usr/bin/nfcapd -D -P /var/run/nfcapd/default.pid -w /var/cache/nfdump -S1 
> -b 120.0.1 -p 2055 -R 127.0.0.2 2055
> Segmentation fault
> The patch (trivial) is attached.

Thanks. For the record, this is included in the much larger

https://github.com/phaag/nfdump/commit/abfab42419117add44e1ea15ad9559d265642219#diff-c95665baa1999e70e29344d1dc05f3282cd1cf7f31b47341581cd1cf81b7d062R593

in v1.7.2

> A minor change in /etc/init.d/nfdump conffile (added return 0) fixes false
> "failed!" message from "/etc/init.d/nfdump start" which appears on systems
> using sysvinit-core rather than systemd.

I really don't get what this code is supposed to do though. And I don't
want to invest much time into sysvinit.  From my understanding

start-stop-daemon --start --quiet \
--pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
|| return 1

First we run with --test. If start-stop-daemon returns zero (process not
already running) we continue, else we return 1. So far so good.

start-stop-daemon --start --quiet \
--pidfile "$PIDFILE" \
--exec "$NFCAPD" -- \
-D -P "$PIDFILE" \
$options \
|| return 2

Now we really start it. If we can do it we continue, if we can't we
return 2 (could not be started)

sleep 1
start-stop-daemon --start --quiet \
--pidfile "$PIDFILE" --exec "$NFCAPD" --test > /dev/null \
&& return 2

Now we basically test again if the daemon is already running. If it
isn't, we return 2, 

At this point we have checked that 1 second after the start the process
is still running, and can return 0.

Could you please try the just uploaded 1.7.1-3 to verify the fix for
both bugs?

Bernhard

Bug#1037281: Please add support for MediaTek MT7986 in U-Boot

[Bernhard]

Package: src:u-boot
Severity: wishlist

Hello Vagrant

I'm interested in the Router BANANA Pi R3 from Sinovoip:
https://wiki.banana-pi.org/Banana_Pi_BPI-R3

This Banana Pi has MediaTek MT7986 (Filogic 830).

Is it possible, to support this SoC within U-Boot?
In case you say, YES, I intend to buy this new BananaPi R3 Router.

Best regards and thank you for your great support
Bernhard




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

Bug#1037126: ansible-core: Patch to fix URI Module find json sub type

[Bernhard Turmann]

Am 08.06.23 um 18:37 schrieb Lee Garrett:
I acknowledge this bug, and will issue a point release update once it 
has been merged upstream.


Hello Lee,
meanwhile, upstream has merged the change also in stable-2.14, see [1].

After successful registering with salsa, I also opened a MR in 
ansible-core repo [2].


[1] https://github.com/ansible/ansible/pull/80870
[2] https://salsa.debian.org/debian/ansible-core/-/merge_requests/2

Thanks for efforts maintaining ansible in debian!

Grüße
Berni

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#1037126: ansible-core: Patch to fix URI Module find json sub type

[Bernhard Turmann]

Source: ansible-core
Source-Version: 2.14.3-1
Severity: important
Tags: fixed-upstream, patch, upstream


Dear Maintainer,
the attached patch applied in upstream commit [0] will fix ansible-core 
2.14.3-1 in Debian 12 Bookworm having an issue with the URI module 
recognizing JSON with some API endpoints correctly.


I am using this module in many tasks with the CEPH Dashboard API and 
confirm the patch is fixing it successfully. Without the patch, all 
these tasks are failing after installing a fresh Debian Bookworm.


Note:
The ansible version in Bullseye was working fine in this regard.

Upstream has an open PR [1] against stable-2.14, but not merged yet.

I would have opened a Merge Request on Salsa, but I just registered and 
waiting for approval.


[0] 
https://github.com/ansible/ansible/commit/0c7361d9acf7c8966a09f67de2a8679ef86fd856


[1] https://github.com/ansible/ansible/pull/80870

With Best Regards
Berni--- /usr/lib/python3/dist-packages/ansible/modules/uri.py	2023-03-01 21:06:21.0 +0100
+++ /tmp/uri.py	2023-06-03 16:51:49.224330090 +0200
@@ -699,7 +699,14 @@
 sub_type = 'octet-stream'
 content_encoding = 'utf-8'

-maybe_json = content_type and sub_type.lower() in JSON_CANDIDATES
+if sub_type and '+' in sub_type:
+# https://www.rfc-editor.org/rfc/rfc6839#section-3.1
+sub_type_suffix = sub_type.partition('+')[2]
+maybe_json = content_type and sub_type_suffix.lower() in JSON_CANDIDATES
+elif sub_type:
+maybe_json = content_type and sub_type.lower() in JSON_CANDIDATES
+else:
+maybe_json = False
 maybe_output = maybe_json or return_content or info['status'] not in status_code

 if maybe_output:

Bug#1036302: free(): double free detected in tcache 2 during history search

[Bernhard Übelacker]

Hello,
below is the top of a valgrind run
with dbgsym package installed.

Kind regards,
Bernhard



benutzer@debian:~$ valgrind bash
==1114== Memcheck, a memory error detector
==1114== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1114== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==1114== Command: bash
==1114==
benutzer@debian:~$ bind '"\C-p": history-search-backward'
benutzer@debian:~$ bind '"\C-n": history-search-forward'
benutzer@debian:~$

Control-P   # history-search-backward
Control-U   # unix-line-discard
Control-P   # history-search-backward
Control-U   # unix-line-discard
Control-N   # history-search-forward
Control-J   # accept-line

==1114== Invalid read of size 4
==1114==at 0x1E9D04: rl_do_undo (undo.c:186)
==1114==by 0x1EA0B4: rl_revert_line (undo.c:337)
==1114==by 0x1CD86C: readline_internal_teardown (readline.c:498)
==1114==by 0x1CEC7B: readline_internal (readline.c:734)
==1114==by 0x1CEC7B: readline (readline.c:387)
==1114==by 0x13AFE1: yy_readline_get (parse.y:1528)
==1114==by 0x13DAE0: yy_getc (parse.y:1462)
==1114==by 0x13DAE0: shell_getc (parse.y:2393)
==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402)
==1114==by 0x1440BA: yylex (parse.y:2890)
==1114==by 0x1440BA: yyparse (y.tab.c:1854)
==1114==by 0x13A5B5: parse_command (eval.c:348)
==1114==by 0x13A743: read_command (eval.c:392)
==1114==by 0x13A8F5: reader_loop (eval.c:139)
==1114==by 0x1393D8: main (shell.c:833)
==1114==  Address 0x53ba808 is 24 bytes inside a block of size 32 free'd
==1114==at 0x484317B: free (vg_replace_malloc.c:872)
==1114==by 0x1E9ABA: _rl_free_undo_list (undo.c:111)
==1114==by 0x1F03DF: _rl_free_saved_history_line (misc.c:396)
==1114==by 0x1D4286: rl_history_search_forward (search.c:647)
==1114==by 0x1CDD96: _rl_dispatch_subseq (readline.c:916)
==1114==by 0x1CE371: _rl_dispatch (readline.c:860)
==1114==by 0x1CE371: readline_internal_char (readline.c:675)
==1114==by 0x1CEC64: readline_internal_charloop (readline.c:721)
==1114==by 0x1CEC64: readline_internal (readline.c:733)
==1114==by 0x1CEC64: readline (readline.c:387)
==1114==by 0x13AFE1: yy_readline_get (parse.y:1528)
==1114==by 0x13DAE0: yy_getc (parse.y:1462)
==1114==by 0x13DAE0: shell_getc (parse.y:2393)
==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402)
==1114==by 0x1440BA: yylex (parse.y:2890)
==1114==by 0x1440BA: yyparse (y.tab.c:1854)
==1114==by 0x13A5B5: parse_command (eval.c:348)
==1114==  Block was alloc'd at
==1114==at 0x48407B4: malloc (vg_replace_malloc.c:381)
==1114==by 0x1A2C8D: xmalloc (xmalloc.c:114)
==1114==by 0x1E9A4E: alloc_undo_entry (undo.c:75)
==1114==by 0x1E9A4E: rl_add_undo (undo.c:92)
==1114==by 0x1EDB41: rl_delete_text (text.c:152)
==1114==by 0x1E8E4C: rl_kill_text (kill.c:177)
==1114==by 0x1E9466: rl_unix_line_discard (kill.c:412)
==1114==by 0x1CDD96: _rl_dispatch_subseq (readline.c:916)
==1114==by 0x1CE371: _rl_dispatch (readline.c:860)
==1114==by 0x1CE371: readline_internal_char (readline.c:675)
==1114==by 0x1CEC64: readline_internal_charloop (readline.c:721)
==1114==by 0x1CEC64: readline_internal (readline.c:733)
==1114==by 0x1CEC64: readline (readline.c:387)
==1114==by 0x13AFE1: yy_readline_get (parse.y:1528)
==1114==by 0x13DAE0: yy_getc (parse.y:1462)
==1114==by 0x13DAE0: shell_getc (parse.y:2393)
==1114==by 0x13FF5A: read_token.constprop.0 (parse.y:3402)
==1114==
==1114== Invalid read of size 4
...
==1114==
benutzer@debian:~$ exit
...
==1114== ERROR SUMMARY: 85 errors from 13 contexts (suppressed: 0 from 0)
benutzer@debian:~$

Bug#1034661: twinkle: Please update twinkle to latest release

[Bernhard Schmidt]

Control: tags -1 + patch
Control: severity -1 serious
Control: forwarded -1 
https://github.com/LubosD/twinkle/commit/da274607aa835a2735dcf9b9a7ba550910f9d03e

On 15/05/23 11:34 PM, Frédéric Brière wrote:
> On Fri, Apr 21, 2023 at 04:46:20PM +1000, Jason Lewis wrote:
> > Please can you update twinkle to the latest release version 1.10.3
> > 
> > this will at least solve https://github.com/LubosD/twinkle/issues/222
> 
> (Upstream co-maintainer speaking.)
> 
> To provide some context: the domain name once used by the original
> author to host the user manual has now been acquired by scammers
> peddling "male enhancement devices" and such.  As you can imagine, this
> is not quite what users expect to see when they click on the "Manual"
> entry in the Help menu.
> 
> This has already been fixed upstream a few years ago, but since we're
> unlikely to see a full Twinkle release in the near future, we also put
> out a single-fix 1.10.3 release for the sake of distributions, with this
> URL change being the only difference between 1.10.2 and 1.10.3.

Thanks for the heads-up. I think this is RC. And easy to fix.

If noone else steps up I'll prepare a team upload and file an unblock
request.

Bernhard

Bug#1034336: unblock: openvpn/2.6.3-1 and openvpn-dco-dkms/0.0+git20230324-1 (pre-approval)

[Bernhard Schmidt]

Control: tags -1 - moreinfo

> > in order to reduce the deviation from an upstream tag I'd like to skip
> > 2.6.2 and go for 2.6.3. Updated debdiff attached.
> 
> Please go ahead and remove the moreinfo tag once the packages are
> available in unstable.

Uploaded, accepted and built on all architectures. piuparts is clean,
the autopkgtest of openvpn-dco-dkms also ran fine. The autopkgtest for
openvpn won't run in the Debian infrastructure due to the unsupported
isolation-machine restriction.

Please unblock (and - if possible - age) both packages.

unblock openvpn/2.6.3-1
unblock openvpn-dco-dkms/0.0+git20230324-1

Bernhard


signature.asc
Description: PGP signature

Bug#1000793: bind9-dnsutils: dig command fails with "`fd > STDERR_FILENO' failed" when run from a XFCE4 desktop applet

[Bernhard Schmidt]

Control: reassign -1 xfce4-genmon-plugin
Control: tags -1 = upstream fixed-upstream patch
Control: affects -1 bind9-dnsutils
Control: forwarded -1 
https://gitlab.xfce.org/panel-plugins/xfce4-genmon-plugin/-/issues/19

Hi Cesar,

On 24/04/23 12:04 AM, Cesar Enrique Garcia Dabo wrote:
> This turned out to be a bug in xfce4-genmon-plugin. For the record, this is
> the bug report:

Thanks for following up on this. I'll reassign the bug accordingly.

Bernhard

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Bernhard Reiter]

Hi,

Am Dienstag 18 April 2023 04:55:35 schrieb Lisandro Damián Nicanor Pérez 
Meyer:
> On Mon, 17 Apr 2023 at 12:34, Bernhard Reiter  
wrote:

> > Konqueror is advertised as web browser, which means it will (offer to)
> > open URLs from different sources, e.g. when clicked from emails which
> > means external URLs and data.
>
> Same goes with KMail too :-)

not really, KMail protects against just displaying external HTML
code from mails, you need to explicitely enable it, e.g. by clicking.

> Whatever uses webengine/webkit/ has the same
> issue. Well, for as long as they are a pile of embedded code, at least
> to start with.

Only if they are exposed to unfiltered external data and having active code 
elements enabled like 

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Bernhard Reiter]

Hi Lisandro,

thanks for your response!

Am Samstag 15 April 2023 15:15:08 schrieben Sie:
> On Thu, 13 Apr 2023 at 14:15, Bernhard Reiter 
> >"qtwebengine-opensource-src No security support upstream and
> >backports not feasible, only for use on trusted content"

> If we follow that reasoning we shouldn't be shipping Plasma at all, as
> many things use Qt5's webengine.

Konqueror is advertised as web browser, which means it will (offer to)
open URLs from different sources, e.g. when clicked from emails which means
external URLs and data. 

Other components from plasma may not share the same exposure to outside
data, and thus would be less vulnerable. It seems that this would warrant
some more examination. 

If it is true that other components show the same risks, then yes, I'd say 
that we should either get the security situation changed or really do not 
ship those components by default. They may risk systems like
the dynamic loading of remote objects from java did which would be a problem 
for both Debian and upstream.

It seems to big a topic for this issue.
What would be the right place in debian to bring this up?

Thanks again,
Bernhard


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

Bug#973894: rr: Improve reproducibility

[Bernhard Übelacker]

Hello,
upstream uses now macro-prefix-map, therefore e.g.
source files using __FILE__ should no longer
contain absolute paths.

So there are still the *.S files embedding their absolute paths.
In the long run maybe dpkg-buildflags might help there [1], [2].

But there is also mentioned to "just" feed c-flags into asm-flags.
(See patch below.)
This produces from different build directories a deb file with
the same md5sum.

Kind regards,
Bernhard


[1] https://salsa.debian.org/debian/debhelper/-/merge_requests/50
[2] 
https://git.dpkg.org/cgit/dpkg/dpkg.git/commit/scripts/Dpkg/BuildFlags.pm?id=ce5af1eeb795c6fa8ce122b801930ccd7adc8516


--- rr-5.6.0.orig/CMakeLists.txt
+++ rr-5.6.0/CMakeLists.txt
@@ -50,6 +50,9 @@ configure_file(
   ${CMAKE_BINARY_DIR}/git_revision.h
 )
 
+# For reproducibility, e.g. -ffile-prefix-map

+set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} ${CMAKE_C_FLAGS}")
+
 set(FLAGS_COMMON "-D__USE_LARGEFILE64 -pthread")
 set(supports32bit true)
 set(x86ish false)

Bug#763193: kde-base: KDE Memory leak still present in jessie

[Bernhard Reiter]

As kde4libs are not in Bullseye anymore and phased out completely,
we have moved to the KDE Frameworks generation of technology.

This defect is potentially not relevant anymore as a lot of the technology is 
different now. At least it needs a new reproduction
and thus confirmation that is is still present on Bullseye or Unstable/
Testing.

My suggestion is to close the report, because there would have been more 
information meanwhile if a similar defect has shown in the last 9 years.

Leslie thanks again for reporting this problem, sorry that it could not
fixed for kde4libs based technology. (Or, by chance are you still using the 
new stuff and experiencing still such problems?)

Bug#1034364: kde-baseapps depends on konqueror which is not security maintained

[Bernhard Reiter]

Package: kde-baseapps
Version: 4:22.12.3+5.142
Severity: important

Dear Maintainers,

consider removing konqueror from the depencies of kde-baseapps.

Rationale:

kde-baseapps for version 5:111 (stable) and 5:142 (unstable) depends on
  konqueror
but konqueror depends on
  libqt5webenginecore5
source package is
  qtwebengine-opensource-src
which according to 
https://salsa.debian.org/debian/debian-security-support/-/blob/573b1a3f35208754bdf50a2af03f6c1b8c066a8b/security-support-limited
is not security maintained:
   "qtwebengine-opensource-src No security support upstream and
   backports not feasible, only for use on trusted content"

If this information is still correct,
konqueror should not be recommended or depended on
as user should by default get a system which is reasonable secure.

Thanks
Bernhard

Bug#1034317: unblock: linphone-desktop/4.4.10-3

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: linphone-desk...@packages.debian.org
Control: affects -1 + src:linphone-desktop

Please unblock package linphone-desktop

[ Reason ]
It fixes the RC bug #1033868 where you had to agree to the upstream's ToS and
privacy policy even if not using their SIP service. This has been fixed by
Dennis by backporting a patch that has been in experimental for quite some
time (but linphone 5.0 did not make the freeze)

[ Impact ]
RC bug is not fixed

[ Tests ]
Testing done by the maintainer

[ Risks ]
Code change is trivial

[ Checklist ]
  [X] all changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in testing

unblock linphone-desktop/4.4.10-3
diff -Nru linphone-desktop-4.4.10/debian/changelog 
linphone-desktop-4.4.10/debian/changelog
--- linphone-desktop-4.4.10/debian/changelog2022-11-27 18:02:24.0 
+0100
+++ linphone-desktop-4.4.10/debian/changelog2023-04-04 18:09:27.0 
+0200
@@ -1,3 +1,10 @@
+linphone-desktop (4.4.10-3) unstable; urgency=medium
+
+  * Add patch to relax needlessly strict Terms of Service dialogue
+(Closes: #1033868).
+
+ -- Dennis Filder   Tue, 04 Apr 2023 18:09:27 +0200
+
 linphone-desktop (4.4.10-2) unstable; urgency=medium
 
   * Release to unstable.
diff -Nru 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch
--- 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch
1970-01-01 01:00:00.0 +0100
+++ 
linphone-desktop-4.4.10/debian/patches/adjust-terms-of-service-barrier.patch
2023-04-04 18:09:27.0 +0200
@@ -0,0 +1,25 @@
+Description: Enable creation of third-party accounts unconditionally
+ Users should be able to do it without the need for accepting BC's
+ Terms of Use and Privacy Policy.
+Author: Dennis Filder 
+Last-Update: 2022-12-13
+--- a/linphone-app/ui/views/App/Main/Assistant/AssistantHome.qml
 b/linphone-app/ui/views/App/Main/Assistant/AssistantHome.qml
+@@ -101,7 +101,7 @@
+   
+   cellHeight: height / 2
+   cellWidth: width / 2
+-  enabled: cguCheckBox.checked
++//enabled: cguCheckBox.checked
+   
+   delegate: Item {
+   height: buttons.cellHeight
+@@ -113,7 +113,7 @@
+   margins: 
AssistantHomeStyle.buttons.spacing
+   }
+   
+-  enabled: cguCheckBox.checked && 
SettingsModel[$viewType.charAt(0).toLowerCase() + $viewType.slice(1) + 
"Enabled"]
++  enabled: $viewType=='UseOtherSipAccount' || 
(cguCheckBox.checked && SettingsModel[$viewType.charAt(0).toLowerCase() + 
$viewType.slice(1) + "Enabled"])
+   text: $text.replace('%1', 
Qt.application.name.toUpperCase())
+   
+   onClicked:{ assistant.pushView($view, $props) }
diff -Nru linphone-desktop-4.4.10/debian/patches/series 
linphone-desktop-4.4.10/debian/patches/series
--- linphone-desktop-4.4.10/debian/patches/series   2022-11-27 
18:02:24.0 +0100
+++ linphone-desktop-4.4.10/debian/patches/series   2023-04-04 
18:09:27.0 +0200
@@ -5,3 +5,4 @@
 louden-find-package.patch
 guard-codec-download.patch
 #a11y.patch
+adjust-terms-of-service-barrier.patch

Bug#990560: Some questions regarding Inodes

[Bernhard]

Hello Helge

You wrote:

>>>>>
The limiting factor is how many inodes a filesystem allows.
This depends on the "inode size" and can be specified when formatting the 
filessystem.
32-bit applications can only address 2^32-1 inodes, which is ~ 4 million.
<<<<<

2^32 is ~4 billion.
Why is ~4 million a limiting factor?
Mistake?

>>>>>
Another option is to use xfs filesystem, which tries to work around that
problem
<<<<<

I use the XFS file system at the 4TB hard drive, which is formatted with the 
32Bit OS.
This is the output for the used XFS filesystem with size ~4TB:

> FilesystemInodes IUsed IFree IUse% Mounted on
> /dev/sda1  390701632  9608 3906920241% /storage

Thank you for your support and answering my questions.
Bernhard



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

Bug#1032834: freecad: Segmentation fault while redoing

[Bernhard Übelacker]

Why isn't there a symbol package, just for some ports?


Hello Patrick,
there are symbol packages for nearly all Debian packages nowadays.
You can add the debug component [1] to be able to install the dbgsym packages,
or if you like you can just use the DEBUGINFOD_URLS environment variable [2].

Kind regards,
Bernhard

[1] https://wiki.debian.org/HowToGetABacktrace#Installing_the_debugging_symbols
[2] 
https://wiki.debian.org/HowToGetABacktrace#Automatically_loading_debugging_symbol_from_the_Internet

Bug#990560: Thanks for investigations

[Bernhard]

Hello Helge

Thanks for investigating this topic.

My very first test with i386 was in a Acer Netbook with 64GB SSD.
This failure was not shown.

If i understand it right, this failure don't happen in case, of small partition 
<1TB:
2^31*512byte=1TB.
Can you please confirm?

But this failure happens at my Banana Pi with 4TB hard drive.

So, a small partition can be a workaround until subversion/apr is compiled with 
LBA support. Correct?

Best regards and thanks for support
Bernhard

Bug#1033006: unblock: openvpn/2.6.1-1 (preapproval)

[Bernhard Schmidt]

On 25/03/23 10:17 PM, Sebastian Ramacher wrote:

> > - upload 2.6.1 from experimental to unstable, then stage 2.6.2 and the
> >   new DCO in experimental for the second review round
> > 
> > I would prefer the last option.
> 
> Let's go ahead with the last option. Please let us know once openvpn
> 2.6.1 is in unstable.

src:openvpn 2.6.1-1 is in unstable. I have cherry-picked the three most
important fixes from 2.6.2 as well (one crash, one memory-leak and one
stall due to a blocking socket)

I have also uploaded src:openvpn 2.6.2-1~exp1 and src:openvpn-dco-dkms
0.0+git20230324-1~exp1 to experimental. Those are the version I'd like
to end up in bookworm.

I have filed an internal change to get 2.6.2+dcov2 installed on our eduVPN
node next week.

Bernhard


signature.asc
Description: PGP signature

Bug#1032423: lldb-15: Bug "No module named lldb.embedded_interpreter" reappeared again in lldb-15

[Bernhard Übelacker]

Dear Maintainer,
it looks like the searched file ends up here in the current package:
  /usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/embedded_interpreter.py

But by inspecting the strace output it should probably be in this directory:
  /usr/lib/llvm-15/lib/python3/dist-packages/lldb

For a test I moved the files that way manually,
and it makes the error message go away.

Kind regards,
Bernhard



newfstatat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", 
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", 
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
newfstatat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", 
{st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0
openat(AT_FDCWD, "/usr/lib/python3/dist-packages/lldb", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
newfstatat(3, "", {st_mode=S_IFDIR|0755, st_size=4096, ...}, AT_EMPTY_PATH) = 0
getdents64(3, 0x55ab0a60fdf0 /* 5 entries */, 32768) = 160
getdents64(3, 0x55ab0a60fdf0 /* 0 entries */, 32768) = 0
close(3)= 0
write(2, "Traceback (most recent call last"..., 35Traceback (most recent call 
last):
) = 35
write(2, "  File \"\", line 1, in ", line 1, in 

) = 39
write(2, "ModuleNotFoundError: No module n"..., 65ModuleNotFoundError: No 
module named 'lldb.embedded_interpreter'
) = 65


$ ls -lisah /usr/lib/python3/dist-packages/lldb
1045401 0 lrwxrwxrwx 1 root root 44  3. Jan 20:55 
/usr/lib/python3/dist-packages/lldb -> 
../../llvm-15/lib/python3/dist-packages/lldb


$ ls -lisah /usr/lib/llvm-15/lib/python3/dist-packages/lldb
insgesamt 8,0K
674672 4,0K drwxr-xr-x 2 root root 4,0K 25. Mär 11:02 .
674671 4,0K drwxr-xr-x 3 root root 4,0K 25. Mär 11:02 ..
6747020 lrwxrwxrwx 1 root root   51  3. Jan 20:55 libLLVM-15.0.6.so.1 -> 
../../../../../x86_64-linux-gnu/libLLVM-15.0.6.so.1
6747030 lrwxrwxrwx 1 root root   51  3. Jan 20:55 libLLVM-15.so.1 -> 
../../../../../x86_64-linux-gnu/libLLVM-15.0.6.so.1
6747010 lrwxrwxrwx 1 root root   47  3. Jan 20:55 _lldb.so -> 
../../../../../x86_64-linux-gnu/liblldb-15.so.1


$ dpkg -S embedded
python3-lldb-15: 
/usr/lib/llvm-15/lib/python3.11/dist-packages/lldb/embedded_interpreter.py

Bug#1032642: iproute2: ip tunnel change ip6gre to gre crashes with stack smash

[Bernhard Übelacker]

Dear Maintainer,
I tried to find out where exactly the stack smashing takes place.
And found the ioctl SIOCCHGTUNNEL did write more than the 52 bytes
allocated in variable old_p, by that overwriting the stack canary.

Kind regards,
Bernhard


(gdb)
0x5557589f  62  {
1: x/i $pc
=> 0x5557589f :  mov%fs:0x28,%rax
(gdb)
0x555758a8  62  {
1: x/i $pc
=> 0x555758a8 :  mov%rax,0x68(%rsp)
(gdb) print/x $rax
$1 = 0xbf9b77d893accd00
(gdb) print/x $rsp + 0x68
$2 = 0x7fffea28


(gdb)
0x77e575f5  120 in ../sysdeps/unix/syscall-template.S
1: x/i $pc
=> 0x77e575f5 :syscall
2: /x *(uint64_t*)0x7fffea28 = 0xbf9b77d893accd00
(gdb) bt
#0  0x77e575f5 in ioctl () at ../sysdeps/unix/syscall-template.S:120
#1  0x55578230 in tnl_get_ioctl (basedev=0x7fffee8f "gre1", 
p=) at tunnel.c:77
#2  0x55576243 in parse_args (argc=9, argv=0x7fffec50, cmd=35315, 
p=0x7fffea70) at iptunnel.c:181
#3  0x555762fb in do_add (cmd=35315, argc=, argv=) at iptunnel.c:260
#4  0x5556258b in do_cmd (argv0=0x7fffee81 "tunnel", argc=11, 
argv=0x7fffec40) at ip.c:133
#5  0x55561fc2 in main (argc=12, argv=0x7fffec38) at ip.c:344
(gdb) stepi
0x77e575f7  120 in ../sysdeps/unix/syscall-template.S
1: x/i $pc
=> 0x77e575f7 :cmp$0xf001,%rax
2: /x *(uint64_t*)0x7fffea28 = 0x200

(gdb) print _p
$7 = (struct ip_tunnel_parm *) 0x7fffe9f0
(gdb) print sizeof(old_p)
$8 = 52
(gdb) print/x 0x7fffe9f0 + 52
$9 = 0x7fffea24

(gdb) list iptunnel.c:181
178 if (cmd == SIOCCHGTUNNEL && count == 0) {
179 struct ip_tunnel_parm old_p = {};
180
181 if (tnl_get_ioctl(*argv, _p))
182 return -1;

Bug#1033006: unblock: openvpn/2.6.1-1 (preapproval)

[Bernhard Schmidt]

On 15/03/23 04:57 PM, Bernhard Schmidt wrote:

Hi,

> The upcoming DCO change will involve a new version of src:openvpn and a new 
> version
> of src:openvpn-dco-dkms. The list of changes on the kernel side is already 
> visible
> on https://github.com/OpenVPN/ovpn-dco/commits/master .
> 
> In the past we managed to break DCO on above mentioned really heavily loaded
> OpenVPN server within a few hours. The new version is a major overhaul and 
> more
> in-line with code upstreamable in Linux, and did survive torture tests.
> 
> I know this is kind of late, but I think it would be better to include it as 
> well
> as soon as it is released because
> 
> - we cannot support the old deprecated module
> - openvpn uses DCO (of the right version) automatically and will transparently
>   fall-back to non-DCO mode if the module is not found (or the wrong version)
> - it has not been in Bullseye previously, so if we see that DCO is too 
> unstable
>   with the new version we can just drop it before the release

So, the release of 2.6.2 with the new DCO module has been done
yesterday, fixing a number of bugs already present in 2.6.0.

https://github.com/OpenVPN/openvpn/blob/release/2.6/Changes.rst

---
New control packets flow for data channel offloading on Linux. 2.6.2+
changes the way OpenVPN control packets are handled on Linux when DCO is
active, fixing the lockups observed with 2.6.0/2.6.1 under high client
connect/disconnect activity. This is an INCOMPATIBLE change and
therefore an ovpn-dco kernel module older than v0.2.20230323 (commit ID
726fdfe0fa21) will not work anymore and must be upgraded. The kernel
module was renamed to "ovpn-dco-v2.ko" in order to highlight this change
and ensure that users and userspace software could easily understand
which version is loaded. Attempting to use the old ovpn-dco with 2.6.2+
will lead to disabling DCO at runtime.
---

So I need some guidance from the release team how to proceed. I can
think of

- abandoning all of this, leading to a bookworm release using a buggy
  OpenVPN version with a DCO kernel interface that noone else uses
- update experimental to 2.6.2 and the new DCO module, then ask for a
  approval for upload to unstable (2.6.1+2.6.2) in one go
- upload 2.6.2 and the new DCO module to unstable right away
- upload 2.6.1 from experimental to unstable, then stage 2.6.2 and the
  new DCO in experimental for the second review round

I would prefer the last option.

Bernhard

Bug#1018061: pads: segfault at 3a ip

[Bernhard Übelacker]

Am 23.03.23 um 17:38 schrieb Tim McConnell:

Bernhard,
Just cause I said it was fixed this happens to show up in journalctl:
systemd-coredump[3614]: Process 1704 (pads) of user 0 dumped core.
   
   Module

libsystemd.so.0 from deb systemd-252.5-2.amd64
   Stack trace of thread 1704:
   #0 0x5600f24f6954 
print_arp_asset_screen (pads + 0x9954)
   #1 0x5600f24f66f0 
print_arp_asset (pads + 0x96f0)
   #2 0x7fdc7fdb54f6 n/a 
(libpcap.so.0.8 + 0x84f6)
   #3 0x7fdc7fdb58ec n/a 
(libpcap.so.0.8 + 0x88ec)
   #4 0x7fdc7fdbcd1d 
pcap_loop (libpcap.so.0.8 + 0xfd1d)
   #5 0x5600f24efe5b 
main_pads (pads + 0x2e5b)
   #6 0x5600f24ef47b main 
(pads + 0x247b)
   #7 0x7fdc7fbec18a 
__libc_start_call_main (libc.so.6 + 0x2718a)
   #8 0x7fdc7fbec245 
__libc_start_main_impl (libc.so.6 + 0x27245)
   #9 0x5600f24ef4b1 _start 
(pads + 0x24b1)
   ELF object binary
architecture: AMD x86-64
Mar 04 14:31:02 DebianTim systemd[1]:
systemd-coredump@0-3613-0.service: Deactivated successfully.

Well I thought it was fixed :-(



Hello Time,
are you sure that your rebuilt package is still in place?
The offsets in your new backtrace are exactly the same as
in the email from 8 Feb 2023.

We have not changed the version of the rebuilt package.
Additionally built with "-b".
Then with a "apt dist-upgrade" always
the Debian version gets reinstalled.

Sorry for not mentioning that extra care has to be taken
to hold the rebuilt package version in place.

Kind regards,
Bernhard

Bug#1032426: xsane: Help>About XSane crashes without opening a window

[Bernhard Übelacker]

On Mon, 06 Mar 2023 14:40:12 + Reuben Thomas  wrote:


If I select Help→About XSane, the application pauses for a couple of seconds
then crashes. (The changes in Ubuntu’s version are just to depend on a
different JPEG library, so I think it’s reasonable to file a bug here.)



Dear Maintainer,
I could reproduce it also with a current Bookworm/testing system.

It looks like between 0.999-6 (buster/oldstable)
and 0.999-12 (bullseye/stable) the file xsane-logo.xpm got moved
from path /usr/share/sane/xsane to /usr/share/doc/xsane-common.

Unfortunately the about dialog still constructs the old path,
does not find there the pixmap and handles this case not carefully.

A workaround is to create a symlink and the dialog shows up without crash.

Kind regards,
Bernhard



Core was generated by `xsane'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7fd785b1b665 in IA__gtk_image_set_from_pixmap (image=0x557b947ccdb0, 
pixmap=0x0, mask=0x557b9456e230) at ../../../../gtk/gtkimage.c:858
858   g_return_if_fail (mask == NULL ||

(gdb) bt
#0  0x7fd785b1b665 in IA__gtk_image_set_from_pixmap (image=0x557b947ccdb0 
[GtkImage], pixmap=0x0, mask=0x557b9456e230) at ../../../../gtk/gtkimage.c:858
#1  0x7fd785b1b83d in IA__gtk_image_new_from_pixmap 
(pixmap=pixmap@entry=0x0, mask=0x557b9456e230) at ../../../../gtk/gtkimage.c:606
#2  0x557b92ea2d1b in xsane_about_dialog (data=, 
widget=) at ./src/xsane.c:3523
#6  0x7fd785f31dbf in  
(instance=instance@entry=0x557b946d60d0, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
#3  0x7fd785f183b0 in g_closure_invoke (closure=0x557b946d88e0, 
return_value=return_value@entry=0x0, n_param_values=1, 
param_values=param_values@entry=0x7ffc72ce6750, 
invocation_hint=invocation_hint@entry=0x7ffc72ce66d0) at 
../../../gobject/gclosure.c:832
#4  0x7fd785f2b076 in signal_emit_unlocked_R 
(node=node@entry=0x557b946c4540, detail=detail@entry=0, 
instance=instance@entry=0x557b946d60d0, 
emission_return=emission_return@entry=0x0, 
instance_and_params=instance_and_params@entry=0x7ffc72ce6750) at 
../../../gobject/gsignal.c:3796
#5  0x7fd785f31bf5 in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7ffc72ce68d0) at ../../../gobject/gsignal.c:3549
#7  0x7fd785c57d94 in IA__gtk_widget_activate 
(widget=widget@entry=0x557b946d60d0 [GtkMenuItem]) at 
../../../../gtk/gtkwidget.c:5041
#8  0x7fd785b4baf5 in IA__gtk_menu_shell_activate_item (menu_shell=0x557b94544d80 
[GtkMenu], menu_item=0x557b946d60d0 [GtkMenuItem], force_deactivate=) at ../../../../gtk/gtkmenushell.c:1278
#9  0x7fd785b4be09 in gtk_menu_shell_button_release (widget=0x557b94544d80 
[GtkMenu], event=0x557b9489ca70) at ../../../../gtk/gtkmenushell.c:703
#14 0x7fd785f31dbf in  
(instance=instance@entry=0x557b94544d80, signal_id=, 
detail=detail@entry=0) at ../../../gobject/gsignal.c:3606
#10 0x7fd785b391ab in _gtk_marshal_BOOLEAN__BOXED (closure=0x557b944dfd30, 
return_value=0x7ffc72ce6be0, n_param_values=, param_values=0x7ffc72ce6c40, 
invocation_hint=, marshal_data=) at 
../../../../gtk/gtkmarshalers.c:84
#11 0x7fd785f183b0 in g_closure_invoke 
(closure=closure@entry=0x557b944dfd30, 
return_value=return_value@entry=0x7ffc72ce6be0, n_param_values=2, 
param_values=param_values@entry=0x7ffc72ce6c40, 
invocation_hint=invocation_hint@entry=0x7ffc72ce6bc0) at 
../../../gobject/gclosure.c:832
#12 0x7fd785f2b1a5 in signal_emit_unlocked_R (node=, 
detail=detail@entry=0, instance=instance@entry=0x557b94544d80, 
emission_return=emission_return@entry=0x7ffc72ce6d30, 
instance_and_params=instance_and_params@entry=0x7ffc72ce6c40) at 
../../../gobject/gsignal.c:3835
#13 0x7fd785f3142d in g_signal_emit_valist (instance=, 
signal_id=, detail=, 
var_args=var_args@entry=0x7ffc72ce6de0) at ../../../gobject/gsignal.c:3559
#15 0x7fd785c58fe4 in gtk_widget_event_internal 
(widget=widget@entry=0x557b94544d80 [GtkMenu], 
event=event@entry=0x557b9489ca70) at ../../../../gtk/gtkwidget.c:5010
#16 0x7fd785c592d5 in IA__gtk_widget_event 
(widget=widget@entry=0x557b94544d80 [GtkMenu], 
event=event@entry=0x557b9489ca70) at ../../../../gtk/gtkwidget.c:4807
#17 0x7fd785b377d4 in IA__gtk_propagate_event (widget=0x557b94544d80 
[GtkMenu], event=0x557b9489ca70) at ../../../../gtk/gtkmain.c:2503
#18 0x7fd785b37c4b in IA__gtk_main_do_event (event=0x557b9489ca70) at 
../../../../gtk/gtkmain.c:1698
#19 IA__gtk_main_do_event (event=) at 
../../../../gtk/gtkmain.c:1503
#20 0x7fd785fc0afc in gdk_event_dispatch (source=, 
callback=, user_data=) at 
../../../../../gdk/x11/gdkevents-x11.c:2425
#21 0x7fd7860f97a9 in g_main_dispatch (context=0x557b94477800) at 
../../../glib/gmain.c:3454
#22 g_main_context_dispatch (context=context@entry=0x557b94477800) at 
../../../glib/gmain.c:4172
#23 0x7fd7860f9a38 in g_main_context_iterate (context=0x557b94477800, 
block=block@entry=1, dispatch

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#1033317: unblock: linphone/5.1.65-4

[Bernhard Schmidt]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: linph...@packages.debian.org
Control: affects -1 + src:linphone

Please unblock package linphone

[ Reason ]
Two important bugs have been resolved

* Disable behind-the-scenes download of the AppImage (Closes: #1031771).
* Update documentation to highlight limitations in linphonec CLI utility
  and to properly explain how to create an initial ~/.linphonerc file
  (Closes: #1032051).

[ Impact ]
linphone will attempt to self-update by downloading a newer AppImage
version, which is upstream's preferred way of distributing linphone

The second change is documentary only and will update README.Debian and
the manpage to explain about the configuration migration logic in
linphone (CLI) vs. linphone-desktop.

[ Tests ]
No automatic tests, patches have been prepared by Dennis who has been
maintaining linphone with an excellent quality in mind.

Version has been in unstable for two weeks now

[ Risks ]
Patch has been tested and could easily be backed out if necessary

[ Checklist ]
  [x] all changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in testing

[ Other info ]
-

unblock linphone/5.1.65-4
diff -Nru linphone-5.1.65/debian/changelog linphone-5.1.65/debian/changelog
--- linphone-5.1.65/debian/changelog2023-01-21 09:21:53.0 +0100
+++ linphone-5.1.65/debian/changelog2023-03-02 20:10:59.0 +0100
@@ -1,3 +1,12 @@
+linphone (5.1.65-4) unstable; urgency=medium
+
+  * Disable behind-the-scenes download of the AppImage (Closes: #1031771).
+  * Update documentation to highlight limitations in linphonec CLI utility
+and to properly explain how to create an initial ~/.linphonerc file
+(Closes: #1032051).
+
+ -- Dennis Filder   Thu, 02 Mar 2023 20:10:59 +0100
+
 linphone (5.1.65-3) unstable; urgency=medium
 
   * Port wrappers/cpp/genwrapper.py to Python 3.11 (Closes: #1029253).
diff -Nru linphone-5.1.65/debian/linphone-cli.README.Debian 
linphone-5.1.65/debian/linphone-cli.README.Debian
--- linphone-5.1.65/debian/linphone-cli.README.Debian   1970-01-01 
01:00:00.0 +0100
+++ linphone-5.1.65/debian/linphone-cli.README.Debian   2023-03-02 
20:10:59.0 +0100
@@ -0,0 +1,24 @@
+Debian-specific information
+===
+
+linphonec by default erroneously still solely expects ~/.linphonerc to
+be present and is unaware of ~/.config/linphone/linphonerc.  To make
+linphonec use ~/.config/linphone/linphonerc invoke it with the -c
+parameter:
+
+  linphone -c $HOME/.config/linphone/linphonerc
+
+Alternatively, you can create a suitable symbolic link by running:
+
+  ln -v -s $HOME/.config/linphone/linphonerc $HOME/.linphonerc
+
+This cannot be done automatically because it might interfere with
+configuration migration logic.
+
+Also take note of the fact that the Qt-based graphical linphone
+application houses all migration logic for configuration files, chat
+logs etc.  If you have any existing such files you should run the
+graphical linphone application to ensure it is properly migrated after
+every upgrade.
+
+ -- Dennis Filder , Thu,  2 Mar 2023 19:40:11 +0100
diff -Nru linphone-5.1.65/debian/patches/disable_appimage_download.patch 
linphone-5.1.65/debian/patches/disable_appimage_download.patch
--- linphone-5.1.65/debian/patches/disable_appimage_download.patch  
1970-01-01 01:00:00.0 +0100
+++ linphone-5.1.65/debian/patches/disable_appimage_download.patch  
2023-03-02 20:10:59.0 +0100
@@ -0,0 +1,27 @@
+Description: Disable behind-the-scenes AppImage download
+ The error message is unfortunately only printed to the log, not stderr.
+Author: Dennis Filder 
+Last-Update: 2023-03-02
+Bug-Debian: https://bugs.debian.org/1031771
+Forwarded: not-needed
+--- a/coreapi/update_check.c
 b/coreapi/update_check.c
+@@ -114,6 +114,11 @@
+   return;
+   }
+ 
++  if (!getenv("LINPHONE_DO_APPIMAGE_DOWNLOAD")) {
++  bctbx_error("AppImage download disabled.  To enable it restart 
the program with the variable LINPHONE_DO_APPIMAGE_DOWNLOAD set to \"y\" in the 
environment.");
++  return;
++  }
++
+   if (version_check_url_root != NULL) {
+   belle_http_request_listener_callbacks_t belle_request_listener 
= { 0 };
+   belle_http_request_t *request;
+@@ -154,4 +159,4 @@
+   request = belle_http_request_create("GET", uri, 
belle_sip_header_create("User-Agent", linphone_core_get_user_agent(lc)), NULL);
+   belle_http_provider_send_request(lc->http_provider, request, 
update->http_listener);
+   }
+-}
+\ No newline at end of file
++}
diff -Nru linphone-5.1.65/debian/patches/fix_linphonec_manpage.patch 
linphone-5.1.65/debian/patches/fix_linphonec_manpage.patch
--- linphone-5.1.65/debian/patches/fix_linphonec_manpage.patch  1970-01-01 
01:00:00.0 +0100
+++ 

Bug#1018061: pads: segfault at 3a ip

[Bernhard Übelacker]

control: tags -1 +patch


Hello Tim,
nice to hear it helps. Therefore adding the patch tag.

Kind regards,
Bernhard



Am 21.03.23 um 17:53 schrieb Tim McConnell:

Hi Bernhard,
I believe the patch has fixed the issue. I haven't seen any messages
about psad since installing the patch.
Thanks so much for the fix & patience with me.

Bug#1031868: kde-cli-tools: kstart5 : does not return after launching command since upgrade to KDE Fralework 5.103

[Bernhard Übelacker]

Dear Maintainer,
I tried to reproduce this issue and found a difference between
a minimal Bookworm VM with just running jwm window manager and my
regular Plasma desktop.

In the minimal VM a `kstart5 kcalc` returns immediately,
while at my regular Plasma desktop it blocks until the started
application is closed.

I found in the non-blocking case `KStart::windowAdded` gets executed
and therefore `QCoreApplication::exit` is called.

This seems to be caused by having useRule to be true
in the `KStart::KStart` constructor,
and therefore the connect call is not reached.

Kind regards,
Bernhard


(rr) bt
#0  0x7ffb802b1860 in QCoreApplication::exit 
(returnCode=returnCode@entry=0) at kernel/qcoreapplication.cpp:1430
#1  0x55a5e93fd065 in KStart::windowAdded (this=0x7fff2864b760, w=6291470) 
at ./kstart/kstart.cpp:201
#2  0x7ffb802e8f4f in QtPrivate::QSlotObjectBase::call (a=0x7fff2864adc0, 
r=0x7fff2864b760, this=0x55a5e9b58230) at 
../../include/QtCore/../../src/corelib/kernel/qobjectdefs_impl.h:398
#3  doActivate (sender=0x7ffb8174a440 <(anonymous 
namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal_index=4, 
argv=0x7fff2864adc0) at kernel/qobject.cpp:3923
#4  0x7ffb802e21ef in QMetaObject::activate (sender=sender@entry=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
m=m@entry=0x7ffb81748700 , 
local_signal_index=local_signal_index@entry=1, argv=argv@entry=0x7fff2864adc0) at 
kernel/qobject.cpp:3983
#5  0x7ffb8170e522 in KWindowSystem::windowAdded (this=this@entry=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
_t1=, _t1@entry=6291470) at 
./obj-x86_64-linux-gnu/src/KF5WindowSystem_autogen/EWIEGA46WW/moc_kwindowsystem.cpp:409
#6  0x7ffb7b07363d in NETEventFilter::addClient (this=0x55a5e9b6baf0, 
w=6291470) at ./src/platforms/xcb/kwindowsystem.cpp:412
#7  0x7ffb8172ea51 in NETRootInfo::update (this=0x55a5e9b6baf0, 
properties=..., properties2=...) at ./src/platforms/xcb/netwm.cpp:2033
#8  0x7ffb7b071af7 in NETEventFilter::activate (this=) at 
./src/platforms/xcb/kwindowsystem.cpp:183
#9  KWindowSystemPrivateX11::init (this=this@entry=0x7ffb74006730, 
what=what@entry=KWindowSystemPrivateX11::INFO_BASIC) at 
./src/platforms/xcb/kwindowsystem.cpp:575
#10 0x7ffb7b071d4c in KWindowSystemPrivateX11::connectNotify 
(this=0x7ffb74006730, signal=...) at ./src/platforms/xcb/kwindowsystem.cpp:536
#11 0x7ffb8171fc35 in KWindowSystem::connectNotify (this=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
signal=...) at ./src/kwindowsystem.cpp:380
#12 0x7ffb802dea6a in QObjectPrivate::connectImpl (sender=sender@entry=0x7ffb8174a440 
<(anonymous namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, signal_index=4, 
receiver=receiver@entry=0x7fff2864b760, slot=slot@entry=0x7fff2864b670, 
slotObj=slotObj@entry=0x55a5e9b58230, type=, types=, 
senderMetaObject=) at kernel/qobject.cpp:5108
#13 0x7ffb802ded45 in QObject::connectImpl (sender=0x7ffb8174a440 <(anonymous 
namespace)::Q_QGS_g_kwmInstanceContainer::innerFunction()::holder>, 
signal=signal@entry=0x7fff2864b660, receiver=receiver@entry=0x7fff2864b760, 
slot=slot@entry=0x7fff2864b670, slotObj=0x55a5e9b58230, type=Qt::AutoConnection, types=0x0, 
senderMetaObject=) at kernel/qobject.cpp:5038
#14 0x55a5e93fc7bb in QObject::connect (type=Qt::AutoConnection, slot=(void (KStart::*)(KStart * const, 
unsigned long long)) 0x55a5e93fcfc0 , 
receiver=0x7fff2864b760, signal=(void (KWindowSystem::*)(KWindowSystem * const, unsigned long long)) 
0x7ffb8170e4e0 , sender=) at 
/usr/include/x86_64-linux-gnu/qt5/QtCore/qobject.h:268
#15 KStart::KStart (this=0x7fff2864b760) at ./kstart/kstart.cpp:78
#16 0x55a5e93fac84 in main (argc=, argv=) at 
./kstart/kstart.cpp:424


kde-cli-tools-5.27.2/kstart/kstart.cpp
62  KStart::KStart()
63  : QObject()
64  {
65  bool useRule = false;
66
67  #ifdef HAVE_X11
68  if (QX11Info::isPlatformX11()) {
69  NETRootInfo i(QX11Info::connection(), NET::Supported);
70  useRule = i.isSupported(NET::WM2KDETemporaryRules);
71  }
72  #endif
73
74  if (useRule) {
75  sendRule();
76  } else {
77  // connect to window add to get the NEW windows
78  connect(KWindowSystem::self(), ::windowAdded, this, 
::windowAdded);
79  }

Bug#1033050: amdgpu output on USB-C docking station fails (after screen suspend?)

[Bernhard Schmidt]

Package: src:linux
Version: 6.1.15-1
Severity: important

Hi,

I run a Lenovo T14s Gen2 with a Lenovo Dockingstation and two
DP-connected external displays, with KDE on Wayland.

Every few days, after an extended coffee break/lunch, I find my
previously locked session unusable. The displays stay in standby mode,
although KDE thinks they are connected and extends the workspace there.

The quickest option at this point is to open the laptop lid, switch to
the console and reboot. I have not found a way to revive the external
displays.

There is one kernel WARNING that looks related to external MST displays,
happens at the right time and matches my perceived frequency. KDE energy
settings are currently set to

blank screen after 5 minutes
suspend screen after 10 minutes

I left the desktop at 11:13, so the kernel warning happens at the same
time the screen was suspended.

Mär 16 11:18:41 badwlrz-cl99868 dbus-daemon[1807]: [system] Activating service 
name='org.kde.powerdevil.backlighthelper' requested by ':1.239' (uid=1176730394 
pid=28764 comm="/usr/lib/x86_64-linux-gnu/libexec/org_kde_powerdev") (using >
Mär 16 11:18:41 badwlrz-cl99868 dbus-daemon[1807]: [system] Successfully 
activated service 'org.kde.powerdevil.backlighthelper'
Mär 16 11:23:42 badwlrz-cl99868 kernel: [ cut here ]
Mär 16 11:23:42 badwlrz-cl99868 kernel: WARNING: CPU: 3 PID: 31810 at 
drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_helpers.c:154 
fill_dc_mst_payload_table_from_drm+0x99/0x140 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel: Modules linked in: udp_diag tcp_diag 
inet_diag rpcsec_gss_krb5 nfsv4 nfs lockd grace nls_utf8 cifs cifs_arc4 
cifs_md4 dns_resolver fscache netfs ctr ccm rfcomm snd_seq_dummy snd_hrtimer 
snd_seq q>
Mär 16 11:23:42 badwlrz-cl99868 kernel:  snd_rn_pci_acp3x ucsi_acpi 
snd_acp_config snd_soc_acpi watchdog ccp typec_ucsi snd_timer snd_pci_acp3x 
roles snd rng_core soundcore typec rfkill ac joydev acpi_cpufreq serio_raw 
evdev hid_multit>
Mär 16 11:23:42 badwlrz-cl99868 kernel: CPU: 3 PID: 31810 Comm: kworker/u32:9 
Tainted: GW  6.1.0-6-amd64 #1  Debian 6.1.15-1
Mär 16 11:23:42 badwlrz-cl99868 kernel: Hardware name: LENOVO 
20XGS0N400/20XGS0N400, BIOS R1NET54W (1.24) 10/27/2022
Mär 16 11:23:42 badwlrz-cl99868 kernel: Workqueue: amdgpu_dm_hpd_rx_offloa 
dm_handle_hpd_rx_offload_work [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel: RIP: 
0010:fill_dc_mst_payload_table_from_drm+0x99/0x140 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel: Code: c1 eb 0b 83 c2 01 48 83 c1 18 39 
d6 74 1c 40 38 39 75 f0 0f b7 3d 7f 93 53 00 48 63 ca 48 8d 0c 49 66 89 7c cc 
28 39 d6 75 22 <0f> 0b eb 1e 0f b7 5a 0c 0f b7 05 60 93 53 00 48 8d 0c 76 8a 4>
Mär 16 11:23:42 badwlrz-cl99868 kernel: RSP: 0018:b1f74ce73cb0 EFLAGS: 
00010246
Mär 16 11:23:42 badwlrz-cl99868 kernel: RAX: b1f74ce73cd8 RBX: 
 RCX: 
Mär 16 11:23:42 badwlrz-cl99868 kernel: RDX:  RSI: 
 RDI: b1f74ce73d58
Mär 16 11:23:42 badwlrz-cl99868 kernel: RBP: 8d1a5d3aa000 R08: 
b1f74ce73de4 R09: 
Mär 16 11:23:42 badwlrz-cl99868 kernel: R10: 0002 R11: 
0001 R12: b1f74ce73de4
Mär 16 11:23:42 badwlrz-cl99868 kernel: R13: 8d19f39bf340 R14: 
8d19c3786540 R15: 8d1a0147cba0
Mär 16 11:23:42 badwlrz-cl99868 kernel: FS:  () 
GS:8d1c9ecc() knlGS:
Mär 16 11:23:42 badwlrz-cl99868 kernel: CS:  0010 DS:  ES:  CR0: 
80050033
Mär 16 11:23:42 badwlrz-cl99868 kernel: CR2: 559d90824354 CR3: 
4b21 CR4: 00750ee0
Mär 16 11:23:42 badwlrz-cl99868 kernel: PKRU: 5554
Mär 16 11:23:42 badwlrz-cl99868 kernel: Call Trace:
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
dm_helpers_dp_mst_write_payload_allocation_table+0x79/0xa0 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel:  core_link_disable_stream+0x2d0/0x540 
[amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
dc_link_dp_handle_link_loss+0x12e/0x160 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
dm_handle_hpd_rx_offload_work+0x12b/0x160 [amdgpu]
Mär 16 11:23:42 badwlrz-cl99868 kernel:  process_one_work+0x1c7/0x380
Mär 16 11:23:42 badwlrz-cl99868 kernel:  worker_thread+0x4d/0x380
Mär 16 11:23:42 badwlrz-cl99868 kernel:  ? rescuer_thread+0x3a0/0x3a0
Mär 16 11:23:42 badwlrz-cl99868 kernel:  kthread+0xe9/0x110
Mär 16 11:23:42 badwlrz-cl99868 kernel:  ? kthread_complete_and_exit+0x20/0x20
Mär 16 11:23:42 badwlrz-cl99868 kernel:  ret_from_fork+0x22/0x30
Mär 16 11:23:42 badwlrz-cl99868 kernel:  
Mär 16 11:23:42 badwlrz-cl99868 kernel: ---[ end trace  ]---

-- Package-specific info:
** Version:
Linux version 6.1.0-6-amd64 (debian-ker...@lists.debian.org) (gcc-12 (Debian 
12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP 
PREEMPT_DYNAMIC Debian 6.1.15-1 (2023-03-05)

** Command line:

Bug#1032039: xorg: xserver fails to recover session after locking (xfce4 / lightdm)

[Bernhard Übelacker]

Dear Maintainer,
I tried to add source line information to the Xorg backtrace:

fdd in inl at /usr/include/x86_64-linux-gnu/sys/io.h:83  
(pci_device_linux_sysfs_read32+93)
f1a in x86emuOp_in_word_AX_DX at 
../../../../../../hw/xfree86/int10/../x86emu/ops.c:10364
024 in X86EMU_exec at ../../../../../../hw/xfree86/int10/../x86emu/decode.c:135
995 in xf86ExecX86int10 at ../../../../../../hw/xfree86/int10/xf86x86emu.c:39
486 in VBESetVBEMode at ../../../../../../hw/xfree86/int10/vbe.c:473
200 in VESASetMode at ../../src/vesa.c:1247
405 in VESAEnterVT at ../../src/vesa.c:1166
127 in CMapEnterVT at ../../../../../../hw/xfree86/common/xf86cmap.c:475
e31 in xf86VTEnter at ../../../../../../hw/xfree86/common/xf86Events.c:456
243 in WakeupHandler at ../../../../dix/dixutils.c:427
6b8 in WaitForSomething at ../../../../os/WaitFor.c:210
473 in Dispatch at ../../../../dix/dispatch.c:492
6cc in dix_main at ../../../../dix/main.c:272



[ 6.584] Current Operating System: Linux keats 4.19.0-5-amd64 #1 SMP Debian 
4.19.37-6 (2019-07-18) x86_64


The used kernel version is not from current testing.
Could that be the reason why the vesa driver
gets selected at all in the first place?


Kind regards,
Bernhard