Bug#712594: xserver-xorg-video-radeon: Blank screen on Thinkpad R60 with ATI Radeon Mobility X1400

2024-07-01 Thread Nils Dagsson Moskopp
Package: xserver-xorg-video-radeon
Followup-For: Bug #712594
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

updating the Thinkpad R60 BIOS made modesetting with the radeon driver work;
after updating the BIOS I did not need any additional Linux cmdline options.

Lenovo Thinkpad R60 BIOS Update 2.23 CD image: file size 5273600 bytes
SHA256 e6aaf32ee8999eaeb677b2e34515d5c0edda7b5a2e3e475213456bf91932cfa7
https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/7cuj26uc.iso

Lenovo Thinkpad R60 BIOS Update 2.23 Release Notes: file size 17545 bytes
SHA256 bdb48dc1bf54b6ea26774912d56114fba15e9d6e17f19dedfa35bd5b186fed8e
https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/7cuj26us.txt

I burned the CD image to a physical CD and then booted from it to update.
I believe this bug report can be closed – should I report somewhere else?

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

VGA-compatible devices on PCI bus:
--
01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. 
[AMD/ATI] RV515/M54 [Mobility Radeon X1400] [1002:7145]

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

Contents of /etc/X11/xorg.conf.d:
-
total 4
-rw-r--r-- 1 root root 226 Jan 20  2019 90-xpra-virtual.conf

KMS configuration files:

/etc/modprobe.d/radeon-kms.conf:
  #options radeon modeset=0

