Bug#1003351: Update package to upstream version 5.0 (patches provided)
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)
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
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
> 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
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
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
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
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
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
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
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
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
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
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: