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#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#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#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#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
[ "$VERBOSE" != no ] && echo "$DESC is running."
exit 0
else
[ "$VERBOSE" != no ] && echo "$DESC is not running"
exit 3
fi
;;
  force-reload)
#--user $USER \
start-stop-daemon --stop --test --quiet \

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#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: