Bug#680619: nullmailer: dpkg-reconfigure corrupts IPv6 zone index in "remotes"

2023-06-09 Thread Jörg Mechnich

Pretty sure the following contraption in the postinst script is responsible:


36  echo "$RET" | sed -r -e ':a s/(\[[^]:]*):/\1=/; ta' \
37   -e 
's/[[:space:]]*:[[:space:]]*/\n/g' \
38   -e ':b s/(\[[^]=]*)=/\1:/; tb' \
39   -e 's/[][]//g' > 
/etc/nullmailer/remotes


Unfortunately I am not completely sure what happens here (and what could 
possibly removed or fixed).


Jörg


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1030609: Sluggish performance in Bookworm (and Bullseye since version 0.9.13+dfsg-2+deb11u1)

2023-02-05 Thread Jörg Mechnich

Package: x11vnc
Version: 0.9.16-8+b1

I am using VNC via SSH using x11vnc to access my remote desktop from 
home. x11vnc is called with the following arguments:



x11vnc -quiet -safer -localhost -nopw -once -display :0


Since upgrading to Debian Bookworm about half a year ago, update 
performance degraded rapidly and the following messages started showing 
up in the output from x11vnc on various events (opening of windows, 
focus changes):



PORT=5900

The VNC desktop is:  localhost:0

*** fb_push ublen NOT ZERO: -1616838418
*** fb_push ublen NOT ZERO: 932745215
*** fb_push ublen NOT ZERO: -1644826
*** fb_push ublen NOT ZERO: -1711237889
*** fb_push ublen NOT ZERO: -1711237889


The same issue has been reported by at least one other user as well in 
the Debian forums [1].


After erroneously assuming this to be caused by a patch that was 
backported to Bullseye (see [2] and [3]), it appears now to be a 
packaging bug as recompiling x11vnc locally fixes the issue.


References:

[1] https://forums.debian.net/viewtopic.php?t=153655
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027043
[3] https://github.com/LibVNC/x11vnc/issues/220


OpenPGP_signature
Description: OpenPGP digital signature


Bug#1027043: libvncserver1: 0.9.13+dfsg-2+deb11u1 make x11vnc slow. 0.9.13+dfsg-2 works fine.

2023-01-29 Thread Jörg Mechnich

I was able to fix this by removing patch


0003-rfb-increase-update-buf-size.patch


and recompiling this package, as well as x11vnc. I am guessing this 
might actually be a problem within x11vnc.



On Mon, 26 Dec 2022 23:19:31 + (UTC) Jay  wrote:

Package: libvncserver1
Version: 0.9.13+dfsg-2
Severity: normal

Dear Maintainer,

   * What led up to the situation?

I run x11vnc over a gigabit direct connection with:

x11vnc -usepw -ncache_cr -display :0 -loop -noxdamage -shared -nomodtweak -noshm

Upgrading to 0.9.13+dfsg-2+deb11u1 and then reconnecting my client caused x11vnc 
to run very slowly.  `*** fb_push ublen NOT ZERO: 3290940` appeared in the log 
very frequently.  From my logs, I had only seen this message once before, 10 
months ago.


   * What exactly did you do (or not do) that was effective (or
 ineffective)?

Ineffective: reconnecting, restarting x11vnc, or rebooting

Effective: downgrading to 0.9.13+dfsg-2 and reconnecting

   * What was the outcome of this action?

reconnecting, restarting x11vnc, or rebooting: x11vnc remained sluggish and 
`fb_push ublen NOT ZERO` continued to appear


downgrading to 0.9.13+dfsg-2 and reconnecting: went back to a usable speed

   * What outcome did you expect instead?

I did not expect a minor update to change the speed of x11vnc.

-- System Information:
Debian Release: 11.6
  APT prefers stable-security
  APT policy: (900, 'stable-security'), (900, 'stable'), (875, 'oldstable'), 
