Bug#1038134: g++-12: Conditional compilation error in optimized mode
I don't understand how this is a bug. Calling a member function on a null pointer is clearly UB. There is already a flag to support non-standard programs like this (-fno-delete-null-pointer-checks), but it's not enabled by default, of course.
Bug#953980: E117: Unknown function: vifm#globals#Init
Package: vifm: Version: 0.10-1 There is error E117 in vim after vim-addon-manager install vifm. Error detected while processing /var/lib/vim/addons/plugin/vifm.vim: line 50: E117: Unknown function: vifm#globals#Init /var/lib/vim/addons/plugin/vifm.vim: symbolic link to /usr/share/vim/addons/plugin/vifm.vim
Bug#824827: mixmaster: hold on..
Package: mixmaster Version: 3.0.0-8.1 Followup-For: Bug #824827 Dear Maintainer, > The bug reporter is incorrect about the status of mixmaster, it's > not designed to use 4k keys so it is hardly surprising that it fails > when you try to use them. You continue to misunderstand the bug report. This is not a feature request for 4k key support. The bug is that mixmaster selects incompatible (4k key) remailers for the chain, it means 4k keys are /partially/ supported (a very bad idea). In order to function, the support must be entirely one way or the other. These two bugs still remain: bug 1: mixmaster autonomously chooses to use a (so-called) unsupported chain. If 4k keys are not supported, the tool shouldn't attempt to chain through unusable nodes in the first place. bug 2: the error message "encryption failed" is absurdly vague. In the absence of a fix for bug 1, the tool should say something meaningful like: "cannot route through dizum because its keys are too large" > The project is effectively dead upstream and has been for some time. > This is mostly because it is no longer secure. It is for this reason > that I recommend it's removal. A stale upstream project is not necessarily a reason to remove a downstream project (an upstream project may be sufficiently stable). However, persistence of the above-mentioned defects are good cause for removal.
Bug#881040: chromium: No distinction between --incognito and --temp-profile in the manpage
Package: chromium Version: 58.0.3029.110-1 Severity: minor Dear Maintainer, Is there a difference between: $ chromium --temp-profile and $ chromium --incognito ? If so, it should be documented in the manpage. If not, then the --temp-profile option should be removed.
Bug#881033: bitlbee: manpage needs updates, and broken CAPTCHA on upstream bugtracker
Package: bitlbee Version: 3.5.1-1 Severity: wishlist Dear Maintainer, I'll start with the Debian-specific problem. * bug 1 (manpage) * The /man bitlbee/ cmd shows: BUGS Of course there are bugs. If you find some, please report them at http://bugs.bitlbee.org/. Perhaps that should also mention the Debian bug tracker as well? * bug 2 (upstream bug tracker broken) * There is also an upstream bug that I was unable to report because the CAPTCHA for http://bugs.bitlbee.org/ is broken. I could clearly read the CAPTCHA but all of my solutions got rejected. It's very frustrating b/c I took the time to write out a report not knowing it would be subject to a CAPTCHA, much less a broken one. Please also update the manpage to warn users that http://bugs.bitlbee.org/ does not support account creation and requires a CAPTCHA. * bug 3 (manpage) * Bitlbee saves data to /var/lib/bitlbee by default, which is important for users to realize when migrating or backing up systems. Yet this information is somewhat buried in the documentation for the "-d" option. IMO it should be louder, and follow the convention of having a FILES section in the manpage. Bug 220 is loosely related. I don't know what is meant by "configtime", but that bug report should perhaps be handled together with this one. * bug 4 (upstream bug tracker form is out of date) * I'm using version 3.5.1-1, which is not in the list of this bug reporting form. -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1509983846 WARNING torsocks[26270]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1509983846 WARNING torsocks[26272]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages bitlbee depends on: ii bitlbee-common 3.5.1-1 ii debianutils 4.8.1.1 ii libc6 2.24-11+deb9u1 ii libevent-2.0-5 2.0.21-stable-3 ii libgcrypt20 1.7.6-2+deb9u2 ii libglib2.0-02.50.3-2 ii libgnutls30 3.5.8-5+deb9u3 bitlbee recommends no packages. bitlbee suggests no packages. -- debconf information excluded
Bug#880965: chromium: incomplete bugtracker documentation in the manpage
Package: chromium Version: 58.0.3029.110-1 Severity: minor Dear Maintainer, The "bug tracker" part of the manpage mentions this: http://code.google.com/p/chromium/issues/list. It should also list the debian bug tracker, and the kind of bugs that should go there.
Bug#880112: graphviz: Nodes of SVG images do not get inserted if output is SVG
Package: graphviz Version: 2.38.0-17 Severity: normal Dear Maintainer, I created a small SVG image from a LaTeX file by running these commands: $ latex mybox.tex; #this produces a mybox.dvi file $ dvisvgm --color --output=mybox.svg mybox.dvi The mybox.svg renders just fine in Firefox. Then I created a graphviz file which contained (among other things): mynote [tooltip="some plaintext here", label="", image="mybox.svg"]; Then I ran this on that: $ dot -Tsvg:svg:core infile.gv > outfile.gv and the SVG produced does not show the SVG node, just an empty box. -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1508706863 WARNING torsocks[3757]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1508706863 WARNING torsocks[3759]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages graphviz depends on: ii libann0 1.1.2+doc-6 ii libc6 2.24-11+deb9u1 ii libcdt5 2.38.0-17 ii libcgraph62.38.0-17 ii libexpat1 2.2.0-2+deb9u1 ii libgcc1 1:6.3.0-18 ii libgd32.2.4-2+deb9u2 ii libglib2.0-0 2.50.3-2 ii libgts-0.7-5 0.7.6+darcs121130-4 ii libgvc6 2.38.0-17 ii libgvpr2 2.38.0-17 ii libstdc++66.3.0-18 ii libx11-6 2:1.6.4-3 ii libxaw7 2:1.0.13-1+b2 ii libxmu6 2:1.1.2-2 ii libxt61:1.1.5-1 Versions of packages graphviz recommends: ii fonts-liberation 1:1.07.4-2 Versions of packages graphviz suggests: pn graphviz-doc ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4.3 -- debconf information: 1508706772 WARNING torsocks[3381]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488)
Bug#880101: RM: mixmaster -- RoQA; bug 824827 is grave but treated as WONTFIX
Package: ftp.debian.org Severity: normal Before continuing, I must first say that I am a *user* making a request to remove the mixmaster package. The /reportbug/ app only offered these choices: 1 ANAIS Package removal - Architecture Not Allowed In Source. 2 ICE Package removal - Internal Compiler Error. 3 NBS Package removal - Not Built [by] Source. 4 NPOASRPackage removal - Never Part Of A Stable Release. 5 NVIU Package removal - Newer Version In Unstable. 6 ROM Package removal - Request Of Maintainer. 7 ROP Package removal - Request of Porter. 8 RoQA Package removal - Requested by the QA team. 9 other Not a package removal request, report other problems. 10 override Change override request. So I selected 8 RoQA but I'm not on the QA team. However, this is something the QA team should discuss. Rationale: The mixmaster package is effectively unmaintained*, and has reached a state of mostly broken, ultimately it diluting the Debian brand. I could not find any rules or criteria on quality standards for packages that acquire placement in an official Debian repository, but if there are any such standards mixmaster has likely fallen short of them. Grave bug 824827 was essentially treated as WONTFIX, leaving the application in a state that fails more often than not. The app relies on the services of message forwarding nodes, some of which have transitioned to more secure 4k key size. The mixmaster app (which does not support the new key size) routes messages to nodes it's not compatible with, causing traffic to be silently dropped. (*) Or perhaps mixmaster is maintained, but the package maintainer has opted to deliberately hold the package in a disfunctional state.
Bug#879965: aptitude: build-dep fails with vague (& probably bogus) error
Package: aptitude Version: 0.8.7-1 Followup-For: Bug #879965 > Can you please verify that your issue only shows up if there are > virtual packages listed in the build-dependencies (or their > dependencies), i.e. if aptitude always and only argues about virtual > packages? I have in my notes that I was able to successfully run: $ aptitude build-dep ledger=2.6.2-3.1 but when I search for "ledger" in /var/log/aptitude and /var/log/apt/*, I find no trace of that action (which I was hoping would reveal which packages were installed as a result). Can you suggest another way for me to get that information? To answer the question w.r.t mutt, I removed all non-virtual packages from the set of packages that apt-get installed: $ aptitude remove comerr-dev krb5-multidev libgnutls28-dev libgnutlsxx28 libgssrpc4 libidn11-dev libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-8 libkrb5-dev libncursesw5-dev libnotmuch-dev libp11-kit-dev libsasl2-dev libtasn1-6-dev libtokyocabinet-dev nettle-dev zlib1g-dev The idea is that if only non-virtual packages are needed, then aptitude would have no problems as far as we know. But in fact it still has a problem with the virtual package that was never needed in the first place. That is, running "aptitude --log-level=debug build-dep mutt" still produces: Unable to satisfy the build-depends: Build-Depends: libgpgme11-dev Unable to apply some actions, aborting It seems I've caught aptitude in a lie, which seems to play into this problem: $ aptitude why libgpgme11-dev Not currently installed No dependencies require to install libgpgme11-dev $ aptitude why libgpgme11 i libgpgme-dev Depends libgpgme11 (= 1.8.0-3+b2) $ aptitude show libgpgme-dev Package: libgpgme-dev Version: 1.8.0-3+b2 State: installed Automatically installed: no ... >> 4) "Unable to apply some actions" is too vague. What actions? > > Installation, Removal, Reinstallation, Configuration, etc. Do you > know any better term to describe any action on packages? If I can assume that the "Unable to apply some actions" is a final summary statement to tell the user why the high-level operation failed, then it should state what exactly prevented aptitude from printing a "success" message. As I understand it, in the course of handling a request aptitude is doing many tasks, and delegating many tasks to other tools/processes. All those tasks result in warnings, errors, and information, and perhaps in some cases silent failures that yielded no output at all. Aptitude probably doesn't have a practical way of knowing whether the child processes properly informed the user, but it does know specifically what job had what exit status, which is likely how aptitude knew in the first place that there was a blocking failure. It should tell the user "apt-get failed to find a file", for example. It's particularly important in the case of a misbehaving tool (developed externally to the aptitude project) that would fail silently, for example. -- Package-specific info: Terminal: screen.xterm-256color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.7 Compiler: g++ 6.3.0 20170406 Compiled against: apt version 5.0.1 NCurses version 6.0 libsigc++ version: 2.10.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20161126 cwidget version: 0.5.17 Apt version: 5.0.1 aptitude linkage: linux-vdso.so.1 (0x7ffddb3d) /usr/lib/x86_64-linux-gnu/torsocks/libtorsocks.so (0x7fce6f4ab000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7fce6f0f9000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fce6eec9000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fce6ec9f000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fce6ea98000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7fce6e79b000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fce6e493000) libboost_iostreams.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7fce6e27b000) libboost_filesystem.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7fce6e062000) libboost_system.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7fce6de5e000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7fce6da4a000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fce6d82d000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fce6d4ab000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fce6d1a7000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fce6cf9) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fce6cbf1000) libdl.so.2 =>
Bug#879965: aptitude: build-dep fails with vague (& probably bogus) error
Package: aptitude Version: 0.8.7-1 Severity: normal Dear Maintainer, Running "aptitude --log-level=debug build-dep mutt" produces: Unable to satisfy the build-depends: Build-Depends: libgpgme11-dev Unable to apply some actions, aborting I see a few bugs here: 1) If I omit "--log-level=debug" I get the same output. So it's unfortunate that the "debug" logging level does not clear up the extreme vagueness of the output. 2) The libgpgme11-dev package is already installed. So aptitude should not even be attempting to install it in the first place. 3) "Unable to satisfy.." is too vague, and also printing "..build-depends: Build-Depends:.." is redundant. 4) "Unable to apply some actions" is too vague. What actions? It's also important to point out that apt-get has no problem. That is, running "apt-get build-dep mutt" shows: Reading package lists... Done Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: comerr-dev krb5-multidev libgnutls28-dev libgnutlsxx28 libgssrpc4 libidn11-dev libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-8 libkrb5-dev libncursesw5-dev libnotmuch-dev libp11-kit-dev libsasl2-dev libtasn1-6-dev libtokyocabinet-dev nettle-dev zlib1g-dev 0 upgraded, 18 newly installed, 0 to remove and 0 not upgraded. Need to get 4,411 kB of archives. After this operation, 15.2 MB of additional disk space will be used. Do you want to continue? [Y/n] and apt-get simply works in this case. -- Package-specific info: Terminal: screen.xterm-256color $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.8.7 Compiler: g++ 6.3.0 20170406 Compiled against: apt version 5.0.1 NCurses version 6.0 libsigc++ version: 2.10.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 6.0.20161126 cwidget version: 0.5.17 Apt version: 5.0.1 aptitude linkage: linux-vdso.so.1 (0x7fff9b26) /usr/lib/x86_64-linux-gnu/torsocks/libtorsocks.so (0x7fb9a8c2b000) libapt-pkg.so.5.0 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.5.0 (0x7fb9a8879000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fb9a8649000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fb9a841f000) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7fb9a8218000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7fb9a7f1b000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7fb9a7c13000) libboost_iostreams.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.62.0 (0x7fb9a79fb000) libboost_filesystem.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.62.0 (0x7fb9a77e2000) libboost_system.so.1.62.0 => /usr/lib/x86_64-linux-gnu/libboost_system.so.1.62.0 (0x7fb9a75de000) libxapian.so.30 => /usr/lib/x86_64-linux-gnu/libxapian.so.30 (0x7fb9a71ca000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fb9a6fad000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7fb9a6c2b000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fb9a6927000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7fb9a671) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fb9a6371000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fb9a616d000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fb9a5f56000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fb9a5d3c000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fb9a5b2c000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fb9a5906000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7fb9a56f4000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fb9a54ec000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7fb9a52e7000) /lib64/ld-linux-x86-64.so.2 (0x7fb9a9457000) -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1509112945 WARNING torsocks[10625]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1509112945 WARNING torsocks[10627]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common0.8.7-1 ii libapt-pkg5.0 1.4.8 ii
Bug#879856: okular(25652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig:
Package: okular Version: 4:16.08.2-1+b1 Severity: minor Dear Maintainer, When okular is invoked on the commandline, the terminal from which it launches is junked up with this: okular(25652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(25652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(25652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: okular(25652)/kdecore (KConfigSkeleton) KCoreConfigSkeleton::writeConfig: If that noise is necessary, it should be re-worded so users know what the message is trying to convey. Otherwise it should be silenced. -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1509013311 WARNING torsocks[10749]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1509013311 WARNING torsocks[10751]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages okular depends on: ii kde-runtime 4:16.08.3-2 ii libc6 2.24-11+deb9u1 ii libfreetype62.6.3-3.2 ii libjpeg62-turbo 1:1.5.1-2 ii libkdecore5 4:4.14.26-2 ii libkdeui5 4:4.14.26-2 ii libkexiv2-114:15.04.3-1 ii libkio5 4:4.14.26-2 ii libkparts4 4:4.14.26-2 ii libkprintutils4 4:4.14.26-2 ii libkpty44:4.14.26-2 ii libokularcore7 4:16.08.2-1+b1 ii libphonon4 4:4.9.0-4 ii libpoppler-qt4-40.48.0-2 ii libqca2 2.1.1-4+b2 ii libqimageblitz4 1:0.0.6-4+b2 ii libqmobipocket1 4:16.08.0-1 ii libqt4-dbus 4:4.8.7+dfsg-11 ii libqt4-declarative 4:4.8.7+dfsg-11 ii libqt4-svg 4:4.8.7+dfsg-11 ii libqt4-xml 4:4.8.7+dfsg-11 ii libqtcore4 4:4.8.7+dfsg-11 ii libqtgui4 4:4.8.7+dfsg-11 ii libsolid4 4:4.14.26-2 ii libspectre1 0.2.8-1 ii libstdc++6 6.3.0-18 ii phonon 4:4.9.0-4 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages okular recommends: ii cups-bsd 2.2.1-8 Versions of packages okular suggests: ii ghostscript9.20~dfsg-3.2+deb9u1 pn jovie pn okular-extra-backends ii poppler-data 0.4.7-8 ii texlive-binaries 2016.20160513.41080.dfsg-2 ii unrar 1:5.3.2-1+deb9u1
Bug#878958: apt: dupe
Package: apt Version: 1.4.8 Followup-For: Bug #878958 Dear Maintainer, Sorry this is a duplicate of bug 878166. I didn't notice that the original report was rerouted. Please close or delete this bug report. Thanks. -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (no /etc/apt/preferences.d/* present) -- -- (/etc/apt/sources.list present, but not submitted) -- -- (/etc/apt/sources.list.d/gc2latex.list present, but not submitted) -- -- (/etc/apt/sources.list.d/gc2latex.list.save present, but not submitted) -- -- (/etc/apt/sources.list.d/gc2latex.list~ present, but not submitted) -- -- (/etc/apt/sources.list.d/ring-nightly-main.list present, but not submitted) -- -- (/etc/apt/sources.list.d/ring-nightly-main.list.save present, but not submitted) -- -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1508313750 WARNING torsocks[7419]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1508313750 WARNING torsocks[7421]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt depends on: ii adduser 3.115 ii debian-archive-keyring 2017.5 ii gpgv2.1.18-8~deb9u1 ii init-system-helpers 1.48 ii libapt-pkg5.0 1.4.8 ii libc6 2.24-11+deb9u1 ii libgcc1 1:6.3.0-18 ii libstdc++6 6.3.0-18 Versions of packages apt recommends: ii gnupg 2.1.18-8~deb9u1 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.7-1 ii dpkg-dev1.18.24 ii powermgmt-base 1.31+nmu1 pn python-apt ii synaptic0.84.2 -- debconf information excluded
Bug#878958: apt: let admins decide security matters not the apt team
Package: apt Version: 1.4.8 Severity: wishlist Dear Maintainer, Aptitude developers have taken the liberty of deciding for everyone subjectively what quality of cryptographic signature is adequate for everyone in a single sweeping decision, without knowing the individual threat models and assets that the decision is trying to protect. This decision is in the wrong hands. Sys admins are accountable for the security of the systems they control, and so responsibility and control should go to the same people who have accountability. Specifically, consider the SHA1 removal, documented here: https://wiki.debian.org/Teams/Apt/Sha1Removal If the apt team must decide on everyones security standards, blocking SHA1 was a good move. But that's not the case. The apt suite of tools could have some sensible defaults as far as which signing algorithms are accepted or not, but ultimately the admin should be in control of her own system. Maybe an admin finds SHA256 insufficient, and requires an even higher standard. Who is the apt team to tell her which algorithm she may and may not trust? There is a hack to say trust all, which can even be used on a per repository basis or all repositories, but this is the wrong mechanism as it disables validity checking entirely. The sys admin should control which algorithms are fit for purpose, and the apt tool should check validity on admin-permitted algorithms. -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (no /etc/apt/preferences.d/* present) -- -- (/etc/apt/sources.list present, but not submitted) -- -- (/etc/apt/sources.list.d/gc2latex.list present, but not submitted) -- -- (/etc/apt/sources.list.d/gc2latex.list.save present, but not submitted) -- -- (/etc/apt/sources.list.d/gc2latex.list~ present, but not submitted) -- -- (/etc/apt/sources.list.d/ring-nightly-main.list present, but not submitted) -- -- (/etc/apt/sources.list.d/ring-nightly-main.list.save present, but not submitted) -- -- System Information: Debian Release: 9.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=1508228706 WARNING torsocks[12992]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8), LANGUAGE=en_US.UTF-8 (charmap=1508228706 WARNING torsocks[12994]: [syscall] Unsupported syscall number 217. Denying the call (in tsocks_syscall() at syscall.c:488) UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apt depends on: ii adduser 3.115 ii debian-archive-keyring 2017.5 ii gpgv2.1.18-8~deb9u1 ii init-system-helpers 1.48 ii libapt-pkg5.0 1.4.8 ii libc6 2.24-11+deb9u1 ii libgcc1 1:6.3.0-18 ii libstdc++6 6.3.0-18 Versions of packages apt recommends: ii gnupg 2.1.18-8~deb9u1 Versions of packages apt suggests: pn apt-doc ii aptitude0.8.7-1 ii dpkg-dev1.18.24 ii powermgmt-base 1.31+nmu1 pn python-apt ii synaptic0.84.2 -- debconf information excluded
Bug#878166: aptitude: feature request: admins should determine their security stand team
Package: aptitude Version: 0.6.11-1+b1 Severity: wishlist Dear Maintainer, Aptitude developers have taken the liberty of deciding for everyone subjectively what quality of cryptographic signature is adequate for everyone in a single sweeping decision, without knowing the individual threat models and assets that the decision is trying to protect. This decision is in the wrong hands. Specifically, consider the SHA1 removal, documented here: https://wiki.debian.org/Teams/Apt/Sha1Removal If the apt team must decide on everyones security standards, blocking SHA1 was a good move. But that's not the case. The apt suite of tools could have some sensible defaults as far as which signing algorithms are accepted or not, but ultimately the admin should be in control of her own system. Maybe an admin finds SHA256 insufficient, and requires an even higher standard. Who is the apt team to tell her which algorithm she may and may not trust? There is a hack to say trust all, which can even be used on a per repository basis or all repositories, but this is the wrong mechanism as it disables validity checking entirely. The sys admin should control which algorithms are fit for purpose, and the apt tool should check validity on admin-permitted algorithms. -- Package-specific info: Terminal: screen $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.11 compiled at Nov 8 2014 13:34:39 Compiler: g++ 4.9.1 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.4.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20140913 cwidget version: 0.5.17 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x7ffde62f) /usr/lib/torsocks/libtorsocks.so (0x7f561b87) libapt-pkg.so.4.12 => /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7f561b50) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f561b2ca000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f561b0a) libsigc-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f561ae9a000) libcwidget.so.3 => /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f561ab84000) libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f561a8bb000) libboost_iostreams.so.1.55.0 => /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7f561a6a3000) libxapian.so.22 => /usr/lib/libxapian.so.22 (0x7f561a292000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f561a075000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f5619d6a000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f5619a69000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f5619853000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f56194a8000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7f56192a4000) libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x7f56190a1000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7f5618e86000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f5618c76000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f5618a53000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7f561884b000) libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f5618646000) /lib64/ld-linux-x86-64.so.2 (0x7f561c0d5000) -- System Information: Debian Release: 8.6 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common 0.6.11-1 ii libapt-pkg4.121.0.9.8.3 ii libboost-iostreams1.55.0 1.55.0+dfsg-3 ii libc6 2.19-18+deb8u6 ii libcwidget3 0.5.17-2 ii libgcc1 1:4.9.2-10 ii libncursesw5 5.9+20140913-1+b1 ii libsigc++-2.0-0c2a2.4.0-1 ii libsqlite3-0 3.8.7.1-1+deb8u2 ii libstdc++64.9.2-10 ii libtinfo5 5.9+20140913-1+b1 ii libxapian22 1.2.19-1+deb8u1 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc] 0.6.11-1 ii libparse-debianchangelog-perl 1.2.0-1.1 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: ii apt-xapian-index 0.47 pn debtags ii tasksel 3.31+deb8u1 -- no debconf information
Bug#806553: gnucash: FX rate dialog forced when all accounts are euro (loan repayme issue)
Package: gnucash Version: 1:2.6.4-3 Severity: normal Dear Maintainer, With all accounts configured as euro, there is a situation where the user is forced to enter an EUR/USD exchange rate. These are the steps to reproduce: 1) make sure EUR is the default currency for the books, and add these EUR-denominated accounts: Assets:current Liabilities:tax loan Expenses:interest Expenses:tax (not really needed to show bug) 2) Actions > Scheduled Transactions > Mortgage & Loan Repayment.. 3) Enter some arbitrary figures into the wizard. Make the loan for 6 months or so, and use a more sensible rate like 1%. Supply the step 1 accounts in the corresponding fields. Finish the wizard. 4) Actions > Scheduled Transactions > Scheduled Transaction Editor 5) Open the new loan. Tick "create automatically" and "create in advance", and set the advance creation to ~700 days. That will ensure that all transactions are pushed to the register. 6) Save, exit, and start gnucash again to make sure the scheduler runs. 7) Open one of the transactions with the splits showing. 8) Reduce the principle amount by an arbitrary amount. Before you can increase the principle by the same amount, gnucash will force an EUR/USD exchange rate dialog even though all accounts are in euros. Where does USD come from? Apparently the amortization scheduling tool assumes USD for something. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnucash depends on: ii gnucash-common 1:2.6.4-3 ii guile-2.0 2.0.11+1-9 ii guile-2.0-libs 2.0.11+1-9 ii libaqbanking34 5.4.3beta-2+b1 ii libaqbanking34-plugins 5.4.3beta-2+b1 ii libc6 2.19-18+deb8u1 ii libcairo2 1.14.0-2.1 ii libcrypt-ssleay-perl 0.58-1+b2 ii libdate-manip-perl 6.47-1 ii libdbi10.9.0-4 ii libfinance-quote-perl 1.35-1 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u2 ii libglib2.0-0 2.42.1-1 ii libgnome-keyring0 3.12.0-1+b1 ii libgnomecanvas2-0 2.30.3-2 ii libgoffice-0.8-8 0.8.17-3 ii libgtk2.0-02.24.25-3 ii libgwengui-gtk2-0 4.12.0beta-3+b1 ii libgwenhywfar604.12.0beta-3+b1 ii libhtml-tableextract-perl 2.11-1 ii libhtml-tree-perl 5.03-1 ii libktoblzcheck1c2a 1.47-1 ii libofx61:0.9.10-1 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-01.36.8-3 ii libpython2.7 2.7.9-2 ii libwebkitgtk-1.0-0 2.4.8-2 ii libwww-perl6.08-1 ii libx11-6 2:1.6.2-3 ii libxml22.9.1+dfsg1-5 ii libxslt1.1 1.1.28-2+b2 ii perl 5.20.2-3+deb8u1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages gnucash recommends: ii gnucash-docs 2.6.4-1 ii yelp 3.14.1-1 Versions of packages gnucash suggests: pn libdbd-mysql pn libdbd-pgsql ii libdbd-sqlite3 0.9.0-3 -- no debconf information
Bug#804760: gnus-agent-regenerate-group => Invalid read syntax: . in wrong context
Package: emacs24 Version: 24.4+1-5 Severity: important Dear Maintainer, A particular newsgroup breaks gnus in an irrecoverable way. Gnus cannot open a group with content from "gwene.com.fatwallet.hotdeals" from the news.gmane.org server (filed in bug# 797409). Two other gnus functions fail when trying to recover: * gnus-agent-regenerate-group * gnus-agent-expire-group Those two commands fail with: Invalid read syntax: ". in wrong context" This is very severe, because regenerating the group is the only function to recover from other bugs, and this function itself is broken. It's not even possible to delete the messages, because the group cannot be entered. It's a complete stalemate. The bugs are so entrenched that there is no way to recover from this. -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages emacs24 depends on: ii emacs24-bin-common 24.4+1-5 ii gconf-service 3.2.6-3 ii libacl12.2.52-2 ii libasound2 1.0.28-1 ii libatk1.0-02.14.0-1 ii libc6 2.19-18+deb8u1 ii libcairo-gobject2 1.14.0-2.1 ii libcairo2 1.14.0-2.1 ii libdbus-1-31.8.20-0+deb8u1 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3+deb8u1 ii libgconf-2-4 3.2.6-3 ii libgdk-pixbuf2.0-0 2.31.1-2+deb8u2 ii libgif44.1.6-11 ii libglib2.0-0 2.42.1-1 ii libgnutls-deb0-28 3.3.8-6+deb8u3 ii libgomp1 4.9.2-10 ii libgpm21.20.4-6.1+b2 ii libgtk-3-0 3.14.5-1+deb8u1 ii libice62:1.0.9-1+b1 ii libjpeg62-turbo1:1.3.1-12 ii libm17n-0 1.6.4-3 ii libmagickcore-6.q16-2 8:6.8.9.9-5 ii libmagickwand-6.q16-2 8:6.8.9.9-5 ii libotf00.9.13-2 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-01.36.8-3 ii libpng12-0 1.2.50-2+b2 ii librsvg2-2 2.40.5-1 ii libselinux12.3-2 ii libsm6 2:1.2.2-1+b1 ii libtiff5 4.0.3-12.3 ii libtinfo5 5.9+20140913-1+b1 ii libx11-6 2:1.6.2-3 ii libxft22.3.2-1 ii libxinerama1 2:1.1.3-1+b1 ii libxml22.9.1+dfsg1-5 ii libxpm41:3.5.11-1+b1 ii libxrandr2 2:1.4.2-1+b1 ii libxrender11:0.9.8-1+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 emacs24 recommends no packages. Versions of packages emacs24 suggests: pn emacs24-common-non-dfsg -- no debconf information
Bug#801734: tclcurl: file output lost if -file option is used
Package: tclcurl Version: 7.22.0-1 Severity: important Dear Maintainer, This is similar to (unfixed) bug 680662 (from 3 yrs ago), but much more severe. When the "-file" option is used for a GET, the file will be zero in size with all data lost if the -bodyvar option is used in a later transaction. This is very astonishing, baffling, and frustrating to users who have little hope of knowing what's wrong. After much time analyzing strace output, it became clear what happens. The file is opened for writing, and the data is in fact sent, but the file is not closed. Then use of -bodyvar causes the filename previously used for the -file option to be opened again! And it's not opened in append mode either. To worsen diagnosis, nothing is written to the file, so the user cannot see that the past filename was reused in the following operation. This bug has a high chance of occurrance, because any session that involves a logout at the end is likely to use -bodyvar and not -file, because it's not interesting to save the "goodbye" page in a file, but perhaps useful to render the variable to show the user. This is the demonstration script, which includes commented-out workarounds: 8< #!/usr/bin/tclsh8.6 package require TclCurl set curlHandle [::curl::init] $curlHandle configure -url http://bugs.debian.org\ -file /tmp/directly_written_file.html $curlHandle perform puts "strace shows that the file was opened and written to (but never closed)" # There are two undocumented workarounds at this point. # # (1) This workaround is the most intuitive, but it does not always # work! It's also quite inconvenient because pre-existing config # options must be reconfigured afterwards: # # $curlHandle reset # # (2) This workaround seems to always work, but very non-intuitive. # Most users have no hope of figuring this out. They will just # wonder why their file is not being written. # # $curl_handle configure -file /dev/null $curlHandle configure -url http://www.fsf.org\ -bodyvar payload_fsf $curlHandle perform puts "this 2nd /perform/ is where the damage is done." puts "strace shows the same file is opened again even though bodyvar is used instead of -file." puts "the reopening of the same filename causes it to get clobbered before it is written and closed." $curlHandle cleanup puts "file holds: [exec cat /tmp/directly_written_file.html]" 8< -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages tclcurl depends on: ii libc62.19-18+deb8u1 ii libcurl3-gnutls 7.38.0-4+deb8u2 ii tcl [tclsh] 8.6.0+8 tclcurl recommends no packages. Versions of packages tclcurl suggests: pn libcurl4-gnutls-dev -- no debconf information
Bug#800719: qpdf fussy about malformed metadata
Package: qpdf
Version: 5.1.2-2
Severity: minor
Dear Maintainer,
When a PDF is produced that contains malformed metadata, qpdf chokes
on it when trying to encrypt it with an error like:
(file position 16068): unknown token while reading object (CatB)
You may not regard this as a bug. Feel free to disregard. But I
should point out that pdftk can encrypt the same file without issues,
so it is at least possible for qpdf to be more forgiving, FWIW.
This example script demonstrates:
8<
#!/bin/bash
# This script demonstrates how to break qpdf by generating a PDF with
# (bad?) metadata. It's a self-contained example requiring no input
# files - only tools. These are the steps:
#
# 1) auto-generate a PDF file with some dummy text, such that the
# "keywords" field in the metadata is malformed.
# 2) show that qpdf errors:
# (file position 16068): unknown token while reading object (CatB)
# 3) show that pdftk can encrypt the same document without trouble.
#
# Tools required:
#
# * LaTeX
# * qpdf
# * pdftk (optional)
# 1) auto-generate a PDF file with some dummy text
latex_fn="$(tempfile -p doc_ -s .tex)"
latex_doc() {
printf %s '
\documentclass[pdftex]{article}
\usepackage{lipsum}
% notice that /keywords/ is not using paranthesis to delimit the
% content (which is incorrect, but pdflatex accepts this anyway and
% produces a usable document although without keywords).
\pdfinfo{
/Author (Eric S. Raymond)
/Subject (Musings on Linux and Open Source by an Accidental Revolutionary)
/Title (The Cathedral and the Bazaar)
/Keywords CatB
}
\begin{document}
\lipsum[2]
\end{document}
'
}
latex_doc >"$latex_fn"
pushd "$(dirname "$latex_fn")"
pdflatex "$latex_fn"
pdf_fn="${latex_fn//.tex/.pdf}"
# 2) qpdf errors and produces a zero size file
qpdf --encrypt foo foo 40 -- "$pdf_fn" qpdf_rc4.pdf
# 3) the equivalent pdftk operation produces a usable file in /tmp/
pdftk "$pdf_fn" cat output pdftk_rc4.pdf allow AllFeatures user_pw foo
popd
8<
BTW, I appreciate your feedback on my previous 2 bug reports regarding
encryption. I'm sorry that they turned out to be false alarms.
-- System Information:
Debian Release: 8.2
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages qpdf depends on:
ii libc6 2.19-18+deb8u1
ii libgcc1 1:4.9.2-10
ii libpcre32:8.35-3.3
ii libqpdf13 5.1.2-2
ii libstdc++6 4.9.2-10
ii zlib1g 1:1.2.8.dfsg-2+b1
qpdf recommends no packages.
qpdf suggests no packages.
-- no debconf information
Bug#799526: pdftk: update_info cannot eat its own dogfood
Package: pdftk Version: 2.02-2 Severity: normal Dear Maintainer, The "pdftk --help" documentation states that the update_info function is expecting the same format of data from the dump_data function. However, it does not work on a variety of files, even with no alterations. E.g. $ pdftk foo.pdf dump_data | pdftk foo.pdf update_info - Done. Input errors, so no output created. If the piping seems questionable, even the normal approach breaks: $ pdftk foo.pdf dump_data output dogfood.txt $ pdftk foo.pdf update_info dogfood.txt Done. Input errors, so no output created. -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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 pdftk depends on: ii libc6 2.19-18 ii libgcc1 1:4.9.2-10 ii libgcj154.9.2-10 ii libstdc++6 4.9.2-10 pdftk recommends no packages. Versions of packages pdftk suggests: ii poppler-utils [xpdf-utils] 0.26.5-2 -- no debconf information
Bug#793447: mutt: attached images not fed to graphical browsers
Package: mutt Version: 1.5.23-3 Severity: normal Dear Maintainer, MIME-compliant messages containing images that are referenced by an HTML attachment do not render with the images because mutt does not unpack them. While it's understandable that mutt users do not generally care if html can be rendered graphically, there are those rare cases where it's useful. In particular, producing printable/distributable non-forensic copies of e-mail for legal purposes, where the stationary used by an author is important. This article gives some insight - indicating that if image files are mime-unpacked, mutt's usual choice for naming attachments won't always work: https://stackoverflow.com/questions/4018709/how-to-create-an-email-with-embedded-images-that-is-compatible-with-the-most-mai the names should be formed as: cid:Content-ID a filename might look like this: image001.png@0D0B1FF0.79904F06 Note that images render correctly only if the html references an URL as opposed to a local file. -- Package-specific info: Mutt 1.5.23 (2014-03-12) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 3.16.0-4-amd64 (x86_64) ncurses: ncurses 5.9.20140913 (compiled with 5.9) libidn: 1.29 (compiled with 1.29) hcache backend: tokyocabinet 1.4.48 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-4) Configure options: '--prefix=/usr' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' '--with-mailpath=/var/mail' '--disable-dependency-tracking' '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm' Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/usr/share/mutt SYSCONFDIR=/etc EXECSHELL=/bin/sh MIXMASTER=mixmaster To contact the developers, please mail to mutt-...@mutt.org. To report a bug, please visit http://bugs.mutt.org/. misc/am-maintainer-mode.patch features/ifdef.patch features/xtitles.patch features/trash-folder.patch features/purge-message.patch features/imap_fast_trash.patch features/sensible_browser_position.patch features-old/patch-1.5.4.vk.pgp_verbose_mime.patch features/compressed-folders.patch features/compressed-folders.debian.patch debian-specific/Muttrc.patch debian-specific/Md.etc_mailname_gethostbyname.patch debian-specific/use_usr_bin_editor.patch
Bug#791452: lynx: http_proxy variable silently ignored!
Package: lynx Version: 2.8.9dev1-2 Severity: important Dear Maintainer, The http_proxy variable is silently ignored! This is very dangerous, because a privoxy/tor user who relies on this setting for privacy will be compromised, and they generally will not even be aware of the compromise because the browser retrieves pages over an untrusted connection without warning. For example, suppose a tor user configures privoxy on port 8118. This will yield an exposed session: $ export http_proxy=http://localhost:8118 $ lynx To prove that this bug exists, a tor user can run: $ http_proxy=http://127.0.0.1:8118 lynx https://torstatus.blutmagie.de/ and see the message saying that the connection is not from the tor network. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lynx depends on: ii lynx-cur 2.8.9dev1-2+b1 lynx recommends no packages. lynx suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791425: w3m: HTTP_PROXY variable silently ignored!
Package: w3m Version: 0.5.3-19 Severity: important Dear Maintainer, The HTTP_PROXY variable is silently ignored! This is very dangerous, because a privoxy/tor user who relies on this setting for privacy will be compromised, and they generally will not even be aware of the compromise because the browser retrieves pages over an untrusted connection without warning. For example, suppose a tor user configures privoxy on port 8118. This is how /usr/share/doc/w3m/FAQ.html documents a proxy should be configured, yet it yields an exposed session: $ export HTTP_PROXY=http://localhost:8118 $ w3m To prove that this bug exists, a tor user can run: $ HTTP_PROXY=http://127.0.0.1:8118 w3m https://torstatus.blutmagie.de/ The page reports that the connection is not from the tor network. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages w3m depends on: ii libc62.19-18 ii libgc1c2 1:7.2d-6.4 ii libgpm2 1.20.4-6.1+b2 ii libssl1.0.0 1.0.1k-3+deb8u1 ii libtinfo55.9+20140913-1+b1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages w3m recommends: ii ca-certificates 20141019 Versions of packages w3m suggests: pn cmigemo none ii man-db2.7.0.2-5 ii mime-support 3.58 pn w3m-elnone pn w3m-img none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#790112: djvulibre-bin: ddjvu: TIFF output requires a valid output file name
Package: djvulibre-bin Version: 3.5.25.4-4+b1 Severity: minor Dear Maintainer, The man page states that the output filename can be a dash or be omitted, in which case the output goes to /dev/sdtout. Assuming the documentation is correct, it's broken: $ ddjvu -format=tiff myfile.djvu /tmp/kmasdkfe.tiff ddjvu: TIFF output requires a valid output file name. $ ddjvu -format=tiff myfile.djvu - /tmp/kmasdkfe.tiff ddjvu: TIFF output requires a valid output file name. If this is a deliberate limitation of TIFF files in particular, the documentation should disclose the limitation. -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages djvulibre-bin depends on: ii curl7.38.0-4+deb8u2 ii libc6 2.19-18 ii libdjvulibre21 3.5.25.4-4+b1 ii libgcc1 1:4.9.2-10 ii libstdc++6 4.9.2-10 ii libtiff54.0.3-12.3 Versions of packages djvulibre-bin recommends: ii pdf2djvu 0.7.17-4+deb8u1 Versions of packages djvulibre-bin suggests: pn djvulibre-desktop none ii evince [djvu-viewer] 3.14.1-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#787927: mutt cannot extract attachments from iPGMail senders
Package: mutt Version: 1.5.23-3 Severity: normal Dear Maintainer, When a mutt user receives a message from an iPGMail user, and the message has attachments, the attachments are not extractable. After saving the attachment that came from an iPGMail user, the following command: $ gpg image.jpg.pgp results in: gpg: CRC error; 123456 - ABCDEF gpg: Problem reading source (534223 bytes remaining) gpg: handle plaintext failed: file read error gpg: mdc_packet with invalid encoding gpg: decryption failed: invalid packet gpg: invalid armor: line longer than 2 characters It does not matter what kind of file is attached. All file attachments that are created using iPGMail fail to decrypt in the above manner. There is still output, but the output is partially corrupt. This is evident if the attachment is an image, so a small part of the image is correct then the rest is junk. It's likely a problem with iPGMail, but I'm filing this bug because I may be wrong, or perhaps mutt could include a feature enabling recipients to salvage these corrupt attachments. -- Package-specific info: Mutt 1.5.23 (2014-03-12) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 3.16.0-4-amd64 (x86_64) ncurses: ncurses 5.9.20140913 (compiled with 5.9) libidn: 1.29 (compiled with 1.29) hcache backend: tokyocabinet 1.4.48 Compiler: Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.9.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.9.2 (Debian 4.9.2-4) Configure options: '--prefix=/usr' '--sysconfdir=/etc' '--mandir=/usr/share/man' '--with-docdir=/usr/share/doc' '--with-mailpath=/var/mail' '--disable-dependency-tracking' '--enable-compressed' '--enable-debug' '--enable-fcntl' '--enable-hcache' '--enable-gpgme' '--enable-imap' '--enable-smtp' '--enable-pop' '--with-curses' '--with-gnutls' '--with-gss' '--with-idn' '--with-mixmaster' '--with-sasl' '--without-gdbm' '--without-bdb' '--without-qdbm' '--build' 'x86_64-linux-gnu' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall' 'LDFLAGS=-Wl,-z,relro' 'CPPFLAGS=-D_FORTIFY_SOURCE=2 -I/usr/include/qdbm' Compilation CFLAGS: -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/usr/share/mutt SYSCONFDIR=/etc EXECSHELL=/bin/sh MIXMASTER=mixmaster To contact the developers, please mail to mutt-...@mutt.org. To report a bug, please visit http://bugs.mutt.org/. misc/am-maintainer-mode.patch features/ifdef.patch features/xtitles.patch features/trash-folder.patch features/purge-message.patch features/imap_fast_trash.patch features/sensible_browser_position.patch features-old/patch-1.5.4.vk.pgp_verbose_mime.patch features/compressed-folders.patch features/compressed-folders.debian.patch debian-specific/Muttrc.patch
Bug#760164: buggy argument parsing of -u and -p options
Package: torsocks Version: 2.0.0-1 Severity: minor Torsocks doesn't recognise the arguments to the -u (--user) and -p (--pass) options if they immediately follow the option characters: $ torsocks -uMyUser -pMyPass /bin/true Illegal option -u /usr/bin/torsocks: 98: local: /usr/bin/which: bad variable name It works if you put a space between the option and the argument: $ torsocks -u MyUser -p MyPass /bin/true Torsocks should support the former syntax too, as it is standard on UNIX-like systems. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758804: consider packaging scheme48 1.9.x based scsh
Package: scsh Version: 0.6.6.3 Severity: wishlist There is a newer version of scsh that is implemented as a module for scheme48 1.9.x (rather than as a fork from an old version of scheme48, as with the current version of scsh in Debian): http://github.com/scheme/scsh Unlike scsh 0.6.x, this version seems to be under active development. Please consider switching to this upstream version for the Debian scsh package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758612: store cache separately from config file
Package: get-iplayer Version: 2.86-1 Severity: wishlist get-iplayer uses the same directory (~/.get_iplayer/) to store both the user configuration file, the programme download history and the cache of available programmes (the *.cache files). As the cache files are automatically generated and their contents changes regularly, it makes sense for the user to exclude them when making backups. On the other hand, users will probably want to backup their configuration files and download history. It would help if get-iplayer allowed storing these files in separate directories. Ideally, the cache should be stored in a standard location for cache files; either a user-owned subdirectory of /var/tmp/ or the $XDG_CACHE_HOME directory defined in the XDG Base Directory Specification (usually ~/.cache/) http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745242: hdparm: Fails to unlock OPAL SSC drive (Input/Output Error)
Package: hdparm Version: 9.39-1+b1 Severity: normal Dear Maintainer, The hdparm tool was unable to unlock standard OPAL SSC drives. Two OPAL drives were tested. The first test was with a Seagate Momentus. The scenario is this: 1) The drive was first put in the stock factory configuration (that is, on the internal SATA bus of the Thinkpad T61) 2) The BIOS was used to create a password. 3) Rebooted, and the BIOS rightly asked for a password, which was used to unlock the drive. 4) The drive was removed and then usb-attached (using a JMicron bridge). 5) The BIOS does not see USB-attached OPAL drives (No Operating System). This is a T61 limitation. 6) An internal drive was installed simply to boot Debian. 7) sudo hdparm --security-unlock 1234 /dev/sdb Step 7 /appears/ to work, showing this output: 8 security_password=1234 /dev/sdb: Issuing SECURITY_UNLOCK command, password=1234, user=user 8 8) fdisk /dev/sdb fdisk: unable to read /dev/sdb: Input/output error Logs appeared in /var/log/kern.log: 8 kernel: [ 3909.886710] usb 1-3: USB disconnect, device number 3 kernel: [ 4063.740087] usb 1-3: new high-speed USB device number 4 using ehci_hcd kernel: [ 4063.880965] usb 1-3: New USB device found, idVendor=152d, idProduct=2329 kernel: [ 4063.880970] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=5 kernel: [ 4063.880973] usb 1-3: Product: USB to ATA/ATAPI bridge kernel: [ 4063.880976] usb 1-3: Manufacturer: JMicron kernel: [ 4063.880978] usb 1-3: SerialNumber: withheld kernel: [ 4063.881796] usb-storage 1-3:1.0: Quirks match for vid 152d pid 2329: 8020 kernel: [ 4063.881857] scsi6 : usb-storage 1-3:1.0 kernel: [ 4064.922813] scsi 6:0:0:0: Direct-Access ST950042 2AS PQ: 0 ANSI: 2 CCS kernel: [ 4064.925210] sd 6:0:0:0: Attached scsi generic sg2 type 0 kernel: [ 4064.925254] sd 6:0:0:0: [sdb] 976773168 512-byte logical blocks: (500 GB/465 GiB) kernel: [ 4064.925988] sd 6:0:0:0: [sdb] Write Protect is off kernel: [ 4064.925996] sd 6:0:0:0: [sdb] Mode Sense: 28 00 00 00 kernel: [ 4064.926722] sd 6:0:0:0: [sdb] No Caching mode page found kernel: [ 4064.926731] sd 6:0:0:0: [sdb] Assuming drive cache: write through kernel: [ 4064.929722] sd 6:0:0:0: [sdb] No Caching mode page found kernel: [ 4064.929730] sd 6:0:0:0: [sdb] Assuming drive cache: write through kernel: [ 4064.931710] sd 6:0:0:0: [sdb] Unhandled sense code kernel: [ 4064.931718] sd 6:0:0:0: [sdb] Result: hostbyte=invalid driverbyte=DRIVER_SENSE kernel: [ 4064.931727] sd 6:0:0:0: [sdb] Sense Key : Medium Error [current] kernel: [ 4064.931738] sd 6:0:0:0: [sdb] Add. Sense: Unrecovered read error kernel: [ 4064.931749] sd 6:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 kernel: [ 4064.931769] end_request: critical target error, dev sdb, sector 0 kernel: [ 4064.931777] Buffer I/O error on device sdb, logical block 0 ... kernel: [ 4733.049354] sd 6:0:0:0: [sdb] Unhandled sense code kernel: [ 4733.049363] sd 6:0:0:0: [sdb] Result: hostbyte=invalid driverbyte=DRIVER_SENSE kernel: [ 4733.049372] sd 6:0:0:0: [sdb] Sense Key : Medium Error [current] kernel: [ 4733.049382] sd 6:0:0:0: [sdb] Add. Sense: Unrecovered read error kernel: [ 4733.049393] sd 6:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 20 00 kernel: [ 4733.049414] end_request: critical target error, dev sdb, sector 0 kernel: [ 4733.049423] quiet_error: 151 callbacks suppressed kernel: [ 4733.049428] Buffer I/O error on device sdb, logical block 0 kernel: [ 4733.049439] Buffer I/O error on device sdb, logical block 1 kernel: [ 4733.049446] Buffer I/O error on device sdb, logical block 2 kernel: [ 4733.049453] Buffer I/O error on device sdb, logical block 3 kernel: [ 4733.050720] sd 6:0:0:0: [sdb] Unhandled sense code kernel: [ 4733.050726] sd 6:0:0:0: [sdb] Result: hostbyte=invalid driverbyte=DRIVER_SENSE kernel: [ 4733.050735] sd 6:0:0:0: [sdb] Sense Key : Medium Error [current] kernel: [ 4733.050744] sd 6:0:0:0: [sdb] Add. Sense: Unrecovered read error kernel: [ 4733.050753] sd 6:0:0:0: [sdb] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 kernel: [ 4733.050773] end_request: critical target error, dev sdb, sector 0 kernel: [ 4733.050779] Buffer I/O error on device sdb, logical block 0 8 The above scenario is on Debian Wheezy. Another experiment was done, this time with a Hitachi (model hts22016k9sa00) on Ubuntu 13.10, and in that case the hdparm command itself failed (in step 7), with the error Input/Output Error. -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux
Bug#743056: pastebinit: fails when -b is supplied a non-URL (the -l form) - please this
Package: pastebinit Version: 1.3-4 Severity: wishlist Dear Maintainer, When a -l is used to obtain a list of sites, and a choice from that list is then supplied as-is to the -b option, pastebinit behaves as if the site is unknown. E.g. $ pastebinit -a anon -b slexy.org debug.tex Unknown website, please post a bugreport to request this pastebin to be added (slexy.org) $ pastebinit -a anon -b sprunge.us debug.tex Unknown website, please post a bugreport to request this pastebin to be added (sprunge.us) $ pastebinit -a anon -b paste.pocoo.org debug.tex Unknown website, please post a bugreport to request this pastebin to be added (paste.pocoo.org) $ pastebinit -a anon -b cxg.de debug.tex Unknown website, please post a bugreport to request this pastebin to be added (cxg.de) $ pastebinit -a anon -b paste.debian.net debug.tex Unknown website, please post a bugreport to request this pastebin to be added (paste.debian.net) The -b option only works when an URL is supplied. Considering the -l option does not list URLs, pastebinit should accept hostnames as well and automatically work out what the URL is using a default scheme (like https://;). -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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 Versions of packages pastebinit depends on: ii python2.7.3-4+deb7u1 ii python-configobj 4.7.2+ds-4 Versions of packages pastebinit recommends: ii lsb-release 4.1+Debian8+deb7u1 pastebinit suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#706183: WARNING: untrusted versions of the following packages will be installe vague
Package: aptitude Version: 0.6.3-3.2+squeeze1 Severity: wishlist The following warning is too vague: vague warning WARNING: untrusted versions of the following packages will be installed! vague warning vague warning Untrusted packages could compromise your system's security. vague warning You should only proceed with the installation if you are certain that vague warning this is what you want to do. vague warning vague warning libswscale0 libavutil50 libdrm-radeon1 libdrm2 libvpx0 libdrm-intel1 libpostproc51 vague warning vague warning Do you want to ignore this warning and proceed anyway? Why is it untrusted? Are the keys missing from the users keyring? Are the keys present, but expired? Are the packages signed or unsigned? -- Package-specific info: aptitude 0.6.3 compiled at Aug 10 2011 23:28:10 Compiler: g++ 4.4.5 Compiled against: apt version 4.10.1 NCurses version 5.7 libsigc++ version: 2.2.4.2 Ept support enabled. Gtk+ support disabled. Current library versions: NCurses version: ncurses 5.7.20100313 cwidget version: 0.5.16 Apt version: 4.10.1 linux-vdso.so.1 = (0x7fff787ff000) /usr/lib/torsocks/libtorsocks.so (0x7f7134617000) libapt-pkg.so.4.10 = /usr/lib/libapt-pkg.so.4.10 (0x7f71342fd000) libncursesw.so.5 = /lib/libncursesw.so.5 (0x7f71340a9000) libsigc-2.0.so.0 = /usr/lib/libsigc-2.0.so.0 (0x7f7133ea4000) libcwidget.so.3 = /usr/lib/libcwidget.so.3 (0x7f7133bd8000) libept.so.1 = /usr/lib/libept.so.1 (0x7f7133983000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f71335a3000) libz.so.1 = /usr/lib/libz.so.1 (0x7f713338c000) libsqlite3.so.0 = /usr/lib/libsqlite3.so.0 (0x7f71330f4000) libboost_iostreams.so.1.42.0 = /usr/lib/libboost_iostreams.so.1.42.0 (0x7f7132ed9000) libpthread.so.0 = /lib/libpthread.so.0 (0x7f7132cbd000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f71329a8000) libm.so.6 = /lib/libm.so.6 (0x7f7132726000) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x7f713251) libc.so.6 = /lib/libc.so.6 (0x7f71321ad000) libdl.so.2 = /lib/libdl.so.2 (0x7f7131fa9000) libresolv.so.2 = /lib/libresolv.so.2 (0x7f7131d93000) libutil.so.1 = /lib/libutil.so.1 (0x7f7131b8f000) libuuid.so.1 = /lib/libuuid.so.1 (0x7f713198b000) libbz2.so.1.0 = /lib/libbz2.so.1.0 (0x7f713177a000) librt.so.1 = /lib/librt.so.1 (0x7f7131572000) /lib64/ld-linux-x86-64.so.2 (0x7f7134827000) Terminal: screen $DISPLAY is set. `which aptitude`: /usr/bin/aptitude aptitude version information: aptitude linkage: -- System Information: Debian Release: 6.0.7 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages aptitude depends on: ii apt [libapt-pkg4.10] 0.8.10.3+squeeze1 Advanced front-end for dpkg ii libboost-iostreams1.42 1.42.0-4 Boost.Iostreams Library ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libcwidget30.5.16-3 high-level terminal interface libr ii libept11.0.4 High-level library for managing De ii libgcc11:4.4.5-8 GCC support library ii libncursesw5 5.7+20100313-5shared libraries for terminal hand ii libsigc++-2.0-0c2a 2.2.4.2-1 type-safe Signal Framework for C++ ii libsqlite3-0 3.7.3-1 SQLite 3 shared library ii libstdc++6 4.4.5-8 The GNU Standard C++ Library v3 ii libxapian221.2.3-2 Search engine library ii zlib1g 1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages aptitude recommends: ii apt-xapian-index 0.41 maintenance and search tools for a pn aptitude-doc-en | aptitude-do none (no description available) ii libparse-debianchangelog-perl 1.1.1-2.1 parse Debian changelogs and output ii sensible-utils0.0.4 Utilities for sensible alternative Versions of packages aptitude suggests: pn debtags none (no description available) ii tasksel 2.88 Tool for selecting tasks for insta -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705027: torsocks: documentation with sources references obsolete file, and omits prerequisites
Package: torsocks Version: 1.0~epsilon+dfsg1-1 Severity: normal The INSTALL file has flaws in both the latest debian source package for torsocks, and also the latest in git. In the git version of the INSTALL document, there is a reference to Makefile.cvs, which has been obsoleted. In the debian version, there was no mention of packages that are required for building, and it takes some investigation to discover what's missing. The build process fails if the user does not have automake and libtool. Perhaps there should be an INSTALL.debian file if these packages are particular to debian. -- System Information: Debian Release: 6.0.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages torsocks depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib Versions of packages torsocks recommends: ii tor0.2.3.25-1~~squeeze+1 anonymizing overlay network for TC torsocks suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#699151: gnus: batch download of virtual groups causes error: Creating director long
Package: gnus Version: 5.11+v0.10.dfsg-3 Severity: normal A virtual group (named shopping) was created and agentified. These were the natural groups that composed the shopping group: alt.consumers.free-stuff alt.consumers.uk-freebies gwene.com.dealbreaker gwene.com.feedburner.mydealz gwene.com.fatwallet.hotdeals The download agent was executed as follows: emacs -batch -l ~/.gnus.el -f gnus-agent-batch-fetch It works up until it came time to process the new virtual group, at which point this error resulted: Creating directory: file name too long, /home/blee/news/agent/nnvirtual/^$\|\(^nntp\+news\.gmane\.org:gwene\.com\.feedburner\.mydealz$\)\|\(^alt\.consumers\.free-stuff$\)\|\(^alt\.consumers\.uk-freebies$\)\|\(^nntp\+news\.gmane\.org:gwene\.com\.dealbreaker$\)\|\(^nntp\+news\.gmane\.org:gwene\.com\.feedburner\.mydealz$\)\|\(^alt\.consumers\.free-stuff$\)\|\(^alt\.consumers\.uk-freebies$\)\|\(^nntp\+news\.gmane\.org:gwene\.com\.dealbreaker$\) The download terminated at that point. -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnus depends on: ii dpkg 1.15.8.13 Debian package management system ii install-info 4.13a.dfsg.1-6 Manage installed documentation in ii make 3.81-8 An utility for Directing compilati ii ucf 3.0025+nmu1Update Configuration File: preserv ii xemacs21 21.4.22-3.1highly customizable text editor ii xemacs21-mule [xemacs21] 21.4.22-3.1highly customizable text editor -- Versions of packages gnus recommends: ii idn1.15-2Command line and Emacs interface t ii openssl0.9.8o-4squeeze13 Secure Socket Layer (SSL) binary a Versions of packages gnus suggests: ii netpbm2:10.0-12.2+b1 Graphics conversion tools between pn w3m-elnone (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664644: openjdk-6-jre: also hangs for interactivebrokers jar files
Package: openjdk-6-jre Version: 6b18-1.8.13-0+squeeze2 Severity: normal Another example: Also hangs for interactivebrokers jar files: wget https://www.interactivebrokers.com/download/unixmacosx.jar /usr/lib/jvm/java-6-openjdk/bin/jar xf unixmacosx.jar -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages openjdk-6-jre depends on: ii libaccess-bridge- 1.26.2-5 Java Access Bridge for GNOME (jni ii libasound21.0.23-2.1 shared library for ALSA applicatio ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii libgif4 4.1.6-9library for GIF images (library) ii libjpeg62 6b1-1 The Independent JPEG Group's JPEG ii libpng12-01.2.44-1+squeeze4 PNG library - runtime ii libpulse0 0.9.21-3+squeeze1 PulseAudio client libraries ii libx11-6 2:1.3.3-4 X11 client-side library ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar ii libxi62:1.3-7X11 Input extension library ii libxrender1 1:0.9.6-1 X Rendering Extension client libra ii libxtst6 2:1.1.0-3 X11 Testing -- Record extension li ii openjdk-6-jre-hea 6b18-1.8.13-0+squeeze2 OpenJDK Java runtime, using Hotspo ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime Versions of packages openjdk-6-jre recommends: ii ttf-dejavu-extra 2.31-1 Vera font family derivate with add Versions of packages openjdk-6-jre suggests: pn icedtea6-plugin none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#696832: possible dupe of a bug in another package
Note that this is potentially the same bug as the following openjava bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664644 Therefore, openjava jar and fastjar may be using the same code containing the same defect. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697478: openjdk-6-jre: incorrect help page syntax
Package: openjdk-6-jre
Version: 6b18-1.8.13-0+squeeze2
Severity: minor
The jar Usage is shown to have some *commands* without dashes,
followed by *options* without dashes. Then all commands and options
are grouped together under the heading Options:. The significant
conflict is that each command and option is then listed with a dash in
front of it.
Are dashes needed or not? I think not, so the dashes should be
removed from the page.
$ /usr/lib/jvm/java-6-openjdk/bin/jar -help
Illegal option: h
Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point] [-C dir]
files ...
Options:
-c create new archive
-t list table of contents for archive
-x extract named (or all) files from archive
-u update existing archive
-v generate verbose output on standard output
-f specify archive file name
-m include manifest information from specified manifest file
-e specify application entry point for stand-alone application
bundled into an executable jar file
-0 store only; use no ZIP compression
-M do not create a manifest file for the entries
-i generate index information for the specified jar files
-C change to the specified directory and include the following file
If any file is a directory then it is processed recursively.
The manifest file name, the archive file name and the entry point name are
specified in the same order as the 'm', 'f' and 'e' flags.
Example 1: to archive two class files into an archive called classes.jar:
jar cvf classes.jar Foo.class Bar.class
Example 2: use an existing manifest file 'mymanifest' and archive all the
files in the foo/ directory into 'classes.jar':
jar cvfm classes.jar mymanifest -C foo/ .
-- System Information:
Debian Release: 6.0.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages openjdk-6-jre depends on:
ii libaccess-bridge- 1.26.2-5 Java Access Bridge for GNOME (jni
ii libasound21.0.23-2.1 shared library for ALSA applicatio
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii libgif4 4.1.6-9library for GIF images (library)
ii libjpeg62 6b1-1 The Independent JPEG Group's JPEG
ii libpng12-01.2.44-1+squeeze4 PNG library - runtime
ii libpulse0 0.9.21-3+squeeze1 PulseAudio client libraries
ii libx11-6 2:1.3.3-4 X11 client-side library
ii libxext6 2:1.1.2-1 X11 miscellaneous extension librar
ii libxi62:1.3-7X11 Input extension library
ii libxrender1 1:0.9.6-1 X Rendering Extension client libra
ii libxtst6 2:1.1.0-3 X11 Testing -- Record extension li
ii openjdk-6-jre-hea 6b18-1.8.13-0+squeeze2 OpenJDK Java runtime, using Hotspo
ii zlib1g1:1.2.3.4.dfsg-3 compression library - runtime
Versions of packages openjdk-6-jre recommends:
ii ttf-dejavu-extra 2.31-1 Vera font family derivate with add
Versions of packages openjdk-6-jre suggests:
pn icedtea6-plugin none (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#694371: ghostscript: \CropBox on A3 paper- result unreadable to xpdf and evince
Package: ghostscript
Version: 8.71~dfsg2-9
Severity: normal
The following LaTeX document initially displays fine with evince and
xpdf, but after cropping it the resulting file is unusable.
Example:
==[latex_a3_paper.tex]%-
\documentclass[12pt]{minimal}
\usepackage[a3paper,left=1in,right=1in,top=1in,bottom=1in]{geometry}
\begin{document}
\newsavebox{\sometxt}
\sbox{\sometxt}{\begin{tabular}{@{}l@{}}
One line of text.\\
Another line of text.
\end{tabular}}
\newcommand{\row}{\usebox{\sometxt}\hfill\usebox{\sometxt}\\[5mm]}
\row\row\row\row\row\row
\fbox{Crop Me!!\row}
\row\row\row\row\row\row
\begin{verbatim}
pdflatex latex_a3_paper.tex
gs -sDEVICE=pdfwrite -o latex_a3_paper_cropped.pdf -c [/CropBox [65 850 303
890] /PAGES pdfmark -f latex_a3_paper.pdf
\end{verbatim}
\end{document}
%-
To follow this example, save the text above to a file
latex_a3_paper.tex. Then run:
pdflatex latex_a3_paper.tex
then:
gs -sDEVICE=pdfwrite -o latex_a3_paper_cropped.pdf -c [/CropBox [65 850 303
890] /PAGES pdfmark -f latex_a3_paper.pdf
then:
evince latex_a3_paper_cropped.pdf
or
xpdf latex_a3_paper_cropped.pdf
To see latex_a3_paper_cropped.pdf render properly, open it with gv
or emacs.
-- System Information:
Debian Release: 6.0.6
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages ghostscript depends on:
ii debconf [de 1.5.36.1 Debian configuration management sy
ii debianutils 3.4 Miscellaneous utilities specific t
ii gsfonts 1:8.11+urwcyr1.0.7~pre44-4.2 Fonts for the Ghostscript interpre
ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib
ii libgs8 8.71~dfsg2-9 The Ghostscript PostScript/PDF int
ghostscript recommends no packages.
ghostscript suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#693546: workaround
The workaround for the workaround is to add delay_upload 0 to davfs2.conf. I just tested it. With that option, Duplicity is able to upload more than one file over a davfs2 mount. The details are in this wishlist request for davfs2 to disable caching: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=693607 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#690255: mutt: smime_keys fails to add certificates if they are self-signed
Package: mutt Version: 1.5.20-9+squeeze2 Severity: normal A self-signed certificate does not require a root certificate. However, the perl script smime_keys falls over if a self-signed cert is supplied. The error is: Couldn't identify root certificate! No root and no intermediate certificates. Can't continue. at /usr/bin/smime_keys line 708. Below are the steps to reproduce the error (effectively simulating the creation of SSL certificates for internal use within an organization): $ smime_keys init $ openssl genrsa -out my.key 2048 $ openssl req -new -key my.key -out my_request.csr $ openssl x509 -req -days 3650 -in my_request.csr -signkey my.key -out my.crt $ openssl pkcs12 -keypbe PBE-SHA1-3DES\ -certpbe PBE-SHA1-3DES\ -export\ -in my.crt\ -inkey my.key\ -out my_pkcs12.pfx\ -nameMe $ smime_keys add_p12 my_pkcs12.pfx ... Verifying - Enter PEM pass phrase: Couldn't identify root certificate! No root and no intermediate certificates. Can't continue. at /usr/bin/smime_keys line 708. -- Package-specific info: Mutt 1.5.20 (2009-06-14) Copyright (C) 1996-2009 Michael R. Elkins and others. Mutt comes with ABSOLUTELY NO WARRANTY; for details type `mutt -vv'. Mutt is free software, and you are welcome to redistribute it under certain conditions; type `mutt -vv' for details. System: Linux 2.6.32-5-amd64 (x86_64) ncurses: ncurses 5.7.20100313 (compiled with 5.7) libidn: 1.15 (compiled with 1.15) hcache backend: tokyocabinet 1.4.37 Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_POP +USE_IMAP +USE_SMTP -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +USE_GSS +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME +CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL=/usr/sbin/sendmail MAILPATH=/var/mail PKGDATADIR=/usr/share/mutt SYSCONFDIR=/etc EXECSHELL=/bin/sh MIXMASTER=mixmaster To contact the developers, please mail to mutt-...@mutt.org. To report a bug, please visit http://bugs.mutt.org/. misc/am-maintainer-mode misc/hg.pmdef.debugtime debian-specific/build_doc_adjustments.diff features/ifdef features/xtitles features/trash-folder features/purge-message features/sensible_browser_position features-old/patch-1.5.4.vk.pgp_verbose_mime features/compressed-folders features/compressed-folders.debian debian-specific/Muttrc debian-specific/Md.etc_mailname_gethostbyname.diff debian-specific/use_usr_bin_editor.diff debian-specific/correct_docdir_in_man_page.diff debian-specific/dont_document_not_present_features.diff debian-specific/document_debian_defaults debian-specific/assumed_charset-compat debian-specific/467432-write_bcc.patch misc/define-pgp_getkeys_command.diff misc/gpg.rc-paths misc/smime.rc upstream/533209-mutt_perror.patch upstream/533459-unmailboxes.patch upstream/533439-mbox-time.patch upstream/531430-imapuser.patch upstream/534543-imap-port.patch upstream/538128-mh-folder-access.patch upstream/537818-emptycharset.patch upstream/535096-pop-port.patch upstream/542910-search-segfault.patch upstream/533370-pgp-inline.patch upstream/533520-signature-highlight.patch upstream/393926-internal-viewer.patch upstream/543467-thread-segfault.patch upstream/544180-italian-yesorno.patch upstream/542817-smimekeys-tmpdir.patch upstream/544794-smtp-batch.patch upstream/537694-segv-imap-headers.patch upstream/548577-gpgme-1.2.patch upstream/548494-swedish-intl.patch upstream/553321-ansi-escape-segfault.patch upstream/553238-german-intl.patch upstream/557395-muttrc-crypto.patch upstream/545316-header-color.patch upstream/568295-references.patch upstream/547980-smime_keys-chaining.patch upstream/528233-readonly-open.patch upstream/228671-pipe-mime.patch upstream/383769-score-match.patch upstream/547739-manual-typos.patch upstream/311296-rand-mktemp.patch upstream/573823-imap_internal_date upstream/542344-dont_fold_From_ upstream/537061-dont-recode-saved-attachments.patch upstream/619216-gnutls-CN-validation.patch upstream/path_max misc/hyphen-as-minus.patch misc/smime_keys-manpage.patch mutt.org -- System Information: Debian Release: 6.0.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages mutt depends on: ii libc6 2.11.3-4 Embedded GNU C Library: Shared lib ii
Bug#690041: socat: early termination with 0 exit code
Package: socat Version: 1.7.1.3-1 Severity: normal Socat terminates early when used as a forwarding daemon through a tor daemon. With a tor instance listening on port 9050, this is the socat command: socat -T999 -s\ TCP4-LISTEN:12345,ignoreeof\ SOCKS4A:127.0.0.1:nntp.aioe.org:563,socksport=9050,ignoreeof The syntax above prevents termination due to a timeout (-T999), an EOF (ignoreeof), or a non-fatal error (-s). So the *only* reason it should terminate is if there is a fatal error or the connection is idle for over 115 days. However, it terminates the same day it's launched, and does so with an error code of 0. A news client is able to browse some newsgroups, read messages, and respond, but then for no apparent reason the connection dies eventually. -- System Information: Debian Release: 6.0.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages socat depends on: ii libc6 2.11.3-3 Embedded GNU C Library: Shared lib ii libreadline5 5.2-7 GNU readline and history libraries ii libssl0.9.80.9.8o-4squeeze13 SSL shared libraries ii libwrap0 7.6.q-19 Wietse Venema's TCP wrappers libra socat recommends no packages. socat suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
