Bug#1074239: cura: Cura fails to start
Control: severity -1 grave I'm also having this problem as of recently. I tried building the package myself from source (the Debian version, not upstream) and still had the problem. It's probably related to a recent upgrade of one of Cura's dependencies. I wasn't able to get upstream to build, but if I do I will report back here. Since this bug makes the package unusable, I think the severity should be grave. I am not sure whether anyone is able to change that, but I have added the control header in case it works, because I think it's pretty clear that the severity should be grave. Thanks, Asher -- Violence is the last refuge of the incompetent. -- Salvor Hardin I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#1053387: reportbug: querybts crashes when more than one bug number is passed on the command line
Package: reportbug
Version: 12.0.0
Severity: normal
X-Debbugs-Cc: none, Asher Gordon
Dear Maintainer,
-- Package-specific info:
** Environment settings:
EDITOR="/home/asher/.config/fish/scripts/emacsclient.fish"
When passing multiple bug numbers on the command line, the querybts
script crashes. Example:
$ querybts 100 101
Querying Debian BTS for reports on 100 101...
2 bug reports found:
Traceback (most recent call last):
File "/usr/bin/querybts", line 241, in
main()
File "/usr/bin/querybts", line 217, in main
ui.handle_bts_query(package, options.system, options.timeout,
options.mirrors, options.http_proxy,
File "/usr/lib/python3/dist-packages/reportbug/ui/text_ui.py", line 603,
in handle_bts_query
package = [p[4:] for p in package if p.startswith("src:")][0]
File "/usr/lib/python3/dist-packages/reportbug/ui/text_ui.py", line 603,
in
package = [p[4:] for p in package if p.startswith("src:")][0]
AttributeError: 'int' object has no attribute 'startswith'
This is because of a chunk of code introduced in 9855d71:
# only pass a single package name to browse_bugs
if isinstance(package, list):
package = [p[4:] for p in package if p.startswith("src:")][0]
source = True
This code is problematic for several reasons.
1. The elements of 'package' are integers, not strings (I am not sure
under what circumstances they would be strings). This is what causes the
crash.
2. Even if we fix problem 1 (e.g. s/if p/if str(p)/), this code still
fails if none of the packages begin with the string 'src:', because the
list comprehension will result in an empty list, for which 0 is an
invalid index.
3. There is no need for a list comprehension at all (or even a loop),
since we only take the 0th element.
4. Even if this code did what I believe it intended to do (more or less
'package = package[0]'), this does not align with expected behavior. The
help text for the 'b' command says 'Open the complete bugs list in a web
browser.' Note that it does not say 'Open the first bug in a web
browser.'
I believe all of these problems can be fixed by
a) Reverting 9855d71.
b) Changing browse_bugs() and search_bugs() to call launch_browser()
multiple times (once for each package).
c) Changing launch_browser() to run xdg-open in the background so that
all the bugs are opened in separate tabs, and you don't have to close
the browser to see the next bug. webbrowser().open() automatically runs
the browser in the background as far as I can tell, so we don't have to
worry about that part.
I have done all of these things in the patch below:
From 2037bac77dae3e49162780277ff0501726bc6bf0 Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Tue, 3 Oct 2023 00:51:18 -0400
Subject: [PATCH] Fix browsing multiple bugs from the command line.
---
reportbug/ui/text_ui.py | 15 +--
reportbug/urlutils.py | 2 +-
2 files changed, 6 insertions(+), 11 deletions(-)
diff --git a/reportbug/ui/text_ui.py b/reportbug/ui/text_ui.py
index bd8bd83..af316fb 100644
--- a/reportbug/ui/text_ui.py
+++ b/reportbug/ui/text_ui.py
@@ -598,11 +598,6 @@ def handle_bts_query(package, bts, timeout, mirrors=None, http_proxy="",
else:
ewrite('%d bug reports found:\n\n', count)
-# only pass a single package name to browse_bugs
-if isinstance(package, list):
-package = [p[4:] for p in package if p.startswith("src:")][0]
-source = True
-
return browse_bugs(hierarchy, count, bugs, bts, queryonly,
mirrors, http_proxy, timeout, screen, title,
package, source, mbox_reader_cmd)
@@ -690,10 +685,9 @@ def browse_bugs(hierarchy, count, bugs, bts, queryonly, mirrors,
lastpage = []
break
elif x == 'b':
-if source:
-launch_browser('https://bugs.debian.org/src:%s' % package)
-else:
-launch_browser('https://bugs.debian.org/%s' % package)
+for p in package:
+launch_browser('https://bugs.debian.org/%s%s' %
+ (('src:' if source else ''), p))
continue
elif x == 'r':
continue
@@ -910,7 +904,8 @@ def search_bugs(hierarchyfull, bts, queryonly, mirrors,
lastpage = []
Bug#1051972: jami-daemon: Fails to start with libopendht2 2.6.0.4-1
Package: jami-daemon Version: 20230206.0~ds2-1.3 Severity: grave X-Debbugs-Cc: none, Asher Gordon Dear Maintainer, After upgrading libopendht2, jami-daemon fails to start, making Jami unusable. Downgrading libopendht2 fixes the problem. $ apt-cache policy libopendht2 | grep Installed: Installed: 2.6.0.4-1 $ jami Using Qt runtime version: 6.4.2 "notify server name: dunst, vendor: knopwob, version: 1.9.2 (2023-04-20), spec: 1.2" "Using locale: en_US" "Error : jamid is not available, make sure it is running" terminate called after throwing an instance of 'char const*' Aborted $ /usr/libexec/jamid /usr/libexec/jamid: symbol lookup error: /usr/libexec/jamid: undefined symbol: _ZN3dht4http8ResolverC1ERN4asio10io_contextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10shared_ptrINS_6LoggerEE Downgrading: $ sudo sed -i~ s/trixie/bookworm/g /etc/apt/sources.list $ sudo apt-get update Get:1 tor+https://deb.debian.org/debian bookworm InRelease [151 kB] [...] Fetched 88.2 MB in 42s (2,120 kB/s) Reading package lists... Done $ sudo apt-get install libopendht2=2.4.12-7 Reading package lists... Done Building dependency tree... Done Reading state information... Done The following packages will be DOWNGRADED: libopendht2 0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded. Need to get 806 kB of archives. After this operation, 377 kB disk space will be freed. Do you want to continue? [Y/n] y Get:1 tor+https://deb.debian.org/debian bookworm/main amd64 libopendht2 amd64 2.4.12-7 [806 kB] Fetched 806 kB in 2s (335 kB/s) debconf: unable to initialize frontend: Dialog debconf: (Dialog frontend will not work on a dumb terminal, an emacs shell buffer, or without a controlling terminal.) debconf: falling back to frontend: Readline dpkg: warning: downgrading libopendht2:amd64 from 2.6.0.4-1 to 2.4.12-7 (Reading database ... 586843 files and directories currently installed.) Preparing to unpack .../libopendht2_2.4.12-7_amd64.deb ... Unpacking libopendht2:amd64 (2.4.12-7) over (2.6.0.4-1) ... Setting up libopendht2:amd64 (2.4.12-7) ... Processing triggers for libc-bin (2.37-8) ... $ apt-cache policy libopendht2 | grep Installed: Installed: 2.4.12-7 $ jami Using Qt runtime version: 6.4.2 "notify server name: dunst, vendor: knopwob, version: 1.9.2 (2023-04-20), spec: 1.2" "Using locale: en_US" No migration required [...] $ /usr/libexec/jamid Jami Daemon 13.7.0, by Savoir-faire Linux Inc. 2004-2023 https://jami.net/ [Video support enabled] [Plugins support enabled] 22:56:59.121 os_core_unix.c !pjlib 2.12.1 for POSIX initialized C-c C-cCaught signal Interrupt, terminating... Jami runs as expected. It looks like jamid references an undefined symbol, _ZN3dht4http8ResolverC1ERN4asio10io_contextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10shared_ptrINS_6LoggerEE, which is likely present in the old version of libopendht2. I don't know a whole lot about C++ and name mangling, but I would guess that Jami had been using a deprecated or undocumented symbol, which has been removed or renamed in libopendht2. It's also possible that the new libopendht2 was compiled with a newer compiler, which mangled the name differently, but as far as I know, name mangling is supposed to be fairly stable (again, I don't know a whole lot about this). Also, the name unmangled: $ echo _ZN3dht4http8ResolverC1ERN4asio10io_contextERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEESt10shared_ptrINS_6LoggerEE | c++filt dht::http::Resolver::Resolver(asio::io_context&, std::__cxx11::basic_string, std::allocator > const&, std::shared_ptr) Thanks, Asher -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-4-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages jami-daemon depends on: ii libarchive13 3.6.2-1 ii libasound2 1.2.9-2 ii libavcodec60 7:6.0-6 ii libavdevice607:6.0-6 ii libavfilter9 7:6.0-6 ii libavformat607:6.0-6 ii libavutil58 7:6.0-6 ii libc62.37-8 ii libdbus-c++-1-0v50.9.0-12 ii libfmt9 9.1.0+ds1-2 ii libgcc-s113.2.0-3 ii libgit2-1.5 1.5.1+ds-1
Bug#947222: marked as pending in bsdgames
Hi Tobias, Thanks for fixing this bug. I believe #723808 can now be closed as well. Thanks, Asher -- Brian Kernighan has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant "?" lights up in the center of the dashboard. "The experienced driver", he says, "will usually know what's wrong." I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#1041902: lua5.4: 'lua_settop' may use an invalid pointer to stack
Control: reassign -1 src:lua5.4
Asher Gordon writes:
> I think this fix from upstream should be backported to Debian's Lua
> 5.4, and possibly 5.{1,2,3} as well (I haven't tested those).
I found out Lua 5.4 is the first version with lua_toclose() (and the
__close() metamethod), so the particular manifestation of the bug I've
shown cannot be present in previous versions. Also, lua.org says this
bug has existed since 5.4.3: https://www.lua.org/bugs.html#5.4.4-5
I think that Debian should update lua5.4 to the latest upstream version
5.4.6, which should fix this (and other) bugs. I see that currently,
even in sid, lua5.4 is still 5.4.4.
Thanks,
Asher
P.S. I am reassigning this to the source package, since I think that
makes more sense.
--
On two occasions I have been asked [by members of Parliament!], "Pray, Mr.
Babbage, if you put into the machine wrong figures, will the right answers
come out?" I am not able rightly to apprehend the kind of confusion of
ideas that could provoke such a question.
-- Charles Babbage
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#1041902: lua5.4: 'lua_settop' may use an invalid pointer to stack
Package: lua5.4
Version: 5.4.4-3
Severity: normal
X-Debbugs-Cc: none, Asher Gordon
Dear Maintainer,
I found a bug in which calling lua_toclose() while the "main" stack is
active (i.e., not inside a function which was called by lua_call()), can
sometimes cause memory errors later. As I later found out, this was a
symptom of a bug in lua_settop(). Here is a minimal example showcasing
the bug:
#include
#include
#include
#include
/* Here's where we do our experimentation. The table returned by the
Lua program should be given as the sole argument on the Lua
stack. */
static int experiment(lua_State *L) {
/* local obj = class:new() */
lua_getfield(L, -1, "new");
lua_rotate(L, -2, 1);
lua_call(L, 1, 1);
lua_toclose(L, -1);
lua_pop(L, 1);
return 0;
}
int main(int argc, char **argv) {
lua_State *L;
const char *prog;
if (argc != 2) {
fprintf(stderr, "Usage: %s FILE\n", argv[0]);
return 1;
}
prog = argv[1];
L = luaL_newstate();
luaL_openlibs(L);
if (luaL_loadfile(L, prog))
lua_error(L);
lua_call(L, 0, 1);
if (!lua_istable(L, -1))
luaL_error(L, "%s did not return a table", prog);
#ifdef BAD_CODE
/* Here's where the error originates! If we call experiment()
manually like this, closing the value causes memory errors later
on. Instead, we have to call it through Lua. */
experiment(L);
#else
/* This works as expected. */
lua_pushcfunction(L, experiment);
lua_rotate(L, -2, 1);
lua_call(L, 1, 0);
#endif
lua_close(L);
return 0;
}
local inspect = require 'inspect'
local class = {}
local mt = {__index = class}
function mt:__close ()
print('Closing!')
-- This triggers the error for some reason. I imagine it's not
-- specific to the 'inspect' package, but rather just doing
-- something complex with 'self'.
print(inspect(self))
end
function class:new ()
assert(self == mt.__index)
return setmetatable({foo = 'bar'}, mt)
end
return class
Compile using
$ gcc -Wall -O0 -DBAD_CODE `pkg-config --cflags lua5.4` -o memory-error
memory-error.c `pkg-config --libs lua5.4`
and then run it with
$ valgrind ./memory-error test.lua
You should notice many errors. If you compile without -DBAD_CODE, it
works as expected (see the source for details).
I tried this with the latest upstream version from git, and found that
the bug did not occur. After some bisecting, I found the commit where
this was fixed upstream. The commit is "196bb94d Bug: 'lua_settop' may
use an invalid pointer to stack"
https://github.com/lua/lua/commit/196bb94d66e727e0aec053a0276c3ad701500762
I'm not sure if this is a security issue or not. If so, please raise the
Severity accordingly.
I think this fix from upstream should be backported to Debian's Lua 5.4,
and possibly 5.{1,2,3} as well (I haven't tested those). Hopefully it is
as simple as applying the patch.
Thanks,
Asher
-- System Information:
Debian Release: trixie/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.3.0-1-amd64 (SMP w/12 CPU threads; PREEMPT)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages lua5.4 depends on:
ii libc6 2.37-5
ii libreadline8 8.2-1.3
lua5.4 recommends no packages.
lua5.4 suggests no packages.
-- no debconf information
--
Yesterday upon the stair
I met a man who wasn't there.
He wasn't there again today --
I think he's from the CIA.
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#1038918: librem-ec-acpi-dkms: Does not build against Linux 6.3.0
Package: librem-ec-acpi-dkms Version: 0.9.1-4 Severity: grave X-Debbugs-Cc: none, Asher Gordon Dear Maintainer, During a system upgrade, I noticed that there was an error upgrading the Linux kernel. I was able to isolate the problem to the librem-ec-acpi-dkms package. (Without this package, the brightness keys on the Librem 14 do not work anymore after a suspend, and possibly other issues too.) If I remove the package and install it again, I get the following output: Loading new librem_ec_acpi-0.9.1 DKMS files... Building for 6.1.0-9-amd64 6.3.0-1-amd64 Building initial module for 6.1.0-9-amd64 Done. librem_ec_acpi.ko: Running module version sanity check. - Original module - No original module exists within this kernel - Installation - Installing to /lib/modules/6.1.0-9-amd64/updates/dkms/ depmod... Building initial module for 6.3.0-1-amd64 Error! Bad return status for module build on kernel: 6.3.0-1-amd64 (x86_64) Consult /var/lib/dkms/librem_ec_acpi/0.9.1/build/make.log for more information. dpkg: error processing package librem-ec-acpi-dkms (--configure): installed librem-ec-acpi-dkms package post-installation script subprocess returned error exit status 10 So it appears to build successfully against 6.1.0, but not 6.3.0. Here is the contents of my /var/lib/dkms/librem_ec_acpi/0.9.1/build/make.log: DKMS make.log for librem_ec_acpi-0.9.1 for kernel 6.3.0-1-amd64 (x86_64) Fri Jun 23 01:16:58 AM EDT 2023 make: Entering directory '/usr/src/linux-headers-6.3.0-1-amd64' CC [M] /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.o /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:276:24: error: initialization of ‘int (*)(struct power_supply *, struct acpi_battery_hook *)’ from incompatible pointer type ‘int (*)(struct power_supply *)’ [-Werror=incompatible-pointer-types] 276 | .add_battery = librem_ec_battery_add, |^ /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:276:24: note: (near initialization for ‘librem_ec_battery_hook.add_battery’) /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:277:27: error: initialization of ‘int (*)(struct power_supply *, struct acpi_battery_hook *)’ from incompatible pointer type ‘int (*)(struct power_supply *)’ [-Werror=incompatible-pointer-types] 277 | .remove_battery = librem_ec_battery_remove, | ^~~~ /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:277:27: note: (near initialization for ‘librem_ec_battery_hook.remove_battery’) /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:773:27: error: initialization of ‘void (*)(struct acpi_device *)’ from incompatible pointer type ‘int (*)(struct acpi_device *)’ [-Werror=incompatible-pointer-types] 773 | .remove = librem_ec_remove, | ^~~~ /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.c:773:27: note: (near initialization for ‘librem_ec_driver.ops.remove’) cc1: some warnings being treated as errors make[1]: *** [/usr/src/linux-headers-6.3.0-1-common/scripts/Makefile.build:257: /var/lib/dkms/librem_ec_acpi/0.9.1/build/librem_ec_acpi.o] Error 1 make: *** [/usr/src/linux-headers-6.3.0-1-common/Makefile:2050: /var/lib/dkms/librem_ec_acpi/0.9.1/build] Error 2 make: Leaving directory '/usr/src/linux-headers-6.3.0-1-amd64' I don't know much about kernel module development, but it looks like these errors are due to an API change in the new kernel version. This makes the package nonfunctional for Linux 6.3.0 (although it still works for 6.1.0, which I'm on now), thus the grave severity. Thanks, Asher -- System Information: Debian Release: trixie/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-9-amd64 (SMP w/12 CPU threads; PREEMPT) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages librem-ec-acpi-dkms depends on: ii dkms 3.0.11-3 librem-ec-acpi-dkms recommends no packages. librem-ec-acpi-dkms suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#1029974: libsox-fmt-base: [PATCH] vorbis: fix memory leaks
Also, I should note that I also reported this bug upstream. Since I don't have a SourceForge account, I wrote to where my message is awaiting moderator approval. But until the bug is fixed upstream, perhaps a patch should be implemented in the Debian package. Thanks, Asher -- Brian Kernighan has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant "?" lights up in the center of the dashboard. "The experienced driver", he says, "will usually know what's wrong." I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#1029974: libsox-fmt-base: [PATCH] vorbis: fix memory leaks
Package: libsox-fmt-base
Version: 14.4.2+git20190427-3+b1
Severity: normal
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
While attempting to write Perl bindings for libsox, I stumbled upon a
memory leak in vorbis.c (two, actually). The memory leak can be seen by
something like the following:
$ valgrind --leak-check=full --show-leak-kinds=all sox test.ogg test.mp3
$ valgrind --leak-check=full --show-leak-kinds=all sox test.mp3 test.ogg
The first line shows the read memory leak and the second shows the write
memory leak.
The fix is trivial, and I have attached a patch below (created on the
upstream code base, but applies cleanly on the Debian version):
From a23816e06a6433d1d553668bb8bd784d5f11d37e Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Sun, 29 Jan 2023 13:08:12 -0500
Subject: [PATCH] vorbis: fix memory leaks
Data was allocated in startread() and startwrite() that was not freed
in stopread() and stopwrite(). Fix it.
---
src/vorbis.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/vorbis.c b/src/vorbis.c
index 9fa234ce..ab15301a 100644
--- a/src/vorbis.c
+++ b/src/vorbis.c
@@ -229,6 +229,7 @@ static int stopread(sox_format_t * ft)
free(vb->buf);
ov_clear(vb->vf);
+ free(vb->vf);
return (SOX_SUCCESS);
}
@@ -404,6 +405,7 @@ static int stopwrite(sox_format_t * ft)
vorbis_block_clear(&ve->vb);
vorbis_dsp_clear(&ve->vd);
vorbis_info_clear(&ve->vi);
+ free(ve);
return (SOX_SUCCESS);
}
--
2.39.0
Thanks,
Asher
-- System Information:
Debian Release: bookworm/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 6.0.0-6-amd64 (SMP w/2 CPU threads; PREEMPT)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libsox-fmt-base depends on:
ii libc6 2.36-8
ii libflac12 1.4.2+ds-2
ii libgsm1 1.0.22-1
ii libogg0 1.3.5-3
ii libopencore-amrnb0 0.1.6-1
ii libopencore-amrwb0 0.1.6-1
ii libsndfile1 1.2.0-1
ii libsox3 14.4.2+git20190427-3+b1
ii libvorbis0a 1.3.7-1
ii libvorbisenc2 1.3.7-1
ii libvorbisfile3 1.3.7-1
ii libwavpack1 5.6.0-1
libsox-fmt-base recommends no packages.
libsox-fmt-base suggests no packages.
-- no debconf information
--
* Dry-ice can't code his way out of a paper bag
dry-ice: int main() { ExitPaperBag(); return 0; }
Is that how that's done then? *takes notes*
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#1008808: texlive-games: [chess.sty] Incorrect usage of babel breaks package
Hi Hilmar, Hilmar Preuße writes: > So you're actively pushed to other packages. Please consider to follow > this recommendation. Thanks for the advice. So it seems a better solution would be to use an alternative package in Scid's generated LaTeX files. I don't think that should be too difficult. I'll do that when I have the time and send a report to upstream and/or Debian. Thanks, Asher -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me sprea= d! I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#1008808: texlive-games: [chess.sty] Incorrect usage of babel breaks package
Package: texlive-games
Version: 2021.20220204-1
Severity: normal
X-Debbugs-Cc: Asher Gordon
File: /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
Dear Maintainer,
The file /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty (used
by the LaTeX files generated by Scid) uses "\input english.sty" instead
of "\usepackage[english]{babel}". This causes a lot of errors when
compiling a LaTeX file that uses the chess package. If the errors are
ignored (e.g. by using "-interaction nonstopmode"), then the compiled
document has a lot of garbage at the start.
The following is a minimal example that produces the error:
\documentclass{article}
\usepackage{chess}
\begin{document}
This is a test.
\begin{chess}
1.~e4 c5 2.~Nf3 Nc6
\end{chess}
\end{document}
The test.fls file produced by
"pdflatex -interaction nonstopmode -recorder test.tex" is attached
below:
PWD /tmp/tmp.mH6e5epKvE
INPUT /etc/texmf/web2c/texmf.cnf
INPUT /usr/share/texmf/web2c/texmf.cnf
INPUT /usr/share/texlive/texmf-dist/web2c/texmf.cnf
INPUT /var/lib/texmf/web2c/pdftex/pdflatex.fmt
INPUT test.tex
OUTPUT test.log
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/article.cls
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/base/size10.clo
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/english.sty
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel-english/english.ldf
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/babel.def
INPUT /usr/share/texlive/texmf-dist/tex/generic/babel/txtbabel.def
INPUT /usr/share/texlive/texmf-dist/fonts/map/fontname/texfonts.map
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/chess/chess20.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/chess/chessf10.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmr6.tfm
INPUT /usr/share/texlive/texmf-dist/fonts/tfm/public/cm/cmsy6.tfm
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT /usr/share/texlive/texmf-dist/tex/latex/l3backend/l3backend-pdftex.def
INPUT ./test.aux
INPUT test.aux
INPUT test.aux
OUTPUT test.aux
OUTPUT test.pdf
INPUT /var/lib/texmf/fonts/map/pdftex/updmap/pdftex.map
INPUT test.aux
INPUT
/home/asher/.texlive2021/texmf-var/fonts/pk/ljfour/public/chess/chessf10.600pk
INPUT /usr/share/texlive/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb
The following change resolves most of the errors:
--- /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty~ 2022-04-01 15:57:17.0 -0400
+++ /usr/share/texlive/texmf-dist/tex/latex/chess/chess.sty 2022-04-01 16:26:46.228383005 -0400
@@ -61,7 +61,7 @@
%
% Do we have language support? Otherwise take default language!
%
-\ifx\undefined\babel@core@loaded\input english.sty\fi
+\ifx\undefined\babel@core@loaded\usepackage[english]{babel}\fi
Bug#987810: filters: kraut: Please remove offensive salute
Package: filters
Version: 2.55-3
Severity: normal
Tags: patch
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
The 'kraut' filter contains the salute "Sieg Heil!", which was used by
the Nazis and is considered offensive (it's even a crime in
Germany). Please remove this and replace it with "Naturlich!", as in the
following patch (see also the commit message of the patch for more
info):
From a6d6cff523e30fec19488a2efe9e7f638839f2d2 Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Thu, 29 Apr 2021 23:16:58 -0400
Subject: [PATCH] kraut: Remove offensive salute.
The "Sieg Heil!" salute was used by the Nazis, and it is even a crime
to use this salute in Germany today. Replace this salute with the
inoffensive "Naturlich!", literally "Naturally!", used as an emphatic
"yes".
Also remove braces around the "Naturlich!" print statement, since the
braces were left over from when sprintf() was used, and the braces are
not consistent with the rest of the file.
---
debian/changelog | 6 ++
kraut.l | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index d3e0097..bb11d6e 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+filters (2.55-4) unstable; urgency=medium
+
+ * kraut: remove offensive "Sieg Heil!" salute.
+
+ -- Asher Gordon Thu, 29 Apr 2021 23:16:46 -0400
+
filters (2.55-3) unstable; urgency=medium
[ Helmut Grohne ]
diff --git a/kraut.l b/kraut.l
index bc522d4..fc8fae1 100644
--- a/kraut.l
+++ b/kraut.l
@@ -65,8 +65,7 @@ Th printf("D");
[Gg]ary printf("Gerhardt");
[Jj]on printf("Hansel");
-[a-f]"!" {printf("%s Naturlich!",yytext);}
-[p-z]"!" {printf("%s Sieg Heil!",yytext);}
+"!"printf("%s Naturlich!", yytext);
. printf("%s", yytext);
\n printf("\n");
--
2.30.2
Also, I'm not sure if the "Sieg Heil!" is a violation of Debian
policy. If so, please raise the severity appropriately (or just apply my
patch ;-) ).
Thanks,
Asher
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-6-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages filters depends on:
ii libc6 2.31-11
filters recommends no packages.
Versions of packages filters suggests:
ii bsdgames 2.17-28
-- no debconf information
--
Vimes grunted. "Where there are policemen there's crime, sergeant,
remember that."
"Yes, I do, sir, although I think it sounds better with a little reordering
of the words."
[Snuff, by Terry Pratchett]
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#982776: mpdtoys: mpfade does not work for a stopped MPD server with PulseAudio output
Package: mpdtoys
Version: 0.25.0
Severity: normal
Tags: patch
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
I have configured my MPD daemon to output through PulseAudio (the PA
server is running as my local user). After doing so, when the daemon is
stopped (no song playing or paused), the volume displays as 'n/a' in
'mpc status' and is returned as undef by the 'volume' method of the
Audio::MPD::Common::Status class in the Audio::MPD Perl library. I'm not
sure why this is--possibly due to a limitation in the PulseAudio
interface--but it breaks mpfade when the MPD daemon is stopped. mpfade
thinks the volume was changed manually, even though it wasn't, and thus
exits erroneously.
Here is the exact message:
$ mpfade 0.5 100
fading up from 0 to 100 over 30 seconds
manual volume change, aborting fade up
I've written a patch to fix this problem. Unfortunately, it's a bit of a
hack, but it should work. I took the liberty of adding a
debian/changelog entry in my name, but of course, feel free to put my
name in brackets and change the name at the bottom. The patch is as
follows:
From ab6adb95c0b3a744df326f3e4351e58fe7084d20 Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Sun, 14 Feb 2021 04:51:29 -0500
Subject: [PATCH] mpfade: Fix setting volume for PulseAudio sound output.
When MPD is configured to output sound through PulseAudio, it seems
that the volume cannot be set or gotten unless a song is playing or
paused (not stopped). This could be a bug in MPD, but more likely it
is a limitation in the PulseAudio interface (I don't know much about
that, so I'm not sure).
In any case, this simple hack (unfortunately it cannot be called
anything other than a hack) should fix it. We also may need to try to
set the volume several times, because it seems it may not be possible
to set the volume immediately after we start playing a song.
---
debian/changelog | 6 ++
mpfade | 16 +++-
2 files changed, 21 insertions(+), 1 deletion(-)
diff --git a/debian/changelog b/debian/changelog
index 5e07a73..b836200 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,9 @@
+mpdtoys (0.25.2) unstable; urgency=medium
+
+ * mpfade: Fix setting volume for PulseAudio sound output.
+
+ -- Asher Gordon Sun, 14 Feb 2021 05:02:40 -0500
+
mpdtoys (0.25.1) unstable; urgency=medium
* QA upload.
diff --git a/mpfade b/mpfade
index 49adf17..49260a4 100755
--- a/mpfade
+++ b/mpfade
@@ -74,9 +74,23 @@ else {
if (! defined $endpoint) {
$endpoint=50;
}
- $mpd->volume($vol=0);
+ $vol=0;
print "fading up from $vol to $endpoint over $seconds seconds\n";
$mpd->play;
+
+ # Sometimes the volume is not defined unless a song is playing
+ # or paused (not stopped). This seems to happen for PulseAudio
+ # sound output. This little hack gets around that.
+ my $curvol;
+ my $iterations=0;
+ do {
+ $mpd->volume($vol);
+ $curvol=$mpd->status->volume;
+ if (++$iterations >= 10) {
+ die "error: cannot set volume to $vol\n";
+ }
+ } until (defined $curvol && $curvol == $vol);
+
fade($endpoint, $seconds);
}
--
2.30.0
Thanks,
Asher
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.0-3-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages mpdtoys depends on:
ii libaudio-mpd-perl 2.004-2
ii perl 5.32.1-2
mpdtoys recommends no packages.
Versions of packages mpdtoys suggests:
ii libproc-daemon-perl0.23-1
ii libstring-approx-perl 3.28-1+b3
ii libterm-readkey-perl 2.38-1+b2
ii mpd0.22.4-1
-- no debconf information
--
I often quote myself; it adds spice to my conversation.
-- G. B. Shaw
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#976990: fprintd: Latest update broke fprintd entirely
Package: fprintd Version: 1.90.5-2 Severity: grave X-Debbugs-Cc: Asher Gordon Dear Maintainer, After upgrading fprintd (and libpam-fprintd) from 1.90.1-2 to 1.90.5-2, it stopped working entirely. Instead of fingerprint authentication, password authentication is used for login and sudo. I have checked that /etc/pam.d/common-auth has the right settings. The problem appears to be that fprintd itself has stopped working, not the PAM module (which is why I reported this bug in fprintd rather than libpam-fprintd). When I use any of the fprintd-* commands, it fails as follows: $ fprintd-delete asher Impossible to get devices: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.184" (uid=1000 pid=15139 comm="fprintd-delete asher ") interface="net.reactivated.Fprint.Manager" member="GetDevices" error name="(unset)" requested_reply="0" destination=":1.185" (uid=0 pid=15143 comm="/usr/libexec/fprintd ") $ fprintd-enroll asher Impossible to enroll: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.186" (uid=1000 pid=15151 comm="fprintd-enroll asher ") interface="net.reactivated.Fprint.Manager" member="GetDefaultDevice" error name="(unset)" requested_reply="0" destination=":1.185" (uid=0 pid=15143 comm="/usr/libexec/fprintd ") $ fprintd-list asher Impossible to get devices: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.188" (uid=1000 pid=15165 comm="fprintd-list asher ") interface="net.reactivated.Fprint.Manager" member="GetDevices" error name="(unset)" requested_reply="0" destination=":1.185" (uid=0 pid=15143 comm="/usr/libexec/fprintd ") $ fprintd-verify Impossible to verify: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.189" (uid=1000 pid=15169 comm="fprintd-verify ") interface="net.reactivated.Fprint.Manager" member="GetDefaultDevice" error name="(unset)" requested_reply="0" destination=":1.185" (uid=0 pid=15143 comm="/usr/libexec/fprintd ") From the org.freedesktop.DBus.Error.AccessDenied error, it seems that it might be a permissions problem. However, the commands do not work, even when run as root: $ sudo fprintd-list asher [sudo] password for asher: Impossible to get devices: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Rejected send message, 1 matched rules; type="method_call", sender=":1.199" (uid=0 pid=15422 comm="fprintd-list asher ") interface="net.reactivated.Fprint.Manager" member="GetDevices" error name="(unset)" requested_reply="0" destination=":1.200" (uid=0 pid=15425 comm="/usr/libexec/fprintd ") All the above commands returned with an exit status of 1. Also, if I run /usr/libexec/fprintd manually, I get the following warning (although a 0 exit status): $ /usr/libexec/fprintd (fprintd:15733): fprintd-WARNING **: 13:01:49.856: Failed to get name: net.reactivated.Fprint Perhaps this is because fprintd is already running. However 'ps -fe | grep [f]printd' lists no processes. Thanks, Asher -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fprintd depends on: ii dbus 1.12.20-1 ii libc6 2.31-5 ii libfprint-2-2 1:1.90.5-2 ii libglib2.0-0 2.66.3-2 ii libpolkit-gobject-1-0 0.105-29 ii policykit-10.105-29 fprintd recommends no packages. fprintd suggests no packages. -- no debconf information -- By necessity, by proclivity, and by delight, we all quote. In fact, it is as difficult to appropriate the thoughts of others as it is to invent. -- R. Emerson -- Quoted from a fortune cookie program (whose author claims, "Actually, stealing IS easier.") [to which I reply, "You think it's easy for me to misconstrue all these misquotations?!?" Ed.] I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#975876: libpam-fprintd: Upgrade removed fprintd method from /etc/pam.d/common-auth
Package: libpam-fprintd Version: 1.90.1-2 Severity: important X-Debbugs-Cc: Asher Gordon Dear Maintainer, When I upgraded the libpam-fprintd package to 1.90.1-2 (from 0.8.1-2¹), fingerprint scanning stopped working for many things, including login, sudo, and systemctl (but still worked for GDM and GNOME). I figured out that this was because the pam_fprintd.so method had been removed from /etc/pam.d/common-auth. After using pam-auth-update to re-add fprintd, everything worked as expected. The upgrade should not have removed the pam_fprintd.so method from /etc/pam.d/common-auth. Indeed, I see no reason why that file should be modified at all. I set the severity of this bug to important, since removing fprintd from common-auth breaks many things, and the cause of the problem is not obvious. Feel free to downgrade if you disagree. The best solution, in my opinion, would be to stop further updates from modifying common-auth. At the very least, something should be added to NEWS.Debian indicating that pam-auth-update will need to be re-run in order to have fingerprints working again. Also, it's possible that a different package upgrade caused the config file to change, but this package seems the likeliest candidate. Thanks, Asher Footnotes: ¹ I had been using an old version because of other problems. See #949165. -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-3-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-fprintd depends on: ii fprintd 1.90.1-2 ii libc6 2.31-4 ii libpam-runtime 1.3.1-5 ii libpam0g1.3.1-5 ii libsystemd0 246.6-4 libpam-fprintd recommends no packages. libpam-fprintd suggests no packages. -- no debconf information -- He was part of my dream, of course -- but then I was part of his dream too. -- Lewis Carroll I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#970984: linux-image-5.8.0-2-amd64: Please replace console scrollback
Control: forwarded -1 https://bugzilla.kernel.org/show_bug.cgi?id=209421 Hi Moritz, Moritz Mühlenhoff writes: > Yeah, I'm also bitten by this for my day-to-day workflows, but > unfortunately this was removed upstream, this is not a Debian-specific > patch, so this needs to be fixed upstream, before it becomes available > in Debian again. OK, I forwarded this upstream here: https://bugzilla.kernel.org/show_bug.cgi?id=209421 Thanks, Asher -- The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#970984: linux-image-5.8.0-2-amd64: Please replace console scrollback
Package: src:linux
Version: 5.8.10-1
Severity: normal
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
After upgrading to linux-image-5.8.0-2, I noticed that scrollback is no
longer available in the console. A quick look at the changelog
('apt changelog linux-image-amd64') indicates that this was done to fix
CVE-2020-14390. Surely however, there must be a better way to fix this
than simply removing this code entirely?
It is pretty annoying not having scrollback, and I'm sure I'm not the
only one who would like scrollback replaced.
Thanks,
Asher
-- Package-specific info:
** Version:
Linux version 5.8.0-2-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian
10.2.0-9) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.10-1
(2020-09-19)
** Command line:
BOOT_IMAGE=/vmlinuz root=/dev/sda1 rw quiet splash
** Tainted: I (2048)
* workaround for bug in platform firmware applied
** Kernel log:
Unable to read kernel log; any relevant messages should be attached
** Model information
sys_vendor: Libiquity
product_name: Taurinus X200
product_version: 1.0
chassis_vendor: Libiquity
chassis_version:
bios_vendor: coreboot
bios_version: CBET4000 4.0
board_vendor: Libiquity
board_name: Taurinus X200
board_version: 1.0
** Loaded modules:
rfcomm
snd_seq_dummy
snd_hrtimer
snd_seq
snd_seq_device
fuse
ctr
ccm
bnep
btusb
btrtl
ath9k
btbcm
btintel
ath9k_common
ath9k_hw
bluetooth
ath
coretemp
kvm_intel
mac80211
uvcvideo
snd_hda_codec_conexant
snd_hda_codec_generic
kvm
jitterentropy_rng
videobuf2_vmalloc
snd_hda_intel
videobuf2_memops
snd_intel_dspcfg
videobuf2_v4l2
videobuf2_common
snd_hda_codec
drbg
cfg80211
videodev
aes_generic
snd_hda_core
snd_hwdep
crypto_simd
irqbypass
cryptd
glue_helper
snd_pcm
mc
sg
iTCO_wdt
serio_raw
intel_pmc_bxt
iTCO_vendor_support
pcspkr
ansi_cprng
snd_timer
watchdog
nvram
ledtrig_audio
snd
ecdh_generic
ecc
libaes
libarc4
soundcore
rfkill
ac
evdev
acpi_cpufreq
binfmt_misc
ecryptfs
parport_pc
ppdev
lp
parport
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
xor
zstd_decompress
zstd_compress
raid6_pq
libcrc32c
crc32c_generic
sd_mod
t10_pi
crc_t10dif
crct10dif_generic
crct10dif_common
i915
ahci
libahci
i2c_algo_bit
libata
drm_kms_helper
cec
ehci_pci
uhci_hcd
scsi_mod
drm
ehci_hcd
psmouse
e1000e
usbcore
i2c_i801
i2c_smbus
lpc_ich
ptp
pps_core
usb_common
battery
video
button
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory
Controller Hub [8086:2a40] (rev 07)
Subsystem: Lenovo ThinkPad T400 [17aa:20e0]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series
Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA
controller])
Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics
Controller [17aa:20e4]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
Kernel driver in use: i915
Kernel modules: i915
00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset
Integrated Graphics Controller [8086:2a43] (rev 07)
Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics
Controller [17aa:20e4]
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR-
00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network
Connection [8086:10f5] (rev 03)
Subsystem: Lenovo ThinkPad T400 [17aa:20ee]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-
Kernel driver in use: e1000e
Kernel modules: e1000e
00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T400 [17aa:20f0]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:1a.1 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #5 [8086:2938] (rev 03) (prog-if 00 [UHCI])
Subsystem: Lenovo ThinkPad T400 [17aa:20f0]
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR-
Kernel driver in use: uhci_hcd
Bug#970619: libnet-telnet-perl: Connections occasionally time out and cause errors
Asher Gordon writes: > I sent this report upstream, but I'm not confident it will be > applied because upstream doesn't seem t' have been active fer a > while. I just got a reply from upstream, and the author says he doesn't think it's a bug. So maybe wait on applying the patch until we've figured out whether it's a bug or not. The issue on the request tracker is here: https://rt.cpan.org/Public/Bug/Display.html?id=133371 You can reply to it by sending email to with the string "[rt.cpan.org #133371]" in the Subject header. -- The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#970619: libnet-telnet-perl: Connections occasionally time out and cause errors
Package: libnet-telnet-perl
Version: 3.04-1
Severity: normal
Tags: patch
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
I used Net::Telnet t' write a chat bot fer th' Frrree Internet Chess
Server (freechess.org), called blikII. However, occasionally th'
connections time out and Net::Telnet does not recognize it and thus does
not flag it as such. This causes prroblems, because I set th' errmode t'
a callback which dies on any error except timeout. Even if I ty
t' catch th' timeout that Net::Telnet misses, it be too late because
Net::Telnet already closed th' filehandle. Walk the plank!
I sent this report upstream, but I'm not confident it will be
applied because upstream doesn't seem t' have been active fer a
while. Here be a patch which should fix th' problem (though I ha'nae
tested it much), avast. The patch be created against 3.04_01, but also
applies against 3.04.
diff -pur Net-Telnet-3.04_01.orig/lib/Net/Telnet.pm Net-Telnet-3.04_01/lib/Net/Telnet.pm
--- Net-Telnet-3.04_01.orig/lib/Net/Telnet.pm 2020-02-17 08:12:07.0 -0500
+++ Net-Telnet-3.04_01/lib/Net/Telnet.pm 2020-09-19 23:02:58.031015494 -0400
@@ -43,6 +43,7 @@ my $AF_UNSPEC = &_import_af_unspec() ||
my $AI_ADDRCONFIG = &_import_ai_addrconfig() || 0;
my $EAI_BADFLAGS = &_import_eai_badflags() || -1;
my $EINTR = &_import_eintr();
+my $ETIMEDOUT = &_import_etimedout();
## Global variables.
use vars qw($VERSION @Telopts);
@@ -2602,6 +2603,12 @@ sub _fillbuf {
else {
next if $! =~ /^interrupted/i; # restart select()
}
+ if (defined $ETIMEDOUT) {
+ next if $! == $ETIMEDOUT; # restart select()
+ }
+ else {
+ next if $! =~ /timed out/i; # restart select()
+ }
$s->{opened} = '';
return $self->error("read error: $!");
@@ -2628,6 +2635,12 @@ sub _fillbuf {
else {
next if $! =~ /^interrupted/i; # restart sysread()
}
+ if (defined $ETIMEDOUT) {
+ next if $! == $ETIMEDOUT; # restart sysread()
+ }
+ else {
+ next if $! =~ /timed out/i; # restart sysread()
+ }
$s->{opened} = '';
return $self->error("read error: $!");
@@ -2778,6 +2791,14 @@ sub _import_eintr {
} # end sub _import_eintr
+sub _import_etimedout {
+local $@;
+local $SIG{"__DIE__"} = "DEFAULT";
+
+eval "require Errno; Errno::ETIMEDOUT();";
+} # end sub _import_etimedout
+
+
sub _interpret_cr {
my ($s, $pos) = @_;
my (
@@ -3645,6 +3666,12 @@ sub _put {
else {
next if $! =~ /^interrupted/i; # restart select()
}
+ if (defined $ETIMEDOUT) {
+ next if $! == $ETIMEDOUT; # restart select()
+ }
+ else {
+ next if $! =~ /timed out/i; # restart select()
+ }
$s->{opened} = '';
return $self->error("write error: $!");
@@ -3662,6 +3689,12 @@ sub _put {
else {
next if $! =~ /^interrupted/i; # restart syswrite()
}
+ if (defined $ETIMEDOUT) {
+ next if $! == $ETIMEDOUT; # restart syswrite()
+ }
+ else {
+ next if $! =~ /timed out/i; # restart syswrite()
+ }
$s->{opened} = '';
return $self->error("write error: $!");
Thanks,
Asher
P.S., pass the grog! Happy Talk Like a Pirate Day (fer th' next 25
minutes, anyway), with a chest full of booty.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.8.0-1-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libnet-telnet-perl depends on:
ii perl 5.30.3-4
libnet-telnet-perl recommends no packages.
libnet-telnet-perl suggests no packages.
-- no debconf information
--
It be better t' be quotable than t' be honest.
-- Tom Stoppard
I pefer t' send and receive mail encrypted, I'll warrant ye. Please
send me yer public key, and if ye den't have me public key, please
let me know. Shiver me timbers! Thanks, by Blackbearrd's sword.
GPG fingerprrrint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#970401: linux-image-5.8.0-1-amd64: Cursor still blinks (not usually visibly) even after it is turned off
Package: src:linux Version: 5.8.7-1 Severity: normal X-Debbugs-Cc: Asher Gordon Dear Maintainer, When the cursor is turned off in the console, using $ printf '\e[?17;0;0c' the cursor still blinks, although not visibly. This may not seem like a serious bug, or even a bug at all, but it becomes noticeable and annoying when watching a video with mplayer using the fbdev2 output. For example, $ printf '\e[?17;0;0c'; mplayer -quiet -vo fbdev2 -vf scale= ; tput reset The cursor is visible as a flickering black rectangle, making it very annoying to watch videos like this. Note that this bug is not present in linux-image-5.7.0-3-amd64, and when I boot onto that kernel, I cannot reproduce the bug. When watching videos as I have described, while booted onto the old kernel, the cursor is not visible at all (although, it is of course if you omit the initial 'printf'). And before you ask "why don't you just use Totem or VLC or something?" it's because I prefer to work in the console. :-) Thanks, Asher -- Package-specific info: ** Version: Linux version 5.8.0-1-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.0-6) 10.2.0, GNU ld (GNU Binutils for Debian) 2.35) #1 SMP Debian 5.8.7-1 (2020-09-05) ** Command line: BOOT_IMAGE=/vmlinuz root=/dev/sda1 rw quiet splash ** Tainted: I (2048) * workaround for bug in platform firmware applied ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Libiquity product_name: Taurinus X200 product_version: 1.0 chassis_vendor: Libiquity chassis_version: bios_vendor: coreboot bios_version: CBET4000 4.0 board_vendor: Libiquity board_name: Taurinus X200 board_version: 1.0 ** Loaded modules: rfcomm fuse snd_seq_dummy snd_hrtimer snd_seq snd_seq_device ctr ccm bnep ath9k ath9k_common btusb btrtl btbcm btintel ath9k_hw bluetooth ath mac80211 jitterentropy_rng drbg coretemp kvm_intel cfg80211 aes_generic kvm snd_hda_codec_conexant crypto_simd uvcvideo cryptd snd_hda_codec_generic glue_helper videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 snd_hda_intel snd_intel_dspcfg videobuf2_common irqbypass ansi_cprng snd_hda_codec videodev pcspkr snd_hda_core serio_raw mc iTCO_wdt intel_pmc_bxt iTCO_vendor_support snd_hwdep sg watchdog ecdh_generic ecc libaes snd_pcm libarc4 nvram snd_timer ledtrig_audio ac snd soundcore rfkill binfmt_misc evdev acpi_cpufreq ecryptfs parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 btrfs blake2b_generic xor zstd_decompress zstd_compress raid6_pq libcrc32c crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_common i915 ahci libahci libata i2c_algo_bit drm_kms_helper cec psmouse drm e1000e uhci_hcd ehci_pci scsi_mod ehci_hcd i2c_i801 usbcore i2c_smbus lpc_ich usb_common ptp pps_core battery video button ** PCI devices: 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub [8086:2a40] (rev 07) Subsystem: Lenovo ThinkPad T400 [17aa:20e0] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07) (prog-if 00 [VGA controller]) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 00:02.1 Display controller [0380]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a43] (rev 07) Subsystem: Lenovo Mobile 4 Series Chipset Integrated Graphics Controller [17aa:20e4] Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- SERR- 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit Network Connection [8086:10f5] (rev 03) Subsystem: Lenovo ThinkPad T400 [17aa:20ee] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: e1000e Kernel modules: e1000e 00:1a.0 USB controller [0c03]: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 [8086:2937] (rev 03) (prog-if 00 [UHCI]) Subsystem: Lenovo ThinkPad T400 [17aa:20f0] Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SER
Bug#969293: uci2wb: Long option strings are handled incorrectly due to insufficient buffer size
Package: uci2wb
Version: 4.1+git200714-1
Severity: normal
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
When a very long UCI option string is encountered by uci2wb, such as the
UCI_Variant option for engines with many variants like Multi-Variant
Stockfish or Fairy-Stockfish, it overflows the 'val' buffer, causing the
option to be handled incorrectly (at least when compiled with
optimization). The easy fix is to simply increase the buffer size as
below:
diff -ur a/UCI2WB.c b/UCI2WB.c
--- a/UCI2WB.c 2020-07-14 08:03:26.0 -0400
+++ b/UCI2WB.c 2020-08-30 16:17:06.311188760 -0400
@@ -331,7 +331,7 @@
}
}
else if(!strcmp(command, "option")) { // USI option: extract data fields
- char name[80], type[80], buf[1024], val[256], *q;
+ char name[80], type[80], buf[1024], val[1024], *q;
int min=0, max=1e9; *val = 0;
if(p = strstr(line+6, " type ")) sscanf(p+1, "type %s", type), *p = '\n';
if(p = strstr(line+6, " min ")) sscanf(p+1, "min %d", &min), *p = '\n';
Of course, this is hardly perfect, but a better solution would require a
lot more work.
Incidentally, I think the following quote may be relevant for uci2wb:
On the subject of C program indentation:
"In My Egotistical Opinion, most people's C programs should
be indented six feet downward and covered with dirt."
-- Blair P. Houghton
Thanks,
Asher
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages uci2wb depends on:
ii libc6 2.31-3
Versions of packages uci2wb recommends:
ii eboard 1.1.3-0.3
pn gpsshogi | eleeye
ii xboard 4.9.1-2
uci2wb suggests no packages.
-- no debconf information
--
One picture is worth 128K words.
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#969228: glaurung: Segmentation fault caused by out of bounds access
Package: glaurung
Version: 2.2-3
Severity: grave
Tags: patch
X-Debbugs-Cc: Asher Gordon
Dear Maintainer,
Glaurung segfaults when the 'go' command is used, making it
unusable. For example:
$ glaurung
Glaurung 2.2. Copyright (C) 2004-2008 Tord Romstad.
go
Segmentation fault
This is because of an out of bounds access, fixed by the following
patch:
From 62017d29d816d07513805500d498d8779343e074 Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Sat, 29 Aug 2020 12:53:56 -0400
Subject: [PATCH 1/3] Fix buffer overrun, causing a segfault
---
src/evaluate.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/evaluate.cpp b/src/evaluate.cpp
index 72032f0..ac303fa 100644
--- a/src/evaluate.cpp
+++ b/src/evaluate.cpp
@@ -1243,7 +1243,7 @@ namespace {
SafetyTable[i] = Value((int)(100 * a * (i - b)));
}
-for(i = 0; i < 100; i++)
+for(i = 0; i < 99; i++)
if(SafetyTable[i+1] - SafetyTable[i] > maxSlope) {
for(j = i + 1; j < 100; j++)
SafetyTable[j] = SafetyTable[j-1] + Value(maxSlope);
--
2.28.0
I also attempted to send this patch upstream, but I don't know Tord's
current email address (it's not t...@glaurungchess.com; I tried). So I
sent it to Matthew Purland, since he had made the last commit on
https://github.com/phenri/glaurung.
So hopefully, he will be able to apply it upstream, but until then,
please apply this patch in Debian.
Thanks,
Asher
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages glaurung depends on:
ii libc6 2.31-3
ii libstdc++6 10.1.0-6
Versions of packages glaurung recommends:
ii polyglot 2.0.4-2+b1
ii xboard4.9.1-2
glaurung suggests no packages.
-- no debconf information
--
One picture is worth 128K words.
I prefer to send and receive mail encrypted. Please send me your
public key, and if you do not have my public key, please let me
know. Thanks.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
signature.asc
Description: PGP signature
Bug#966816: lvm2: Patch to fix the problem
Michael Biebl writes: > As said in the initial message: a better fix is to simply drop that > ExecStart= line altogether. It's not necessary (anymore) for > Type=oneshot services. Sorry, I missed that. Well although it is trivial, here is a patch to justify the patch tag I added: ;-) diff --git a/scripts/blk_availability_systemd_red_hat.service.in b/scripts/blk_availability_systemd_red_hat.service.in index c556e1c8d..c7df95cc0 100644 --- a/scripts/blk_availability_systemd_red_hat.service.in +++ b/scripts/blk_availability_systemd_red_hat.service.in @@ -7,7 +7,6 @@ Conflicts=shutdown.target [Service] Type=oneshot -ExecStart=@bindir@/true ExecStop=@SBINDIR@/blkdeactivate -u -l wholevg -m disablequeueing -r wait RemainAfterExit=yes Thanks, Asher -- If you stand on your head, you will get footprints in your hair. I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#966816: lvm2: Patch to fix the problem
Asher Gordon writes: > It seems that this problem was present for quite a while, so I'm not > sure why I didn't notice it before. Ah, it's because the bug only came up after the new release (2.03.09-2). The bug lay dormant in 2.03.09-1. That's because '--bindir=/bin' was removed from debian/rules in commit 5df1ae4 in order to fix #929437. (That commit was between debian/2.03.09-1 and debian/2.03.09-2.) So that's why I didn't notice it before. Thanks, Asher -- If you stand on your head, you will get footprints in your hair. I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#966816: lvm2: Patch to fix the problem
Package: lvm2 Version: 2.03.09-2 Followup-For: Bug #966816 Dear Maintainer, I noticed this bug as well, when I was upgrading lvm2. Here is a patch to fix the problem: diff --git a/scripts/blk_availability_systemd_red_hat.service.in b/scripts/blk_availability_systemd_red_hat.service.in index c556e1c8d..c83f76a08 100644 --- a/scripts/blk_availability_systemd_red_hat.service.in +++ b/scripts/blk_availability_systemd_red_hat.service.in @@ -7,7 +7,7 @@ Conflicts=shutdown.target [Service] Type=oneshot -ExecStart=@bindir@/true +ExecStart=/bin/true ExecStop=@SBINDIR@/blkdeactivate -u -l wholevg -m disablequeueing -r wait RemainAfterExit=yes This could also be fixed by fully expanding $bindir in configure like $SBINDIR and some other variables, but the path to 'true' is independent on $bindir anyway, so I think using /bin/true is a better solution. (Also, I'm not even sure that $bindir _is_ /bin.) It seems that this problem was present for quite a while, so I'm not sure why I didn't notice it before. Thanks, Asher -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-2-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages lvm2 depends on: ii dmeventd 2:1.02.171-2 ii dmsetup 2:1.02.171-2 ii init-system-helpers 1.58 ii libaio1 0.3.112-8 ii libblkid1 2.36-2 ii libc6 2.31-2 ii libdevmapper-event1.02.1 2:1.02.171-2 ii libreadline5 5.2+dfsg-3+b13 ii libselinux1 3.1-2 ii libsystemd0 246-2 ii libudev1 246-2 ii lsb-base 11.1.0 Versions of packages lvm2 recommends: ii thin-provisioning-tools 0.8.5-4 lvm2 suggests no packages. -- no debconf information -- By necessity, by proclivity, and by delight, we all quote. In fact, it is as difficult to appropriate the thoughts of others as it is to invent. -- R. Emerson -- Quoted from a fortune cookie program (whose author claims, "Actually, stealing IS easier.") [to which I reply, "You think it's easy for me to misconstrue all these misquotations?!?" Ed.] I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#966648: eboard: Split zseal into a separate package
Package: eboard Version: 1.1.3-0.3 Severity: wishlist X-Debbugs-Cc: Asher Gordon Dear Maintainer, Currently, eboard ships with zseal (the timeseal implementation included with eboard) as /usr/share/games/eboard/timeseal.Linux. However, zseal is useful without eboard, for use with XBoard for example. So I think it would be better to split zseal into a separate package. Note that zseal is included in the upstream eboard distribution (https://github.com/fbergo/eboard) and it also has its own repository (https://github.com/fbergo/zseal). At the time of this writing, zseal.c in both repositories are effectively the same. I think it would be simplest to build a separate zseal binary package from the eboard source package. Then, the eboard binary package could Recommend zseal and install a symlink (or wrapper script to avoid dangling links) that points to the zseal binary in /usr/share/games/eboard/timeseal.Linux. Other chess clients (like XBoard) could then Recommend (or perhaps Suggest) zseal as well. Also, I think that a symlink should be installed in /usr/bin/timeseal that points to zseal, since timeseal is the more commonly known name. I think this should either be done by the zseal package itself, or a separate package, timeseal, that depends on zseal (and zseal could Recommend or Suggest timeseal). Personally, I think the second way is better, because users looking for the timeseal binary would find it in the timeseal package. Then maybe it would be better for chess clients to Recommend or Suggest the timeseal package, rather than zseal. I have limited experience with Debian package development, but I'll try to do some of this myself if I can find the time. Thanks, Asher -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages eboard depends on: ii libatk1.0-0 2.36.0-2 ii libc62.31-2 ii libcairo21.16.0-4 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.2+dfsg-3 ii libgcc-s1 [libgcc1] 10.1.0-6 ii libgdk-pixbuf2.0-0 2.40.0+dfsg-5 ii libglib2.0-0 2.64.4-1 ii libgstreamer1.0-01.16.2-2 ii libgtk2.0-0 2.24.32-4 ii libpango-1.0-0 1.44.7-4 ii libpangocairo-1.0-0 1.44.7-4 ii libpangoft2-1.0-01.44.7-4 ii libpng16-16 1.6.37-2 ii libstdc++6 10.1.0-6 ii zlib1g 1:1.2.11.dfsg-2 Versions of packages eboard recommends: ii xfonts-75dpi 1:1.0.4+nmu1 Versions of packages eboard suggests: ii gnuchess 6.2.5-1 -- no debconf information -- If for every rule there is an exception, then we have established that there is an exception to every rule. If we accept "For every rule there is an exception" as a rule, then we must concede that there may not be an exception after all, since the rule states that there is always the possibility of exception, and if we follow it to its logical end we must agree that there can be an exception to the rule that for every rule there is an exception. -- Bill Boquist I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#966468: util-linux: provide rename.ul again
Package: util-linux Version: 2.36-1 Severity: normal X-Debbugs-Cc: none, Asher Gordon Dear Maintainer, I realize that rename.ul was removed because of #926637, but I think that action was unnecessary. I believe the reporter of that bug wanted rename.ul to be installed as an alternative for rename. Although you provided a good reason for why this should not be done, I don't think that's a reason to remove rename.ul entirely. Personally, rename.ul was my rename of choice because of its simplicity, and I was disappointed to see it go. I would appreciate it if you would consider providing rename.ul in util-linux again. Also, if you'd rather not provide rename.ul in util-linux, you might consider building a separate binary package which provides rename.ul from the util-linux source package. Then you might have the util-linux binary package Suggest or Recommend rename.ul. Thanks, Asher -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.7.0-1-amd64 (SMP w/2 CPU threads) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages util-linux depends on: ii libaudit1 1:2.8.5-3+b1 ii libblkid1 2.36-1 ii libc6 2.31-1 ii libcap-ng0 0.7.9-2.2 ii libcrypt1 1:4.4.16-1 ii libmount1 2.36-1 ii libpam0g 1.3.1-5 ii libselinux13.1-2 ii libsmartcols1 2.36-1 ii libsystemd0245.6-2 ii libtinfo6 6.2-2 ii libudev1 245.6-2 ii libuuid1 2.36-1 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.1-2 ii kbd 2.0.4-4 ii util-linux-locales 2.36-1 -- no debconf information -- The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#964025: berusky2: New upstream release
Hi Markus, Markus Koschany writes: > Thank you. I have uploaded berusky2 a few minutes ago. Cool, thanks! > Tip for the future: You can just attach your compressed debian > diretory to the bug report or open a merge request on salsa.debian.org > and send a note to your bug report. If you create a patch for upstream > and debian files I can't apply it as is because of the > master/upstream/pristine-tar Git structure of our packages. There is > also a tool called debdiff which eases the creation of Debian patches. Thanks, good to know. > Have a nice weekend You too. Asher -- "It's my cookie file and if I come up with something that's lame and I like it, it goes in." -- karl (Karl Lehenbauer) I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#964263: linux-image-5.7.0-1-amd64: Switching from a graphical VT to a non-graphical one freezes display
Package: src:linux Version: 5.7.6-1 Severity: normal Dear Maintainer, When I switch from a VT running a graphical environment, specifically EXWM, to a VT running a plain old console with getty, the display freezes up. Switching from that VT to another one (graphical or console) unfreezes the display. The VT still recognizes my keypresses, but it still displays whatever was on the screen before I switched VTs. I use Ctrl+Alt+F[1-6] to switch VTs. Strangely enough, this doesn't happen all the time. Sometimes I can't make it happen even once, but sometimes it happens most of the time. I have observed the bug in both EXWM and i3, but I have yet to observe it in GNOME. I noticed this when I upgraded the kernel, and if I boot onto the old one (linux-image-amd64 5.6.14-2, linux-image-5.6.0-1-amd64 5.6.7-1), I am unable to cause the symptoms described. Also, if the non-graphical VT that I am switching to is not running getty, the symptoms do not appear. So if I run 'systemctl stop getty@tty3.service' and then run a graphical shell (using startx) in tty2, switching from tty2 to tty3 will not freeze the display. However, if I then switch from tty3 back to tty2 and then back to tty3 again, it will (maybe) freeze the display, since getty is now running in tty3. Note that I only stopped getty, I didn't actually deallocate the VT (using deallocvt). I suspect that stopping getty could have caused the VT to automatically deallocate itself. I have not observed this bug when switching from a graphical to graphical VT, from a non-graphical to non-graphical VT, or from a non-graphical to graphical VT. Only when switching from a graphical to non-graphical VT does the bug appear. Thanks, Asher -- Package-specific info: ** Version: Linux version 5.7.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 9.3.0 (Debian 9.3.0-14), GNU ld (GNU Binutils for Debian) 2.34) #1 SMP Debian 5.7.6-1 (2020-06-24) ** Command line: BOOT_IMAGE=/vmlinuz root=/dev/sda1 rw quiet splash ** Tainted: I (2048) * workaround for bug in platform firmware applied ** Kernel log: [6.336783] iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0) [6.338438] sd 0:0:0:0: Attached scsi generic sg0 type 0 [6.411428] systemd[1]: Created slice system-wacom\x2dinputattach.slice. [6.411776] systemd[1]: Condition check resulted in Dispatch Password Requests to Console Directory Watch being skipped. [6.411968] systemd[1]: Condition check resulted in FUSE Control File System being skipped. [6.412078] systemd[1]: Condition check resulted in Kernel Configuration File System being skipped. [6.412183] systemd[1]: Condition check resulted in Set Up Additional Binary Formats being skipped. [6.412228] systemd[1]: Condition check resulted in Rebuild Hardware Database being skipped. [6.412276] systemd[1]: Condition check resulted in Commit a transient machine-id on disk being skipped. [6.412309] systemd[1]: Condition check resulted in Platform Persistent Storage Archival being skipped. [6.428197] audit: type=1400 audit(1593880876.069:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-oopslash" pid=293 comm="apparmor_parser" [6.462107] cfg80211: Loading compiled-in X.509 certificates for regulatory database [6.462454] cfg80211: Loaded X.509 cert 'b...@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf' [6.462816] cfg80211: Loaded X.509 cert 'romain.per...@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328' [6.463157] cfg80211: Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7' [6.466353] platform regulatory.0: firmware: direct-loading firmware regulatory.db [6.466725] platform regulatory.0: firmware: direct-loading firmware regulatory.db.p7s [6.468314] snd_hda_codec_conexant hdaudioC0D0: CX20561 (Hermosa): BIOS auto-probing. [6.469853] audit: type=1400 audit(1593880876.109:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="libreoffice-xpdfimport" pid=305 comm="apparmor_parser" [6.485434] systemd[1]: Finished Load/Save Screen Backlight Brightness of backlight:intel_backlight. [6.493410] snd_hda_codec_conexant hdaudioC0D0: autoconfig for CX20561 (Hermosa): line_outs=1 (0x1a/0x0/0x0/0x0/0x0) type:speaker [6.493413] snd_hda_codec_conexant hdaudioC0D0:speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) [6.493415] snd_hda_codec_conexant hdaudioC0D0:hp_outs=2 (0x19/0x16/0x0/0x0/0x0) [6.493416] snd_hda_codec_conexant hdaudioC0D0:mono: mono_out=0x0 [6.493418] snd_hda_codec_conexant hdaudioC0D0:dig-out=0x1c/0x0 [6.493419] snd_hda_codec_conexant hdaudioC0D0:inputs: [6.493421] snd_hda_codec_conexant hdaudioC0D0: Mic=0x18 [6.493423] snd_hda_codec_conexant hdaudioC0D0: Internal Mic=0x1d [6.493424] snd_hda_codec_conexant hdaudioC0D0: Dock Mic=0x17 [6.530933] input: HDA Intel Mic as /devices/pci:00/:00:1b.0/sound/card0/input8 [6.531005] input: HDA Int
Bug#964025: berusky2: New upstream release
I just realized that readme-debian-mode added my name to README.Debian, because I removed an entry. You can change/remove that if you wish. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me sprea= d! I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#964025: berusky2: New upstream release
Package: berusky2 Version: 0.10+git20170630-5 Severity: normal Dear Maintainer, I have been doing some work on Berusky 2 and I am pleased to announce that we have released a new version, 0.12 (0.11 wasn't really an official release, but there were 0.11 packages on Fedora). This fixes #948760 as well as many other bugs (none of the other open Debian bugs, unfortunately), and adds some new features (and maybe some new bugs as well). After updating, you can drop the following patches: 944431-avoid-no-return-statement-in-function-returning-non-void.patch fix-crash-when-teleporting.patch fix-more-crashes.patch gcc-6-FTBFS.patch In fact, the only patches you shouldn't drop are data.patch and docs.patch since those are Debian-specific. The new release also makes many changes to the data, including replacing APAK files with directories and .bmp with .png. The new data tarball is available here: https://anakreon.cz/download/berusky2-data-0.12.tar.xz Also, Martin has decided that you should now use my repository for the upstream repository (not homepage). My repository is here: https://notabug.org/AsDaGo/berusky2 The current homepage URL in the Debian package does not point to the Berusky 2 page any more. Martin is trying to fix that, but I think the alternative URL is more descriptive, so you might want to switch to that anyway. Also, anakreon.cz now supports https, so you should use that as well. The new URL is as follows: https://anakreon.cz/berusky2.html Thanks, Asher -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.6.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages berusky2 depends on: ii berusky2-data 0.9-2 ii libalut01.1.0-6 ii libc6 2.30-8 ii libgcc-s1 [libgcc1] 10.1.0-4 ii libgl1 1.3.1-1 ii libglu1-mesa [libglu1] 9.0.1-1 ii libopenal1 1:1.19.1-1+b1 ii libsdl-image1.2 1.2.12-12 ii libsdl1.2debian 1.2.15+dfsg2-5 ii libstdc++6 10.1.0-4 ii libvorbisfile3 1.3.6-2 ii libx11-62:1.6.9-2+b1 ii zlib1g 1:1.2.11.dfsg-2 berusky2 recommends no packages. berusky2 suggests no packages. -- no debconf information -- If at first you don't succeed, redefine success. I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#954806: Wrong copyright years in attached tarball
Asher Gordon writes: > Since I was not able write a simpler program that triggers the bug, I > have attached the source tarball (mu.tar.gz). I copied the copyright notices in that tarball from another project and forgot to change the copyright years. It should really be 2020. (It probably makes no difference, but I just thought I'd clarify just in case.) Asher -- The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. I prefer to send and receive mail encrypted. Please send me your public key, and if you do not have my public key, please let me know. Thanks. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#954806: gcc-9: Optimizes away something it shouldn't
Package: gcc-9
Version: 9.3.0-3
Severity: normal
Dear Maintainer,
I am writing a general purpose convenience library called Mu (for
Miscellaneous Utilities). It includes an option parsing module intended
to be a replacement for getopt_long().
Options are defined in structures which include various information,
including an optional callback which will be called when the option is
found. The parse_opts() function has a flag `OPT_HELP' (or
`OPT_HELP_SHORT' or `OPT_HELP_LONG') which makes it automatically add a
'-h' and/or a '--help' option which calls a callback to print a usage
message.
The problem is, when the test program (test.c) is compiled with
optimization, the data fields (set at options.c:127-131) passed to the
callback are optimized out. This causes a segmentation fault and/or
error message when './test' is passed '-h' or '--help'. Note that when
the program is compiled without optimization, no memory errors are
reported when run under Valgrind (although memory errors *are* reported
when the program is compiled with optimization).
I thought that the problem may have been that I was casting the data
pointer to (void *), but I tried creating a test program to test that,
and that didn't seem to be the problem.
To compile the program with optimization, I ran:
$ make CC=gcc-9 CFLAGS='-Wall -O1' clean all
And without optimization:
$ make CC=gcc-9 CFLAGS='-Wall -O0' clean all
Note that the problem can be reproduced with GCC 10 also
(CC=gcc-10). Also note that no warnings are reported with -Wall, not
even with -O3. Three warnings are reported with -Werror, but I don't
think they are serious or relevant. Here they are, just in case
(compiled with -O3 to catch warnings it might not otherwise):
$ make CC=gcc-9 CFLAGS='-Wall -Wextra -O3' clean all
rm -f *.o test
gcc-9 -Wall -Wextra -O3 -c -o test.o test.c
gcc-9 -Wall -Wextra -O3 -c -o compat.o compat.c
gcc-9 -Wall -Wextra -O3 -c -o format.o format.c
format.c: In function ‘format_list’:
format.c:277:36: warning: comparison of integer expressions of different
signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
277 | if (width && size + char_width > width - *col) {
|^
In file included from format.c:34:
format.c:303:27: warning: comparison of integer expressions of different
signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
303 | assert(index + tab_width > width - *col);
| ^
format.c:314:19: warning: comparison of integer expressions of different
signedness: ‘size_t’ {aka ‘long unsigned int’} and ‘int’ [-Wsign-compare]
314 | assert(index + 1 > width - *col);
| ^
gcc-9 -Wall -Wextra -O3 -c -o io.o io.c
gcc-9 -Wall -Wextra -O3 -c -o options.o options.c
gcc-9 -Wall -Wextra -O3 -c -o safe.o safe.c
gcc-9 test.o compat.o format.o io.o options.o safe.o -o test
Also note that when compiled with Clang (CC=clang), even with -O3, the
program works as expected and no memory errors are reported by Valgrind.
Note that only the -O* and all the -O* options trigger the bug. I tried
manually passing all the -f* options which (according to the
documentation) are enabled by the various -O* options. However,
strangely, I could not reproduce the bug that way.
The following patch adds a nop() function to options.c that is used to
prevent the data fields from being optimized out. When this patch is
applied, the issue is no longer present, even when compiled with -O3
(with gcc-9 or gcc-10).
--- options.c~ 2020-03-23 14:23:08.625333110 -0400
+++ options.c 2020-03-23 14:23:17.841369826 -0400
@@ -81,6 +81,13 @@
static int free_opts(const char *, const OPTION *);
static int format_help_callback(void *, char *);
+static void nop(const void *data, ...) {
+ /* We have to do this so GCC doesn't optimize calls to us away. */
+ va_list ap;
+ va_start(ap, data);
+ va_end(ap);
+}
+
/*
* Parse options. Returns zero on success or nonzero on error, in
* which case an error message will be printed to `stderr'. The last
@@ -137,6 +144,7 @@
opt->callback_none = format_help_callback;
opt->data = &data;
opt->help = "print this help and exit";
+nop(data.prog_name, data.usage, data.desc, data.notes, data.options);
}
else {
/* This is slightly evil (casting it to a non-const), but we know
Since I was not able write a simpler program that triggers the bug, I
have attached the source tarball (mu.tar.gz). README.Bugs says that I
should provide the *.i files, so I have included them in the
tarball. Different .i files are produced under optimization, so I have
included the ones produced with '-O0 --save-temps'. I have also attached
a patch (nop_preprocessed.patch) that adds the nop() function to the
preprocessed options.i.
Here is the output of 'gcc-9 -v' and 'gcc-10 -v':
$ gcc-9 -v
Using b
Bug#949165: libpam-fprintd: Does not allow fingerprint authentication for 'login'
Package: libpam-fprintd Version: 0.9.0-1 Severity: important Dear Maintainer, When I login on the console (tty), it asks for a password rather than a fingerprint. This also happens if I type 'login' (as root) manually. However, only 'login' seems to be affected so far; 'sudo' still asks for a fingerprint as well as GDM. This looks like a bug in libpam-fprintd, but feel free to reassign if it's actually in a different package. Here is the contents of /etc/pam.d/common-auth: # # /etc/pam.d/common-auth - authentication settings common to all services # # This file is included from other service-specific PAM config files, # and should contain a list of the authentication modules that define # the central authentication scheme for use on the system # (e.g., /etc/shadow, LDAP, Kerberos, etc.). The default is to use the # traditional Unix authentication mechanisms. # # As of pam 1.0.1-6, this file is managed by pam-auth-update by default. # To take advantage of this, it is recommended that you configure any # local modules either before or after the default block, and use # pam-auth-update to manage selection of other modules. See # pam-auth-update(8) for details. # here are the per-package modules (the "Primary" block) auth[success=2 default=ignore] pam_fprintd.so max_tries=1 timeout=10 # debug auth[success=1 default=ignore] pam_unix.so nullok_secure try_first_pass # here's the fallback if no module succeeds authrequisite pam_deny.so # prime the stack with a positive return value if there isn't one already; # this avoids us returning an error just because nothing sets a success code # since the modules above will each just jump around authrequiredpam_permit.so # and here are more per-package modules (the "Additional" block) authoptionalpam_ecryptfs.so unwrap authoptionalpam_cap.so # end of pam-auth-update config As you can see, 'pam_fprintd.so' is listed before 'pam_unix.so'. I tried disabling and re-enabling fprintd with 'pam-auth-update', but it did not work. Note: this bug only appeared when I upgraded to 0.9.0-1. It was not present in 0.8.1-1+b1. Thanks, Asher -- He was part of my dream, of course -- but then I was part of his dream too. -- Lewis Carroll GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libpam-fprintd depends on: ii fprintd 0.9.0-1 ii libc6 2.29-7 ii libdbus-1-3 1.12.16-2 ii libdbus-glib-1-2 0.110-5 ii libglib2.0-0 2.62.4-1 ii libpam-runtime1.3.1-5 ii libpam0g 1.3.1-5 libpam-fprintd recommends no packages. libpam-fprintd suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#948760: berusky2: Compile without warnings
Hello Markus and Bernhard, Markus Koschany writes: > Am 13.01.20 um 22:26 schrieb Bernhard Übelacker: >> Hello Asher, >> maybe you want to incorporate the changes given here: >>https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944431#31 >> Unfortunately I was too late there. >> >> Then the call to e.g. SetThreadPriority would not needed to get >> commented out, and the "-O0" fix in #944431 could be removed >> again, I guess. > > I had incorporated and applied your patch and removed the -O0 fix again. > I haven't checked though how all this is related to Asher's patch. As Markus says, he's already added Bernhard's fixes. I've written my patch on top of those fixes. Markus Koschany writes: > thanks for the report. Have you considered to forward these patches > upstream and help upstream to implement them? I'm asking because a lot > of users won't benefit from bug fixes if they are only fixed in Debian. I've forked the upstream repository here[1] (because I don't want to use GitHub) and I've sent Martin Stransky an email to let him know. In my repository, I've added Markus's patch for GCC 6 and Bernhard's patch for the 'no return statement in function returning non-void' warning as well as my patches. I've added both of these as separate commits where I've credited you in the commit message. But if you like, I can change the Author to your name instead. Hopefully, these will be accepted upstream and we will be able to drop all patches except the Debian-specific ones (data.patch and docs.patch). Asher Footnotes: [1] https://notabug.org/AsDaGo/berusky2 -- If at first you don't succeed, redefine success. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#948760: berusky2: Compile without warnings
Package: berusky2
Version: 0.10+git20170630-3
Severity: normal
Tags: patch
Dear Maintainer,
Currently when Berusky2 is compiled it generates a *lot* of compile
warnings, some of which seem serious. I've fixed all these warnings and
have attached a patch (I've attached it as an attachment rather than
inline because it is quite large (3651 lines) and I don't want to
clutter up the bug report log).
I've set the severity to "normal" since there are so many warnings and I
suspect that my patch may fix some crashes. But feel free to downgrade
as you see fit.
Here is a short summary (not meant to be comprehensive) of the changes I
have made:
* Some functions (such as chdir() and getcwd()) warn if their return
values are not checked. I have added checks to all such functions
which did not already have checks.
* I've added a few assertions where needed to avoid warnings.
* I've changed many calls to sprintf() which may overflow to calls to
snprintf(). I also check the return value of the snprintf() call
since the output may be truncated.
* I've replaced the deprecated ALUT functions alutLoadWAVFile() and
alutUnloadWAV() with local implementations (s/alut/adas/).
* Apparently G++ doesn't like calls to memset() on a non-trivial type
(all of these were structs). So I've casted the pointer to (void *)
before passing it to memset(). Is there a better way to do this? I
don't know C++ very well (the warning said to "use assignment or
value-initialization instead").
* Numerous other miscellaneous fixes.
The coding style of Berusky2 is inconsistent, so I just tried to use the
local style in whatever file (or part of file!) I was editing.
I finally (sort of) figured out how to use quilt properly, and I've
added a DEP-3 compliant header to my patch. Please remember to update
the Bug-Debian (this bug), Reviewed-by (you), and Last-Update headers
before you add the patch.
Since Berusky2 now compiles without warnings, I recommend adding -Werror
to the C{,XX}FLAGS. I guess this would be done by adding it to
DEB_CXXFLAGS_MAINT_APPEND (like you did in 89e7190) and
DEB_CFLAGS_MAINT_APPEND.
I tested running Berusky2 periodically while writing the patch to make
sure that I didn't introduce any bugs. I also tested it after I finished
writing the patch. But I did not test very thoroughly (I just started it
and made a few moves in a level). However, the only part that seems
likely to introduce new bugs is the replacement of the deprecated ALUT
functions, and sound still works fine. So I'm pretty sure I didn't
introduce any new bugs.
I have attached the patch after the message.
Thanks,
Asher
--
...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning.
-- Matt Welsh
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages berusky2 depends on:
ii berusky2-data 0.9-2
ii libalut01.1.0-6
ii libc6 2.29-7
ii libgcc1 1:9.2.1-22
ii libgl1 1.1.0-1+b1
ii libglu1-mesa [libglu1] 9.0.1-1
ii libopenal1 1:1.19.1-1+b1
ii libsdl-image1.2 1.2.12-12
ii libsdl1.2debian 1.2.15+dfsg2-5
ii libstdc++6 9.2.1-22
ii libvorbisfile3 1.3.6-2
ii libx11-62:1.6.8-1
ii zlib1g 1:1.2.11.dfsg-1+b1
berusky2 recommends no packages.
berusky2 suggests no packages.
-- no debconf information
Description: Make Berusky2 compile cleanly with no warnings
Berusky2 used to generate a *lot* of warnings when compiled. Some of
these were not too serious, but some seemed like they could possibly
allow buffer overflows. This patch likely fixes many potential
crashes as well.
Author: Asher Gordon
Bug-Debian: TODO
Reviewed-by: TODO
Last-Update: 2020-01-12
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
Index: berusky2/src/adas/adas.c
===
--- berusky2.orig/src/adas/adas.c
+++ berusky2/src/adas/adas.c
@@ -214,7 +214,7 @@ void adas_Init(ADAS_INIT_DATA * p_adas_d
memcpy(&ADAS_data, p_adas_data, sizeof(ADAS_INIT_DATA));
- p_Device = alcOpenDevice((ALCubyte *) p_adas_data->Implementation);
+ p_Device = alcOpenDevice(p_adas_data->Imp
Bug#947870: berusky2: Fix crash when teleporting
Package: berusky2
Version: 0.10+git20170630-2
Severity: normal
Tags: patch
Dear Maintainer,
Berusky2 segfaults when a bug steps into a teleport. The issue is the
same as in #945107. Please see the following patch which fixes the bug:
diff --git a/src/kofola/animationk.h b/src/kofola/animationk.h
index 2101946..044d906 100644
--- a/src/kofola/animationk.h
+++ b/src/kofola/animationk.h
@@ -6,7 +6,7 @@
typedef struct
{
void *pParam;
- int iParam[2];
+ size_ptr iParam[2];
END_FUNKCE pProc;
int flag;
} ANIM_TRIGER;
Cheers,
Asher
--
By necessity, by proclivity, and by delight, we all quote. In fact, it is as
difficult to appropriate the thoughts of others as it is to invent.
-- R. Emerson
-- Quoted from a fortune cookie program
(whose author claims, "Actually, stealing IS easier.")
[to which I reply, "You think it's easy for me to
misconstrue all these misquotations?!?" Ed.]
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_WARN, TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages berusky2 depends on:
ii berusky2-data 0.9-2
ii libalut01.1.0-6
ii libc6 2.29-3
ii libgcc1 1:9.2.1-21
ii libgl1 1.1.0-1+b1
ii libglu1-mesa [libglu1] 9.0.1-1
ii libopenal1 1:1.19.1-1+b1
ii libsdl-image1.2 1.2.12-12
ii libsdl1.2debian 1.2.15+dfsg2-5
ii libstdc++6 9.2.1-21
ii libvorbisfile3 1.3.6-2
ii libx11-62:1.6.8-1
ii zlib1g 1:1.2.11.dfsg-1+b1
berusky2 recommends no packages.
berusky2 suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#947222: rain: Default delay is in wrong units, making it effectively 0
Package: bsdgames
Version: 2.17-28
Severity: normal
Tags: patch
Dear Maintainer,
In bsdgames 2.17.20, #579062[1] was supposedly fixed. However, `delay'
is passed to usleep()[2]. Since the "fix" changed the default value of
`delay' to 120, that makes the default delay 120 *micro*seconds instead
of 120 *milli*seconds, making it practically the same as 0. Note that
when "-d" is parsed, the integer argument is multiplied by 1000 before
being used for the delay.
The default delay should be 12, not 120. See the following patch
(apply with 'patch -p0 < fix-delay.patch'):
--- rain/rain.c~ 2018-10-13 20:05:55.0 -0400
+++ rain/rain.c 2019-12-22 23:41:11.723230711 -0500
@@ -70,7 +70,7 @@
{
int x, y, j;
long cols, lines;
- unsigned int delay = 120;
+ unsigned int delay = 12;
unsigned long val = 0;
int ch;
char *ep;
Suggestion: Include this in
0005-rain-Update-default-delay.-Closes-579062.patch rather than creating
a new patch.
See also: #723808
Thanks,
Asher
Footnotes:
[1] Which suggests that the default delay should be changed to 120
milliseconds.
[2] Which has not been in POSIX since POSIX.1-2008 and has been
obsolete since POSIX.1-2001. But that is a different issue.
--
By necessity, by proclivity, and by delight, we all quote. In fact, it is as
difficult to appropriate the thoughts of others as it is to invent.
-- R. Emerson
-- Quoted from a fortune cookie program
(whose author claims, "Actually, stealing IS easier.")
[to which I reply, "You think it's easy for me to
misconstrue all these misquotations?!?" Ed.]
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
-- System Information:
Debian Release: bullseye/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.3.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages bsdgames depends on:
ii libc62.29-3
ii libfl2 2.6.4-6.2
ii libgcc1 1:9.2.1-21
ii libncurses6 6.1+20191019-1
ii libstdc++6 9.2.1-21
ii libtinfo66.1+20191019-1
ii wamerican [wordlist] 2018.04.16-1
ii wamerican-insane [wordlist] 2018.04.16-1
ii wbritish [wordlist] 2018.04.16-1
bsdgames recommends no packages.
bsdgames suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#930128: tint: Error creating /var/games/tint.scores
Package: tint Version: 0.05+b1 Followup-For: Bug #930128 Hi, I've looked into this a bit more, and I've found commit a05fa0e30c (in the Debian git repository [1]). This commit references #769296, which I will now quote: Ernest Adrogué writes: > As long as the player is in group "games" making tint.scores > group-writeable should be enough to fix the problem. No need to setgid > the tint executable. The maintainer (Ricardo Mones) documented this solution in /usr/share/doc/tint/README.Debian. However, I think this solution is inferior to making the binary setgid "games" for a couple reasons: a) Most games in Debian use the setgid method. I don't see why TINT should be any different. b) If a user is part of the "games" group, that user may tamper with the score file. If the binary is setgid "games", users may only write to the score file through TINT itself. Looking at the moon buggy package, I believe the following patch should make the binary setgid "games" (I tested it out on my machine and it works): From 085c8eb8e021c271c1c57311decc638d53276459 Mon Sep 17 00:00:00 2001 From: Asher Gordon Date: Mon, 9 Dec 2019 19:13:37 -0500 Subject: [PATCH] Install binary as setgid games. Users now no longer have to be part of the group "games" to save highscores. Also remove README.Debian since it is no longer relevant. --- debian/README.Debian | 12 debian/rules | 13 + 2 files changed, 13 insertions(+), 12 deletions(-) delete mode 100644 debian/README.Debian diff --git a/debian/README.Debian b/debian/README.Debian deleted file mode 100644 index 2ccdf2b..000 --- a/debian/README.Debian +++ /dev/null @@ -1,12 +0,0 @@ - -TINT Is Not Tetris for Debian -- - - Users which are allowed to update the scores file must be added to the - "games" group, otherwise an error message is printed after entering - your name: "Error creating /var/games/tint.scores" - - Simplest method is running "adduser games" as root. User - session must also be restarted to make this change effective. - - -- Ricardo Mones Sat, 26 Jan 2019 13:59:03 +0100 diff --git a/debian/rules b/debian/rules index 2d33f6a..45e9016 100755 --- a/debian/rules +++ b/debian/rules @@ -1,4 +1,17 @@ #!/usr/bin/make -f +PACKAGE = tint + +# setgid games to access highscore files +INSTALL_GAME = install -p -o root -g games -m 2755 + %: dh $@ + +override_dh_install: + dh_install -X usr/games/$(PACKAGE) + # setgid games + $(INSTALL_GAME) $(PACKAGE) debian/$(PACKAGE)/usr/games/ + +override_dh_fixperms: + dh_fixperms -X usr/games/$(PACKAGE) -- 2.24.0 Note that I have also removed README.Debian in the above patch because it is no longer relevant. Thanks, Asher P.S. I am going to attempt to add a patch tag to this bug (since I added a patch), but I don't know if I have permission to do so, so it may not work (I've never tried before). Footnotes: [1] https://salsa.debian.org/games-team/tint.git -- : The following (relative to AutoSplit 1.03) attempts to please everyone : and perhaps pleases no one: I think that's way cool. -- Larry Wall in <199709292015.naa09...@wall.org> GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#930128: tint: Error creating /var/games/tint.scores
Package: tint Version: 0.05+b1 Followup-For: Bug #930128 Hi Mark, Mark Van den Borre writes: > May I suggest updating the default high scores file to the user's home > directory? A better solution would be to have /usr/games/tint binary be owned by the group "games" and set the set-group-ID bit. This would allow it to write /var/games/tint.scores since that file is writable by the "games" group. This solution is better than having the high scores file in the user's home directory, because this way if multiple users are playing, they can each see each others high scores. In fact, many games in Debian do this already (take moon-buggy for example). You can work around this bug by changing the group and set-group-ID bit yourself: $ su Password: # chown root:games /usr/games/tint # chmod g+s /usr/games/tint # exit $ ls -l /usr/games/tint -rwxr-sr-x 1 root games 27032 Aug 7 04:48 /usr/games/tint* $ tint Choose a level to start [1-9]: 1 PLAYER STATISTICS Score 186 Efficiency -1 Score ratio 8 Congratulations! You have a new high score. Enter your name [asher]: Asher TINT HIGH SCORES Rank ScoreName 1* 186Asher Hopefully you get a better score than I did, but as you can see, it did save the score. By the way: I played TINT a while ago, and I'm pretty sure this bug wasn't present then (most likely someone accidentally removed the set-group-ID bit from the package since then). Also, in my opinion, the severity of this bug should be important or even serious since saving high scores are a big part of the game. But I'll leave that up to the Maintainers to decide. Asher -- It's better to be quotable than to be honest. -- Tom Stoppard GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages tint depends on: ii libc62.29-3 ii libncurses6 6.1+20191019-1 ii libtinfo66.1+20191019-1 tint recommends no packages. tint suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#914702: ghci: The 'impossible' happens when running ":print length"
Dear Maintainer, Sorry, I meant to open a new bug report instead of replying to this one. Originally, I was going to reply to this one, but decided that my bug was different enough to justify a new report. So I removed the Followup-For pseudo-header, but I forgot to change the address. Should I create a new report now or just leave it as is? Sorry for the inconvenience! Asher -- Only fools are quoted. -- Anonymous GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#946102: ghc: Please add unregisterised binary package
Package: ghc Version: 8.8.1+dfsg2-1~exp1 Severity: wishlist Dear Maintainer, The GHC packaged with Debian is registerised (or "not unregisterised"?), meaning that it cannot compile to C code (with the -C option). While being unregisterised is usually good (generates faster code), it is sometimes useful to generate C code. For example, to examine how Haskell programs work if you know C but are learning Haskell (my situation) or if you just want to understand Haskell better. It could also be useful for cross compilation and maybe other things too. My suggestion is to build a new binary package (from the same source package) called "ghc-unregisterised". Then you could have "/usr/bin/ghc-unregisterised" so as not to conflict with the regular ghc package. Maybe even use update-alternatives. You would also have to rename "/usr/lib/ghc" to "/usr/lib/ghc-unregisterised". Thanks, Asher -- Reader, suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself. -- Mark Twain GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ghc depends on: ii dpkg 1.19.7 ii gcc 4:9.2.1-3.1 ii libbsd-dev0.10.0-1 ii libc6 2.29-3 ii libc6-dev 2.29-3 ii libffi-dev3.2.1-9 ii libffi6 3.2.1-9 ii libgmp-dev2:6.1.2+dfsg-4 ii libgmp10 2:6.1.2+dfsg-4 ii libncurses-dev [libncurses5-dev] 6.1+20191019-1 ii libncurses5-dev 6.1+20191019-1 ii libtinfo6 6.1+20191019-1 ghc recommends no packages. Versions of packages ghc suggests: it ghc-doc 8.8.1+dfsg1+is+8.6.5+dfsg1-2 pn ghc-prof ii haskell-doc 20061128 ii llvm-7 1:7.0.1-9+b2 ii perl 5.30.0-9 -- no debconf information signature.asc Description: PGP signature
Bug#914702: ghci: The 'impossible' happens when running ":print length"
Package: ghc
Version: 8.8.1+dfsg2-1~exp1
Dear Maintainer,
When ":print length" is run at the GHCi prompt, the 'impossible'
happens:
$ ghci
GHCi, version 8.8.1: https://www.haskell.org/ghc/ :? for help
Prelude> :print length
ghc: panic! (the 'impossible' happened)
(GHC version 8.8.1 for x86_64-unknown-linux):
isUnliftedType
t1_a1w0[rt] :: TYPE t0_a1vZ[rt]
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1159:37 in
ghc:Outputable
pprPanic, called at compiler/types/Type.hs:2278:10 in ghc:Type
Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug
This does not happen with all functions. In fact, length is the only
function I have found so far that does this. If I define my own version
of length, len, this bug does not appear:
Prelude> :{
Prelude| len l = case l of
Prelude| [] -> 0
Prelude| (x:xs) -> 1 + len xs
Prelude| :}
Prelude> :print len
len = (_t1::Num p => [a] -> p)
So, maybe length is defined in C code in the compiler rather than an
actual Haskell function, and that is what triggers the bug?
I've also tested this in version ghc_8.8.1+dfsg1+is+8.6.5+dfsg1-2 (the
current latest in testing) with the same results.
Related: #914702 (however, that bug seems to be fixed in both the
versions I tried).
Thanks,
Asher
--
Steal this tagline. I did.
GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.3.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages ghc depends on:
ii dpkg 1.19.7
ii gcc 4:9.2.1-3.1
ii libbsd-dev0.10.0-1
ii libc6 2.29-3
ii libc6-dev 2.29-3
ii libffi-dev3.2.1-9
ii libffi6 3.2.1-9
ii libgmp-dev2:6.1.2+dfsg-4
ii libgmp10 2:6.1.2+dfsg-4
ii libncurses-dev [libncurses5-dev] 6.1+20191019-1
ii libncurses5-dev 6.1+20191019-1
ii libtinfo6 6.1+20191019-1
ghc recommends no packages.
Versions of packages ghc suggests:
it ghc-doc 8.8.1+dfsg1+is+8.6.5+dfsg1-2
pn ghc-prof
ii haskell-doc 20061128
ii llvm-7 1:7.0.1-9+b2
ii perl 5.30.0-9
-- no debconf information
signature.asc
Description: PGP signature
Bug#945107: Fix some more crashes
Dear Maintainer, I have written a patch to fix some more crashes. This has not been fixed upstream (although it is the same issue; storing a pointer in an integer type too small to store a pointer). Here is the patch: Index: berusky2-0.10/src/komat/Berusky3d_castice.h === --- berusky2-0.10.orig/src/komat/Berusky3d_castice.h +++ berusky2-0.10/src/komat/Berusky3d_castice.h @@ -195,8 +195,8 @@ typedef struct _PARMETAC GLMATRIX world; // transfromacni matice void *p_param; - int param; - int param2; + size_ptr param; + size_ptr param2; END_FUNKCE p_endfce; // kofolova end funkce struct _PARMETAC *p_next; Thanks, Asher -- If at first you don't succeed, redefine success. GPG fingerprint: 38F3 975C D173 4037 B397 8095 D4C9 C4FC 5460 8E68 signature.asc Description: PGP signature
Bug#945107: berusky2: Segmentation fault in animation module
Package: berusky2 Version: 0.10-8 Severity: important Tags: patch Dear Maintainer, Certain animations (such as pushing a block over a ledge) cause berusky2 to crash. This has been fixed upstream in commit 97ed81c (the bug is due to trying to store a pointer in an integer type too small to store a pointer). For your convenience, here is a patch from that commit (created with `git format-patch 97ed^..97ed'): From 97ed81cc7fd48c4955d15efd5a341d6af4e96759 Mon Sep 17 00:00:00 2001 From: Martin Stransky Date: Sun, 3 Jan 2016 15:28:37 +0100 Subject: [PATCH] Fixed crashes in animation module --- src/komat/Berusky3d.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/komat/Berusky3d.h b/src/komat/Berusky3d.h index 2b8bcc4..aef18c7 100644 --- a/src/komat/Berusky3d.h +++ b/src/komat/Berusky3d.h @@ -181,8 +181,8 @@ typedef struct _GLOBALNI_KONT_ANIMACE int *p_flag; // kofoluv flag void *p_param;// kofolova end funkce - int param; - int param2; + size_ptr param; + size_ptr param2; END_FUNKCE p_endfce; int konec; -- 2.24.0 You can import the patch into quilt with quilt import Fixed-crashes-in-animation-module.patch In addition, upstream commit df8d2a4 claims to fix crashes in the particle engine (I haven't noticed these crashes yet). Also, since upstream hasn't made a release in a while, maybe it would be a good idea to update the Debian package against the latest upstream commit. Thanks, Asher -- : The following (relative to AutoSplit 1.03) attempts to please everyone : and perhaps pleases no one: I think that's way cool. -- Larry Wall in <199709292015.naa09...@wall.org> -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages berusky2 depends on: ii berusky2-data 0.9-2 ii libalut01.1.0-6 ii libc6 2.29-3 ii libgcc1 1:9.2.1-19 ii libgl1 1.1.0-1+b1 ii libglu1-mesa [libglu1] 9.0.0-2.1+b3 ii libopenal1 1:1.19.1-1+b1 ii libsdl-image1.2 1.2.12-12 ii libsdl1.2debian 1.2.15+dfsg2-5 ii libstdc++6 9.2.1-19 ii libvorbisfile3 1.3.6-2 ii libx11-62:1.6.8-1 ii zlib1g 1:1.2.11.dfsg-1+b1 berusky2 recommends no packages. berusky2 suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#944483: moon-lander: consider remaining fuel when a bonus ship is given
Package: moon-lander
Version: 1:1.0-7
Severity: normal
Tags: patch
Dear Maintainer,
When a player reaches 1 points, a bonus ship is supposed to be
given. However, if the player is currently at, say, 8000 points and
lands on an 1800 point pad but has 300 fuel left, the score will then be
8000 + 1800 + 300 = 10100, which is greater than 1 but no bonus ship
will be given.
This is because the new score is calculated considering the remaining
fuel (a feature added by Debian in 20_fix-score.patch), but the bonus
ship does not consider the remaining fuel. Please see the following
patch for a simple fix:
Description: Fix bonus ship calculation to account for remaining fuel.
Author: Asher Gordon
---
This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
--- moon-lander-1.0.orig/moon_lander.c
+++ moon-lander-1.0/moon_lander.c
@@ -1686,7 +1686,7 @@ void gameloop(Game *game){
// Bonus ship every 1 points
if( (game->score / 1) <
- ((game->score + game->current_level.landing_score[count]) / 1 ) ) {
+ ((game->score + game->current_level.landing_score[count] + game->fuel) / 1 ) ) {
// (MLH) This would be a good place to play a sound
game->landing_pad = count;
To reproduce this bug, follow these steps:
Compile for easier debugging (you'll be using this value for CFLAGS
again, so put it in the environment):
$ export CFLAGS="$(sdl-config --cflags) -O0 -ggdb3"
$ make clean all
[...]
Now run it under GDB (or your favorite front-end):
$ gdb moon-lander
[...]
(gdb) run
[...]
Go to the moon-lander window, and start a new game with and pause
it immediately after it starts with P. Now go back to GDB, and type
^C. Then go up until you reach the bottom most frame in moon-lander (not
libSDL).
^C
Thread 1 "moon-lander" received signal SIGINT, Interrupt.
0x77f0dd97 in ?? () from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
(gdb) up
#1 0x77f02470 in ?? ()
from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
(gdb)
#2 0x77f16b46 in SDL_LowerBlit ()
from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
(gdb)
#3 0x77f18812 in SDL_Flip ()
from /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0
(gdb)
#4 0xa928 in gameloop (game=0x7fffdc00)
at moon_lander.c:1733
1733SDL_Flip(game->screen);
Now set the fuel to some huge value so that your new score will be
greater than 1 because of the fuel left:
(gdb) call game->fuel = 15000
$1 = 15000
(gdb) cont
Continuing.
Go back to the moon-lander window, unpause the game (with P again), and
land on a pad (you can cheat with GDB if you're really bad at this
game). Your new score should be greater than 1, but you will not get
a bonus ship.
This can happen in real life (i.e. without GDB) and you won't get a
bonus ship until 2 points (and even then you might not). If you
repeat the steps above with my patch applied (and don't forget to
recompile--that's why you exported CFLAGS), you will find that it will
give you a bonus ship.
Thanks,
Asher
--
If at first you don't succeed, redefine success.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages moon-lander depends on:
ii libc6 2.29-2
ii libsdl-image1.2 1.2.12-12
ii libsdl-mixer1.2 1.2.12-16
ii libsdl1.2debian 1.2.15+dfsg2-5
ii moon-lander-data 1:1.0-7
moon-lander recommends no packages.
moon-lander suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#942552: gdb: please link with GNU source-highlight
Package: gdb Version: 8.3.1-1 Severity: wishlist Dear Maintainer, Gdb has supporting linking with GNU source-highlight since version 8.3 (released on May 11th). GNU source-highlight is already included in Debian (libsource-highlight4v5 and libsource-highlight-dev), so it shouldn't be too hard to link against source-highlight in the Debian package of gdb. Linking with source-highlight provides syntax highlighting in gdb's TUI. Thanks, Asher -- Steal this tagline. I did. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gdb depends on: ii libbabeltrace1 1.5.7-1 ii libc6 2.29-2 ii libexpat1 2.2.9-1 ii libgcc1 1:9.2.1-8 ii libipt2 2.0.1-1+b1 ii liblzma55.2.4-1+b1 ii libncursesw66.1+20190803-1 ii libpython3.73.7.5~rc1-2 ii libreadline88.0-3 ii libstdc++6 9.2.1-8 ii libtinfo6 6.1+20190803-1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages gdb recommends: ii libc6-dbg [libc-dbg] 2.29-2 Versions of packages gdb suggests: ii gdb-doc8.2.1-1 pn gdbserver -- no debconf information signature.asc Description: PGP signature
Bug#942227: fish: "unreachable" state reached when redirecting to/from an unopenable file with `exec'
Hi David, David Adam writes: > I am pleased to report that this problem is fixed in the upcoming 3.1.0 > release: > > https://github.com/fish-shell/fish-shell/pull/5643 Great! I can confirm that the bug is no longer present in the latest upstream git (currently commit g82eca4bc). Thanks, Asher -- The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. signature.asc Description: PGP signature
Bug#942227: fish: "unreachable" state reached when redirecting to/from an unopenable file with `exec'
Package: fish Version: 3.0.2-2 Severity: normal Tags: upstream Dear Maintainer, I was running a program under GDB, and I needed to have it read from a file which it is not permitted to read. So I typed (gdb) run < /dev/mem GDB ran fish (since that is my $SHELL) to execute my program. But fish was terminated by SIGABRT with the following stacktrace: An error occurred while redirecting file '/dev/mem' open: Permission denied fish: src/exec.cpp:1032: failed assertion: this should be unreachable fish: Backtrace: fish: 0 /usr/bin/fish(+0xb16e7) [0x556056e7] fish: 1 parse_execution_context_t::run_1_job(tnode_t, block_t const*) + 2101 fish: 2 parse_execution_context_t::run_job_conjunction(tnode_t, block_t const*) + 196 fish: 3 parse_execution_result_t parse_execution_context_t::run_job_list(tnode_t, block_t const*) + 281 fish: 4 parse_execution_context_t::eval_node(tnode_t, block_t const*, io_chain_t const&) + 1380 fish: 5 int parser_t::eval_node(std::shared_ptr, tnode_t, io_chain_t const&, block_type_t, std::shared_ptr) + 777 fish: 6 parser_t::eval(std::shared_ptr, io_chain_t const&, block_type_t) + 176 fish: 7 parser_t::eval(std::__cxx11::basic_string, std::allocator >, io_chain_t const&, block_type_t) + 225 fish: 8 run_command_list(std::vector, std::allocator >, std::allocator, std::allocator > > >*, io_chain_t const&) + 147 fish: 9 main + 2200 fish: 10 __libc_start_main + 235 fish: 11 _start + 42 The first two lines are expected, but it then aborts because it reached an "unreachable" state (how embarrassing!) At first I thought that the problem was being run by GDB, but it is actually `exec' that is the problem. For example: $ fish -c 'exec cat < /dev/mem' An error occurred while redirecting file '/dev/mem' open: Permission denied fish: src/exec.cpp:1032: failed assertion: this should be unreachable fish: Backtrace: [...] Note the `exec' and the `<'. Without the `<', `cat' tries to open /dev/mem, not `fish', so the bug does not appear. This is not only specific to /dev/mem or special files. It can be any unreadable file, for example /etc/shadow. It can even be a file that does not exist. (Just remember to look for a file that does not exist outside of your home directory, since you are sure to have created every possible filename in your home directory if you are anything like me (actually, I usually just shove it under ~/misc these days).) Each time, it aborts in src/exec.cpp:1032. Fish should of course exit with an error, but it should not reach an "unreachable" state. This also happens if you redirect *to* an unwritable file even if it is readable (such as /etc/passwd). Also note that without the `exec', the bug does not appear: $ fish -c 'cat < /dev/mem' An error occurred while redirecting file '/dev/mem' open: Permission denied This looks like an upstream bug (hence the "upstream" tag), but I'm not sure because I haven't tried it with upstream fish yet. I'll send another message with my findings if I do get around to trying it with upstream. Thanks, Asher -- A witty saying proves nothing, but saying something pointless gets people's attention. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-3-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fish depends on: ii bc 1.07.1-2+b2 ii dpkg1.19.7 ii elinks [www-browser]0.13~20190125-4 ii epiphany-browser [www-browser] 3.32.1.2-3 ii firefox-esr [www-browser] 60.8.0esr-1 ii fish-common 3.0.2-2 ii libc6 2.29-2 ii libgcc1 1:9.2.1-8 ii libncurses6 6.1+20190803-1 ii libpcre2-32-0 10.32-5+b1 ii libstdc++6 9.2.1-8 ii libtinfo6 6.1+20190803-1 ii links2 [www-browser]2.20.2-1 ii lynx [www-browser] 2.9.0dev.4-1 ii man-db 2.8.7-3 ii netrik [www-browser]1.16.1-2+b2 ii python3 3.7.5-1 ii w3m [www-browser] 0.5.3-37+b1 Versions of packages fish recommends: ii xsel 1.2.0+git9bfc13d.20180109-3 Versions of packages fish suggests: pn doc-base -- no debconf information signature.asc Description: PGP signature
Bug#940516: valgrind: ONLY uses /usr/lib/$(arch)-linux-gnu/default.supp by default
Package: valgrind
Version: 1:3.15.0-1
Followup-For: Bug #940516
Hello,
I have updated the patch to include changes to the documentation. Please
see upstream #93376 [1] for the new patch and further updates.
I think there is a good chance that upstream will accept the patch, so
Debian should just wait until (if) that happens. And when (if) they
accept the patch and release version 3.16.0, Debian should also add
VG_(add_suppression_file)("/usr/local/lib/valgrind");
VG_(add_suppression_file)("/usr/lib/valgrind");
after
VG_(add_suppression_file)(VG_(libdir));
in coregrind/m_main.c like I mentioned before.
Asher
[1] https://bugs.kde.org/show_bug.cgi?id=93376
--
If at first you don't succeed, redefine success.
signature.asc
Description: PGP signature
Bug#940516: Created patch
Package: valgrind
Version: 1:3.15.0-1
Followup-For: Bug #940516
Dear Maintainer,
Also, my patch only adds VG_(libdir) as the default suppression
directory (I guess that would be /usr/lib/$(arch)-linux-gnu/valgrind on
Debian). To add other directories, just call
VG_(add_suppression_file)() after the
line which has
VG_(add_suppression_file)(VG_(libdir));
in coregrind/m_main.c.
It would be nice to load by default /usr{,/local}/lib/valgrind as well,
but I think that should be done in the Debian package, not upstream.
Thanks,
Asher
--
...very few phenomena can pull someone out of Deep Hack Mode, with two
noted exceptions: being struck by lightning, or worse, your *computer*
being struck by lightning.
-- Matt Welsh
signature.asc
Description: PGP signature
Bug#940516: Created patch
Package: valgrind
Version: 1:3.15.0-1
Followup-For: Bug #940516
Dear Maintainer,
The patch email didn't seem to work properly. Some of the headers are
part of the message somehow. I'm still new to Git, so I guess I didn't
send it properly (Gnus did mention something about fixing the headers or
something like that). Should've used git send-email I guess... Anyway,
I'll just attach the patch to this message below.
From 8b3719c3a8eb16802c58b1625c6551987def0477 Mon Sep 17 00:00:00 2001
From: Asher Gordon
Date: Thu, 19 Sep 2019 20:11:46 -0400
Subject: [PATCH] Allow loading suppression directories recursively.
To: Debian Bug Tracking System <940...@bugs.debian.org>
Also, load the $prefix/lib/valgrind directory recursively by default
instead of $prefix/lib/valgrind/default.supp.
Fixes 93376.
---
NEWS| 5 +++
coregrind/m_errormgr.c | 80 +++--
coregrind/m_libcfile.c | 5 +++
coregrind/m_main.c | 7 +---
include/pub_tool_libcfile.h | 8
5 files changed, 95 insertions(+), 10 deletions(-)
diff --git a/NEWS b/NEWS
index 2fde3c7cd..fe696c060 100644
--- a/NEWS
+++ b/NEWS
@@ -25,6 +25,10 @@ support for X86/macOS 10.13 and AMD64/macOS 10.13.
Your program can also change the dynamically changeable options using
the client request VALGRIND_CLO_CHANGE(option).
+* Directories are now loaded recursively when passed to
+ --suppressions. A default directory, $prefix/lib/valgrind is loaded
+ by default instead of $prefix/lib/valgrind/default.supp.
+
* TOOL CHANGES
* DHAT:
@@ -62,6 +66,7 @@ To see details of a given bug, visit
https://bugs.kde.org/show_bug.cgi?id=XX
where XX is the bug number as listed below.
+93376 Suppressions directory
400593 In Coregrind, use statx for some internal syscalls if [f]stat[64] fail
406561 mcinfcallWSRU gdbserver_test fails on ppc64
406824 Unsupported baseline
diff --git a/coregrind/m_errormgr.c b/coregrind/m_errormgr.c
index 52505ba5b..2b01a2f21 100644
--- a/coregrind/m_errormgr.c
+++ b/coregrind/m_errormgr.c
@@ -1481,10 +1481,82 @@ static void load_one_suppressions_file ( Int clo_suppressions_i )
void VG_(add_suppression_file)(const HChar *filename)
{
- HChar *f = VG_(strdup)("errormgr.addsup", filename);
- VG_(addToXA)(VG_(clo_suppressions), &f);
- if (load_suppressions_called)
- load_one_suppressions_file( VG_(sizeXA)(VG_(clo_suppressions)) - 1 );
+ // Check if it's a directory.
+ if (VG_(is_dir)( filename )) {
+ SysRes sres;
+ Int fd;
+
+ // Open the directory.
+ sres = VG_(open)( filename, VKI_O_RDONLY, 0 );
+ if (sr_isError(sres)) {
+ if (VG_(clo_xml))
+VG_(printf_xml)("\n");
+ VG_(umsg)("FATAL: can't open suppressions directory \"%s\"\n", filename );
+ VG_(exit)(1);
+ }
+ fd = sr_Res(sres);
+
+ // Read each entry and add it recursively.
+ while (True) {
+ Int nRead, pos = 0;
+ HChar buf[1024];
+
+ sres = VG_(getdents)( fd, (struct vg_dirent *)buf, sizeof(buf) );
+ if (sr_isError(sres)) {
+if (VG_(clo_xml))
+ VG_(printf_xml)("\n");
+VG_(umsg)("FATAL: can't read suppressions directory \"%s\"\n", filename );
+VG_(exit)(1);
+ }
+ nRead = sr_Res(sres);
+
+ vg_assert(nRead >= 0);
+
+ if (nRead == 0) {
+// We're at the end of the directory.
+break;
+ }
+
+ // Add the entries.
+ while (pos < nRead) {
+struct vg_dirent *entry = (struct vg_dirent *)(buf + pos);
+HChar *fullpath;
+SizeT nameSize = VG_(strlen)(entry->name);
+
+// Skip dotfiles and files which don't end in ".supp".
+if (entry->name[0] == '.' || nameSize < 5 ||
+!VG_STREQ(entry->name + nameSize - 5, ".supp")) {
+ pos += entry->reclen;
+ continue;
+}
+
+// Get the full path including the directory name.
+fullpath = VG_(malloc)("errormgr.addsup",
+ VG_(strlen)(filename) +
+ VG_(strlen)(entry->name) + 2);
+VG_(strcpy)(fullpath, filename);
+VG_(strcat)(fullpath, "/");
+VG_(strcat)(fullpath, entry->name);
+
+// Add the entry.
+VG_(add_suppression_file)( fullpath );
+
+VG_(free)(fullpath);
+
+// Go to the next entry.
+pos += entry->reclen;
+ }
+ }
+
+ VG_(close)(fd);
+ }
+ else {
+ // It's not a directory.
+ HChar *f = VG_(strdup)("errormgr.addsup", filename);
+
Bug#940516: [PATCH] Allow loading suppression directories recursively.
Message-ID: <87ef0bsrre@posteo.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
micalg=pgp-sha256; protocol="application/pgp-signature"
--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Also, load the $prefix/lib/valgrind directory recursively by default
instead of $prefix/lib/valgrind/default.supp.
Fixes 93376.
=2D--
NEWS| 5 +++
coregrind/m_errormgr.c | 80 +++--
coregrind/m_libcfile.c | 5 +++
coregrind/m_main.c | 7 +---
include/pub_tool_libcfile.h | 8
5 files changed, 95 insertions(+), 10 deletions(-)
diff --git a/NEWS b/NEWS
index 2fde3c7cd..fe696c060 100644
=2D-- a/NEWS
+++ b/NEWS
@@ -25,6 +25,10 @@ support for X86/macOS 10.13 and AMD64/macOS 10.13.
Your program can also change the dynamically changeable options using
the client request VALGRIND_CLO_CHANGE(option).
=20
+* Directories are now loaded recursively when passed to
+ --suppressions. A default directory, $prefix/lib/valgrind is loaded
+ by default instead of $prefix/lib/valgrind/default.supp.
+
* =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D TOOL CHANGE=
S =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
=20
* DHAT:
@@ -62,6 +66,7 @@ To see details of a given bug, visit
https://bugs.kde.org/show_bug.cgi?id=3DXX
where XX is the bug number as listed below.
=20
+93376 Suppressions directory
400593 In Coregrind, use statx for some internal syscalls if [f]stat[64] =
fail
406561 mcinfcallWSRU gdbserver_test fails on ppc64
406824 Unsupported baseline
diff --git a/coregrind/m_errormgr.c b/coregrind/m_errormgr.c
index 52505ba5b..2b01a2f21 100644
=2D-- a/coregrind/m_errormgr.c
+++ b/coregrind/m_errormgr.c
@@ -1481,10 +1481,82 @@ static void load_one_suppressions_file ( Int clo_su=
ppressions_i )
=20
void VG_(add_suppression_file)(const HChar *filename)
{
=2D HChar *f =3D VG_(strdup)("errormgr.addsup", filename);
=2D VG_(addToXA)(VG_(clo_suppressions), &f);
=2D if (load_suppressions_called)
=2D load_one_suppressions_file( VG_(sizeXA)(VG_(clo_suppressions)) - 1=
);
+ // Check if it's a directory.
+ if (VG_(is_dir)( filename )) {
+ SysRes sres;
+ Int fd;
+
+ // Open the directory.
+ sres =3D VG_(open)( filename, VKI_O_RDONLY, 0 );
+ if (sr_isError(sres)) {
+ if (VG_(clo_xml))
+VG_(printf_xml)("\n");
+ VG_(umsg)("FATAL: can't open suppressions directory \"%s\"\n", fi=
lename );
+ VG_(exit)(1);
+ }
+ fd =3D sr_Res(sres);
+
+ // Read each entry and add it recursively.
+ while (True) {
+ Int nRead, pos =3D 0;
+ HChar buf[1024];
+
+ sres =3D VG_(getdents)( fd, (struct vg_dirent *)buf, sizeof(buf) =
);
+ if (sr_isError(sres)) {
+if (VG_(clo_xml))
+ VG_(printf_xml)("\n");
+VG_(umsg)("FATAL: can't read suppressions directory \"%s\"\n",=
filename );
+VG_(exit)(1);
+ }
+ nRead =3D sr_Res(sres);
+
+ vg_assert(nRead >=3D 0);
+
+ if (nRead =3D=3D 0) {
+// We're at the end of the directory.
+break;
+ }
+
+ // Add the entries.
+ while (pos < nRead) {
+struct vg_dirent *entry =3D (struct vg_dirent *)(buf + pos);
+HChar *fullpath;
+SizeT nameSize =3D VG_(strlen)(entry->name);
+
+// Skip dotfiles and files which don't end in ".supp".
+if (entry->name[0] =3D=3D '.' || nameSize < 5 ||
+!VG_STREQ(entry->name + nameSize - 5, ".supp")) {
+ pos +=3D entry->reclen;
+ continue;
+}
+
+// Get the full path including the directory name.
+fullpath =3D VG_(malloc)("errormgr.addsup",
+ VG_(strlen)(filename) +
+ VG_(strlen)(entry->name) + 2);
+VG_(strcpy)(fullpath, filename);
+VG_(strcat)(fullpath, "/");
+VG_(strcat)(fullpath, entry->name);
+
+// Add the entry.
+VG_(add_suppression_file)( fullpath );
+
+VG_(free)(fullpath);
+
+// Go to the next entry.
+pos +=3D entry->reclen;
+ }
+ }
+
+ VG_(close)(fd);
+ }
+ else {
+ // It's not a directory.
+ HChar *f =3D VG_(strdup)("errormgr.addsup", filename);
+ VG_(addToXA)(VG_(clo_suppressions), &f);
+ if (load_suppressions_called)
+ load_one_suppressions_file( VG_(sizeXA)(VG_(clo_suppressions)) - =
1 );
+ }
}
=20
void VG_(load_suppressions) ( void )
diff --git a/coregrind/m_libcfile.c b/coregrind/m_libcfile.c
index 3a8fed85d..7e6ffe2e8 100644
=2D-- a/coregrind/m_libcfile.c
+++ b/coregrind/m_libcfile.c
@@ -215,6 +215,11 @@ Int VG_(read) ( Int fd, void* buf, Int count)
return ret;
}
=20
+SysRes VG_(getdents) ( UInt fd, struct v
Bug#940516: Created patch
Package: valgrind Version: 1:3.15.0-1 Tags: patch Followup-For: Bug #940516 Dear Maintainer, I have written a patch to fix this bug. I will send it in the next email (created with git format-patch). The patch is based on commit 3bac39a10 upstream (the current latest). Please see also upstream bugs 93376 [1] and 160905 [2]. I'll also send the patch upstream to bug 93376. Thanks, Asher [1] https://bugs.kde.org/show_bug.cgi?id=93376 [2] https://bugs.kde.org/show_bug.cgi?id=160905 -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me sprea= d! signature.asc Description: PGP signature
Bug#940516: valgrind: ONLY uses /usr/lib/$(arch)-linux-gnu/default.supp by default
Package: valgrind
Version: 1:3.15.0-1
Severity: normal
Tags: upstream
Dear Maintainer,
The only suppression file that Valgrind loads by default is
/usr/lib/$(arch)-linux-gnu/default.supp
(/usr/lib/x86_64-linux-gnu/default.supp on my system). This is
inconvenient, because if you are using Valgrind to debug a program, but
you don't want to debug the libraries that program uses, or maybe one of
the libraries never free()'s some of its memory (for example ncurses or
Readline), then you will need to load the suppression file manually.
Further more (and this is the reason I tagged this bug as `normal'
rather than `wishlist'), some Debian packages install suppression files
to /usr/lib/valgrind/, and they appear to think that those files will be
loaded automatically. For example, the packages python{,2,3} install the
files /usr/lib/valgrind/python{,2,3}.supp. Here is an excerpt from one
of those files:
# Debian note:
# The file Misc/valgrind-python.supp is placed in an modified form into the
# directory /usr/lib/valgrind as python.supp. There's no need to to add it
# with the --suppressions option.
But in fact you DO need to add it with the --suppressions option.
To prove that Valgrind actually doesn't load these files, create a file
like this one:
#include
int main(void) {
/* Leak some memory. */
malloc(1);
return 0;
}
Then create a suppression like this:
{
Memory leak suppression
Memcheck:Leak
match-leak-kinds: definite
fun:malloc
fun:main
}
Verify that the suppression works:
$ gcc -o leak leak.c
$ valgrind ./leak
[...]
==3428==definitely lost: 1 bytes in 1 blocks
[...]
==3428== suppressed: 0 bytes in 0 blocks
[...]
$ valgrind --suppressions=leak.supp ./leak
[...]
==3436==definitely lost: 0 bytes in 0 blocks
[...]
==3436== suppressed: 1 bytes in 1 blocks
[...]
And if you copy the suppression to /usr/lib/valgrind/ (or even
/usr/lib/$(arch)-linux-gnu/valgrind/), you will find that it is not
loaded automatically. However, if you copy it to
/usr/lib/$(arch)-linux-gnu/valgrind/default.supp (make a backup of
default.supp first), it *is* loaded automatically.
Correct me if I am mistaken, but I don't believe that Valgrind
suppression files have any way to include other files. If they did, and
it supported shell globs or similar,
/usr/lib/$(arch)-linux-gnu/valgrind/default.supp could simply include
all the *.supp files in /usr/lib/valgrind/, /usr/local/lib/valgrind/,
etc.
But since I don't believe that is possible, the next best solution would
be to modify /usr/bin/valgrind (which is already a wrapper shell script)
to pass a --suppression=FILE for every FILE in /usr/lib/valgrind/*.supp,
/usr/local/lib/valgrind/*.supp, etc. to valgrind.bin. And maybe it could
also parse --default-suppressions=no and not include those files as well
as passing on --default-suppressions=no to valgrind.bin so it doesn't
load the actual default.supp.
Of course, this should probably really be fixed upstream. Maybe the best
solution would be to allow inclusion of other suppression files within
suppression files so that it is easy for the distribution packaging
Valgrind to choose which files/directories are loaded.
Thanks,
Asher
--
Steal this tagline. I did.
-- System Information:
Debian Release: bullseye/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages valgrind depends on:
ii libc6 2.29-1
ii libc6-dbg 2.29-1
Versions of packages valgrind recommends:
ii gdb 8.3-1
ii valgrind-dbg 1:3.15.0-1
Versions of packages valgrind suggests:
pn alleyoop
pn kcachegrind
pn valgrind-mpi
pn valkyrie
-- no debconf information
signature.asc
Description: PGP signature
Bug#940261: Upgrade clang/llvm version used for postgresql-11
Christoph Berg writes: > it's a strict dependency because postgresql-11 is linked against a > specific version of libllvm, used for JIT compilation of SQL queries > using LLVM bitcode. I haven't really looked around myself, but from > talking to Andres Freund who implemented the JIT engine on the > PostgreSQL side, the bitcode files are probably specific to the llvm > version, so we make that a strict dependency to make sure the > PostgreSQL extension modules are compiled using the same clang version > as the server itself. I see. Thanks for the clarification. > About the version used, 9 is around the corner so I'd prefer moving > from 7 to 9, instead of upgrading to 8 now, and then upgrading again > in the next weeks/month. I'll leave this bug around as a reminder that > we need to do that upgrade. OK, sounds good. Asher -- The marvels of today's modern technology include the development of a soda can, when discarded will last forever ... and a $7,000 car which when properly cared for will rust out in two or three years. signature.asc Description: PGP signature
Bug#940261: postgresql-server-dev-11: depend on clang and llvm-dev rather than clang-7 and llvm-7-dev
Package: postgresql-server-dev-11 Version: 11.5-2 Severity: normal Dear Maintainer, I just upgraded clang which now depends on clang-8 since that is the new default in Debian. I would like to remove clang-7 (and llvm-7, etc.), but postgresql-server-dev-11 depends on those packages. $ aptitude why clang-7 i postgresql-server-dev-all Depends postgresql-server-dev-11 i A postgresql-server-dev-11 Depends clang-7 This prevents me from removing clang-7 & co. Unless postgresql-server-dev-11 depends specifically on version 7 of clang for a reason, the dependencies should be corrected to clang and llvm-dev which depend on the defaults in Debian. Thanks, Asher -- A witty saying proves nothing, but saying something pointless gets people's attention. -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages postgresql-server-dev-11 depends on: ii clang-71:7.0.1-9+b1 ii libc6 2.29-1 ii libpq-dev 11.5-2 ii llvm-7-dev 1:7.0.1-9+b1 ii postgresql-common 205 postgresql-server-dev-11 recommends no packages. postgresql-server-dev-11 suggests no packages. -- no debconf information signature.asc Description: PGP signature
Bug#939876: gimp: segmentation fault on open
Package: gimp Version: 2.10.8-2+b1 Followup-For: Bug #939876 Hello Witold, Witold Baryluk writes: > I think I do have same issue. > > It happens even when creating an empty document using menu File -> > New, with anysize (i.e. 1024x768). But also when opening any file > (tested with png and jpeg files). > > Stack trace looks similar. Looks like a bug in gimp_gegl_mask_is_empty > maybe? The issue seems to be a GEGL version mismatch (compiled against versus linked against). > I hope this is fixed soon :) If you need to use the GIMP right away, a workaround that worked for me is to install the updated libgegl-0.4-0 and libgegl-common from sid. Download the packages from the Debian website and install with gdebi or similar (make sure to install libgegl-common first). See also #939754 and #939768 which appear to be the same bug. Asher -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me sprea= d! -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp depends on: ii gimp-data2.10.8-2 ii libaa1 1.4p5-46+b1 ii libbabl-0.1-00.1.62-1 ii libbz2-1.0 1.0.6-9.2 ii libc62.28-10 ii libcairo21.16.0-4 ii libfontconfig1 2.13.1-2+b1 ii libfreetype6 2.9.1-4 ii libgcc1 1:9.2.1-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgegl-0.4-00.4.14-1+b2 ii libgexiv2-2 0.10.9-1 ii libgimp2.0 2.10.8-2+b1 ii libglib2.0-0 2.60.6-2 ii libgs9 9.27~dfsg-3.1 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b2.6.1-2 ii libheif1 1.5.1-1 ii libilmbase24 2.3.0-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3+b1 ii liblzma5 5.2.4-1+b1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1.3.0-2.1+b1 ii libopenexr24 2.3.0-6 ii libopenjp2-7 2.3.0-2 ii libpango-1.0-0 1.42.4-7 ii libpangocairo-1.0-0 1.42.4-7 ii libpangoft2-1.0-01.42.4-7 ii libpng16-16 1.6.37-1 ii libpoppler-glib8 0.71.0-5+b1 ii librsvg2-2 2.44.14-1 ii libstdc++6 9.2.1-4 ii libtiff5 4.0.10+git190818-1 ii libwebp6 0.6.1-2+b1 ii libwebpdemux20.6.1-2+b1 ii libwebpmux3 0.6.1-2+b1 ii libwmf0.2-7 0.2.8.4-14 ii libx11-6 2:1.6.7-1 ii libxcursor1 1:1.2.0-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages gimp recommends: ii ghostscript 9.27~dfsg-3.1 Versions of packages gimp suggests: pn gimp-data-extras ii gimp-help-en [gimp-help] 2.8.2-1 pn gimp-python ii gvfs-backends 1.38.1-5 ii libasound21.1.8-1 -- no debconf information signature.asc Description: PGP signature
Bug#939754: gimp: Crashes when I try to open an image or create a new one
Jakob Haufe writes: > On Mon, 09 Sep 2019 14:59:02 -0400 > Asher Gordon wrote: > >> I think that its the GEGL version that fixed it, not the patch. The >> bug appears to be caused because the GIMP was built against GEGL >> 0.4.14 (in sid), but bullseye only has GEGL 0.4.12. > > I doubt this is correct. Installing GEGL 0.4.14-1 from sid on an > bullseye system did not resolve the segfault issue. This was the first > thing i tried. I just tried installing libgegl-0.4-0 version 0.4.14-1+b2 (and libgegl-common version 0.4.14-1) from sid (also on a bullseye system) and the GIMP was able to load files and work as expected. You say you installed GEGL 0.4.14-1. Did you install just plain 0.4.14-1 or with the +b2 (or +b1)? Did you also install the updated version of libgegl-common? If you installed GEGL 0.4.14-1 (no +b*), maybe the issue was introduced in GEGL 0.4.14-1+b1 or 0.4.14-1+b2? At any rate, the bug seemed to have been introduced when the GIMP was updated to 2.10.8-2+b1, so reverting to 2.10.8-2 should provide a temporary fix at least. Asher -- Reader, suppose you were an idiot. And suppose you were a member of Congress. But I repeat myself. -- Mark Twain signature.asc Description: PGP signature
Bug#939754: gimp: Crashes when I try to open an image or create a new one
Package: gimp Version: 2.10.8-2+b1 Followup-For: Bug #939754 Hello Jakob, Jakob Haufe writes: > I cherry-picked 986a298a from upstream (which is also contained in > 2.10.10+) and rebuilt gimp. This fixes the issue for me. This patch, > however, needs gegl >= 0.4.14 which is stuck in unstable ATM. I think that its the GEGL version that fixed it, not the patch. The bug appears to be caused because the GIMP was built against GEGL 0.4.14 (in sid), but bullseye only has GEGL 0.4.12. See also #939768 for more info, which appears to be the same bug. See especially message #20. #939876 also looks like the same bug. All three of these bugs should probably be merged. Thanks, Asher -- ...very few phenomena can pull someone out of Deep Hack Mode, with two noted exceptions: being struck by lightning, or worse, your *computer* being struck by lightning. -- Matt Welsh -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp depends on: ii gimp-data2.10.8-2 ii libaa1 1.4p5-46+b1 ii libbabl-0.1-00.1.62-1 ii libbz2-1.0 1.0.6-9.2 ii libc62.28-10 ii libcairo21.16.0-4 ii libfontconfig1 2.13.1-2+b1 ii libfreetype6 2.9.1-4 ii libgcc1 1:9.2.1-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgegl-0.4-00.4.12-2 ii libgexiv2-2 0.10.9-1 ii libgimp2.0 2.10.8-2+b1 ii libglib2.0-0 2.60.6-2 ii libgs9 9.27~dfsg-3.1 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b2.6.1-2 ii libheif1 1.5.1-1 ii libilmbase24 2.3.0-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3+b1 ii liblzma5 5.2.4-1+b1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1.3.0-2.1+b1 ii libopenexr24 2.3.0-6 ii libopenjp2-7 2.3.0-2 ii libpango-1.0-0 1.42.4-7 ii libpangocairo-1.0-0 1.42.4-7 ii libpangoft2-1.0-01.42.4-7 ii libpng16-16 1.6.37-1 ii libpoppler-glib8 0.71.0-5+b1 ii librsvg2-2 2.44.14-1 ii libstdc++6 9.2.1-4 ii libtiff5 4.0.10+git190818-1 ii libwebp6 0.6.1-2+b1 ii libwebpdemux20.6.1-2+b1 ii libwebpmux3 0.6.1-2+b1 ii libwmf0.2-7 0.2.8.4-14 ii libx11-6 2:1.6.7-1 ii libxcursor1 1:1.2.0-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages gimp recommends: ii ghostscript 9.27~dfsg-3.1 Versions of packages gimp suggests: pn gimp-data-extras ii gimp-help-en [gimp-help] 2.8.2-1 pn gimp-python ii gvfs-backends 1.38.1-5 ii libasound21.1.8-1 -- no debconf information signature.asc Description: PGP signature
Bug#939768: gimp: After the last upgrade, GIMP crashes when creating a new image or opening an existing one.
Package: gimp Version: 2.10.8-2+b1 Followup-For: Bug #939768 Hello, I'm also using testing (bullseye) and I can confirm this bug too. Here's what I think happened: GIMP 2.10.8-2 was built on sid (which had GEGL 0.4.12 at the time). Testing also had GEGL 0.4.12, so there was no version mismatch and everything was fine. Then, GIMP 2.10.8-2+b1 was built on sid, which now has GEGL 0.4.14. When GIMP 2.10.8-2+b1 (now built against GEGL 0.4.14) migrated to testing (which still has GEGL 0.4.12), the version mismatch occurred causing the GIMP to crash. Note that I am just guessing the versions of packages that sid and testing had in the past, so it should be taken with a grain of salt. If this is the case, there appears to be three obvious fixes: 1. Migrate GEGL 0.4.14 to testing. 2. Revert the testing GIMP package to 2.10.8-2. 3. Build the testing GIMP package against GEGL 0.4.12. Since GEGL is 188 days old and should be migrated anyway, 1. seems to be preferable. Looking at the package tracker [1], it appears that there are some migration issues that need to be looked at, so perhaps 2. could be a temporary fix. I'm not sure how 3. would be implemented, since the sid GIMP package would still need to be built against GEGL 0.4.14. In the future, care should be taken to avoid GEGL mismatches like this. By the way, #939754 looks like the same bug. Hope this helps, Asher P.S. I am neither a GIMP developer nor a Debian developer, just an affected user trying to help. [1] https://tracker.debian.org/pkg/gegl -- By necessity, by proclivity, and by delight, we all quote. In fact, it is as difficult to appropriate the thoughts of others as it is to invent. -- R. Emerson -- Quoted from a fortune cookie program (whose author claims, "Actually, stealing IS easier.") [to which I reply, "You think it's easy for me to misconstrue all these misquotations?!?" Ed.] -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gimp depends on: ii gimp-data2.10.8-2 ii libaa1 1.4p5-46+b1 ii libbabl-0.1-00.1.62-1 ii libbz2-1.0 1.0.6-9.2 ii libc62.28-10 ii libcairo21.16.0-4 ii libfontconfig1 2.13.1-2+b1 ii libfreetype6 2.9.1-4 ii libgcc1 1:9.2.1-4 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgegl-0.4-00.4.12-2 ii libgexiv2-2 0.10.9-1 ii libgimp2.0 2.10.8-2+b1 ii libglib2.0-0 2.60.6-2 ii libgs9 9.27~dfsg-3.1 ii libgtk2.0-0 2.24.32-3 ii libgudev-1.0-0 232-2 ii libharfbuzz0b2.6.1-2 ii libheif1 1.5.1-1 ii libilmbase24 2.3.0-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblcms2-2 2.9-3+b1 ii liblzma5 5.2.4-1+b1 ii libmng1 1.0.10+dfsg-3.1+b5 ii libmypaint-1.3-0 1.3.0-2.1+b1 ii libopenexr24 2.3.0-6 ii libopenjp2-7 2.3.0-2 ii libpango-1.0-0 1.42.4-7 ii libpangocairo-1.0-0 1.42.4-7 ii libpangoft2-1.0-01.42.4-7 ii libpng16-16 1.6.37-1 ii libpoppler-glib8 0.71.0-5+b1 ii librsvg2-2 2.44.14-1 ii libstdc++6 9.2.1-4 ii libtiff5 4.0.10+git190818-1 ii libwebp6 0.6.1-2+b1 ii libwebpdemux20.6.1-2+b1 ii libwebpmux3 0.6.1-2+b1 ii libwmf0.2-7 0.2.8.4-14 ii libx11-6 2:1.6.7-1 ii libxcursor1 1:1.2.0-2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2+b3 ii libxpm4 1:3.5.12-1 ii xdg-utils1.1.3-1 ii zlib1g 1:1.2.11.dfsg-1+b1 Versions of packages gimp recommends: ii ghostscript 9.27~dfsg-3.1 Versions of packages gimp suggests: pn gimp-data-extras ii gimp-help-en [gimp-help] 2.8.2-1 pn gimp-python ii gvfs-backends 1.38.1-5 ii libasound21.1.8-1 -- no debconf information signature.asc Description: PGP signature
Bug#931182: gcc-8: does not issue a warning with -Wall when a named enum value is overridden by a variable with the same name
Package: gcc-8
Version: 8.3.0-6
Severity: normal
Tags: upstream
Dear Maintainer,
In a C program, when an enum's value is overridden by a variable with
the same name, and it is compiled by gcc with -Wall, no warning is
emitted even though it is questionable to override an enum. See the
program below:
#include
int main(void) {
enum {g, h, i} foo[3];
/* Set all elements of `foo' to `i' (2), or so you would think */
for (int i = 0; i < sizeof(foo) / sizeof(*foo); i++) {
foo[i] = i; /* <-- this doesn't do what you think */
}
/* Now print all the elements (note we use `iterator' instead of `i'
to avoid the situation above) */
for (int iterator = 0; iterator < sizeof(foo) / sizeof(*foo); iterator++) {
printf("foo[%d] is ", iterator);
switch (foo[iterator]) {
case g:
puts("g");
break;
case h:
puts("h");
break;
case i:
puts("i");
break;
default:
printf("something else: %d\n", foo[iterator]);
break;
}
}
return 0;
}
In line 8, "foo[i] = i;", foo[i] is indexed using the "i" which was
declared at the beginning of the loop ("int i = 0;"), as you would
expect. However, it is not clear what the second "i" (the one on the
right of the assignment) is referring to. It could be referring to the
value "2" (since that is the value `i' is assigned to in the enum), or
it could also be referring to the "i" which was declared at the
beginning of the loop. It is in fact referring to the loop `i' as you
can see if you compile and run the program.
$ gcc -Wall -o enum-test enum-test.c
$ ./enum-test
foo[0] is g
foo[1] is h
foo[2] is i
However, note that gcc succeeded with *no output* even though -Wall was
passed. Since overriding enum values is unclear and may not do what you
think, and it's easily avoidable (just change the variable or enum value
name), it should be warned against when -Wall is passed.
From the "(gcc) Warning Options" info node,
'-Wall'
This enables all the warnings about constructions that some users
consider questionable, and that are easy to avoid (or modify to
prevent the warning), even in conjunction with macros.
So I think this should definitely be warned against by -Wall.
Clang too, does not warn against this:
$ clang -Wall -o enum-test enum-test.c
$ ./enum-test
foo[0] is g
foo[1] is h
foo[2] is i
(As you can see, the runtime behavior of the program is the same as when
compiled with gcc, as you would expect.)
Curiously, both g++ and clang++ raise an error when an enum is
overridden (along with a few warnings since the program was not meant to
be compiled as C++).
$ g++ -Wall -o enum-test enum-test.c
enum-test.c: In function ‘int main()’:
enum-test.c:7:21: warning: comparison of integer expressions of different
signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
for (int i = 0; i < sizeof(foo) / sizeof(*foo); i++) {
~~^~~~
enum-test.c:8:14: error: invalid conversion from ‘int’ to ‘main()::’ [-fpermissive]
foo[i] = i; /* <-- this doesn't do what you think */
^
enum-test.c:13:35: warning: comparison of integer expressions of different
signedness: ‘int’ and ‘long unsigned int’ [-Wsign-compare]
for (int iterator = 0; iterator < sizeof(foo) / sizeof(*foo); iterator++) {
~^~~~
$ clang++ -Wall -o enum-test enum-test.c
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior
is deprecated [-Wdeprecated]
enum-test.c:8:14: error: assigning to 'enum (anonymous enum at
enum-test.c:4:3)' from incompatible type 'int'
foo[i] = i; /* <-- this doesn't do what you think */
^
1 error generated.
I haven't reported a bug against clang since you can only report a bug
against one package, but perhaps a bug should be reported against clang
referencing this one to alert the clang people about this too.
-- System Information:
Debian Release: 10.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gcc-8 depends on:
ii binutils 2.31.1-16
ii cpp-8 8.3.0-6
ii gcc-8-base8.3.0-6
ii libc6 2.28-10
ii libcc1-0 8.3.0-6
ii libgcc-8-dev 8.3.0-6
ii libgcc1 1:8.3.0-6
ii libgmp10 2:6.1.2+dfsg-4
ii libisl19 0.20-2
ii libmpc3 1.1.0-1
ii libmpfr6 4.0.2-1
ii libstdc++68.3.0-6
ii zlib1g1:1.2.11.dfsg-1
Versions of packages gcc-8 recommends:
ii libc6-dev 2.28-10
Versions of packages gcc-8 suggests:
pn gcc-8-doc
pn gcc-8-locales
pn gcc-8-multilib
Bug#929188: gnubg: allows re-rolling dice after declined resignation in graphical mode
Package: gnubg Version: 1.06.002-1 Severity: normal Tags: upstream Dear Maintainer, Follow these steps to reproduce the bug: 1. Start GNU Backgammon in graphical mode (just type "gnubg" at the command prompt, and make sure X is running). 2. Start a new game by clicking "New" or select File -> New... 3. Select "Human vs. Human" and click "OK". 4. Take note of the numbers on the dice. 5. As the player whose turn it is, offer a resignation by clicking "Resign" or select Game -> Resign, and select any of the options. This will remove the dice from the board. 6. As the other player, decline the resignation by clicking "Reject" or select Game -> Reject. 7. Now, as the first player again, roll the dice by clicking in the area on the board in which they would be rolled. Note that the roll is different than it was before the resignation offer (if it is not, repeat steps 5-7 until it is). This allows the player to cheat by re-rolling the dice until a good roll is available. If you can get the computer into a state where it will not accept a normal resign (play badly until a gammon/backgammon is inevitable), this bug is also reproducible, allowing the player to cheat against the computer. Ideally, in step 5. above, when the player offers a resignation, GNU Backgammon should leave the dice on the board, and not allow the player to re-roll them. Note also that after step 6., if you don't roll the dice and instead resign again immediately, and you choose a level less than or equal to the level chosen before (e.g. normal), then it will print " has already declined your offer of a ." and will not offer the resignation a second time. This should also happen when the dice are rolled again before the second resignation. However it does not. I suppose that is a different bug, but it seemed related enough to mention it here. Also note that in text mode neither of these bugs are present: $ gnubg -t [...] (No game) set player 0 human Moves for foo must now be entered manually. (No game) set player 1 human Moves for bar must now be entered manually. (No game) new game foo rolls 3, bar rolls 1. [...] (foo) resign foo offers to resign a single game. [...] (bar) reject bar declines the single game. [...] (foo) roll You have already rolled the dice. (foo) resign bar has already declined your offer of a single game. (foo) exit Are you sure you want to discard the current match? y -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-5-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gnubg depends on: ii debconf [debconf-2.0] 1.5.71 ii gnubg-data 1.06.002-1 ii libc6 2.28-10 ii libcairo2 1.16.0-4 ii libcanberra-gtk00.30-7 ii libcanberra00.30-7 ii libcurl47.64.0-3 ii libfreetype62.9.1-3 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libgl1 1.1.0-1 ii libglib2.0-02.58.3-1 ii libglu1-mesa [libglu1] 9.0.0-2.1+b3 ii libgmp102:6.1.2+dfsg-4 ii libgtk2.0-0 2.24.32-3 ii libgtkglext11.2.0-9 ii libpango-1.0-0 1.42.4-6 ii libpangocairo-1.0-0 1.42.4-6 ii libpng16-16 1.6.36-5 ii libpython2.72.7.16-2 ii libreadline77.0-5 ii libsqlite3-03.27.2-2 gnubg recommends no packages. Versions of packages gnubg suggests: ii sensible-utils 0.0.12 -- debconf information: * gnubg/build-bearoffs: true signature.asc Description: PGP signature
Bug#928559: manpages: contrary to the manpage, the infinite loop in pldd(1) is no longer present
Package: manpages Version: 4.16-1 Severity: minor Tags: patch Dear Maintainer, The manpage for pldd(1) says BUGS Since glibc 2.19, pldd is broken: it just hangs when executed. It is unclear if it will ever be fixed. However, in glibc 2.28-10, this bug was fixed. The manpage should be updated according to the patch below (of course you could put "None." or "Many." or something like that in the BUGS section, as is the tradition when you can't think of any bugs :-)): --- man1/pldd.1~ 2018-04-30 11:54:33.0 -0400 +++ man1/pldd.1 2019-05-07 01:05:44.440420437 -0400 @@ -96,12 +96,6 @@ \fB-ex "quit" \-p $pid | grep '^0x.*0x'\fP .EE .in -.SH BUGS -Since glibc 2.19, -.B pldd -is broken: it just hangs when executed. -.\" FIXME . https://sourceware.org/bugzilla/show_bug.cgi?id=18035 -It is unclear if it will ever be fixed. .SH EXAMPLE .EX $ \fBecho $$\fP # Display PID of shell Thanks, Asher -- The most delightful day after the one on which you buy a cottage in the country is the one on which you resell it. -- J. Brecheux -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled manpages depends on no packages. manpages recommends no packages. Versions of packages manpages suggests: ii man-db [man-browser] 2.8.5-2 -- no debconf information
Bug#928558: reportbug: "message-fetch-field" should be "mail-fetch-field" in reportbug.el
Package: reportbug
Version: 7.5.2
Severity: normal
Tags: patch
Dear Maintainer,
When I run "reportbug -G" ("-G" to use the Gnus MUA), it starts up emacs
with a buffer containing the message, but it is in text-mode and not in
message-mode as one would expect. Here is the relevant part of the
*Messages* buffer:
Loading /usr/share/reportbug/reportbug.el (source)...done
Starting new Ispell process aspell with default dictionary...
let: Symbol’s function definition is void: message-fetch-field
As you can see, there is no function "message-fetch-field". It should
instead be "mail-fetch-field". A workaround is to put
(defalias 'message-fetch-field 'mail-fetch-field
"Compatibility with reportbug(1)")
in your ~/.emacs which is what I did, and I am sending this with Gnus
now. However, the problem should really be corrected in
/usr/share/reportbug/reportbug.el as in the following patch:
--- share/reportbug.el~ 2019-01-31 20:57:49.0 -0500
+++ share/reportbug.el 2019-05-07 00:24:08.944752814 -0400
@@ -28,8 +28,8 @@
(interactive)
(require 'gnus)
(find-file reportbug-template)
- (let ((subject (message-fetch-field "Subject"))
-(toaddr (or (message-fetch-field "To") "sub...@bugs.debian.org")))
+ (let ((subject (mail-fetch-field "Subject"))
+(toaddr (or (mail-fetch-field "To") "sub...@bugs.debian.org")))
(gnus-narrow-to-body)
(let ((body (or (buffer-string) "")))
(gnus-summary-mail-other-window)
Thanks,
Asher
--
Real computer scientists don't program in assembler. They don't write
in anything less portable than a number two pencil.
-- Package-specific info:
** Environment settings:
EDITOR="emacs"
PAGER="less"
INTERFACE="text"
** /home/asher/.reportbugrc:
reportbug_version "7.5.2"
mode standard
ui text
email "asd...@posteo.net"
smtphost "posteo.de"
smtpuser "asd...@posteo.net"
smtppasswd
smtptls
http_proxy "socks5://localhost:9050"
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages reportbug depends on:
ii apt1.8.0
ii python33.7.2-1
ii python3-reportbug 7.5.2
ii sensible-utils 0.0.12
reportbug recommends no packages.
Versions of packages reportbug suggests:
pn claws-mail
pn debconf-utils
pn debsums
pn dlocate
pn emacs24-bin-common | emacs25-bin-common
ii exim4-daemon-light [mail-transport-agent] 4.92-2
ii file 1:5.35-4
ii gnupg 2.2.12-1
pn python3-urwid
pn reportbug-gtk
ii xdg-utils 1.1.3-1
Versions of packages python3-reportbug depends on:
ii apt1.8.0
ii file 1:5.35-4
ii python33.7.2-1
ii python3-apt1.8.4
ii python3-debian 0.1.34
ii python3-debianbts 2.8.2
ii python3-requests 2.21.0-1
python3-reportbug suggests no packages.
-- no debconf information
signature.asc
Description: PGP signature
Bug#927705: autoconf: configure does not find builtin functions when -Werror is in CFLAGS
Package: autoconf
Version: 2.69-11
Severity: normal
Tags: upstream
Dear Maintainer,
When AC_CHECK_FUNC or AC_CHECK_FUNCS is called on a builtin function
in gcc, the compiler emits a warning. For example, using memset() as
an example builtin:
warning: conflicting types for built-in function 'memset'
[-Wbuiltin-declaration-mismatch]
When -Werror is in CFLAGS, this is promoted to an error, causing
configure to believe memset() was not found.
See this very simple example configure.ac file:
AC_INIT([test], [0.0])
AC_PROG_CC
AC_CHECK_FUNC([memset])
AC_OUTPUT
When the resulting configure script is run, you will find the line
checking for memset... yes
in the output. This is expected, since memset() is available. However,
when the configure script is run as "./configure CFLAGS=-Werror", you
will find this line in the output:
checking for memset... no
This is not the expected behavior because, as we have seen above,
memset() is indeed available.
Here is the relevant part of config.log:
configure:2614: checking for memset
configure:2614: gcc -o conftest -Werror conftest.c >&5
conftest.c:32:6: error: conflicting types for built-in function 'memset'
[-Werror=builtin-declaration-mismatch]
char memset ();
^~
cc1: all warnings being treated as errors
configure:2614: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "test"
| #define PACKAGE_TARNAME "test"
| #define PACKAGE_VERSION "0.0"
| #define PACKAGE_STRING "test 0.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h. */
| /* Define memset to an innocuous variant, in case declares
memset.
|For example, HP-UX 11i declares gettimeofday. */
| #define memset innocuous_memset
|
| /* System header to define __stub macros and hopefully few prototypes,
| which can conflict with char memset (); below.
| Prefer to if __STDC__ is defined, since
| exists even on freestanding compilers. */
|
| #ifdef __STDC__
| # include
| #else
| # include
| #endif
|
| #undef memset
|
| /* Override any GCC internal prototype to avoid an error.
|Use char because int might match the return type of a GCC
|builtin and then its argument prototype would still apply. */
| #ifdef __cplusplus
| extern "C"
| #endif
| char memset ();
| /* The GNU C library defines this for functions which it implements
| to always fail with ENOSYS. Some functions are actually named
| something starting with __ and the normal name is an alias. */
| #if defined __stub_memset || defined __stub___memset
| choke me
| #endif
|
| int
| main ()
| {
| return memset ();
| ;
| return 0;
| }
configure:2614: result: no
When the configure script is run with
CFLAGS='-Werror -Wno-builtin-declaration-mismatch', however, it *does*
find memset(). That is because, with the warning disabled, it is not
promoted to an error and therefore compiles successfully. My
suggestion is to always append '-Wno-builtin-declaration-mismatch' to
CFLAGS when checking for functions with AC_CHECK_FUNC and
AC_CHECK_FUNCS. That way, those macros would find both library
functions and builtins even when -Werror is in CFLAGS.
Thanks,
Asher
P.S. A real world example of this bug is my "c2py" program at
sv.nongnu.org/p/c2py. If you checkout the latest sources with cvs and
configure with "./configure --enable-Werror", it will fail since some
of the functions it requires are builtin.
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-4-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages autoconf depends on:
ii debianutils 4.8.6.1
ii m4 1.4.18-2
ii perl 5.28.1-6
Versions of packages autoconf recommends:
ii automake [automaken] 1:1.16.1-4
Versions of packages autoconf suggests:
ii autoconf-archive 20180313-1
ii autoconf-doc 2.69-11
ii gettext 0.19.8.1-9
ii gnu-standards 2010.03.11-1
ii libtool 2.4.6-9
-- no debconf information
Bug#916562: libc6: fputs(), fputc(), and fwrite() do not fail on write error
On Saturday, December 15, 2018 7:02 PM, Samuel Thibault wrote: > Hello, > > Asher Gordon, le sam. 15 déc. 2018 18:51:19 -0500, a ecrit: > > > If I use fputs(3), fputc(3), or fwrite(3) to write to a file that can > > be opened for writing but cannot be written to (e.g /dev/full), the > > functions return 1 rather than the expected EOF (or 0 in the case of > > fread()). > > Well, that is not surprising since these functions are buffered. You > need to call fflush() to make sure that no error happened on the actual > underlying write. > > Samuel You're right. I tried it with fflush() and it gave expected results. I guess we can close this bug now.
Bug#916562: libc6: fputs(), fputc(), and fwrite() do not fail on write error
Package: libc6
Version: 2.27-8
Severity: normal
Tags: upstream
Dear Maintainer,
If I use fputs(3), fputc(3), or fwrite(3) to write to a file that can
be opened for writing but cannot be written to (e.g /dev/full), the
functions return 1 rather than the expected EOF (or 0 in the case of
fread()). On the other hand, write(2) returns -1 and sets errno to
ENOSPC an expected.
Expected results:
The functions fputs() and fputc() should return EOF and fwrite()
should return 0. All the functions should set errno to ENOSPC (for
/dev/full).
Actual results:
The functions return 1 (an indication of success) and leave errno
unchanged.
Steps to reproduce:
Compile the attached program (the compiler flag `-fno-builtin' does
not change anything, nor does -O0):
$ gcc -o write write.c
Run the program with /dev/full as the output file:
$ ./write hello /dev/full
fputs() returned 1 and errno is 0 (Success).
fputc() returned 104 (h) and errno is 0 (Success).
fwrite() returned 5 (the length of "hello" is 5) and errno is 0 (Success).
write() returned -1 (the length of "hello" is 5) and errno is 28 (No space left
on device).
The expected output is:
fputs() returned EOF (-1) and errno is 28 (No space left on device).
fputc() returned EOF (-1) and errno is 28 (No space left on device).
fwrite() returned 0 (the length of "hello" is 5) and errno is 28 (No space left
on device).
write() returned -1 (the length of "hello" is 5) and errno is 28 (No space left
on device).
-- System Information:
Debian Release: buster/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages libc6 depends on:
ii libgcc1 1:8.2.0-9
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.69
pn glibc-doc
ii libc-l10n 2.27-8
ii locales2.27-8
-- debconf information:
* glibc/restart-services: cups cron
glibc/kernel-too-old:
glibc/kernel-not-supported:
glibc/restart-failed:
glibc/upgrade: true
glibc/disable-screensaver:
* libraries/restart-without-asking: false
#include
#include
#include
#include
int main(int argc, char **argv) {
int ret;
size_t string_len;
FILE *output_file;
if (argc != 3) {
fprintf(stderr, "Usage: %s STRING FILE\nWrite STRING to FILE.\n", argv[0]);
return 1;
}
/* Open the file */
if (!(output_file = fopen(argv[2], "w"))) {
fprintf(stderr, "%s: could not open %s: %m\n", argv[0], argv[2]);
return 1;
}
/* Now try to write to the file using fputs() */
errno = 0;
ret = fputs(argv[1], output_file);
/* `ret' should be EOF if an error occured (see fputs(3)) */
printf ("fputs() returned ");
if (ret == EOF)
printf("EOF (%d)", ret);
else
printf("%d", ret);
printf(" and errno is %d (%m).\n", errno);
/* This happens with fputc() too */
errno = 0;
ret = fputc(argv[1][0], output_file);
printf("fputc() returned ");
if (ret == EOF)
printf("EOF (%d)", ret);
else
printf("%d (%c)", ret, (char)ret);
printf(" and errno is %d (%m).\n", errno);
string_len = strlen(argv[1]);
/* This happens with fwrite() too */
errno = 0;
printf("fwrite() returned %lu (the length of \"%s\" is %lu) ",
fwrite(argv[1], 1, string_len, output_file), argv[1], string_len);
printf("and errno is %d (%m).\n", errno);
/* write() gives us expected results */
errno = 0;
printf("write() returned %ld (the length of \"%s\" is %lu) ",
write(fileno(output_file), argv[1], string_len), argv[1], string_len);
printf("and errno is %d (%m).\n", errno);
return 0;
}