(800, 'oldoldstable'), (800, 'testing'), (700, 'oldoldstable'), (700, 
'unstable'), (600, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages libvncserver1 depends on:
ii  libc62.33-8
ii  libgcrypt20  1.8.7-6
ii  libgnutls30  3.7.1-5+deb11u2
ii  libjpeg62-turbo  1:2.0.6-4
ii  liblzo2-22.10-2
ii  zlib1g   1:1.2.11.dfsg-2+deb11u2

libvncserver1 recommends no packages.

libvncserver1 suggests no packages.



OpenPGP_signature
Description: OpenPGP digital signature


Bug#981368: xserver-xorg-video-intel: Xserver becomes unresponsive with some worloads. maybe related to video rendering

2021-02-23 Thread Jörg Mechnich

Looks like this was actually a bug in the i915 module:

https://gitlab.freedesktop.org/drm/intel/-/issues/2905

There is a linked issue #2923
"deadlock in intel_atomic_cleanup_work (kernel 5.10.5)"
that seems to fit the descriptions in this thread here.

After upgrading to a custom 5.10.17 kernel, I don't seem to experience 
the same issue anymore while still using the intel Xorg driver.


I agree that this report could be closed now.

Cheers and thanks for keeping the intel driver alive, still performs 
significantly better on my particular system than the modesetting driver!


--
Jörg Mechnich
Stellv. Abteilungsleitung Digitale Bibliotheksdienste

Universität Mannheim
Universitätsbibliothek
Schloss Schneckenhof West, SN281, 68131 Mannheim

Tel: +49 621 181-2965
E-Mail: joerg.mechn...@bib.uni-mannheim.de



OpenPGP_signature
Description: OpenPGP digital signature


Bug#981368: xserver-xorg-video-intel: Xserver becomes unresponsive with some worloads. maybe related to video rendering

2021-02-09 Thread Jörg Mechnich
I am experiencing the same issue on an older Lenovo X121e with Sandy 
Bridge graphics.


This is what I am seeing in dmesg:


[28597.592510] GpuWatchdog[4662]: segfault at 0 ip 5639c0a48107 sp 
7f8c55ac04d0 error 6 in signal-desktop[5639bd867000+53d6000]
[28597.592534] Code: 7d b7 00 79 09 48 8b 7d a0 e8 35 52 d3 fe 8b 83 00 01 00 00 85 
c0 0f 84 91 00 00 00 48 8b 03 48 89 df be 01 00 00 00 ff 50 68  04 25 00 00 
00 00 37 13 00 00 c6 05 17 bc 6f 02 01 80 7d 87 00
[28759.260907] INFO: task kworker/1:1H:161 blocked for more than 120 seconds.
[28759.260917]   Tainted: G U OE 5.10.0-3-amd64 #1 Debian 
5.10.12-1
[28759.260921] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this 
message.
[28759.260926] task:kworker/1:1Hstate:D stack:0 pid:  161 ppid: 2 
flags:0x4000
[28759.261051] Workqueue: events_highpri intel_atomic_cleanup_work [i915]
[28759.261056] Call Trace:
[28759.261069]  __schedule+0x282/0x870
[28759.261077]  schedule+0x46/0xb0
[28759.261083]  schedule_preempt_disabled+0xa/0x10
[28759.261088]  __ww_mutex_lock.constprop.0+0x209/0x750
[28759.261094]  ? newidle_balance+0x1d3/0x3c0
[28759.261192]  intel_unpin_fb_vma+0x25/0xa0 [i915]
[28759.261225]  drm_atomic_helper_cleanup_planes+0x52/0x70 [drm_kms_helper]
[28759.261321]  intel_atomic_cleanup_work+0x67/0x110 [i915]
[28759.261330]  process_one_work+0x1b6/0x350
[28759.261336]  worker_thread+0x53/0x3e0
[28759.261342]  ? process_one_work+0x350/0x350
[28759.261347]  kthread+0x11b/0x140
[28759.261352]  ? __kthread_bind_mask+0x60/0x60
[28759.261360]  ret_from_fork+0x22/0x30


Not sure, if the Signal desktop client triggers the crash or just 
crashes when it happens.


My intel driver settings:


Section "Device"
  Identifier  "Intel Graphics"
  Driver  "intel"
Option "AccelMethod"  "sna"
#Option "TearFree" "true"
EndSection




Cheers,
Jörg


On Tue, 02 Feb 2021 22:56:39 +0100 pablo joubert  wrote:

Package: xserver-xorg-video-intel
Followup-For: Bug #981368

Dear Maintainer,

I updated the kernel to linux-image-5.10.0-3-amd64 (5.10.12-1i from 2.10.9-1)
and I am not able to "reproducibly reproduce" the bug I reported a few days ago
anymore.

This report should now be closed.

Kernel version (/proc/version):
---
Linux version 5.10.0-3-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.1) #1 SMP 
Debian 5.10.12-1 (2021-01-30)

--
piti




--
Jörg Mechnich

Universität Mannheim
Universitätsbibliothek
Digitale Bibliotheksdienste | Schloss Schneckenhof West | 68131 Mannheim

Tel: +49 621 181-2965
E-Mail: joerg.mechn...@bib.uni-mannheim.de

Web: https://www.uni-mannheim.de/



OpenPGP_signature
Description: OpenPGP digital signature


Bug#954283: gzip: produces corrupt output files on armv5tel

2020-03-19 Thread Jörg Mechnich
Package: gzip
Version: 1.10-1
Severity: critical
Justification: causes serious data loss

Dear Maintainer,

the stock package from testing provides a broken gzip binary which will produce
corrupt output that fails CRC checks. Compiling the plain 1.10 sources generates
a working gzip binary.

The issue seems to be caused by

> DEB_CPPFLAGS_MAINT_APPEND := -DUNALIGNED_OK

in debian/rules. After commenting the line and rebuilding the package properly,
gzip works as expected. gzip-1.9-3 from stable obviously works as well.

Please let me know if I can assist in any way during the resolution of this 
issue.

Cheers,
Jörg

-- System Information:
Debian Release: bullseye/sid
  APT prefers testing
  APT policy: (500, 'testing'), (500, 'stable'), (100, 'unstable')
Architecture: armel (armv5tel)

Kernel: Linux 5.4.0-4-marvell
Kernel taint flags: TAINT_WARN
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gzip depends on:
ii  dpkg  1.19.7
ii  install-info  6.7.0.dfsg.2-5
ii  libc6 2.30-2

gzip recommends no packages.

Versions of packages gzip suggests:
ii  less  551-1

-- no debconf information