Bug#1072921: openbox depends on python needlessly
Package: openbox Followup-For: Bug #1072921 Hi. I cannot confirm any dependencies on ghostscript or related, and there's no mention of it in the changelog or any documentation file. Are you pulling it for something else? The one on python, on the other hand, is not needless as the obamenu script is python. This isn't just an example, it was actually meant to be used for menu generation. I've never used it! So the question is, does anyone? Openbox certainly works without it, with the package as is however, Python is required. Regards, Oliver
Bug#1076526: hardening-runtime: Outdated comment in sysctl config file
Package: hardening-runtime Version: 2 Severity: minor Hi, according to /usr/lib/sysctl.d/10-hardening.conf in the section on user namespaces: # On Debian kernel.unprivileged_userns_clone is set to 0 by default as well This has been incorrect for some time, apparently the default was changed in 5.10.1-1. I think the comment can just be removed. Regards, Oliver
Bug#1071203: nicotine: GTK not found, fails to start.
Package: nicotine Version: 3.3.2-1 Severity: grave Justification: renders package unusable Hi there, I'm running sid, just installed Nicotine after a good while not using it. Known dependencies are present, Python up to date, running `nicotine` fails: [05/15/24 20:41:37] Loading Python 3.11.9 [05/15/24 20:41:37] Loading Nicotine+ 3.3.2 [05/15/24 20:41:37] Cannot find GTK >=3, please install it. Stracing it reveals a couple of failed lookups similar to this: openat(AT_FDCWD, "/usr/lib/girepository-1.0", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = -1 ENOENT (No such file or directory) Correct path is /usr/lib/x86_64-linux-gnu/libgirepository-1.0.so.1 Maybe a clue. Regards, Oliver
Bug#996329: pal: re glib error(s)
Package: pal Version: 0.4.3-9 Followup-For: Bug #996329 Actually appears to be the same bug as reported earlier. I don't think it's important, the duplicate should be closed. Interactive mode obviously got never fully implemented to put it mildly, and what's left is aging badly. Not too surprising considering the application is 20 years old, the current version about 15 and the package is unmaintained. If the curses interface wasn't entirely useless by now, its usefulness could still be doubted. It should have been left out from the package, that would've also removed the ncurses dependencies, perhaps glib's too. Pal is still doing its trick as a simple command line utility, or what it originally was likely intented to be. But that would probably call for a maintainer. At least it should be made clear that the .pal files are supposed to be maintained manually, it's easy to crash the whole thing from the TUI, not much harder to garble your event files. Regards, Oliver
Bug#963151: suboptimal libzstd usage due to different build/runtime versions
Package: tor Version: 0.4.7.13-1 Followup-For: Bug #963151 The same thing has again been popping up for a couple of months, we're just at a later version of course. Tor was compiled with zstd 1.5.2, but is running with zstd 1.5.4. For safety, we'll avoid using advanced zstd functionality. Unstable actually has 1.5.5 already. Looks like we'd need a rebuild while there's little pressing incentive; fair enough, as tor itself is up to date even in Bookworm. May not be a bug at all. Regards, Oliver
Bug#1034573: note: Note not setting non-default database path
Package: note Version: 1.3.26-3 Severity: normal Tags: patch Hey guys, due to a mistake in the package provided config file, if copied as is, changing the directory for the DBM backend has no effect. /usr/share/doc/note/examples/noterc.gz: 60c60 < dbm::directory = ~/.notedbm # directory --- > dbm::dbname = ~/.notedbm # directory The package appears to be unmaintained, perhaps QA or the Debian Perl Group could have a look into this. Regards, Oliver
Bug#1027956: manpages: mtrace and sprof have been moved to optional package libc-devtools
Package: manpages Version: 6.02-1 Severity: minor Hi, mtrace, sprof and sotruss are now shipped by libc-devtools, with the manpage for the latter already included there. I suggest moving the others too. Regards, Oliver
Bug#1024875: vifm: Dito colorschemes
Package: vifm Version: 0.12-1+b1 Followup-For: Bug #1024875 The path under /usr/share/vifm doesn't appear to be honored other than vifm on first run copying the vifm-help.txt, itself already a copy of the manpage, to $HOME/.config/vifm. The purpose is unclear, :help fails with the error described in any case. Removing it brings it back at next run. The colors folder isn't touched, vifm does however look into /etc/vifm/colors, where there's just a lone default scheme. We can copy or link the schemes to the configuration in $HOME as a workaround, but that's hardly the way to go. Not sure whether it's ok to install the schemes under /etc, vifm should allow to change where it looks for its data. Regards, Oliver
Bug#1016144: codequery: Exuberant Ctags dependency should be optional
Package: codequery Version: 0.24.0+dfsg1-1 Severity: minor Hi! exuberant-ctags was superseded by universal-ctags that's been in Debian for a couple of years now. Codequery's website explicitly states both are supported and I can confirm as much. Please add universal-ctags as an alternative, thanks. Oliver
Bug#996781: luarocks: Installation fails with dpkg error
Package: luarocks Version: 3.7.0+dfsg1-1 Severity: grave Justification: renders package unusable Hi, thanks for reviving the package. Now I'm getting this when attempting to install however: Error: Cannot access repository at /root/.luarocks/lib/luarocks/rocks-5.3 dpkg: error processing package luarocks (--configure): installed luarocks package post-installation script subprocess returned error exit status 1 luarocks.postinst: mkdir -p /usr/local/lib/luarocks/rocks/ luarocks-admin make_manifest --local-tree <--- Using local-tree here is probably wrong. Regards, Oliver Versions of packages luarocks depends on: ii liblua5.3-dev 5.3.6-1 ii lua-any27 ii lua5.3 5.3.6-1 ii unzip 6.0-26 ii wget 1.21.2-2+b1 ii zip3.0-12 Versions of packages luarocks recommends: ii lua-sec 1.0.1-1 luarocks suggests no packages.
Bug#945229: pinfo exits if lynx is not found
Package: pinfo Version: 0.6.13-1.1 Followup-For: Bug #945229 Yes, but with a clean exit you're even lucky, hit on a broken manpage link (it line breaks on all with a hyphen in it) and it's crashing without even resetting your terminal, which is a bit rude but a different issue. There is a setting for it in pinforc: HTTPVIEWER. Lynx is just the tentative default. Looks like a reasonable choice when pinfo was cooked up, it's been in Debian for 20 years. These days maybe something like w3m might fare slightly better, but a lot of people don't even have a text browser anymore. I use links. About the best one could do I suppose is replacing it with 'sensible-browser' or 'www-browser', it's what we have it for. This is still a solid info browser though. Oliver
Bug#988117: flatpak: Resolved, please close.
Package: flatpak Followup-For: Bug #988117 Sorry, turns out flatpak fish is bound to the SDK runtime, which I didn't want to install. There is no bug. Regards
Bug#988117: flatpak: Some flatpaks unusable with /bin linked
Package: flatpak Version: 1.10.2-1 Severity: normal Tags: upstream Hi! I'm reporting this for flatpak even though point of failure and error message refer to bubblewrap (here 0.4.1-3), but it's clearly more of a flatpak (or flathub) issue. Some of their packages cannot be started once /bin is a link to /usr/bin, as is by now the installation default I think. To give an example, let's say I'm pulling in the fish shell, single partition scenario, then doing the obvious: flatpak run com.visualstudio.code.tool.fish I'll just get an exec error for /bin/sh: no such file There a good reasons for generally not using CLI apps via flatpak to begin with, but that's not the point of this report of course. Regards, Oliver
Bug#978699: sockstat: Manpage should mention privilege needed
Package: sockstat Version: 0.4.1-1 Severity: normal Hi, in contrast to `ss` (and others) I'm getting no output with `sockstat` being run as a normal user, which is unclear from the manpage or README and cannot be expected for something living under /usr/bin. (It lists holding process by default.) Of course, a usage note to this effect would be better still, considering a lone header line isn't all that helpful. And I'm ending up with this even with open sockets that are my own. The output also isn't exactly consistent even when run as root: `sockstat -4 -l` shows some connected ones, whereas '-4 -c' whill show (some) from the other group. I don't even see a pattern here, it's rather confusing as is anything that's not exclusive if the default is already all-inclusive (according to the manpage). `sockstat` on FreeBSD also works very differently. Regards, Oliver
Bug#975683: color_sampler_pack/colors/Mustang.vim: Please rename
Package: vim-scripts Version: 20201113 Severity: normal Hi, please rename: Mustang.vim ==> mustang.vim While the scheme works even with a wrong file name, vim looks for the correct one and prints an error message on startup. Hence this only happens when set (capitalized) in .vimrc. Regards Oliver
Bug#966639: lybniz: Lybniz depends on python3-scipy
Package: lybniz Version: 3.0.4-3 Severity: important Hi, lybniz expects a scipy installation present, but it's currently missing from the dependencies: Versions of packages lybniz depends on: ii gir1.2-gdkpixbuf-2.0 2.40.0+dfsg-5 ii gir1.2-glib-2.0 1.64.1-1 ii gir1.2-gtk-3.03.24.20-1 ii gir1.2-pango-1.0 1.44.7-4 ii python3 3.8.2-3 ii python3-cairo 1.16.2-4 ii python3-gi3.36.0-4 lybniz recommends no packages. lybniz suggests no packages.
Bug#960069: capstone-tool: Please consider moving to utils section
Package: capstone-tool Version: 4.0.1+really+3.0.5-2 Severity: wishlist Hi there, capstone-tool is in section libs despite providing no "necessary functionality" for other software. Only dependency being "forensics-all", but that isn't a real package. It seems unwarranted and rather unconventional since it doesn't include any libraries of its own nor do any need it. It's just the binary, presumably once split off the core capstone package. Enhancements like this usually go, and would be searched, in utils. Also bear in mind that without proper marking and by default, tools like deborphan currently select it for removal, as it appears to be unneeded and a "library". Regards, Oliver
Bug#941563: binfmtc: Example scripts no longer work
Package: binfmtc Version: 0.17-2+b1 Severity: important Hi, realcsh.c and realcxxsh.cc are broken, apparently no longer linking correctly to readline: /usr/bin/ld: /tmp/ccx5pXpn.o: in function `main': /usr/bin/realcsh.c:64: undefined reference to `readline' /usr/bin/ld: /usr/bin/realcsh.c:72: undefined reference to `add_history' collect2: error: ld returned 1 exit status binfmtc: Compilation failed for /usr/bin/realcsh.c, see above messages for details Not sure what's wrong, but it does indeed look like it started with the last readline upgrade. Both of them worked at least a couple of months ago. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Versions of packages binfmtc depends on: ii binfmt-support 2.2.0-2 ii binutils2.32.51.20190909-1 ii g++ 4:9.2.1-3.1 ii gcc 4:9.2.1-3.1 ii libc6 2.29-2 Versions of packages binfmtc recommends: ii libreadline-dev 8.0-3 Versions of packages binfmtc suggests: pn gcj-jdk pn gfortran
Bug#939615: rtkit: Flooding syslog
Package: rtkit Version: 0.12-4 Severity: important Tags: upstream Hello, beginning with the latest update, rtkit-daemon is filling my syslog with near identical, informational messages like: Sep 06 20:41:57 localhost rtkit-daemon[14050]: Supervising 17 threads of 9 processes of 1 users. Sep 06 20:41:57 localhost rtkit-daemon[14050]: Supervising 17 threads of 9 processes of 1 users. Sep 06 20:41:57 localhost rtkit-daemon[14050]: Supervising 17 threads of 9 processes of 1 users. Sep 06 20:41:57 localhost rtkit-daemon[14050]: Supervising 17 threads of 9 processes of 1 users. Sep 06 20:41:56 localhost rtkit-daemon[14050]: Supervising 17 threads of 9 processes of 1 users. Sep 06 20:41:56 localhost rtkit-daemon[14050]: Successfully made thread 14634 of process 14618 owned by '1000' RT at priority 10. Sep 06 20:41:56 localhost rtkit-daemon[14050]: Supervising 16 threads of 9 processes of 1 users. Sep 06 20:41:56 localhost rtkit-daemon[14050]: Supervising 16 threads of 9 processes of 1 users. Sep 06 20:41:56 localhost rtkit-daemon[14050]: Successfully made thread 14635 of process 14618 owned by '1000' RT at priority 10. Sep 06 20:41:56 localhost rtkit-daemon[14050]: Supervising 15 threads of 8 processes of 1 users. Sep 06 20:41:56 localhost rtkit-daemon[14050]: Supervising 15 threads of 8 processes of 1 users. (...) See also: https://bugs.launchpad.net/ubuntu/+source/rtkit/+bug/1547589 Currently, in order to stop it I too had to uninstall as there doesn't seem to be an easy way to terminate it and rtkit-daemon apparently has no option to disable logging or even to reduce its level. Greetings, Oliver
Bug#873818: iproute2: Keeping the man page is confusing
Package: iproute2 Version: 5.2.0-1 Followup-For: Bug #873818 Hi, the package still ships a man page for ifstat, why is that? Briefly judging from the changelog I guess it's just been overlooked following a revert. It probably should be removed, or at least add a short hint to the readme confirming the removal. Kind regards, Oliver
Bug#917881: gforth: Cannot upgrade 0.7.3.+dfsg-7 on Sid, gforth-common unavailable.
Package: gforth Version: 0.7.3+dfsg-7 Severity: normal Hi! Very likely only temporary, yet just in case of an oversight: Gforth is currently stuck in unstable as gforth-common lags behind. Nothing serious, nothing's broken, we're around the holidays, but it's a couple of days now and the changelog doesn't look like trouble so I'll just post a tip-off. Greetings, Oliver -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gforth depends on: ii emacsen-common 3.0.4 ii gforth-common 0.7.3+dfsg-7 ii gforth-lib 0.7.3+dfsg-7 ii libc6 2.28-4 ii libffi6 3.2.1-9 ii libltdl72.4.6-6 gforth recommends no packages. gforth suggests no packages.
Bug#914960: openbox: Missing alternative in recommends
Package: openbox Version: 3.6.1-7 Severity: minor Hi! Openbox recommends obconf, which is GTK based, but there's also a Qt-version available, obconf-qt, providing roughly equivalent functionality. I'd like to suggest both being recommended as an option. Recommendations should be satisfiable without having to install duplicate software. Best regards, Oliver
Bug#910043: links2: misspelled options in help and man page
Package: links2 Version: 2.17-1 Severity: minor Tags: upstream Hi, the following options as per man page and links2 -h -html-t-text-color <0>-<15> Text color in text mode. -html-t-link-color <0>-<15> Link color in text mode. -html-t-background-color <0>-<7> Background color in text mode. -html-t-ignore-document-color <0>/<1> Ignore colors specified in html document in text mode. do not actually expect the -t- signifier, they once did probably. I haven't looked into the sources, just found out by trial and luck, apparently because I don't like the new default with yellow links too much. ;) Never used these before, it's an older omission though, at least 2.14 has it, which is the version now packaged in Cygwin. Either way, thanks a lot for keeping this current in Debian! Oliver -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages links2 depends on: ii libbrotli1 1.0.3-1 ii libbz2-1.0 1.0.6-9 ii libc6 2.27-5 ii libcairo2 1.15.10-3 ii libdirectfb-1.7-7 1.7.7-8 ii libevent-2.1-6 2.1.8-stable-4 ii libfontconfig1 2.13.1-1 ii libgdk-pixbuf2.0-0 2.36.12-2 ii libglib2.0-02.58.1-1 ii libgomp18.2.0-4 ii libgpm2 1.20.7-5 ii libjpeg62-turbo 1:1.5.2-2+b1 ii liblz1 1.10-1 ii liblzma55.2.2-1.3 ii libpng16-16 1.6.34-1 ii librsvg2-2 2.40.20-2 ii libssl1.1 1.1.1-1 ii libtiff54.0.9-5 ii libx11-62:1.6.6-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages links2 recommends: ii ca-certificates 20180409 ii konsole [x-terminal-emulator]4:18.04.0-1 ii qterminal [x-terminal-emulator] 0.9.0-3 ii xterm [x-terminal-emulator] 337-1 links2 suggests no packages. -- no debconf information
Bug#908642: libnet-pcap-perl: Missing export in Pcap.pm
Package: libnet-pcap-perl Version: 0.18-2+b2 Severity: normal Hi, it seems that Pcap.pm doesn't export `pcap_close` quite as intended, so e.g. sudo pcapinfo just fails with "Undefined subroutine ::pcap_close called at /usr/bin/pcapinfo line 55." Regards, Oliver -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libnet-pcap-perl depends on: ii libc6 2.27-5 ii libpcap0.8 1.8.1-6 ii perl5.26.2-7 ii perl-base [perlapi-5.26.0] 5.26.2-7 libnet-pcap-perl recommends no packages. libnet-pcap-perl suggests no packages. -- no debconf information
Bug#904627: cons: unusable due to obsolete dependency on cwd in @INC
Package: cons Version: 2.3.0.1+2.2.0-2 Severity: grave Tags: a11y upstream Justification: renders package unusable Dear Maintainer, cons unfortunately fails immediately and no longer succeeds on building even a single C source file: do "Construct" failed, '.' is no longer in @INC; did you mean do "./Construct"? at /usr/bin/cons line 689. cons: don't know how to construct "example" '.' was removed from @INC in Perl 5.26, although this has been far from optimal long before and I can't say when exactly it turned fatal. Just in case no one feels like fixing this anymore, I think it would be nice to at least mention the problems in the description, not least because cons comes with a fairly whopping (and good) man page at almost 2000 pp. As enjoyable a read as it makes for, some people might just waste a lot of time, esp. since the changelog promises a last known-to-be-good version (yes, dating from 2006). Regards, Oliver -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages cons depends on: ii perl [libdigest-md5-perl] 5.26.2-6 cons recommends no packages. cons suggests no packages. -- no debconf information
Bug#903093: ddir: Spurious close on dirhandle
Package: ddir Version: 2016.1029+gitce9f8e4-1 Severity: important Tags: patch upstream Hello, ddir is fairly broken on my machine due to a possible typo in what appears to be a more recent addition. Use closedir instead of close: 496c496 < closedir $DIR or warn "Close failure: $ERRNO $dir"; --- > close $DIR or warn "Close failure: $ERRNO $dir"; Regards, Oliver -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages ddir depends on: ii perl 5.26.2-6 ddir recommends no packages. ddir suggests no packages. -- no debconf information
Bug#847918: python3-pip: Can be closed.
Package: python3-pip Followup-For: Bug #847918 Hi, this report can be closed. As could've been deduced from the error message, the crash was rather due to a local version conflict between pip and Setuptools. It appears I had accidentally updated my system version of the latter, instead of a user or pyvenv installation. So this is not a bug. Oliver -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-pip depends on: ii ca-certificates 20161130+nmu1 ii python-pip-whl 9.0.1-2 ii python3 3.5.3-3 Versions of packages python3-pip recommends: ii build-essential 12.3 ii python3-dev 3.5.3-3 ii python3-setuptools 36.0.1-1 ii python3-wheel 0.29.0-2 python3-pip suggests no packages. -- no debconf information
Bug#860395: cppcheck: Missing reference to gui package.
Package: cppcheck Version: 1.76.1-1 Severity: minor Hi there! ´cppcheck´ is currently without suggestion/recommendation, yet there is a gui package. Please include some reference to ´cppcheck-gui´, I think a suggestion would do the trick. Thank you. Oliver -- System Information: Debian Release: 9.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages cppcheck depends on: ii libc62.24-9 ii libgcc1 1:6.3.0-12 ii libpcre3 2:8.39-3 ii libstdc++6 6.3.0-12 ii libtinyxml2-44.0.1-1 ii python-pygments 2.2.0+dfsg-1 pn python:any cppcheck recommends no packages. cppcheck suggests no packages. -- no debconf information
Bug#847918: python3-pip: Exception on 'pip3 list --outdated'
Package: python3-pip Version: 9.0.1-1 Severity: normal Tags: upstream Pip3 fails when attempting to list only outdated packages with pip3 list -o: Exception: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/pip/basecommand.py", line 215, in main status = self.run(options, args) File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 157, in run packages = self.get_outdated(packages, options) File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 168, in get_outdated dist for dist in self.iter_packages_latest_infos(packages, options) File "/usr/lib/python3/dist-packages/pip/commands/list.py", line 169, in if dist.latest_version > dist.parsed_version TypeError: unorderable types: Version() > SetuptoolsVersion() Similar options (-u/-e/..) seem unaffected and work as expected. Note that this is coming from my system Python 3, i.e. currently 3.5.2, on Stretch, and only applies to pip3. Pip2 list -o doesn't fail. I'm using Debian's original pip3 package. Getting same result after reinstalling (pip), so I don't think it's locally broken. Also might not even be an upstream problem, at least I'm not getting the error on other platforms, as far as I can say. Gr. Oliver -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.8.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages python3-pip depends on: ii ca-certificates 20161102 ii python-pip-whl 9.0.1-1 pn python3:any Versions of packages python3-pip recommends: ii build-essential 12.2 ii python3-dev 3.5.1-4 ii python3-setuptools 28.7.1-1 ii python3-wheel 0.29.0-2 python3-pip suggests no packages.
Bug#799427: links2: Links segfaults on selecting Version in "About" menu
Package: links2 Version: 2.11-1 Severity: normal Tags: upstream Hi, when invoking the About window from the Help menu and then selecting 'Version', Links will crash immediately. Back in the shell I'm left with the following information: ''' INTERNAL ERROR at menu.c.:211: menu_version: text mismatched Forcing core dump Segmentation fault ''' Selecting "Ok" instead closes the window and leaves the menu context, as expected. Since I haven't seen this before and the system I'm filing the bug from doesn't produce core dumps, I can unfortunately not provide one yet. The behavior is however easily reproducible and it doesn't appear as if anything I did before is relevant. The same crash occurs if it's the first thing I do upon starting Links. It also doesn't matter whether Links is running in text or graphics mode. While I'd like to mention that the About page already states "Links 2.11", which one may think renders a further "Version" option somewhat redundant: It's still there, and can be selected, so whatever one might expect from it, the program should not crash. Thank you. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.1.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages links2 depends on: ii libbz2-1.0 1.0.6-8 ii libc6 2.19-20 ii libcairo2 1.14.2-2 ii libdirectfb-1.2-9 1.2.10.0-5.1 ii libevent-2.0-5 2.0.21-stable-2 ii libgdk-pixbuf2.0-0 2.31.7-1 ii libglib2.0-02.44.1-1.1 ii libgomp15.2.1-17 ii libgpm2 1.20.4-6.1+b2 ii libjpeg62-turbo 1:1.4.1-2 ii liblzma55.1.1alpha+20120614-2.1 ii libpng12-0 1.2.50-2+b2 ii librsvg2-2 2.40.10-1 ii libssl1.0.0 1.0.2d-1 ii libtiff54.0.5-1 ii libx11-62:1.6.3-1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages links2 recommends: ii konsole [x-terminal-emulator] 4:15.08.1-1 ii xterm [x-terminal-emulator]320-1 links2 suggests no packages. -- no debconf information