Kernel version (/proc/version):
---
Linux version 5.10.0-26-686 (debian-ker...@lists.debian.org) (gcc-10 (Debian 
10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP 
Debian 5.10.197-1 (2023-09-29)

Xorg X server log files on system:
--
-rw-r--r-- 1 root root 15236 Apr 11  2019 /var/log/Xorg.1.log
-rw-r--r-- 1 nils nils 41860 Jul  1 21:40 
/home/nils/.local/share/xorg/Xorg.0.log
-rw-r--r-- 1 root root 61410 Jul  2 03:26 /var/log/Xorg.0.log

Contents of most recent Xorg X server log file (/var/log/Xorg.0.log):
-
[   217.898] 
X.Org X Server 1.20.11
X Protocol Version 11, Revision 0
[   217.898] Build Operating System: linux Debian
[   217.898] Current Operating System: Linux uff 5.10.0-26-686 #1 SMP Debian 
5.10.197-1 (2023-09-29) i686
[   217.898] Kernel command line: BOOT_IMAGE=/vmlinuz-5.10.0-26-686 
root=/dev/mapper/uff--vg-root ro acpi_sleep=nonvs
[   217.898] Build Date: 23 March 2023  10:25:56AM
[   217.898] xorg-server 2:1.20.11-1+deb11u6 (https://www.debian.org/support) 
[   217.898] Current version of pixman: 0.40.0
[   217.898]Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[   217.898] Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[   217.898] (==) Log file: "/var/log/Xorg.0.log", Time: Mon Jul  1 21:40:40 
2024
[   217.899] (==) Using config directory: "/etc/X11/xorg.conf.d"
[   217.899] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[   217.899] (==) No Layout section.  Using the first Screen section.
[   217.899] (==) No screen section available. Using defaults.
[   217.899] (**) |-->Screen "Default Screen Section" (0)
[   217.899] (**) |   |-->Monitor ""
[   217.899] (==) No monitor specified for screen "Default Screen Section".
Using a default monitor configuration.
[   217.899] (==) Automatically adding devices
[   217.899] (==) Automatically enabling devices
[   217.899] (==) Automatically adding GPU devices
[   217.899] (==) Max clients allowed: 256, resource mask: 0x1f
[   217.899] (WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
[   217.899]Entry deleted from font path.
[   217.899] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[   217.900] (==) ModulePath set to "/usr/lib/xorg/modules"
[   217.900] (II) The server relies on udev to provide the list of input 
devices.
If no devices become available, reconfigure udev or disable 
AutoAddDevices.
[   217.900] (II) Loader magic: 0x70d740
[   217.900] (II) Module ABI versions:
[   217.900]X.Org ANSI C Emulation: 0.4
[   217.900]X.Org Video Driver: 24.1
[   217.900]X.Org XInput driver : 24.1
[   217.900]X.Org Server Extension : 10.0
[   217.901] (++) using VT number 7

[   217.901] (II) systemd-logind: logind integration requires -keeptty and 
-keeptty was not provided, disabling logind integration
[   217.902] (II) xfree86: Adding drm device (/dev/dr

Bug#1071663: RFP: minetest-mod-voxelibre -- voxelibre mod for minetest

2024-05-23 Thread Nils Dagsson Moskopp
Matthias Geiger  writes:

> […]
>
> Since this is an RFP I suggest you file a different one for Mineclonia. 
> If someone decides to package either they can draw their own conclusions.

Thanks, maybe I will. I am not against packaging VoxeLibre, I just want
people to know what they are in for: An upstream that breaks things and
is not particularly receptive to approaches that don't break stuff (and
arguably that was a big reason for the Mineclonia fork event initially).


signature.asc
Description: PGP signature


Bug#1071644: Thumbnails of wallpapers missing due to incompatible python3-pil version

2024-05-22 Thread Nils Kanning

Package: hydrapaper
Version: 3.3.1-2

Hi,

in HydraPaper 3.3.1-2 running on Debian testing/trixie, the thumbnails
of wallpapers are not displayed and I get the following error:

AttributeError: module 'PIL.Image' has no attribute 'ANTIALIAS'
Exception in thread Thread-19 (af):
Traceback (most recent call last):
  File "/usr/lib/python3.11/threading.py", line 1045, in _bootstrap_inner
self.run()
  File "/usr/lib/python3.11/threading.py", line 982, in run
self._target(*self._args, **self._kwargs)
  File
"/usr/lib/python3/dist-packages/hydrapaper/wallpaper_flowbox_item.py",
line 114, in af
self.make_wallpaper_thumb(self.cache_path)
  File
"/usr/lib/python3/dist-packages/hydrapaper/wallpaper_flowbox_item.py",
line 150, in make_wallpaper_thumb
thumb.thumbnail((250, 250), Image.ANTIALIAS)

The problem appears to be that Image.ANTIALIAS was removed from
python3-pil starting at version 10.0.0 as mentioned in
https://pillow.readthedocs.io/en/stable/releasenotes/10.0.0.html#constants.
I am using python3-pil 10.3.0-2, the version currently in trixie.

There is the new HydraPaper release 3.3.2 available upstream, which
seems to fix this issue via
https://gitlab.gnome.org/GabMus/HydraPaper/-/commit/780a7a8cba48219e1226b773d426bb8fcad8a1ce.
Would it be possible to update the Debian package to this version?

Best regards,
Nils



Bug#1065427: python3-werkzeug has unnecessary libjs-jQuery dependency

2024-03-04 Thread Nils Kattenbeck
Package: python3-werkzeug
Version: 2.2.2-3

As of Version 2 of Werkzeug the jQuery dependency which was previously
used for the debugger is no longer needed. However, it is still listed
as a dependency of the Debian package. As a consequence the installed
size is nearly doubled.

It seems like the Files-Excluded setting was already updated (as
Debian used to remove the bundled jQuery version and add libjs-jQuery)
but the dependency on libjs-jQuery still exists.

Salsa commit updating the Files-Excluded:
https://salsa.debian.org/python-team/packages/python-werkzeug/-/commit/1d55463c59b821f2a9b91803994d5d7c228dc365
Upstream PR where jQuery got removed, this was shipped in v2.0.0:
https://github.com/pallets/werkzeug/pull/1857



Bug#1054547: apitrace diff script needs Python 3.8, but 3.9 is installed

2023-10-25 Thread Nils Dagsson Moskopp
Package: apitrace
Version: 9.0+repack-1+b3
Severity: normal
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

I wanted to see the help text for the apitrace “--diff-state” option:

; apitrace --diff-state --help
error: failed to execute: /usr/bin/python3.8 
/usr/bin/../lib/apitrace/scripts/jsondiff.py --help

I expected to see some help text, not an error.

My python version is 3.9.2, reported by “python --version”.
Using Python 3.9 to execute the script shows the help text:

; python3.9 /usr/bin/../lib/apitrace/scripts/jsondiff.py --hel
Usage: 
jsondiff.py [options]  

Options:
  -h, --help  show this help message and exit
  --ignore-added  ignore added state
  --keep-images   compare images


-- System Information:
Debian Release: 11.7
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages apitrace depends on:
ii  apitrace-tracers  9.0+repack-1+b3
ii  libbsd0   0.11.3-1
ii  libc6 2.31-13+deb11u6
ii  libgcc-s1 10.2.1-6
ii  libpng16-16   1.6.37-3
ii  libprocps82:3.3.17-5
ii  libsnappy1v5  1.1.8-1
ii  libstdc++610.2.1-6
ii  libwaffle-1-0 1.6.3-3
ii  libx11-6  2:1.7.2-1
ii  python3   3.9.2-3
ii  python3-pil   8.1.2+dfsg-0.3+deb11u1
ii  zlib1g1:1.2.11.dfsg-2+deb11u2

apitrace recommends no packages.

apitrace suggests no packages.

-- no debconf information


Bug#1003351: Update package to upstream version 5.0 (patches provided)

2023-06-22 Thread Nils König
Hi,

On Fri, Jun 16, 2023 at 22:01:54 +0200, Oneric wrote:
> Hi!
> 
> I’ve been considering taking over this package (if I can
> find a sponsor) now that it can be utilised by libass.
>
> On Sat, 8 Jan 2022 20:42:54 +0100 Nils König  wrote:
> > Thus I believe it would be a good idea to upgrade; patches to update
> > the Debian package to 5.0 are attached (also fixing lintian warnings).
> 
> First of all thanks for your effort. I already had a version of this
> for upstream’s 5.1 release for private use, but after looking through
> your patches adopted some bits from your version too.
> If it all goes well, how would you like to be credited?

Oh, no need to attribute anything to me. I just updated this once for
my own use and then didn't think much about it anymore. Whatever saves me
the trouble of manually building this package is welcome by me. You can
consider whatever of my work remains in the to be packaged version as CC0
or 0BSD.
In fact, given that I didn't really follow up on this
after the initial post, I’d prefer to not be listed.

> 
> > [...]
> > 
> > It appears like most packages, include a copyright declaration for debian/*
> > with past and current maintainers as copyright holders; this package does 
> > not,
> > but obviously I cannot choose a licence for someone else. If this is 
> > required,
> > what licence did/do you intend Eugene?
> 
> Just to be sure: did you receive a reply to this from Eugene (perhaps
> by accident as a private reply instead of sending to BTS)?

Unfortunately, I did not get any reply.

> Best,
> Oneric

Cheers
Nils König


signature.asc
Description: PGP signature


Bug#1035595: gl-117: Crash on exit

2023-05-05 Thread Nils Dagsson Moskopp
Package: gl-117
Version: 1.3.2-3+b1
Severity: normal
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

after the gl-117 main menu had loaded, Ipressed ESCAPE and Y, gl-117 crashed.
The last log message was “corrupted double-linked list”, followed by “abort”.

My screen was set to 1024x768 (gl-117 resolution) instead of a previous one –
so I had to manually set it back with: xrandr --output LVDS1 --mode 1400x1050

So I immediately tried it again; I got a different error message. Here it is:

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

The last “regular” message that the program printed to the terminal was this:

> Info: Pilots saved

-- System Information:
Debian Release: 11.7
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages gl-117 depends on:
ii  freeglut3   2.8.1-6
ii  gl-117-data 1.3.2-3
ii  libc6   2.31-13+deb11u6
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libgcc1 1:8.3.0-6
ii  libgl1  1.3.2-1
ii  libgl1-mesa-glx 20.3.5-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libsdl-mixer1.2 1.2.12-16+b1
ii  libsdl1.2debian 1.2.15+dfsg2-6
ii  libstdc++6  10.2.1-6

gl-117 recommends no packages.

gl-117 suggests no packages.

-- no debconf information


Bug#1034689: gl-117: Moving mouse creates lag (workaround: use software rendering)

2023-05-05 Thread Nils Dagsson Moskopp
Package: gl-117
Version: 1.3.2-3+b1
Followup-For: Bug #1034689
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

I tested gl-117 on a Thinkpad T60 and found the lag does not to occur on it;
I actually did get 60 fps almost consistently, sometimes dropping to 45 fps.

I have no idea what could make gl-117 work so much worse on newer hardware …

Here is the terminal output of “glxinfo |grep -i ' version'” on that laptop:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Version: 20.3.5
Max core profile version: 0.0
Max compat profile version: 1.4
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 2.0
OpenGL version string: 1.4 Mesa 20.3.5
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

-- System Information:
Debian Release: 11.7
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages gl-117 depends on:
ii  freeglut3   2.8.1-6
ii  gl-117-data 1.3.2-3
ii  libc6   2.31-13+deb11u6
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libgcc1 1:8.3.0-6
ii  libgl1  1.3.2-1
ii  libgl1-mesa-glx 20.3.5-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libsdl-mixer1.2 1.2.12-16+b1
ii  libsdl1.2debian 1.2.15+dfsg2-6
ii  libstdc++6  10.2.1-6

gl-117 recommends no packages.

gl-117 suggests no packages.

-- no debconf information


Bug#1034698: mm3d: Installing mm3d package installs blender, too

2023-04-22 Thread Nils Dagsson Moskopp
Package: mm3d
Version: 1.3.12-1+b1
Followup-For: Bug #1034698
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

I am fully aware that mm3d “recommends” blender, but
I do believe that this “recommendation” is in error.

Granted, both are 3D model editors. However, I have
not seen any evidence that installing blender could
improve or enhance mm3d usage in any way … does it?

The only thing I noticed is over 330 MB more data –
for a package with “Installed-Size: 3.869 kB” it is
a bit excessive to recommend an alternative program
that is about 2 orders of magnitude larger on disk.

In which version of the package is the “recommends”
field fixed? I ask because status is set to “done”.

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

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

Versions of packages mm3d depends on:
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libgl1  1.3.2-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5opengl5   5.15.2+dfsg-9
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libstdc++6  10.2.1-6

Versions of packages mm3d recommends:
pn  blender  
ii  wings3d  2.2.5-1
pn  yafray   

mm3d suggests no packages.

-- no debconf information


Bug#1034698: mm3d: Installing mm3d package installs blender, too

2023-04-21 Thread Nils Dagsson Moskopp
Package: mm3d
Severity: minor
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

“sudo apt-get install mm3d” installs mm3d – and blender, too …
I assume most users do not want blender when they ask for mm3d,
installing blender too means downloading a few hundred mb more!

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

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

Versions of packages mm3d depends on:
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libgl1  1.3.2-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
pn  libqt5opengl5   
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libstdc++6  10.2.1-6

Versions of packages mm3d recommends:
pn  blender  
ii  wings3d  2.2.5-1
pn  yafray   

mm3d suggests no packages.


Bug#1034690: barrage: Middle click does not fire small grenades

2023-04-21 Thread Nils Dagsson Moskopp
Package: barrage
Version: 1.0.5-1
Severity: important
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

I started “barrage” and clicked “Receive Briefing”.
It says to use middle click to fire small grenades.

I middle-clicked in the game, but that did nothing.

I used xev to verify that my middle clicking works;
it seems to work in every other app except barrage.

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

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

Versions of packages barrage depends on:
ii  libc62.31-13+deb11u5
ii  libsdl-mixer1.2  1.2.12-16+b1
ii  libsdl1.2debian  1.2.15+dfsg2-6

barrage recommends no packages.

barrage suggests no packages.

-- no debconf information


Bug#1034689: gl-117: Moving mouse creates lag (workaround: use software rendering)

2023-04-21 Thread Nils Dagsson Moskopp
Package: gl-117
Version: 1.3.2-3+b1
Severity: important
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

I installed and started gl-117 just now. It showed severe lag.
There was a warning shown about the rendering being too slow …

I managed to disable fullscreen mode and quit the application and started it 
again.
I found that lag only happens when the mouse cursor moves inside the gl-117 
window.

Using Mesa software rendering with “LIBGL_ALWAYS_SOFTWARE=1 gl-117” avoids the 
lag.
Here is the terminal output of “glxinfo |grep -i ' version'” on the machine I 
used:

server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
Version: 20.3.5
Max core profile version: 4.6
Max compat profile version: 4.6
Max GLES1 profile version: 1.1
Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.6 (Core Profile) Mesa 20.3.5
OpenGL core profile shading language version string: 4.60
OpenGL version string: 4.6 (Compatibility Profile) Mesa 20.3.5
OpenGL shading language version string: 4.60
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

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

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

Versions of packages gl-117 depends on:
ii  freeglut3   2.8.1-6
ii  gl-117-data 1.3.2-3
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libgl1  1.3.2-1
ii  libgl1-mesa-glx 20.3.5-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libsdl-mixer1.2 1.2.12-16+b1
ii  libsdl1.2debian 1.2.15+dfsg2-6
ii  libstdc++6  10.2.1-6

gl-117 recommends no packages.

gl-117 suggests no packages.

-- no debconf information


Bug#1034687: ardentryst: Crash when renaming existing character

2023-04-21 Thread Nils Dagsson Moskopp
Package: ardentryst
Version: 1.71-8
Severity: normal
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

when resuming a saved game you can press “Q” in the world map/overview.
You then get a menu in which you can press “R” to rename the character.
Pressing “return” after typing the new character name crashes the game.

The following text is the entire terminal output from start to a crash:

pygame 1.9.6
Hello from the pygame community. https://www.pygame.org/contribute.html
Ext.reader.Sax2 not found

---
Ardentryst v.20090726 (1.71-Comet Unstable) 1:11 PM AEST   
   by Jordan Trudgett  
---

Ardentryst Copyright (C) 2007, 2008, 2009 Jordan Trudgett
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions; for details, see the COPYING file.

An error has occurred. 
Traceback (most recent call last):
  File "/usr/share/games/ardentryst/ardentryst.py", line 4722, in 
main()
  File "/usr/share/games/ardentryst/ardentryst.py", line 4423, in main
handle_game(Game, True)
  File "/usr/share/games/ardentryst/ardentryst.py", line 2988, in handle_game
r = Ingame_Menu((screen, Data, Fonts, p1c, soundbox, ticker, Game, player, 
False))
  File "/usr/share/games/ardentryst/play_level.py", line 1588, in Ingame_Menu
sfiles = os.listdir("Saves")
FileNotFoundError: [Errno 2] No such file or directory: 'Saves'
Traceback (most recent call last):
  File "/usr/share/games/ardentryst/ardentryst.py", line 4722, in 
main()
  File "/usr/share/games/ardentryst/ardentryst.py", line 4423, in main
handle_game(Game, True)
  File "/usr/share/games/ardentryst/ardentryst.py", line 2988, in handle_game
r = Ingame_Menu((screen, Data, Fonts, p1c, soundbox, ticker, Game, player, 
False))
  File "/usr/share/games/ardentryst/play_level.py", line 1588, in Ingame_Menu
sfiles = os.listdir("Saves")
FileNotFoundError: [Errno 2] No such file or directory: 'Saves'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/share/games/ardentryst/ardentryst.py", line 4726, in 
handleException(e)
  File "/usr/share/games/ardentryst/ardentryst.py", line 685, in handleException
open("bugreport.txt", "w").write(open(os.path.join(SAVEDIRECTORY, 
"log.txt"), "r").read())
PermissionError: [Errno 13] Permission denied: 'bugreport.txt'

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

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

Versions of packages ardentryst depends on:
ii  fonts-freefont-ttf  20120503-10
ii  python3 3.9.2-3
ii  python3-future  0.18.2-5
ii  python3-pygame  1.9.6+dfsg-4+b1

ardentryst recommends no packages.

ardentryst suggests no packages.

-- no debconf information


Bug#1034686: curseofwar: package can not be uninstalled after running curseofwar binary

2023-04-21 Thread Nils Dagsson Moskopp
Package: curseofwar
Version: 1.1.8-3.1
Severity: normal
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

I ran curseofwar in an xfce4-terminal.
I then wanted to uninstall curseofwar.

Strangely, running curseofwar in terminals seems to cancel any following 
uninstall –
the “Do you want to continue?” question from apt seems to be automatically 
rejected.

Here is the full output of “LANG=C sudo apt autoremove curseofwar” in this 
scenario:

Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
  curseofwar
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 89,1 kB disk space will be freed.
Do you want to continue? [Y/n] Abort.

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

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

Versions of packages curseofwar depends on:
ii  libc62.31-13+deb11u5
ii  libncurses6  6.2+20201114-2
ii  libtinfo66.2+20201114-2

curseofwar recommends no packages.

curseofwar suggests no packages.

-- no debconf information


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

2023-04-21 Thread Nils Dagsson Moskopp
Package: glob2
Version: 0.9.4.4-5
Severity: important
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

clicking “Settings” and then clicking “Ok” in the main menu crashes glob2.
This seems to happen regardless of there being an output for sound or not.
I tried “pasuspender glob2” to see if it works, but it only hangs instead.
The full terminal output from starting “glob2” to the crash follows below:

ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5233:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM sysdefault
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5233:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM sysdefault
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5233:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM front
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.rear
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.center_lfe
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM cards.pcm.side
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5233:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM surround21
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5233:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM surround21
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_concat returned 
error: No such file or directory
ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_refer returned 
error: No such file or directory
ALSA lib conf.c:5233:(snd_config_expand) Evaluate error: No such file or 
directory
ALSA lib pcm.c:2660:(snd_pcm_open_noupdate) Unknown PCM surround40
ALSA lib confmisc.c:767:(parse_card) cannot find card '0'
ALSA lib conf.c:4745:(_snd_config_evaluate) function snd_func_card_driver 
returned error: No such file or directory
ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings
ALSA lib conf.c:4745

Bug#1034674: mm3d can not load OBJ files, corrupts IQE & SMD & D3D files on save, depending on locale

2023-04-21 Thread Nils Dagsson Moskopp
Package: mm3d
Version: 1.3.12-1+b1
Severity: grave
Tags: l10n
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

I tried to open some OBJ files with mm3d, but no 3D model was shown.
I figured out that it seems to have something to do with my locale.
I think file loading code mistakenly localizes decimal separators.

This did not work:
LC_NUMERIC=de_DE.UTF-8 mm3d tmp/sydney.obj

This did work:
LC_NUMERIC=C mm3d tmp/sydney.obj

According to this commit message I found, this is fixed in a new upstream 
version:
https://github.com/zturtleman/mm3d/commit/f00fdd5f2a27292a646a23ba34f80be50ab9844c

The commit message also warns that mm3d will corrupt IQE & SMD & D3D when 
saving …
for this reason the bug report is marked grave because this could cause data 
loss!

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

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

Versions of packages mm3d depends on:
ii  libc6   2.31-13+deb11u5
ii  libgcc-s1 [libgcc1] 10.2.1-6
ii  libgl1  1.3.2-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5opengl5   5.15.2+dfsg-9
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libstdc++6  10.2.1-6

Versions of packages mm3d recommends:
ii  blender  2.83.5+dfsg-5+deb11u1
ii  wings3d  2.2.5-1
pn  yafray   

mm3d suggests no packages.

-- no debconf information


Bug#1034649: 7kaa: Unplugging USB headset hangs 7kaa

2023-04-20 Thread Nils Dagsson Moskopp
Package: 7kaa
Version: 2.15.4p1+dfsg-1
Severity: normal
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

whenever I unplug the USB headset while 7kaa is running, it hangs.
7kaa prints a single line of output to the terminal, quoted below:

> AL lib: (EE) ALCpulsePlayback_streamStateCallback: Received stream failure!

“lsusb” outputs the following information about the USB headset:

> Bus 003 Device 017: ID 0b0e:0308 GN Netcom Jabra EVOLVE LINK

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

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

Versions of packages 7kaa depends on:
ii  7kaa-data2.15.4p1+dfsg-1
ii  libc62.31-13+deb11u5
ii  libcurl3-gnutls  7.74.0-1.3+deb11u7
ii  libenet7 1.3.13+ds-1
ii  libgcc-s110.2.1-6
ii  libopenal1   1:1.19.1-2
ii  libsdl2-2.0-02.0.14+dfsg2-3+deb11u1
ii  libstdc++6   10.2.1-6
ii  libuuid1 2.36.1-8+deb11u1

7kaa recommends no packages.

Versions of packages 7kaa suggests:
pn  7kaa-music  

-- no debconf information


Bug#1034642: naev: Crash after landing on a planet in the Qex system

2023-04-20 Thread Nils Dagsson Moskopp
Package: naev
Version: 0.8.0-1
Severity: important
X-Debbugs-Cc: nils+debian-p...@dieweltistgarnichtso.net

Dear Maintainer,

when doing the tutorial the player has to visit the Qex system,
but upon landing on a planet and taking off, the game crashes …

The output of naev in a terminal is reproduced below this line:

 Naev v0.8.0+dev (linux-x86_64)
Found ndata: /usr/share/naev/dat
 Sea of Darkness
Reached main menu
Warning: [font_makeChar] Unicode character '0xfff7eefc' not found in font! 
Using missing glyph.
Entity: line 491: parser error : Input is not proper UTF-8, indicate encoding !
Bytes: 0xBB 0x9C 0x62 0x75
  Kapilän Z. ��bung, der Melendez-Mitarbeiter, d
 ^
Entity: line 491: parser error : PCDATA invalid Char value 24
ab dir eine Anleitung, wie man es steuert, und behauptete anschli]��end, dass du
   ^
error : xmlTextWriterWriteDocCallback : XML error 9 !
I/O error : flush error
ERROR ../src/save.c:134 [save_all]: xmlw: unable to end document
abort

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

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

Versions of packages naev depends on:
ii  libc62.31-13+deb11u5
ii  libcxsparse3 1:5.8.1+dfsg-2
ii  libfreetype6 2.10.4+dfsg-1+deb11u1
ii  liblua5.1-0  5.1.5-8.1+b3
ii  libopenal1   1:1.19.1-2
ii  libpng16-16  1.6.37-3
ii  libsdl2-2.0-02.0.14+dfsg2-3+deb11u1
ii  libsdl2-mixer-2.0-0  2.0.4+dfsg1-3
ii  libvorbis0a  1.3.7-1
ii  libvorbisfile3   1.3.7-1
ii  libxml2  2.9.10+dfsg-6.7+deb11u3
ii  naev-data0.8.0-1

naev recommends no packages.

naev suggests no packages.

-- no debconf information


Bug#1022230: maliit-keyboard has a broken dependency

2022-10-22 Thread Nils Jacobs
Package: maliit-keyboard
Version: 2.2.1.1-1
Severity: important
X-Debbugs-Cc: oj002...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   updating to the newest version of maliit-keyboard in sid
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   jus trying to upgrade
   * What was the outcome of this action?
   apt failed to upgrade the package
   * What outcome did you expect instead?
   a successfull upgrade

the newest version of maliit-keyboard depends on 
qml-module-qtquick-qtgraphicaleffects which does not exist.
I think the correct package name would be qml-module-qtgraphicaleffects which 
does exist

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

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

Versions of packages maliit-keyboard depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.40.0-3
ii  libc62.35-3
ii  libchewing3  0.5.1-4
ii  libgcc-s112.2.0-7
ii  libglib2.0-0 2.74.0-3
ii  libhunspell-1.7-01.7.1-1
ii  libmaliit-plugins2   2.3.0-2
ii  libpinyin13  2.6.2-2
ii  libpresage1v50.9.1-2.3
ii  libqt5core5a 5.15.6+dfsg-2
ii  libqt5dbus5  5.15.6+dfsg-2
ii  libqt5feedback5  5.0~git20180903.a14bd0b-5
ii  libqt5gui5   5.15.6+dfsg-2
ii  libqt5multimedia55.15.6-2
ii  libqt5qml5   5.15.6+dfsg-2
ii  libqt5quick5 5.15.6+dfsg-2
ii  libstdc++6   12.2.0-7
ii  maliit-framework 2.3.0-2

maliit-keyboard recommends no packages.

maliit-keyboard suggests no packages.

-- no debconf information



Bug#1010760: closed by Debian FTP Masters (reply to Tobias Frost ) (Bug#1010760: fixed in minetest 5.6.0+dfsg+~1.9.0mt7+dfsg-1)

2022-09-19 Thread Nils Dagsson Moskopp

 says:
> upstream requires SSE3 to function properly, depend on sse3-support

The commit message seems to be wrong: Minetest uses SSE2, not SSE3.


signature.asc
Description: PGP signature


Bug#1019411: RFS: ani-cli/3.4.0-1 -- A cli to browse and watch anime (alone AND with friends).

2022-09-09 Thread Nils Wiemer

Hi,

    I have seen that there was already a package of ani-cli uploaded to 
mentors.debian.net. Sadly only after i have gone and uploaded it. I 
would go ahead and contacted the other individual who already worked on 
the package, fix the problems with the package.


Thanks for the info.

--
---
Mit freundlichen Grüßen

Nils Wiemer



Bug#1019411: RFS: ani-cli/3.4.0-1 -- A cli to browse and watch anime (alone AND with friends).

2022-09-08 Thread Nils Wiemer

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "ani-cli":

* Package name : ani-cli
Version : 3.4.0-1
Upstream Author : https://github.com/pystardust/ani-cli
* URL : https://github.com/pystardust/ani-cli
* License : GPL-3.0+
* Vcs : [fill in URL of packaging vcs]
Section : video

The source builds the following binary packages:

ani-cli - A cli to browse and watch anime (alone AND with friends).

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


https://mentors.debian.net/package/ani-cli/

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

dget -x 
https://mentors.debian.net/debian/pool/main/a/ani-cli/ani-cli_3.4.0-1.dsc


Changes for the initial release:

ani-cli (3.4.0-1) unstable; urgency=medium
.
* Closes: #888
* Closes: #883
* gogo proxy change

Regards,

--

  Nils Wiemer



Bug#1016120: kmscube does not quit on its own and inhibits switching to other TTYs, making computer unusable

2022-07-27 Thread Nils Dagsson Moskopp
Package: kmscube
Version: 0.0.0~git20210103-1
Severity: important
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

I started kmscube to test out whether kernel mode-setting would work on my 
hardware.
I saw a rotating textured cube (so KMS works), but there was no way to exit 
kmscube.

Among other things, I tried ESC, SPC and CTRL + C, but none of those exited 
kmscube.

I then tried to switch to another TTY to log in and kill kmscube. This did not 
work.
It seems that all keyboard inputs i tried were deferred until after kmscube 
exits.

I expected shortcuts like CTRL + ALT + F2 to always get me to TTY2 immediately.
I also expected kmscube to exit upon a keypress, mouse click, or after a time.

To reproduce this issue:

1. Execute ”timeout 10 kmscube” in TTY1.
2. Press CTRL + ALT + F2 as soon as you see a rotating cube.
3. Wait 10 seconds.
4. Verify that the display only switches to TTY2 after kmscube exits.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages kmscube depends on:
ii  libc6   2.31-13+deb11u3
ii  libdrm2 2.4.104-1
ii  libegl1 1.3.2-1
ii  libgbm1 20.3.5-1
ii  libgles21.3.2-1
ii  libglib2.0-02.66.8-1
ii  libgstreamer-plugins-base1.0-0  1.18.4-2
ii  libgstreamer1.0-0   1.18.4-2.1
ii  libpng16-16 1.6.37-3

kmscube recommends no packages.

kmscube suggests no packages.

-- no debconf information


Bug#1014937: stormbaancoureur: Slow/wrong rendering on Intel 945GM x86/MMX/SSE2

2022-07-15 Thread Nils Dagsson Moskopp
Package: stormbaancoureur
Version: 2.1.6-3
Followup-For: Bug #1014937
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

I haveinvestigated the source package of stormbaancoureur.

The file src-common/ogl.cxx contains the shadow rendering functionality.

It also contains a check for when exactly shadow rendering is enabled:

--- 8< --- snip --- 8< ---
/*
 * This helper function checks wether we have all req'd extensions for shadow 
mapping
 */
bool OglCanDoShadowing(void)
{
  if (getenv("PLODE_NO_SHADOWS")) return false;
  const char *vers = (const char*) glGetString(GL_VERSION);
  const char *rend = (const char*) glGetString(GL_RENDERER);
  fprintf(stderr, "OpenGL is version %s\n", vers);
  fprintf(stderr, "OpenGL renderer %s\n", rend);
  const char *exts = (const char*) glGetString(GL_EXTENSIONS);
  //fprintf(stderr, "OpenGL has extensions %s\n", exts);
  if (!strstr(exts, "GL_ARB_multitexture")) return false;
  if (!strstr(exts, "GL_ARB_depth_texture")) return false;
  if (!strstr(exts, "GL_ARB_shadow")) return false;
  if (!strstr(exts, "GL_EXT_framebuffer_object")) return false;
  if (!strstr(exts, "GL_ARB_vertex_shader")) return false;
  if (!strstr(exts, "GL_ARB_fragment_shader")) return false;
  if (!strstr(exts, "GL_ARB_shader_objects")) return false;
  return true;
}
--- >8 --- snap --- >8 ---

The Irrlicht engine manages to do bug-free realtime shadows on the same GPU.
Therefore, I assume that this issue can be worked around relatively easily.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages stormbaancoureur depends on:
ii  freeglut3   2.8.1-6
ii  libasound2  1.2.4-1.1
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
ii  libgl1  1.3.2-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libode8 2:0.16.2-1
ii  libplib11.8.5-8+deb11u1
ii  libstdc++6  10.2.1-6
ii  stormbaancoureur-data   2.1.6-3

stormbaancoureur recommends no packages.

stormbaancoureur suggests no packages.

-- no debconf information



Bug#1014937: stormbaancoureur: Slow/wrong rendering on Intel 945GM x86/MMX/SSE2

2022-07-14 Thread Nils Dagsson Moskopp
Package: stormbaancoureur
Version: 2.1.6-3
Severity: important
Tags: patch
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

when I started stormbaancoureur, it had very low FPS (about 3) in racing mode.
Additionally, the level textures looked broken – a bit like a moiré effect.

I expected the game to look non-broken and run well on my Thinkpad T60.

Using software rendering with LIBGL_ALWAYS_SOFTWARE=1 I got about 14 FPS.
In the main menu I got over 30 FPS, always, which seemed highly unusual …

I remembered the game running fine on worse hardware than I am using now.
Henwe, I tried to disable Mesa extensions by year. I found the following:

The game ran fine using: MESA_EXTENSION_MAX_YEAR=2001 stormbaancoureur 
The game was broken using: MESA_EXTENSION_MAX_YEAR=2002 stormbaancoureur

To figure out which extensions this could be i looked at glxinfo output.
It reported different extensions based on the MESA_EXTENSION_MAX_YEAR.

Here is a word-diff of the extensions between 2001 and 2002:

--- 8< --- snip --- 8< ---
@@ -61,28 +61,32 @@ OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 945GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 20.3.5
OpenGL extensions:
GL_3DFX_texture_compression_FXT1, {+GL_APPLE_packed_pixels,+} 
GL_ARB_depth_texture, {+GL_ARB_draw_buffers, GL_ARB_fragment_program, +}
{+GL_ARB_fragment_shader,+} GL_ARB_multisample, GL_ARB_multitexture, 
GL_ARB_point_parameters, {+GL_ARB_shader_objects,+} GL_ARB_shadow, 
GL_ARB_texture_border_clamp, GL_ARB_texture_compression, 
GL_ARB_texture_cube_map, GL_ARB_texture_env_add, 
GL_ARB_texture_env_combine, GL_ARB_texture_env_crossbar, 
GL_ARB_texture_env_dot3, GL_ARB_texture_mirrored_repeat, 
GL_ARB_transpose_matrix, {+GL_ARB_vertex_program, GL_ARB_vertex_shader,+} 
GL_ARB_window_pos, {+GL_ATI_draw_buffers, GL_ATI_texture_env_combine3,+} 
GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color, GL_EXT_blend_func_separate, 
GL_EXT_blend_minmax, GL_EXT_blend_subtract, GL_EXT_compiled_vertex_array, 
GL_EXT_copy_texture, GL_EXT_draw_range_elements, GL_EXT_fog_coord, 
GL_EXT_framebuffer_object, GL_EXT_multi_draw_arrays, GL_EXT_packed_pixels, 
GL_EXT_point_parameters, GL_EXT_rescale_normal, GL_EXT_secondary_color, 
GL_EXT_separate_specular_color, {+GL_EXT_shadow_funcs,+} 
GL_EXT_stencil_two_side, {+GL_EXT_stencil_wrap,+} GL_EXT_subtexture, 
GL_EXT_texture, GL_EXT_texture3D, GL_EXT_texture_compression_s3tc, 
GL_EXT_texture_cube_map, GL_EXT_texture_edge_clamp, 
GL_EXT_texture_env_add, GL_EXT_texture_env_combine, 
GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic, 
GL_EXT_texture_lod_bias, GL_EXT_texture_object, GL_EXT_vertex_array, 
GL_IBM_multimode_draw_arrays, GL_IBM_rasterpos_clip, 
GL_IBM_texture_mirrored_repeat, GL_INGR_blend_func_separate, 
{+GL_MESA_pack_invert,+} GL_MESA_window_pos, {+GL_MESA_ycbcr_texture,+} 
GL_NV_blend_square, GL_NV_light_max_exponent, GL_NV_packed_depth_stencil, 
GL_NV_texgen_reflection, GL_NV_texture_env_combine4, 
GL_NV_texture_rectangle, GL_S3_s3tc, GL_SGIS_generate_mipmap, 
GL_SGIS_texture_border_clamp, GL_SGIS_texture_edge_clamp, 
--- >8 --- snap --- >8 ---

Disabling any of th the following extensions makes the game run well:

GL_ARB_fragment_shader
GL_ARB_vertex_shader
GL_EXT_shadow_funcs

A line in the output of stormbaancoureur changed in all cases from

“This platform supports all required GL extensions to do hardware accelerated 
shadowing.”

to

“This platform does not support all required GL extensions to do hardware 
accelerated shadowing.
”

therefore it seems to me that shadow rendering is (at least partially) broken.

To make the game run well, I suggest to make it start using:

MESA_EXTENSION_OVERRIDE='-GL_EXT_shadow_funcs' stormbaancoureur

If you do not want to always disable shadows, please add a hint to the man page.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages stormbaancoureur depends on:
ii  freeglut3   2.8.1-6
ii  libasound2  1.2.4-1.1
ii  libc6   2.31-13+deb11u3
ii  libgcc-s1   10.2.1-6
ii  libgl1  1.3.2-1
ii  libglu1-mesa [libglu1]  9.0.1-1
ii  libode8 2:0.16.2-1
ii  libplib11.8.5-8+deb11u1
ii  libstdc++6  10.2.1-6
ii  stormbaancoureur-data   2.1.6-3

stormbaancoureur recommends no packages.

stormbaancoureur suggests no packages.

-- no debconf information


Bug#1014758: steam fails to install on debian sid/unstable due to to borken dependencies

2022-07-11 Thread Nils Jacobs
Package: steam
Version: 1:1.0.0.74-1
Severity: important
X-Debbugs-Cc: oj002...@gmail.com

Dear Maintainer,

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

   * What led up to the situation?
   just running apt install steam
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   I just tried to install steam
   * What was the outcome of this action?
   apt fails with the following dependency issue:
   $ sudo apt install steam
   Paketlisten werden gelesen… Fertig
   Abhängigkeitsbaum wird aufgebaut… Fertig
   Statusinformationen werden eingelesen… Fertig
   Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
   Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
   Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
   nicht erstellt wurden oder Incoming noch nicht verlassen haben.
   Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

   Die folgenden Pakete haben unerfüllte Abhängigkeiten:
   libgl1-mesa-dri:i386 : Hängt ab von: libllvm14:i386 soll aber nicht 
installiert werden
   E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene 
defekte Pakete.

   somewhat english summary: libgl1-mesa-dri:i386 depends on libllvm14:i386 but 
should not be installed 
   * What outcome did you expect instead?
   a successful installation of steam

   another way to install steam that aptitude provides:
   16) libllvm14 [1:14.0.6-1 (now, unstable) -> 1:14.0.5-1 (testing)]
   so really looks like a dependency issue with llm14
*** End of the template - remove these template lines ***


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

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

Versions of packages steam depends on:
pn  curl   
ii  debconf [debconf-2.0]  1.5.79
ii  file   1:5.41-4
ii  libc6  2.33-8
ii  libgcc-s1 [libgcc1]12.1.0-5
ii  libgl1 1.4.0-1
ii  libgl1-mesa-dri22.1.3-1
ii  libgpg-error0  1.45-2
ii  libstdc++6 12.1.0-5
ii  libudev1   251.2-8
ii  libx11-6   2:1.7.5-1
ii  libxcb-dri3-0  1.14-3
ii  libxcb11.14-3
ii  libxi6 2:1.8-1
ii  libxinerama1   2:1.1.4-3
ii  xz-utils   5.2.5-2.1

Versions of packages steam recommends:
ii  bubblewrap   0.6.2-1
ii  ca-certificates  20211016
ii  fontconfig   2.13.1-4.4
ii  fonts-liberation 1:1.07.4-11
ii  i965-va-driver [va-driver]   2.4.1+dfsg1-1
ii  intel-media-va-driver [va-driver]22.4.3+dfsg1-1
ii  konsole [x-terminal-emulator]4:22.04.1-1
ii  libasound2-plugins   1.2.7.1-1
ii  libegl1  1.4.0-1
ii  libgbm1  22.1.3-1
ii  libsdl2-2.0-02.0.22+dfsg-6
ii  libva2   2.15.0-1
ii  libxss1  1:1.2.3-1
ii  mesa-va-drivers [va-driver]  22.1.3-1
ii  mesa-vulkan-drivers  22.1.3-1
pn  steam-devices
ii  va-driver-all2.15.0-1
ii  xdg-desktop-portal   1.14.4-1
ii  xdg-desktop-portal-gtk [xdg-desktop-portal-backend]  1.14.0-1
ii  xdg-utils1.1.3-4.1
ii  xterm [x-terminal-emulator]  372-1
pn  zenity   

Versions of packages steam suggests:
pn  nvidia-driver-libs  
pn  nvidia-vulkan-icd   
ii  pipewire0.3.54-2


Bug#1004645: rc: Tab complete leads to crash on some (e.g. empty) lines

2022-06-02 Thread Nils Dagsson Moskopp
Bernhard Übelacker  writes:

> Hello Nils,
> I tried to reproduce the issue but it showed not up
> for me in a minimal Bullseye i386 VM.
>
> Therefore I guess the maintainer might need some more informations.
>
> Maybe you could try again with installing valgrind and starting rc like this:
>valgrind rc

I did this and then pressed tab on an empty line and got the following:

--- snip ---
==6292== Invalid free() / delete / delete[] / realloc()
==6292==at 0x4837867: free (in 
/usr/lib/i386-linux-gnu/valgrind/vgpreload_memcheck-x86-linux.so)
==6292==by 0x1134BF: ??? (in /usr/bin/rc.byron)
==6292==by 0x118B7C: ??? (in /usr/bin/rc.byron)
==6292==by 0x118473: ??? (in /usr/bin/rc.byron)
==6292==by 0x488B775: rl_completion_matches (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x118760: ??? (in /usr/bin/rc.byron)
==6292==by 0x488B8C2: ??? (in /lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x488BAC7: rl_complete_internal (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x488C0B8: rl_complete (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x488053A: _rl_dispatch_subseq (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x4880A56: _rl_dispatch (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x4880B3D: readline_internal_char (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==  Address 0x4b187e0 is 0 bytes inside a block of size 24 free'd
==6292==at 0x4837867: free (in 
/usr/lib/i386-linux-gnu/valgrind/vgpreload_memcheck-x86-linux.so)
==6292==by 0x1134BF: ??? (in /usr/bin/rc.byron)
==6292==by 0x118B60: ??? (in /usr/bin/rc.byron)
==6292==by 0x118473: ??? (in /usr/bin/rc.byron)
==6292==by 0x488B775: rl_completion_matches (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x118760: ??? (in /usr/bin/rc.byron)
==6292==by 0x488B8C2: ??? (in /lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x488BAC7: rl_complete_internal (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x488C0B8: rl_complete (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x488053A: _rl_dispatch_subseq (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x4880A56: _rl_dispatch (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x4880B3D: readline_internal_char (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==  Block was alloc'd at
==6292==at 0x483663B: malloc (in 
/usr/lib/i386-linux-gnu/valgrind/vgpreload_memcheck-x86-linux.so)
==6292==by 0x1133AF: ??? (in /usr/bin/rc.byron)
==6292==by 0x118660: ??? (in /usr/bin/rc.byron)
==6292==by 0x118B25: ??? (in /usr/bin/rc.byron)
==6292==by 0x118473: ??? (in /usr/bin/rc.byron)
==6292==by 0x488B775: rl_completion_matches (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x118760: ??? (in /usr/bin/rc.byron)
==6292==by 0x488B8C2: ??? (in /lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x488BAC7: rl_complete_internal (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x488C0B8: rl_complete (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x488053A: _rl_dispatch_subseq (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292==by 0x4880A56: _rl_dispatch (in 
/lib/i386-linux-gnu/libreadline.so.8.1)
==6292== 
--- snap ---

When invoked under valgrind, rc did not crash after this output.

> Or maybe running in within gdb might show a backtrace,
> maybe also setting the environment MALLOC_CHECK_=2 before
> might improve the gathered informations.
>
> Kind regards,
> Bernhard
>
> [1] https://wiki.debian.org/HowToGetABacktrace

Do I still need to do this or is the above information enough?

Thank you,
Nils



Bug#1010827: minetest: wrong find_nodes_in_area() volume calculation can crash or hang server

2022-05-10 Thread Nils Dagsson Moskopp
Package: minetest
Version: 5.3.0+repack-2.1+deb11u1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

Minetest before version 5.5.0 has an implementation of the function 
minetest.find_nodes_in_area() that can be used by clients to hang a 
server. Attached is a proof of concept Lua code to this bug report; 
you can run the “/areatest” command to crash Minetest with an error 
message that states “area volume exceeds allowed value of 4096000”.

This issue is security-relevant: It can be used by clients to crash 
or hang the server, depending on the exact coordinates given to the 
function minetest.find_nodes_in_area().

Minetest issue: <https://github.com/minetest/minetest/issues/11769>

Note that the upstream fix for this is actually faulty, as Minetest 
developers reused the constant MAX_MAP_GENERATION_LIMIT, neglegting 
that it is unsuited for bounds checking – as the map generator only 
stops after overrunning it. Basically: Minetest developers have bad 
understanding of how Minetest map generator works at map boundaries 
and are unwilling to introduce bounds checks in advance of anything 
proven to crash or hang for fear of performance losses.

Minetest patch: <https://github.com/minetest/minetest/pull/11770>

Again, the above patch is faulty and should not be applied – it has 
caused at least one other bug. which may or may not be mitigated by 
raising MAX_MAP_GENERATION_LIMIT to 31007 (I am unsure about that … 
it might be that the current version of Minetest still has issues).

Minetest bug: <https://github.com/minetest/minetest/issues/11828>

Before Minetest upstream came up with their questionable fix, I had 
come up with a fix which wraps around minetest.find_nodes_in_area() 
to prevent the crash. It is fully unit-tested, AFAIK it works 100%.

You can see the entire patch and the unit test for it here:
<https://git.minetest.land/Mineclonia/Mineclonia/pulls/169>
It is written in the form of Lua wrapper code for Minetest.

If you are unsure on how to integrate it, I can try to help.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages minetest depends on:
ii  libc6 2.31-13+deb11u3
ii  libcurl3-gnutls   7.74.0-1.3+deb11u1
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libgmp10  2:6.2.1+dfsg-1+deb11u1
ii  libirrlicht1.81.8.4+dfsg1-1.1
ii  libjsoncpp24  1.9.4-4
ii  libleveldb1d  1.22-3
ii  libluajit-5.1-2   2.1.0~beta3+dfsg-5.3
ii  libncursesw6  6.2+20201114-2
ii  libopenal11:1.19.1-2
ii  libpq513.5-0+deb11u1
ii  libspatialindex6  1.9.3-2
ii  libsqlite3-0  3.34.1-3
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  libvorbisfile31.3.7-1
ii  libx11-6  2:1.7.2-1
ii  minetest-data 5.3.0+repack-2.1+deb11u1
ii  zlib1g1:1.2.11.dfsg-2

minetest recommends no packages.

Versions of packages minetest suggests:
pn  minetest-mod-moreblocks  
pn  minetest-mod-moreores
pn  minetest-mod-pipeworks   
pn  minetest-server  
pn  minetestmapper   

-- no debconf information


Bug#1010816: minetest.emerge_area() call with invalid position can hang server

2022-05-10 Thread Nils Dagsson Moskopp
Package: minetest
Version: 5.3.0+repack-2.1+deb11u1
Severity: normal
Tags: upstream
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

calling minetest.emerge_area() with the first argument being a position 
where x equals 32767 causes RAM and CPU usage to spike, as the Minetest 
server queues 4096 emerge calls instead of 0. Note that as of now, such 
a position is nonsensical, as the map generator stops generating around 
x=31007 or so. It takes a long time to process these emerge calls, even 
if a server has enough spare RAM and CPU resources to not hang forever.

This bug is security-relevant: A malicious client could provoke servers 
into emerging an area – e.g. if it can trigger structure placement code 
that does not have bounds checks. So far I have never seen such code in 
any mod that had any bounds checks for minetest.emerge_area() calls.

I have attached proof of concept code. To verify the bug, name the file 
init.lua, put it in a folder that is in the minetest mods folder (named 
crash_emerge) then enter a world with the mod “crash_emerge” activated.

This bug likely affects all Minetest versions and is not fixed upstream. 

A fix for all versions of Minetest would be to write a mod that wraps 
the function minetest.emerge_area() and checks if the given positions 
are out of bounds, not calling minetest.emerge_area() if that is true.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages minetest depends on:
ii  libc6 2.31-13+deb11u3
ii  libcurl3-gnutls   7.74.0-1.3+deb11u1
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libgmp10  2:6.2.1+dfsg-1+deb11u1
ii  libirrlicht1.81.8.4+dfsg1-1.1
ii  libjsoncpp24  1.9.4-4
ii  libleveldb1d  1.22-3
ii  libluajit-5.1-2   2.1.0~beta3+dfsg-5.3
ii  libncursesw6  6.2+20201114-2
ii  libopenal11:1.19.1-2
ii  libpq513.5-0+deb11u1
ii  libspatialindex6  1.9.3-2
ii  libsqlite3-0  3.34.1-3
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  libvorbisfile31.3.7-1
ii  libx11-6  2:1.7.2-1
ii  minetest-data 5.3.0+repack-2.1+deb11u1
ii  zlib1g1:1.2.11.dfsg-2

minetest recommends no packages.

Versions of packages minetest suggests:
pn  minetest-mod-moreblocks  
pn  minetest-mod-moreores
pn  minetest-mod-pipeworks   
pn  minetest-server  
pn  minetestmapper   

-- no debconf information
local emerge = function()
local i = 32767
minetest.emerge_area(
{ x=i, y=0, z=0 },
{ x=i+1, y=0, z=0 },
function(blockpos, action, calls_remaining)
minetest.debug(
dump(
calls_remaining,
i
)
)
end
)
end

minetest.after( 0, emerge )


Bug#1010760: minetest: Floating point serialization error on x86

2022-05-09 Thread Nils Dagsson Moskopp
Package: minetest
Version: 5.3.0+repack-2.1+deb11u1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

Minetest in versions lower than 5.5.0 is being miscompiled by GCC on 
x86. To verify this bug, run Minetest using “minetest --run-unittests” 
on x86 and look for the following three lines:

Test assertion failed: readF1000(is) == 53.534f
at test_serialization.cpp:308
[FAIL] testStreamRead - 0ms

The reason for this is that the x87 FPU computes in 80bit precision by 
default, while IEEE-754 requires 64 bit precision.

There exist two ways to solve this. Upstream forces SSE2 for floating 
point calculations, by adding the following to CMakeLists.txt on x86:

--- start of patch ---
# use SSE for floating-point operations to avoid issues with improper 
fp-rounding and loss of precision
# when moving fp-data to incompatible or less-precise registers/storage 
locations
# see https://gcc.gnu.org/wiki/FloatingPointMath and 
https://gcc.gnu.org/wiki/x87note

add_compile_options(-mfpmath=sse -msse2)
--- end of patch ---

A non-SSE2 way is to achieve this is to use the compiler option “-mpc64”. 
Both achieve the same goal, calculating with 64 bit precision instead of 
doing calculations with 80 bit precision and then rounding the result to 
64 bit (which makes the unit test fail).

I therefore suggest to instead try the following to CMakeLists.txt on x86:

--- start of patch ---
# Limit x87 FPU to 64 bit precision to avoid floating point precision 
# errors. See both https://gcc.gnu.org/wiki/FloatingPointMath and 
# https://gcc.gnu.org/wiki/x87note for more details about this.

add_compile_options(-mpc64)
--- end of patch ---

If you use the latter, verify that this makes the testStreamRead not fail.

There is no need to upstream this change, as it has already been fixed 
in Minetest 5.5.0, but since it affects serialization, it might lead to 
some crashes or maybe even security bugs if Minetest 5.3.x and 5.4.x are 
being distributed in ways that floating point calculations are miscompiled.

For full context, see <https://github.com/minetest/minetest/issues/11810>.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages minetest depends on:
ii  libc6 2.31-13+deb11u3
ii  libcurl3-gnutls   7.74.0-1.3+deb11u1
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libgmp10  2:6.2.1+dfsg-1+deb11u1
ii  libirrlicht1.81.8.4+dfsg1-1.1
ii  libjsoncpp24  1.9.4-4
ii  libleveldb1d  1.22-3
ii  libluajit-5.1-2   2.1.0~beta3+dfsg-5.3
ii  libncursesw6  6.2+20201114-2
ii  libopenal11:1.19.1-2
ii  libpq513.5-0+deb11u1
ii  libspatialindex6  1.9.3-2
ii  libsqlite3-0  3.34.1-3
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  libvorbisfile31.3.7-1
ii  libx11-6  2:1.7.2-1
ii  minetest-data 5.3.0+repack-2.1+deb11u1
ii  zlib1g1:1.2.11.dfsg-2

minetest recommends no packages.

Versions of packages minetest suggests:
pn  minetest-mod-moreblocks  
pn  minetest-mod-moreores
pn  minetest-mod-pipeworks   
pn  minetest-server  
pn  minetestmapper   

-- no debconf information


Bug#1010759: minetest: item count unreadable due to error in rectangle drawing code

2022-05-09 Thread Nils Dagsson Moskopp
Package: minetest
Version: 5.3.0+repack-2.1+deb11u1
Severity: normal
Tags: patch upstream
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

due to faulty drawing code, the item count has no background rectangle.
To quote the person who discovered the issue & has fixed the rendering:

> The original code was using the wrong overloaded constructor of rect,
> using two points instead of one point and dimension, this patch makes it 
> work like it was originally intended.

This often makes an item count very hard to read even with 20/20 vision.

You can verify this easily by holding an item stack with the item string 
“vessels:glass_fragments” (included in the default game) with a count of 
2 or more: The item count in the lower right corner of the rendered item 
stack is almost entirely unreadable, as white digits are rendered on the 
mostly-white item background.

I am including a patch to fix this, since upstream only ever focuses on 
new releases and people are using older versions of Minetest. The patch 
is tested to work with Minetest 5.4.1; please apply it to all versions.

Do not bother upstreaming the patch as upstream is aware of the issue –
see <https://github.com/minetest/minetest/pull/11316> for full context.

-- System Information:
Debian Release: 11.3
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages minetest depends on:
ii  libc6 2.31-13+deb11u3
ii  libcurl3-gnutls   7.74.0-1.3+deb11u1
ii  libfreetype6  2.10.4+dfsg-1
ii  libgcc-s1 10.2.1-6
ii  libgmp10  2:6.2.1+dfsg-1+deb11u1
ii  libirrlicht1.81.8.4+dfsg1-1.1
ii  libjsoncpp24  1.9.4-4
ii  libleveldb1d  1.22-3
ii  libluajit-5.1-2   2.1.0~beta3+dfsg-5.3
ii  libncursesw6  6.2+20201114-2
ii  libopenal11:1.19.1-2
ii  libpq513.5-0+deb11u1
ii  libspatialindex6  1.9.3-2
ii  libsqlite3-0  3.34.1-3
ii  libstdc++610.2.1-6
ii  libtinfo6 6.2+20201114-2
ii  libvorbisfile31.3.7-1
ii  libx11-6  2:1.7.2-1
ii  minetest-data 5.3.0+repack-2.1+deb11u1
ii  zlib1g1:1.2.11.dfsg-2

minetest recommends no packages.

Versions of packages minetest suggests:
pn  minetest-mod-moreblocks  
pn  minetest-mod-moreores
pn  minetest-mod-pipeworks   
pn  minetest-server  
pn  minetestmapper   

-- no debconf information
>From d8394f4d509101df1927f2ed91f5f750faebf595 Mon Sep 17 00:00:00 2001
From: Kezi 
Date: Sat, 5 Jun 2021 00:03:56 +0200
Subject: [PATCH] Draw item count background rectangle in inventory

The original code was using the wrong overloaded constructor of rect,
using two points instead of one point and dimension, this patch makes it
work like it was originally intended.

See <https://github.com/minetest/minetest/pull/11316> for context.
---
 src/client/hud.cpp | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/src/client/hud.cpp b/src/client/hud.cpp
index 46736b325..99a1c03fb 100644
--- a/src/client/hud.cpp
+++ b/src/client/hud.cpp
@@ -1098,15 +1098,21 @@ void drawItemStack(
v2u32 dim = font->getDimension(utf8_to_wide(text).c_str());
v2s32 sdim(dim.X, dim.Y);
 
-   core::rect rect2(
-   /*rect.UpperLeftCorner,
-   core::dimension2d(rect.getWidth(), 15)*/
-   rect.LowerRightCorner - sdim,
-   sdim
+   const s32 horizontal_padding = 3; //px
+   core::position2d offset(-5,-2);
+
+   core::rect background_rect(
+   rect.LowerRightCorner - sdim + 
core::position2d(-horizontal_padding,0) + offset,
+   rect.LowerRightCorner + 
core::position2d(horizontal_padding,0) + offset
);
 
video::SColor bgcolor(128, 0, 0, 0);
-   driver->draw2DRectangle(bgcolor, rect2, clip);
+   driver->draw2DRectangle(bgcolor, background_rect, clip);
+
+   core::rect rect2(
+   rect.LowerRightCorner - sdim + offset,
+   rect.LowerRightCorner + offset
+   );
 
video::SColor color(255, 255, 255, 255);
font->draw(text.c_str(), rect2, color, false, false, clip);
-- 
2.30.2



Bug#1005048: elpa-lua-mode: Emacs hangs when I press enter twice on line 534 of a lua file

2022-02-05 Thread Nils Dagsson Moskopp
Package: elpa-lua-mode
Version: 20201010-1
Severity: normal
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

when working on Mineclonia https://git.minetest.land/Mineclonia/Mineclonia/
Emacs hung itself.  I have attached a lua file that is part of Mineclonia.
Pressing enter twice on line 534 reproducibly hangs Emacs on my machine.

I expected Emacs to not hang when I pressed enter twice on line 534 of 
the attached file.

Greetings!

-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages elpa-lua-mode depends on:
ii  dh-elpa-helper  2.0.8
ii  emacsen-common  3.0.4

elpa-lua-mode recommends no packages.

elpa-lua-mode suggests no packages.

-- no debconf information
local S = minetest.get_translator("mcl_structures")
mcl_structures ={}
local rotations = {
"0",
"90",
"180",
"270"
}

local function ecb_place(blockpos, action, calls_remaining, param)
if calls_remaining >= 1 then return end
minetest.place_schematic(param.pos, param.schematic, param.rotation, 
param.replacements, param.force_placement, param.flags)
if param.after_placement_callback and param.p1 and param.p2 then
param.after_placement_callback(param.p1, param.p2, param.size, 
param.rotation, param.pr)
end
end
mcl_structures.place_schematic = function(pos, schematic, rotation, 
replacements, force_placement, flags, after_placement_callback, pr)
local s = loadstring(minetest.serialize_schematic(schematic, "lua", 
{lua_use_comments = false, lua_num_indent_spaces = 0}) .. " 
return(schematic)")()
if s and s.size then
local x, z = s.size.x, s.size.z
if rotation then
if rotation == "random" and pr then
rotation = rotations[pr:next(1,#rotations)]
end
if rotation == "random" then
x = math.max(x, z)
z = x
elseif rotation == "90" or rotation == "270" then
x, z = z, x
end
end
local p1 = {x=pos.x, y=pos.y   , z=pos.z}
local p2 = {x=pos.x+x-1, y=pos.y+s.size.y-1, z=pos.z+z-1}
minetest.log("verbose","[mcl_structures] size=" 
..minetest.pos_to_string(s.size) .. ", rotation=" .. tostring(rotation) .. ", 
emerge from "..minetest.pos_to_string(p1) .. " to " .. 
minetest.pos_to_string(p2))
local param = {pos=vector.new(pos), schematic=s, 
rotation=rotation, replacements=replacements, force_placement=force_placement, 
flags=flags, p1=p1, p2=p2, after_placement_callback = after_placement_callback, 
size=vector.new(s.size), pr=pr}
minetest.emerge_area(p1, p2, ecb_place, param)
end
end

mcl_structures.get_struct = function(file)
local localfile = 
minetest.get_modpath("mcl_structures").."/schematics/"..file
local file, errorload = io.open(localfile, "rb")
if errorload ~= nil then
minetest.log("error", '[mcl_structures] Could not open this 
struct: ' .. localfile)
return nil
end

local allnode = file:read("*a")
file:close()

return allnode
end

-- Call on_construct on pos.
-- Useful to init chests from formspec.
local init_node_construct = function(pos)
local node = minetest.get_node(pos)
local def = minetest.registered_nodes[node.name]
if def and def.on_construct then
def.on_construct(pos)
return true
end
return false
end

-- The call of Struct
mcl_structures.call_struct = function(pos, struct_style, rotation, pr)
minetest.log("action","[mcl_structures] call_struct " .. 
struct_style.." at "..minetest.pos_to_string(pos))
if not rotation then
rotation = "random"
end
if struct_style == "desert_temple" then
return mcl_structures.generate_desert_temple(pos, rotation, pr)
elseif struct_style == "desert_well" then
return mcl_structures.generate_desert_well(pos, rotation)
elseif struct_style == "igloo" then
return mcl_structures.generate_igloo(pos, rotation, pr)
elseif s

Bug#1004645: rc: Tab complete leads to crash on some (e.g. empty) lines

2022-01-30 Thread Nils Dagsson Moskopp
Package: rc
Version: 1.7.4+97.gceb59bb-4
Severity: important
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear maintainer,

I have used the rc shell for quite a while now. I really like it.

However, It fails to tab complete after an upgrade to Debian Bullseye.

When I press tab on an empty line, the rc shell crashes with this message:

free(): double free detected in tcache 2

-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages rc depends on:
ii  libc6 2.31-13+deb11u2
ii  libreadline8  8.1-1

rc recommends no packages.

rc suggests no packages.

-- no debconf information



Bug#873578: xserver-xorg-video-all: The suggestion is ridiculous, please do not do it!

2022-01-23 Thread Nils Dagsson Moskopp
Package: xserver-xorg-video-all
Followup-For: Bug #873578
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,


Itai Shaked  wrote:

> I think it is safe to assume that in 2017, the vast majority of Debian 
> users will have hardware meeting this criteria, so having 
> `xserver-xorg-video-all` Recommend `xserver-xorg-video-intel` seems 
> wrong.

It is 2022 and I had to install xserver-xorg-video-intel manually to get 
a usable graphical desktop – on a computer which runs Debian just fine …

It seems to me the person suggesting this has no empathy for people who 
do not own the latest and greatest hardware. Not everyone can figure it 
out that a package that is supposed to install all drivers is not doing 
that actually.

Therefore I kindly ask you to please not listen to this person who owns 
newer hardware than I do.


Greetings,
Nils Moskopp

-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages xserver-xorg-video-all depends on:
ii  xserver-xorg-video-amdgpu   19.1.0-2
ii  xserver-xorg-video-ati  1:19.1.0-2
ii  xserver-xorg-video-fbdev1:0.5.0-1
ii  xserver-xorg-video-nouveau  1:1.0.17-1
ii  xserver-xorg-video-vesa 1:2.5.0-1
ii  xserver-xorg-video-vmware   1:13.3.0-3

Versions of packages xserver-xorg-video-all recommends:
ii  xserver-xorg-video-intel  2:2.99.917+git20200714-1+b1
pn  xserver-xorg-video-qxl

xserver-xorg-video-all suggests no packages.

-- no debconf information


Bug#1004277: xserver-xorg-video-all does not depend on xserver-xorg-video-intel

2022-01-23 Thread Nils Dagsson Moskopp
Package: xserver-xorg-video-all
Version: 1:7.7+22
Severity: important
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

on my computer (Thinkpad T60) X11 would not start, throwing an error 
about OpenGL 2.1 being required. I was very concerned, since the GPU 
does not support OpenGL 2.1.

I had already installed xserver-xorg-video-all and was very confused. 
Only as I noticed that xserver-xorg-video-intel was not a dependency, 
but merely recommended, I figured out that I could try to install it.

I suspect that someone assumed that some fallback driver would be able 
to handle the situation. Clearly, this is not the case. I therefore ask 
for xserver-xorg-video-all to please depend on xserver-xorg-video-intel.

--- snib ---

; glxinfo |grep OpenGL
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 945GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 20.3.5
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 20.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16
OpenGL ES profile extensions:

--- snab ---

Greetings,
Nils Moskopp

-- System Information:
Debian Release: 11.2
  APT prefers stable
  APT policy: (900, 'stable'), (500, 'oldoldstable')
Architecture: i386 (i686)

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

Versions of packages xserver-xorg-video-all depends on:
ii  xserver-xorg-video-amdgpu   19.1.0-2
ii  xserver-xorg-video-ati  1:19.1.0-2
ii  xserver-xorg-video-fbdev1:0.5.0-1
ii  xserver-xorg-video-nouveau  1:1.0.17-1
ii  xserver-xorg-video-vesa 1:2.5.0-1
ii  xserver-xorg-video-vmware   1:13.3.0-3

Versions of packages xserver-xorg-video-all recommends:
ii  xserver-xorg-video-intel  2:2.99.917+git20200714-1+b1
pn  xserver-xorg-video-qxl

xserver-xorg-video-all suggests no packages.

-- no debconf information


Xorg.0.log.old
Description: application/json


Bug#1004223: minetest-server: ItemStack meta injection vulnerability in Minetest 5.3

2022-01-22 Thread Nils Dagsson Moskopp
Package: minetest-server
Version: 5.3.0+repack-2.1
Severity: grave
Tags: patch security
Justification: user security hole
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net, Debian Security 
Team 

Dear Maintainer,


Minetest 5.3 contains a serious security issue by default.
The ItemStack meta is not sanitized properly by the server.

Is is therefore possible for clients to inject ItemStack meta.
It might be possible to backdoor the server by injecting Lua.

Computers running Minetest 5.3 are vulnerable to this exploit.
The following patch, part of Minetest 5.4, fixes the problem:

https://github.com/minetest/minetest/commit/b5956bde259faa240a81060ff4e598e25ad52dae


Greetings,
Nils Moskopp

-- System Information:
Debian Release: 11.2
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages minetest-server depends on:
ii  adduser  3.118
ii  init-system-helpers  1.60
ii  libc62.31-13+deb11u2
ii  libcurl3-gnutls  7.74.0-1.3+deb11u1
ii  libgcc-s110.2.1-6
ii  libgmp10 2:6.2.1+dfsg-1+deb11u1
ii  libjsoncpp24 1.9.4-4
ii  libleveldb1d 1.22-3
ii  libluajit-5.1-2  2.1.0~beta3+dfsg-5.3
ii  libncursesw6 6.2+20201114-2
ii  libpq5   13.5-0+deb11u1
ii  libspatialindex6 1.9.3-2
ii  libsqlite3-0 3.34.1-3
ii  libstdc++6   10.2.1-6
ii  libtinfo66.2+20201114-2
ii  lsb-base 11.1.0
ii  minetest-data5.3.0+repack-2.1
ii  zlib1g   1:1.2.11.dfsg-2

minetest-server recommends no packages.

minetest-server suggests no packages.

-- no debconf information



Bug#1004208: quaternion: Quaternion hangs on login at 100% CPU

2022-01-22 Thread Nils Dagsson Moskopp
Package: quaternion
Version: 0.0.9.5~beta2-2
Severity: important
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

I am trying to find a Matrix chat client that does not lag my computer.

When logging in with Quaternion, after login it hangs forever at 100% CPU.

I expected it to allow me to chat with my friends and not use many resources.

Greetings,
Nils Moskopp

-- System Information:
Debian Release: 11.2
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages quaternion depends on:
ii  libc6 2.31-13+deb11u2
ii  libgcc-s1 10.2.1-6
ii  libqt5core5a  5.15.2+dfsg-9
ii  libqt5gui55.15.2+dfsg-9
ii  libqt5keychain1   0.10.0-1
ii  libqt5network55.15.2+dfsg-9
ii  libqt5qml55.15.2+dfsg-6
ii  libqt5quick5  5.15.2+dfsg-6
ii  libqt5quickwidgets5   5.15.2+dfsg-6
ii  libqt5widgets55.15.2+dfsg-9
ii  libquotient0.60.6.6-1
ii  libstdc++610.2.1-6
ii  qml-module-qtquick-controls   5.15.2-2
ii  qml-module-qtquick-controls2  5.15.2+dfsg-2

quaternion recommends no packages.

quaternion suggests no packages.

-- no debconf information



Bug#1004205: matrix-mirage shows error on login

2022-01-22 Thread Nils Dagsson Moskopp
Package: matrix-mirage
Version: 0.6.4~dfsg+~hsluv1.0.0-4
Severity: important
X-Debbugs-Cc: nils+debian-report...@dieweltistgarnichtso.net

Dear Maintainer,

I am trying to find a Matrix chat client that does not lag my computer.

I tried matrix-mirage. Unfortunately, upon login, I got this error:

--- 8< --- snib --- 8< ---

X 19:21:13 | python: (200, None)
Traceback (most recent call last):
  File "qrc:/src/backend/matrix_client.py", line 399, in _start
await self.sync_task
  File "/usr/lib/python3/dist-packages/nio/client/async_client.py", line 1130, 
in sync_forever
sync_response = await self.sync(use_timeout, use_filter, since, full_state, 
presence)
  File "/usr/lib/python3/dist-packages/nio/client/async_client.py", line 1003, 
in sync
response = await self._send(
  File "qrc:/src/backend/matrix_client.py", line 255, in _send
raise MatrixError.from_nio(response)
backend.errors.MatrixError: (200, None)

--- >8 --- snab --- >8 ---

The error is repeatedly printed on the terminal about every five seconds.

-- System Information:
Debian Release: 11.2
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable')
Architecture: i386 (i686)

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

Versions of packages matrix-mirage depends on:
ii  libc6   2.31-13+deb11u2
ii  libgcc-s1   10.2.1-6
ii  libqt5core5a5.15.2+dfsg-9
ii  libqt5gui5  5.15.2+dfsg-9
ii  libqt5qml5  5.15.2+dfsg-6
ii  libqt5quick55.15.2+dfsg-6
ii  libqt5quickcontrols2-5  5.15.2+dfsg-2
ii  libqt5widgets5  5.15.2+dfsg-9
ii  libstdc++6  10.2.1-6
ii  libx11-62:1.7.2-1
ii  libxss1 1:1.2.3-1
ii  python3 3.9.2-3
ii  python3-aiofiles0.6.0-2
ii  python3-appdirs 1.4.4-1
ii  python3-blist   1.3.6-7+b1
ii  python3-cairosvg2.5.0-1.1
ii  python3-html-sanitizer  1.9.1-2
ii  python3-lxml4.6.3+dfsg-0.1
ii  python3-magic   2:0.4.20-3
ii  python3-matrix-nio  0.16.0-1
ii  python3-mistune 0.8.4-4
ii  python3-pil 8.1.2+dfsg-0.3
ii  python3-pymediainfo 5.0.3-1
ii  qml-module-io-thp-pyotherside   1.5.9-2+b3
ii  qml-module-qt-labs-folderlistmodel  5.15.2+dfsg-6
ii  qml-module-qt-labs-platform 5.15.2+dfsg-2
ii  qml-module-qt-labs-qmlmodels5.15.2+dfsg-6
ii  qml-module-qtav 1.13.0+ds-3+b2
ii  qml-module-qtgraphicaleffects   5.15.2-2
ii  qml-module-qtquick-controls25.15.2+dfsg-2
ii  qml-module-qtquick-dialogs  5.15.2-2
ii  qml-module-qtquick-layouts  5.15.2+dfsg-6
ii  qml-module-qtquick-shapes   5.15.2+dfsg-6
ii  qml-module-qtquick-window2  5.15.2+dfsg-6
ii  qml-module-qtquick2 5.15.2+dfsg-6

Versions of packages matrix-mirage recommends:
pn  fonts-hack 
ii  fonts-roboto-unhinted  2:0~20170802-3
pn  qt5-image-formats-plugins  

matrix-mirage suggests no packages.

-- no debconf information



Bug#1003351: Update package to upstream version 5.0 (patches provided)

2022-01-08 Thread Nils König
Source: libunibreak
Version: 1.1-2.1
Severity: wishlist
Tags: patch

Dear Maintainer,

while there aren't any known grave issues with the packaged version 1.1,
released 2013, this is severely lagging behind upstream's newest version
5.0 released in late 2021.
Upgrading to 5.0 brings the benefit of an updated linebreaking behaviour
following the current revision of Unicode and additional API-entrypoints
and new API regarding graphemes and pictographics.
Thus I believe it would be a good idea to upgrade; patches to update
the Debian package to 5.0 are attached (also fixing lintian warnings).

One noteworthy incompatible change is that in 5.0 the signature of the
set_linebreaks (without suffix) function from linebreakdef.h changed its
signature. However as far as I can tell currently the only user of
libunibreak in the Debian archives is libzltext, which does not use this
function, so this is probably not an issue.
https://github.com/adah1972/libunibreak/commit/a6bcee2daf6fb884edd1ff78ce58521ab31f9826

  $ ls -l ~1/libzltext.so.0.13
  lrwxrwxrwx 1 user user 20  1. Sep 2019  /tmp/libzltext.so.0.13 -> 
libzltext.so.0.12.10
  $ nm -gDC ~1/libzltext.so.0.12.10 | grep -E '^ +U' | grep -E 
'lb_|ub_|unibreak|break'
   U init_linebreak
   U set_linebreaks_utf8


The patches are split in 6 parts in hopes to make review easier.
As one of the patches is large'ish (~1.5MiB) due to adding some data files
otherwise fetched from the network, I compressed all of them into a
xz-compressed tar-archive before attaching. Some further notes:

The changelog is using the ~local suffix and my own name; this will
need to be changed to reflect the actual uploader and drop the suffix.

Upstream tarballs contain prebuilt documentation including some javascript,
to resolve the errors resulting from the sourceless javascript I'm using
Files-Excluded to repackage the tarball without the docs.
This works, but perhaps there's a softer approach to resolve this?

It appears like most packages, include a copyright declaration for debian/*
with past and current maintainers as copyright holders; this package does not,
but obviously I cannot choose a licence for someone else. If this is required,
what licence did/do you intend Eugene?

I made sure to resolve all lintian hints >= pedantic, but I only packaged for my
personal use before, so there might be some things I missed and not caught by
lintian, or just superior alternative approaches I don't know about.
Nonetheless I'm hoping the patches are helpful in getting the package back in
sync with upstream.


Cheers
Nils König



-- System Information:
Debian Release: 11.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'
), (500, 'stable'), (10, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-10-amd64 (SMP w/16 CPU threads)
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: OpenRC (via /run/openrc), PID 1: openrc-init
LSM: AppArmor: enabled

Versions of packages libunibreak1 depends on:
ii  libc6  2.31-13+deb11u2


libunibreak-5.0-patches.tar.xz
Description: application/xz


signature.asc
Description: PGP signature


Bug#1001090: latex-beamer: backport bugfix for bibliographies to Bullseye

2021-12-03 Thread Nils König
Package: texlive-latex-recommended
Version: 2020.20210202-3
Severity: wishlist

Dear Maintainer,

the version of beamer shipped in Bullseye's texlive-latex-recommended contains 
a 
bug preventing beamer files with multiple \printbibliography calls from being 
processed successfully. This can happen if e.g. the bibliography is split in 
literature sources for the content and another section for the images used in 
the presentation.
The bug was already fixed upstream and modifying my installed files to apply 
this patch was successfull in resolving the problem:

https://github.com/josephwright/beamer/commit/a41c6a779ca1f921d536ea9d9a2785ff6d5df615

>From the datetags of Bookworm's and Sid's packages I'm assuming they already 
include the fix, but imho it would be a very good idea to backport it to 
Bullseye too — if my local modification is something to go by it should apply 
without conflicts.

A minimal sample failing to be processed in unpatched Bullseye,
but working with the patch, can be found further below.

Cheers,
Nils König


minimal input file
##

\begin{filecontents}{\jobname.bib}
@misc{beamer,
  url = {https://ctan.org/pkg/beamer},
}
\end{filecontents}

\documentclass{beamer}

\usepackage[style=authoryear]{biblatex}

\addbibresource{\jobname.bib}

\begin{document}

\nocite{*}

\begin{frame}
\printbibliography
\end{frame}

\begin{frame}
\printbibliography
\end{frame}

\end{document}

##


other files

##
 List of ls-R files

-rw-r--r-- 1 root root 2234 Dec  4 02:30 /var/lib/texmf/ls-R
lrwxrwxrwx 1 root root 29 Feb 12  2021 /usr/share/texmf/ls-R -> 
/var/lib/texmf/ls-R-TEXMFMAIN
lrwxrwxrwx 1 root root 31 Feb 17  2021 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
lrwxrwxrwx 1 root root 31 Feb 17  2021 /usr/share/texlive/texmf-dist/ls-R -> 
/var/lib/texmf/ls-R-TEXLIVEDIST
##
 Config files
-rw-r--r-- 1 root root 475 Aug 22 20:46 /etc/texmf/web2c/texmf.cnf
lrwxrwxrwx 1 root root 33 Feb 17  2021 /usr/share/texmf/web2c/fmtutil.cnf -> 
/var/lib/texmf/fmtutil.cnf-DEBIAN
lrwxrwxrwx 1 root root 32 Feb 17  2021 /usr/share/texmf/web2c/updmap.cfg -> 
/var/lib/texmf/updmap.cfg-DEBIAN
-rw-r--r-- 1 root root 3865 Oct 31 17:34 
/var/lib/texmf/tex/generic/config/language.dat
##
 Files in /etc/texmf/web2c/
total 8
-rw-r--r-- 1 root root 283 Feb 28  2019 mktex.cnf
-rw-r--r-- 1 root root 475 Aug 22 20:46 texmf.cnf
##
 md5sums of texmf.d
ca40c66f144b4bafc3e59a2dd32ecb9c  /etc/texmf/texmf.d/00debian.cnf

-- System Information:
Debian Release: 11.1
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 
'stable-debug'), (500, 'proposed-updates-debug'), (500, 'stable'), (10, 
'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-9-amd64 (SMP w/16 CPU threads)
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: OpenRC (via /run/openrc), PID 1: openrc-init
LSM: AppArmor: enabled

Versions of packages texlive-latex-recommended depends on:
ii  tex-common  6.16
ii  texlive-base2020.20210202-3
ii  texlive-binaries2020.20200327.54578-7
ii  texlive-latex-base  2020.20210202-3

texlive-latex-recommended recommends no packages.

Versions of packages texlive-latex-recommended suggests:
pn  texlive-latex-recommended-doc  
ii  texlive-luatex 2020.20210202-3
ii  texlive-pstricks   2020.20210202-3

Versions of packages tex-common depends on:
ii  dpkg  1.20.9
ii  ucf   3.0043

Versions of packages tex-common suggests:
ii  debhelper  13.3.4

Versions of packages texlive-latex-recommended is related to:
ii  tex-common6.16
ii  texlive-binaries  2020.20200327.54578-7

-- no debconf information



Bug#931197: base-files: Include minor version in /etc/os-release

2021-11-16 Thread Nils Breunese
I would also appreciate it if VERSION_ID in /etc/os-release would contain the 
full version from /etc/debian_version. I collect information for a lot of 
different Kubernetes containers running all kinds of operating systems and 
versions, and I have found ID and VERSION_ID in /etc/os-release to be the most 
reliably available information across Linux distributions.

From Alpine Linux and RHEL I get versions like 3.14.3 and 8.4, but Debian only 
provides the major version, so for Debian containers this gives me less 
information. I could implement a custom check for /etc/debian_version and use 
that instead when present, but it would be nice to get this information from 
/etc/os-release directly.

Nils.


Bug#987886: krita: Right-clicking on the canvas crashes krita

2021-10-04 Thread Nils König
> I tried to reproduce this issue inside a virtual machine.
> But there the menu opens without the issue.

I can reliably reproduce this in Debian Bullseye; it appears like the
environment variable QT_SCALE_FACTOR needs to be set to a non-integer value 
(which is supported!) for the crash to happen. By default I'm using 
QT_SCALE_FACTOR=1.7 and it crashes — it doesn't crash with QT_SCALE_FACTOR=1 
or QT_SCALE_FACTOR=2.

Testing inside a Sid+Experimental chroot, version 5.0.0~beta1+dfsg-1 
from experimental seems not affected.

> Does this happen to you if you startup without the wacom input attached?

It happens with only a keyboard and a mouse as input devices attached.

> Does the KCrash window open or do you have the
> sad smiley at the bottom right near the clock?

It just crashes without any dialog, even with MALLOC_CHECK_=3 and
I'm afraid I don't know which smiley or clock you're referring to.
Before right-clicking and crashing the console log already shows a bunch of 
warnings like these, which might or might not be related to the crash:

  QImage::setPixel: coordinate (132,166) out of range
  QImage::setPixel: coordinate (133,166) out of range
  QImage::setPixel: coordinate (134,166) out of range
  QImage::setPixel: coordinate (135,166) out of range
  QImage::setPixel: coordinate (136,166) out of range

To get more info I ran krita in gdb, with 

  set args --new-image RGBA,U8,1600,1600
  set environment MALLOC_CHECK_ 3
  set environment QT_SCALE_FACTOR 1.7
  run

On right click, gdb first showed the following:

  Thread 1 "krita" received signal SIGABRT, Aborted.
  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
  50  ../sysdeps/unix/sysv/linux/raise.c: file or directory not found

Then I requested the backtrace, whose entirety can be found a few lines below.
I hope this helps in locating and fixing the issue (and backporting the fix to 
Bullseye). If you need any more information or something tested I'd be happy 
to help.

Cheers
Nils König

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x74529537 in __GI_abort () at abort.c:79
#2  0x74582768 in __libc_message (action=action@entry=do_abort, 
fmt=fmt@entry=0x74690e2d "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x74589a5a in malloc_printerr (str=str@entry=0x7468f05a 
"free(): invalid pointer") at malloc.c:5347
#4  0x7458bca6 in free_check (mem=0x7fffbafeb010, caller=) at hooks.c:255
#5  0x74f84e25 in QImageData::~QImageData() () from 
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#6  0x74f85308 in QImage::~QImage() () from 
/lib/x86_64-linux-gnu/libQt5Gui.so.5
#7  0x73db45e8 in KoTriangleColorSelector::generateTriangle() () from 
/lib/x86_64-linux-gnu/libkritawidgets.so.20
#8  0x73db4a35 in KoTriangleColorSelector::paintEvent(QPaintEvent*) () 
from /lib/x86_64-linux-gnu/libkritawidgets.so.20
#9  0x7565ffae in QWidget::event(QEvent*) () from 
/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#10 0x7562015f in QApplicationPrivate::notify_helper(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x770d37c9 in KisApplication::notify(QObject*, QEvent*) () from 
/lib/x86_64-linux-gnu/libkritaui.so.20
#12 0x74b5dfca in QCoreApplication::notifyInternal2(QObject*, QEvent*) 
() from /lib/x86_64-linux-gnu/libQt5Core.so.5
#13 0x75658116 in QWidgetPrivate::sendPaintEvent(QRegion const&) () 
from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#14 0x75658962 in QWidgetPrivate::drawWidget(QPaintDevice*, QRegion 
const&, QPoint const&, QFlags, QPainter*, 
QWidgetRepaintManager*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#15 0x75659cb3 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, 
QFlags, QPainter*, QWidgetRepaintManager*) () 
from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#16 0x75659ad2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, 
QFlags, QPainter*, QWidgetRepaintManager*) () 
from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#17 0x75659ad2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, 
QFlags, QPainter*, QWidgetRepaintManager*) () 
from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#18 0x75659ad2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, 
QFlags, QPainter*, QWidgetRepaintManager*) () 
from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#19 0x75659ad2 in QWidgetPrivate::paintSiblingsRecursive(QPaintDevice*, 
QList const&, int, QRegion const&, QPoint const&, 
QFlags, QPainter*, QWidgetRepaintManager*) () 
from /lib/x86_64-linux-gnu/libQt5Widgets.so.5
#20 0x75659ad2 in QWidg

Bug#987177: lockfile-progs: lockfile creation failing on cifs mounts

2021-09-06 Thread Nils
dotlock / dotlock -u work fine without error messages



Bug#987177: lockfile-progs: lockfile creation failing on cifs mounts

2021-09-06 Thread Nils
I can verify that it still exists on Buster:

nils@smidge:/mnt/nas/backup/scripts/smidge$ mkdir tmp_locktest
nils@smidge:/mnt/nas/backup/scripts/smidge$ cd tmp_locktest/
nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ lockfile-create
testlock
lockfile creation failed: Value too large for defined data type
nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ ll
total 1
drwxr-xr-x 2 nils nils 0 Sep  6 09:56 ./
drwxr-xr-x 2 nils nils 0 Sep  6 09:55 ../
-rwxr-xr-x 2 nils nils 2 Sep  6 09:56 .lk01464asmidge*
-rwxr-xr-x 2 nils nils 2 Sep  6 09:56 testlock.lock*
nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ lockfile-remove
testlock
nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ ll
total 1
drwxr-xr-x 2 nils nils 0 Sep  6 09:57 ./
drwxr-xr-x 2 nils nils 0 Sep  6 09:55 ../
-rwxr-xr-x 1 nils nils 2 Sep  6 09:56 .lk01464asmidge*
nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ uname -a
Linux smidge 5.10.0-0.bpo.5-686-pae #1 SMP Debian 5.10.24-1~bpo10+1
(2021-03-29) i686 GNU/Linux
nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ cat
/etc/debian_version
10.10
nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ dpkg -l | grep
libc6
ii  libc6:i386  
2.28-10 i386 GNU C Library:
Shared libraries
rc  libc6-i686:i386 
2.24-11+deb9u4  i386 transitional dummy
package
nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ dpkg -l | grep
liblockfile1
ii  liblockfile1:i386   
1.14-1.1    i386 NFS-safe locking
library



Bug#987177: lockfile-progs: lockfile creation failing on cifs mounts

2021-09-06 Thread Nils
Also exists on Bullseye:

nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ lockfile-create 
testlock

lockfile creation failed: Value too large for defined data type

nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ ll

total 1

drwxr-xr-x 2 nils nils 0 Sep  6 12:51 ./

drwxr-xr-x 2 nils nils 0 Sep  6 09:55 ../

-rwxr-xr-x 2 nils nils 2 Sep  6 12:51 .lk010918smidge*

-rwxr-xr-x 2 nils nils 2 Sep  6 12:51 testlock.lock*

nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ uname -a

Linux smidge 5.10.0-8-686-pae #1 SMP Debian 5.10.46-4 (2021-08-03) i686 
GNU/Linux

nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ cat 
/etc/debian_version 

11.0

nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ dpkg -l | egrep 
"libc6|liblockfile1"

ii  libc6:i386   2.31-13 i386   
  GNU C Library: Shared libraries

rc  libc6-i686:i386  2.24-11+deb9u4  i386   
  transitional dummy package

ii  liblockfile1:i386    1.17-1+b1   i386   
  NFS-safe locking library

nils@smidge:/mnt/nas/backup/scripts/smidge/tmp_locktest$ 



Bug#987960: Backport fixes from libass 0.15.1

2021-05-02 Thread Nils König
Source: libass
Version: 1:0.15.0-1
Severity: normal
Tags: patch

Hi,

as you may already have noticed libass 0.15.1 was released recently and fixes
many bugs. I believe at least one of those fixes needs to be pulled into 
Debian.

0.15.0 introduced a regression leading to reliable crashes on some files with
embedded fonts. Without this fix some subtitle files will be plain unplayable
and cause the libass-using application to segfault.
Attached a patch with the relevant upstream commits as 'fix-emf-crash.patch';
it's rebased to apply cleanly on top of current Debian master.

Furthermore, 0.15.1 includes another fix for an older embedded font bug
preventing most libass-API-users from actually utilising embedded fonts as 
they only worked with a specific API-call order. This prevents eg VLC from 
correctly displaying subtitles with embedded fonts. Applying this fix on 
libass' side, will instantly make embedded fonts work in VLC, without further 
changes being neccesary.
I believe, while less severe than crashing, it would be a very good idea to 
also backport this fix to Debian.
Attached a patch with the relevant upstream commits as 'fix-emf-render.patch';
it's rebased to apply cleanly on Debian master + previous patch.


However, as upstream's release notes state, 0.15.1 is a pure bugfix release 
with no actual API changes or additions and there are a number of additional
bugfixes. Perhaps a full upgrade to 0.15.1 would also be a good idea?
But then again, the "Hard Freeze" already started and I'm not sure what the 
guidelines say about pure bugfix releases from an upstream that doesn't 
regularly provide stable bugfix releases.
So, I just thought I'd mention it and leave it up to your judgement :)

Here's the relevant part of upstream's release text:
> This is purely a bug fix and polish release, with no significant API or ABI
> changes.
>
> The only API change is that `ass_add_font` is now declared to accept
> `const char *`. Previously it took only `char *`, but const has worked in
> practice since the very first standalone libass release.
>
> [Full text with a list of all fixes:
>  https://github.com/libass/libass/releases/tag/0.15.1 ]


Cheers
Nils König

-- System Information:
Debian Release: 11.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.10.0-0.bpo.5-amd64 (SMP w/16 CPU threads)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: openrc (via /run/openrc)
PID 1: openrc-init
LSM: AppArmor: enabled
From 4830494fcdcf2cf67f35d92cade1a60713a2fdd1 Mon Sep 17 00:00:00 2001
From: Oleg Oshmyan 
Date: Tue, 27 Oct 2020 15:46:04 +0200
Subject: [PATCH 1/2] Fix crashes on some files with embedded fonts

Squashed from upstream commits 017137471d0043e0321e377ed8da48e45a3ec632
and 59eb317aaa495ad5331c9efdf8d7bf3d860c2992

== Commit message from 017137471d0043e0321e377ed8da48e45a3ec632:
decode_font: fix subtraction broken by change to unsigned type

This caused a one-byte buffer overwrite and an assertion failure.

Regression in commit 910211f1c0078e37546f73e95306724358b89be2.

Discovered by OSS-Fuzz.

Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26674.
Fixes https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=26678.

== Commit Message from 59eb317aaa495ad5331c9efdf8d7bf3d860c2992
Match more types and format specifiers to size_t fontdata_used

Omissions in commit 910211f1c0078e37546f73e95306724358b89be2.

Microsoft's C library does not support %zu until Universal CRT
(Visual Studio 2015). At worst, this verbose-level message will
look wrong and be useless.
---
 libass/ass.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libass/ass.c b/libass/ass.c
index 428a332..51fa201 100644
--- a/libass/ass.c
+++ b/libass/ass.c
@@ -820,7 +820,7 @@ static unsigned char *decode_chars(const unsigned char *src,
unsigned char *dst, size_t cnt_in)
 {
 uint32_t value = 0;
-for (int i = 0; i < cnt_in; i++)
+for (size_t i = 0; i < cnt_in; i++)
 value |= (uint32_t) ((src[i] - 33u) & 63) << 6 * (3 - i);
 
 *dst++ = value >> 16;
@@ -850,14 +850,14 @@ static int decode_font(ASS_Track *track)
 size_t dsize;  // decoded size
 unsigned char *buf = 0;
 
-ass_msg(track->library, MSGL_V, "Font: %d bytes encoded data",
+ass_msg(track->library, MSGL_V, "Font: %zu bytes encoded data",
 track->parser_priv->fontdata_used);
 size = track->parser_priv->fontdata_used;
 if (size % 4 == 1) {
 ass_msg(track->library, MSGL_ERR, "Bad encoded data size");
 goto error_decode_font;
 }
-buf = malloc(size / 4 * 3 + FFMAX(size % 4 - 1, 0));
+buf = malloc(size / 4 * 3 + FFMAX(size % 4, 1) - 1);
 if (!buf)
 goto error_decode_font

Bug#987177: lockfile-progs: lockfile creation failing on cifs mounts

2021-04-19 Thread Nils
Package: lockfile-progs
Version: 0.1.18
Severity: important

Dear Maintainer,

lockfile creation fails on a cifs mounted drive with "lockfile creation failed: 
Value too large for defined data type"
The problem was seen on the running kernel 5.10.0 and also on 
linux-image-4.19.0-16-686-pae
The problem appeared only recently (last 2- weeks?) after an apt full-upgrade, 
but I don't recall what all changed there.
The created .lk*smidge file could be part of the problem. It disappears when it 
works, but stays wen it does not.
On an ubuntu machine the same lockfile-progs with newer dependencies works (see 
third paste below)

$ uname -a
Linux smidge 5.10.0-0.bpo.5-686-pae #1 SMP Debian 5.10.24-1~bpo10+1 
(2021-03-29) i686 GNU/Linux

---TESTING IN HOME - WORKS
nils@smidge:~$ mkdir test
nils@smidge:~$ cd test
nils@smidge:~/test$ ll
total 8
drwxr-xr-x  2 nils nils 4096 Apr 19 08:52 ./
drwxr-xr-x 15 nils nils 4096 Apr 19 08:52 ../
nils@smidge:~/test$ lockfile-create testlock
nils@smidge:~/test$ ll
total 12
drwxr-xr-x  2 nils nils 4096 Apr 19 08:52 ./
drwxr-xr-x 15 nils nils 4096 Apr 19 08:52 ../
-rw-r--r--  1 nils nils2 Apr 19 08:52 testlock.lock
nils@smidge:~/test$ cat testlock.lock
0
nils@smidge:~/test$ lockfile-remove testlock
nils@smidge:~/test$ ll
total 8
drwxr-xr-x  2 nils nils 4096 Apr 19 08:53 ./
drwxr-xr-x 15 nils nils 4096 Apr 19 08:52 ../
nils@smidge:~/test$

---TESTING IN CIFS - BROKEN
nils@smidge:/mnt/nas/backup/scripts/smidge$ mkdir test
nils@smidge:/mnt/nas/backup/scripts/smidge$ cd test
nils@smidge:/mnt/nas/backup/scripts/smidge/test$ lockfile-create testlock
lockfile creation failed: Value too large for defined data type
nils@smidge:/mnt/nas/backup/scripts/smidge/test$ ll
total 1
drwxr-xr-x 2 nils nils 0 Apr 19 08:54 ./
drwxr-xr-x 2 nils nils 0 Apr 19 08:54 ../
-rwxr-xr-x 2 nils nils 2 Apr 19 08:54 .lk013502smidge*
-rwxr-xr-x 2 nils nils 2 Apr 19 08:54 testlock.lock*
nils@smidge:/mnt/nas/backup/scripts/smidge/test$ cat .lk013502smidge
0
nils@smidge:/mnt/nas/backup/scripts/smidge/test$ cat testlock.lock
0
nils@smidge:/mnt/nas/backup/scripts/smidge/test$ lockfile-remove testlock
nils@smidge:/mnt/nas/backup/scripts/smidge/test$ ll
total 1
drwxr-xr-x 2 nils nils 0 Apr 19 08:54 ./
drwxr-xr-x 2 nils nils 0 Apr 19 08:54 ../
-rwxr-xr-x 1 nils nils 2 Apr 19 08:54 .lk013502smidge*
nils@smidge:/mnt/nas/backup/scripts/smidge/test$

---TESTING IN CIFS FROM UBUNTU MACHINE - WORKS
Works as expected on Ubuntu 20.10 (also with lockfile-progs 0.1.18), but has 
newer dependencies:
nils@blackbox:/mnt/nas/backup/scripts/smidge/test$ uname -a
Linux blackbox 5.8.0-49-generic #55-Ubuntu SMP Wed Mar 24 14:45:45 UTC 2021 
x86_64 x86_64 x86_64 GNU/Linux
nils@blackbox:/mnt/nas/backup/scripts/smidge/test$ dpkg -l | grep libc6
ii  libc6:amd64 2.32-0ubuntu3   
amd64GNU C Library: Shared libraries
ii  libc6:i386  2.32-0ubuntu3   
i386 GNU C Library: Shared libraries
ii  libc6-dbg:amd64 2.32-0ubuntu3   
amd64GNU C Library: detached 
debugging symbols
ii  libc6-dev:amd64 2.32-0ubuntu3   
amd64GNU C Library: Development 
Libraries and Header Files
ii  libc6-i386  2.32-0ubuntu3   
amd64GNU C Library: 32-bit shared 
libraries for AMD64
nils@blackbox:/mnt/nas/backup/scripts/smidge/test$ dpkg -l | grep liblockfile1
ii  liblockfile1:amd64  1.16-1.1
amd64NFS-safe locking library
nils@blackbox:/mnt/nas/backup/scripts/smidge/test$


-- System Information:
Debian Release: 10.9
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-0.bpo.5-686-pae (SMP w/4 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lockfile-progs depends on:
ii  libc6 2.28-10
ii  liblockfile1  1.14-1.1

lockfile-progs recommends no packages.

lockfile-progs suggests no packages.

-- no debconf information



Bug#980079: mumble-server: service restart and stop borked

2021-01-27 Thread Nils König
Sorry it took me so long to come back to this.
And also sorry for the lengthy reply.

On Fri, Jan 15, 2021 at 09:27:30 +, Chris Knadle wrote:
> Is the system with this issue running systemd?

Yes, the affected system does run systemd.

> Which method of creating an SSL cert is being used?

certbot (Let's Encrypt)

> I've tested mumble-server on Debian 10.7 for this, with the default
> configuration, both with and without CAPABILITIES enabled, and I'm able to
> shut down mumble-server correctly on a system running systemd. […]

Welp, I couldn't reproduce it on other systems either; turned out some 
modification to the init-script I made months ago and forgot about was causing 
this (I suspect it only started to cause problems after a reboot).
Sorry, for wasting your time by jumping to a report to quickly.

Though, I also already heard about about the same thing happening to another 
user before (without any modification afaik). Hearing back from this user now,
the problem disappeared again for him without any apparent reason.
I'm afraid I don't know what's causing this issue for him and people 
reporting this upstream. Again, I'm terribly sorry to not have better checked 
on my side before reporting this.

Something (possibly related?) I noticed while investigating this:
If capabilities are used and uname in /etc/mumble-server.ini
is set to something else than "mumble-server", than this problem appears
as long as USER inside the init-script isn't also changed.
Ofc, before that happens murmur will first refuse to start at all, since
it will be unable to access vital files, like:
  /var/lib/mumble-server
  /var/log/mumble-server
  /etc/mumble-server.ini
Change ownership of those locations is perhaps more obvious than needing to 
edit some variable inside the init-script. Especially since after changing
ownership of those files murmur will at first glance appear to start just fine
as no error about the missing pid file is printed.
I'm however neither sure if that really is the cause for those upstream 
reports, nor what's the best way to solve this.


Now about the SSL-certs:

> I understand the problem of needing to start as root in order to read ssl
> certs, and […] I think there's an alternative; I think the SSL cert can
> be copied with different ownership + permissions to a location that
> mumble-server can access using a "post-hook" or "deploy-hook" call to
> certbot or dehydrated […]

Using --post-hook would be cleaner than my current method of just chaining
certbot renewal and restarting/reloading affected services, like so:

  certbot renew --quiet && service mumble-server restart

If the certificate should remain root-only, then
  --post-hook 'service mumble-server restart'
seems ok to me and is comfortably short.

Otherwise, if making it accessible to mumble-server is acceptable I assume 
calling a script similar to the following (!untested!) one in certbot's 
post-hook would be better and allows to utilise a reload instead of restart:

  #!/bin/sh
  set -e
  umask 077
  mkdir -p /var/lib/mumble-server/ssl
  cp /etc/letsencrypt/live/mumble.example.org/fullchain.pem 
/var/lib/mumble-server/ssl
  cp /etc/letsencrypt/live/mumble.example.org/privkey.pem   
/var/lib/mumble-server/ssl
  chown -R mumble-server:mumble-server /var/lib/mumble-server/ssl
  service mumble-server reload

> Mumble upstream also suggests […]
> https://wiki.mumble.info/wiki/Obtaining_a_Let%27s_Encrypt_Murmur_Certificate

Yes, I've seen this suggestion before, but didn't like it due to security 
concerns and opted for starting murmur as root instead (which then drops root 
privileges on its own).

> I'm fairly interested in trying to find a good solution to this, because
> this permission problem is a common gripe that I hear from users on the
> Mumble IRC channel, so if a better solution can be found maybe I could have
> upstream add it to the wiki or the website so others could take advantage of
> it.
> 
>-- Chris

~~ Nils



Bug#980079: mumble-server: service restart and stop borked

2021-01-13 Thread Nils König
I must correct myself.

As I ofc only remembered after sending the bug report, I did already change 
the initscript once before to start as root (so it can read the root-owned ssl 
certs once on startup, before dropping privileges)

So in the default config, the --user switches shouldn't be a problem (but with 
CAPABILITIES enabled they probably still are) and the pidfile-dir permission 
should be the only problem.

~~ Nils



Bug#980079: mumble-server: service restart and stop borked

2021-01-13 Thread Nils König
Package: mumble-server
Version: 1.3.0~git20190125.440b173+dfsg-2
Severity: normal

Hi,

currently /etc/init.d/mumble-server stop doesn't does not stop the murmurd
and "restart" spawns an additional instance of mumble-server, leading to
various problems. I'd assume "force-reload" is similarly affected.

This is caused by two separate issues:

First the init script specifies "--user $USER", where $USER is "root"
by default. But murmur will (by default) drop itself to "mumble-server"
user; so this flag prevents start-stop-daemon from finding the process.
Removing the --user switches resolves this part. I've included the modified 
init-script below.

Second murmur does not write its own pidfile in the default setup.
I was able to fix this with
   chown root:mumble-server $PIDDIR && chmod g+w PIDDIR
This is a bit crude though and ideally murmurd would write its pidfile
_before_ dropping privileges instead if that's possible.
Apparently murmurd already does read ssl certificates before dropping
privileges.

There's also a related upstream issue, albeit apparently stale:
 https://github.com/mumble-voip/mumble/issues/2388

~~ Nils



-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 5.4.83-v7+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages mumble-server depends on:
ii  adduser3.118
ii  debconf [debconf-2.0]  1.5.71
ii  libatomic1 8.3.0-6+rpi1
ii  libavahi-client3   0.7-4+b1
ii  libavahi-common3   0.7-4+b1
ii  libavahi-compat-libdnssd1  0.7-4+b1
ii  libc6  2.28-10+rpi1
ii  libcap21:2.25-2
ii  libgcc11:8.3.0-6+rpi1
ii  libprotobuf17  3.6.1.3-2+rpi1
ii  libqt5core5a   5.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5dbus55.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5network5 5.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5sql5 5.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5sql5-sqlite  5.11.3+dfsg1-1+rpi1+deb10u4
ii  libqt5xml5 5.11.3+dfsg1-1+rpi1+deb10u4
ii  libssl1.1  1.1.1d-0+deb10u4+rpt1
ii  libstdc++6 8.3.0-6+rpi1
ii  libzeroc-ice3.73.7.2-4
ii  lsb-base   10.2019051400+rpi1

mumble-server recommends no packages.

mumble-server suggests no packages.

-- Configuration Files:
/etc/init.d/mumble-server changed:
PATH=/sbin:/bin:/usr/sbin:/usr/bin
NAME=mumble-server
DESC="Mumble VoIP Server"
PIDDIR=/run/$NAME
PIDFILE=$PIDDIR/$NAME.pid
DAEMON=/usr/sbin/murmurd
#USER=mumble-server
# mumble will drop to 'mumble-server' itself
USER=root
GROUP=mumble-server
test -x $DAEMON || exit 0
INIFILE=/etc/mumble-server.ini
DAEMON_OPTS="-ini $INIFILE"
MURMUR_USE_CAPABILITIES=0
MURMUR_LIMIT_NOFILE=0
if [ -f /etc/default/$NAME ] ; then
. /etc/default/$NAME
fi
. /lib/init/vars.sh
. /lib/lsb/init-functions
if [ "$MURMUR_LIMIT_NOFILE" -gt 0 ] ; then
ulimit -n $MURMUR_LIMIT_NOFILE
fi
case "$1" in
  start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
[ -d $PIDDIR ] || install -o $USER -d $PIDDIR
if [ "$MURMUR_USE_CAPABILITIES" != "1" ] ; then
  start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--chuid $USER:$GROUP \
--exec $DAEMON \
-- $DAEMON_OPTS
else
  start-stop-daemon --start --quiet \
--pidfile $PIDFILE \
--exec $DAEMON \
-- $DAEMON_OPTS
fi
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
  stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
start-stop-daemon --stop --quiet \
--retry=TERM/30/KILL/5 \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
case "$?" in
0|1)rm -f $PIDFILE
[ "$VERBOSE" != no ] && log_end_msg 0
;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
  status)
if start-stop-daemon --test --stop --quiet \
--pidfile $PIDFILE \
--exec $DAEMON
#--user $USER \
then
[ "

Bug#970535: (no subject)

2020-12-18 Thread Nils Griebner

Same behavior on my Thinkpad X13 (amd) with kernel 5.9.



Bug#970445: libfarstream-0.2-5: can't connect to video call via pidgin sipe

2020-09-16 Thread Nils Reichert
Package: libfarstream-0.2-5
Version: 0.2.8-4.1
Severity: normal
Tags: upstream

Dear Maintainer,


   * What led up to the situation?
In Pidgin, using the SIPE-Plugin, attempt to make a video call.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Attempt to make video call: in chat window/contact list select contact 
and click "voice/video-call"
   * What was the outcome of this action?
Setting up video call fails with error mesage "Error with your webcam"
   * What outcome did you expect instead?
Video call should be set up correctly
   * Possible solution:
This is a known problem documented in the plugins FAQ at 
https://sourceforge.net/p/sipe/wiki/Frequently%20Asked%20Questions/#video-call-setup-fails-with-the-error-message-error-with-your-webcam
The farstream version included in buster predates the patch mentioned 
there. Please include the patch or provide a newer version via backports.
   * Thanks:
Thank You!


-- System Information:
Distributor ID: Bunsenlabs
Description:BunsenLabs GNU/Linux 10.5 (Lithium)
Release:10.5
Codename:   buster
Architecture: x86_64

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

Versions of packages libfarstream-0.2-5 depends on:
ii  libc6   2.28-10
ii  libglib2.0-02.58.3-2+deb10u2
ii  libgstreamer-plugins-base1.0-0  1.14.4-2
ii  libgstreamer1.0-0   1.14.4-1
ii  libgupnp-1.0-4  1.0.3-3
ii  libgupnp-igd-1.0-4  0.2.5-3
ii  libnice10   0.1.14-1

Versions of packages libfarstream-0.2-5 recommends:
ii  gstreamer1.0-nice  0.1.16-1~bpo10+1
ii  gstreamer1.0-plugins-bad   1.14.4-1+b1
ii  gstreamer1.0-plugins-base  1.14.4-2
ii  gstreamer1.0-plugins-good  1.14.4-1

libfarstream-0.2-5 suggests no packages.

-- no debconf information



Bug#968096: reportbug: Can't detect OpenRC as init

2020-08-08 Thread Nils König
Package: reportbug
Version: 7.7.0
Severity: normal

Dear Maintainer,

Currently reportbug does not detect openrc as init system. (The same seems to 
apply to s6, but I never used s6).
What makes this a bit more complicated is, that it is possible to use openrc 
as 
a service manager and supervisor, but something else — eg sysv-init — as the 
actual init-system.
Or use openrc as init, but leave (some or all) process supervision to s6
  https://github.com/OpenRC/openrc/blob/master/s6-guide.md
.

I've attached patches that afaik should allow OpenRC to be correctly detected 
in 
a "normal" setup and also added a patch to check the name of the actual pid 1 
process, which should work for an openrc+sysv configuration.
I'm not sure what to do with openrc+s6 (and I never used both in conjunction) 
or
if this even matters.

Regards
Nils König

(Below information generated with patched reportbug; see attached patches)

-- Package-specific info:

-- System Information:
Debian Release: 10.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (10, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.12-pc3+fs (SMP w/16 CPU threads)
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: openrc (via /run/openrc)
PID 1: openrc-init
LSM: AppArmor: enabled

Versions of packages reportbug depends on:
ii  apt1.8.2.1
ii  python33.7.3-1
ii  python3-reportbug  7.7.0+openrc+pid1
ii  sensible-utils 0.0.12

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail
pn  debconf-utils 
ii  debsums   2.2.3
pn  default-mta | postfix | exim4 | mail-transport-agent  
pn  dlocate   
pn  emacs-bin-common  
ii  file  1:5.35-4+deb10u1
ii  gnupg 2.2.12-1+deb10u1
pn  python3-urwid 
pn  reportbug-gtk 
ii  xdg-utils 1.1.3-1+deb10u1

Versions of packages python3-reportbug depends on:
ii  apt1.8.2.1
ii  file   1:5.35-4+deb10u1
ii  python33.7.3-1
ii  python3-apt1.8.4.1
ii  python3-debian 0.1.35
ii  python3-debianbts  3.0.2
ii  python3-requests   2.21.0-1
ii  sensible-utils 0.0.12

python3-reportbug suggests no packages.

-- no debconf information


From eee54657ee872be51dcb4aced65d96d2b22818cb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nils=20K=C3=B6nig?= 
Date: Sat, 8 Aug 2020 01:02:12 +0200
Subject: [PATCH 1/2] reportbug/utils.py: Detect OpenRC as init

OPenRC's init is shipped as /sbin/openrc-init, but its mere
prescence does not indicate if OpenRC is actually used.
Therefore attempt to detect OpenRC by checking for its run-folder.
The caveat is, that openrc may be used as the service manager, but not
as the actual pid1 init system.
---
 reportbug/utils.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/reportbug/utils.py b/reportbug/utils.py
index a1c68b3..beb4828 100644
--- a/reportbug/utils.py
+++ b/reportbug/utils.py
@@ -1207,6 +1207,8 @@ def get_init_system():
 init = 'upstart (via init_is_upstart())'
 elif os.path.isfile('/run/runit.stopit'):
 init = 'runit (via /run/runit.stopit)'
+elif os.path.isdir('/run/openrc'):
+init = 'openrc (via /run/openrc)'
 elif os.path.isfile('/sbin/init') and not os.path.islink('/sbin/init'):
 init = 'sysvinit (via /sbin/init)'
 
-- 
2.20.1

From 292891d9e85b1339c1e0364d1f83dfbaba0dba8d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Nils=20K=C3=B6nig?= 
Date: Sat, 8 Aug 2020 01:12:12 +0200
Subject: [PATCH 2/2] reportbug/bugreport.py, reportbug/utils.py: Check PID 1
 name

It is possible to create setups, in which service-management and
pid1-init are done by different programms, eg openrc with sysv-init.
To have better chances at correctly identifying these setups, check the
PID 1 command name.
---
 reportbug/bugreport.py |  3 +++
 reportbug/utils.py | 13 +
 2 files changed, 16 insertions(+)

diff --git a/reportbug/bugreport.py b/reportbug/bugreport.py
index 920e045..d334852 100644
--- a/reportbug/bugreport.py
+++ b/reportbug/bugreport.py
@@ -83,6 +83,7 @@ class bugreport(object):
 debinfo = ''
 shellpath = utils.realpath('/bin/sh')
 init = utils.get_init_system()
+pid1 = utils.get_pid1_name()
 lsminfo = utils.get_lsm_info()
 taint_flags = utils.get_kernel_taint_flags()
 
@@ -190,6 +191,8 @@ class bugreport(object):
 debinfo += 'Shell: /bin/sh linked to %s\n' % shellpath
 if init:
 debinfo += 'Init: %s

Bug#964901: UTF-8 BOM can be moved while editing

2020-07-18 Thread Nils König
On Sat, Jul 18, 2020 at 18:53:34 +0200, Benno Schulenberg wrote:
> 
> Op 13-07-2020 om 01:56 schreef Nils König:
> > Basically, I imagined this just like:
> > 
> >> If nano were to handle a BOM properly, it must remove a BOM whenever
> >> a file is read, and add it back when it is written.  But that would
> >> make it impossible to delete an unwanted BOM with a simple backspace.
> >> Then the user would need to fall back to a tool like dos2unix.
> > 
> > But without the need for an external tool to remove a BOM, instead this 
> > could 
> > be toggled in the save dialog.
> 
> You want to have it both ways.  1) You want nano to hide the BOM from the
> user -- because the BOM is part of the file format and must of course stay
> where it is.  And 2) you want to be able to remove the BOM in some way.
> 
> But... in what circumstances would you want to remove the BOM?

If everything goes well a BOM is only present if really required for 
compatibility. If things don't go so well, I could imagine that an unneeded 
or unwanted BOM might slip in if a file was edited on another platform.
And might subsequently lead to parsing issues with eg software expecting 
ASCII-only or BOM-less UTF-8 input and checks for some magic character 
sequence at the start (like '#!')

 
> Another question.  These *.ass files, are they in DOS format?
> Or do you also have Unix files that start with a BOM?

Funnily enough, while aegisub will   always   add a BOM to UTF-8 *.ass files, 
it will use the system default for linebreaks, in my case UNIX CR.
*.ass files automatically created by ffmpeg on the other hand will always use 
DOS CRLF linebreaks.


Nils



Bug#965068: RFP: New Session Manager - Assists music production by grouping standalone programs into sessions.

2020-07-15 Thread Nils Hilbricht
Package: wnpp
Version: N/A; reported 2020-07-15
Severity: wishlist

* Package name : New Session Manager
Version : 1.4.0
Upstream Author : Hilbricht, Nils 
* URL : https://github.com/linuxaudio/new-session-manager
* License : (GPLv3, one ISC License header file, CC-By-Sa for Documentation)
Description : 

New Session Manager (NSM) is a tool to assist music production by grouping 
standalone programs into sessions. Your workflow becomes easy to manage, robust 
and fast by leveraging the full potential of cooperative applications.

It is a community version of the "NON Session Manager" and free in every sense 
of the word: free of cost, free to share and use, free of spyware or ads, 
free-and-open-source.

You can create a session, or project, add programs to it and then use commands 
to save, start/stop, hide/show all programs at once, or individually. At a 
later date you can then re-open the session and continue where you left off.


Dependencies are: liblo (OSC library), FLTK 1.3, JACK Audio Connection Kit 
(runtime)
Build system is meson.

This software already has been packaged for 

Fedora http://rpms.remirepo.net/rpmphp/zoom.php?rpm=new-session-manager
Archlinux 
https://www.archlinux.org/packages/community/x86_64/new-session-manager/
KXStudio https://kx.studio/Repositories:Applications
Ubuntu (Studio) approved, WIP


pgppoyZlGbuV0.pgp
Description: PGP signature


Bug#964901: UTF-8 BOM can be moved while editing

2020-07-12 Thread Nils König
On Sun, Jul 12, 2020 at 20:04:31 +0200, Benno Schulenberg wrote:
> Op 12-07-2020 om 16:26 schreef Nils König:
> > FWIW I would have expected leading BOM/NoBOM to be an option when saving 
> > with 
> > ^O (like DOS/Mac-Format) and by default keep status quo.
> 
> No-no-no, horrible!  The user ought not to be aware of the presence
> of a BOM.

Looking in the save dialogue was just my first intuition, others ways to 
handle this are fine too – or even better. Though I don't understand how this 
would make a user  more  aware of a BOM in a file; maybe I described it 
poorly. Basically, I imagined this just like:

> If nano were to handle a BOM properly, it must remove a BOM whenever
> a file is read, and add it back when it is written.  But that would
> make it impossible to delete an unwanted BOM with a simple backspace.
> Then the user would need to fall back to a tool like dos2unix.

But without the need for an external tool to remove a BOM, instead this could 
be toggled in the save dialog. (And only a BOM at the very beginning would be 
treated special)

  
>   Software that accepts UTF-8 ought not to require a BOM.
> Nano is a simple editor, a Unix editor  It is meant for editing emails,
> configuration files, shell scripts, and other plain text files.  There
> are never any BOMs there.  And now, because some people want to use nano
> to edit files with a silly required format, nano must adapt and treat a
> BOM as a sacred trio of bytes?

It is definitely not my intention to tell you what to do with nano. Sorry, if 
I failed to make this clear before.

But I think that nano's current handling of BOMs is not ideal – both 
for keeping and removing a BOM – and hope that my suggestions may help with 
that. If you decide that it is not needed this is fine too, now that I know 
about it I can take care on the few occasions I edit a BOMed file in nano.


> I've contemplated adding the attached patch, but then the user
> could still backspace over the BOM or cut the line unawares.
> 
> diff --git a/src/nano.c b/src/nano.c
> index 8e8b9952..db213857 100644
> --- a/src/nano.c
> +++ b/src/nano.c
> @@ -1649,6 +1649,8 @@ void process_a_keystroke(void)
>  #endif
>  }
>  
> +#define byte(n)  (unsigned char)openfile->current->data[openfile->current_x 
> + n]
> +
>  int main(int argc, char **argv)
>  {
>   int stdin_flags, optchr;
> @@ -2489,6 +2491,13 @@ int main(int argc, char **argv)
>   lastmessage = VACUUM;
>   as_an_at = TRUE;
>  
> +#if defined(ENABLE_UTF8) && !defined(NANO_TINY)
> + /* Tell the user when the cursor sits on a BOM. */
> + if (byte(0) == 0xEF && byte(1) == 0xBB && byte(2) == 0xBF) {
> + statusline(NOTICE, _("Byte Order Mark"));
> + beep();
> + }
> +#endif
>   /* Refresh just the cursor position or the entire edit window. 
> */
>   if (!refresh_needed) {
>   place_the_cursor();

This seems useful and makes it both harder to accidentally remove a bom and
easier to intentionally remove it. Though as you mentioned it's still possible 
to accidentally remove in some circumstances.


Nils



Bug#964901: UTF-8 BOM can be moved while editing

2020-07-12 Thread Nils König
Hello Benno,

thanks for your quick reply.

On Sun, Jul 12, 2020 at 13:15:41 +0200, Benno Schulenberg wrote:
> Ideally, a UTF-8 file should not contain a Byte Order Mark.  What if
> I concatenate several files together?  Then the result might contain
> BOMs embedded in the text.
> 
> As far as I know, BOM is only a problem with Windows and Google files.
> I do not know of any tool on Unix that adds a BOM to a UTF-8 file.

I agree, that a UTF8-BOM is usually not necessary. Probably because of
the mentioned compatibility reasons on Windows 'aegisub' does always 
include a BOM when saving as UTF-8 (concatenating two valid ASS files 
wouldn't produce a new valid ASS file anyway).


> […]  And the Unicode standard
> does not forbid the BOM from occurring elsewhere -- in that case
> it should be considered as a Zero Width Non Breaking Space.

Thanks for pointing it out, I wasn't aware of this. In that case it is
probably just good practice(?) to have a BOM only at the beginning.


> I could mitigate the problem by placing the cursor after the BOM
> when a file is opened.  (See attached patch.)  But you can still
> delete the BOM with , or put the cursor on it with
>  or .  For nano, all characters are just a group of
> bytes that can be added, deleted, restored, searched, and saved.
> 
> If I would make the BOM uneditable and unmovable, people could
> no longer use nano to get rid of a BOM in a file.
> 
>   https://bugs.launchpad.net/ubuntu/+source/nano/+bug/1045062

With the explanation having nano's current behaviour seems like a valid 
approach, though there's a chance a user, who isn't aware of it, might move or 
delete the BOM by accident. The patch would make this less likely (but it 
would still be possible).
FWIW I would have expected leading BOM/NoBOM to be an option when saving with 
^O (like DOS/Mac-Format) and by default keep status quo.  (looking at other 
editors, vim has this as :set bomb / :set nobomb ).
Or for the BOM to be visible. Though being visible would contradict the 
interpretation as a zero-width-nb-space, so maybe not.

Nils



Bug#964901: UTF-8 BOM can be moved while editing

2020-07-11 Thread Nils König
Package: nano
Version: 3.2-3
Severity: normal

Dear Maintainer,

when editing a UTF8 file in nano that contains a BOM (efbbbf) and inserting a 
character at the beginning, the BOM bytes will move after the inserted 
character. This can lead to breakages when such a file is being parsed by a 
programm as a BOM should, if at all present, only occur at the very beginning 
of the file.
Ideally nano should detect the presence of BOM and not have it be 
editable/moveable.

I've confirmed that this also affects version 4.9.3-1 as currently packaged in 
sid.

The initial file with correct BOM:
$ head -n 1 sample.ass | xxd
: efbb bf5b 5363 7269 7074 2049 6e66 6f5d  ...[Script Info]
0010: 0a

After inserting a leading space with nano:
$ head -n 1 sample-nano.ass | xxd
: 20ef bbbf 5b53 6372 6970 7420 496e 666f   ...[Script Info
0010: 5d0a ].

When doing the same with vim instead:
$ head -n 1 sample-vim.ass | xxd
: efbb bf20 5b53 6372 6970 7420 496e 666f  ... [Script Info
0010: 5d0a ].


I've attached an sample-file with correct and incorrect utf8 bom.

Regards
Nils


-- System Information:
Debian Release: 10.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (10, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 5.7.8-pc3+fs (SMP w/16 CPU cores)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: openrc
LSM: AppArmor: enabled

Versions of packages nano depends on:
ii  libc6 2.28-10
ii  libncursesw6  6.1+20181013-2+deb10u2
ii  libtinfo6 6.1+20181013-2+deb10u2
ii  zlib1g1:1.2.11.dfsg-1

nano recommends no packages.

Versions of packages nano suggests:
pn  spell  

-- no debconf information

[Script Info]
 [Script Info]
 [Script Info]


Bug#964252: Failure to build from source on buster

2020-07-04 Thread Nils König
Source: libbluray
Version: 1.1.0-1
Severity: serious
Tags: ftbfs

Hi,

Building from source fails on buster (amd64) while trying to create pdf docs.
Relevant log excerpt at end of mail, full log available here:
  https://oneric.de/public/libbluray-1.1.0-1_ftbfs.log
It seems like that, while no tex files are produced, doxygen still tries to 
build pdf docs.

I retrieved the source with
  apt-get source libbluray/buster
and tried building both with
  apt-get source -b libbluray/buster
and
 debuild -us -uc -b
Build dependencies were installed with mk-build-deps.

System: Debian Buster amd64
 libc6   2.28-10
 doxygen 1.8.13-10
 texlive 2018.20190227-2


Either dropping patch 0004-Disable-PDF-documentation or adding

confflags += --disable-doxygen-pdf
confflags += --disable-doxygen-ps

to debian/rules resolved this for me.

Regards
Nils König


---

[…]
Generating file index...
Generating file member index...
Generating example index...
finalizing index lists...
writing tag file...
lookup cache used 359/65536 hits=1092 misses=366
finished...
cd doc/doxygen/latex; \
rm -f *.aux *.toc *.idx *.ind *.ilg *.log *.out; \
/usr/bin/latex refman.tex; \
 refman.idx; \
/usr/bin/latex refman.tex; \
countdown=5; \
while /usr/bin/egrep 'Rerun (LaTeX|to get cross-references right)' \
refman.log > /dev/null 2>&1 \
&& test $countdown -gt 0; do \
/usr/bin/latex refman.tex; \
countdown=`expr $countdown - 1`; \
done; \
/usr/bin/dvips -o ../libbluray.ps refman.dvi
/bin/bash: line 0: cd: doc/doxygen/latex: No such file or directory
This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2019/dev/Debian) 
(preloaded format=latex)
 restricted \write18 enabled.
entering extended mode
! I can't find file `refman.tex'.
<*> refman.tex
  
(Press Enter to retry, or Control-D to exit)
Please type another input file name:



Bug#961853: micro crashes at startup

2020-05-30 Thread Nils Dagsson Moskopp
Package: micro
Version: 2.0.3-1~bpo10+1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

a friend just suggested that I try the “micro” text editor.
I installed the software using “sudo apt-get install micro”.

I executed the command “micro” from a terminal. Instead of starting an 
editor, the terminal contents look all weird and only executing “reset” 
brings it into a usable state again. I see no text editor anywhere.

I managed to capture the error messages by redirecting the standard 
error to a file, which I have appended to this bug report.

-- System Information:
Debian Release: 10.2
  APT prefers stable
  APT policy: (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

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

Versions of packages micro depends on:
ii  libc6  2.28-10

Versions of packages micro recommends:
ii  xclip  0.13-1

micro suggests no packages.

-- no debconf information
unexpected fault address 0x80cda9e9
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x80cda9e9 pc=0x9b2896]

goroutine 1 [running]:
runtime.throw(0x9fa5fc, 0x5)
/usr/lib/go-1.11/src/runtime/panic.go:608 +0x70 fp=0x23d2de0 
sp=0x23d2dcc pc=0x52cb00
runtime.sigpanic()
/usr/lib/go-1.11/src/runtime/signal_unix.go:397 +0x1e4 fp=0x23d2e04 
sp=0x23d2de0 pc=0x542224
github.com/zyedidia/micro/internal/display.(*BufWindow).Relocate(0x2231d00, 
0x9b2215)
github.com/zyedidia/micro/internal/display/bufwindow.go:153 +0x126 
fp=0x23d2e40 sp=0x23d2e04 pc=0x9b2896
github.com/zyedidia/micro/internal/display.(*BufWindow).Resize(0x2231d00, 0x50, 
0x17)
github.com/zyedidia/micro/internal/display/bufwindow.go:57 +0x32 
fp=0x23d2e4c sp=0x23d2e40 pc=0x9b2242
github.com/zyedidia/micro/internal/action.(*BufPane).Resize(0x2068d20, 0x50, 
0x17)
:1 +0x3e fp=0x23d2e5c sp=0x23d2e4c pc=0x9dc17e
github.com/zyedidia/micro/internal/action.(*Tab).Resize(0x2231ce0)
github.com/zyedidia/micro/internal/action/tab.go:296 +0xd1 fp=0x23d2e8c 
sp=0x23d2e5c pc=0x9d5dd1
github.com/zyedidia/micro/internal/action.(*TabList).Resize(0x21ae820)
github.com/zyedidia/micro/internal/action/tab.go:92 +0x210 fp=0x23d2ec4 
sp=0x23d2e8c pc=0x9d5070
github.com/zyedidia/micro/internal/action.(*TabList).HandleEvent(0x21ae820, 
0xc85970, 0x21a4040)
github.com/zyedidia/micro/internal/action/tab.go:102 +0x1b8 
fp=0x23d2edc sp=0x23d2ec4 pc=0x9d5298
main.main()
github.com/zyedidia/micro/cmd/micro/micro.go:316 +0x5b2 fp=0x23d2fd0 
sp=0x23d2edc pc=0x9f6b02
runtime.main()
/usr/lib/go-1.11/src/runtime/proc.go:201 +0x289 fp=0x23d2ff0 
sp=0x23d2fd0 pc=0x52e619
runtime.goexit()
/usr/lib/go-1.11/src/runtime/asm_386.s:1324 +0x1 fp=0x23d2ff4 
sp=0x23d2ff0 pc=0x558771

goroutine 5 [syscall]:
os/signal.signal_recv(0x0)
/usr/lib/go-1.11/src/runtime/sigqueue.go:139 +0x157
os/signal.loop()
/usr/lib/go-1.11/src/os/signal/signal_unix.go:23 +0x1b
created by os/signal.init.0
/usr/lib/go-1.11/src/os/signal/signal_unix.go:29 +0x3d

goroutine 17 [select]:
github.com/zyedidia/tcell.(*tScreen).mainLoop(0x20dc420)
github.com/zyedidia/tcell/tscreen.go:1411 +0x166
created by github.com/zyedidia/tcell.(*tScreen).Init
github.com/zyedidia/tcell/tscreen.go:198 +0x623

goroutine 18 [IO wait]:
internal/poll.runtime_pollWait(0xa7a95fc0, 0x72, 0x5ae26a)
/usr/lib/go-1.11/src/runtime/netpoll.go:173 +0x4c
internal/poll.(*pollDesc).wait(0x21501d4, 0x72, 0xff01, 0xc85150, 0x5c60e5)
/usr/lib/go-1.11/src/internal/poll/fd_poll_runtime.go:85 +0x99
internal/poll.(*pollDesc).waitRead(0x21501d4, 0x2234001, 0x1000, 0x1000)
/usr/lib/go-1.11/src/internal/poll/fd_poll_runtime.go:90 +0x33
internal/poll.(*FD).Read(0x21501c0, 0x2234000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/lib/go-1.11/src/internal/poll/fd_unix.go:169 +0x152
os.(*File).read(0x211df90, 0x2234000, 0x1000, 0x1000, 0x0, 0x0, 0x0)
/usr/lib/go-1.11/src/os/file_unix.go:249 +0x3e
os.(*File).Read(0x211df90, 0x2234000, 0x1000, 0x1000, 0x1000, 0x1000, 0x0)
/usr/lib/go-1.11/src/os/file.go:108 +0x52
github.com/zyedidia/tcell.(*tScreen).inputLoop(0x20dc420)
github.com/zyedidia/tcell/tscreen.go:1464 +0x9b
created by github.com/zyedidia/tcell.(*tScreen).Init
github.com/zyedidia/tcell/tscreen.go:199 +0x646

goroutine 9 [select]:
github.com/zyedidia/tcell.(*tScreen).PollEvent(0x20dc420, 0x23dd7e4, 0x21a4040)
github.com/zyedidia/tcell/tscreen.go:819 +0x97
main.main.func3()
github.com/zyedidia/micro/cmd/micro/micro.go:299 +0x33
created by main.main
github.com/zyedidia/micro/cmd/micro/micro.go:296 +0x4a1


Bug#960285: License information for libmariadb3 outdated

2020-05-11 Thread Nils Rennebarth
Package: mariadb-10.3
Version: 10.3.22-1

The debian copyright file of the source package is outdated. It still claims 
that all files in the source are GPL-2 licensed. It does mention various 
exceptions, but it does not mention that the client library:

Files: libmariadb/*
Copyright:
 ...
License: LGPL-2.1

is LGPL'ed as stated in libmariadb/COPYING.LIB and libmariadb/README

Also the files there bear copyright notices like

  2000, 2012 MySQL AB & MySQL Finland AB & TCX DataKonsult AB, Monty Program AB
  2016 MariaDB Corporation AB

This is due to the fact that mariadb-10.3 now includes the code of 
mariadb-connector-c as the client library, instead of the original mysql client 
library, that was indeed GPL-2'ed.

Best regards, Nils Rennebarth

-- 
Dipl. Math Nils Rennebarth
Senior Berater Entwicklung
Division Network & Client security
secunet Security Networks AG 
 

Tel.: +49 201 5454-3976
Fax: +49 711 900300-90
Mobil: +49 174 9750449
E-Mail: nils.renneba...@secunet.com


Neue Brücke 3
70173 Stuttgart
www.secunet.com

__

Sitz: Kurfürstenstraße 58, 45138 Essen, Deutschland 
Amtsgericht Essen HRB 13615
Vorstand: Axel Deininger (Vors.), Torsten Henn, Dr. Kai Martius, Thomas Pleines 
Aufsichtsratsvorsitzender: Ralf Wintergerst
__



Bug#949369: i915: kernel crash in i915_active_acquire()

2020-02-18 Thread Nils Jarle Haugen

Dear maintainers,

I experienced the same crash today. I have the Lenovo t470p with the 
i915 (Intel HD 630 graphics) and the NVIDIA 940MX dedicated graphics 
card. I statically switch between intel and nvidia with xrandr and sddm 
scrpts (using 
https://wiki.debian.org/NvidiaGraphicsDrivers/Optimus#Configuration).


On the occasion when the system crashed, the xrandr and sddm scripts 
were commented out and not actively in use (but the nvidia kernel module 
was still loaded).


The crash left the system in a unusable state, needed to call sysrq to 
force restart it.


I'll try to purge the proprietary drivers and then try to reproduce the 
issue.



Kind regards,
Nils J. Haugen


Distributor ID: Debian
Description:    Debian GNU/Linux bullseye/sid
Release:    testing
Codename:   bullseye
5.4.0-3-amd64

Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.793555] i915 
:00:02.0: GPU HANG: ecode 9:1:0x, hang on rcs0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.794565] i915 
:00:02.0: Resetting rcs0 for hang on rcs0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.795587] i915 
:00:02.0: Resetting chip for hang on rcs0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846861] [ cut 
here ]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846871] invalid opcode: 
 [#1] SMP PTI
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846875] CPU: 1 PID: 4125 
Comm: Unity Tainted: G   OE 5.4.0-3-amd64 #1 Debian 5.4.13-1
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846878] Hardware name: 
LENOVO 20J6CTO1WW/20J6CTO1WW, BIOS R0FET50W (1.30 ) 07/03/2019
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846885] RIP: 
0010:__list_del_entry_valid.cold+0x31/0x55
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846889] Code: 61 0e a3 e8 
d4 1d ce ff 0f 0b 48 c7 c7 50 62 0e a3 e8 c6 1d ce ff 0f 0b 48 89 f2 48 
89 fe 48 c7 c7 10 62 0e a3 e8 b2 1d ce ff <0f> 0b 48 89 fe 4c 89 c2 48 
c7 c7 d8 61 0e a3 e8 9e 1d ce ff 0f 0b
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846892] RSP: 
0018:ba9dc91978a0 EFLAGS: 00010046
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846895] RAX: 
0054 RBX: a0769e0d4fc0 RCX: 
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846897] RDX: 
 RSI: a0783e257688 RDI: a0783e257688
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846899] RBP: 
a0783b9b6068 R08: a0783e257688 R09: 0063
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846901] R10: 
ba9dc9197750 R11:  R12: a0783b9b6000
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846903] R13: 
a0783b9b6000 R14: a0783267c180 R15: a078300f7ae8
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846906] FS: 
7f571b4992c0() GS:a0783e24() knlGS:
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846908] CS:  0010 DS: 
 ES:  CR0: 80050033
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846910] CR2: 
7f5717f28000 CR3: 000432e5e004 CR4: 003606e0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846913] DR0: 
 DR1:  DR2: 
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846915] DR3: 
 DR6: fffe0ff0 DR7: 0400

Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846916] Call Trace:
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.846989] 
i915_request_retire+0xc9/0x380 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847042] 
retire_requests+0x4e/0x60 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847088] 
i915_retire_requests+0xa9/0x230 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847133] 
i915_gem_evict_for_node+0x264/0x2b0 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847176] 
i915_gem_gtt_reserve+0x45/0x70 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847222] 
__i915_vma_do_pin+0x1d7/0x490 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847265] 
eb_lookup_vmas+0xa90/0xb90 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847305]  ? 
intel_gt_terminally_wedged+0x23/0xf0 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847344] 
i915_gem_do_execbuffer+0x67c/0x1520 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847352]  ? 
shmem_alloc_page+0x47/0x90
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847356]  ? 
xas_store+0x56/0x5e0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847362]  ? 
mem_cgroup_charge_statistics+0x4c/0xd0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847365]  ? 
mem_cgroup_commit_charge+0x5f/0x4e0
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847370]  ? 
__kmalloc_node+0x1f5/0x300
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847407] 
i915_gem_execbuffer2_ioctl+0x1df/0x3d0 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847445]  ? 
i915_gem_execbuffer_ioctl+0x2e0/0x2e0 [i915]
Feb 18 15:29:29 nilsjarle-t470p kernel: [ 6312.847466] 
drm_ioctl_kernel+0xaa/0xf0 [drm]
Feb 18 15:29:29 nilsjarle

Bug#948257: Testet Patch mentioned by Salvatore Bonaccorso

2020-01-07 Thread nils
The small patch at 
https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/23 
(https://salsa.debian.org/kernel-team/initramfs-tools/merge_requests/23) works 
fine.

Before:
100s of depmod: ERROR: ../libkmod/libkmod.c:515 lookup_builtin_file() could not 
open builtin file 
'/var/tmp/mkinitramfs_DkdaZa/lib/modules/5.4.0-2-amd64/modules.builtin.bin

With patch:
No Errors.


Bug#946308: /usr/games/fs2_open: fs2_open crashes immediately (illegal instruction)

2019-12-07 Thread Nils Dagsson Moskopp
Bernhard Übelacker  writes:

> Dear Maintainer,
> I tried to reproduce inside a minimal Buster i386 qemu VM
> and received also an "Illegal instruction" message.
>
> It looks like it tries to execute an AVX instruction that
> my CPU should support, but is not enabled inside the VM.
>
> The usage of AVX might originate from the compiler
> flag "-march=native".
> This might be added in configure.ac, lines 149 or 163.

To clarify:

- line 149 is for a target architecture matching “x86_64-*-linux*”
- line 163 is for a target architecture matching “*-*-linux*”

In both cases, using “-march=native” seems like a wrong thing to use.
 states clearly:

Using -march=native enables all instruction subsets supported by the
local machine (hence the result might not run on different machines).

> The solution could be to just add this configure flag:
> -CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech
> +CONF_O=--bindir=/usr/games --disable-silent-rules --enable-speech 
> --enable-generic-architecture
>
> Then these flags get used instead:
>   -mtune=generic -mfpmath=sse -msse -msse2
> Do these also violate the i386 Buster baseline?
>
> Kind regards,
> Bernhard

I have re-built the Debian package according to those instructions and
it seems to work on my machine … Then again, I suspect this would also
have been the case if I just had rebuilt the package – due to “native”
architecture choice. It now gives an entirely different error message:

; cd /usr/share/games/freespace2-open/ && fs2_open
ERROR: " Web cursor bitmap not found.  This is most likely due to one of three 
reasons: 1) You're running FreeSpace Open from somewhere other than 
your FreeSpace 2 folder; 2) You've somehow corrupted your FreeSpace 2 
installation, e.g. by modifying or removing the retail VP files;   3) You 
haven't installed FreeSpace 2 at all.  (Note that installing FreeSpace Open 
does NOT remove the need for a FreeSpace 2 installation.) Number 1 can be fixed 
by simply moving the FreeSpace Open executable file to the FreeSpace 2 folder.  
Numbers 2 and 3 can be fixed by installing or reinstalling FreeSpace 2." at 
graphics/2d.cpp:1079
AL lib: (EE) alc_cleanup: 1 device not closed

I definitely have not installed FreeSpace 2 content, so I expect this.



Bug#946161: dia: CVE-2019-19451: Endless loop on filenames with invalid encoding can be used for denial-of-service

2019-12-04 Thread Nils Steinger
Package: dia
Version: 0.97.3+git20160930-8.1
Severity: critical
Tags: security upstream
Justification: breaks the whole system

Dear Maintainer,

when GNOME Dia before 2019-11-27 is launched with a filename argument
that is not a valid codepoint in the current encoding, it enters an
endless loop, thus endlessly writing text to stdout.
(The filename can be for a nonexistent file.)

If this launch is from a thumbnailer service, this output will usually
be written to disk via the system's logging facility (potentially with
elevated privileges), thus filling up the disk and eventually rendering
the system unusable.

Further details are available in the upstream bugreport [1] and the CVE
description [2].

Upstream (the GNOME Dia developers) has not tagged any official release
versions since 2011 (0.97.2), so Debian currently ships a more recent
state as 0.97.3+git20160930-8.2.
The vulnerability was introduced after the release of 0.97.2, and is
contained in all 0.97.3+* versions in Debian.

Could you please package the current development version of Dia, or
apply the (one-line) patch [3], to fix this vulnerability?

Kind regards,
Nils Steinger

[1]: https://gitlab.gnome.org/GNOME/dia/issues/428
[2]: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-19451
[3]: 
https://gitlab.gnome.org/GNOME/dia/commit/baa2df853f9fb770eedcf3d94c7f5becebc90bb9?merge_request_iid=50

-- System Information:
Debian Release: 10.2
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable'), (90, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages dia depends on:
ii  dia-common   0.97.3+git20160930-8.1
ii  libart-2.0-2 2.3.21-4
ii  libatk1.0-0  2.30.0-2
ii  libc62.28-10
ii  libcairo21.16.0-4
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3+deb10u1
ii  libgdk-pixbuf2.0-0   2.38.1+dfsg-1
ii  libglib2.0-0 2.58.3-2+deb10u2
ii  libgtk2.0-0  2.24.32-3
ii  libpango-1.0-0   1.42.4-7~deb10u1
ii  libpangocairo-1.0-0  1.42.4-7~deb10u1
ii  libpangoft2-1.0-01.42.4-7~deb10u1
ii  libpng16-16  1.6.36-6
ii  libpython2.7 2.7.16-2+deb10u1
ii  libxml2  2.9.4+dfsg1-7+b3
ii  libxslt1.1   1.1.32-2.2~deb10u1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages dia recommends:
ii  dia-shapes   0.6.0-3
ii  gsfonts-x11  0.26

dia suggests no packages.

-- no debconf information



Bug#940920: ktouch: unable to rend properly on hidpi displays, fixed in upstream 19.08.1

2019-09-21 Thread Nils Jarle Haugen
Package: ktouch
Version: 4:18.04.1-1
Severity: minor

Dear Maintainer,

When trying to use the program on hidpi displays & scaling enabled some
ui elements appear broken. The appliction is still fully functionable,
as this only affects the ui. I use a display with resolution of
2560x1440 px with 1.2 as scaling factor. I've uploaded a screenshot of
the situation: https://i.imgur.com/zQslGex.png 

19.08.1 has now been released upstream, and ktouch now supports hidpi
displays.Please see this blog for more information:

https://blog.sebasgo.net/2019/08/15/ktouch-in-kde-sc-19-08-0/

I hope it's possible to pull 19.08 soon to testing (or at least sid).

Thank you !

Best regards,
Nils Jarle Haugen


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

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

Versions of packages ktouch depends on:
ii  ktouch-data   4:18.04.1-1
ii  libc6 2.29-1
ii  libkf5completion5 5.54.0-1
ii  libkf5configcore5 5.54.0-2
ii  libkf5configgui5  5.54.0-2
ii  libkf5configwidgets5  5.54.0-1
ii  libkf5coreaddons5 5.54.0-1
ii  libkf5declarative55.54.0-1
ii  libkf5i18n5   5.54.0-1
ii  libkf5itemviews5  5.54.0-1
ii  libkf5kcmutils5   5.54.0-1
ii  libkf5service-bin 5.54.0-1
ii  libkf5service55.54.0-1
ii  libkf5textwidgets55.54.0-1
ii  libkf5widgetsaddons5  5.54.0-1
ii  libkf5xmlgui5 5.54.0-1
ii  libqt5core5a  5.11.3+dfsg1-4
ii  libqt5gui55.11.3+dfsg1-4
ii  libqt5qml55.11.3-4
ii  libqt5quick5  5.11.3-4
ii  libqt5quickwidgets5   5.11.3-4
ii  libqt5sql55.11.3+dfsg1-4
ii  libqt5widgets55.11.3+dfsg1-4
ii  libqt5x11extras5  5.11.3-2
ii  libqt5xml55.11.3+dfsg1-4
ii  libqt5xmlpatterns55.11.3-2
iu  libstdc++69.2.1-8
ii  libx11-6  2:1.6.7-1
ii  libxcb-xkb1   1.13.1-2
ii  libxcb1   1.13.1-2

ktouch recommends no packages.

ktouch suggests no packages.

-- no debconf information



Bug#935057: RM: afl -- ROM; upstream not actively developed anymore

2019-09-08 Thread Nils Dagsson Moskopp
Paul Tagliamonte  writes:

> Well, seeing as how Daniel Is the maintainer, perhaps one of you can take
> over as maintainer and rename / reassign this bug to an adoption.
>
> How does that sound, all?

If no one is willing, I can be a maintainer, but I have no experience.

I have been asking around for maintainers for some days now.

Please reassign this bug to an adoption soon.



Bug#939770: wireshark: Wrong path in pre-install notification

2019-09-08 Thread Nils Dagsson Moskopp
Package: wireshark
Version: 2.6.7-1~deb9u1
Severity: minor

Dear Maintainer,

in the pre-install notification about installing dumpcamp so that
non-root users can capture packets it is displayed that users can
read about that feature in the file at the following path:

/usr/share/doc/wireshark-common/README.Debian

A file does not actually exist at the path.
After installation, it does also not exist.
However, the following path holds the file:

/usr/share/doc/wireshark-common/README.Debian.gz

I suggest to change path in the question and make it clear that the
file will only exist after the package is installed – even though a
text mentioning it might be shown before installation is completed.

-- System Information:
Debian Release: 9.9
  APT prefers oldstable-updates
  APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-7-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages wireshark depends on:
ii  wireshark-qt  2.6.7-1~deb9u1

wireshark recommends no packages.

wireshark suggests no packages.

-- no debconf information


Bug#935057: RM: afl -- ROM; upstream not actively developed anymore

2019-08-30 Thread Nils Dagsson Moskopp
Package: ftp.debian.org
Followup-For: Bug #935057


According to this, there were 5 commits today:




Bug#927386: /lib/modules/4.9.0-7-686/kernel/drivers/gpu/drm/radeon/radeon.ko: “modprobe radeon 'modeset=1'” on Thinkpad R60: black screen, kernel NULL pointer dereference

2019-04-18 Thread Nils Dagsson Moskopp
Package: src:linux
Version: 4.9.110-3+deb9u2
Severity: important
File: /lib/modules/4.9.0-7-686/kernel/drivers/gpu/drm/radeon/radeon.ko

Dear Maintainer,

I boot Linux with Kernel Modesetting disabled. This is the only way to
prevent a completely black screen. Unfortunately, it limits me to VESA
graphics, i.e. no 3D at all – since User Modesetting is not available.

A “modprobe radeon 'modeset=0'” only generates this kernel message:
[drm:radeon_init [radeon]] *ERROR* No UMS support in radeon module!

Whenever I attempt to load the radeon module with modeseting enabled,
the screen immediately goes black. I expected it to actually load the
driver, change the resolution using Kernel Modesetting and give me 3D
rendering acceleration, via the radeon module. The kernel outputs the
lines after this paragraph, which mention the dereferencing of a NULL
pointer; I believe this is a program error in the radeon driver code.

[ 4374.923486] [drm] radeon kernel modesetting enabled.
[ 4374.923646] checking generic (d800 5b) vs hw (d800 800)
[ 4374.923649] fb: switching to radeondrmfb from VESA VGA
[ 4374.923775] Console: switching to colour dummy device 80x25
[ 4374.924928] [drm] initializing kernel modesetting (RV515 0x1002:0x7145 
0x17AA:0x2006 0x00).
[ 4374.924964] [drm] register mmio base: 0xEE00
[ 4374.924967] [drm] register mmio size: 65536
[ 4374.925149] ATOM BIOS: M54CSP/M52CSP
[ 4374.925173] [drm] Generation 2 PCI interface, using max accessible memory
[ 4374.925183] radeon :01:00.0: VRAM: 128M 0x - 
0x07FF (128M used)
[ 4374.925190] radeon :01:00.0: GTT: 512M 0x0800 - 
0x27FF
[ 4374.927419] [drm] Detected VRAM RAM=128M, BAR=128M
[ 4374.927423] [drm] RAM width 128bits DDR
[ 4374.936146] [TTM] Zone  kernel: Available graphics memory: 440242 kiB
[ 4374.936150] [TTM] Zone highmem: Available graphics memory: 1033590 kiB
[ 4374.936152] [TTM] Initializing pool allocator
[ 4374.936214] [drm] radeon: 128M of VRAM memory ready
[ 4374.936217] [drm] radeon: 512M of GTT memory ready.
[ 4374.936251] [drm] GART: num cpu pages 131072, num gpu pages 131072
[ 4374.937907] [drm] radeon: power management initialized
[ 4374.940380] [drm] radeon: 1 quad pipes, 1 z pipes initialized.
[ 4374.947928] [drm] PCIE GART of 512M enabled (table at 0x0004).
[ 4374.947982] radeon :01:00.0: WB enabled
[ 4374.947991] radeon :01:00.0: fence driver on ring 0 use gpu addr 
0x0800 and cpu addr 0xf2ea1000
[ 4374.947995] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 4374.947997] [drm] Driver supports precise vblank timestamp query.
[ 4374.948001] radeon :01:00.0: radeon: MSI limited to 32-bit
[ 4374.948064] [drm] radeon: irq initialized.
[ 4374.948100] [drm] Loading R500 Microcode
[ 4374.951990] radeon :01:00.0: firmware: direct-loading firmware 
radeon/R520_cp.bin
[ 4374.953018] [drm] radeon: ring at 0x08001000
[ 4374.953060] [drm] ring test succeeded in 9 usecs
[ 4374.953433] [drm] ib test succeeded in 0 usecs
[ 4374.954709] [drm] Radeon Display Connectors
[ 4374.954712] [drm] Connector 0:
[ 4374.954713] [drm]   VGA-1
[ 4374.954718] [drm]   DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 
0x7e4c
[ 4374.954720] [drm]   Encoders:
[ 4374.954722] [drm] CRT1: INTERNAL_KLDSCP_DAC1
[ 4374.954724] [drm] Connector 1:
[ 4374.954726] [drm]   LVDS-1
[ 4374.954731] [drm]   DDC: 0x7e60 0x7e60 0x7e64 0x7e64 0x7e68 0x7e68 0x7e6c 
0x7e6c
[ 4374.954732] [drm]   Encoders:
[ 4374.954734] [drm] LCD1: INTERNAL_LVTM1
[ 4374.954736] [drm] Connector 2:
[ 4374.954738] [drm]   SVIDEO-1
[ 4374.954739] [drm]   Encoders:
[ 4374.954741] [drm] TV1: INTERNAL_KLDSCP_DAC2
[ 4374.954743] [drm] Connector 3:
[ 4374.954745] [drm]   DVI-I-1
[ 4374.954747] [drm]   HPD1
[ 4374.954751] [drm]   DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 
0x7e5c
[ 4374.954753] [drm]   Encoders:
[ 4374.954755] [drm] DFP1: INTERNAL_KLDSCP_TMDS1
[ 4375.348177] [drm] fb mappable at 0xD80C
[ 4375.348181] [drm] vram apper at 0xD800
[ 4375.348183] [drm] size 5914624
[ 4375.348185] [drm] fb depth is 24
[ 4375.348187] [drm]pitch is 5632
[ 4375.348428] fbcon: radeondrmfb (fb0) is primary device
[ 4375.348793] Console: switching to colour frame buffer device 175x65
[ 4375.348807] radeon :01:00.0: fb0: radeondrmfb frame buffer device
[ 4375.364112] [drm] Initialized radeon 2.49.0 20080528 for :01:00.0 on 
minor 0
[ 4375.364854] PCI registers are not implemented.
[ 4375.364890] BUG: unable to handle kernel NULL pointer dereference at 0124
[ 4375.365041] IP: [] atom_get_src_int+0x626/0x6f0 [radeon]
[ 4375.365209] *pde =  

[ 4375.365270] Oops:  [#1] SMP
[ 4375.365324] Modules linked in: radeon btrfs xor raid6_pq ufs qnx4 hfsplus 
hfs minix ntfs vfat msdos fat jfs xfs libcrc32c ctr ccm snd_hrtimer snd_seq 
snd_seq_device fuse binfmt_misc iTCO_wdt iTCO_vendor_support arc4 pcmcia 
coretemp ttm iwl3945 drm_kms_helper 

Bug#925475: clamav-freshclam.service is "inactive (dead)" after logrotate postrotate script execution

2019-03-26 Thread Nils Fahldieck - Profihost AG
Am 25.03.19 um 18:45 schrieb Adam D. Barratt:
> On 2019-03-25 15:39, Nils Fahldieck - Profihost AG wrote:
>> libc6 Version: 2.24-11+deb9u4
>> systemd Version: 232-25+deb9u9
>> Debian Version: Debian GNU/Linux 9 (stretch)
>>
>> The `postrotate` script in `/etc/logrotate.d/clamav-freshclam` executes
>> this code if systemd is used:
>>
>> $ cat /etc/logrotate.d/clamav-freshclam
>>  postrotate
>>  if [ -d /run/systemd/system ]; then
>>  systemctl -q is-active clamav-freshclam && systemctl kill
>> --signal=SIGHUP clamav-freshclam || true
>>
>> Whenever logrotate rotates freshclam's logfile, the service is inactive
>> (dead) afterwards.
>>
>> Reproducer:
>>
>> $ systemctl is-active clamav-freshclam
>> active
>> $ systemctl -q is-active clamav-freshclam && systemctl kill
>> --signal=SIGHUP clamav-freshclam || true
>> $ systemctl is-active clamav-freshclam
>> inactive
>> $ systemctl status clamav-freshclam.service
>> ● clamav-freshclam.service - ClamAV virus database updater
>>    Loaded: loaded (/lib/systemd/system/clamav-freshclam.service;
>> enabled; vendor preset: enabled)
>>   Drop-In: /etc/systemd/system/clamav-freshclam.service.d
>>    └─limits.conf
>>    Active: inactive (dead) since Mon 2019-03-25 16:28:25 CET; 2s ago
>>  Docs: man:freshclam(1)
> 
> fwiw, I can't reproduce this.
> 
> clamav-freshclam 0.100.2+dfsg-0+deb9u1
> libc6 2.24-11+deb9u4
> systemd 232-25+deb9u9
> 
> ● clamav-freshclam.service - ClamAV virus database updater
>    Loaded: loaded (/lib/systemd/system/clamav-freshclam.service;
> enabled; vendor preset: enabled)
>    Active: active (running) since Sun 2019-03-10 19:07:03 GMT; 2 weeks 0
> days ago
> ..
> 
> -rw-r- 1 clamav adm   4754 Mar 11 06:25
> /var/log/clamav/freshclam.log.3.gz
> -rw-r- 1 clamav adm   3544 Mar 17 06:25
> /var/log/clamav/freshclam.log.2.gz
> -rw-r- 1 clamav adm 312142 Mar 24 06:25 /var/log/clamav/freshclam.log.1
> -rw-r- 1 clamav adm  65671 Mar 25 17:25 /var/log/clamav/freshclam.log
> 
> also:
> 
> # systemctl is-active clamav-freshclam
> active
> # systemctl -q is-active clamav-freshclam && systemctl kill
> --signal=SIGHUP clamav-freshclam || true
> # systemctl is-active clamav-freshclam
> active
> 
> Aahhh... My guess would be that this is due to your local
> customisation:
> 
>  Drop-In: /etc/systemd/system/clamav-freshclam.service.d
>    └─limits.conf
> ...
>   Process: 15231 ExecStart=/usr/bin/cpulimit -f -l 5 --
> /usr/bin/freshclam -d --foreground=true (code=killed, signal=HUP)
> 
> which means that the HUP will be being sent to cpulimit, not to freshclam.
> 
> I'm not a clamav maintainer, but I'd be inclined at this point to say
> that this is not a problem with the package, and "you get to keep the
> pieces", I'm afraid. From a quick bit of research, I would suggest that
> you want to be using systemd's built-in
> https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#CPUQuota=
> , which would entirely avoid this issue.
> 
> Regards,
> 
> Adam

Hi Adam,

thank you very much for your answer and your time. You've guided me in
the right direction. In fact cpulimit receives the SIGHUP, which kills
the whole Cgroup of clamav-freshclam.

Regarding your suggestion to use CPUQuota: I will look more into
systemd's own options and use them the next time round.

So this is *not* a bug in clamav-freshclam package. I'm very sorry for
this false bug report.

Kind Regards,
Nils



Bug#925475: clamav-freshclam.service is "inactive (dead)" after logrotate postrotate script execution

2019-03-25 Thread Nils Fahldieck - Profihost AG
Package: clamav-freshclam
Version: 0.100.2+dfsg-0+deb9u1
Severity: important

libc6 Version: 2.24-11+deb9u4
systemd Version: 232-25+deb9u9
Debian Version: Debian GNU/Linux 9 (stretch)

The `postrotate` script in `/etc/logrotate.d/clamav-freshclam` executes
this code if systemd is used:

$ cat /etc/logrotate.d/clamav-freshclam
 postrotate
 if [ -d /run/systemd/system ]; then
 systemctl -q is-active clamav-freshclam && systemctl kill
--signal=SIGHUP clamav-freshclam || true

Whenever logrotate rotates freshclam's logfile, the service is inactive
(dead) afterwards.

Reproducer:

$ systemctl is-active clamav-freshclam
active
$ systemctl -q is-active clamav-freshclam && systemctl kill
--signal=SIGHUP clamav-freshclam || true
$ systemctl is-active clamav-freshclam
inactive
$ systemctl status clamav-freshclam.service
● clamav-freshclam.service - ClamAV virus database updater
   Loaded: loaded (/lib/systemd/system/clamav-freshclam.service;
enabled; vendor preset: enabled)
  Drop-In: /etc/systemd/system/clamav-freshclam.service.d
   └─limits.conf
   Active: inactive (dead) since Mon 2019-03-25 16:28:25 CET; 2s ago
 Docs: man:freshclam(1)
   man:freshclam.conf(5)
   https://www.clamav.net/documents
  Process: 15231 ExecStart=/usr/bin/cpulimit -f -l 5 --
/usr/bin/freshclam -d --foreground=true (code=killed, signal=HUP)
 Main PID: 15231 (code=killed, signal=HUP)
  CPU: 57ms

Logrotate for freshclam runs once every week at 06:25. This run was on
2019-03-17, two days later at 2019-03-19 I used my config management to
ensure a highstate. During that run freshclam was started - as defined
in my states:

$ journalctl -x -u clamav-freshclam.service --since 2019-03-16
Mär 17 06:26:06 hostname cpulimit[8290]: Sun Mar 17 06:26:06 2019 ->
Update process terminated
Mär 19 06:22:52 hostname systemd[1]: Started ClamAV virus database updater.
-- Subject: Unit clamav-freshclam.service has finished start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit clamav-freshclam.service has finished starting up.
-- 
-- The start-up result is done.
Mär 19 06:22:53 hostname cpulimit[29197]: Tue Mar 19 06:22:53 2019 ->
ClamAV update process started at Tue Mar 19 06:22:53 2019


I can just guess, that SIGHUP might be the wrong signal to tell
freshclam to re-open its log file.

This bug is in so far dangerous, as freshclam will not update clamav's
virus definitions anymore. Also clamav-freshclam.service is not failed.

Thank you, Nils



Bug#623537: virt-manager: Confirms issue

2019-03-04 Thread Nils Jarle Haugen

Dear maintainer,


I can confirm that i fixed the issue after consulting with some support 
over at the #virt channel on OFTC.
The issue was that the libvirt system user account (libvirt-qemu) was 
not a member of the plugdev group, which owns /dev/kvm.


After adding the libvirt-qemu to the plugdev group, libvirt recognises 
KVM and runs as normal.


I'm not sure how this happend, as I've never done any changes to that group.



Kind regards,

Nils J. Haugen


On Mon, 25 Feb 2019 11:30:40 +0100 nils+bugl...@gaupne.net wrote:
> Package: virt-manager
> Version: 1:2.0.0-3
> Followup-For: Bug #623537
>
> Dear Maintainer,
>
>
> I can confirm to experience the same issue, virt-manager/libvirt are
> unable to detect the presence of KVM on the system. It stopped working
> after updating to version 1.2.0.0-3. Virt-manager the tries to run the
> virtual machines with QEMU TCG...
>
> I've checked with both lsmod and kvm-ok and they reports that the
> required modules are
> loaded.  Intel Virtualisation Technology is enabled in BIOS.
> The CPU running on the machineis an i7 7820HQ. I've tried purging all
> qemu-system-* libvirt-* packages and reinstalling qemu-kvm, 
libvirt-client,

> qemu-utils and libvirt-daemon-system
>
> As opposed to using libivirt I can run the virtual machines fine with
> qemu-system and
> experience bare-metal performance. So my guess is that this might be a
> bug in libvirt/ virt-manager, as the other systems can detect KVM us
> usual ?
>
> Best regards,
> Nils J. Haugen
>
> -- System Information:
> Debian Release: buster/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: amd64 (x86_64)
> Foreign Architectures: i386
>
> Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
> Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
> Locale: LANG=nn_NO.UTF-8, LC_CTYPE=nn_NO.UTF-8 (charmap=UTF-8),
> LANGUAGE=en_US (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> LSM: AppArmor: enabled
>
> Versions of packages virt-manager depends on:
> ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
> ii  gir1.2-gtk-3.0   3.24.5-1
> ii  gir1.2-gtk-vnc-2.0   0.9.0-1
> ii  gir1.2-libosinfo-1.0 1.2.0-1
> ii  gir1.2-libvirt-glib-1.0  1.0.0-1
> ii  gir1.2-vte-2.91  0.54.2-2
> ii  librsvg2-common  2.44.10-1
> ii  python-requests  2.20.0-2
> ii  python3  3.7.2-1
> ii  python3-dbus 1.2.8-3
> ii  python3-gi   3.30.4-1
> ii  python3-gi-cairo 3.30.4-1
> ii  python3-libvirt  5.0.0-1
> ii  virtinst 1:2.0.0-3
>
> Versions of packages virt-manager recommends:



Bug#922191: typo in mirror update commit

2019-03-03 Thread Nils Hamerlinck
Hi,

This commit
<https://salsa.debian.org/mirror-team/masterlist/commit/b1905ba9511dc11494eb790feb5f1c7ba8bbb829>
seems
to have introduced a typo:

-Archive-http: /debian/
+*s*rchive-http: /debian/

Br,

Nils Hamerlinck


Bug#923452: gimp: fails with segfault when trying to change theme

2019-02-28 Thread nils+buglist

Package: gimp
Version: 2.10.8-2
Severity: important

Dear Maintainer,

GIMP segfaults when trying to select a different theme from the settings
menu. As a result of this, all unsaved work done in the program is lost.

I've not tried to change the theme before, so I'm unsure why this
happens.

How to reproduce:
1. Open a new, empty instance of GIMP
2. Open the Preferences window from Edit -> Preferences
3. Then in the tree view, select Interface -> Theme
4. Select one of the theme names in the list

The program then segfaults, instead of setting the theme as I expected.

I'm running KDE Plasma 5 with Global Menu activated (not sure if this
affects the theme of GIMP)

Please see the GIMP Crash Debug information for more information:
https://paste.debian.net/1070643/

Kind regards,

Nils J. Haugen

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

Kernel: Linux 4.19.0-2-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=nn_NO.UTF-8, LC_CTYPE=nn_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages gimp depends on:
ii  gimp-data    2.10.8-2
ii  libaa1   1.4p5-45
ii  libbabl-0.1-0    0.1.62-1
ii  libbz2-1.0   1.0.6-9
ii  libc6    2.28-7
ii  libcairo2    1.16.0-2
ii  libfontconfig1   2.13.1-2
ii  libfreetype6 2.9.1-3
ii  libgcc1  1:8.2.0-21
ii  libgdk-pixbuf2.0-0   2.38.0+dfsg-7
ii  libgegl-0.4-0    0.4.12-2
ii  libgexiv2-2  0.10.9-1
ii  libgimp2.0   2.10.8-2
ii  libglib2.0-0 2.58.3-1
ii  libgs9   9.26a~dfsg-2
ii  libgtk2.0-0  2.24.32-3
ii  libgudev-1.0-0   232-2
ii  libharfbuzz0b    2.3.1-1
ii  libheif1 1.3.2-1+b1
ii  libilmbase23 2.2.1-2
ii  libjpeg62-turbo  1:1.5.2-2+b1
ii  liblcms2-2   2.9-3
ii  liblzma5 5.2.4-1
ii  libmng1  1.0.10+dfsg-3.1+b5
ii  libmypaint-1.3-0 1.3.0-2.1
ii  libopenexr23 2.2.1-4
ii  libopenjp2-7 2.3.0-1.1
ii  libpango-1.0-0   1.42.4-6
ii  libpangocairo-1.0-0  1.42.4-6
ii  libpangoft2-1.0-0    1.42.4-6
ii  libpng16-16  1.6.36-5
ii  libpoppler-glib8 0.71.0-2
ii  librsvg2-2   2.44.10-1
ii  libstdc++6   8.2.0-21
ii  libtiff5 4.0.10-4
ii  libwebp6 0.6.1-2
ii  libwebpdemux2    0.6.1-2
ii  libwebpmux3  0.6.1-2
ii  libwmf0.2-7  0.2.8.4-14
ii  libx11-6 2:1.6.7-1
ii  libxcursor1  1:1.1.15-2
ii  libxext6 2:1.3.3-1+b2
ii  libxfixes3   1:5.0.3-1
ii  libxmu6  2:1.1.2-2
ii  libxpm4  1:3.5.12-1
ii  xdg-utils    1.1.3-1
ii  zlib1g   1:1.2.11.dfsg-1

Versions of packages gimp recommends:
ii  ghostscript  9.26a~dfsg-2

Versions of packages gimp suggests:
pn  gimp-data-extras  
ii  gimp-help-nn [gimp-help]  2.8.2-1
pn  gimp-python   
ii  gvfs-backends 1.38.1-3
ii  libasound2    1.1.8-1

-- no debconf information



Bug#623537: virt-manager: Confirms issue

2019-02-25 Thread nils+buglist

Package: virt-manager
Version: 1:2.0.0-3
Followup-For: Bug #623537

Dear Maintainer,


I can confirm to experience the same issue, virt-manager/libvirt are
unable to detect the presence of KVM on the system. It stopped working
after updating to version 1.2.0.0-3. Virt-manager the tries to run the
virtual machines with QEMU TCG...

I've checked with both lsmod and kvm-ok and they reports that the 
required modules are

loaded.  Intel Virtualisation Technology is enabled in BIOS.
The CPU running on the machineis an i7 7820HQ. I've tried purging all
qemu-system-* libvirt-* packages and reinstalling qemu-kvm, libvirt-client,
qemu-utils and libvirt-daemon-system

As opposed to using libivirt I can run the virtual machines fine with 
qemu-system and

experience bare-metal performance. So my guess is that this might be a
bug in libvirt/ virt-manager, as the other systems can detect KVM us
usual ?

Best regards,
Nils J. Haugen

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

Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=nn_NO.UTF-8, LC_CTYPE=nn_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages virt-manager depends on:
ii  dconf-gsettings-backend [gsettings-backend]  0.30.1-2
ii  gir1.2-gtk-3.0   3.24.5-1
ii  gir1.2-gtk-vnc-2.0   0.9.0-1
ii  gir1.2-libosinfo-1.0 1.2.0-1
ii  gir1.2-libvirt-glib-1.0  1.0.0-1
ii  gir1.2-vte-2.91  0.54.2-2
ii  librsvg2-common  2.44.10-1
ii  python-requests  2.20.0-2
ii  python3  3.7.2-1
ii  python3-dbus 1.2.8-3
ii  python3-gi   3.30.4-1
ii  python3-gi-cairo 3.30.4-1
ii  python3-libvirt  5.0.0-1
ii  virtinst 1:2.0.0-3

Versions of packages virt-manager recommends:
ii  gir1.2-spiceclientglib-2.0  0.35-2
ii  gir1.2-spiceclientgtk-3.0   0.35-2
ii  libvirt-daemon-system   5.0.0-1

Versions of packages virt-manager suggests:
ii  gir1.2-secret-1    0.18.7-1
ii  gnome-keyring  3.28.2-2
ii  ksshaskpass [ssh-askpass]  4:5.14.5-1
pn  python3-guestfs    
pn  virt-viewer    

-- no debconf information



Bug#921773: i3lock: Failed attempts count wraps around after 2^32 wrong login attempts

2019-02-08 Thread Nils Dagsson Moskopp
Package: i3lock
Version: 2.8-1
Severity: minor

Dear Maintainer,


i3lock can show the number of failed attempts using the -f flag. If
the number of failed attempts is higher than 999, it shows “>999” –
but the value shown was “1” again, after I manually incremented the
value saved in i3lock memory to 2^32-1 and entered a wrong password
again. I think one can duplicate this pretty easily using scanmem …

To be clear, I expected the amount of failed attempts to be “>999”,
without any wraparound behaviour. Note that the man page for i3lock
does not contain a description of “>999” behaviour for the -f flag.

I chose “Severity: minor” since it looks like a cosmetic bug to me.


-- System Information:
Debian Release: 9.7
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-7-686 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages i3lock depends on:
ii  libc6   2.24-11+deb9u3
ii  libcairo2   1.14.8-1
ii  libev4  1:4.22-1+b1
ii  libpam0g1.1.8-3.6
ii  libxcb-dpms01.12-1
ii  libxcb-image0   0.4.0-1+b2
ii  libxcb-shm0 1.12-1
ii  libxcb-util00.3.8-3+b2
ii  libxcb-xinerama01.12-1
ii  libxcb-xkb1 1.12-1
ii  libxcb1 1.12-1
ii  libxkbcommon-x11-0  0.7.1-2~deb9u1
ii  libxkbcommon0   0.7.1-2~deb9u1

i3lock recommends no packages.

i3lock suggests no packages.

-- no debconf information


Bug#888266: stterm: Space between letters when using GNU Unifont

2019-02-05 Thread Nils Dagsson Moskopp
Paride Legovini  writes:

> On Wed, 24 Jan 2018 14:22:24 +0100 Nils Dagsson Moskopp
>  wrote:> when starting
> stterm with GNU Unifont, with “stterm -f unifont”, the
>> letter spacing is much too wide. This makes this terminal unpleasant
>> to read. Also the terminal window became unusually wide due to this.
>
> Hello Nils,
>
> I can't reproduce the issue with stterm 0.8.1-1. Could you please give
> it a try and confirm it's fixed?

I did try st downloaded from https://dl.suckless.org/st/st-0.8.1.tar.gz
sha256 c4fb0fe2b8d2d3bd5e72763e80a8ae05b7d44dbac8f8e3bb18ef0161c7266926

As far as I can tell, the bug seems to be fixed in that stterm version.

Greetings,
Nils



Bug#913715: Bug #913715: simulide: terminates with segfault sometimes, when trying to undo changes

2018-11-23 Thread Nils Jarle Haugen

Hello,

Thanks you very much for the suggestions!

I tried running the program with again with gdb and got a backtrace of 
the crash.
Below is output of all threads(thread apply all bt). A more 
comprehensive output (thread apply all bt full) is available at: 
https://paste.debian.net/?show=1053004


What I did:

1. Added Arduino AVR Board
2. Connected components LED, resistor and ground to pin 4 on the 
Arduino. 5V rail and ground is also directly connect to the board

3. Loaded firmware
4. Started simulation
5. Stopped simulation
6. Started simulation
7. Moved components 5V rail and ground.
8. Used [Ctrl+Z] to undo the move
9. Program Segfaults

Hope this information is helpful.

Kind regards,
Nils Jarle Haugen


AvrProcessor::loadFirmware Avr Init:  atmega328 true
qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 12494, 
resource id: 29360513, major code: 40 (TranslateCoords), minor code: 0

[Thread 0x7fffd7fff700 (LWP 17080) exited]

Thread 1 "simulide" received signal SIGSEGV, Segmentation fault.
0x555d209a in ?? ()
(gdb) thread apply all bt
Thread 5 (Thread 0x7fffddbf4700 (LWP 12443)):
#0  0x764c5e6c in futex_wait_cancelable (private=out>, expected=0, futex_word=0x55c81520)

    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  0x764c5e6c in __pthread_cond_wait_common (abstime=0x0, 
mutex=0x55c814d0, cond=0x55c814f8)

    at pthread_cond_wait.c:502
#2  0x764c5e6c in __pthread_cond_wait (cond=0x55c814f8, 
mutex=0x55c814d0) at pthread_cond_wait.c:655

#3  0x7fffde2b0e2b in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#4  0x7fffde2b0b57 in  () at /usr/lib/x86_64-linux-gnu/dri/i965_dri.so
#5  0x764bff2a in start_thread (arg=0x7fffddbf4700) at 
pthread_create.c:463
#6  0x760bfedf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Thread 4 (Thread 0x7fffdf8f2700 (LWP 12442)):
#0  0x764c5e6c in futex_wait_cancelable (private=out>, expected=0, futex_word=0x55c3ef64)

    at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  0x764c5e6c in __pthread_cond_wait_common (abstime=0x0, 
mutex=0x55c3ef10, cond=0x55c3ef38)

    at pthread_cond_wait.c:502
#2  0x764c5e6c in __pthread_cond_wait (cond=0x55c3ef38, 
mutex=0x55c3ef10) at pthread_cond_wait.c:655
#3  0x7659c44b in QWaitCondition::wait(QMutex*, unsigned long) 
() at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x77443c05 in  () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5

#5  0x7659bc97 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#6  0x764bff2a in start_thread (arg=0x7fffdf8f2700) at 
pthread_create.c:463
#7  0x760bfedf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Thread 3 (Thread 0x7fffe67fb700 (LWP 12441)):
#0  0x760b5739 in __GI___poll (fds=0x7fffe00195c0, nfds=4, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
#1  0x75100e46 in  () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#2  0x75100f6c in g_main_context_iteration () at 
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0
#3  0x76795d13 in 
QEventDispatcherGlib::processEvents(QFlags) 
()

    at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#4  0x76742d0b in 
QEventLoop::exec(QFlags) ()

    at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x765920c6 in QThread::exec() () at 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5

#6  0x7fffedfb0545 in  () at /usr/lib/x86_64-linux-gnu/libQt5DBus.so.5
#7  0x7659bc97 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#8  0x764bff2a in start_thread (arg=0x7fffe67fb700) at 
pthread_create.c:463
#9  0x760bfedf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Thread 2 (Thread 0x7fffed52e700 (LWP 12440)):
#0  0x760b5739 in __GI___poll (fds=0x7fffed52d9f8, nfds=1, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29

#1  0x72f82cf7 in  () at /usr/lib/x86_64-linux-gnu/libxcb.so.1
#2  0x72f8491a in xcb_wait_for_event () at 
/usr/lib/x86_64-linux-gnu/libxcb.so.1
#3  0x7fffee073519 in  () at 
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5

#4  0x7659bc97 in  () at /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#5  0x764bff2a in start_thread (arg=0x7fffed52e700) at 
pthread_create.c:463
#6  0x760bfedf in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Thread 1 (Thread 0x7fffee565f80 (LWP 12435)):
#0  0x555d209a in  ()
#1  0x555d5c1e in  ()
#2  0x555d7397 in  ()
#3  0x555d08bc in  ()
#4  0x5563eae6 in  ()
#5  0x556379ff in  ()
#6  0x555bbf30 in  ()
#7  0x555bd7bd in  ()
#8  0x555c0f9e in  ()
#9  0x555c5230 in  ()
#10 0x77541567 in QGraphicsScene::event(QEvent*) () at 
/usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#11 0x77231491 in QApplicationPrivate::notify_helper(QObject*, 
QEvent*) ()

    at /usr/lib/

Bug#908681: libsane1: pointless package rename

2018-11-19 Thread Nils Schasse
Hi,

is this related to conflicts with the gnome package in sid?

(apt dist-upgrade)

To be removed:
  colord gnome gnome-color-manager gnome-control-center gnome-core
libsane1 libsane1:i386 sane-utils simple-scan task-gnome-desktop
Held back:
  libtiff5
Upgrade:
  libsane-common

Regards,
Nils


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


Bug#913715: simulide: terminates with segfault sometimes, when trying to undo changes

2018-11-14 Thread Nils Jarle Haugen

Package: simulide
Version: 0.1.7+dfsg-2
Severity: normal

Dear Maintainer,

Sometimes when I try to undo changes (by pressing Ctrl+Z) the program 
terminates with

segfault. This happens not often, but is frustrating because all the
changes done to the circuit is lost since last save.

To prevent this from happening I now avoid to use the
undo-functionality of the program, and it runs very stable.


   * What led up to the situation?
     Using the program as normal, moving a component in the circuit 
into another position

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
    Pressed Ctrl+Z to undo the change I did.
   * What was the outcome of this action ( does not happen all the time).
    Program exited with segfault.
   * What outcome did you expect instead?
    Undo the change I did with the component in the ciruit.

Please see this paste from /var/log/messages with the segfault: 
http://paste.debian.net/1051656/




Best regards,
Nils J. Haugen

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

Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=nn_NO.UTF-8, LC_CTYPE=nn_NO.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US (charmap=UTF-8)

Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages simulide depends on:
ii  gpsim  0.30.0-1
ii  libc6  2.27-8
ii  libelf1    0.170-0.5
ii  libgcc1    1:8.2.0-9
ii  libqt5core5a   5.11.2+dfsg-4
ii  libqt5gui5 5.11.2+dfsg-4
ii  libqt5multimedia5  5.11.2-2
ii  libqt5serialport5  5.11.2-2
ii  libqt5svg5 5.11.2-2
ii  libqt5widgets5 5.11.2+dfsg-4
ii  libqt5xml5 5.11.2+dfsg-4
ii  libstdc++6 8.2.0-9

Versions of packages simulide recommends:
ii  arduino-core   2:1.0.5+dfsg2-4.1
ii  avra   1.3.0-3
ii  gputils    1.4.0-0.1+b1
ii  libqt5multimedia5-plugins  5.11.2-2

Versions of packages simulide suggests:
ii  arduino   2:1.0.5+dfsg2-4.1
ii  avr-libc  1:2.0.0+Atmel3.6.1-1
ii  gcc-avr   1:5.4.0+Atmel3.6.0-1+b1
pn  simavr    
pn  simutron  

-- no debconf information



Bug#678694: Problem with preseed_fetch is still present in Debian Stretch installer

2018-11-06 Thread Nils Bronstert
Hello,

I have the same problem. It seems to be still present in the installer
for Debian 9 (Stretch). If you use preseed_fetch it does not use a
relative path to the URL used for the main preseed script. Instead the
absolute path is used from the file system.

Seems that the patch from John Morrissey could fix it.

-- 
Nils Bronstert



Bug#902905: varnishadm: vcl.show does not contain newline characters

2018-07-03 Thread Nils Fahldieck - Profihost AG
Package: varnish
Version: 5.0.0-7+deb9u2
Severity: normal

libc6 version: 2.24-11+deb9u3
Debian version: Debian GNU/Linux 9 (stretch)

This command prints the active vcl as an one liner:

$ varnishadm
varnish> vcl.show boot

I suggest that the output contains newlines. This behaviour exists since
upgrading from varnish 4.x.

Thanks, Nils

-- 
Mit freundlichen Grüßen
  Nils Fahldieck
Ihr Profihost Team

---
Profihost AG
Expo Plaza 1
30539 Hannover
Deutschland

Tel.: +49 (511) 5151 8181 | Fax.: +49 (511) 5151 8282
URL: http://www.profihost.com | E-Mail: i...@profihost.com

Sitz der Gesellschaft: Hannover, USt-IdNr. DE813460827
Registergericht: Amtsgericht Hannover, Register-Nr.: HRB 202350
Vorstand: Cristoph Bluhm, Sebastian Bluhm, Stefan Priebe
Aufsichtsrat: Prof. Dr. iur. Winfried Huck (Vorsitzender)



Bug#896189: Workaround

2018-04-23 Thread Nils Schasse
Maybe this helps:

The openmpi-bin.postinst uses
update-alternatives --query mpi | grep --silent libmpi

this returns Exit-Code 1 (which is tested one line below.

Since "set -e" is set, the scrips breaks here.

Workaround is:
# Delete old non-multi-arch aware mpi
set +e
 update-alternatives --query mpi | grep --silent libmpi
if [ $? -eq 0 ] ; then
  update-alternatives --remove-all mpi
fi
set -e

this runs.



Bug#888266: stterm: Space between letters when using GNU Unifont

2018-01-24 Thread Nils Dagsson Moskopp
Package: stterm
Version: 0.6-1
Severity: minor

Dear Maintainer,

when starting stterm with GNU Unifont, with “stterm -f unifont”, the
letter spacing is much too wide. This makes this terminal unpleasant
to read. Also the terminal window became unusually wide due to this.

I am including a screenshot to illustrate the problem.


-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages stterm depends on:
ii  libc6   2.24-11+deb9u1
ii  libfontconfig1  2.11.0-6.7+b1
ii  libx11-62:1.6.4-3
ii  libxft2 2.3.2-1+b2

stterm recommends no packages.

stterm suggests no packages.

-- no debconf information


Bug#771542: stterm shows glyphs twice

2018-01-24 Thread Nils Dagsson Moskopp
Package: stterm
Followup-For: Bug #771542

Dear Maintainer,

this bug no longer occurs on my system.

-- System Information:
Debian Release: 9.3
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages stterm depends on:
ii  libc6   2.24-11+deb9u1
ii  libfontconfig1  2.11.0-6.7+b1
ii  libx11-62:1.6.4-3
ii  libxft2 2.3.2-1+b2

stterm recommends no packages.

stterm suggests no packages.

-- no debconf information



Bug#880067: calibre-bin depends on qtbase-abi-5-9-0 but there is no installation candidate

2017-10-29 Thread Nils Schasse
Package: calibre-bin
Version: 3.10.0+dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

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

   * What led up to the situation?
Install package calibre.
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Used apt to figure out the reason.
   * What was the outcome of this action?
qtbase-abi-5-9-0 has no candidate to install, so the dependancy is broken.
   * What outcome did you expect instead?
clean install of calibre



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

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), 
LANGUAGE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages calibre-bin depends on:
ii  libc6  2.24-17
pn  libchm1
ii  libfontconfig1 2.12.3-0.2
ii  libfreetype6   2.8.1-0.1
ii  libgcc11:7.2.0-12
ii  libgl1 0.2.999+git20170802-5
ii  libglib2.0-0   2.54.2-1
ii  libicu57   57.1-8
ii  libmtp91.1.13-1
pn  libpodofo0.9.5 
ii  libpython2.7   2.7.14-2
ii  libqt5core5a   5.9.2+dfsg-4
ii  libqt5dbus55.9.2+dfsg-4
ii  libqt5gui5 5.9.2+dfsg-4
ii  libqt5widgets5 5.9.2+dfsg-4
ii  libssl1.1  1.1.0f-5
ii  libstdc++6 7.2.0-12
ii  libusb-1.0-0   2:1.0.21-2
ii  python-sip [sip-api-12.2]  4.19.3+dfsg-2
ii  python2.7  2.7.14-2
pn  qtbase-abi-5-9-0   
ii  zlib1g 1:1.2.8.dfsg-5

Versions of packages calibre-bin recommends:
pn  calibre  

calibre-bin suggests no packages.



Bug#878035: libopengl0-glvnd-nvidia: bug still present with new sid version

2017-10-12 Thread nils
Package: libopengl0-glvnd-nvidia
Version: 375.82-5
Followup-For: Bug #878035

Dear Maintainer,

This bug still exists on the newly released version 375.82-5 (on sid).

Thanks,
Nils



Bug#878035: libopengl0-glvnd-nvidia: libopengl0 version reported to "none" with libopengl0-glvnd-nvidia

2017-10-08 Thread nils
Package: libopengl0-glvnd-nvidia
Version: 375.82-4
Severity: important

Dear Maintainer,

While trying to install libglvnd-dev, apt reported it to depend on
libopengl0 and failed ( http://paste.debian.net/989711/ ).
I then tried to build it from source with apt-source and debuild to
investigate a bit more, which worked but the dpkg install failed and
dpkg reported "Version of libopengl0 on system, provided by
libopengl0-glvnd-nvidia:amd64, is " 
( http://paste.debian.net/989713/ ). 

As I understand, I do have libopengl0 throught libopengl0-glvnd-nvidia
and therefore my openGL version number should not be empty.

I hope I posted this on the right package.
Thanks in advance,
Nils

PS: for the (very legthy) package-specific and system info, please see
http://paste.debian.net/989714/



Bug#876033: primus: fix found?

2017-09-28 Thread nils
Package: primus
Version: 0~20150328-4
Followup-For: Bug #876033

Dear Maintainer,

I had the same problem after switching to glvnd on sid.
I edited /usr/bin/primusrun and found

PRIMUS_libGL=${PRIMUS_libGL:-'/usr/$LIB/primus'}

replacing the simple quotes by double quotes fixed it (in the commented
out parts, singne quotes needs to be replaced too).

Hope this is it,
Regards,
Nils

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

Kernel: Linux 4.12.0-2-amd64 (SMP w/8 CPU cores)
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)

Versions of packages primus depends on:
ii  bumblebee  3.2.1-16
ii  primus-libs0~20150328-4
ii  socat  1.7.3.2-1
ii  xserver-xorg-core  2:1.19.3-2

Versions of packages primus recommends:
ii  primus-libs-ia32  0~20150328-4

primus suggests no packages.

-- no debconf information



Bug#868705: gnome-exe-thumbnailer: Thumbnail generation for MSI files executes arbitrary VBScript

2017-07-18 Thread Nils Dagsson Moskopp
Quote <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-11421>:

> gnome-exe-thumbnailer before 0.9.5 is prone to a VBScript Injection
> when generating thumbnails for MSI files, aka the "Bad Taste"
> issue. There is a local attack if the victim uses the GNOME Files file
> manager, and navigates to a directory containing a .msi file with
> VBScript code in its filename.

Note that thumbnailer issues could be exploited via drive-by downloads
with any web browser that does not ask users if files should be saved.

Salvatore Bonaccorso <car...@debian.org> writes:

> Control: retitle -1 gnome-exe-thumbnailer: CVE-2017-11421: Thumbnail 
> generation for MSI files executes arbitrary VBScript
>  
> Hi
>
> CVE-2017-11421 has been assigned for this issue.
>
> Regards,
> Salvatore

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


signature.asc
Description: PGP signature


Bug#868705: [pkg-wine-party] Bug#868705: gnome-exe-thumbnailer: Thumbnail generation for MSI files executes arbitrary VBScript

2017-07-17 Thread Nils Dagsson Moskopp
I like that the patch is less code. Deleted code is debugged code!
Btw, are you sure that using mssiinfo does not introduce new bugs?

Cheers,
Nils

James Lu <bitfl...@gmail.com> writes:

> [ Unknown signature status ]
> Hi Nils,
>
> I wasn't able to reproduce the exploit on my (64-bit) system with either
> Caja and Nautilus (it also required setting up a new wineprefix in
> ~/.wine). The msi thumbnail ended up generating without any version
> information tag at all.
>
> Regardless, I've gone and replaced the VBScript-based parsing entirely
> with msitools' msiinfo in
> https://github.com/gnome-exe-thumbnailer/gnome-exe-thumbnailer/commit/1d8e3102dd8fd23431ae6127d14a236da6b4a4a5;
> hopefully this should fix the issue. I'll tag a new release soon and
> look at pushing the fix to Debian.
>
> (Also CC'ing the other maintainers, who I don't think are on the Debian
> Wine list)
>
> Best,
> James
>
> On 18/07/17 05:01 AM, Nils Dagsson Moskopp wrote:
>> Package: gnome-exe-thumbnailer
>> Version: 0.9.4-2
>> Severity: grave
>> Tags: security
>> Justification: user security hole
>> 
>> Dear Maintainer,
>> 
>> the following PoC is copied verbatim from my post about the parsing issue:
>> http://news.dieweltistgarnichtso.net/posts/gnome-thumbnailer-msi-fail.html
>> 
>> Proof of Concept
>> 
>> Install Dependencies
>> 
>> On Debian GNU/Linux, install the packages gnome-exe-thumbnailer, nautilus 
>> and wixl. The wixl package is only needed to create MSI files that trigger 
>> the thumbnailer.
>> 
>> If the proof of concept does not work, install winetricks and run winetricks 
>> wsh56 to upgrade the Windows Script Host.
>> 
>> Create MSI Files
>> 
>> Create a file named poc.xml with the following content:
>> 
>> 
>> http://schemas.microsoft.com/wix/2006/wi;>
>> 
>> 
>> 
>> Execute the following Bourne Shell code:
>> 
>> wixl -o poc.msi poc.xml
>> cp poc.msi "poc.msi\",0):Set 
>> fso=CreateObject(\"Scripting.FileSystemObject\"):Set 
>> poc=fso.CreateTextFile(\"badtaste.txt\")'.msi"
>> 
>> Trigger Execution
>> 
>> Start GNOME Files and navigate to the folder with the MSI files. An empty 
>> file with the name badtaste.txt should appear.
>> 
>> *** End of the template - remove these template lines ***
>> 
>> 
>> -- System Information:
>> Debian Release: 9.0
>>   APT prefers stable
>>   APT policy: (500, 'stable')
>> Architecture: i386 (i686)
>> 
>> Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
>> Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
>> Shell: /bin/sh linked to /bin/dash
>> Init: sysvinit (via /sbin/init)
>> 
>> Versions of packages gnome-exe-thumbnailer depends on:
>> ii  icoutils 0.31.2-1.1
>> ii  imagemagick  8:6.9.7.4+dfsg-11
>> ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
>> ii  libglib2.0-bin   2.50.3-2
>> 
>> Versions of packages gnome-exe-thumbnailer recommends:
>> pn  wine 
>> 
>> pn  wine64-tools | wine32-tools | wine64-development-tools | wine32-dev  
>> 
>> 
>> gnome-exe-thumbnailer suggests no packages.
>> 
>> -- no debconf information
>> 
>> ___
>> pkg-wine-party mailing list
>> pkg-wine-pa...@lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-wine-party
>> 
>

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>


signature.asc
Description: PGP signature


Bug#868705: gnome-exe-thumbnailer: Thumbnail generation for MSI files executes arbitrary VBScript

2017-07-17 Thread Nils Dagsson Moskopp
Package: gnome-exe-thumbnailer
Version: 0.9.4-2
Severity: grave
Tags: security
Justification: user security hole

Dear Maintainer,

the following PoC is copied verbatim from my post about the parsing issue:
http://news.dieweltistgarnichtso.net/posts/gnome-thumbnailer-msi-fail.html

Proof of Concept

Install Dependencies

On Debian GNU/Linux, install the packages gnome-exe-thumbnailer, nautilus and 
wixl. The wixl package is only needed to create MSI files that trigger the 
thumbnailer.

If the proof of concept does not work, install winetricks and run winetricks 
wsh56 to upgrade the Windows Script Host.

Create MSI Files

Create a file named poc.xml with the following content:


http://schemas.microsoft.com/wix/2006/wi;>



Execute the following Bourne Shell code:

wixl -o poc.msi poc.xml
cp poc.msi "poc.msi\",0):Set 
fso=CreateObject(\"Scripting.FileSystemObject\"):Set 
poc=fso.CreateTextFile(\"badtaste.txt\")'.msi"

Trigger Execution

Start GNOME Files and navigate to the folder with the MSI files. An empty file 
with the name badtaste.txt should appear.

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


-- System Information:
Debian Release: 9.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages gnome-exe-thumbnailer depends on:
ii  icoutils 0.31.2-1.1
ii  imagemagick  8:6.9.7.4+dfsg-11
ii  imagemagick-6.q16 [imagemagick]  8:6.9.7.4+dfsg-11
ii  libglib2.0-bin   2.50.3-2

Versions of packages gnome-exe-thumbnailer recommends:
pn  wine 
pn  wine64-tools | wine32-tools | wine64-development-tools | wine32-dev  

gnome-exe-thumbnailer suggests no packages.

-- no debconf information



Bug#856843: Arch bug, upstream bug, patch

2017-05-01 Thread Nils
https://bugs.archlinux.org/task/53639
https://bugzilla.kernel.org/show_bug.cgi?id=194531
Patch links in the kernel and arch bug reports.



Bug#856843: Problem also exists on Ubuntu 16.04 with 4.4.0 kernel

2017-05-01 Thread Nils
I also see it on Ubuntu 16.04 on another system:
Linux blackbox 4.4.0-75-generic #96-Ubuntu SMP Thu Apr 20 09:56:33 UTC
2017 x86_64 x86_64 x86_64 GNU/Linux
ii  linux-image-4.4.0-75-generic   
4.4.0-75.96amd64Linux kernel
image for version 4.4.0 on 64 bit x86 SMP

I'll try with 4.8.0 on Ubuntu as well, but am expecting the same
behavior. For me this is with a FreeNAS server.

Should I file this bug with Ubuntu as well? Does it make sense to file
it upstream with the kernel directly?



Bug#856843: FYI, Ubuntu Bugtracker link

2017-05-01 Thread Nils
Already exists on the Ubuntu tracker, with additional info.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1686099



Bug#856843: smbclient: connection flood to port 445 on mounting cifs volume under kernel 4.9.0

2017-03-21 Thread Nils
Problem persists with linux-image-4.9.0-0.bpo.2-amd64 (4.9.13-1~bpo8+1)



Bug#856843: [Pkg-samba-maint] Bug#856843: smbclient: connection flood to port 445 on mounting cifs volume under kernel 4.9.0

2017-03-09 Thread Nils
On 2017-03-09 13:46, Mathieu Parent wrote:
> Control: affects -1 + cifs-utils
>
> 2017-03-05 12:30 GMT+01:00 nils <internation...@gmx.net>:
>
>> Hello,
>> after upgrading my kernel from 4.0.8 to 4.0.9 I am getting connection floods 
>> to
>> my FreeNAS samba server from my debian machine. I never had this issue with
>> 4.0.8
> 4.0.8? Don't you mean 4.8?
>
> Can you point to the exact good/bad versions, from
> http://snapshot.debian.org/package/linux/?
>
> Also, what are your mount options (from fstab?)
>
> Regards
>
Yes, sorry, typos... 4.8 vs. 4.9.
Versions are:
ii  linux-image-4.8.0-0.bpo.2-amd64  4.8.15-2~bpo8+2
ii  linux-image-4.9.0-0.bpo.1-amd64  4.9.2-2~bpo8+1

Mount options:
//192.168.2.88/xfer /mnt/nas/xfercifs 
noauto,uid=1000,gid=1000,iocharset=utf8,sec=ntlm,credentials=/root/.cifs-nils 
0  0

Freenas Box (for Info) has:
FreeBSD freenas.dynils.de 10.3-STABLE FreeBSD 10.3-STABLE #0
r295946+1805185(9.10.2-STABLE): Wed Jan 11 17:12:42 UTC 2017
root@gauntlet:/freenas-9.10-releng/_BE/objs/freenas-9.10-releng/_BE/os/sys/FreeNAS.amd64
 
amd64
samba-nsupdate-9.8.6_1 nsupdate utility with GSS-TSIG support
samba44-4.4.5_102277   Free SMB/CIFS and AD/DC server and client
for Uni

Thanks, Nils.



Bug#856843: [Pkg-samba-maint] Bug#856843: smbclient: connection flood to port 445 on mounting cifs volume under kernel 4.9.0

2017-03-05 Thread Nils
Then this is a kernel issue, I assumed that cifsd was part of smbclient
and I see that taking up resources, but maybe that is unrelated (it was
in a normal resource usage range).

Please reassign as you think appropriate.


On 2017-03-05 14:36, Jelmer Vernooij wrote:
> On Sun, Mar 05, 2017 at 12:30:33PM +0100, nils wrote:
>> Package: smbclient
>> Version: 2:4.2.14+dfsg-0+deb8u2
>> Severity: important
>>
>> Hello,
>> after upgrading my kernel from 4.0.8 to 4.0.9 I am getting connection floods 
>> to
>> my FreeNAS samba server from my debian machine. I never had this issue with
>> 4.0.8
>>
>> Linux dnet64 4.9.0-0.bpo.1-amd64 #1 SMP Debian 4.9.2-2~bpo8+1 (2017-01-26)
>> x86_64 GNU/Linux
>> ii  smbclient  2:4.2.14+dfsg-0+deb8u2   amd64command-line
>> SMB/CIFS clients for Unix
>>
>> After mouting the cifs share(s) everything is OK for about 10 minutes, then a
>> flood of connections happens. Here is an extract of 'netstat -an' run every
>> second. Only one or two connections are shown for every 'netstat -an' run. 
>> The
>> connections are opening and closing at an incredible speed (nethogs goes to
>> 100% and doesn't show anything because it's overwhelmed). gkrellm reports 
>> about
>> 70k/Sec traffic due to this. See how the source port numbers increase
>> increadibly quickly to get an idea of how many connections are really
>> happening...
>> 
>> tcp0  1 10.0.2.15:55044 192.168.2.88:445SYN_SENT
>> tcp0  1 10.0.2.15:55252 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:55288 192.168.2.88:445
>> ESTABLISHED
>> tcp0  1 10.0.2.15:55314 192.168.2.88:445SYN_SENT
>> tcp0  1 10.0.2.15:55348 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:55396 192.168.2.88:445
>> ESTABLISHED
>> tcp0  1 10.0.2.15:55454 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:55500 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55544 192.168.2.88:445
>> ESTABLISHED
>> tcp0 42 10.0.2.15:55586 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55630 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55676 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55720 192.168.2.88:445
>> ESTABLISHED
>> tcp0  1 10.0.2.15:55770 192.168.2.88:445SYN_SENT
>> tcp1  0 10.0.2.15:55820 192.168.2.88:445
>> CLOSE_WAIT
>> tcp0  1 10.0.2.15:55868 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:55912 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:55962 192.168.2.88:445
>> ESTABLISHED
>> tcp1  0 10.0.2.15:56010 192.168.2.88:445
>> CLOSE_WAIT
>> tcp0  1 10.0.2.15:56058 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:56056 192.168.2.88:445LAST_ACK
>> tcp0  0 10.0.2.15:56104 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:56162 192.168.2.88:445
>> ESTABLISHED
>> tcp0  0 10.0.2.15:56202 192.168.2.88:445
>> ESTABLISHED
>> tcp0  1 10.0.2.15:56246 192.168.2.88:445SYN_SENT
>> tcp0  0 10.0.2.15:56290 192.168.2.88:445
>> ESTABLISHED
>> etc.
>>
>> Rebooting in 4.0.8 makes the issue go away, and I can have the shares mounted
>> as long as I want without a connection flood. Hence I assume that it's a
>> smbclient + Kernel 4.0.9 issue
> smbclient is a command-line tool, if you're just mounting CIFS shares then 
> this
> is an issue in the kernel rather than in smbclient.
>
> Jelmer



Bug#856843: smbclient: connection flood to port 445 on mounting cifs volume under kernel 4.9.0

2017-03-05 Thread nils
Package: smbclient
Version: 2:4.2.14+dfsg-0+deb8u2
Severity: important

Hello,
after upgrading my kernel from 4.0.8 to 4.0.9 I am getting connection floods to
my FreeNAS samba server from my debian machine. I never had this issue with
4.0.8

Linux dnet64 4.9.0-0.bpo.1-amd64 #1 SMP Debian 4.9.2-2~bpo8+1 (2017-01-26)
x86_64 GNU/Linux
ii  smbclient  2:4.2.14+dfsg-0+deb8u2   amd64command-line
SMB/CIFS clients for Unix

After mouting the cifs share(s) everything is OK for about 10 minutes, then a
flood of connections happens. Here is an extract of 'netstat -an' run every
second. Only one or two connections are shown for every 'netstat -an' run. The
connections are opening and closing at an incredible speed (nethogs goes to
100% and doesn't show anything because it's overwhelmed). gkrellm reports about
70k/Sec traffic due to this. See how the source port numbers increase
increadibly quickly to get an idea of how many connections are really
happening...

tcp0  1 10.0.2.15:55044 192.168.2.88:445SYN_SENT
tcp0  1 10.0.2.15:55252 192.168.2.88:445SYN_SENT
tcp0  0 10.0.2.15:55288 192.168.2.88:445ESTABLISHED
tcp0  1 10.0.2.15:55314 192.168.2.88:445SYN_SENT
tcp0  1 10.0.2.15:55348 192.168.2.88:445SYN_SENT
tcp0  0 10.0.2.15:55396 192.168.2.88:445ESTABLISHED
tcp0  1 10.0.2.15:55454 192.168.2.88:445SYN_SENT
tcp0  0 10.0.2.15:55500 192.168.2.88:445ESTABLISHED
tcp0  0 10.0.2.15:55544 192.168.2.88:445ESTABLISHED
tcp0 42 10.0.2.15:55586 192.168.2.88:445ESTABLISHED
tcp0  0 10.0.2.15:55630 192.168.2.88:445ESTABLISHED
tcp0  0 10.0.2.15:55676 192.168.2.88:445ESTABLISHED
tcp0  0 10.0.2.15:55720 192.168.2.88:445ESTABLISHED
tcp0  1 10.0.2.15:55770 192.168.2.88:445SYN_SENT
tcp1  0 10.0.2.15:55820 192.168.2.88:445CLOSE_WAIT
tcp0  1 10.0.2.15:55868 192.168.2.88:445SYN_SENT
tcp0  0 10.0.2.15:55912 192.168.2.88:445ESTABLISHED
tcp0  0 10.0.2.15:55962 192.168.2.88:445ESTABLISHED
tcp1  0 10.0.2.15:56010 192.168.2.88:445CLOSE_WAIT
tcp0  1 10.0.2.15:56058 192.168.2.88:445SYN_SENT
tcp0  0 10.0.2.15:56056 192.168.2.88:445LAST_ACK
tcp0  0 10.0.2.15:56104 192.168.2.88:445ESTABLISHED
tcp0  0 10.0.2.15:56162 192.168.2.88:445ESTABLISHED
tcp0  0 10.0.2.15:56202 192.168.2.88:445ESTABLISHED
tcp0  1 10.0.2.15:56246 192.168.2.88:445SYN_SENT
tcp0  0 10.0.2.15:56290 192.168.2.88:445ESTABLISHED
etc.

Rebooting in 4.0.8 makes the issue go away, and I can have the shares mounted
as long as I want without a connection flood. Hence I assume that it's a
smbclient + Kernel 4.0.9 issue



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

Kernel: Linux 4.9.0-0.bpo.1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_DK.UTF-8, LC_CTYPE=en_DK.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages smbclient depends on:
ii  dpkg  1.17.27
ii  libarchive13  3.1.2-11+deb8u3
ii  libbsd0   0.7.0-2
ii  libc6 2.19-18+deb8u7
ii  libpopt0  1.16-10
ii  libreadline6  6.3-8+b3
ii  libsmbclient  2:4.2.14+dfsg-0+deb8u2
ii  libtalloc22.1.2-0+deb8u1
ii  libtevent00.9.28-0+deb8u1
ii  samba-common  2:4.2.14+dfsg-0+deb8u2
ii  samba-libs2:4.2.14+dfsg-0+deb8u2

smbclient recommends no packages.

Versions of packages smbclient suggests:
ii  cifs-utils   2:6.4-1
pn  heimdal-clients  

-- no debconf information



  1   2   3   4   >