Bug#989779: unblock: polyphone/2.2.0.20210109+dfsg1-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: t...@mirbsd.de Please unblock package polyphone [ Reason ] The current release contains a regression where large soundfont sample offsets are not correctly encoded. [ Impact ] Silently produces bad output for large sample offsets. This kind of corruption is hard to manually test for. [ Tests ] The submitter of the patch tested the package, although not the precise binary but a recompilation from the same sources in my PPA. [ Risks ] Low, leaf package, merely reverts part of an upstream commit. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing [ Other info ] unblock polyphone/2.2.0.20210109+dfsg1-2 diff -Nru polyphone-2.2.0.20210109+dfsg1/debian/changelog polyphone-2.2.0.20210109+dfsg1/debian/changelog --- polyphone-2.2.0.20210109+dfsg1/debian/changelog 2021-01-19 23:14:12.0 +0100 +++ polyphone-2.2.0.20210109+dfsg1/debian/changelog 2021-06-06 15:22:08.0 +0200 @@ -1,3 +1,9 @@ +polyphone (2.2.0.20210109+dfsg1-2) unstable; urgency=medium + + * Add patch to fix large soundfonts/samples’ offsets + + -- Thorsten Glaser Sun, 06 Jun 2021 15:22:08 +0200 + polyphone (2.2.0.20210109+dfsg1-1) unstable; urgency=medium * Improve compiler flags handling, via MuseScore packaging diff -Nru polyphone-2.2.0.20210109+dfsg1/debian/patches/142.patch polyphone-2.2.0.20210109+dfsg1/debian/patches/142.patch --- polyphone-2.2.0.20210109+dfsg1/debian/patches/142.patch 1970-01-01 01:00:00.0 +0100 +++ polyphone-2.2.0.20210109+dfsg1/debian/patches/142.patch 2021-06-06 15:21:55.0 +0200 @@ -0,0 +1,24 @@ +Description: allow offset values greater than 16-bit signed integer + A fix for issue #141, which was broken by commit + f80fc38b406ad094a1d3d2563da5d8124818e2e3. This fix reverts to the + use of qRound when storing offset values for sample and loop start/end. +From: "S. Christian Collins" +Origin: https://github.com/davy7125/polyphone/pull/142 +Bug: https://github.com/davy7125/polyphone/issues/141 + +--- a/sources/core/types/attribute.cpp b/sources/core/types/attribute.cpp +@@ -181,11 +181,11 @@ AttributeValue Attribute::fromRealValue( + break; + case champ_startloopAddrsCoarseOffset: case champ_endloopAddrsCoarseOffset: + case champ_startAddrsCoarseOffset: case champ_endAddrsCoarseOffset: +-storedValue.shValue = Utils::round16(realValue) / 32768; ++storedValue.shValue = static_cast(qRound(realValue) / 32768); + break; + case champ_startloopAddrsOffset: case champ_startAddrsOffset: + case champ_endloopAddrsOffset: case champ_endAddrsOffset: +-storedValue.shValue = static_cast(Utils::round16(realValue) % 32768); ++storedValue.shValue = static_cast(qRound(realValue) % 32768); + break; + case champ_keyRange: case champ_velRange: + storedValue.rValue.byHi = static_cast(0.001 * realValue); diff -Nru polyphone-2.2.0.20210109+dfsg1/debian/patches/series polyphone-2.2.0.20210109+dfsg1/debian/patches/series --- polyphone-2.2.0.20210109+dfsg1/debian/patches/series2021-01-19 23:12:32.0 +0100 +++ polyphone-2.2.0.20210109+dfsg1/debian/patches/series2021-06-06 15:16:36.0 +0200 @@ -2,3 +2,4 @@ branding.diff fix-build.diff reproducible.diff +142.patch
Bug#989736: openjdk-8: keep out of testing and stable
Source: openjdk-8 Version: 8u282-b08-2 Severity: serious Justification: should not migrate to testing or stable any more X-Debbugs-Cc: t...@mirbsd.de Keep this package in unstable (and possibly experimental) for now. It is to be used officially only for bootstrapping JVM-based languages like Kotlin, as well as to provide LTS packages for stretch and ELTS for jessie. Users may use this further at their own risk, with no support. I’m providing precompiled backports for all Debian releases from wheezy onwards and all *buntu LTS releases from precise (12.04) onwards in my personal APT repository; contact me, or see extrepo-data, for details.
Bug#736803: dh_dkms could automatically replace #MODULE_VERSION#
Package: dkms Version: 2.6.1-4 Followup-For: Bug #736803 I just ran into that as well because the manpage is ambiguously worded in a way one could think that that’s already done. Also, having an option that optionally takes an argument is likely going to fail. @Andreas: packages with a literal #MODULE_VERSION# are indeed already broken: first because of the directory structure… […] drwxr-xr-x root/root 0 2021-06-07 18:52 ./usr/src/sch-jens-#MODULE_VERSION#/ -rw-r--r-- root/root 344 2021-06-07 18:44 ./usr/src/sch-jens-#MODULE_VERSION#/dkms.conf drwxr-xr-x root/root 0 2021-06-07 18:52 ./usr/src/sch-jens-0~20210607.0/ -rw-r--r-- root/root20 2021-06-07 15:59 ./usr/src/sch-jens-0~20210607.0/Kbuild […] … and second because they won’t uninstall: the prerm has… # Automatically added by dh_dkms/UNDECLARED DKMS_NAME=sch-jens DKMS_VERSION=#MODULE_VERSION# case "$1" in remove|upgrade|deconfigure) if [ "$(dkms status -m $DKMS_NAME -v $DKMS_VERSION)" ]; then dkms remove -m $DKMS_NAME -v $DKMS_VERSION --all fi … which will end up calling 'dkms status -m name -v', which works, and 'dkms remove -m name -v --all', which will fail badly. -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages dkms depends on: ii build-essential 12.6 ii coreutils8.30-3 ii dpkg-dev 1.19.7 ii gcc 4:8.3.0-1 ii kmod 26-1 ii make 4.2.1-1.2 ii patch2.7.6-3+deb10u1 Versions of packages dkms recommends: ii fakeroot 1.23-1 ii linux-headers-amd64 4.19+105+deb10u11 ii lsb-release 10.2019051400 ii sudo 1.8.27-1+deb10u3 Versions of packages dkms suggests: ii menu2.1.47+b1 pn python3-apport -- no debconf information
Bug#956245: dkms: Error! You must be root to use this command STILL broken in buster?
Hi, this bug is still open in buster… bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#989532: unblock: mc/3:4.8.26-1.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de, only...@debian.org, y...@shurup.com,
ti...@debian.org, deb...@denis-briand.fr
Please unblock package mc
[ Reason ]
This fixes #987446 which basically made any file that isn’t called
.zip but is a PKZIP container (including both things that are ZIP-like
archives, like *.jar, and those which aren’t, like office documents)
unusable with mc.
[ Impact ]
Quite a regression and limiting use.
[ Tests ]
I’ve manually tested this. It’s a backport of an upstream fix,
so I guess they also tested it, and it’ll be part of the next
upstream release.
[ Risks ]
This changes a conffile only, in a somewhat-leaf (only pulled
in by tasks-like packages) package. If anything should need to
be fixed up later, it can if necessary be done by the end user
changing the file in /etc.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
unblock mc/3:4.8.26-1.1
diff -Nru mc-4.8.26/debian/changelog mc-4.8.26/debian/changelog
--- mc-4.8.26/debian/changelog 2021-02-01 02:44:43.0 +0100
+++ mc-4.8.26/debian/changelog 2021-06-01 15:26:23.0 +0200
@@ -1,3 +1,10 @@
+mc (3:4.8.26-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix PKZIP archive handling, patch backported from upstream
+
+ -- Thorsten Glaser Tue, 01 Jun 2021 15:26:23 +0200
+
mc (3:4.8.26-1) unstable; urgency=medium
* New upstream release.
diff -Nru mc-4.8.26/debian/patches/fix-987446.patch
mc-4.8.26/debian/patches/fix-987446.patch
--- mc-4.8.26/debian/patches/fix-987446.patch 1970-01-01 01:00:00.0
+0100
+++ mc-4.8.26/debian/patches/fix-987446.patch 2021-06-01 15:24:55.0
+0200
@@ -0,0 +1,263 @@
+Origin: upstream, commit:fa2cbd2a2c7e38ee56d1756eac5899b57f7f4262
+From: Andrew Borodin
+Description: Ticket #4180: reorgzanize mc.ext.
+ $ file -L image.zip
+ image.zip: Zip archive data, at least v2.0 to extract
+ $ file -L -z image.zip
+ image.zip: JPEG image data, JFIF standard 1.01, resolution (DPI),
+ density 96x96, segment length 16, baseline, precision 8, 1024x768,
+ frames 3 (Zip archive data, at least v2.0 to extract)
+ .
+ Since in mc.ext
+ .
+ type/^JPEG
+ .
+ is evaluated before
+ .
+ type/\(Zip archive
+ .
+ mc assume image.zip is a image not an archive.
+ .
+ To solve this, since we use "file -z", match file name at first
+ (regex/ and shell/), then type/.
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987446
+
+--- a/misc/mc.ext.in
b/misc/mc.ext.in
+@@ -107,6 +107,7 @@
+ ### Changes ###
+ #
+ # Reorganization: 2012-03-07 Slava Zanko
++# 2021-03-28 Andrew Borodin
+
+
+ ### GIT Repo ###
+@@ -117,6 +118,7 @@ regex/^\[git\]
+
+
+ ### Archives ###
++# Since we use "file -z", we should use regex/ and shell/ at first, then
type/.
+
+ # .tgz, .tpz, .tar.gz, .tar.z, .tar.Z, .ipk, .gem
+ regex/\.t([gp]?z|ar\.g?[zZ])$|\.ipk$|\.gem$
+@@ -171,16 +173,6 @@ shell/i/.tar
+ Open=%cd %p/utar://
+ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view tar
+
+-# lha
+-type/^LHa\ .*archive
+- Open=%cd %p/ulha://
+- View=%view{ascii} @EXTHELPERSDIR@/archive.sh view lha
+-
+-# PAK
+-type/^PAK\ .*archive
+- Open=%cd %p/unar://
+- View=%view{ascii} @EXTHELPERSDIR@/archive.sh view pak
+-
+ # arj
+ regex/i/\.a(rj|[0-9][0-9])$
+ Open=%cd %p/uarj://
+@@ -300,7 +292,6 @@ shell/i/.iso
+ Open=%cd %p/iso9660://
+ View=%view{ascii} @EXTHELPERSDIR@/misc.sh view iso9660
+
+-
+ regex/\.(diff|patch)$
+ Open=%cd %p/patchfs://
+ View=%view{ascii} @EXTHELPERSDIR@/misc.sh view cat
+@@ -316,6 +307,102 @@ shell/i/.lib
+ Open=%cd %p/ulib://
+ View=%view{ascii} @EXTHELPERSDIR@/misc.sh view lib
+
++# ace
++shell/i/.ace
++ Open=%cd %p/uace://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view ace
++ Extract=unace x %f
++
++# arc
++shell/i/.arc
++ Open=%cd %p/uarc://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view arc
++ Extract=arc x %f '*'
++ Extract (with flags)=I=%{Enter any Arc flags:}; if test -n "$I"; then
arc x $I %f; fi
++
++# zip
++shell/i/.zip
++ Open=%cd %p/uzip://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zip
++
++# zoo
++shell/i/.zoo
++ Open=%cd %p/uzoo://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zoo
++
++# lz4
++regex/\.lz4$
++ Open=@EXTHELPERSDIR@/archive.sh view lz4 %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view lz4
++
++# WIM
++shell/i/\.wim
++ Open=%cd %p/uwim://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view wim
++
++# gzip
++type/\(gzip compressed
++ Open=@EXTHELPERSDIR@/archive.sh view gz %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view g
Bug#989531: vcswatch: Error: fatal: dumb http transport does not support shallow capabilities
Package: qa.debian.org Severity: normal X-Debbugs-Cc: t...@mirbsd.de https://qa.debian.org/cgi-bin/vcswatch?package=campania and others have: Error: fatal: dumb http transport does not support shallow capabilities
Bug#989509: buster-pu: package klibc/2.0.6-1+deb10u1
Ben Hutchings dixit: >Thorsten Glaser tested the s390x fix in unstable. It has not (yet) >been manually tested in this version. Unfortunately we don’t have a baseline, as the only test I had that triggered this doesn’t trigger in buster (probably because only a newer GCC scheduled things to use these registers in the first place). bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#989310: partx: /dev/$VG/$LV: adding partition #4 failed: Invalid argument
Hi Chris, >Right. Thanks for the report, however could I ask you to directly >report this to upstream? I don't think this is a Debian peculiarity >and I cannot think of anything useful that I could add to an >upstream bug report. could you please do that? I have no relationship with upstream and no desire to register in just another bugtracker, and I’m not even sure which component is even part of the problem. Thanks, //mirabilos -- DevRef 3.1.4.
Bug#987446: mc: diff for NMU 4.8.26-1.1
Dear maintainer,
I uploaded the NMU to DELAYED/5 as per policy. Please find
the diff attached and integrate it into the next maintainer
upload (or drop once you upgrade to an upstream version
that carries it). I’ve forgotten, oops, to close the bug
in debian/changelog, but I d̲i̲d̲ verify the fix.
bye,
//mirabilos
--
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...diff -Nru mc-4.8.26/debian/changelog mc-4.8.26/debian/changelog
--- mc-4.8.26/debian/changelog 2021-02-01 02:44:43.0 +0100
+++ mc-4.8.26/debian/changelog 2021-06-01 15:26:23.0 +0200
@@ -1,3 +1,10 @@
+mc (3:4.8.26-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix PKZIP archive handling, patch backported from upstream
+
+ -- Thorsten Glaser Tue, 01 Jun 2021 15:26:23 +0200
+
mc (3:4.8.26-1) unstable; urgency=medium
* New upstream release.
diff -Nru mc-4.8.26/debian/patches/fix-987446.patch
mc-4.8.26/debian/patches/fix-987446.patch
--- mc-4.8.26/debian/patches/fix-987446.patch 1970-01-01 01:00:00.0
+0100
+++ mc-4.8.26/debian/patches/fix-987446.patch 2021-06-01 15:24:55.0
+0200
@@ -0,0 +1,263 @@
+Origin: upstream, commit:fa2cbd2a2c7e38ee56d1756eac5899b57f7f4262
+From: Andrew Borodin
+Description: Ticket #4180: reorgzanize mc.ext.
+ $ file -L image.zip
+ image.zip: Zip archive data, at least v2.0 to extract
+ $ file -L -z image.zip
+ image.zip: JPEG image data, JFIF standard 1.01, resolution (DPI),
+ density 96x96, segment length 16, baseline, precision 8, 1024x768,
+ frames 3 (Zip archive data, at least v2.0 to extract)
+ .
+ Since in mc.ext
+ .
+ type/^JPEG
+ .
+ is evaluated before
+ .
+ type/\(Zip archive
+ .
+ mc assume image.zip is a image not an archive.
+ .
+ To solve this, since we use "file -z", match file name at first
+ (regex/ and shell/), then type/.
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987446
+
+--- a/misc/mc.ext.in
b/misc/mc.ext.in
+@@ -107,6 +107,7 @@
+ ### Changes ###
+ #
+ # Reorganization: 2012-03-07 Slava Zanko
++# 2021-03-28 Andrew Borodin
+
+
+ ### GIT Repo ###
+@@ -117,6 +118,7 @@ regex/^\[git\]
+
+
+ ### Archives ###
++# Since we use "file -z", we should use regex/ and shell/ at first, then
type/.
+
+ # .tgz, .tpz, .tar.gz, .tar.z, .tar.Z, .ipk, .gem
+ regex/\.t([gp]?z|ar\.g?[zZ])$|\.ipk$|\.gem$
+@@ -171,16 +173,6 @@ shell/i/.tar
+ Open=%cd %p/utar://
+ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view tar
+
+-# lha
+-type/^LHa\ .*archive
+- Open=%cd %p/ulha://
+- View=%view{ascii} @EXTHELPERSDIR@/archive.sh view lha
+-
+-# PAK
+-type/^PAK\ .*archive
+- Open=%cd %p/unar://
+- View=%view{ascii} @EXTHELPERSDIR@/archive.sh view pak
+-
+ # arj
+ regex/i/\.a(rj|[0-9][0-9])$
+ Open=%cd %p/uarj://
+@@ -300,7 +292,6 @@ shell/i/.iso
+ Open=%cd %p/iso9660://
+ View=%view{ascii} @EXTHELPERSDIR@/misc.sh view iso9660
+
+-
+ regex/\.(diff|patch)$
+ Open=%cd %p/patchfs://
+ View=%view{ascii} @EXTHELPERSDIR@/misc.sh view cat
+@@ -316,6 +307,102 @@ shell/i/.lib
+ Open=%cd %p/ulib://
+ View=%view{ascii} @EXTHELPERSDIR@/misc.sh view lib
+
++# ace
++shell/i/.ace
++ Open=%cd %p/uace://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view ace
++ Extract=unace x %f
++
++# arc
++shell/i/.arc
++ Open=%cd %p/uarc://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view arc
++ Extract=arc x %f '*'
++ Extract (with flags)=I=%{Enter any Arc flags:}; if test -n "$I"; then
arc x $I %f; fi
++
++# zip
++shell/i/.zip
++ Open=%cd %p/uzip://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zip
++
++# zoo
++shell/i/.zoo
++ Open=%cd %p/uzoo://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view zoo
++
++# lz4
++regex/\.lz4$
++ Open=@EXTHELPERSDIR@/archive.sh view lz4 %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view lz4
++
++# WIM
++shell/i/\.wim
++ Open=%cd %p/uwim://
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view wim
++
++# gzip
++type/\(gzip compressed
++ Open=@EXTHELPERSDIR@/archive.sh view gz %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view gz
++
++# bzip2
++type/\(bzip2 compressed
++ Open=@EXTHELPERSDIR@/archive.sh view bzip2 %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view bz2
++
++# bzip
++type/\(bzip compressed
++ Open=@EXTHELPERSDIR@/archive.sh view bzip %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view bzip
++
++# compress
++type/\(compress'd
++ Open=@EXTHELPERSDIR@/archive.sh view gz %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view gz
++
++# lz
++type/\(lzip compressed
++ Open=@EXTHELPERSDIR@/archive.sh view lz %var{PAGER:more}
++ View=%view{ascii} @EXTHELPERSDIR@/archive.sh view lz
++
++# lzma
++type/\(LZMA
Bug#989314: unblock: mksh/59c-8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de
Control: block -1 by 989279
Please unblock package mksh
[ Reason ]
This upload addresses the following issues:
• Work around #988027 in klibc (which is a POSIX violation but
apparently deliberate by upstream) by using {set,long}jmp
instead of sig{set,long}jmp when not saving/restoring signals
(cherry-pick from upstream)
• Rebuild against klibc with #943425 ({set,long}jmp on s390x use
wrong registers) fixed
• Cherry-pick another two upstream memory leak fixes
• Backport just enough (for Debian) of upstream patch fixing the
way control characters are escaped when showing variable contents
(for reentrancy or when deliberately escaping with ${varname@Q});
specifically, escape C1 control characters dependent on whether
utf8-mode is on (UTF8-encoded) or off (bytewise), catching some
situations in which they were not escaped properly, make the
escaped output match the UTF-8 mode better, and add a shell option
“asis” to allow \x80‥\x9F unescaped outside(!) of UTF-8 mode only
for when the user uses a codepage that has them as printable, not
control, characters
(There’s also a one-line d-ports-only change of no relevance to
the release architectures.)
[ Impact ]
• Potential (but minor; except on s390x, the testsuite didn’t catch
anything) misbehaviour of the klibc-built binaries; outdated
Built-Using for klibc once 2.0.8-6.1 migrates
• Minor memory leaks
• Attempting to display a variable escaped (“typeset -p varname”,
“set | grep ^varname”) may send control sequences to the terminal,
including sequences that cause xterm to, for example, dump the
current terminal contents to files
[ Tests ]
The testsuite is very throughout (it did catch the s390x/klibc issue
and switched the mksh-static and lksh binary to musl for that); it
also proves the klibc change works. I’ve manually verified the escaping-
related changes. I’ve not verified the memory leaks separately, but
the codepaths are like this that, if they were wrong (e.g. use-after-
free), the testsuite (especially on MirBSD with malloc hardening)
would’ve caught it crashing.
I’ve run a number of scripts comparing output with the previous and
the binaries from this upload installed.
[ Risks ]
As I wrote in earlier unblock requests (#987975, #986431) mksh is
effectively leaf in Debian, and changes like these are low risk.
I’ve reduced the upstream commits related to escaping to include
only the necessary parts to make reviewing easier. This carries
some, but very low, risk. The tests would have caught mistakes
during that (incidentally, they did, when I removed a hunk which
I at first thought not necessary).
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
I’m attaching a diff of the unpacked trees instead of debdiff(1)
output again because I use single-debian-patch here and that’d
be a nightmare to review. I’ve commented in the diff which hunks
match which issue.
I’m also attaching a “diff -w” of the file misc.c to make review
easier; a huge part of the escaping code lost one level of indent.
I’ll be uploading another escaping-related fix revision, similar
issues (C0/C1 control characters and DEL) but in the command line
editor and tab completion code, but I have yet to find the time
to actually fix these issues first and think that including what
we’ve already got in sid into testing right now is a good thing.
unblock mksh/59c-8
diff -pruN mksh_59c-6/debian/changelog mksh_59c-8/debian/changelog
--- mksh_59c-6/debian/changelog 2021-05-03 03:26:28.0 +0200
+++ mksh_59c-8/debian/changelog 2021-05-31 02:42:55.0 +0200
@@ -1,3 +1,26 @@
+mksh (59c-8) unstable; urgency=medium
+
+ * Fix a -Wpointer-sign in escaping code
+ * Shrink escape diff (algorithm unchanged) for easier review
+
+ -- Thorsten Glaser Mon, 31 May 2021 02:42:55 +0200
+
+mksh (59c-7) unstable; urgency=medium
+
+ * Do not use sigsetjmp(â¦, 0) with klibc (cf. #988027)
+ * Cherry-pick upstream memory leak fixes
+ * Apply just enough upstream changes to address more escaping
+issues: for ${var@Q} and âtypeset -pâ, take UTF-8 mode (on/off)
+into account; donât issue \u escapes outside of UTF-8 mode,
+donât escape nÅn-ASCII printable, that is, nÅn-control characters;
+always escape C0 controls and DEL; escape C1 controls by default,
+but add an option âasisâ to disable that (e.g. for DOS codepages)
+in nÅn-UTF8 modeââânote this will need fixing for tab completion,
+command line editing (in a subsequent upload)â¦
+ * Work around hppa buildd issue (same as m68k, sh4)
+
+ -- Thorsten Glaser Sun, 30 May 2021 23:57:59 +0200
+
mksh (59c-6) unstable; urgency=medium
* Clear âtaintâ on most actions mutating a variable
Bug#989310: partx: /dev/$VG/$LV: adding partition #4 failed: Invalid argument
Dixi quod… >… whereas partx at least recognises the disklabel: > >tglase@tglase:~ $ sudo partx --show - /dev/mapper/vg--tglase-ufs4 whole-disc:^^ bsd-disklabel-partition:^ >NR START END SECTORS SIZE NAME UUID > 1 2097152 67108863 65011712 31G > 2 32 2097151 2097120 1024M > 3 0 31 32 16K I found a workaround… it does require manually figuring out which of the “NR” maps to which slice, then losetup(8)ing that — this is a bit tricky (START is relative to the entire disc, not the partition) and ugly (losetup only uses bytes, Kibibytes, etc. but not sectors as offset): sudo losetup -f -o $((2097152/2))K --sizelimit $((65011712/2))K /dev/mapper/vg--tglase-ufs START=>^^^SECTORS=> whole-disc:^^ 2sec=1K:^2sec=1K:^ Then, “sudo losetup -a” to figure out which loop device “won”, afterwards use that, for example, with ufsutils (= 8.2-4) installed, I can do… sudo ffsinfo /dev/loop0 | less sudo fsck.ufs -fy /dev/loop0 … and even… sudo mount -t ufs -o ufstype=44bsd /dev/loop0 /mnt ls /mnt sudo umount /mnt … and at the end, don’t forget to: sudo losetup -d /dev/loop0 sudo kpartx -d -v /dev/mapper/vg--tglase-ufs JFYI, in case this pops up with someone else. A working solution, involving partx, partprobe, kpartx or something, would still be welcome. bye, //mirabilos -- [...] if maybe ext3fs wasn't a better pick, or jfs, or maybe reiserfs, oh but what about xfs, and if only i had waited until reiser4 was ready... in the be- ginning, there was ffs, and in the middle, there was ffs, and at the end, there was still ffs, and the sys admins knew it was good. :) -- Ted Unangst über *fs
Bug#989310: partx: /dev/$VG/$LV: adding partition #4 failed: Invalid argument
Package: util-linux Version: 2.36.1-7 Severity: normal X-Debbugs-Cc: t...@mirbsd.de, team+linux-blo...@tracker.debian.org I’m trying to use partx instead of kpartx to make partitions available to the system, but it completely fails: tglase@tglase:~ $ sudo partx -a -v - /dev/vg-tglase/ufs partition: none, disk: /dev/vg-tglase/ufs, lower: 0, upper: 0 /dev/vg-tglase/ufs: partition table type 'dos' detected range recount: max partno=4, lower=0, upper=0 partx: /dev/vg-tglase/ufs: adding partition #4 failed: Invalid argument partx: /dev/vg-tglase/ufs: error adding partition 4 Doing this with kpartx works… tglase@tglase:~ $ sudo kpartx -a -v /dev/mapper/vg--tglase-ufs add map vg--tglase-ufs4 (253:9): 0 67108832 linear 253:8 32 … but kpartx fails in the second step, making the slices from the BSD disklabel available… tglase@tglase:~ $ sudo kpartx -a -v /dev/mapper/vg--tglase-ufs4 device-mapper: reload ioctl on vg--tglase-ufs4p1 (253:10) failed: Invalid argument create/reload failed on vg--tglase-ufs4p1 device-mapper: reload ioctl on vg--tglase-ufs4p2 (253:10) failed: Invalid argument create/reload failed on vg--tglase-ufs4p2 device-mapper: reload ioctl on vg--tglase-ufs4p3 (253:10) failed: Invalid argument create/reload failed on vg--tglase-ufs4p3 device-mapper: reload ioctl on vg--tglase-ufs4p4 (253:10) failed: Invalid argument create/reload failed on vg--tglase-ufs4p4 … whereas partx at least recognises the disklabel: tglase@tglase:~ $ sudo partx --show - /dev/mapper/vg--tglase-ufs4 NR START END SECTORS SIZE NAME UUID 1 2097152 67108863 65011712 31G 2 32 2097151 2097120 1024M 3 0 31 32 16K So I’m stuck. -- System Information: Debian Release: 11.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages util-linux depends on: ii libaudit1 1:3.0-2 ii libblkid1 2.36.1-7 ii libc6 2.31-12 ii libcap-ng0 0.7.9-2.2+b1 ii libcrypt1 1:4.4.18-4 ii libelogind0 [libsystemd0] 246.9.1-1+debian1 ii libmount1 2.36.1-7 ii libpam0g 1.4.0-7 ii libselinux13.1-3 ii libsmartcols1 2.36.1-7 ii libtinfo6 6.2+20201114-2 ii libudev1 247.3-5 ii libuuid1 2.36.1-7 ii login 1:4.8.1-1 ii zlib1g 1:1.2.11.dfsg-2 util-linux recommends no packages. Versions of packages util-linux suggests: ii dosfstools 4.2-1 ii kbd 2.3.0-3 pn util-linux-locales -- debconf information: util-linux/noauto-with-nonzero-passnum:
Bug#989284: insserv: toggles rc0.d/{K02avahi-daemon => K01avahi-daemon} with every upgrade
Package: insserv
Version: 1.21.0-1.1
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
I believe this is insserv; if not, feel free to reassign.
With every update, I have etckeeper churn:
[master 8a1a489] committing changes in /etc made by "apt-get --purge
dist-upgrade"
Author: mirabilos <…>
4 files changed, 91 insertions(+), 9 deletions(-)
rename rc0.d/{K02avahi-daemon => K01avahi-daemon} (100%)
rename rc1.d/{K02avahi-daemon => K01avahi-daemon} (100%)
rename rc6.d/{K02avahi-daemon => K01avahi-daemon} (100%)
Basically, avahi-daemon toggles between K01 and K02 every time.
This is annoying and a waste of git space.
-- System Information:
Debian Release: 11.0
APT prefers unreleased
APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'),
(100, 'experimental')
Architecture: x32 (x86_64)
Foreign Architectures: i386, amd64
Kernel: Linux 5.10.0-6-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages insserv depends on:
ii libc6 2.31-12
insserv recommends no packages.
Versions of packages insserv suggests:
pn bootchart2
-- no debconf information
Bug#931402: could not leave editor on examining a config file conflict
Package: dpkg Version: 1.19.7 Followup-For: Bug #931402 Control: severity -1 important Control: retitle -1 dpkg: improperly sets up conffile examine shell session; breaks Emacs totally I just noticed the same, ^C gets eaten; thankfully, my editor can do without, but this is probably severe for Emacs users. Please see whether the fix suggested works and apply it if so, if not, fix it somehow ;-) -- Package-specific info: -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages dpkg depends on: ii libbz2-1.0 1.0.6-9.2~deb10u1 ii libc62.28-10 ii liblzma5 5.2.4-1 ii libselinux1 2.8-1+b1 ii tar 1.30+dfsg-6 ii zlib1g 1:1.2.11.dfsg-1 dpkg recommends no packages. Versions of packages dpkg suggests: ii apt1.8.2.3 pn debsig-verify -- no debconf information
Bug#989283: prosody: upgrade overwrites changed files in /etc without asking
Package: prosody
Version: 0.11.2-1+deb10u2
Severity: serious
Justification: Policy 10.7.3
The recent security upgrade (0.11.2-1 → 0.11.2-1+deb10u2)
overwrote the configuration files prosody/certs/localhost.{crt,key}
without asking, notifying, or anything. This is a Policy violation:
10.7.3. Behavior[40]¶
Configuration file handling must conform to the following behavior:
* local changes must be preserved during a package upgrade, and
Please make sure to fix this!
-- System Information:
Debian Release: 10.9
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-16-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8)
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages prosody depends on:
ii adduser 3.118
ii libc6 2.28-10
ii libidn111.33-2.2
ii libssl1.1 1.1.1d-0+deb10u6
ii lsb-base10.2019051400
ii lua-bitop [lua5.2-bitop]1.0.2-5
ii lua-expat [lua5.2-expat]1.3.0-4
ii lua-filesystem [lua5.2-filesystem] 1.6.3-1
ii lua-sec [lua5.2-sec]0.7-1
ii lua-socket [lua5.2-socket] 3.0~rc1+git+ac3201d-4
ii lua5.2 5.2.4-1.1+b2
ii ssl-cert1.0.39
Versions of packages prosody recommends:
pn lua5.2-event
Versions of packages prosody suggests:
pn lua-dbi-mysql
pn lua-dbi-postgresql
pn lua-dbi-sqlite3
pn lua-zlib
-- Configuration Files:
/etc/init.d/prosody changed [not included]
/etc/prosody/conf.avail/example.com.cfg.lua [Errno 13] Permission denied:
'/etc/prosody/conf.avail/example.com.cfg.lua'
/etc/prosody/conf.avail/localhost.cfg.lua [Errno 13] Permission denied:
'/etc/prosody/conf.avail/localhost.cfg.lua'
/etc/prosody/prosody.cfg.lua [Errno 13] Permission denied:
'/etc/prosody/prosody.cfg.lua'
-- no debconf information
Bug#989279: unblock: klibc/2.0.8-6.1
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de
Please unblock package klibc
[ Reason ]
The NMU contains a fix for #943425 (save/restore correct set of
registers across *{set,long}jmp) which is RC on s390x, which is
a release architecture.
[ Impact ]
klibc-built binaries on s390x can malfunction.
[ Tests ]
The mksh testsuite catches this. Today’s mksh upload’s buildd log
on s390x shows that the fix works. An S/390 expert provided the
correct set of registers to save/restore. I’ve compared it to the
glibc implementation afterwards, and it matches, so I believe it
to be correct.
[ Risks ]
klibc is rather critical; it’s part of booting and installing (so
this also needs an udeb unblock). The patch affects s390x only,
as far as I can tell, but I believe it necessary there.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
This will need an udeb unblock; what do I need to do for this?
unblock klibc/2.0.8-6.1
diff -Nru klibc-2.0.8/debian/changelog klibc-2.0.8/debian/changelog
--- klibc-2.0.8/debian/changelog2021-04-30 03:05:23.0 +0200
+++ klibc-2.0.8/debian/changelog2021-05-27 00:12:10.0 +0200
@@ -1,3 +1,11 @@
+klibc (2.0.8-6.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * {set,long}jmp [s390x]: save/restore the correct FPU registers
+(f8‥f15 not f1/f3/f5/f7) (Closes: #943425)
+
+ -- Thorsten Glaser Thu, 27 May 2021 00:12:10 +0200
+
klibc (2.0.8-6) unstable; urgency=medium
* Upload to unstable
diff -Nru
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
---
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
1970-01-01 01:00:00.0 +0100
+++
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
2021-05-27 00:11:57.0 +0200
@@ -0,0 +1,57 @@
+Description: {set,long}jmp [s390x]: save/restore the correct registers
+ The s390x ABI actually has FPU registers f8‥f15, not f1/f3/f5/f7,
+ to be saved. (Closes: Debian #943425)
+Author: mirabilos
+Forwarded: https://lists.zytor.com/archives/klibc/2021-May/004620.html
+
+--- a/usr/include/arch/s390/klibc/archsetjmp.h
b/usr/include/arch/s390/klibc/archsetjmp.h
+@@ -16,7 +16,7 @@ struct __jmp_buf {
+
+ struct __jmp_buf {
+ uint64_t __gregs[10]; /* general registers r6-r15 */
+- uint64_t __fpregs[4]; /* fp registers f1, f3, f5, f7 */
++ uint64_t __fpregs[8]; /* fp registers f8-f15 */
+ };
+
+ #endif /* __s390x__ */
+--- a/usr/klibc/arch/s390/setjmp.S
b/usr/klibc/arch/s390/setjmp.S
+@@ -38,10 +38,14 @@ longjmp:
+
+ setjmp:
+ stmg%r6,%r15,0(%r2) # save all general registers
+- std %f1,80(%r2) # save fp registers f4 and f6
+- std %f3,88(%r2)
+- std %f5,96(%r2)
+- std %f7,104(%r2)
++ std %f8,80(%r2) # save fp registers f8 to f15
++ std %f9,88(%r2)
++ std %f10,96(%r2)
++ std %f11,104(%r2)
++ std %f12,112(%r2)
++ std %f13,120(%r2)
++ std %f14,128(%r2)
++ std %f15,136(%r2)
+ lghi%r2,0 # return 0
+ br %r14
+
+@@ -54,10 +58,14 @@ setjmp:
+ longjmp:
+ lgr %r1,%r2 # jmp_buf
+ lgr %r2,%r3 # return value
+- ld %f7,104(%r1)# restore all saved registers
+- ld %f5,96(%r1)
+- ld %f3,88(%r1)
+- ld %f1,80(%r1)
++ ld %f15,136(%r1) # restore all saved registers
++ ld %f14,128(%r1)
++ ld %f13,120(%r1)
++ ld %f12,112(%r1)
++ ld %f11,104(%r1)
++ ld %f10,96(%r1)
++ ld %f9,88(%r1)
++ ld %f8,80(%r1)
+ lmg %r6,%r15,0(%r1)
+ br %r14# return to restored address
+
diff -Nru klibc-2.0.8/debian/patches/series klibc-2.0.8/debian/patches/series
--- klibc-2.0.8/debian/patches/series 2021-04-30 02:38:31.0 +0200
+++ klibc-2.0.8/debian/patches/series 2021-05-27 00:09:21.0 +0200
@@ -10,3 +10,4 @@
0037-klibc-calloc-Fail-if-multiplication-overflows.patch
0039-klibc-cpio-Fix-possible-integer-overflow-on-32-bit-s.patch
0040-klibc-cpio-Fix-possible-crash-on-64-bit-systems.patch
+0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
Bug#989185: youtube-dl: needs version update to 2021.05.16 to continue working with youtube
Package: youtube-dl Version: 2021.02.10-1 Severity: important X-Debbugs-Cc: t...@mirbsd.de, ti...@debian.org The currently packaged version has: […] WARNING: unable to extract player URL; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see https://yt-dl.org/update on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output. ERROR: No video formats found; please report this issue on https://yt-dl.org/bug . Make sure you are using the latest version; see https://yt-dl.org/update on how to update. Be sure to call youtube-dl with the --verbose flag and include its complete output. Using the upstream binary works, so, a mere update should fix this. Maybe the Release Team will accept this under the provisio of keeping up with ever-changing external APIs? -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages youtube-dl depends on: ii python33.9.2-3 ii python3-pkg-resources 52.0.0-3 Versions of packages youtube-dl recommends: ii ca-bundle [ca-certificates] 20190604 ii curl 7.74.0-1.2 ii ffmpeg 7:4.3.2-0+deb11u1 ii mplayer 2:1.4+ds1-1 pn python3-pyxattr pn rtmpdump ii wget 1.21-1+b1 Versions of packages youtube-dl suggests: ii libfribidi-bin 1.0.8-2 pn phantomjs -- no debconf information
Bug#943425: klibc: debdiff for NMU 2.0.8-6.1
Hi Ben, maks,
please find attached the debdiff fixing this release-critical bug.
I’ve uploaded to DELAYED/0 per devref.
Please integrate this into the next maintainer upload.
I’ve only added the patch for the wrong registers being saved,
not the one fixing sig{set,long}jmp because, apparently, klibc
documents its standard violation for these two functions, so
that’s best dealt with upstream. I’ll upload mksh using the
regular {set,long}jmp functions instead where signals are to
not be saved once klibc is built on all architectures.
bye,
//mirabilos
--
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
-- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2diff -Nru klibc-2.0.8/debian/changelog klibc-2.0.8/debian/changelog
--- klibc-2.0.8/debian/changelog2021-04-30 03:05:23.0 +0200
+++ klibc-2.0.8/debian/changelog2021-05-27 00:12:10.0 +0200
@@ -1,3 +1,11 @@
+klibc (2.0.8-6.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * {set,long}jmp [s390x]: save/restore the correct FPU registers
+(f8‥f15 not f1/f3/f5/f7) (Closes: #943425)
+
+ -- Thorsten Glaser Thu, 27 May 2021 00:12:10 +0200
+
klibc (2.0.8-6) unstable; urgency=medium
* Upload to unstable
diff -Nru
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
---
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
1970-01-01 01:00:00.0 +0100
+++
klibc-2.0.8/debian/patches/0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
2021-05-27 00:11:57.0 +0200
@@ -0,0 +1,57 @@
+Description: {set,long}jmp [s390x]: save/restore the correct registers
+ The s390x ABI actually has FPU registers f8‥f15, not f1/f3/f5/f7,
+ to be saved. (Closes: Debian #943425)
+Author: mirabilos
+Forwarded: https://lists.zytor.com/archives/klibc/2021-May/004620.html
+
+--- a/usr/include/arch/s390/klibc/archsetjmp.h
b/usr/include/arch/s390/klibc/archsetjmp.h
+@@ -16,7 +16,7 @@ struct __jmp_buf {
+
+ struct __jmp_buf {
+ uint64_t __gregs[10]; /* general registers r6-r15 */
+- uint64_t __fpregs[4]; /* fp registers f1, f3, f5, f7 */
++ uint64_t __fpregs[8]; /* fp registers f8-f15 */
+ };
+
+ #endif /* __s390x__ */
+--- a/usr/klibc/arch/s390/setjmp.S
b/usr/klibc/arch/s390/setjmp.S
+@@ -38,10 +38,14 @@ longjmp:
+
+ setjmp:
+ stmg%r6,%r15,0(%r2) # save all general registers
+- std %f1,80(%r2) # save fp registers f4 and f6
+- std %f3,88(%r2)
+- std %f5,96(%r2)
+- std %f7,104(%r2)
++ std %f8,80(%r2) # save fp registers f8 to f15
++ std %f9,88(%r2)
++ std %f10,96(%r2)
++ std %f11,104(%r2)
++ std %f12,112(%r2)
++ std %f13,120(%r2)
++ std %f14,128(%r2)
++ std %f15,136(%r2)
+ lghi%r2,0 # return 0
+ br %r14
+
+@@ -54,10 +58,14 @@ setjmp:
+ longjmp:
+ lgr %r1,%r2 # jmp_buf
+ lgr %r2,%r3 # return value
+- ld %f7,104(%r1)# restore all saved registers
+- ld %f5,96(%r1)
+- ld %f3,88(%r1)
+- ld %f1,80(%r1)
++ ld %f15,136(%r1) # restore all saved registers
++ ld %f14,128(%r1)
++ ld %f13,120(%r1)
++ ld %f12,112(%r1)
++ ld %f11,104(%r1)
++ ld %f10,96(%r1)
++ ld %f9,88(%r1)
++ ld %f8,80(%r1)
+ lmg %r6,%r15,0(%r1)
+ br %r14# return to restored address
+
diff -Nru klibc-2.0.8/debian/patches/series klibc-2.0.8/debian/patches/series
--- klibc-2.0.8/debian/patches/series 2021-04-30 02:38:31.0 +0200
+++ klibc-2.0.8/debian/patches/series 2021-05-27 00:09:21.0 +0200
@@ -10,3 +10,4 @@
0037-klibc-calloc-Fail-if-multiplication-overflows.patch
0039-klibc-cpio-Fix-possible-integer-overflow-on-32-bit-s.patch
0040-klibc-cpio-Fix-possible-crash-on-64-bit-systems.patch
+0041-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
Bug#989047: lynx: broken handling (double slashes) of relative links
Package: lynx Version: 2.9.0dev.6-2 Severity: normal X-Debbugs-Cc: t...@mirbsd.de Affected: Lynx Version 2.9.0dev.6 (Debian 2.9.0dev.6-2) Not affected: Lynx Version 2.8.8dev.16-MirOS-0AB8.1 $ lynx http://www.mirbsd.org/permalinks/wlog2020_e20210207.htm In Advanced mode, naviate to link #68 “locale(1)” and watch the status bar. Affected: -more- http://www.mirbsd.org//htman/i386/man1/locale.htm Not affected: -more- http://www.mirbsd.org/htman/i386/man1/locale.htm So this is a recent regression. Corresponding HTML source: […] In a next step libc will have a binary toggle between C and C.UTF-8 (somewhat again), locale(1) and […] -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/2 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages lynx depends on: ii libbsd0 0.11.3-1 ii libbz2-1.01.0.8-4 ii libc6 2.31-12 ii libgnutls30 3.7.1-4 ii libidn11 1.33-3 ii libncursesw6 6.2+20201114-2 ii libtinfo6 6.2+20201114-2 ii lynx-common 2.9.0dev.6-2 ii zlib1g1:1.2.11.dfsg-2 Versions of packages lynx recommends: ii mime-support 3.66 lynx suggests no packages. -- no debconf information
Bug#943425: [klibc] #943425 [s390x] setjmp/longjmp do not save/restore all registers in use
Hello Ben, any chance to upload at least the patch for s390x? This affects a release architrecture, so I’d NMU this if necessary, so we have it fixed in bullseye. Thanks, //mirabilos -- “Having a smoking section in a restaurant is like having a peeing section in a swimming pool.” -- Edward Burr
Bug#892842: OpenJDK 8 archive re-entry
On Mon, 26 Apr 2021, Thorsten Glaser wrote: >I assume the normal > process of looking at it and eventually getting back to us will run > now. So far, nothing happened, and repeated inquiries got no response at all. Just keeping the list informed. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#988738: eyeD3: depends on unpackaged Python package “grako”
Package: eyed3
Version: 0.8.10-1.1
Severity: serious
Justification: fails to work
X-Debbugs-Cc: t...@mirbsd.de
$ eyeD3 -P display -p %a% *.mp3
eyed3.plugins:WARNING: Plugin '('lastfm.py',
'/usr/lib/python3/dist-packages/eyed3/plugins')' requires packages that are not
installed: cannot import name 'COVER_EXTRA_LARGE' from 'pylast'
(/usr/lib/python3/dist-packages/pylast/__init__.py)
Unknown module 'grako'
Please install grako! E.g. $ pip install grako
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500,
'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages eyed3 depends on:
ii python33.9.2-3
ii python3-eyed3 0.8.10-1.1
ii python3-pkg-resources 52.0.0-3
eyed3 recommends no packages.
eyed3 suggests no packages.
-- no debconf information
Bug#696332: lsb-release: release/codename depend on a successful apt-get
On Tue, 18 May 2021, Benjamin Drung wrote: > In case /usr/lib/os-release sets VERSION_CODENAME or > /etc/debian_version specifies only one codename, lsb-release takes the > information from there. base-files 11 don't set these values (and > therefore trigger this bug), but base-files 11.1 does set these values > (and therefore does not trigger this bug). Once bullseye is released, > base-files will be updated and trigger the bug again. It gets worse: unstable will, for a while, register as next-stable instead, throwing off buildds and all that. Furthermore, this breaks horribly when you have more than one release in your sources.list and on debian-ports platforms. > I ran into this issue with salt. salt failed to determine its codename > grain after a fresh boot. Older lsb-release versions had as the official fix to write into /etc/lsb-release the following lines… DISTRIB_RELEASE=unstable DISTRIB_CODENAME=sid … and things would work. For some reason, probably something to do with systemd/fdo/whatever shiny new thing, this was desupported after stretch; from buster onwards, you have to instead create /usr/lib/os-release.sid which needs to contain all fields, not just the overrides… PRETTY_NAME="Debian GNU/Linux sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/"; SUPPORT_URL="https://www.debian.org/support"; BUG_REPORT_URL="https://bugs.debian.org/"; VERSION_ID=unstable VERSION_CODENAME=sid … and then run… sudo dpkg-divert --rename --divert /usr/lib/os-release.dpkg-dist \ --add /usr/lib/os-release sudo ln -sfT os-release.sid /usr/lib/os-release … to fix this issue. (To remove, dpkg-divert can be used, but you can’t switch from sid to testing or stable anyway. Even then the /etc/lsb-release method was easier to do.) Even before buster it was said that, to run a sid system (or even a testing system, I suppose, but I don’t), this is mandatory, but neither has this found its way into any kind of official documentation nor does the desupporting of /etc/lsb-release help with it :/ tl;dr: Run the above dpkg-divert+ln after /usr/lib/os-release.sid creation immediately after or even during creation of a sid chroot or system/VM image. Hmm. Someone should add that to modules/schroot/files/setup-dchroot in dsa-puppet, I think, for sid chroots anyway. Jessica? bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!
Bug#987446: mc: cannot view .zip files (PKZIP archives) containing PDF files any more
On Sun, 25 Apr 2021, Adrian Bunk wrote: > There seem to be revert and cherry-pick options available for this > specific issue: I’ve applied the cherry-pick option from the upstream commit https://github.com/MidnightCommander/mc/commit/fa2cbd2a2c7e38ee56d1756eac5899b57f7f4262.patch to my /etc/mc/mc.ext (with slight hassle due to substitution) and found it improves the situation a lot. Please apply, upload and request unblock; I intend to do myself, as NMU, in a week (or so) if no activity happens. Thanks in advance, //mirabilos -- Du hast Recht. Du hast Recht!
Bug#988221: xterm: uses unescaped backslashes in manpage example
Thomas Dickey dixit: >The example is correct, however. xterm's manpage isn't a tutorial >on shell programming. Yes and yes, but it’s still over-microoptimised, in a way that is not helpful to users. bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
Bug#988221: xterm: uses unescaped backslashes in manpage example
Package: xterm Version: 366-1 Severity: minor Tags: upstream X-Debbugs-Cc: t...@mirbsd.de The manual page includes example commands such as… printf '\033]2;Hello world!\033\' … which use unescaped backslashes at the end of the command. In general this works… $ printf '\' | hd 5c|\| … but when copying this specific example into a larger string, such as appending “abc”, it fails: $ printf '\abc' | hd 07 62 63 |.bc| Doubling the backslash fixes this: $ printf '\\abc' | hd 5c 61 62 63 |\abc| In the manpage, this will mean changing the sequence “\e'” to “\e\e'” (as each ‘\e’ denotes a backslash in nroff escaping). -- System Information: Debian Release: 11.0 APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages xterm depends on: ii libc6 2.31-12 ii libfontconfig1 2.13.1-4.2 ii libfreetype62.10.4+dfsg-1 ii libice6 2:1.0.10-1 ii libtinfo6 6.2+20201114-2 ii libutempter01.2.1-2 ii libx11-62:1.7.0-2 ii libxaw7 2:1.0.13-1.1 ii libxext62:1.3.3-1.1 ii libxft2 2.3.2-2 ii libxinerama12:1.1.4-2 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.2.0-1 ii xbitmaps1.1.1-2.1 Versions of packages xterm recommends: ii x11-utils 7.7+5 Versions of packages xterm suggests: pn xfonts-cyrillic -- no debconf information
Bug#942013: lintian: non-consecutive-debian-revision: false positive for NMUs
On Wed, 5 May 2021, Felix Lechner wrote: > > X: klibc source: non-consecutive-debian-revision 2.0.8-6 -> 2.0.8-6.1 > > Where may I find your NMU for klibc, please? I haven’t uploaded it yet, let’s give bwh a chance to do it first ;) Attached. bye, //mirabilos -- Sometimes they [people] care too much: pretty printers [and syntax highligh- ting, d.A.] mechanically produce pretty output that accentuates irrelevant detail in the program, which is as sensible as putting all the prepositions in English text in bold font. -- Rob Pike in "Notes on Programming in C"Format: 3.0 (quilt) Source: klibc Binary: libklibc-dev, libklibc, klibc-utils Architecture: linux-any Version: 2.0.8-6.1 Maintainer: Debian Kernel Team Uploaders: Ben Hutchings , maximilian attems Homepage: https://git.kernel.org/cgit/libs/klibc/klibc.git Standards-Version: 4.1.2 Vcs-Browser: https://salsa.debian.org/kernel-team/klibc Vcs-Git: https://salsa.debian.org/kernel-team/klibc.git Build-Depends: debhelper-compat (= 12), linux-libc-dev, m4 [sparc] Build-Conflicts: ccache Package-List: klibc-utils deb libs optional arch=linux-any libklibc deb libs optional arch=linux-any libklibc-dev deb libdevel optional arch=linux-any Checksums-Sha1: eaa050b663783e1278c9038a76c21a605af701c9 472200 klibc_2.0.8.orig.tar.xz 2ca3434380de25cc6b9aa9080fc5feb5752f484c 26008 klibc_2.0.8-6.1.debian.tar.xz Checksums-Sha256: 4e48f1398cfe3ce0b6df55ce6e70acf54fc8488e3aea3fb3610ee1622d9cb436 472200 klibc_2.0.8.orig.tar.xz 0f02c2c6767c2cd4282dcca1065d8d5e99e46614c9628b261b8e0c92f3cfe0cd 26008 klibc_2.0.8-6.1.debian.tar.xz Files: bdd05bf16fce534e7a49d98644cdec87 472200 klibc_2.0.8.orig.tar.xz da02991a022086b2f2e6faebc4b96809 26008 klibc_2.0.8-6.1.debian.tar.xz klibc_2.0.8-6.1.debian.tar.xz Description: application/xz
Bug#922815: What is the current workaround?
On Wed, 5 May 2021, Kurt Fitzner wrote: > So yes, if this is a nonsensical combination, please do put in the > dependencies and conflicts that will enforce that for whatever packages > you maintain. I don’t maintain *any* of these packages. I just learnt that such a thing as rcconf exists at all and wondered about its description. Why don’t you ask the rcconf maintainer about this? bye, //mirabilos -- 15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#943425: [klibc] Bug#943425: Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use
tags 943425 + patch
tags 988027 + patch
thanks
Dixi quod…
>Patches for klibc upstream git attched; I’m currently trying to test
>them, will report.
This was really tricky given we can’t install patched B-Ds on
porterboxen, but I managed. I can confirm this fixes my issue.
bye,
//mirabilos
--
Beware of ritual lest you forget the meaning behind it.
yeah but it means if you really care about something, don't
ritualise it, or you will lose it. don't fetishise it, don't
obsess. or you'll forget why you love it in the first place.diff -Nru klibc-2.0.8/debian/changelog klibc-2.0.8/debian/changelog
--- klibc-2.0.8/debian/changelog2021-04-30 03:05:23.0 +0200
+++ klibc-2.0.8/debian/changelog2021-05-05 21:38:31.0 +0200
@@ -1,3 +1,11 @@
+klibc (2.0.8-6.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix sig{set,long}jmp always saves the signal mask (Closes: #988027)
+ * [s390x] Fix {set,long}jmp registers to save (Closes: #943425)
+
+ -- Thorsten Glaser Wed, 05 May 2021 21:38:31 +0200
+
klibc (2.0.8-6) unstable; urgency=medium
* Upload to unstable
diff -Nru
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
---
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
1970-01-01 01:00:00.0 +0100
+++
klibc-2.0.8/debian/patches/0001-klibc-sig-set-long-jmp-do-not-ignore-sigsetjmp-s-sec.patch
2021-05-05 21:38:31.0 +0200
@@ -0,0 +1,71 @@
+From ba9cce08553cb49fe077485b13ae99548bb2da5c Mon Sep 17 00:00:00 2001
+From: mirabilos
+Date: Wed, 5 May 2021 21:02:37 +0200
+Subject: [PATCH 1/2] [klibc] sig{set,long}jmp: do not ignore sigsetjmp's
+ second argument
+
+Save and restore the signal mask only if that argument is nonzero,
+as required by the standards. (Closes: Debian #988027)
+
+Signed-off-by: mirabilos
+---
+ usr/include/setjmp.h | 7 ++-
+ usr/klibc/CAVEATS | 3 +--
+ usr/klibc/siglongjmp.c | 3 ++-
+ 3 files changed, 9 insertions(+), 4 deletions(-)
+
+diff --git a/usr/include/setjmp.h b/usr/include/setjmp.h
+index abebccde..5916cd8a 100644
+--- a/usr/include/setjmp.h
b/usr/include/setjmp.h
+@@ -27,6 +27,7 @@ __extern __noreturn longjmp(jmp_buf, int);
+ struct __sigjmp_buf {
+ jmp_buf __jmpbuf;
+ sigset_t __sigs;
++ unsigned char __sigs_saved;
+ };
+
+ typedef struct __sigjmp_buf sigjmp_buf[1];
+@@ -34,7 +35,11 @@ typedef struct __sigjmp_buf sigjmp_buf[1];
+ #define sigsetjmp(__env, __save) \
+ ({ \
+ struct __sigjmp_buf *__e = (__env); \
+- sigprocmask(0, NULL, &__e->__sigs); \
++ if (__save) { \
++sigprocmask(0, NULL, &__e->__sigs); \
++__e->__sigs_saved = 1; \
++ } else \
++__e->__sigs_saved = 0; \
+ setjmp(__e->__jmpbuf); \
+ })
+
+diff --git a/usr/klibc/CAVEATS b/usr/klibc/CAVEATS
+index 5e991cb7..39949c28 100644
+--- a/usr/klibc/CAVEATS
b/usr/klibc/CAVEATS
+@@ -13,8 +13,7 @@ Compiling with -O0 is more likely to work on gcc 3.
+ setjmp()/longjmp():
+ ---
+ setjmp() and longjmp() *do not* save signal state. sigsetjmp() and
+-siglongjmp() *do* save the signal mask -- regardless of the value of
+-the extra argument.
++siglongjmp() *do* save the signal mask if the extra argument is nonzero.
+
+ The standards actually state that if you pass longjmp() a final value
+ of zero the library should change that to a 1! Presumably the reason
+diff --git a/usr/klibc/siglongjmp.c b/usr/klibc/siglongjmp.c
+index 31042cbd..45f4e400 100644
+--- a/usr/klibc/siglongjmp.c
b/usr/klibc/siglongjmp.c
+@@ -10,6 +10,7 @@
+
+ __noreturn siglongjmp(sigjmp_buf buf, int retval)
+ {
+- sigprocmask(SIG_SETMASK, &buf->__sigs, NULL);
++ if (buf->__sigs_saved)
++ sigprocmask(SIG_SETMASK, &buf->__sigs, NULL);
+ longjmp(buf->__jmpbuf, retval);
+ }
+--
+2.31.1
+
diff -Nru
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
---
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
1970-01-01 01:00:00.0 +0100
+++
klibc-2.0.8/debian/patches/0002-klibc-set-long-jmp-s390x-save-restore-the-correct-re.patch
2021-05-05 21:38:31.0 +0200
@@ -0,0 +1,76 @@
+From fc5a53932ee56d61a9fd8db75784e9f39ca474a3 Mon Sep 17 00:00:00 2001
+From: mirabilos
+Date: Wed, 5 May 2021 21:26:33 +0200
+Subject: [PATCH 2/2] [klibc] {set,long}jmp [s390x]: save/restore the correct
+ registers
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The s390x ABI actually has FPU registers f8‥f15, not f1/f3/f5/f7,
+to be saved. (Closes: Debian #943425)
+
+Signed-off-by: mirabilos
+---
+ usr/include/arch/s390/
Bug#942013: lintian: non-consecutive-debian-revision: false positive for NMUs
Package: lintian Version: 2.104.0 Followup-For: Bug #942013 X-Debbugs-Cc: t...@mirbsd.de This bug is still pertinent: X: klibc source: non-consecutive-debian-revision 2.0.8-6 -> 2.0.8-6.1 N: P: non-consecutive-debian-revision -- System Information: Debian Release: 11.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.10.0-5-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages lintian depends on: ii binutils2.35.2-2 ii bzip2 1.0.8-4 ii diffstat1.64-1 ii dpkg1.20.9 ii dpkg-dev1.20.9 ii file1:5.39-3 ii gettext 0.21-4 ii gpg 2.2.27-2 ii intltool-debian 0.35.0+20060710.5 ii libapt-pkg-perl 0.1.40 ii libarchive-zip-perl 1.68-1 ii libcapture-tiny-perl0.48-1 ii libclass-xsaccessor-perl1.19-3+b7 ii libclone-perl 0.45-1+b1 ii libconfig-tiny-perl 2.26-1 ii libcpanel-json-xs-perl 4.25-1+b1 ii libdata-dpath-perl 0.58-1 ii libdata-validate-domain-perl0.10-1.1 ii libdevel-size-perl 0.83-1+b2 ii libdigest-sha-perl 6.02-1+b3 ii libdpkg-perl1.20.9 ii libemail-address-xs-perl1.04-1+b3 ii libfile-basedir-perl0.08-1 ii libfile-find-rule-perl 0.34-1 ii libfont-ttf-perl1.06-1.1 ii libhtml-html5-entities-perl 0.004-1.1 ii libipc-run3-perl0.048-2 ii libjson-maybexs-perl1.004003-1 ii liblist-compare-perl0.55-1 ii liblist-moreutils-perl 0.430-2 ii liblist-utilsby-perl0.11-1 ii libmoo-perl 2.004004-1 ii libmoox-aliases-perl0.001006-1.1 ii libnamespace-clean-perl 0.27-1 ii libpath-tiny-perl 0.118-1 ii libperlio-gzip-perl 0.19-1+b7 ii libproc-processtable-perl 0.59-2+b1 ii libsereal-decoder-perl 4.018+ds-1+b1 ii libsereal-encoder-perl 4.018+ds-1+b1 ii libtext-glob-perl 0.11-1 ii libtext-levenshteinxs-perl 0.03-4+b8 ii libtext-markdown-discount-perl 0.12-1+b1 ii libtext-xslate-perl 3.5.8-1+b1 ii libtime-duration-perl 1.21-1 ii libtime-moment-perl 0.44-1+b3 ii libtimedate-perl2.3300-2 ii libtry-tiny-perl0.30-1 ii libtype-tiny-perl 1.012001-2 ii libunicode-utf8-perl0.62-1+b2 ii liburi-perl 5.08-1 ii libxml-libxml-perl 2.0134+dfsg-2+b1 ii libyaml-libyaml-perl0.82+repack-1+b1 ii lzip1.22-3 ii lzop1.04-2 ii man-db 2.9.4-2 ii patchutils 0.4.2-1 ii perl [libdigest-sha-perl] 5.32.1-4 ii t1utils 1.41-4 ii unzip 6.0-26 ii xz-utils5.2.5-2 lintian recommends no packages. Versions of packages lintian suggests: ii binutils-multiarch 2.35.2-2 pn libtext-template-perl -- no debconf information
Bug#943425: Debian #943425: klibc: [s390x] setjmp/longjmp do not save/restore all registers in use
Hi Andreas, >>> Jessica Clarke brought out docs saying f8‥f15 must be saved, the >>> other FPU registers not: > >I can confirm this. It is f8-f15 for the z/Architecture (64 bit). thanks! >It is f1, f3, f5, f7 for the ESA >architecture (32 bit) which is still supported by Glibc and GCC. Is this what we know as s390 in Debian? (klibc saves f4 and f6 there currently. If so, this also needs to change.) >>> … GCC chooses to allocate an FPU register for a pointer value. > >GCC will put integer values into vector registers for >auto-vectorization or for spilling. We also use call-clobbered FPRs as >save slots for GPRs in leaf-functions if can get rid of allocating a >stack frame that way. Ah, interesting. Thanks! >The vector registers are call-clobbered - exactly for the reason of >setjmp / longjmp. Only f8-f15 need to be saved. Right. >You can find the latest version of our ABI here: >https://github.com/IBM/s390x-abi/releases/download/v1.5/lzsabi_s390x.pdf > >However, it is still lacking the vector ABI extension. I wrote a >document for that which we use internally and we are working on >integrating it into the publicly available version. OK, thanks for the information! >>> @klibc list: as indicated earlier, I can provide a patch if needed >>> (though it should be obvious). hpa, maks, bwh: any of you taking these two or should I send patches and possibly NMU klibc in Debian? Thanks, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#922815: What is the current workaround?
On Tue, 4 May 2021, Kurt Fitzner wrote: > I just tried to install rcconf on a Debian testing sytem. Since rcconf How is rcconf even useful on a nōn-sysvinit+sysv-rc system? Maybe rcconf should depend on that or conflict with all others? bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#943425: Debian #943425: [s390x] setjmp/longjmp do not save/restore all registers in use
Dixi quod… >Jessica Clarke brought out docs saying f8‥f15 must be saved, the >other FPU registers not: This needs to be fixed in klibc. >>• klibc does not really support the FPU anyway > >… GCC chooses to allocate an FPU register for a pointer value. This is a curiosity. >>• the half of v10 that equals f10 just HAPPENS to be saved by >> glibc, but what if the upper half, that is outside of the FPU, >> is used? > >The question here is, does GCC only use the halves of the half >of the vector registers that match the FPU registers? 04:41⎜«jrtc27:#debian-x32» hephaistor: re s390x vector registers, reading the gcc and llvm sources they're ⎜all call-clobbered by default, only the float parts are call-saved 04:41⎜«jrtc27:#debian-x32» so that's why setjmp/longjmp don't need to save/restore them 04:42⎜«jrtc27:#debian-x32» there *is* a vector calling convention, but it's not the default for the ABI, ⎜it's opt-in, and setjmp/longjmp won't be annotated as such So we indeed need to only save the registers glibc does. >@klibc list: as indicated earlier, I can provide a patch if needed >(though it should be obvious). bye, //mirabilos -- [00:02] gecko: benutzt du emacs ? [00:03] nö [00:03] nur n normalen mac [00:04] argl [00:04] ne den editor -- Vutral und gecko2 in #deutsch (NB: Editor? Betriebssystem.)
Bug#943425: Debian #943425: [s390x] setjmp/longjmp do not save/restore all registers in use (was Use of $v10 register (was Re: klibc: [s390x] SIGSEGV in mksh testcase funsub-2))
Dixi quod… >So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia >https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors >“the z/Architecture ABI,[11] used in Linux” a page down), while >glibc’s save f8–f15 instead. Jessica Clarke brought out docs saying f8‥f15 must be saved, the other FPU registers not: https://refspecs.linuxfoundation.org/ELF/zSeries/lzsabi0_zSeries.html#AEN413 This matches what glibc does. Maybe an s390x porter wishes to fix Wikipedia? >https://share.confex.com/share/124/webprogram/Handout/Session16897/SHARE_Seattle_2015_SIMD.pdf >shows that the vector registers overlap and extend the FPU registers. >• is register v10 (vector extension) even supposed to be used? This needs to be answered, I guess, because… >• klibc does not really support the FPU anyway … GCC chooses to allocate an FPU register for a pointer value. >• the half of v10 that equals f10 just HAPPENS to be saved by > glibc, but what if the upper half, that is outside of the FPU, > is used? The question here is, does GCC only use the halves of the half of the vector registers that match the FPU registers? @klibc list: as indicated earlier, I can provide a patch if needed (though it should be obvious). bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#988027: klibc: sigsetjmp ignores second argument, siglongjmp always restores signals
Package: libklibc-dev
Version: 2.0.8-6
Severity: serious
Justification: spec violation, affecting release architectures
X-Debbugs-Cc: t...@debian.org
Found during debugging of #943425:
- usr/include/setjmp.h
struct __sigjmp_buf {
jmp_buf __jmpbuf;
sigset_t __sigs;
};
=> does not contain information whether __sigs was saved
#define sigsetjmp(__env, __save) \
({ \
struct __sigjmp_buf *__e = (__env); \
sigprocmask(0, NULL, &__e->__sigs); \
setjmp(__e->__jmpbuf); \
})
=> ignores the __save argument
- usr/klibc/siglongjmp.c
__noreturn siglongjmp(sigjmp_buf buf, int retval)
{
sigprocmask(SIG_SETMASK, &buf->__sigs, NULL);
longjmp(buf->__jmpbuf, retval);
=> always restores __sigs
This is in direct violation to the Debian sigsetjmp(3) docs...
If, and only if, the savesigs argument provided to sigsetjmp() is non-
zero, the process's current signal mask is saved in env and will be re-
stored if a siglongjmp() is later performed with this env.
... and POSIX:
* The siglongjmp() function shall restore the saved signal mask if and
only if the env argument was initialized by a call to [9]sigsetjmp()
with a non-zero savemask argument.
Q: https://pubs.opengroup.org/onlinepubs/9699919799/functions/siglongjmp.html
If necessary I can provide a patch to fix this.
-- System Information:
Debian Release: 11.0
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable')
Architecture: s390x
Kernel: Linux 4.19.0-16-s390x (SMP w/2 CPU threads)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: unable to detect
Versions of packages libklibc-dev depends on:
ii libklibc2.0.8-6
ii linux-libc-dev 5.10.28-1
libklibc-dev recommends no packages.
libklibc-dev suggests no packages.
-- no debconf information
Bug#943425: Use of $v10 register (was Re: klibc: [s390x] SIGSEGV in mksh testcase funsub-2)
retitle 943425 klibc: [s390x] setjmp/longjmp do not save/restore all registers
in use
# because this affects a release architecture
severity 943425 serious
thanks
Recapping for the benefit of d-s390@l.d.o:
> The code in question (where it crashes) is thus:
>1607 */
>1608 valsub(t, NULL);
>1609 subst_exstat = exstat & 0xFF;
>1610 /* rewind the tempfile and restore regular stdout */
>1611 lseek(shf_fileno(shf), (off_t)0, SEEK_SET);
> The crash occurs in line 1611 because shf (a local variable) is nil.
>
> The really interesting part, though, is in line 1608, a call to valsub():
[…]
>2104 if (!kshsetjmp(e->jbuf))
>2105 execute(t, XXCOM | XERROK, NULL);
[…]
kshsetjmp(x) is sigsetjmp(x,0) (though klibc ignores the 0).
execute() calls siglongjmp().
> - it appears as if the combination of sigsetjmp/siglongjmp does not restore
> all callee-saved variables correctly on s390x; comparing with glibc shows
> that the wrong FPU registers seem to be saved but mksh does not use the
> FPU anyway
>
> Setting breakpoints to lines 1608 (valsub call) and 1609:
[…]
> 1608valsub(t, NULL);
> (gdb) print shf
> $5 = (struct shf *) 0x3fffdfe5de8
> (gdb) print &shf
> Address requested for identifier "shf" which is in register $v10
> (gdb) print $v10
> $6 = {v4_float = {1.43352833e-42, -4.22639375e+37, 0, 0}, v2_double =
> {2.1729070589754877e-311, 0}, v16_int8 = {
> 0, 0, 3, -1, -3, -2, 93, -24, 0, 0, 0, 0, 0, 0, 0, 0}, v8_int16 = {0,
> 1023, -514, 24040, 0, 0, 0, 0},
> v4_int32 = {1023, -33661464, 0, 0}, v2_int64 = {4398012849640, 0}, uint128
> = 81129017470195127308370827018240}
>
> 0x3FFFDFE5DE8 is 4398012849640 which is in v2_int64, found.
[…]
> Breakpoint 2, comsub (fn=14, cp=0x0, xp=) at
> ../../eval.c:1609
> 1609subst_exstat = exstat & 0xFF;
[…]
> (gdb) print $v10
> $7 = {v4_float = {0, 0, 0, 0}, v2_double = {0, 0}, v16_int8 = {0 times>}, v8_int16 = {0, 0, 0, 0,
> 0, 0, 0, 0}, v4_int32 = {0, 0, 0, 0}, v2_int64 = {0, 0}, uint128 = 0}
--
So, setjmp/longjmp in klibc save f1/f3/f5/f7 (as shown on Wikipedia
https://en.wikipedia.org/wiki/Calling_convention#IBM_System/360_and_successors
“the z/Architecture ABI,[11] used in Linux” a page down), while
glibc’s save f8–f15 instead.
https://share.confex.com/share/124/webprogram/Handout/Session16897/SHARE_Seattle_2015_SIMD.pdf
shows that the vector registers overlap and extend the FPU registers.
(gdb) info float
[…]
f102.172907066248134e-311 (raw 0x03fffdfe9768)
(gdb) print shf
$2 = (struct shf *) 0x3fffdfe9768
The real questions here are:
• is register v10 (vector extension) even supposed to be used?
• klibc does not really support the FPU anyway
• the half of v10 that equals f10 just HAPPENS to be saved by
glibc, but what if the upper half, that is outside of the FPU,
is used?
• where *is* the s390x̲ ABI documented anyway? syscall(2) has the
kernel side only
Building with -mno-vx does not seem to help, %f* are still in
the .s files generated by gcc.
So I assume klibc should save registers f8–15 on s390x but what
happened to f1/f3/f5/f7?
Thanks,
//mirabilos
--
[17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker:
veni, vidi, fixi(t) ;-)
Bug#943425: klibc: [s390x] SIGSEGV in mksh testcase funsub-2
Package: libklibc-dev
Version: 2.0.8-6
Followup-For: Bug #943425
X-Debbugs-Cc: t...@debian.org
I am able to track this down on the porterbox zelenka.
$ apt-get source mksh
$ cd mksh-59c
$ mkdir -p build/klibc
$ cd build/klibc
$ cp /usr/lib/klibc/bin/mksh .
$ chmod +x mksh # because the x attribute is removed if testsfail
$ gdb --args ./mksh -c 'x=q; e=1; x=${ echo a; typeset e=2; return 3; echo
x$e;}; echo 3:y$x,$e,$?.'
(gdb) r
[...]
Program received signal SIGSEGV, Segmentation fault.
0x01007c32 in comsub (fn=14, cp=0x0, xp=) at
../../eval.c:1611
warning: Source file is more recent than executable.
1611lseek(shf_fileno(shf), (off_t)0, SEEK_SET);
(gdb) bt
#0 0x01007c32 in comsub (fn=14, cp=0x0, xp=) at
../../eval.c:1611
#1 expand (ccp=ccp@entry=0x3fffdfe4768 "\001x\001=\016\\echo a ; \\typeset e=2
; \\return 3 ; \\echo x$e ",
wp=wp@entry=0x3ffed48, f=f@entry=4128) at ../../eval.c:346
#2 0x0100a366 in evalstr (
cp=0x3fffdfe4768 "\001x\001=\016\\echo a ; \\typeset e=2 ; \\return 3 ;
\\echo x$e ", f=f@entry=4128)
at ../../eval.c:173
#3 0x0100d082 in comexec (t=0x3fffdfe4888, tp=tp@entry=0x0,
ap=0x3fffdfe45e8, flags=,
xerrok=) at ../../exec.c:640
#4 0x0100bf0a in execute (t=, flags=,
xerrok=xerrok@entry=0x0)
at ../../exec.c:162
#5 0x0100c0a2 in execute (t=t@entry=0x3fffdfe4588,
flags=flags@entry=0, xerrok=xerrok@entry=0x0)
at ../../exec.c:204
#6 0x0101e048 in shell (s=s@entry=0x3fffdfe3b68, level=level@entry=0)
at ../../main.c:954
#7 0x01000e78 in main (argc=, argv=) at
../../main.c:742
(gdb) print shf
$1 = (struct shf *) 0x0
The code in question (where it crashes) is thus:
1584 } else if (fn == FUNSUB) {
1585 int ofd1;
1586 struct temp *tf = NULL;
1587
1588 /*
1589 * create a temporary file, open for reading and
writing,
1590 * with an shf open for reading (buffered) but yet
unused
1591 */
1592 maketemp(ATEMP, TT_FUNSUB, &tf);
1593 if (!tf->shf) {
1594 errorf(Tf_temp,
1595 Tcreate, tf->tffn, cstrerror(errno));
1596 }
1597 /* extract shf from temporary file, unlink and free it
*/
1598 shf = tf->shf;
1599 unlink(tf->tffn);
1600 afree(tf, ATEMP);
1601 /* save stdout and let it point to the tempfile */
1602 ofd1 = savefd(1);
1603 ksh_dup2(shf_fileno(shf), 1, false);
1604 /*
1605 * run tree, with output thrown into the tempfile,
1606 * in a new function block
1607 */
1608 valsub(t, NULL);
1609 subst_exstat = exstat & 0xFF;
1610 /* rewind the tempfile and restore regular stdout */
1611 lseek(shf_fileno(shf), (off_t)0, SEEK_SET);
1612 restfd(1, ofd1);
The crash occurs in line 1611 because shf (a local variable) is nil.
The really interesting part, though, is in line 1608, a call to valsub():
2093 /* helper function due to setjmp/longjmp woes */
2094 static char *
2095 valsub(struct op *t, Area *ap)
2096 {
2097 char * volatile cp = NULL;
2098 struct tbl * volatile vp = NULL;
2099
2100 newenv(E_FUNC);
2101 newblock();
2102 if (ap)
2103 vp = local(TREPLY, false);
2104 if (!kshsetjmp(e->jbuf))
2105 execute(t, XXCOM | XERROK, NULL);
2106 if (vp)
2107 strdupx(cp, str_val(vp), ap);
2108 quitenv(NULL);
2109
2110 return (cp);
2111 }
Let's look again at the invocation that caused the crash:
x=q; e=1; x=${ echo a; typeset e=2; return 3; echo x$e;}; echo
3:y$x,$e,$?.
This one does not crash:
x=q; e=1; x=${ echo a; typeset e=2; echo x$e;}; echo 2:y$x,$e,$?.
The difference here is that 'return' is used in the crash case,
which executes a kshlongjmp(), that is siglongjmp(); kshsetjmp(x)
is sigsetjmp(x,0), which klibc defines as:
34 #define sigsetjmp(__env, __save) \
35 ({ \
36 struct __sigjmp_buf *__e = (__env); \
37 sigprocmask(0, NULL, &__e->__sigs); \
38 setjmp(__e->__jmpbuf); \
39 })
This apparently has two problems:
- the __save argument is ignored, contrary to sigsetjmp docs:
If, and only if, the savesigs argument provided to sigsetjmp() is non-
zero, the process's current signal mask is saved in env and will be re-
stored if a siglongjmp() is later performed with this env.
- it appears as if the combination of sigsetjmp/siglongjmp does not restore
all callee-saved variables corre
Bug#987975: unblock: mksh/59c-6
s only add backslashes that are safe (extra
backslashes in those cases can’t hurt anyway, eg. = is already
almost needlessly escaped)
- the memory leaks are low-risk as “obvious”
- same for the lexer change
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
(let it simmer in sid for a few days first)
unblock mksh/59c-6
diff -Nru mksh-59c/debian/changelog mksh-59c/debian/changelog
--- mksh-59c/debian/changelog 2021-03-13 19:09:48.0 +0100
+++ mksh-59c/debian/changelog 2021-05-03 03:26:28.0 +0200
@@ -1,3 +1,28 @@
+mksh (59c-6) unstable; urgency=medium
+
+ * Clear “taint” on most actions mutating a variable
+
+ -- Thorsten Glaser Mon, 03 May 2021 03:26:28 +0200
+
+mksh (59c-5) unstable; urgency=medium
+
+ * Apply targeted fixes, intended for bullseye:
+- [tg] Plug some memory leaks
+- [tg] Harden conversion of imported variables to integer, like
+ Perl “taint”: imported variables will now lose the value when
+ converting to integer but they are not purely numeric
+ (CVE-2019-14868 was a similar issue in AT&T ksh); honour
+ -o posix for leading-zero as octal, though (but continue not
+ when importing array indicēs)
+- [tg] Fix lexer token state corruption when reading new input;
+ makes evaluate-region editing command actually useful
+- [tg] Fix proper escaping/quoting and tab completion for tilde,
+ curly braces and \x02, either escaped or not
+Note: patches are reduced to minimum change for bullseye
+ * Rebuild for outdated Built-Using
+
+ -- Thorsten Glaser Sun, 02 May 2021 23:52:52 +0200
+
mksh (59c-4) unstable; urgency=low
* Update to upstream CVS HEAD
diff -pruN mksh_59c-4/check.t mksh_59c-6/check.t
--- mksh_59c-4/check.t 2021-05-03 00:29:50.0 +0200
+++ mksh_59c-6/check.t 2021-05-03 03:57:57.0 +0200
@@ -31,7 +31,7 @@
# (2013/12/02 20:39:44)
http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress/bin/ksh/?sortby=date
expected-stdout:
- KSH R59 2021/03/13
+ KSH R59 2021/05/03
description:
Check base version of full shell
stdin:
@@ -13230,6 +13230,41 @@ expected-stdout:
2=\x7Cfoo-e \x4B
3=\x7Cfoo-e \x4B
---
+name: env-intvars
+description:
+ Check that importing integers fails except for numbers
+stdin:
+ unset foo bar
+ print 1 $foo , $(typeset -p bar) .
+ print 2 $(foo=123 "$__progname" -c 'integer foo; print -- $foo' 2>&1) ,
\
+ $(env 'bar[123]=baz' "$__progname" -c 'typeset -p bar') .
+ print 3 $(foo='abc[$(echo >&2 fowled)0]' "$__progname" -c 'integer foo;
print -- $foo' 2>&1) , \
+ $(env 'bar[$(echo >&2 fowled)0]=baz' "$__progname" -c 'typeset -p
bar') .
+ print 4 $(foo=0123 "$__progname" +o posix -c 'integer foo; print --
$foo' 2>&1) , \
+ $(env 'bar[0123]=baz' "$__progname" +o posix -c 'typeset -p bar') .
+ # ksh93 does not do this:
+ print 5 $(foo=0123 "$__progname" -o posix -c 'integer foo; print --
$foo' 2>&1) .
+ # at import time FPOSIX is not yet set
+ print 6 $(foo=0x123 "$__progname" -c 'integer foo; print -- $foo' 2>&1)
, \
+ $(env 'bar[0x123]=baz' "$__progname" -c 'typeset -p bar') .
+ print 7 $(foo=12#123 "$__progname" -c 'integer foo; print -- $foo'
2>&1) , \
+ $(env 'bar[12#123]=baz' "$__progname" -c 'typeset -p bar') .
+ print 8 $(foo=1+1 "$__progname" -c 'integer foo; print -- $foo' 2>&1) ,
\
+ $(env 'bar[1+1]=baz' "$__progname" -c 'typeset -p bar') .
+ print 9 $(a=1 b=2 c=a "$__progname" -c 'typeset -p c; c=b; typeset -p
c; integer c; typeset -p c') .
+ print 0 $(a=1 b=2 c=a "$__progname" -c 'typeset -p c; typeset -p
c; integer c; typeset -p c') .
+expected-stdout:
+ 1 , .
+ 2 123 , set -A bar typeset -x bar[123]=baz .
+ 3 0 , .
+ 4 123 , set -A bar typeset -x bar[123]=baz .
+ 5 8#123 .
+ 6 16#123 , .
+ 7 12#123 , .
+ 8 0 , .
+ 9 typeset -x c=a typeset -x c=b typeset -i -x c=2 .
+ 0 typeset -x c=a typeset -x c=a typeset -i -x c=0 .
+---
name: utilities-getopts-1
description:
getopts sets OPTIND correctly for unparsed option
diff -pruN mksh_59c-4/edit.c mksh_59c-6/edit.c
--- mksh_59c-4/edit.c 2021-05-03 00:29:50.0 +0200
+++ mksh_59c-6/edit.c 2021-05-03 03:57:57.0 +0200
@@ -74,6 +74,7 @@ static struct {
#define XCF_COMMAND_FILE (XCF_COM
Bug#987848: Security issue: SQL injection with Microsoft SQL
Hi Robin, considering you took over maintenance and know the code in question better, it would be _much_ appreciated if you could also take care of this for buster. Thanks in advance, //mirabilos -- Thorsten Glaser (Founding Member) Teckids e.V. — Digital freedom with youth and education https://www.teckids.org/
Bug#987626: libreoffice: cannot type many things from my keyboard
Package: libreoffice Version: 1:7.0.4-3 Severity: normal X-Debbugs-Cc: t...@mirbsd.de With the following ~/.Xmodmap as my keyboard layout… http://www.mirbsd.org/cvs.cgi/contrib/samples/dot.Xmodmap?rev=1.24.4.15;content-type=text%2Fplain;only_with_tag=grml … on a PC/Thinkpad keyboard, observe that, compared to standard US layout, the key labelled “Alt” is in fact Mode_switch (like AltGr), and that the Windows key is mapped to Alt_L. In most applications… almost all, even… this works correctly. For example, key shortcuts with Ctrl-Alt-… (evilwm, IceWM) or just Alt-… (MuseScore/Qt) work by using the left Windows key as Alt key and when typing e.g. Mode_switch-ä I get ä etc. However, in soffice, this doesn’t work correctly. Mode_switch-d gives ä, correct, but these for example don’t work: • Mode_switch-Tab (supposed to give “) moves the cursor • Mode_switch-Return (supposedly •) does nothing • Mode_switch-F12 (supposedly ‑) changes the current paragraph to a numeric list‽ According to what I could found, Alt-F12 is supposed to show the options dialogue, and, using the proper key (i.e. the one with the Windows logo, remapped to Alt) does, but to change to a numeric list is just F12 (which also works), not Mode_switch-F12. This is seriously impeding my ability to type basically anything in soffice because I need „“ (German), “” (English), •–‐‑ for typographic correctness. Using Tₑχ/LᴬTᴇΧ instead isn’t always an option (e.g. for $dayjob, where WYSIWYG formats are needed for some documents). -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libreoffice depends on: ii libreoffice-base1:7.0.4-3 ii libreoffice-calc1:7.0.4-3 ii libreoffice-core1:7.0.4-3 ii libreoffice-draw1:7.0.4-3 ii libreoffice-impress 1:7.0.4-3 ii libreoffice-math1:7.0.4-3 ii libreoffice-report-builder-bin 1:7.0.4-3 ii libreoffice-writer 1:7.0.4-3 ii python3-uno 1:7.0.4-3 Versions of packages libreoffice recommends: ii fonts-crosextra-caladea 20130214-2.1 ii fonts-crosextra-carlito 20130920-1.1 ii fonts-dejavu2.37-2 ii fonts-liberation1:1.07.4-11 pn fonts-liberation2 ii fonts-linuxlibertine5.3.0-6 ii fonts-noto-core 20201225-1 pn fonts-noto-extra ii fonts-noto-mono 20201225-1 ii fonts-noto-ui-core 20201225-1 ii fonts-sil-gentium-basic 1.102-1.1 ii libreoffice-java-common 1:7.0.4-3 pn libreoffice-nlpsolver pn libreoffice-report-builder pn libreoffice-script-provider-bsh pn libreoffice-script-provider-js pn libreoffice-script-provider-python pn libreoffice-sdbc-mysql pn libreoffice-sdbc-postgresql pn libreoffice-wiki-publisher Versions of packages libreoffice suggests: ii cups-bsd2.3.3op2-3 ii default-jre [java8-runtime] 2:1.11-72 ii feistermops450 [firefox-esr]45.9.0m2 ii firefox-esr 78.9.0esr-1 ii ghostscript 9.53.3~dfsg-7 ii gnupg 2.2.27-1 pn gpa ii gstreamer1.0-libav 1.18.3-1 ii gstreamer1.0-plugins-bad1.18.3-1+b1 ii gstreamer1.0-plugins-base 1.18.3-1 ii gstreamer1.0-plugins-good 1.18.3-1 ii gstreamer1.0-plugins-ugly 1.18.3-1 ii hunspell-en-gb [hunspell-dictionary]1:7.1.0~rc3-3 pn hyphen-hyphenation-patterns ii imagemagick 8:6.9.11.60+dfsg-1 ii imagemagick-6.q16 [imagemagick] 8:6.9.11.60+dfsg-1 ii libgl1 1.3.2-1 pn libofficebean-java pn libreoffice-gnome | libreoffice-plasma pn libreoffice-grammarcheck ii libreoffice-help-en-gb [libreoffice-help] 1:7.0.4-3 ii libreoffice-l10n-en-gb [libreoffice-l10n] 1:7.0.4-3 pn libreoffice-librelogo pn libsane1
Bug#892842: OpenJDK 8 archive re-entry
Hi again, > > Emmanuel, will you or should I? > > Please do. sorry for taking a bit, but I did today. I talked a bit with elbrus, explaining the reasoning, and that, of course, this won’t end up in bookworm or have any sort of official support — I assume the normal process of looking at it and eventually getting back to us will run now. In the meantime I also prepared an 8u292-b10-1… found lots of issues even… but will wait uploading it until it was ACCEPTED into unstable because then the buildds can do their job, instead of me needing to do builds for each architecture… I’m building it for testing locally right now. > That said, we may also upload kotlin now even if openjdk-8 is still in > the queue. As long as they enter sid in the right order, that's fine. In I’d really prefer not. The first upload of openjdk-8 was done in a hackish way. Please wait with uploading kotlin until 8u292 is both uploaded *and* built by the buildds *and* in status Installed, so it’s ready as B-D for further builds. > the worst case kotlin will be accepted before openjdk-8 and simply > prevented from transitioning to testing until openjdk-8 arrives. If kotlin runtime-Depends on openjdk-8 there’s no chance it’ll ever end up in testing anyway ☺ and even if not, it’d only do so after the bullseye release of course. > > I’m not exactly sure this method is the preferred one, especially > > given ebourg’s alternative bootstrapping path from source is > > progressing admirably. (Not to throw away that work though, it’ll > > become useful nearer to that bootstrapping processes end.) > > To be honest, I still have a very long way to go and I'm not even sure > to succeed (I spent a full day dealing with 2 months worth of commits, > and I'm only at the Q2 2015 code). Right. > They've done a great work, I don't think my approach replaces theirs, at > best I may reconnect with them to provide the bootstrap compiler, or > certify later that both approaches produce the same binaries. That’s certainly one way to do it, if things build reproducibly. We probably should look at rebootstrapping openjdk-8 at some point in time as well… the fetch-orig target used http, not https, for downloading the sources… one of the things I’m fixing in 8u292-b10-1 (except for icedtea-sound because of unavailability of https for it but I downloaded it manually, verified-ish it with PGP and added a SHA256 check to d/rules for it so it’s at least consistent). bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#718415: Closing this bug (BTS maintenance for src:linux bugs)
Hi Salvatore, >If you can reproduce it with > >- the current version in unstable/testing >- the latest kernel from backports I still have the occasional freezes or crashes on that machine, with nouveau, but nothing to reliably reproduce it. Basically, if Xorg is left running for long, either it or the entire machine eventually crashes (mostly just the X server, symptom is the session terminates, kdm shows up, rarely the entire machine). It may be that nouveau support for that particular chip is buggy? Since I currently use the box remotely only (due to Corona), I’ve just not logged in graphically and stopped kdm so it reliably runs (using xrdp or ssh), but I’ve recently seen this happen, I believe a bit over three weeks ago (my syslog does not go back this far, this is the uptime) I had to drive there and reset it by pressing the power button long. Do you consider this enough for reopening? /var/log/dmesg: [0.00] microcode: microcode updated early to revision 0x1d, date = 2018-05-11 [0.00] Linux version 5.10.0-5-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.24-1 (2021-03-19) [0.00] Command line: BOOT_IMAGE=/vmlinuz-5.10.0-5-amd64 root=/dev/mapper/vg--tglase-lv--tglase ro rootdelay=5 net.ifnames=0 syscall.x32=y vsyscall=emulate kaslr l1tf=flush,nosmt [0.00] x86/fpu: x87 FPU will use FXSAVE [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009dbff] usable [0.00] BIOS-e820: [mem 0x0009f800-0x0009] reserved [0.00] BIOS-e820: [mem 0x000f-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0xcfec] usable [0.00] BIOS-e820: [mem 0xcfed-0xcfed0fff] ACPI NVS [0.00] BIOS-e820: [mem 0xcfed1000-0xcfed] ACPI data [0.00] BIOS-e820: [mem 0xcfee-0xcfef] reserved [0.00] BIOS-e820: [mem 0xf400-0xf7ff] reserved [0.00] BIOS-e820: [mem 0xfec0-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00062fff] usable [0.00] NX (Execute Disable) protection: active [0.00] SMBIOS 2.4 present. [0.00] DMI: Gigabyte Technology Co., Ltd. X58-USB3/X58-USB3, BIOS F5 09/07/2011 [0.00] tsc: Fast TSC calibration using PIT [0.00] tsc: Detected 3064.502 MHz processor [0.003119] e820: update [mem 0x-0x0fff] usable ==> reserved [0.003124] e820: remove [mem 0x000a-0x000f] usable [0.003132] last_pfn = 0x63 max_arch_pfn = 0x4 [0.003138] MTRR default type: uncachable [0.003140] MTRR fixed ranges enabled: [0.003142] 0-9 write-back [0.003143] A-B uncachable [0.003145] C-CDFFF write-protect [0.003146] CE000-E uncachable [0.003148] F-F write-through [0.003149] MTRR variable ranges enabled: [0.003151] 0 base 0 mask F write-back [0.003153] 1 base 0E000 mask FE000 uncachable [0.003155] 2 base 0D000 mask FF000 uncachable [0.003157] 3 base 1 mask F write-back [0.003158] 4 base 2 mask E write-back [0.003160] 5 base 4 mask C write-back [0.003162] 6 base 5 mask F write-back [0.003164] 7 base 6 mask FC000 write-back [0.004135] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.004696] e820: update [mem 0xd000-0x] usable ==> reserved [0.004704] last_pfn = 0xcfed0 max_arch_pfn = 0x4 [0.014278] found SMP MP-table at [mem 0x000f5a60-0x000f5a6f] [0.028268] RAMDISK: [mem 0x33b95000-0x35dc1fff] [0.028281] ACPI: Early table checksum verification disabled [0.028286] ACPI: RSDP 0x000F7200 14 (v00 GBT ) [0.028294] ACPI: RSDT 0xCFED1040 48 (v01 GBTGBTUACPI 42302E31 GBTU 01010101) [0.028303] ACPI: FACP 0xCFED1100 74 (v01 GBTGBTUACPI 42302E31 GBTU 01010101) [0.028313] ACPI: DSDT 0xCFED11C0 00391C (v01 GBTGBTUACPI 1000 MSFT 010C) [0.028321] ACPI: FACS 0xCFED 40 [0.028327] ACPI: MSDM 0xCFED4CC0 55 (v03 GBTGBTUACPI 42302E31 GBTU 01010101) [0.028334] ACPI: HPET 0xCFED4D80 38 (v01 GBTGBTUACPI 42302E31 GBTU 0098) [0.028341] ACPI: MCFG 0xCFED4E00 3C (v01 GBTGBTUACPI 42302E31 GBTU 01010101) [0.028348] ACPI: EUDS 0xCFED4E40 0004D0 (v01 GBT ) [0.028355] ACPI: MATS 0xCFED5310 34 (v01 GBT ) [0.028362] ACPI: TAMG 0xCFED5380 000CFA (v01 GBTGBT B0 5455312E BG?? 53450101) [0.028369] ACPI:
Bug#892842: OpenJDK 8 archive re-entry
Hi Phil, > I'm sure it's just a matter of time, but have you had any feedback from > ftp-masters about openjdk-8? unfortunately not yet. They’re probably depriorising sid in times of freeze, but the grace period for not bothering them is probably over by now so if ebourg doesn’t want to prod them now, I can do this but nobody else should so they don’t get annoyed. Emmanuel, will you or should I? > Thanks to Sunil for the major breakthrough, > we are now ready to [upload] kotlin which is now [blocked] on this. I’m not exactly sure this method is the preferred one, especially given ebourg’s alternative bootstrapping path from source is progressing admirably. (Not to throw away that work though, it’ll become useful nearer to that bootstrapping processes end.) bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#987316: initscripts: tmpfs has wrong size
On Wed, 21 Apr 2021, Roger Lynn wrote: > Swap is apparently initialised later. There are three calls to that script > recorded by bootlogd and on all of them SwapTotal is 0 kB. It then prints the > lines for "Mounting local filesystems", "Activating swapfile swap, if any" and > "Cleaning up temporary files". Do you still need the full debug output? No, I think we have it then. Nothing I can immediately think of to fix this. We really want tmpfs as early as possible; some swap devices may not yet be available. Maybe we could initialise those which are, though, but not for bullseye, definitely. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#987316: initscripts: tmpfs has wrong size
severity 987316 minor thanks On Wed, 21 Apr 2021, Roger Lynn wrote: > Thanks for the clarification. I think that reduces this bug to "Why is my > tmpfs set to 20% of physical RAM rather than 20% of total virtual memory?" There’s a difference betwen setting it to 20% and to 20%VM. The default value is 20%VM though. tmpfs_size_vm uses vm_size which combines RAM and swap size and calculates a size in KiB based on it (with some extra rounding down due to dividing by 100 first in order to stay within values shell arithmetic can do without UB). However ram_size and swap_size rely on /proc/meminfo, grep and a pretty involved sed command, which can even fail badly, as it doesn’t use sed -n. If anything fails in calculating vm_size, or if using 20% instead of 20%VM, the value is passed as '20%' instead of a size in KiB to mount, so the kernel will do the rest. I think our best bet to tracking this down would be: • add “set -x” as first and “set +x” as last line to /lib/init/tmpfs.sh • perhaps also add “grep Total /proc/meminfo” in there for extra debugging • reboot with serial console, so we can actually capture all the debug messages I suspect one of the operations involved fails for you, or swap is initialised later. Hrm. I have TMP_SIZE=80%VM in my /etc/default/tmpfs and I get… $ df -k Filesystem 1K-blocks Used Available Use% Mountpoint tmpfs 64586403624664283397657% /tmp $ fgrep Total /proc/meminfo MemTotal:8073324 kB SwapTotal: 3206140 kB Okaaay, I guess I can reproduce this. Then I can probably debug this in a VM, as to easier get serial console (I do have a physical serial port, but…). > (And the rewording of the manual page would be nice too.) Agreed, but I believe this is now of minor severity. If nobody complains I’ll commit that change for the next regular upload. bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#987316: initscripts: tmpfs has wrong size
On Wed, 21 Apr 2021, Roger Lynn wrote: > tmpfs(5) says: >TMPFS_SIZE > Maximum size for all tmpfs filesystems if no specific size is > provided. The default is 20%VM (20% of virtual memory, includ‐ > ing swap space). If no value is provided here, the kernel de‐ > fault (50% RAM) will be used. > > I find this confusing, because the default in /etc/defaults/tmpfs is: > #TMPFS_SIZE=20%VM I found it confusing as well, which is why I tracked this down. To “provide no value” you have to actually do… TMPFS_SIZE= … in /etc/defaults/tmpfs because the commented-out value is default. Perhaps rewording tmpfs(5) to say “If this is explicitly set to the empty string, the kernel default…” is in order? HTH&HAND, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#985634: git (1:2.31.0-1): no longer runs addons from /usr/lib/git-core breaking lots of 3rdpty stuff
Chris Hofstaedtler dixit: >installation path. I imagine going back is now hopeless, so either >git searches both paths, or all other packages are just rc-buggy. I wasn’t considering just packages; unpackaged (or third-party- packaged) extensions will also be affected. Both paths is a good plan. Thanks, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#985634: git (1:2.31.0-1): no longer runs addons from /usr/lib/git-core breaking lots of 3rdpty stuff
Hi again, >I imagine *many* other third-party addons do the same. Please >make git search the old location after the new one (preferred) >or revert this change at least until past the bullseye release >(not preferred, as libexec is actually correct). ping?
Bug#987167: unblock: jamulus/3.6.2+dfsg1-3
al servers are operated by the Jamulus project; there is
+a central server for each genre, which is how public servers are
+categorised into genres.
+.Sh SEE ALSO
+.Xr qjackctl 1
+.Bl -tag -width Ds
+.It Pa https://jamulus.io/wiki/Software\-Manual
+online handbook
+.It Pa https://jamulus.io/wiki/Choosing\-a\-Server\-Type
+more details on the individual server types
+.It Pa https://jamulus.io/wiki/Running\-a\-Server
+documentation on server configuration
+.It Pa https://jamulus.io/wiki/Central\-Servers
+current list of central servers operated by the Jamulus project,
+controlling the
+.Dq genre
+.It Pa https://jamulus.io/wiki/Tips\-Tricks\-More
+verbose
+.Fl \-ctrlmidich
+documentation and other more or less useful information
+.El
+.Sh AUTHORS
+.An -nosplit
+.An mirabilos Aq t...@debian.org
+wrote this manual page for the Debian project,
+but it may be used elsewhere as well.
+.Sh BUGS
+This manual page was derived from the source code and summarises
+some of the information from the website, but it could be more helpful.
+.Pp
+Some of the networking code seems to assume Legacy IP
+.Pq IPv4 .
diff -Nru jamulus-3.6.2+dfsg1/debian/changelog
jamulus-3.6.2+dfsg1/debian/changelog
--- jamulus-3.6.2+dfsg1/debian/changelog2021-01-26 00:03:00.0
+0100
+++ jamulus-3.6.2+dfsg1/debian/changelog2021-04-11 16:04:40.0
+0200
@@ -1,3 +1,21 @@
+jamulus (3.6.2+dfsg1-3) unstable; urgency=low
+
+ * Update GitHub URLs
+- the repository moved to a{n, new} organisation
+- GitHub’s tags and releases pages changed tarball links
+ * Mark diff as applied upstream
+ * Run jdupes on the installed documentation as lintian demands
+ * Ship a manpage (Debian-specific for now)
+ * Merge updated list of central (genre) servers offered by upstream
+ * Also apply upstream fix for memory leaks
+ * Add patch to correctly escape messages received from clients
+ * Backport code around --serverpublicip to support running servers
+behind IPv4 NAT; also a prerequisite of the following patch
+ * Privacy fix: cease sending a packet to Cloudflare to determine
+the (nōn-NAT) external interface / IP address
+
+ -- Thorsten Glaser Sun, 11 Apr 2021 16:04:40 +0200
+
jamulus (3.6.2+dfsg1-2) unstable; urgency=low
* Upload to unstable
diff -Nru jamulus-3.6.2+dfsg1/debian/control jamulus-3.6.2+dfsg1/debian/control
--- jamulus-3.6.2+dfsg1/debian/control 2020-12-29 20:28:29.0 +0100
+++ jamulus-3.6.2+dfsg1/debian/control 2021-04-11 15:44:40.0 +0200
@@ -4,6 +4,7 @@
Maintainer: Thorsten Glaser
Homepage: https://jamulus.io/
Build-Depends: debhelper-compat (= 13),
+ jdupes,
libjack-jackd2-dev,
qtbase5-dev,
qtdeclarative5-dev,
diff -Nru jamulus-3.6.2+dfsg1/debian/copyright
jamulus-3.6.2+dfsg1/debian/copyright
--- jamulus-3.6.2+dfsg1/debian/copyright2020-12-29 21:57:20.0
+0100
+++ jamulus-3.6.2+dfsg1/debian/copyright2021-04-11 15:44:40.0
+0200
@@ -1,7 +1,7 @@
Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: Jamulus
Upstream-Contact: https://sourceforge.net/p/llcon/discussion/
-Source: https://github.com/corrados/jamulus
+Source: https://github.com/jamulussoftware/jamulus
# Removed embedded convenience code copies and binaries
Removed embedded binaries (libs blocked by #686777)
Copyright: 2004–2020 Volker Fischer and others
diff -Nru jamulus-3.6.2+dfsg1/debian/jamulus.lintian-overrides
jamulus-3.6.2+dfsg1/debian/jamulus.lintian-overrides
--- jamulus-3.6.2+dfsg1/debian/jamulus.lintian-overrides2020-12-29
20:28:29.0 +0100
+++ jamulus-3.6.2+dfsg1/debian/jamulus.lintian-overrides2021-04-11
15:44:40.0 +0200
@@ -1,15 +1,2 @@
-# I promise to write one for the second upload
-# (the first upload goes to experimental and
-# has to pass ftpmaster NEW; the second one
-# will promote it to unstable) documenting the
-# then-current state of command line options,
-# as they can change…
-jamulus: no-manual-page usr/bin/Jamulus
-
# false positive; I checked all invocations of gcc and g++ in the build log
jamulus: hardening-no-fortify-functions usr/bin/Jamulus
-
-# for now, ignore them; it’s 4 small files, and the next (upstream) version
-# will most likely not ship them at all; otherwise I’ll tackle it in the
-# (second) upload (like above)
-jamulus: duplicate-files usr/share/doc/jamulus/homepage/*
diff -Nru jamulus-3.6.2+dfsg1/debian/jamulus.manpages
jamulus-3.6.2+dfsg1/debian/jamulus.manpages
--- jamulus-3.6.2+dfsg1/debian/jamulus.manpages 1970-01-01 01:00:00.0
+0100
+++ jamulus-3.6.2+dfsg1/debian/jamulus.manpages 2021-04-11 15:57:31.0
+0200
@@ -0,0 +1 @@
+debian/Jamulus.1
diff -Nru jamulus-3.6.2+dfsg1/debian/patches/1073.diff
jamulus-3.6.2+dfsg1/debian/patches/1073.diff
--- jamulus-3.6.2+dfsg1/debian/patches/1073.diff1970-01-01
01:00:00.0 +0100
+++ jamulus-3.6.2+dfsg1/debian/patches/1073.diff
Bug#986762: firefox-esr: mishandles combining characters in textarea
Package: firefox-esr
Version: 78.9.0esr-1
Severity: minor
X-Debbugs-Cc: t...@mirbsd.de
🥄⃠ is misrendered in s (one after another, the second
glyph is not composed on top of the first one as UCS requires),
but it is handled right-ish in input fields, etc.
-- Package-specific info:
-- Extensions information
Name: Amazon.com
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: Autoplay Settings for YouTube
Location: ${PROFILE_EXTENSIONS}/{14e605a0-6fdd-43e9-891a-29f6e481db24}.xpi
Status: enabled
Name: Bing
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: Classic Theme Restorer
Location: ${PROFILE_EXTENSIONS}/classicthemeresto...@arist2noia4dev.xpi
Status: app-disabled
Name: Clear Search 2
Location: ${PROFILE_EXTENSIONS}/clearsear...@extension-id.invalid.xpi
Status: app-disabled
Name: Crowdbar
Location: ${PROFILE_EXTENSIONS}/jid1-xgbyhwcvipe...@jetpack.xpi
Status: enabled
Name: Dark theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled
Name: Dark Reader
Location: ${PROFILE_EXTENSIONS}/ad...@darkreader.org.xpi
Status: enabled
Name: Default theme
Location: /usr/lib/firefox-esr/omni.ja
Package: firefox-esr
Status: enabled
Name: DoH Roll-Out
Location: /usr/lib/firefox-esr/browser/features/doh-roll...@mozilla.org.xpi
Package: firefox-esr
Status: enabled
Name: DuckDuckGo
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: Firefox Screenshots
Location: /usr/lib/firefox-esr/browser/features/screensh...@mozilla.org.xpi
Package: firefox-esr
Status: enabled
Name: Form Autofill
Location: /usr/lib/firefox-esr/browser/features/formautof...@mozilla.org.xpi
Package: firefox-esr
Status: enabled
Name: Google
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: HTTPS Everywhere
Location: /usr/share/webext/https-everywhere
Package: webext-https-everywhere
Status: user-disabled
Name: Image Max URL
Location: ${PROFILE_EXTENSIONS}/max...@qsniyg.xpi
Status: enabled
Name: Light theme
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: user-disabled
Name: Never-Consent
Location: ${PROFILE_EXTENSIONS}/{816c90e6-757f-4453-a84f-362ff989f3e2}.xpi
Status: enabled
Name: Offline QR Code Generator
Location: ${PROFILE_EXTENSIONS}/offline-qr-c...@rugk.github.io.xpi
Status: enabled
Name: Old Image Style
Location: ${PROFILE_EXTENSIONS}/{dfac41f2-b87d-4759-8825-a8bfd4cce744}.xpi
Status: enabled
Name: SoundFixer
Location: ${PROFILE_EXTENSIONS}/soundfi...@unrelenting.technology.xpi
Status: enabled
Name: Tampermonkey
Location: ${PROFILE_EXTENSIONS}/fire...@tampermonkey.net.xpi
Status: enabled
Name: Twitter View Original Images
Location: ${PROFILE_EXTENSIONS}/{0e05c778-ab7d-45a5-98d0-ed365ac4653b}.xpi
Status: user-disabled
Name: User-Agent Switcher and Manager
Location: ${PROFILE_EXTENSIONS}/{a6c4a591-f1b2-4f03-b3ff-767e5bedf4e7}.xpi
Status: enabled
Name: Wayback Machine
Location: ${PROFILE_EXTENSIONS}/wayback_mach...@mozilla.org.xpi
Status: enabled
Name: Web Compat
Location: /usr/lib/firefox-esr/browser/features/webcom...@mozilla.org.xpi
Package: firefox-esr
Status: enabled
Name: WebCompat Reporter
Location:
/usr/lib/firefox-esr/browser/features/webcompat-repor...@mozilla.org.xpi
Package: firefox-esr
Status: user-disabled
Name: Wikipedia (en)
Location: /usr/lib/firefox-esr/browser/omni.ja
Package: firefox-esr
Status: enabled
Name: YouTube Ad Auto-skipper
Location: ${PROFILE_EXTENSIONS}/{bd6b8f4a-b0c3-4d61-a0f8-5539d3df3959}.xpi
Status: enabled
-- Plugins information
-- Addons package information
ii firefox-esr 78.9.0esr-1 amd64Mozilla Firefox web
browser - Extended Support Release (ESR)
ii webext-https-everywhere 2021.1.27-1 all Extension to force the
use of HTTPS on many sites
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500,
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages firefox-esr depends on:
ii debianutils 4.11.2
ii fontconfig 2.13.1-4.2
ii libatk1.0-0 2.36.0-2
ii libc62.31-11
ii libcairo-gobject21.16.0-5
ii libcairo21.16.0-5
ii libdbus-1-3 1.12.20-2
ii libdbus-glib-1-2 0.110-6
ii libevent-2.1-7 2.1.12-stable-1
ii libffi7 3.3-6
ii libfontconfig1 2.13.1-4.2
ii libfreetype6 2.10.4+dfsg-1
ii libgcc-s110.2.1-6
ii libgdk-pixbuf-2.0-0 2.42.2+dfsg-1
ii libglib2.0-0 2.66.8
Bug#986408: lsb-release: ValueError: could not convert string to float: '6.06 LTS' (was Re: Bug#986408: mali-midgard-dkms: Fail to install/build)
Hi, > > begin 644 986408.patch > > Quite clearly the best format for attachments in the BTS. well it was convenient on the sending side, as I had both the MTA and the file on different remote systems. It’s standard enough anyway. > > Sounds like it’s only relevant to *buntu though? > > That's why I wrote "system configuration confuses lsb_release" - > probably into thinking its an Ubuntu system, when it should detect > Debian. At least from the code in lsb_release I guess it does that. Hmh. > The lsb-release Maintainers might however actually have more insight Unlikely, the package moved to debian-init-diversity recently. > into that and can figure out together with Christian Marillat whats > going wrong. […] > However none of that is relevant for finding the root cause... Might be. Looking at the patch, it’s most likely harmless though, and in all currently-working cases a nop… I’m not the one working on this though, just saw it fluttering by. bye, //mirabilos -- «MyISAM tables -will- get corrupted eventually. This is a fact of life. » “mysql is about as much database as ms access” – “MSSQL at least descends from a database” “it's a rebranded SyBase” “MySQL however was born from a flatfile and went downhill from there” – “at least jetDB doesn’t claim to be a database” (#nosec)‣‣‣ Please let MySQL and MariaDB finally die!
Bug#986408: lsb-release: ValueError: could not convert string to float: '6.06 LTS' (was Re: Bug#986408: mali-midgard-dkms: Fail to install/build)
Christian Marillat dixit:
>A patch is available here :
>
>https://itectec.com/ubuntu/ubuntu-ubuntu-18-04-stuck-on-verbose-screen-on-startup/
You could have attached it so it’s easier for the maintainers.
I’m hereby doing that.
begin 644 986408.patch
M+2TM(&QS8E]R96QE87-E+G!Y"3(P,3DM,#,M,#D@,3DZ,S`Z-3(N,#`P,#`P
M,#`P("LP,3`P"BLK*R!L0DR,#(Q+3`T+3`V(#`R.C`S
M.C0W+C(W-#DU,#0Y-"`K,#(P,`I`0"`M-#4L-R`K-#4L-R!`0`H@("`@(&=L
M;V)A;"!214Q%05-%7T-/1$5.04U%7TQ/3TM54"P@4D5,14%315-?3U)$15(L
M(%1%4U1)3D=?0T]$14Y!344*("`@("!214Q%05-%7T-/1$5.04U%7TQ/3TM5
M4"`]('L@3UL86UB9&$@;CH@9FQO870H;ELP
M72YS<&QI="@I6S!=*2D*("`@("!214Q%05-%4U]/4D1%4B`](&QI
Bug#986431: unblock: mksh/59c-4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: t...@mirbsd.de Please unblock package mksh [ Reason ] This change was made under the impression that it would migrate thanks to autopkgtests… I was taken by surprise that mksh is a key package. I debugged that and found that debhelper B-D on shunit2 which B-D on mksh, which causes it to be a key package. Now shunit2 only B-D on mksh because it uses mksh at build time to run its tests, but shunit2’s build only fails if the last (shell, test) tuple fails, which is zsh. The change (asides from updating the documentation, especially wrt. future compatibility guarantees) brings mksh closer to the other shells in that it implements a form of POSIX locale trak‐ king to enable/disable UTF-8 mode (instead of mostly defaulting to C). Furthermore, a few Emacs input editing mode commands are extended to be able to operate on bigwords (like in Vi mode), not only words. [ Impact ] The user who requested the Emacs mode extension will be sad and have to wait for another release (unless I backport mksh, which I may do or may not do later). The shell will behave more closely to the previous releases’ mksh and less like a future mksh and most other shells wrt. handling the POSIX locale. I would consider that unfortunate. [ Tests ] mksh has an extensive regression test suite which exercises a good portion of the code (and the compiler, toolchain and libc/kernel). The testsuite was updated to match the expectations of locale trak‐ king as implemented (minor) and the changes were reviewed. I’ve run the shell, even as /bin/sh (supported but only as manual step in Debian), for more than three weeks now, extensively using it, and found no problems. I’ve verified the interactive mode change as well. [ Risks ] As stated above, the risk is minimal, considering what shunit2 does and when it was changed last, incidentally. mksh is used as direct dependency by not many packages, and while it’s installed on 2454 systems, few would install it as /bin/sh, and those people know what they’re doing. A standard Debian installation will not have mksh even installed. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [↓] attach debdiff against the package in testing I’ve changed the debdiff to change the diff-to-a-patch into a diff between the patched files (the packaging uses single-debian-patch as I normally work on a fully patched tree with git and every new upstream release will have the Debian-local changes go down to 0) to make it more readable. The last time I did that it was accepted. [ Other info ] In a clean bullseye chroot, the autopkgtests pass. unblock mksh/59c-4 diff -Nru mksh-59c/debian/changelog mksh-59c/debian/changelog --- mksh-59c/debian/changelog 2021-02-07 02:57:12.0 +0100 +++ mksh-59c/debian/changelog 2021-03-13 19:09:48.0 +0100 @@ -1,3 +1,27 @@ +mksh (59c-4) unstable; urgency=low + + * Update to upstream CVS HEAD +- [tg] Make "C" the implementation-specified default locale for + early-locale-tracking (note full locale tracking will have to + use whatever the underlying OS’ is, if no setlocale(3) it’ll + be just "C" again) and document possibly removing turning on + POSIX mode disabling and presence of a BOM enabling UTF-8 mode + with full locale tracking +- [tg] Document OPTU-16 (U+EF80‥U+EFFF) mapping for raw octets will not + be present once mksh will have switched to full 21-bit UCS / UTF-8 +- [tg] Add several bigword-based editing commands to Emacs mode +- [tg] Improve documentation wrt. $ENV + * Bring locale tracking code somewhat closer to what will eventually be +in upstream code (once I manage to do the related changes around MirBSD +base and its scripts, which needs some more time and tuits): +- drop BOM enabling UTF-8 mode code +- no longer deactivate UTF-8 mode on entering POSIX mode + (rationale: the POSIX locale parameters will be the only deciding + factor; even if, nominally, only the POSIX locale is compliant) + * Apply locale tracking to nōn-interactive shells as well + + -- Thorsten Glaser Sat, 13 Mar 2021 19:09:48 +0100 + mksh (59c-3) unstable; urgency=medium * Update to upstream CVS HEAD diff --git mksh_59c-3/check.t mksh_59c-4/check.t index e8f96af..7c601fb 100644 --- mksh_59c-3/check.t +++ mksh_59c-4/check.t @@ -31,7 +31,7 @@ # (2013/12/02 20:39:44) http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/regress/bin/ksh/?sortby=date expected-stdout: - KSH R59 2021/02/07 + KSH R59 2021/03/13 description: Check base version of full shell stdin: @@ -8890,7 +8890,7 @@ expected-stderr-pattern: --- name: utf8opt-1 description: - Check that the utf8-mode flag is not set at non-interactive startup + Check that the utf8-mode flag *is* set at non-interactive star
Bug#799476: libc6: strftime should allow extended-format timezone (ISO 8601)
Package: libc6 Version: 2.31-10 Followup-For: Bug #799476 X-Debbugs-Cc: t...@mirbsd.de Control: tags 799476 + upstream Incidentally, I came here to report precisely this (strftime(3) and date(1) not consistent wrt. GNU extensions). I’ve since added %-d and %:z to MirBSD libc’s strftime(3) — whose date(1) uses that. I’ve noticed that trying to use %:z in a locale category fails, but passing it directly to date(1) works: $ LC_TIME=de_DE.UTF-8 date +"$(LC_TIME=de_DE.UTF-8@iso8601 locale d_t_fmt)" 2021-04-04T21:34:31+02:00 (CEST), 2021-W13-7 (So) $ LC_TIME=de_DE.UTF-8@iso8601 date +%c 2021-04-04T21:34:35%:z (CEST), 2021-W13-7 (So) I thought I could get by with using "%Y-%m-%dT%H:%M:%S%z (%Z), %G-W%V-%u (%a)" but the OP makes a good point that mixing basic and extended formats is not permitted either. Please forward this upstream so it’ll be implemented. Thanks! -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libc6 depends on: ii libcrypt1 1:4.4.18-2 ii libgcc-s1 10.2.1-6 Versions of packages libc6 recommends: ii libidn2-0 2.3.0-5 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.76 ii glibc-doc 2.31-10 ii libc-l10n 2.31-10 ii locales2.31-10 -- debconf information: glibc/kernel-too-old: glibc/restart-services: * glibc/upgrade: true glibc/disable-screensaver: glibc/kernel-not-supported: * libraries/restart-without-asking: true glibc/restart-failed:
Bug#771117: etckeeper: stores passwd- backup files
Package: etckeeper Version: 1.18.10-1 Followup-For: Bug #771117 etckeeper should add *~, *-, *.dpkg* and *.ucf* to its default ignore list (to avoid this and similar issues). -- System Information: Debian Release: 10.9 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages etckeeper depends on: ii debconf [debconf-2.0] 1.5.71 ii git1:2.20.1-2+deb10u3 ii python 2.7.16-1 Versions of packages etckeeper recommends: ii cron [cron-daemon] 3.0pl1-134+deb10u1 Versions of packages etckeeper suggests: ii sudo 1.8.27-1+deb10u3 -- debconf information: etckeeper/purge: true
Bug#986025: installation-reports: weird characters in network-console
Package: installation-reports Severity: normal X-Debbugs-Cc: t...@mirbsd.de Boot method: CD Image version: https://d-i.debian.org/daily-images/ppc64el/daily/netboot/mini.iso Mar 26 18:04 Date: 2021-03-26 to 2021-03-28 (yes it took three days, the machine was busy) Machine: qemu-system-ppc64le Partitions: root@ppc64el:~# df -Tl Filesystem Type 1K-blocksUsed Available Use% Mounted on udev devtmpfs 2033152 0 2033152 0% /dev tmpfs tmpfs 4163205312411008 2% /run /dev/vda2 ext4 48232140 1726160 44023448 4% / tmpfs tmpfs 2081472 0 2081472 0% /dev/shm tmpfs tmpfs 5120 0 5120 0% /run/lock tmpfs tmpfs 2081472 0 2081472 0% /var/cache/pbuilder/build/cow.1965/dev/shm root@ppc64el:~# fdisk -l Disk /dev/vda: 48 GiB, 51539607552 bytes, 100663296 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: D3EC9994-AFF1-4A12-BC03-3D2424D74D64 DeviceStart End Sectors Size Type /dev/vda1 2048 16383143367M PowerPC PReP boot /dev/vda2 16384 98662399 98646016 47G Linux filesystem /dev/vda3 98662400 100661247 1998848 976M Linux swap Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect media: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[O] Overall install:[E] Comments/Problems: Things worked well, except I switched to network-console and had weird characters instead of line drawing, although both outside and inside were GNU screen in UTF-8 mode. I ended up with a UsrMerge system :( Please make sure that any installation logs that you think would be useful are attached to this report. Please compress large files using gzip. -- Package-specific info: == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION="Debian GNU/Linux installer" DISTRIB_RELEASE="11 (bullseye) - installer build 20210326-04:02:59" X_INSTALLATION_MEDIUM=netboot == Installer hardware-summary: == uname -a: Linux ppc64el 5.10.0-5-powerpc64le #1 SMP Debian 5.10.24-1 (2021-03-19) ppc64le GNU/Linux lspci -knn: 00:01.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0001] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:02.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio SCSI [1af4:1004] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0008] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:03.0 USB controller [0c03]: Red Hat, Inc. QEMU XHCI Host Controller [1b36:000d] (rev 01) lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:1100] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: Kernel modules: xhci_pci lspci -knn: 00:04.0 Communication controller [0780]: Red Hat, Inc. Virtio console [1af4:1003] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0003] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:05.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio block device [1af4:1001] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0002] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:06.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon [1af4:1002] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0005] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:07.0 Unclassified device [00ff]: Red Hat, Inc. Virtio RNG [1af4:1005] lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:0004] lspci -knn: Kernel driver in use: virtio-pci lspci -knn: Kernel modules: virtio_pci lspci -knn: 00:08.0 VGA compatible controller [0300]: Device [1234:] (rev 02) lspci -knn: Subsystem: Red Hat, Inc. Device [1af4:1100] lspci -knn: 00:09.0 SATA controller [0106]: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] (rev 02) lspci -knn: Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100] lspci -knn: Kernel driver in use: ahci lspci -knn: Kernel modules: ahci usb-list: usb-list: Bus 01 Device 01: xHCI Host Controller [1d6b:0002] usb-list:Level 00
Bug#986022: qemu-user-static: Alpha targets fail to run Java properly (Too small maximum heap)
Package: qemu-user-static Version: 1:5.2+dfsg-9 Severity: normal Similar to #985923 Java™ is not emulated properly by qemu-user-static for Alpha targets but this works in qemu-system-alpha. (pbuild4932-dpo/alpha)root@evolvis-wirt:/# /usr/lib/jvm/java-11-openjdk-alpha/bin/java -version Error occurred during initialization of VM Too small maximum heap Same for openjdk-8-jre-headless. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.2.0-2 Versions of packages qemu-user-static suggests: ii sudo 1.8.27-1+deb10u3 -- no debconf information
Bug#986009: installation-reports: document qemu workarounds and bug in newer d-i image
Package: installation-reports
Severity: normal
Tags: d-i
X-Debbugs-Cc: t...@mirbsd.de
Boot method: CD
Image version:
https://cdimage.debian.org/cdimage/ports/snapshots/2020-10-12/debian-10.0.0-alpha-NETINST-1.iso
Date: 2021-03-26 to 2021-03-27
Machine: qemu-system-alpha on a buster host
Partitions:
root@alpha:~# fdisk -l
|
Disk /dev/sda: 40 GiB, 42949672960 bytes, 83886080 sectors
|
Disk model: QEMU HARDDISK
|
Geometry: 255 heads, 2 sectors/track, 164482 cylinders
|
Units: sectors of 1 * 512 = 512 bytes
|
Sector size (logical/physical): 512 bytes / 512 bytes
|
I/O size (minimum/optimal): 512 bytes / 512 bytes
|
Disklabel type: bsd
|
|
SliceStart End Sectors Size Type Fsize Bsize Cpg
|
a1 1954 1954 977K ext2 0 0 0
|
b 1955 353517 351563 171.7M ext2 0 0 0
|
c 353518 81884768 81531251 38.9G ext2 0 0 0
|
d 81884769 83886078 2001310 977.2M swap 0 0 0
|
root@alpha:~# df -Tl
|
Filesystem Type 1K-blocksUsed Available Use% Mounted on
|
udev devtmpfs 2052568 0 2052568 0% /dev
tmpfs tmpfs 413304 472412832 1% /run
/dev/sda3 ext4 39860300 1123656 36682092 3% /
tmpfs tmpfs 2066512 0 2066512 0% /dev/shm
tmpfs tmpfs 5120 0 5120 0% /run/lock
/dev/sda2 ext2170219 68778 92653 43% /boot
tmpfs tmpfs 413296 0413296 0% /run/user/0
Base System Installation Checklist:
[O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it
Initial boot: [O]
Detect network card:[O]
Configure network: [O]
Detect media: [O]
Load installer modules: [O]
Clock/timezone setup: [O]
User/password setup:[O]
Detect hard drives: [O]
Partition hard drives: [O]
Install base system:[E]
Install tasks: [O]
Install boot loader:[?]
Overall install:[↓]
Comments/Problems:
-
https://cdimage.debian.org/cdimage/ports/debian-installer/2021-01-03/alpha/debian-installer-images_20201202+nmu1_alpha.tar.gz
is insufficient, it lacks the ISO which contains nic-modules
- Tried
https://cdimage.debian.org/cdimage/ports/snapshots/2021-02-01/debian-10.0.0-alpha-NETINST-1.iso
first but it contains errors, e.g. no /var/lib/dpkg/status,
thus used a random older image; turned out to work
- Ran into #985954 so used raw qemu instead of libvirt/virt-manager
- qemu-system-alpha’s SRM firmware ("BIOS") seems to be unable to do
more than set up the bus and echo back REPL commands instead of executing
them, so only direct kernel boot is usable, so I copied out the kernel and
initrd from the ISO and ran:
qemu-system-alpha -cpu ev68-alpha-cpu -m 2048 -drive
format=raw,file=/dev/vg-evolvis-wirt/alpha -drive
format=raw,file=debian-10.0.0-alpha-NETINST-1.iso -nographic -net nic -net user
-kernel vmlinux-alpha -initrd initrd-alpha.gz -append console=ttyS0
Installation using the serial console, including screen, worked fine.
- After install, booting from the HDD failed (see above), so I used
partprobe (kpartx, normally the tool of choice, failed to recognise
the BSD disklabel used by SRM and thus Linux/Alpha) to map the boot
partition onto the host and copied kernel and initrd out and boot with:
qemu-system-alpha -cpu ev68-alpha-cpu -m 4096 -drive
format=raw,file=/dev/vg-evolvis-wirt/alpha -nographic -net nic -net user
-kernel ~/vmlinux-5.10.0-5-alpha-generic -initrd
~/initrd.img-5.10.0-5-alpha-generic -append 'console=ttyS0
root=UUID=6381e09c-4567-4fff-bbe4-608973308f65'
- After install, getting tons of unaligned messages from dbus:
[ 320.117023] dbus-daemon(366): unaligned trap at 02080bf0:
f6857c0e 28 18
⚠ Unfortunately there was no way to disable usrmerge in d-i,
so I’m now left with a system I cannot build on and have
to resort to debootstrapping me a chroot
Please make sure that any installation logs that you think would
be useful are attached to this report. Please compress large
files using gzip.
-- Package-specific info:
==
Installer lsb-release:
==
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20200315"
X_INSTALLATION_MEDIUM=cdrom
===
Bug#985954: libvirt: [alpha guest] IDE controllers are unsupported for this QEMU binary or machine type
Package: libvirt0
Version: 7.0.0-3
Severity: normal
X-Debbugs-Cc: t...@mirbsd.de
libvirt pretends Alpha guests don’t use IDE:
Unable to complete install: 'unsupported configuration: IDE controllers are
unsupported for this QEMU binary or machine type'
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/asyncjob.py", line 65, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File "/usr/share/virt-manager/virtManager/createvm.py", line 2001, in
_do_async_install
installer.start_install(guest, meter=meter)
File "/usr/share/virt-manager/virtinst/install/installer.py", line 701, in
start_install
domain = self._create_guest(
File "/usr/share/virt-manager/virtinst/install/installer.py", line 649, in
_create_guest
domain = self.conn.createXML(install_xml or final_xml, 0)
File "/usr/lib/python3/dist-packages/libvirt.py", line 4366, in createXML
raise libvirtError('virDomainCreateXML() failed')
libvirt.libvirtError: unsupported configuration: IDE controllers are
unsupported for this QEMU binary or machine type
Looking at the Qemu model, however, IDE is the default (and working
when using the command line), whereas SCSI causes trouble (sym0:
unexpected disconnect).
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500,
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages libvirt0 depends on:
ii libacl1 2.2.53-10
ii libapparmor1 2.13.6-9
ii libaudit11:3.0-2
ii libc62.31-10
ii libcap-ng0 0.7.9-2.2+b1
ii libcurl3-gnutls 7.74.0-1.1
ii libgcc-s110.2.1-6
ii libglib2.0-0 2.66.8-1
ii libgnutls30 3.7.1-1
ii libnl-3-200 3.4.0-1+b1
ii libnuma1 2.0.12-1+b1
ii libsasl2-2 2.1.27+dfsg-2.1
ii libselinux1 3.1-3
ii libssh2-11.9.0-2
ii libxml2 2.9.10+dfsg-6.3+b1
ii libyajl2 2.1.0-3
Versions of packages libvirt0 recommends:
pn lvm2
libvirt0 suggests no packages.
-- no debconf information
Bug#985923: qemu-user-static: Unknown privilege violation (03) on 64-bit PowerPC targets when running java
Package: qemu-user-static Version: 1:5.2+dfsg-9 Severity: normal I’m getting… Unknown privilege violation (03) NIP 00400b4192c8 LR 004002967638 CTR 00400b419298 XER CPU#1 MSR 900102806901 HID0 HF 92806000 iidx 6 didx 6 TB 00010620 45613134064220 GPR00 0008 00400330dc80 cafe 00400330ee78 GPR04 1ff8 0010 000a GPR08 0030 00400b419298 0001 c0de GPR12 003f 0040033188d0 004001bbf9e8 GPR16 00400b4192d8 004002d2bcf0 00400b419298 00400330ee78 GPR20 00400b4192f8 004002d04178 03d8 004004009670 GPR24 004004009a48 00400330dcf0 004004009660 00400b419280 GPR28 004004009620 0080 004002cd8430 00400330dc80 CR 240044f8 [ E G - - G G LO L ] RES … trying to run OpenJDK 8 on either ppc64 or… Unknown privilege violation (03) NIP 00400b1b42b0 LR 0040027ddfb8 CTR 00400b1b4280 XER CPU#1 MSR 900102806901 HID0 HF 92806001 iidx 6 didx 6 TB 00010215 43873222717974 GPR00 ffbffcf55fa0 0040030a9e70 004002a8ae00 0040030ab060 GPR04 2000 0010 0001 GPR08 0030 0001 004002adae00 GPR12 00400b1b4280 0040030b48d0 004001b9f468 GPR16 004001872000 004001b9f478 0040030ab060 GPR20 00400b1b42c0 00400b1b42c8 03d8 0040040092b0 GPR24 004004009688 004002ab4430 0040030a9ed0 0040040092a0 GPR28 004004009260 00400b1b4280 004002adc140 0040030a9e70 CR 24884400 [ E G L L G G - - ] RES … ppc64el (release architecture); OpenJDK 11 is worse (it crashes after this info; 8 only dumps then continues), and, given that the buildd logs don’t contain this, it is almost certainly a qemu-user issue. https://github.com/multiarch/qemu-user-static/issues/128 is another user reporting this issue. I retried exporting QEMU_CPU=POWER8 having learnt about its existence while searching about this bug, it does not fix it though. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-0.bpo.3-amd64 (SMP w/8 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) qemu-user-static depends on no packages. Versions of packages qemu-user-static recommends: ii binfmt-support 2.2.0-2 Versions of packages qemu-user-static suggests: ii sudo 1.8.27-1+deb10u3 -- no debconf information
Bug#985920: ca-certificates-java: -Xmx64m may not be sufficient any more
Package: ca-certificates-java Version: 20190909 Granted this is on a debian-ports architecture and with an old JDK but I just hit this error: Setting up openjdk-8-jdk:alpha (8u222-b10-1) ... update-alternatives: using /usr/lib/jvm/java-8-openjdk-alpha/bin/appletviewer to provide /usr/bin/appletviewer (appletviewer) in auto mode update-alternatives: using /usr/lib/jvm/java-8-openjdk-alpha/bin/jconsole to provide /usr/bin/jconsole (jconsole) in auto mode Processing triggers for libc-bin (2.31-10) ... Processing triggers for ca-certificates (20210119) ... Updating certificates in /etc/ssl/certs... 0 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d... Error occurred during initialization of VM Too small initial heap E: /etc/ca-certificates/update.d/jks-keystore exited with code 1. done. Errors were encountered while processing: ca-certificates-java E: Sub-process /usr/bin/dpkg returned an error code (1) E: Failed to process build dependencies Might be more future-proof to raise the heap maximum size (Xmx). If concerned about memory use, you can still specify a smaller minimum heap size…
Bug#985915: ldd: disagrees with file(1) about whether a file is dynamically or statically linked
Package: libc-bin Version: 2.31-10 Severity: normal X-Debbugs-Cc: t...@mirbsd.de I’m debugging a weird lintian problem and found the cause to be: tglase@tglase-nb:~ $ ldd /tmp/libjsound.so statically linked tglase@tglase-nb:~ $ file /tmp/libjsound.so /tmp/libjsound.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=de56e345230aca1c7c8cf06b56e9c21ee53031f5, stripped tglase@tglase-nb:~ $ objdump -p /tmp/libjsound.so | fgrep NEED | wc -l 0 I’m attaching this file so this can be fixed in the right package. I believe that if both agree lintian won’t complain. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libc-bin depends on: ii libc6 2.31-10 Versions of packages libc-bin recommends: ii manpages 5.10-1 libc-bin suggests no packages. -- no debconf information libjsound.so Description: application/sharedlib
Bug#985634: git (1:2.31.0-1): no longer runs addons from /usr/lib/git-core breaking lots of 3rdpty stuff
Dixi quod… >I imagine *many* other third-party addons do the same. Please >make git search the old location after the new one (preferred) Uhm, ping?
Bug#985634: git (1:2.31.0-1): no longer runs addons from /usr/lib/git-core breaking lots of 3rdpty stuff
Package: git Version: 1:2.31.0-1 Severity: important X-Debbugs-Cc: t...@mirbsd.de git (1:2.31.0-1) unstable; urgency=low * install dashed commands to /usr/libexec instead of /usr/lib (thx Chris Lamb for suggesting it through lintian). While this is laudable, some commands now fail: tglase@tglase-nb:~ $ git find git: 'find' is not a git command. See 'git --help'. The most similar command is init 1|tglase@tglase-nb:~ $ dpkg -L git-find | sort /. /usr /usr/lib /usr/lib/git-core /usr/lib/git-core/git-find /usr/share /usr/share/doc /usr/share/doc/git-find /usr/share/doc/git-find/changelog.gz /usr/share/doc/git-find/copyright /usr/share/man /usr/share/man/man1 /usr/share/man/man1/git-find.1.gz I imagine *many* other third-party addons do the same. Please make git search the old location after the new one (preferred) or revert this change at least until past the bullseye release (not preferred, as libexec is actually correct). -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages git depends on: ii git-man 1:2.31.0-1 ii libc62.31-9 ii libcurl3-gnutls 7.74.0-1.1 ii liberror-perl0.17029-1 ii libexpat12.2.10-2 ii libpcre2-8-0 10.36-2 ii perl 5.32.1-3 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages git recommends: ii ca-bundle [ca-certificates] 20190604 ii less 551-2 ii openssh-client [ssh-client] 1:8.4p1-5 ii patch2.7.6-7 Versions of packages git suggests: ii gettext-base 0.21-4 ii git-cvs 1:2.31.0-1 pn git-daemon-run | git-daemon-sysvinit ii git-doc 1:2.31.0-1 pn git-el pn git-email pn git-gui ii git-mediawiki 1:2.31.0-1 ii git-svn 1:2.31.0-1 ii gitk 1:2.31.0-1 pn gitweb -- no debconf information
Bug#982669: buster-pu: package portaudio19/19.6.0-1
Adam D. Barratt dixit: >Please go ahead. Thanks, I’ve done so. bye, //mirabilos
Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch
Utkarsh Gupta dixit: >Thanks to Thomas for his help, I've uploaded a fix for this regression >(by reverting the backport of that part of the patch which was not >necessary It’s got some memory impact, but probably neglegible here, true. > for this CVE fix). And thanks to Thorsten for his >comprehensive bug report and to Sven for further debugging and taking >a look. You’re welcome. >Thorsten, could you please test the latest upload and see if >everything works alright for you? I don’t actally have a testcase, I’ve just noticed that this is wrong when trying to backport the patch further myself. But it won’t hit the bug now. bye, //mirabilos -- „Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund, mksh auf jedem System zu installieren.“ -- XTaran auf der OpenRheinRuhr, ganz begeistert (EN: “[…]uhr.gz is a reason to install mksh on every system.”)
Bug#985229: unblock: musescore2/2.3.2+dfsg4-14, musescore3/3.2.3+dfsg2-10, musescore-general-soundfont/0.2-3, timgm6mb-soundfont/1.3-5
Dixi quod… >[ Other info ] >I have another set of uploads for musescore2 and musescore3 fixing >crash bugs coming up (not uploading them today, I want upstream to >have a go at reviewing the change first). How should this be handled? >Should I first wait until the current set of packages is unblocked >and has migrated to testing? Otherwise, if I upload now musescore2 >would get AUTORM’d which is suboptimal. Waiting so long will however >delay availability of the fix even to sid users. On second thought, this fix (involving crashes caused by soundfonts) needs to go some rounds through affected parties (MuseScore upstream, soundfont author, even input from FluidSynth upstream) so I’d prefer for all four to be unblocked as-is with the #984592 fix only and will handle the other fix once it’s there and tested. Thanks, //mirabilos -- "Using Lynx is like wearing a really good pair of shades: cuts out the glare and harmful UV (ultra-vanity), and you feel so-o-o COOL." -- Henry Nelson, March 1999
Bug#962596: Divergence in Symantec CA blacklist reverting between sid and *stable?
Hi Julien, >Yes, they're different. I'm not sure what you're asking. the reason for the difference; sorry if I was unclear. Thanks, //mirabilos -- 18:47⎜ well channels… you see, I see everything in the same window anyway 18:48⎜ i know, you have some kind of telnet with automatic pong 18:48⎜ haha, yes :D 18:49⎜ though that's more tinyirc – sirc is more comfy
Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV
Hi Fabian, >Am Sonntag, dem 14.03.2021 um 20:05 + schrieb Thorsten Glaser: >> @Fabian since you were the driving force behind SF3 integration >> into FluidSynth itself, you might wish to have a look at the >> patch as well. > >forwarded to Fluidsynth upstream, thanks! OK, thanks! > (I am not active in this project anymore). Oh, sad. Thanks for still responding. bye, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#985229: unblock: musescore2/2.3.2+dfsg4-14, musescore3/3.2.3+dfsg2-10, musescore-general-soundfont/0.2-3, timgm6mb-soundfont/1.3-5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: t...@mirbsd.de
Please unblock package musescore2, musescore3,
musescore-general-soundfont and timgm6mb-soundfont
(all packages related to #984592)
[ Reason ]
In rare conditions, “rmdir --ignore-fail-on-non-empty” as used in
the prerm of some packages can fail because dpkg already removed
one of the directories in question; this was found as #984592 by
piuparts. To ensure uninstalling without errors, we mkdir -p the
directories first (other errors will still cause aborting).
[ Impact ]
#984592 is considered an RC bug, so it would lead to removing a
package from the release, which is very suboptimal. In very rare
cases, not fixing this may cause package uninstallation to fail.
[ Tests ]
None; the code is trivial.
[ Risks ]
No risk, this is trivial.
[ Checklist ]
[x] all changes are documented in the d/changelog
[x] I reviewed all changes and I approve them
[x] attach debdiff against the package in testing
[ Other info ]
I have another set of uploads for musescore2 and musescore3 fixing
crash bugs coming up (not uploading them today, I want upstream to
have a go at reviewing the change first). How should this be handled?
Should I first wait until the current set of packages is unblocked
and has migrated to testing? Otherwise, if I upload now musescore2
would get AUTORM’d which is suboptimal. Waiting so long will however
delay availability of the fix even to sid users.
unblock musescore2/2.3.2+dfsg4-14
unblock musescore3/3.2.3+dfsg2-10
unblock musescore-general-soundfont/0.2-3
unblock timgm6mb-soundfont/1.3-5
diff -Nru musescore-general-soundfont-0.2/debian/changelog
musescore-general-soundfont-0.2/debian/changelog
--- musescore-general-soundfont-0.2/debian/changelog2020-07-12
17:02:25.0 +0200
+++ musescore-general-soundfont-0.2/debian/changelog2021-03-12
20:58:58.0 +0100
@@ -1,3 +1,12 @@
+musescore-general-soundfont (0.2-3) unstable; urgency=medium
+
+ * Bump Policy (no relevant changes)
+ * Avoid rare error in prerm (Closes: #984592)
+ * Update from maintainer script template
+ * Do latest lintian tag rename churn
+
+ -- Thorsten Glaser Fri, 12 Mar 2021 20:58:58 +0100
+
musescore-general-soundfont (0.2-2) unstable; urgency=high
* Merge musescore-general-soundfont-small (0.2-2) changes
diff -Nru musescore-general-soundfont-0.2/debian/control
musescore-general-soundfont-0.2/debian/control
--- musescore-general-soundfont-0.2/debian/control 2020-05-28
23:19:04.0 +0200
+++ musescore-general-soundfont-0.2/debian/control 2021-03-12
20:34:13.0 +0100
@@ -5,7 +5,7 @@
Homepage: https://musescore.org/en/node/269869
Build-Depends: debhelper-compat (= 13),
python3-minimal, sf3convert
-Standards-Version: 4.5.0
+Standards-Version: 4.5.1
Rules-Requires-Root: no
VCS-git: https://evolvis.org/anonscm/git/alioth/soundfonts.git -b
musescore-general-soundfont
VCS-Browser:
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/soundfonts.git;a=shortlog;h=refs/heads/musescore-general-soundfont
diff -Nru
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
---
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
2020-05-28 23:00:17.0 +0200
+++
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.postinst
2021-03-12 20:45:47.0 +0100
@@ -21,9 +21,12 @@
#
# * postinst "triggered" "${triggers[*]}"
# For trigger-only calls, i.e. if "configure" is not called.
+#
+# * new-postinst "reconfigure" [$most_recently_configured_version](?)
+# Treat this as just like "configure" for a future extension by debconf.
case $1 in
-configure)
+(configure|reconfigure)
# need the directories existing before update-alternatives
mkdir -p /usr/share/sounds/sf2 /usr/share/sounds/sf3
# see #929185 for the history behind this
@@ -39,13 +42,13 @@
/usr/share/sounds/sf2/MuseScore_General_Full.sf2 55
;;
-abort-upgrade|abort-remove|abort-deconfigure)
+(abort-upgrade|abort-remove|abort-deconfigure)
;;
-triggered)
+(triggered)
;;
-*)
+(*)
echo >&2 "E: postinst called with unknown subcommand '$1'"
exit 1
;;
diff -Nru
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
---
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
2020-05-28 23:00:17.0 +0200
+++
musescore-general-soundfont-0.2/debian/musescore-general-soundfont-lossless.prerm
2021-03-12 20:46:28.0 +0100
@@ -19,7 +19,7 @@
# other constrain
Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV
forwarded 985129 https://github.com/musescore/MuseScore/pull/7728
tags 985129 - moreinfo
tags 985129 + confirmed upstream pending
affects 985129 musescore
outlook 985129 a patch has been found and musescore{2,3} will be uploaded soon
thanks
@Fabian since you were the driving force behind SF3 integration
into FluidSynth itself, you might wish to have a look at the
patch as well.
Paul Menzel dixit:
> (gdb) print *s
> $2 = {_valid = true, sf = 0x563075eb55a0, start = 0, end = 0,
> loopstart = 29362, loopend = 38401, samplerate = 44100,
> origpitch = 63, pitchadj = -8, sampletype = 17, data = 0x0,
Good news: With sf3convert, I was able to identify this sample:
25705425
25743841
29362
38401
44100
63
-8
1
(Ignore that sampletype is 1 here.)
Bad news: the sample and the soundfont is fine, so this probably
was a temporary hiccup, I/O or decompression-related… or maybe
even caused by threads interjecting… the last commit related to
mutex locking around soundfont loading is present, though… no idea.
More good news: I have a patch, also forwarded upstream, which I
believe fixes this bug, but also others. I’m not uploading this any
more tonight but later but if you want to test it already I provide
it at: https://people.debian.org/~tg/musescore3_3.2.3+dfsg2-11_amd64.deb
bye,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV
@Igor, Jojo: this relates to commit 5aea0ab5b50b9037ba8ed9dd100dcf06396a4c9d
and the follow-up commit 48163e958f02b82e59d910176c5d806d0c9ef7b6 and to
https://musescore.org/en/node/89216 (see my comments there), I will of course
provide a PR if I manage to fix this correctly.
Dixi quod…
>> (gdb) print *s
>> $2 = {_valid = true, sf = 0x563075eb55a0, start = 0, end = 0,
>> loopstart = 29362, loopend = 38401, samplerate = 44100,
>> origpitch = 63, pitchadj = -8, sampletype = 17, data = 0x0,
>
>Hah! There we are, loopstart and loopend are larger than 0,
>start and end are 0 and data is even nil…
You don’t happe to have a copy of the terminal output (perhaps in
~/.xsession-errors or so) from the crashing run?
I’d expect there to be either “Sample::decompressOggVorbis: open failed”
or (more likely) “Sample read failed”.
>I shall be compiling a debug build now which will output information
>in the code area in question when the data is bad, like that, or not
>matching the SoundFont spec (if this works, I’ll even try to push it
>upstream), then we’ll see whether this is bad soundfont data.
This took MUCH longer than I thought, as the soundfont code is split
in SF3 and not-SF3 and that is not harmonic and apparently buggy:
https://musescore.org/en/node/89216
In addition, the changes…
>>> + IF_ASSERT_FAILED(s->loopstart >= s->start) {
>>> +s->loopstart = s->start;
>>> +}
>>> +
>>> + if (s->loopend > s->end) {
>>> +s->loopend = s->end;
>>> +}
… were intended to fix this but not enough and too late.
Right now I *think* I have a fix for all related issues including
audible artefacts with certain SF3 samples (clicking, or even other
notes sounding after one note finished playing).
>I’ll update this bug later, when knowing more.
Building is going to take a while… in the meantime, sf3convert(1)
from the sf3convert Debian package can convert a soundfont to XML
showing the data (such as {,loop}{start,end}) involved. I’ll try
having a look at that as well.
Again thank you for the bugreport, this (probably) proves to be useful!
I’ll also fix this in musescore2 of course.
bye,
//mirabilos
--
exceptions: a truly awful implementation of quite a nice idea.
just about the worst way you could do something like that, afaic.
it's like anti-design. that too… may I quote you on that?
sure, tho i doubt anyone will listen ;)
Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV
Hi Paul,
>> slowness), but, while Valgrind is very unhappy with both the X libraries
>> and MuseScore, showing *many*
>> Conditional jump or move depends on uninitialised value(s)
> Are there any suppression files, one could use?
I’ve got no idea, I barely know Valgrind.
>> 1816 for (i = (int)s->loopstart; i < (int) s->loopend; i ++) {
>> 1817 signed short val = s->data[i];
> (gdb) print *s
> $2 = {_valid = true, sf = 0x563075eb55a0, start = 0, end = 0,
> loopstart = 29362, loopend = 38401, samplerate = 44100,
> origpitch = 63, pitchadj = -8, sampletype = 17, data = 0x0,
Hah! There we are, loopstart and loopend are larger than 0,
start and end are 0 and data is even nil…
>>> I am unable to reproduce the issue, so I am unsure, if it’s related
>>> to upgrade at all.
>>
>> Given this, it could be some, basically, fluke: perhaps the soundfont
I shall be compiling a debug build now which will output information
in the code area in question when the data is bad, like that, or not
matching the SoundFont spec (if this works, I’ll even try to push it
upstream), then we’ll see whether this is bad soundfont data.
I’ll update this bug later, when knowing more.
> The APT/dpkg process was already finished before I started MuseScore.
OK.
>> + IF_ASSERT_FAILED(s->loopstart >= s->start) {
>> +s->loopstart = s->start;
>> +}
>> +
>> + if (s->loopend > s->end) {
>> +s->loopend = s->end;
>> +}
>>
>> The print command above would show whether this would have made
>> a difference.
>
> I am curious, what the result is going to be.
The IF_ASSERT_FAILED macro is… slightly fscking me up, but these two
checks, plus some others, are basically what I’ll do. The git log for
these indicates that “some drumkit soundfont” made MuseScore crash,
which is why the second check is not IF_ASSERT_FAILED (which, seemingly,
only works in debug builds).
Thanks,
//mirabilos
--
Stéphane, I actually don’t block Googlemail, they’re just too utterly
stupid to successfully deliver to me (or anyone else using Greylisting
and not whitelisting their ranges). Same for a few other providers such
as Hotmail. Some spammers (Yahoo) I do block.
Bug#600246: this might be the Y-Tütü bug I also noticed
Hi,
I have a patch also concerned with ÿ characters being output.
Is this the same issue? If so, someone (upstream) should check
which is more correct; mine doesn’t “simply move an assignment”.
Thanks,
//mirabilos who definitely should forward his other screen bugfixes…
--
18:47⎜ well channels… you see, I see everything in the
same window anyway 18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy# DP: cf. MirBSD commitid 1005EED581D59D2B04A
# DP: fixes Y-Tütü bug with doublewidth+combining character sequence
--- a/display.c
+++ b/display.c
@@ -603,7 +603,7 @@ int c;
D_x += D_AM ? 1 : -1;
D_mbcs = 0;
}
- else if (utf8_isdouble(c))
+ else if (utf8_isdouble_maybecomb(c))
{
D_mbcs = c;
D_x++;
--- a/encoding.c
+++ b/encoding.c
@@ -665,6 +665,14 @@ struct combchar {
};
struct combchar **combchars;
+int
+utf8_isdouble_maybecomb(int c)
+{
+ while (c >= 0xd800 && c < 0xe000 && combchars && combchars[c - 0xd800])
+c = combchars[c - 0xd800]->c1;
+ return utf8_isdouble(c);
+}
+
void
AddUtf8(c)
int c;
--- a/extern.h
+++ b/extern.h
@@ -487,6 +487,7 @@ extern int FromUtf8 __P((int, int *));
extern void AddUtf8 __P((int));
extern int ToUtf8 __P((char *, int));
extern int ToUtf8_comb __P((char *, int));
+extern int utf8_isdouble_maybecomb __P((int));
extern int utf8_isdouble __P((int));
extern int utf8_iscomb __P((int));
extern void utf8_handle_comb __P((int, struct mchar *));
Bug#962596: Divergence in Symantec CA blacklist reverting between sid and *stable?
Hi, the changelogs seem to differ in re-added certificates: ca-certificates (20210119) unstable; urgency=medium [ Michael Shuler ] * mozilla/blacklist: Revert Symantec CA blacklist (#911289). Closes: #962596 The following root certificates were added back (+): + "GeoTrust Primary Certification Authority - G2" + "VeriSign Universal Root Certification Authority" ca-certificates (20200601~deb10u2) buster; urgency=medium [ Michael Shuler ] * mozilla/blacklist: Revert Symantec CA blacklist (#911289). Closes: #962596, #968002. The following root certificates were added back (+): + "GeoTrust Global CA" + "GeoTrust Primary Certification Authority" + "GeoTrust Primary Certification Authority - G2" + "GeoTrust Primary Certification Authority - G3" + "GeoTrust Universal CA" + "thawte Primary Root CA" + "thawte Primary Root CA - G2" + "thawte Primary Root CA - G3" + "VeriSign Class 3 Public Primary Certification Authority - G4" + "VeriSign Class 3 Public Primary Certification Authority - G5" + "VeriSign Universal Root Certification Authority" ca-certificates (20200601~deb9u2) stretch-security; urgency=high * mozilla/blacklist: Revert Symantec CA blacklist (#911289). Closes: #962596 The following root certificates were added back (+): + "GeoTrust Global CA" + "GeoTrust Primary Certification Authority" + "GeoTrust Primary Certification Authority - G2" + "GeoTrust Primary Certification Authority - G3" + "GeoTrust Universal CA" + "thawte Primary Root CA" + "thawte Primary Root CA - G2" + "thawte Primary Root CA - G3" + "VeriSign Class 3 Public Primary Certification Authority - G4" + "VeriSign Class 3 Public Primary Certification Authority - G5" + "VeriSign Universal Root Certification Authority" So, which is correct? Thanks in advance, //mirabilos -- you introduced a merge commit│ % g rebase -i HEAD^^ sorry, no idea and rebasing just fscked │ Segmentation should have cloned into a clean repo │ fault (core dumped) if I rebase that now, it's really ugh │ wuahh
Bug#985129: musescore3: /usr/bin/mscore3 terminated with SIGSEGV
tags 985129 + unreproducible moreinfo
thanks
(Don’t let this scare you, let’s see whether we can get to the bottom…)
Hi Paul,
> Today *musescore-general-soundfont* was upgraded, and opening a file in
> MuseScore 3, and changing the sound font of a voice/part to *Oboe* MuseScore 3
> crashed with a segmentation fault.
this is unfortunate. Sadly, it’s not quite unexpected; MuseScore is not
fuzzing-resistant and often crashes when loading corrupt scores, for ex‐
ample, and upstream does not seem interested in fixing this systematically,
although this particular crash is.
I’ve tried to reproduce it, running under Valgrind even (an exercise in
slowness), but, while Valgrind is very unhappy with both the X libraries
and MuseScore, showing *many*
Conditional jump or move depends on uninitialised value(s)
messages, only one of them lies in Fluid, and nowhere even near the area
you experienced. (Your full backtrace is extremely helpful.)
Looking at the backtrace…
#0 FluidS::Sample::optimize() (this=this@entry=0x56307713c970) at
./fluid/voice.cpp:1817
val =
s = 0x56307713c970
peak_max = 0
peak_min = 0
peak =
i = 29362
… and the code…
1816 for (i = (int)s->loopstart; i < (int) s->loopend; i ++) {
1817 signed short val = s->data[i];
… this looks like an out-of-bounds access of s->data (perhaps it’s not
29363 elements long). If you have the debug session still (e.g. from a
core dump), can you please run:
(gdb) print *s
This would give us information with which we can look at it in more
depth. There’s a (very small) chance the soundfont has broken values.
> I am unable to reproduce the issue, so I am
> unsure, if it’s related to upgrade at all.
Given this, it could be some, basically, fluke: perhaps the soundfont
was not yet fully loaded/decompressed while you were doing the change?
Umm… I am assuming, but better ask: did you upgrade the soundfont
while MuseScore was running, and, if so, did you not restart it
between upgrading and crashing? (That could explain a crash as well.)
I’ll also ask around upstream whether someone recalls something in
Fluid, but I doubt that will yield much response.
Looking at the diff, two things changed in that area: i was changed
from int to size_t (as is proper, but almost certainly not involved
here), and two checks were added (ugly indentation courtesy upstream):
+ IF_ASSERT_FAILED(s->loopstart >= s->start) {
+s->loopstart = s->start;
+}
+
+ if (s->loopend > s->end) {
+s->loopend = s->end;
+}
The print command above would show whether this would have made
a difference.
Thanks for reporting,
//mirabilos
--
15:41⎜ Somebody write a testsuite for helloworld :-)
Bug#929983: ipxe-qemu: virtio booting no longer works after upgrade to buster
retitle 929983 ipxe-qemu: virtio booting broken past jessie notfound 929983 1.0.0+git-20141004.86285d1-1 notfound 929983 1.0.0+git-20150424.a25a16d-1 found 929983 1.0.0+git-20161027.b991c67-1 found 929983 1.0.0+git-20190125.36a4c85-5.1 thanks On Fri, 26 Feb 2021, Thorsten Glaser wrote: > … doesn’t make this succeed either. Huh. That’s apparently because I erred. I tried to track this down today and could reproduce this bug in a stretch cowbuilder chroot into which I bind-mounted the /tmp/.X11-unix directory from outside. I recall that the virtualisation host was upgraded from wheezy to buster (ofc hitting jessie and stretch, with reboots, in between, but it was not used on jessie or stretch) and tried this in a jessie cowbuilder chroot and, voilà, succeeded. Then, to track down the exact package in which this broke: (pbuild1662-jessie/amd64)root@tglase:/# qemu-system-x86_64 -device virtio-net-pci,netdev=net0 -netdev user,id=net0 -machine pc-1.1 [ works ] (pbuild1662-jessie/amd64)root@tglase:/var/cache/apt/archives# dpkg -i ipxe-qemu_1.0.0+git-20161027.b991c67-1_all.deb (Reading database ... 12683 files and directories currently installed.) Preparing to unpack ipxe-qemu_1.0.0+git-20161027.b991c67-1_all.deb ... Unpacking ipxe-qemu (1.0.0+git-20161027.b991c67-1) over (1.0.0+git-20141004.86285d1-1) ... Setting up ipxe-qemu (1.0.0+git-20161027.b991c67-1) ... (pbuild1662-jessie/amd64)root@tglase:/var/cache/apt/archives# qemu-system-x86_64 -device virtio-net-pci,netdev=net0 -netdev user,id=net0 -machine pc-1.1 [ fails ] (pbuild1662-jessie/amd64)root@tglase:/var/cache/apt/archives# dpkg -i ipxe-qemu_1.0.0+git-20141004.86285d1-1_all.deb dpkg: warning: downgrading ipxe-qemu from 1.0.0+git-20161027.b991c67-1 to 1.0.0+git-20141004.86285d1-1 (Reading database ... 12683 files and directories currently installed.) Preparing to unpack .../ipxe-qemu_1.0.0+git-20141004.86285d1-1_all.deb ... Unpacking ipxe-qemu (1.0.0+git-20141004.86285d1-1) over (1.0.0+git-20161027.b991c67-1) ... Setting up ipxe-qemu (1.0.0+git-20141004.86285d1-1) ... (pbuild1662-jessie/amd64)root@tglase:/var/cache/apt/archives# qemu-system-x86_64 -device virtio-net-pci,netdev=net0 -netdev user,id=net0 -machine pc-1.1 [ works ] So we now know without fail that there’s a change in the ipxe-qemu binary package, introduced between jessie and stretch, that breaks netbooting on virtio NICs for at least some qemu machine models in use by libvirt guests. Using snapshot.d.o to track this further down… there’s only one upload 1.0.0+git-20150424.a25a16d-1 in between. Which works. Perhaps this helps bisecting the change that breaks it? Thanks in advance, //mirabilos -- [17:15:07] Lukas Degener: Kleines Asterix-Latinum für Softwaretechniker: veni, vidi, fixi(t) ;-)
Bug#985073: multimedia-musiciantools: should prefer the recent version of MuseScore
Dixi quod… >I noticed that multimedia-musiciantools Recommends: musescore > >It should instead > Recommends: musescore3 > Suggests: musescore >for bullseye. multimedia-guitar=0.10 (built from the same source package) Suggests musescore; it probably should Suggests musescore3 instead thus. bye, //mirabilos -- cool ein Ada Lovelace Google-Doodle. aber zum 197. Geburtstag? Hätten die nicht noch 3 Jahre warten können? bis dahin gibts google nicht mehr ja, könnte man meinen. wahrscheinlich ist der angekündigte welt- untergang aus dem maya-kalender die globale abschaltung von google ☺ und darum müssen die die doodles vorher noch raushauen
Bug#985073: multimedia-musiciantools: should prefer the recent version of MuseScore
Package: multimedia-musiciantools Version: 0.10 Severity: normal X-Debbugs-Cc: t...@mirbsd.de I noticed that multimedia-musiciantools Recommends: musescore It should instead Recommends: musescore3 Suggests: musescore for bullseye. Rationale: musescore3 is the recent version of MuseScore and the one users would normally install; musescore is version 2, basically frozen upstream and only bugfixed locally, which is required, even by upstream, when users want to edit scores created with the older version without doing a full relayout in v3 (whose layout engine differs so much that upgrading one older score can take multiple hours; eventually, the idea is that all scores would be upgraded to v4 once that’s out, but when a user does only a small change to a v2 score they must use the v2 binary). -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages multimedia-musiciantools depends on: pn multimedia-tasks Versions of packages multimedia-musiciantools recommends: pn ableton-link-utils pn ableton-link-utils-gui pn gtklick pn klick pn kmetronome pn laborejo pn lilypond pn lilypond-data ii musescore 2.3.2+dfsg4-14 pn rumor pn solfege Versions of packages multimedia-musiciantools suggests: pn audiveris pn bmc pn denemo pn fmit pn frescobaldi pn gtklick pn impro-visor pn kmetronome pn laborejo pn linuxband pn lute-tab pn ly2video pn lyricue pn mingus pn mma pn nted pn qrest pn rosegarden pn rumor pn stretchplayer
Bug#985003: shellcheck: –list-optional: openBinaryFile: does not exist (No such file or directory)
Package: shellcheck
Version: 0.7.1-1
Severity: important
X-Debbugs-Cc: t...@mirbsd.de
$ shellcheck –list-optional
–list-optional: –list-optional: openBinaryFile: does not exist (No such file or
directory)
This was copy/paste from the manual page:
–list-optional
Output a list of known optional checks. These can be enabled
with -o flags or enable directives.
Incidentally, the leading dash is U+2013, not a hyphen-minus.
Typing this myself doesn’t make it work though…
$ shellcheck -list-optional
unrecognized option `-l'
Usage: shellcheck [OPTIONS...] FILES...
-a --check-sourcedInclude warnings from sourced
files
-C[WHEN]--color[=WHEN] Use color (auto, always, never)
-i CODE1,CODE2..--include=CODE1,CODE2..Consider only given types of
warnings
-e CODE1,CODE2..--exclude=CODE1,CODE2..Exclude types of warnings
-f FORMAT --format=FORMATOutput format (checkstyle,
diff, gcc, json, json1, quiet, tty)
--list-optionalList checks disabled by default
--norc Don't look for .shellcheckrc
files
-o check1,check2.. --enable=check1,check2.. List of optional checks to
enable (or 'all')
-P SOURCEPATHS --source-path=SOURCEPATHS Specify path when looking for
sourced files ("SCRIPTDIR" for script's dir)
-s SHELLNAME--shell=SHELLNAME Specify dialect (sh, bash,
dash, ksh)
-S SEVERITY --severity=SEVERITYMinimum severity of errors to
consider (error, warning, info, style)
-V --version Print version information
-W NUM --wiki-link-count=NUM The number of wiki links to
show, when applicable
-x --external-sources Allow 'source' outside of FILES
--help Show this usage summary and
exit
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500,
'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1,
'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-4-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_WARN
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/lksh
Init: sysvinit (via /sbin/init)
Versions of packages shellcheck depends on:
ii libatomic1 10.2.1-6
ii libc6 2.31-9
ii libffi7 3.3-6
ii libgmp102:6.2.1+dfsg-1
shellcheck recommends no packages.
shellcheck suggests no packages.
-- no debconf information
Bug#984954: curl: -1 does not work
Package: curl Version: 7.64.0-4+deb10u1 Severity: important This is a buster-only (AFAICT) bug: stretch (7.52.1-5+deb9u13) doesn’t yet have the problem, and sid (7.74.0-1.1) works. In a default buster installation /etc/ssl/openssl.cnf ends with these fateful lines: [system_default_sect] MinProtocol = TLSv1.2 CipherString = DEFAULT@SECLEVEL=2 Trying to retrieve a document from a TLSv1.0-only server with cURL’s designated option to choose TLSv1.0 fails: (buster-i386)tglase@tglase:~ $ curl -1 https://www.mirbsd.org/~tg/Debs/REPOKEY curl: (35) error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol Setting MinProtocol = TLSv1 instead allows it to work, which is precisely what passing the -1 option on the command line was supposed to do for this one invocation, as opposed to a global setting change. This is a pretty severe bug, impacting communication severely. I only didn’t notice it earlier because I almost only use sid. This really should be fixed in buster. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=C (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages curl depends on: ii libc6 2.28-10 ii libcurl4 7.64.0-4+deb10u1 ii zlib1g1:1.2.11.dfsg-1 curl recommends no packages. curl suggests no packages. -- no debconf information
Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch
Sven Joachim dixit: >I see that this might be a problem (albeit unlikely to happen in >practice), however I have trouble understanding exactly where a >use-after-realloc bug comes into play. Maybe Thorsten can help me fix >my blindness? The next time something is selected, the code a little further up will check if the allocated size is sufficient, and, if so, use screen->selection_data which was the pre-realloc address of line. >> I am glad and surprised that sid is okay and there doesn't seem to be The code in sid completely differs (structures, variable names, etc). >suggestion you could also apply the patches to the SaltTextAway() >function from xterm 365e. If 365e is like 366 (currently in sid), you’ll have lots of fun due to the renamed everything. I’d rather Tom changed xterm upstream to address the realloc-failure difference. I know he reads Debian bugreports ;-) and he’s really busy so probably takes longer to respond. bye, //mirabilos -- >> Why don't you use JavaScript? I also don't like enabling JavaScript in > Because I use lynx as browser. +1 -- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel
Bug#984615: xterm: bug in CVE-2021-27135 patch in at least stretch
Source: xterm
Version: 327-2+deb9u1
Severity: serious
Justification: introduces use-after-realloc
debian/patches/CVE-2021-27135.patch changes button.c line (after
patching) 3747 to:
line = realloc(line, screen->selection_size);
But “line” is a local variable, the address of the buffer must
be stored in the one handed out, too, so please change this to:
if ((have * 2) < (size_t) j) {
Char *next = realloc(line, have + 1);
if (next) {
screen->selection_data = line = next;
screen->selection_size = have + 1;
}
}
This also deals properly with realloc failures (since we’re
shrinking, ignore them and just keep the older, larger area).
I’ve not looked at jessie-ELTS or buster-security whether they
are affected as well; sid is clean (and where I got the realloc
failure check necessity from, although sid’s free()s the buffer
if realloc fails; this isn’t needed @Tom).
bye,
//mirabilos
--
you introduced a merge commit│ % g rebase -i HEAD^^
sorry, no idea and rebasing just fscked │ Segmentation
should have cloned into a clean repo │ fault (core dumped)
if I rebase that now, it's really ugh │ wuahh
Bug#984592: musescore-common: fails to remove: rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory
Andreas Beckmann dixit: > Which is another point for *shipping* the directories to let dpkg do the > refcounting, otherwise the manually created directory gets removed by dpkg > removing a different package. Hmh, good point. > On 05/03/2021 16.17, Thorsten Glaser wrote: >>> Why don't you ship the three empty directories in the package? >> >> lintian considers that an error. > > which can be overridden if you intentionally want to ship empty > directories as in this case Hmm… | Tag: package-contains-empty-directory | Severity: info | Check: files/empty-directories | Explanation: This package installs an empty directory. This might be intentional | but it's normally a mistake. If it is intentional, add a Lintian override. | . | If a package ships with or installs empty directories, you can remove them | in debian/rules by calling: | . | $ find path/to/base/dir -type d -empty -delete So overriding this if the empty directory is deliberate is not only okay but actually considered normal and perhaps even perferrable? Maybe some wording could be added in lintian, so that’s clearer. The mere _existence_ of that tag (perhaps also in linda, back then) scared me away from ever shipping empty directories in Debian… I’ll reconsider that later, for now I’ve plugged the issue differently. Thanks, //mirabilos -- Solange man keine schmutzigen Tricks macht, und ich meine *wirklich* schmutzige Tricks, wie bei einer doppelt verketteten Liste beide Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz hervorragend. -- Andreas Bogk über boehm-gc in d.a.s.r
Bug#984592: musescore-common: fails to remove: rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory
Andreas Beckmann dixit: >during a test with piuparts I noticed your package fails to remove. According to https://piuparts.debian.org/sid-strict/source/m/musescore2.html the musescore-common package succeeds piuparts, too… huh… weird. Fixing it at the moment, //mirabilos
Bug#984592: musescore-common: fails to remove: rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory
Andreas Beckmann dixit: > Removing musescore-common (2.3.2+dfsg4-12) ... > rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory > dpkg: error processing package musescore-common (--remove): > installed musescore-common package pre-removal script subprocess returned > error exit status 1 > dpkg: too many errors, stopping > Errors were encountered while processing: > musescore-common Interesting, because this never happened for me, and I cannot easily reproduce it either. In a fresh cowbuilder: (pbuild3357-sid)root@tglase-nb:/# apt-get install musescore-common Reading package lists... Done Building dependency tree... Done Reading state information... Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following additional packages will be installed: musescore-general-soundfont-small The following NEW packages will be installed: musescore-common musescore-general-soundfont-small 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 3360 kB/37.5 MB of archives. After this operation, 65.0 MB of additional disk space will be used. Do you want to continue? [Y/n] Get:1 http://deb.debian.org/debian sid/main amd64 musescore-common all 2.3.2+dfsg4-12 [3360 kB] Fetched 3360 kB in 1s (2438 kB/s) debconf: delaying package configuration, since apt-utils is not installed Selecting previously unselected package musescore-general-soundfont-small. (Reading database ... 13206 files and directories currently installed.) Preparing to unpack .../musescore-general-soundfont-small_0.2-2_all.deb ... Unpacking musescore-general-soundfont-small (0.2-2) ... Selecting previously unselected package musescore-common. Preparing to unpack .../musescore-common_2.3.2+dfsg4-12_all.deb ... Unpacking musescore-common (2.3.2+dfsg4-12) ... Setting up musescore-general-soundfont-small (0.2-2) ... update-alternatives: using /usr/share/sounds/sf3/MuseScore_General_Lite.sf3 to provide /usr/share/sounds/sf3/default-GM.sf3 (default-GM.sf3) in auto mode update-alternatives: using /usr/share/sounds/sf3/MuseScore_General_Lite.sf3 to provide /usr/share/sounds/sf3/MuseScore_General.sf3 (MuseScore_General.sf3) in auto mode Setting up musescore-common (2.3.2+dfsg4-12) ... (pbuild3357-sid)root@tglase-nb:/# apt-get purge musescore-common Reading package lists... Done Building dependency tree... Done Reading state information... Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following package was automatically installed and is no longer required: musescore-general-soundfont-small Use 'sudo apt autoremove' to remove it. The following packages will be REMOVED: musescore-common* 0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. After this operation, 25.1 MB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 13590 files and directories currently installed.) Removing musescore-common (2.3.2+dfsg4-12) ... Similarily, if I remove both: (pbuild3357-sid)root@tglase-nb:/# apt-get purge musescore-general-soundfont-small musescore-common Reading package lists... Done Building dependency tree... Done Reading state information... Done Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done The following packages will be REMOVED: musescore-common* musescore-general-soundfont-small* 0 upgraded, 0 newly installed, 2 to remove and 0 not upgraded. After this operation, 65.0 MB disk space will be freed. Do you want to continue? [Y/n] (Reading database ... 13590 files and directories currently installed.) Removing musescore-common (2.3.2+dfsg4-12) ... Removing musescore-general-soundfont-small (0.2-2) ... bye, //mirabilos -- If Harry Potter gets a splitting headache in his scar when he’s near Tom Riddle (aka Voldemort), does Tom get pain in the arse when Harry is near him? -- me, wondering why it’s not Jerry Potter………
Bug#984592: musescore-common: fails to remove: rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory
Andreas Beckmann dixit:
>during a test with piuparts I noticed your package fails to remove.
>
>>From the attached log (scroll to the bottom...):
>
> Removing musescore-common (2.3.2+dfsg4-12) ...
> rmdir: failed to remove '/usr/share/sounds/sf2': No such file or directory
> dpkg: error processing package musescore-common (--remove):
Ouch, interesting. Why is this?
case $1 in
(remove|deconfigure)
# remove directories if they were created in postinst
rmdir --ignore-fail-on-non-empty \
/usr/share/sounds/sf2 /usr/share/sounds/sf3 /usr/share/sounds/sfz
;;
Ah, because it doesn’t exist, I guess.
>Why don't you ship the three empty directories in the package?
lintian considers that an error.
Thanks for the heads-up, will fix this in src:musescore{2,3} both.
bye,
//mirabilos
--
22:20⎜ The crazy that persists in his craziness becomes a master
22:21⎜ And the distance between the craziness and geniality is
only measured by the success 18:35⎜ "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#981699: thinkfan: fails on upgrade
Evgeni Golov dixit: >>>, exactly because neither the old nor the new configuration is in a >>>state where it's supposed to work out of the box. >> >>But why? The pre-YAML thing *did* work out of the box, very finely >>so, and I only changed the config one hot summer to have a little >>more quiet. This worked for *years*. > >If you happen to have a ThinkPad with exactly the same sensors like the >author had when the example was written, you were just lucky. Oh, WTF? Really? I thought the config was just to change defaults or when there are problems, and to adjust the temperature levels, and it would figure out which Thinkpad it’s run on and work out suitable settings, after all, there are only so many models out there, and fans are probably identical (or at least mapped to the same kernel devices) on many of those. That will need thought. It’s still leaving me with an upgrade problem. My old config was literally just… $ sed -e 's/#.*//' -e '/^ *$/d' /etc/thinkfan.conf (0, 0, 58) (1, 47, 60) (2, 55, 66) (5, 60, 77) (7, 70, 32767) … modulo comments, and the new one doesn’t work, and I don’t even know what I’m supposed to put where. Perhaps upstream has some kind of list what model needs which settings? Also, YAML is such a weird format unfriendly to human editing… … but I’ve got a local workaround for now. n8, //mirabilos -- den AGP stecker anfeilen, damit er in den slot aufm 440BX board passt… oder netzteile, an die man auch den monitor angeschlossen hat und die dann für ein elektrisch aufgeladenes gehäuse gesorgt haben […] für lacher gut auf jeder LAN party │ damals, als der pizzateig noch auf dem monior "gegangen" ist
Bug#981699: thinkfan: fails on upgrade
Evgeni Golov dixit: >>… without that it’ll also fail, which means it’ll fail package >>installation, which is a serious (RC) bug. > >No, the daemon is not started on install Did that change recently? Because when I reported this bug first it was precisely because it was started on install… >, exactly because neither the old nor the new configuration is in a >state where it's supposed to work out of the box. But why? The pre-YAML thing *did* work out of the box, very finely so, and I only changed the config one hot summer to have a little more quiet. This worked for *years*. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#981699: thinkfan: fails on upgrade
Evgeni Golov dixit: >> No, this is about the *vanilla* config shipped by the package. >> It used to work (my adjustment later was only regarding the levels >> of temperature as I’ve got an SSD, not HDD, so it can become a bit >> higher for quietness) and now the package doesn’t work at all. > >Yeah, but that config is gone from the upstream tarball as it's >deprecated. The YAML one? tglase@tglase-nb:~ $ ll /etc/thinkfan.* -rw-r--r-- 1 root root 1976 Jun 23 2020 /etc/thinkfan.conf -rw-r--r-- 1 root root 6999 Jan 27 21:06 /etc/thinkfan.yaml Nope, still there, not dpkg-maintscript-helper rm_conffile’d. But let’s see… tglase@tglase-nb:~ $ sudo rm /etc/thinkfan.yaml [sudo] password for tglase: tglase@tglase-nb:~ $ sudo mv /etc/thinkfan.conf /etc/thinkfan.old tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan start Starting fan control tool: thinkfan ERROR: /etc/thinkfan.conf: No such file or directory failed! … without that it’ll also fail, which means it’ll fail package installation, which is a serious (RC) bug. Honestly, all this hassle, I’d consider reverting to the last working (pre-YAML) version, if it were me, and try to work something out, over the next years, with upstream that actually works… bye, //mirabilos -- 16:47⎜«mika:#grml» .oO(mira ist einfach gut) 23:22⎜«mikap:#grml» mirabilos: und dein bootloader ist geil :)23:29⎜«mikap:#grml» und ich finds saugeil dass ich ein bsd zum booten mit grml hab, das muss ich dann gleich mal auf usb-stick installieren -- Michael Prokop über MirOS bsd4grml
Bug#981699: thinkfan: fails on upgrade
Evgeni Golov dixit: >> tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan start >> Starting fan control tool: thinkfan >> ERROR: Error scanning >> /sys/devices/pci:00/:00:03.1/:27:00.0/hwmon: No such file or >> directory >> failed! > >-3 has a NEWS.Debian explaining the change and how you can get your old >config back. No, this is about the *vanilla* config shipped by the package. It used to work (my adjustment later was only regarding the levels of temperature as I’ve got an SSD, not HDD, so it can become a bit higher for quietness) and now the package doesn’t work at all. bye, //mirabilos -- 22:20⎜ The crazy that persists in his craziness becomes a master 22:21⎜ And the distance between the craziness and geniality is only measured by the success 18:35⎜ "Psychotics are consistently inconsistent. The essence of sanity is to be inconsistently inconsistent
Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'
With cgroup_controllers = [] in /etc/libvirt/qemu.conf I could get it back to working for the 6.9.0-4 version though. That didn’t (seem to) work with 7.0.0-2 earlier… :/ bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'
Package: libvirt-daemon Version: 6.9.0-4 Followup-For: Bug #983871 X-Debbugs-Cc: t...@mirbsd.de Ouch, after a reboot this stopped working again! -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libvirt-daemon depends on: ii libblkid1 2.36.1-7 ii libc6 2.31-9 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgcc-s1 10.2.1-6 ii libglib2.0-02.66.7-1 ii libnetcf1 1:0.2.8-1.1 ii libparted2 3.4-1 ii libpcap0.8 1.10.0-2 ii libpciaccess0 0.16-1 ii libselinux1 3.1-3 ii libudev1247.3-1 ii libvirt-daemon-driver-qemu 6.9.0-4 hi libvirt06.9.0-4 ii libxml2 2.9.10+dfsg-6.3+b1 Versions of packages libvirt-daemon recommends: pn libvirt-daemon-driver-lxc pn libvirt-daemon-driver-vbox pn libvirt-daemon-driver-xen ii libxml2-utils 2.9.10+dfsg-6.3+b1 ii netcat-openbsd 1.217-3 ii qemu-system 1:5.2+dfsg-6 Versions of packages libvirt-daemon suggests: pn libvirt-daemon-driver-storage-gluster pn libvirt-daemon-driver-storage-iscsi-direct pn libvirt-daemon-driver-storage-rbd pn libvirt-daemon-driver-storage-zfs ii libvirt-daemon-system 6.9.0-4 pn numad -- no debconf information
Bug#981699: thinkfan: fails on upgrade
Package: thinkfan Version: 1.2.1-3 Followup-For: Bug #981699 X-Debbugs-Cc: t...@mirbsd.de Control: reopen 981699 Control: severity 981699 serious Unfortunately, thinkfan still fails to work: tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan stop Stopping fan control tool: thinkfan. tglase@tglase-nb:~ $ sudo cleanenv / /etc/init.d/thinkfan start Starting fan control tool: thinkfan ERROR: Error scanning /sys/devices/pci:00/:00:03.1/:27:00.0/hwmon: No such file or directory failed! There’s no thinkfan binary running now. (I’ve not yet touched its new configuration, as it’s not even working.) -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages thinkfan depends on: ii init-system-helpers 1.60 ii libatasmart4 0.19-5 ii libc62.31-9 ii libgcc-s110.2.1-6 ii libstdc++6 10.2.1-6 ii libyaml-cpp0.6 0.6.3-9 thinkfan recommends no packages. thinkfan suggests no packages. -- Configuration Files: /etc/default/thinkfan changed: START=yes DAEMON_ARGS="-q" /etc/thinkfan.conf changed: (0, 0, 58) (1, 47, 60) (2, 55, 66) (5, 60, 77) (7, 70, 32767) -- no debconf information
Bug#983872: xrdp: again (still?) writes internal messages to the console during startup
Package: xrdp Version: 0.9.15-1 Severity: minor X-Debbugs-Cc: t...@mirbsd.de $ sudo cleanenv / /etc/init.d/xrdp start Starting Remote Desktop Protocol server: xrdp-sesmanlogging configuration: LogFile: /var/log/xrdp-sesman.log LogLevel: [INFO ] ConsoleLevel: SyslogLevel: [INFO ] xrdp. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages xrdp depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii libc62.31-9 ii libfuse2 2.9.9-5 ii libjpeg62-turbo 1:2.0.6-2 ii libopus0 1.3.1-0.1 ii libpam0g 1.4.0-6 ii libssl1.11.1.1j-1 ii libx11-6 2:1.7.0-2 ii libxfixes3 1:5.0.3-2 ii libxrandr2 2:1.5.1-1 ii lsb-base 11.1.0 ii ssl-cert 1.1.0 Versions of packages xrdp recommends: ii fuse3 [fuse] 3.10.2-2 ii xorgxrdp 1:0.2.15-1 Versions of packages xrdp suggests: pn guacamole Versions of packages xorgxrdp depends on: ii libc6 2.31-9 ii libepoxy0 1.5.5-1 pn xorg-input-abi-24 ii xserver-xorg-core [xorg-video-abi-24] 2:1.20.10-3 Versions of packages xorgxrdp recommends: ii xorg 1:7.7+22 Versions of packages xrdp is related to: ii tigervnc-standalone-server [vnc-server] 1.11.0+dfsg-1 ii xserver-xorg-legacy 2:1.20.10-3 -- no debconf information
Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'
notfound 983871 6.9.0-4 thanks > Package: libvirt-daemon > Version: 7.0.0-2 > After an upgrade+reboot I cannot start VMs *again* with some cgroup error: Downgrading the entire bunch of involved packages fixes this: tglase@tglase:~/a $ sudo apt-get install $PWD/*.deb Reading package lists... 0%Reading package lists... 0%Reading package lists... 7%Reading package lists... 7%Reading package lists... 7%Reading package lists... 8%Reading package lists... 8%Reading package lists... 9%Reading package lists... 9%Reading package lists... 21%Reading package lists... 21%Reading package lists... 22%Reading package lists... 22%Reading package lists... 25%Reading package lists... 25%Reading package lists... 32%Reading package lists... 32%Reading package lists... 96%Reading package lists... 96%Reading package lists... Done Building dependency tree... 0%Building dependency tree... 0%Building dependency tree... 50%Building dependency tree... 50%Building dependency tree... 96%Building dependency tree... Done Reading state information... 0% Reading state information... 0%Reading state information... Done Note, selecting 'libvirt-clients' instead of '/home/tglase/a/libvirt-clients_6.9.0-4_x32.deb' Note, selecting 'libvirt-daemon-config-network' instead of '/home/tglase/a/libvirt-daemon-config-network_6.9.0-4_all.deb' Note, selecting 'libvirt-daemon-config-nwfilter' instead of '/home/tglase/a/libvirt-daemon-config-nwfilter_6.9.0-4_all.deb' Note, selecting 'libvirt-daemon-driver-qemu' instead of '/home/tglase/a/libvirt-daemon-driver-qemu_6.9.0-4_x32.deb' Note, selecting 'libvirt-daemon-system-sysv' instead of '/home/tglase/a/libvirt-daemon-system-sysv_6.9.0-4_all.deb' Note, selecting 'libvirt-daemon-system' instead of '/home/tglase/a/libvirt-daemon-system_6.9.0-4_x32.deb' Note, selecting 'libvirt-daemon' instead of '/home/tglase/a/libvirt-daemon_6.9.0-4_x32.deb' Note, selecting 'libvirt0' instead of '/home/tglase/a/libvirt0_6.9.0-4_x32.deb' Note, selecting 'python3-libvirt' instead of '/home/tglase/a/python3-libvirt_6.1.0-1+b3_x32.deb' Starting pkgProblemResolver with broken count: 0 Starting 2 pkgProblemResolver with broken count: 0 Done Suggested packages: libvirt-daemon-driver-storage-gluster libvirt-daemon-driver-storage-iscsi-direct libvirt-daemon-driver-storage-rbd libvirt-daemon-driver-storage-zfs numad apparmor auditd nfs-common open-iscsi radvd systemd systemtap zfsutils Recommended packages: libvirt-login-shell libvirt-daemon-driver-lxc libvirt-daemon-driver-vbox libvirt-daemon-driver-xen dnsmasq-base mdevctl The following packages will be DOWNGRADED: libvirt-clients libvirt-daemon libvirt-daemon-config-network libvirt-daemon-config-nwfilter libvirt-daemon-driver-qemu libvirt-daemon-system libvirt-daemon-system-sysv libvirt0 python3-libvirt 0 upgraded, 0 newly installed, 9 downgraded, 0 to remove and 7 not upgraded. Need to get 0 B/6184 kB of archives. After this operation, 178 kB disk space will be freed. Do you want to continue? [Y/n] 0% [Working]Get:1 /home/tglase/a/python3-libvirt_6.1.0-1+b3_x32.deb python3-libvirt x32 6.1.0-1+b3 [223 kB] 0% [1 python3-libvirt 0 B/223 kB 0%]5% [Working]Get:2 /home/tglase/a/libvirt-daemon-driver-qemu_6.9.0-4_x32.deb libvirt-daemon-driver-qemu x32 6.9.0-4 [751 kB] 17% [Working] Get:3 /home/tglase/a/libvirt0_6.9.0-4_x32.deb libvirt0 x32 6.9.0-4 [3930 kB] 70% [Working] Get:4 /home/tglase/a/libvirt-daemon-system-sysv_6.9.0-4_all.deb libvirt-daemon-system-sysv all 6.9.0-4 [110 kB] 74% [Working] Get:5 /home/tglase/a/libvirt-daemon-config-nwfilter_6.9.0-4_all.deb libvirt-daemon-config-nwfilter all 6.9.0-4 [56.7 kB] 77% [Working] Get:6 /home/tglase/a/libvirt-daemon-config-network_6.9.0-4_all.deb libvirt-daemon-config-network all 6.9.0-4 [54.5 kB] 80% [Working] Get:7 /home/tglase/a/libvirt-daemon-system_6.9.0-4_x32.deb libvirt-daemon-system x32 6.9.0-4 [145 kB] 84% [Working] Get:8 /home/tglase/a/libvirt-daemon_6.9.0-4_x32.deb libvirt-daemon x32 6.9.0-4 [470 kB] 92% [Working] Get:9 /home/tglase/a/libvirt-clients_6.9.0-4_x32.deb libvirt-clients x32 6.9.0-4 [446 kB] 100% [Working] [master 5224eb6] saving uncommitted changes in /etc prior to apt run Author: mirabilos 6 files changed, 117 insertions(+), 20 deletions(-) create mode 100644 libvirt/qemu/ci-busyapps.xml Preconfiguring packages ... dpkg: warning: downgrading python3-libvirt from 7.0.0-2 to 6.1.0-1+b3 (Reading database ... (Reading database ... 5%(Reading database ... 10%(Reading database ... 15%(Reading database ... 20%(Reading database ... 25%(Reading database ... 30%(Reading database ... 35%(Reading database ... 40%(Reading database ... 45%(Reading database ... 50%(Reading database ... 55%(Reading database ... 60%(Reading database ... 65%(Reading database ... 70%(Reading database ... 75%(Reading database ... 80%
Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'
Dixi quod… > After an upgrade+reboot I cannot start VMs *again* with some cgroup error: > > $ wirrsh start Netboot > > error: Failed to start domain 'Netboot' > error: internal error: failed to get cgroup backend for 'pathOfController' Matching log entry: 2021-03-02 14:33:48.839+: 3883: error : virCgroupSetValueRaw:502 : Unable to write to '/sys/fs/cgroup/machine/qemu-3-Netboot.libvirt-qemu/vcpu0/cgroup.threads': Operation not supported 2021-03-02 14:33:48.839+: 3883: error : virCgroupPathOfController:1395 : internal error: failed to get cgroup backend for 'pathOfController' Things are mounted and set up, though: tglase@tglase:~ $ ll /sys/fs/cgroup/machine total 0 -r--r--r-- 1 root root 0 2. Mär 15:41 cgroup.controllers -r--r--r-- 1 root root 0 2. Mär 15:41 cgroup.events -rw-r--r-- 1 root root 0 2. Mär 15:41 cgroup.freeze -rw-r--r-- 1 root root 0 2. Mär 15:41 cgroup.max.depth -rw-r--r-- 1 root root 0 2. Mär 15:41 cgroup.max.descendants -rw-r--r-- 1 root root 0 2. Mär 15:41 cgroup.procs -r--r--r-- 1 root root 0 2. Mär 15:41 cgroup.stat -rw-r--r-- 1 root root 0 2. Mär 15:39 cgroup.subtree_control -rw-r--r-- 1 root root 0 2. Mär 15:41 cgroup.threads -rw-r--r-- 1 root root 0 2. Mär 15:41 cgroup.type -rw-r--r-- 1 root root 0 2. Mär 15:41 cpu.max -rw-r--r-- 1 root root 0 2. Mär 15:41 cpu.pressure -r--r--r-- 1 root root 0 2. Mär 15:41 cpu.stat -rw-r--r-- 1 root root 0 2. Mär 15:41 cpu.weight -rw-r--r-- 1 root root 0 2. Mär 15:41 cpu.weight.nice -rw-r--r-- 1 root root 0 2. Mär 15:41 cpuset.cpus -r--r--r-- 1 root root 0 2. Mär 15:41 cpuset.cpus.effective -rw-r--r-- 1 root root 0 2. Mär 15:41 cpuset.cpus.partition -rw-r--r-- 1 root root 0 2. Mär 15:41 cpuset.mems -r--r--r-- 1 root root 0 2. Mär 15:41 cpuset.mems.effective -rw-r--r-- 1 root root 0 2. Mär 15:41 io.max -rw-r--r-- 1 root root 0 2. Mär 15:41 io.pressure -r--r--r-- 1 root root 0 2. Mär 15:41 io.stat -rw-r--r-- 1 root root 0 2. Mär 15:41 io.weight -r--r--r-- 1 root root 0 2. Mär 15:41 memory.current -r--r--r-- 1 root root 0 2. Mär 15:41 memory.events -r--r--r-- 1 root root 0 2. Mär 15:41 memory.events.local -rw-r--r-- 1 root root 0 2. Mär 15:41 memory.high -rw-r--r-- 1 root root 0 2. Mär 15:41 memory.low -rw-r--r-- 1 root root 0 2. Mär 15:41 memory.max -rw-r--r-- 1 root root 0 2. Mär 15:41 memory.min -r--r--r-- 1 root root 0 2. Mär 15:41 memory.numa_stat -rw-r--r-- 1 root root 0 2. Mär 15:41 memory.oom.group -rw-r--r-- 1 root root 0 2. Mär 15:41 memory.pressure -r--r--r-- 1 root root 0 2. Mär 15:41 memory.stat -r--r--r-- 1 root root 0 2. Mär 15:41 memory.swap.current -r--r--r-- 1 root root 0 2. Mär 15:41 memory.swap.events -rw-r--r-- 1 root root 0 2. Mär 15:41 memory.swap.high -rw-r--r-- 1 root root 0 2. Mär 15:41 memory.swap.max tglase@tglase:~ $ mount | fgrep cgroup cgroup2 on /sys/fs/cgroup type cgroup2 (rw,nosuid,nodev,noexec,relatime,nsdelegate) bye, //mirabilos -- Infrastrukturexperte • tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Telephon +49 228 54881-393 • Fax: +49 228 54881-235 HRB AG Bonn 5168 • USt-ID (VAT): DE122264941 Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg * Mit dem tarent-Newsletter nichts mehr verpassen: www.tarent.de/newsletter *
Bug#983871: error: internal error: failed to get cgroup backend for 'pathOfController'
Package: libvirt-daemon Version: 7.0.0-2 Severity: important X-Debbugs-Cc: t...@mirbsd.de After an upgrade+reboot I cannot start VMs *again* with some cgroup error: $ wirrsh start Netboot error: Failed to start domain 'Netboot' error: internal error: failed to get cgroup backend for 'pathOfController' To unconfuse: $ alias wirrsh wirrsh='virsh -c qemu:///system' -- System Information: Debian Release: bullseye/sid APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable'), (100, 'experimental') Architecture: x32 (x86_64) Foreign Architectures: i386, amd64 Kernel: Linux 5.10.0-3-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=C, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages libvirt-daemon depends on: ii libblkid1 2.36.1-7 ii libc6 2.31-9 ii libdevmapper1.02.1 2:1.02.175-2.1 ii libgcc-s1 10.2.1-6 ii libglib2.0-02.66.7-1 ii libnetcf1 1:0.2.8-1.1 ii libparted2 3.4-1 ii libpcap0.8 1.10.0-2 ii libpciaccess0 0.16-1 ii libselinux1 3.1-3 ii libudev1247.3-1 ii libvirt-daemon-driver-qemu 7.0.0-2 ii libvirt07.0.0-2 ii libxml2 2.9.10+dfsg-6.3+b1 Versions of packages libvirt-daemon recommends: pn libvirt-daemon-driver-lxc pn libvirt-daemon-driver-vbox pn libvirt-daemon-driver-xen ii libxml2-utils 2.9.10+dfsg-6.3+b1 ii netcat-openbsd 1.217-3 ii qemu-system 1:5.2+dfsg-6 Versions of packages libvirt-daemon suggests: pn libvirt-daemon-driver-storage-gluster pn libvirt-daemon-driver-storage-iscsi-direct pn libvirt-daemon-driver-storage-rbd pn libvirt-daemon-driver-storage-zfs ii libvirt-daemon-system 7.0.0-2 pn numad -- no debconf information
Bug#983731: manpages-dev: many pthread manpages missing (and this bug is not about those found in glibc-doc)
Package: manpages-dev Version: 5.10-1 Severity: normal X-Debbugs-Cc: t...@mirbsd.de Besides those few found in the glibc-doc package (which probably should just be taken over, given that that package really consists of only a number of pthread manpages and… imperial tons of changelogs?!), there are manpages genuinely missing, such as pthread_barrier_init, pthread_barrier_wait and friends. Funnily enough, they apparently used to exist (in another package) in stretch… Could be useful combing through libc and looking for more undocumented APIs where such documentation is obtainable elsewhere… -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldstable-updates'), (500, 'buildd-unstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages manpages-dev depends on: ii manpages 5.10-1 manpages-dev recommends no packages. Versions of packages manpages-dev suggests: ii konqueror [man-browser] 4:20.12.0-4 ii man-db [man-browser] 2.9.4-2 -- no debconf information
Bug#983561: firmware-misc-nonfree: broken-symlink /lib/firmware/cxgb4/t4-config.txt and others
maximilian attems dixit: >are there other dangling symlinks besides this three mentioned ones? adequate reported only these three for this package; you can find dangling symlinks, generally, with: (thanks XTaran) find -L . -type l -ls bye, //mirabilos -- FWIW, I'm quite impressed with mksh interactively. I thought it was much *much* more bare bones. But it turns out it beats the living hell out of ksh93 in that respect. I'd even consider it for my daily use if I hadn't wasted half my life on my zsh setup. :-) -- Frank Terbeck in #!/bin/mksh
