Bug#678815: ITP: wmfs -- Window Manager From Scratch
On June 28, 2012 12:58:09 AM Holger Levsen wrote: On Mittwoch, 27. Juni 2012, Thomas Koch wrote: Thus having said, I believe that the world (and Debians archive) does have all the window managers it needs. :-) I beg to differ. To say it mildy :) +1 (says the guy building UDE from source) As someone pointed out earlier, there are lots of different tastes when it comes to window manager-like software... I expect there are more tastes than available WMs--so, the more the merrier as long as its maintained. - Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#674039: no delay, but imports not mounted
Hi, I've installed the packages at ~rleigh/sysvinit and the system doesn't pause waiting for mount.nfs to timeout anymore, but the NFS imports are not mounted when the boot finishes either. # mount -a -tnfs # is required to set things right - Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#649491: boot fails when libnfsidmap.so.0 not found...
Package: libnfsidmap2 Version: 0.24-1 Severity: critical ...because /usr is an NFS mount! Please move everything under /usr/lib to /lib. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#640210: ssh doesn't shutdown after running kmail
When I run kmail from a ssh session I can't log out of the ssh session afterwards. The only symptom in the logs is .xsession-errors having the same SSLv2 messages mentioned above. * When run from the command line (login via SSH, then start kmail) the session hangs when logging out; closing the termial SSH was started on leaves instances of akonadi and nepomuk are left running on the remote host. * When started via a .desktop file (executing: ssh -X kmail, SSH public key on the remote host), sshd leaves a sshd user@notty process and all programs started by kmail's startup running. i.e... [cut'n'paste from top] 12212 12210 bsass 20 0 11880 3988 972 S 0.0 0.8 0:16.35 sshd bsass@notty 12218 1 bsass 20 0 3708 596 364 S 0.0 0.1 0:00.00 dbus-launch --autolaunch 294e50452620d234d6810d269bb91b00 --binary-syntax --close-stderr 12219 1 bsass 20 0 3412 896 556 S 0.0 0.2 0:01.02 /usr/bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session 12225 1 bsass 20 0 33444 4892 3764 S 0.0 1.0 0:00.10 kdeinit4: kdeinit4 Running... 12226 12225 bsass 20 0 44592 8932 7580 S 0.0 1.7 0:00.17 kdeinit4: klauncher [kdeinit] --fd=8 12229 1 bsass 20 0 81352 14m 12m S 0.0 3.0 0:00.68 kdeinit4: kded4 [kdeinit] 12236 1 bsass 20 0 34200 4500 3680 S 0.0 0.9 0:00.82 /usr/bin/akonadi_control 12239 12236 bsass 20 0 160m 7760 5924 S 0.0 1.5 0:00.58 akonadiserver 12242 12239 bsass 20 0 190m 22m 5580 S 0.0 4.6 0:02.87 /usr/sbin/mysqld --defaults- file=/home/bsass/.local/share/akonadi//mysql.conf --datadir=/home/bsass/.local/share/akonadi 12267 12236 bsass 20 0 83740 16m 14m S 0.0 3.3 0:00.45 /usr/bin/akonadi_birthdays_resource -- identifier akonadi_birthdays_resource_0 12268 12236 bsass 20 0 84100 16m 14m S 0.0 3.4 0:00.46 /usr/bin/akonadi_ical_resource -- identifier akonadi_ical_resource_0 12269 12236 bsass 20 0 84100 16m 14m S 0.0 3.4 0:00.46 /usr/bin/akonadi_ical_resource -- identifier akonadi_ical_resource_1 12270 12236 bsass 20 0 81700 16m 14m S 0.0 3.2 0:00.44 /usr/bin/akonadi_maildir_resource -- identifier akonadi_maildir_resource_0 12271 12236 bsass 20 0 82220 16m 14m S 0.0 3.3 0:00.66 /usr/bin/akonadi_maildispatcher_agent --identifier akonadi_maildispatcher_agent 12272 12236 bsass 20 0 89824 16m 14m S 0.0 3.2 0:00.48 /usr/bin/akonadi_nepomuk_contact_feeder --identifier akonadi_nepomuk_contact_feeder 12273 12236 bsass 20 0 81672 16m 14m S 0.0 3.2 0:00.42 /usr/bin/akonadi_vcard_resource -- identifier akonadi_vcard_resource_0 12274 12236 bsass 20 0 81704 16m 14m S 0.0 3.2 0:00.42 /usr/bin/akonadi_vcard_resource -- identifier akonadi_vcard_resource_10 12275 12236 bsass 20 0 81672 16m 14m S 0.0 3.2 0:00.43 /usr/bin/akonadi_vcard_resource -- identifier akonadi_vcard_resource_11 12276 12236 bsass 20 0 81672 16m 14m S 0.0 3.2 0:00.42 /usr/bin/akonadi_vcard_resource -- identifier akonadi_vcard_resource_6 12277 12236 bsass 20 0 81672 16m 14m S 0.0 3.2 0:00.43 /usr/bin/akonadi_vcard_resource -- identifier akonadi_vcard_resource_7 12278 12236 bsass 20 0 81672 16m 14m S 0.0 3.2 0:00.43 /usr/bin/akonadi_vcard_resource -- identifier akonadi_vcard_resource_8 12279 12236 bsass 20 0 81672 16m 14m S 0.0 3.2 0:00.43 /usr/bin/akonadi_vcard_resource -- identifier akonadi_vcard_resource_9 12318 1 bsass 20 0 34708 5640 4720 S 0.0 1.1 0:00.12 /usr/bin/nepomukserver
Bug#639558: playonlinux: version 3.8 no longer supported
Package: playonlinux Version: 3.8.8-1 Severity: important When installing I get the following message from the PlayOnLinux Wizard... Sorry, PlayOnMac 2.5 and PlayOnLinux 3.8 are no longer supported. Please update to 4.0 http://www.playonlinux.com http://www.playonmac.com ...which makes the current package useless for new PlayOnLinux users. note: The 4.0.9 .deb at playonlinux.com appears to install and run without errors, but the game I tried to install failed when opengl couldn't be found (because of the recent mesa, nvidia packaging changes?) - Bruce -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages playonlinux depends on: ii binutils 2.21.53.20110823-3 The GNU assembler, linker and bina ii cabextract1.4-1 Microsoft Cabinet file unpacker ii gettext-base 0.18.1.1-4 GNU Internationalization utilities ii imagemagick 8:6.6.9.7-5image manipulation programs ii konsole [x-terminal-e 4:4.6.5-1 X terminal emulator ii mesa-utils8.0.1-2+b1 Miscellaneous Mesa GL utilities ii python2.6.7-3interactive high-level object- orie ii python-support1.0.14 automated rebuilding support for P ii python-wxgtk2.8 2.8.10.1-3.1 wxWidgets Cross-platform C++ GUI t ii unzip 6.0-5 De-archiver for .zip files ii wget 1.13-1 retrieves files from the web ii wine 1.0.1-3.1 Windows API implementation - stand ii xterm [x-terminal-emu 271-1 X terminal emulator playonlinux recommends no packages. Versions of packages playonlinux suggests: ii ttf-mscorefonts-installer 3.3Installer for Microsoft TrueType c -- 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#638621: forget that patch...
tags 638621 - patch stop I found this issue at bugs.kde.org and it turns out there is more wrong here than just the escaped single quotes. See: https://bugs.kde.org/show_bug.cgi?id=265730 If the 4.6.5 packages are going to have a life in Debian I suggest backporting at least the fix to get rid of the error messages as was applied to 4.7. - Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#638621: error parsing /usr/share/kde4/apps/kate/externaltools
Package: kate Version: 4:4.6.5-1 Severity: normal Tags: patch While running kate from the command line, with all messages disabled via kdebugdialog, I noticed this error repeated a few times: KConfigIni: In file /usr/share/kde4/apps/kate/externaltools, line 8: Invalid escape sequence \'. Removing the escaped single quotes in the file and line indicated in the error message fixes the problem. The attached diff -u output changes the text from: The file \'%filename\' is not under revision control. to The file: %filename, is not under revision control. An escaped double quote (\) is also an invalid escape sequence. The other problem, that of the message being spit out in spit of that behaviour being disabled, is probably an upstream issue with some other KDE component. - Bruce -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.0.0-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages kate depends on: ii kdebase-runtime 4:4.6.5-1 runtime components from the offici ii libc6 2.13-16Embedded GNU C Library: Shared lib ii libkde3support4 4:4.6.5-2 KDE 3 Support Library for the KDE ii libkdecore5 4:4.6.5-2 KDE Platform Core Library ii libkdeui5 4:4.6.5-2 KDE Platform User Interface Librar ii libkfile4 4:4.6.5-2 File Selection Dialog Library for ii libkio5 4:4.6.5-2 Network-enabled File Management Li ii libknewstuff2-4 4:4.6.5-2 Get Hot New Stuff v2 Library for ii libknewstuff3-4 4:4.6.5-2 Get Hot New Stuff v3 Library for ii libkparts44:4.6.5-2 Framework for the KDE Platform Gra ii libktexteditor4 4:4.6.5-2 KTextEditor interfaces for the KDE ii libplasma34:4.6.5-2 Plasma Library for the KDE Platfor ii libqt4-dbus 4:4.7.3-7 Qt 4 D-Bus module ii libqt4-qt3support 4:4.7.3-7 Qt 3 compatibility library for Qt ii libqt4-sql4:4.7.3-7 Qt 4 SQL module ii libqt4-xml4:4.7.3-7 Qt 4 XML module ii libqtcore44:4.7.3-7 Qt 4 core module ii libqtgui4 4:4.7.3-7 Qt 4 GUI module ii libstdc++64.6.1-6GNU Standard C++ Library v3 kate recommends no packages. Versions of packages kate suggests: ii aspell 0.60.7~20110707-1 GNU Aspell spell-checker ii ispell 3.3.02-5 International Ispell (an interacti ii khelpcenter4 4:4.6.5-1 help center ii konsole4:4.6.5-1 X terminal emulator -- no debconf information -- debsums errors found: debsums: changed file /usr/share/kde4/apps/kate/externaltools (from kate package) --- externaltools.orig 2011-01-19 15:07:44.0 -0700 +++ externaltools 2011-08-19 22:27:16.0 -0600 @@ -5,7 +5,7 @@ [externaltool_CompareCurrentDocumenttoRCS] acname=externaltool_CompareCurrentDocumenttoRCS cmdname=document-diff -command=if [ -z %directory ] then kdialog --title Error --msgbox The document has never been saved and thus cannot be compared to RCS.; fi\ncd %directory\nif [ -d .svn ] grep %filename .svn/entries 21 /dev/null ; then\n svn diff %filename|kompare -o -\nelif [ -d CVS ] grep %filename CVS/Entries 21 /dev/null ; then\n cvs diff -ub %filename|kompare -o -\nelif [ -d .git ] echo $(git ls-files) | grep %filename 21 /dev/null ; then\n git diff %filename|kompare -o -\nelse\n kdialog --title Error --msgbox The file \'%filename\' is not under revision control.\nfi\n +command=if [ -z %directory ] then kdialog --title Error --msgbox The document has never been saved and thus cannot be compared to RCS.; fi\ncd %directory\nif [ -d .svn ] grep %filename .svn/entries 21 /dev/null ; then\n svn diff %filename|kompare -o -\nelif [ -d CVS ] grep %filename CVS/Entries 21 /dev/null ; then\n cvs diff -ub %filename|kompare -o -\nelif [ -d .git ] echo $(git ls-files) | grep %filename 21 /dev/null ; then\n git diff %filename|kompare -o -\nelse\n kdialog --title Error --msgbox The file: %filename, is not under revision control.\nfi\n executable=kompare icon=kompare mimetypes=
Bug#452412: libfuse2: mount.ntfs fails when /usr is an NFS mount
Package: libfuse2 Version: 2.8.5-4 Followup-For: Bug #452412 Wed Jul 20 00:18:43 2011: Will now mount local filesystems:/sbin/mount.ntfs: error while loading shared libraries: l ibfuse.so.2: cannot open shared object file: No such file or directory Wed Jul 20 00:18:43 2011: failed! . . . Wed Jul 20 00:20:52 2011: Waiting for /usr...done. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.39-2-686-pae (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libfuse2 depends on: ii libc6 2.13-10Embedded GNU C Library: Shared lib libfuse2 recommends no packages. Versions of packages libfuse2 suggests: ii fuse 2.8.5-4Filesystem in Userspace -- 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#633019: libtirpc1: boot fails when /usr is an NFS mount
On July 7, 2011 05:41:57 PM Steinar H. Gunderson wrote: found 633019 0.2.0-2 thanks On Thu, Jul 07, 2011 at 03:27:25PM -0600, Bruce Sass wrote: Since the lib resides under /usr/lib, and /usr on this box is an NFS mount, mount.nfs fails during boot up and I am left without a /usr partition. I have worked around the problem by booting with a rescue CD, mounting the NFS /usr and local / partitions, then copying libtirpc.so.1 and libtirpc.so.1.0.10 to /lib on the local HDD. We'll need to see if /usr on NFS is really still supported; I'm not honestly sure it should be RC, at least. In any case, this is true of every libtirpc version that has been released, so I'm marking it as found in stable for BTS, in order not to hinder the multiarch transition to testing. Sorry about that--I usually keep the box reasonably up to date with unstable but got distracted with other stuff and stopped upgrading it prior to the most recent pre-release freeze and changes to the NFS infrastructure. [On the bright side, aside from a couple NFS related lib problems, upgrading from a pre-squeeze unstable to the current unstable was painless. :) ] I don't think /usr via NFS is really/properly supported, but since minimal support only requires that NFS infrastructure reside on the local HDD (i.e., /etc, /lib, /bin, /sbin, /var) it doesn't seem like something too onerous to ask for. - Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633019: libtirpc1: boot fails when /usr is an NFS mount
Package: libtirpc1 Version: 0.2.2-3 Severity: critical Justification: breaks the whole system Since the lib resides under /usr/lib, and /usr on this box is an NFS mount, mount.nfs fails during boot up and I am left without a /usr partition. I have worked around the problem by booting with a rescue CD, mounting the NFS /usr and local / partitions, then copying libtirpc.so.1 and libtirpc.so.1.0.10 to /lib on the local HDD. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.39-2-686-pae (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libtirpc1 depends on: ii libc6 2.13-10Embedded GNU C Library: Shared lib ii libgssglue1 0.3-1 mechanism-switch gssapi library ii multiarch-support 2.13-10Transitional package to ensure mul libtirpc1 recommends no packages. libtirpc1 suggests no packages. -- no debconf information -- debsums errors found: prelink: Could not write temporary for /usr/lib/i386-linux-gnu/libtirpc.so.1.0.10: Layout error: overlapping sections debsums: changed file /usr/lib/i386-linux-gnu/libtirpc.so.1.0.10 (from libtirpc1 package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#633021: libgssglue1: boot fails when /usr is an NFS mount
Package: libgssglue1 Version: 0.3-1 Severity: critical Justification: breaks the whole system Since the lib resides under /usr/lib, and /usr on this box is an NFS mount, mount.nfs fails during boot up and I am left without a /usr partition. I have worked around the problem by booting with a rescue CD, mounting the NFS /usr and local / partitions, then copying libgssglue.so.1 and libgssglue.so.1.0.0 to /lib on the local HDD. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.39-2-686-pae (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages libgssglue1 depends on: ii libc6 2.13-10Embedded GNU C Library: Shared lib libgssglue1 recommends no packages. libgssglue1 suggests no packages. -- no debconf information -- debsums errors found: prelink: Could not write temporary for /usr/lib/libgssglue.so.1.0.0: Layout error: overlapping sections debsums: changed file /usr/lib/libgssglue.so.1.0.0 (from libgssglue1 package) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#626450: if you can't remount /root
[maybe I'm just naive wrt how the initramfs works shrug] (initramfs) mount -o remount,rw /root mount: can't read '/proc/mounts': no such file or directory So I changed the ro kernel arg to rw, booted, then created the symlink. - Bruce -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#607528: installation-guide: LSB website URL out of date
Package: installation-guide Severity: minor Tags: squeeze 1.1. What is Debian? ... Debian developers are also involved in... * The Linux Standard Base (http://www.linuxbase.org/)... the current URL is: http://www.linuxfoundation.org/collaborate/workgroups/lsb -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#599671: freeciv-server: intermittent segfault
Package: freeciv-server Version: 2.2.2-1 Severity: important The only strangeness I can see is a pile of... Invalid string conversion from UTF-8 to ISO-8859-1. ...messages in the gtk client's display. Here is the client's output. Lost connection to server! messages appear after the server segfaults: Freeciv is free software and you are welcome to distribute copies of it under certain conditions; See the Copying item on the Help menu. Now ... Go give 'em hell! Welcome to the Freeciv version 2.2.2 Server running at onegee port 5556. You are logged in as 'bsass' connected to John Diefenbaker. Established control over the server. You have command access level 'hack'. All players are ready; starting game. Player 'Kasym' now has AI skill level 'Hard'. Player 'Giorgi III' now has AI skill level 'Hard'. Player 'Benazir Bhutto' now has AI skill level 'Hard'. Invalid string conversion from UTF-8 to ISO-8859-1. Player 'H? Chí Minh' now has AI skill level 'Hard'. Player 'Genseric' now has AI skill level 'Hard'. Invalid string conversion from UTF-8 to ISO-8859-1. Lost connection to server! Welcome to the Freeciv version 2.2.2 Server running at onegee port 5556. You are logged in as 'bsass' connected to John Diefenbaker. Established control over the server. You have command access level 'hack'. All players are ready; starting game. Player 'Kasym' now has AI skill level 'Hard'. Player 'Giorgi III' now has AI skill level 'Hard'. Player 'Benazir Bhutto' now has AI skill level 'Hard'. Invalid string conversion from UTF-8 to ISO-8859-1. Player 'H? Chí Minh' now has AI skill level 'Hard'. Player 'Genseric' now has AI skill level 'Hard'. Invalid string conversion from UTF-8 to ISO-8859-1. Lost connection to server! Welcome to the Freeciv version 2.2.2 Server running at onegee port 5556. You are logged in as 'bsass' connected to John Diefenbaker. Established control over the server. You have command access level 'hack'. All players are ready; starting game. Player 'Kasym' now has AI skill level 'Hard'. Player 'Giorgi III' now has AI skill level 'Hard'. Player 'Benazir Bhutto' now has AI skill level 'Hard'. Invalid string conversion from UTF-8 to ISO-8859-1. Player 'H? Chí Minh' now has AI skill level 'Hard'. Player 'Genseric' now has AI skill level 'Hard'. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string conversion from UTF-8 to ISO-8859-1. Invalid string
Bug#593653: bittornado: using deprecated sha module
Package: bittornado Version: 0.3.18-10 Severity: normal I don't know if this affects BitTornado itself, but it is causing unnecessary output when using command line apps importing BitTornado code. e.g.: $ cfv /usr/lib/pymodules/python2.6/BitTornado/__init__.py:8: DeprecationWarning: the sha module is deprecated; use the hashlib module instead from sha import sha -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages bittornado depends on: ii python2.6.5-13 interactive high-level object-orie ii python-support1.0.9 automated rebuilding support for P Versions of packages bittornado recommends: ii mime-support 3.48-1 MIME files 'mime.types' 'mailcap ii python-crypto 2.1.0-2cryptographic algorithms and proto Versions of packages bittornado suggests: ii bittornado-gui0.3.18-10 bittorrent client with GUI interfa ii python-psyco 1.6-2 Python specializing compiler -- 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#592361: libssl0.9.8: libcrypto.so.0.9.8 accessed before /usr is mounted
Package: libssl0.9.8 Version: 0.9.8g-16 Severity: critical Justification: breaks the whole system /usr on my unstable box is an NFS import. When networking is being brought up /sbin/dhclient fails because it can't find libcrypto.so.0.9.8--which lives under /usr/lib--consequently eth0 doesn't appear, none of the NFS imports get mounted and the system is left without a /usr hierarchy. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589683: reportbug: spews useless information messages when spawing editor
retitle 589683 Kate needs a quiet option stop Hi, Fair enough... I'm so use to verbose KDE apps that I automatically put them in the background and redirect output when I start one from a command line--of course everyone else should do the same. :D I tried a couple other visual editors, xjed and xemacs, neither of them sent any output to the X-term. So, indeed, this is a problem with Kate which makes it rather less than suitable as a system's VISUAL editor. Note: although I use a local build of KDE3 (KDE4 eats up too many resources on this older box), and the Kate that comes with KDE4 is somewhat less verbose than the one from KDE3, it still spews out a lot of generally useless messages and doesn't appear to have a quiet option. - Bruce On July 19, 2010 11:25:19 pm Sandro Tosi wrote: reassign 589683 kate thanks Hello Bruce, this seems to me a bug (even if at wishlist severity) in kate: if you want them to stop print those lengthy messages, ask them :) I can't redirect all output from text editor to dev/null or so: there might be cases when having their output on screen is useful, without going to look in another place (or in no place at all, as in /d/null), but I understand the startup of kate is really verbose. I'm assigning this bug to the kate package. Regards, Sandro On Tue, Jul 20, 2010 at 00:42, Bruce Sass bms...@shaw.ca wrote: Package: reportbug Version: 4.12.4 Severity: wishlist It would be really nice if reportbug sent the information messages generated by Kate (KDE text editor) to /dev/null or a log file instead of the screen when not in debug/verbose mode. Here is a transcript of a session so you can see just how ugly the current behaviour is: bs...@onegee:~$ reportbug chkrootkit *** Welcome to reportbug. Use ? for help at prompts. *** Detected character set: us-ascii Please change your locale if this is incorrect. Using 'Bruce Sass bms...@shaw.ca' as your from address. Getting status for chkrootkit... Verifying package integrity... Checking for newer versions at packages.debian.org, incoming.debian.org and http://ftp-master.debian.org/new.html Will send report to Debian (per lsb_release). Querying Debian BTS for reports on chkrootkit (source)... 9 bug reports found: Outstanding bugs -- Important bugs; Patch Available (1 bug) 1) #580491 chkrootkit: 1)with nfs mounted the silent don't work 2)can't exclude legacy sniffer (dhcpd, snort, ntop e Outstanding bugs -- Normal bugs; Unclassified (7 bugs) 2) #535942 chkrootkit: fix for chkproc race 3) #548582 chkrootkit: Chkrootkit isn't quiet with -q and excluded suspicious files 4) #564147 chkrootkit: false positive: scalper rootkit and ser2net debian package both listen on port 2001 by defaul 5) #566687 chkrootkit: False positive for SMTPs (Courier, Postfix) 6) #576470 chkrootkit: false positives for libsmlnj-smlnj 7) #586897 Meaningless error message when option -e is used without argument 8) #588121 chkrootkit: false positive bitlbee, /usr/bin/find 'head' terminated signal 13 Forwarded bugs -- Normal bugs (1 bug) 9) #488558 False positive for vdr (1-9/9) Is the bug you found listed above [y|N|b|m|r|q|s|f|?]? Maintainer for chkrootkit is 'Giuseppe Iuculano iucul...@debian.org'. Looking up dependencies of chkrootkit... Getting changed configuration files... *** The following debconf settings were detected: * chkrootkit/run_daily: true * chkrootkit/run_daily_opts: -q -n * chkrootkit/diff_mode: false Include these settings in your report [Y|n|q|?]? Please briefly describe your problem (max. 100 characters allowed; you can elaborate in a moment). This will be the bug email subject, so write a concise summary of what is wrong with the package, for example, fails to send email or does not start with -q option specified (type Ctrl+c to exit). $egrep used unset Rewriting subject to 'chkrootkit: $egrep used unset' Enter any additional addresses this report should be sent to; press ENTER after each address. Press ENTER on a blank line to continue. How would you rate the severity of this problem or report? 1 critical makes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. 2 grave makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. 3 serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive); may or may not affect the usability of the package. Note that non-severe policy violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also designate other bugs as 'serious' and thus release-critical; however, end users should
Bug#589682: chkrootkit: $egrep used unset
Package: chkrootkit
Version: 0.49-4
Severity: normal
There are 4 instances of $egrep in 3 lines of code (line numbers: 106, Slapper
check; 1135, PHP files check; and 1638, chk_crontab function) but it doesn't
appear that egrep is ever set to a value.
${egrep} is what is being used in lots of other lines...
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash
Versions of packages chkrootkit depends on:
ii binutils 2.20.1-11 The GNU assembler, linker and bina
ii debconf [debconf-2.0] 1.5.32 Debian configuration management sy
ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib
ii net-tools 1.60-23The NET-3 networking toolkit
ii procps1:3.2.8-9 /proc file system utilities
chkrootkit recommends no packages.
chkrootkit suggests no packages.
-- debconf information:
* chkrootkit/run_daily: true
* chkrootkit/run_daily_opts: -q -n
* chkrootkit/diff_mode: false
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#589683: reportbug: spews useless information messages when spawing editor
Package: reportbug Version: 4.12.4 Severity: wishlist It would be really nice if reportbug sent the information messages generated by Kate (KDE text editor) to /dev/null or a log file instead of the screen when not in debug/verbose mode. Here is a transcript of a session so you can see just how ugly the current behaviour is: bs...@onegee:~$ reportbug chkrootkit *** Welcome to reportbug. Use ? for help at prompts. *** Detected character set: us-ascii Please change your locale if this is incorrect. Using 'Bruce Sass bms...@shaw.ca' as your from address. Getting status for chkrootkit... Verifying package integrity... Checking for newer versions at packages.debian.org, incoming.debian.org and http://ftp-master.debian.org/new.html Will send report to Debian (per lsb_release). Querying Debian BTS for reports on chkrootkit (source)... 9 bug reports found: Outstanding bugs -- Important bugs; Patch Available (1 bug) 1) #580491 chkrootkit: 1)with nfs mounted the silent don't work 2)can't exclude legacy sniffer (dhcpd, snort, ntop e Outstanding bugs -- Normal bugs; Unclassified (7 bugs) 2) #535942 chkrootkit: fix for chkproc race 3) #548582 chkrootkit: Chkrootkit isn't quiet with -q and excluded suspicious files 4) #564147 chkrootkit: false positive: scalper rootkit and ser2net debian package both listen on port 2001 by defaul 5) #566687 chkrootkit: False positive for SMTPs (Courier, Postfix) 6) #576470 chkrootkit: false positives for libsmlnj-smlnj 7) #586897 Meaningless error message when option -e is used without argument 8) #588121 chkrootkit: false positive bitlbee, /usr/bin/find 'head' terminated signal 13 Forwarded bugs -- Normal bugs (1 bug) 9) #488558 False positive for vdr (1-9/9) Is the bug you found listed above [y|N|b|m|r|q|s|f|?]? Maintainer for chkrootkit is 'Giuseppe Iuculano iucul...@debian.org'. Looking up dependencies of chkrootkit... Getting changed configuration files... *** The following debconf settings were detected: * chkrootkit/run_daily: true * chkrootkit/run_daily_opts: -q -n * chkrootkit/diff_mode: false Include these settings in your report [Y|n|q|?]? Please briefly describe your problem (max. 100 characters allowed; you can elaborate in a moment). This will be the bug email subject, so write a concise summary of what is wrong with the package, for example, fails to send email or does not start with -q option specified (type Ctrl+c to exit). $egrep used unset Rewriting subject to 'chkrootkit: $egrep used unset' Enter any additional addresses this report should be sent to; press ENTER after each address. Press ENTER on a blank line to continue. How would you rate the severity of this problem or report? 1 criticalmakes unrelated software on the system (or the whole system) break, or causes serious data loss, or introduces a security hole on systems where you install the package. 2 grave makes the package in question unusable by most or all users, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package. 3 serious is a severe violation of Debian policy (that is, the problem is a violation of a 'must' or 'required' directive); may or may not affect the usability of the package. Note that non-severe policy violations may be 'normal,' 'minor,' or 'wishlist' bugs. (Package maintainers may also designate other bugs as 'serious' and thus release-critical; however, end users should not do so.) 4 important a bug which has a major effect on the usability of a package, without rendering it completely unusable to everyone. 5 does-not-build a bug that stops the package from being built from source. (This is a 'virtual severity'.) 6 normal a bug that does not undermine the usability of the whole package; for example, a problem with a particular option or menu item. 7 minor things like spelling mistakes and other minor cosmetic errors that do not affect the core functionality of the package. 8 wishlistsuggestions and requests for new features. Please select a severity level: [normal] 6 Do any of the following apply to this report? 1 d-i This bug is relevant to the development of debian-installer. 2 experimental This bug only applies to the experimental branch of Debian. 3 ipv6 This bug affects support for Internet Protocol version 6. 4 l10n This bug reports a localization/internationalization issue. 5 lenny This bug only applies to the lenny release (Debian 5.0). 6 lfs This bug affects support for large files (over 2 gigabytes). 7 patch You are including a patch to fix this problem. 8 sid This bug only applies to the unstable branch of Debian. 9 squeeze This bug only applies to the squeeze release. 10
Bug#589123: ethtool: tries /usr/bin/* before /usr mounted
Package: ethtool Version: 1:2.6.34-2 Severity: important This transcript from /var/log/boot says it all: Wed Jul 14 21:55:02 2010: Configuring network interfaces...Internet Systems Consortium DHCP Client V3.1.3 Wed Jul 14 21:55:03 2010: Copyright 2004-2009 Internet Systems Consortium. Wed Jul 14 21:55:03 2010: All rights reserved. Wed Jul 14 21:55:03 2010: For info, please visit https://www.isc.org/software/dhcp/ Wed Jul 14 21:55:03 2010: Wed Jul 14 21:55:03 2010: Listening on LPF/eth0/00:02:a5:7e:9b:78 Wed Jul 14 21:55:03 2010: Sending on LPF/eth0/00:02:a5:7e:9b:78 Wed Jul 14 21:55:03 2010: Sending on Socket/fallback Wed Jul 14 21:55:07 2010: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8 Wed Jul 14 21:55:07 2010: DHCPOFFER from 192.168.0.1 Wed Jul 14 21:55:07 2010: DHCPREQUEST on eth0 to 255.255.255.255 port 67 Wed Jul 14 21:55:07 2010: DHCPACK from 192.168.0.1 Wed Jul 14 21:55:07 2010: bound to 192.168.0.102 -- renewal in 116896 seconds. Wed Jul 14 21:55:07 2010: /etc/network/if-up.d/ethtool: 35: awk: not found Wed Jul 14 21:55:07 2010: /etc/network/if-up.d/ethtool: 35: env: not found Wed Jul 14 21:55:07 2010: /etc/network/if-up.d/ethtool: 38: awk: not found Wed Jul 14 21:55:07 2010: /etc/network/if-up.d/ethtool: 38: env: not found Wed Jul 14 21:55:07 2010: /etc/network/if-up.d/ethtool: 41: awk: not found Wed Jul 14 21:55:07 2010: /etc/network/if-up.d/ethtool: 41: env: not found Wed Jul 14 21:55:07 2010: /etc/network/if-up.d/ethtool: 44: awk: not found Wed Jul 14 21:55:07 2010: /etc/network/if-up.d/ethtool: 44: env: not found Wed Jul 14 21:55:07 2010: Starting portmap daemon Wed Jul 14 21:55:08 2010: Starting NFS common utilities: statd. Wed Jul 14 21:55:10 2010: done. Wed Jul 14 21:55:10 2010: Starting portmap daemon...Already running.. Wed Jul 14 21:55:10 2010: Starting NFS common utilities: statd. Wed Jul 14 21:55:10 2010: Waiting for /usr...done. IMO, awk and env should reside in /bin, not /usr/bin, but perhaps ethtool shouldn't be using those commands or shouldn't be doing its thing until after all imported filesystems have been mounted. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages ethtool depends on: ii libc6 2.11.2-2 Embedded GNU C Library: Shared lib ethtool recommends no packages. ethtool 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#518698: open with `ktorrent' fails
Package: ktorrent Version: 3.1.6+dfsg.4-1 Severity: normal When clicking on a link to a .torrent file I get a popup with the options Save As, Open with `KTorrent', and Cancel. Selecting Open with `KTorrent' results in KTorrent poping up a error window containing, An error occurred while loading the torrent.br/The torrent is probably corrupt or is not a torrent file. Saving the .torrent file instead, then clicking on the saved file starts up KTorrent and the bittorrent starts downloading as expected. -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-onegee (PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages ktorrent depends on: ii kdebase-runtime 4:4.1.0-2 runtime components from the offici ii kdelibs5 4:4.1.0-3+b1 core libraries for all KDE 4 appli ii libc6 2.9-4 GNU C Library: Shared libraries ii libgcc1 1:4.3.3-5 GCC support library ii libgeoip1 1.4.6.dfsg-2 A non-DNS IP-to-country resolver l ii libgmp3c2 2:4.2.4+dfsg-2 Multiprecision arithmetic library ii libphonon44:4.3.0-2 Phonon multimedia framework for Qt ii libqca2 2.0.0-4libraries for the Qt Cryptographic ii libqt4-dbus 4.4.3-2Qt 4 D-Bus module ii libqt4-network4.4.3-2Qt 4 network module ii libqt4-qt3support 4.4.3-2Qt 3 compatibility library for Qt ii libqt4-xml4.4.3-2Qt 4 XML module ii libqtcore44.4.3-2Qt 4 core module ii libqtgui4 4.4.3-2Qt 4 GUI module ii libstdc++64.3.3-5The GNU Standard C++ Library v3 ii phonon4:4.3.0-2 metapackage for Phonon multimedia ktorrent recommends no packages. Versions of packages ktorrent suggests: ii php5-cli 5.2.6.dfsg.1-3 command-line interpreter for the p -- 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#518698: sample .torrent file
Here is a downloaded .torrent file that could not be opened with KTorrent, but worked once saved to the HDD. Underworld.Rise.Of.The.Lycans.R5.DVDR-COALiTiON.torrent Description: application/bittorrent
Bug#463190: possible solution for 24-bit FLAC problem
It appears that Debian's K3b can handle 24-bit FLAC files if the libsndfile plugin is included in the build. I have tested this by: 1. installing libsndfile1-dev (a missing Build-Depends?) 2. adding debian/tmp/usr/lib/kde3/libk3blibsndfiledecoder* to src/k3b-1.0.5/debian/libk3b3-extracodecs.install 3. building then running K3b 4. adding 24-bit FLAC files to an audio CD project, where they appear as Type: FLAC (FLAC Lossless Audio Codec) [16-bit FLAC files appear as Type: FLAC] 5. disabling the libsndfile plugin and confirming that 24-bit FLAC files are no longer supported 6. burning an audio CD from 24-bit FLAC files then listening to the result, which sounded good 7. and just to make sure: $ strings /usr/lib/libsndfile.so.1.0.17 | grep FLAC (FLAC FLAC (FLAC Lossless Audio Codec) $ NOTE... $ ldd /usr/lib/libsndfile.so.1.0.17 linux-gate.so.1 = (0xb7fd9000) libFLAC.so.8 = /usr/lib/libFLAC.so.8 (0x4f826000) libogg.so.0 = /usr/lib/libogg.so.0 (0x410df000) libm.so.6 = /lib/i686/cmov/libm.so.6 (0x4e0e7000) libc.so.6 = /lib/i686/cmov/libc.so.6 (0x4df8a000) /lib/ld-linux.so.2 (0x8000) $ ...so, it may still be a K3b FLAC plugin bug and this is just a workaround if libsndfile doesn't do anything special with 24-bit FLAC files. It would be interesting to know if Sebastian Trueg sees FLAC or FLAC (FLAC Lossless Audio Codec) as the Type in K3b; if he sees FLAC then there is likely a problem with Debian's flac, if they are being processed by libsndfile and it does not do anything special then it could be a K3b FLAC plugin or flac problem. I should also mention that my build included the ffmpeg decoder (-dev files from www.debian-multimedia.org) and lame encoder plugins, and I needed to install over two dozen new packages by the time I finished satisfying all the dependencies (I can now drop .wma files into an audio CD project and bug #498767, Dragging files to audiocd dialog crashes K3b, has magically disappeared [which was the reason I was building K3b myself])--so there is the possibility that something else is having an effect. HTH - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492781: update: ssh hangs after upgrade
I'm still having this problem.
Here is some information I didn't notice when I first reported the bug:
While I did confirm that unsetting SSH_AUTH_SOCK does restore
connectivity, I was not aware that:
SSH_AUTH_SOCK=/tmp/ssh-XnTwx31250/agent.31250
with
[EMAIL PROTECTED]:~$ ls -l /tmp
total 0
drwx-- 2 bsass bsass 60 Oct 5 18:18 ssh-XnTwx31250
[EMAIL PROTECTED]:~$ ls -l /tmp/ssh*
total 0
srw--- 1 bsass bsass 0 Oct 5 18:18 agent.31250
where
$ ps -p 31250
PID TTY TIME CMD
31250 ?00:00:00 startkde
and perhaps most importantly, the upgrade is happening via dselect
running in a KDE Konsole session while there are open ssh sessions to a
couple other boxes on the LAN.
Here is the strace I sent to Colin earlier:
I think this is the interesting bit...
---
write(2, debug1: SSH2_MSG_SERVICE_ACCEPT r..., 42debug1:
SSH2_MSG_SERVICE_ACCEPT received) = 42
socket(PF_FILE, SOCK_STREAM, 0) = 4
fcntl64(4, F_SETFD, FD_CLOEXEC) = 0
connect(4, {sa_family=AF_FILE,
path=/tmp/ssh-sdhZIS2748/agent.2748...}, 110) = 0
write(4, \0\0\0\1..., 4) = 4
write(4, \v..., 1) = 1
read(4, ^C unfinished ...
---
...but here is the entire trace just in case it is not the whole story:
---
[EMAIL PROTECTED]:~$ strace ssh -X -v -v -v smokie
execve(/usr/bin/ssh, [ssh, -X, -v, -v, -v, smokie], [/* 39
vars */]) = 0
brk(0) = 0xb898f000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7ed9000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or
directory)
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=116578, ...}) = 0
mmap2(NULL, 116578, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ebc000
close(3) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/i686/cmov/libresolv.so.2, O_RDONLY) = 3
read(3, [EMAIL PROTECTED]...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=69068, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0xb7ebb000
mmap2(NULL, 80068, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb7ea7000
mmap2(0xb7eb7000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0xf) = 0xb7eb7000
mmap2(0xb7eb9000, 6340, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7eb9000
close(3) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/usr/lib/i686/cmov/libcrypto.so.0.9.8, O_RDONLY) = 3
read(3, [EMAIL PROTECTED]...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1377140, ...}) = 0
mmap2(NULL, 1387864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb7d54000
mmap2(0xb7e8e000, 90112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x13a) = 0xb7e8e000
mmap2(0xb7ea4000, 11608, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7ea4000
close(3) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/i686/cmov/libutil.so.1, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\340\371\232G4\0\0\0T...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=11308, ...}) = 0
mmap2(NULL, 12424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb7d5
mmap2(0xb7d52000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x1) = 0xb7d52000
close(3) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/usr/lib/libz.so.1, O_RDONLY) = 3
read(3,
\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\10nE4\0\0\0\220...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=82536, ...}) = 0
mmap2(NULL, 83740, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0)
= 0xb7d3b000
mmap2(0xb7d4f000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x13) = 0xb7d4f000
close(3) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/i686/cmov/libnsl.so.1, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\!9G4\0\0\0x...,
512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=89424, ...}) = 0
mmap2(NULL, 100328, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3,
0) = 0xb7d22000
mmap2(0xb7d37000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0x14) = 0xb7d37000
mmap2(0xb7d39000, 6120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_ANONYMOUS, -1, 0) = 0xb7d39000
close(3) = 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or
directory)
open(/lib/i686/cmov/libcrypt.so.1, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0
\27G4\0\0\0\30..., 512) = 512
fstat64(3,
Bug#496839: k3b: burns too fast
Package: k3b Version: 1.0.5-3 Severity: wishlist Since the number of speeds writable was reduced I've been struggling to write any media without running the buffers down to 0% full. The main problem is that all data comes from NFS mounted boxes over a 100Mbps LAN. With CDs, 16x works as long as the LAN is quiet (tough since /usr is also an NFS mount); with DVDs, 4x usually works until about 80% of the disk is written, then the buffers empty even if the LAN is quiet. With DVD Dual Layer media there is an additional problem in that the most common blanks available are 2.4x! Writing them at 4x seems to work as long as they are being read by the device attached to the computer, but the DVD player connected to the TV and home theatre amp sometimes has trouble with them. It would be really nice if 8x and 2.4x speeds were available for CD and DVD media repectively. For the record: this is a 1GHz box with 512M RAM, and the device is an LG HL-DT-ST DVD-RAM GSA-H50N (2M buffer), everything was fine before the number of available write speeds was reduced. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages k3b depends on: ii cdparanoia 3.10.0+debian-1 audio extraction tool for sampling ii cdrdao 1:1.2.2-16 records CDs in Disk-At-Once (DAO) ii genisoimage 9:1.1.8-1+b1Creates ISO-9660 CD-ROM filesystem ii k3b-data 1.0.5-3 A sophisticated KDE CD burning app ii kdelibs-data 4:3.5.9.dfsg.1-6core shared data for all KDE appli ii kdelibs4c2a 4:3.5.9.dfsg.1-6core libraries and binaries for al ii libacl1 2.2.47-2Access control list shared library ii libart-2.0-2 2.3.20-2Library of functions for 2D graphi ii libattr1 1:2.4.43-1 Extended attribute shared library ii libaudio21.9.1-4 Network Audio System - shared libr ii libc62.7-13 GNU C Library: Shared libraries ii libdbus-1-3 1.2.1-3 simple interprocess messaging syst ii libdbus-qt-1-1c2 0.62.git.20060814-2 simple interprocess messaging syst ii libdvdread3 0.9.7-11library for reading DVDs ii libexpat12.0.1-4 XML parsing C library - runtime li ii libfam0 2.7.0-13.3 Client library to control the FAM ii libfontconfig1 2.6.0-1 generic font configuration library ii libfreetype6 2.3.7-2 FreeType 2 font engine, shared lib ii libgcc1 1:4.3.1-9 GCC support library ii libhal1 0.5.11-3Hardware Abstraction Layer - share ii libice6 2:1.0.4-1 X11 Inter-Client Exchange library ii libidn11 1.9-1 GNU libidn library, implementation ii libjpeg626b-14 The Independent JPEG Group's JPEG ii libk3b3 1.0.5-3 The KDE cd burning application lib ii libmusicbrainz4c2a 2.1.5-2 Second generation incarnation of t ii libpng12-0 1.2.27-1PNG library - runtime ii libqt3-mt3:3.3.8b-5 Qt GUI Library (Threaded runtime v ii libsm6 2:1.0.3-2 X11 Session Management library ii libstdc++6 4.3.1-9 The GNU Standard C++ Library v3 ii libx11-6 2:1.1.4-2 X11 client-side library ii libxcursor1 1:1.1.9-1 X cursor management library ii libxext6 2:1.0.4-1 X11 miscellaneous extension librar ii libxft2 2.1.12-3FreeType-based font drawing librar ii libxi6 2:1.1.3-1 X11 Input extension library ii libxinerama1 2:1.0.3-2 X11 Xinerama extension library ii libxrandr2 2:1.2.3-1 X11 RandR extension library ii libxrender1 1:0.9.4-2 X Rendering Extension client libra ii libxt6 1:1.0.5-3 X11 toolkit intrinsics library ii wodim9:1.1.8-1+b1command line CD/DVD writing tool ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages k3b recommends: ii dvd+rw-tools7.1-3DVD+-RW/R tools ii kcontrol4:3.5.9.dfsg.1-5 control center for KDE ii kdebase-kio-plugins 4:3.5.9.dfsg.1-5 core I/O slaves for KDE ii libk3b3-extracodecs 1.0.5-3 The KDE cd burning application lib ii vcdimager 0.7.23-4 A VideoCD (VCD) image mastering an Versions of packages k3b suggests: pn k3b-i18n none (no description available) ii movixmaker-2
Bug#496150: xserver-xorg-core: shutting off monitor messes up display
Package: xserver-xorg-core Version: 2:1.4.2-4 Severity: normal After the most recent upgrades of xserver-xorg-core and xserver-utils my LCD display started breaking up (like the vertical sync was really messed up) resulting in a screen full of coloured lines if the system was left untouched for some time. After reading through some similar reports regarding the intel driver, and the text at the two upstream links provided in one report, I added a line to the device section of the config file which will turn off framebuffer compression (although I haven't restarted the xserver so I don't know if it will have any affect) and turned off KDE's display power management. Everything was fine until I powered down the monitor for the night, in the morning the display was back to being unusable. For the last three or four days I haven't turned off the monitor and everything is fine. I have not experienced any flicker, the screen simply goes haywire after the monitor is shutdown either automaticaly because of inactivity or manually by hitting the monitor's power switch. HTH -- Package-specific info: Contents of /var/lib/x11/X.roster: xserver-xorg /var/lib/x11/X.md5sum does not exist. X server symlink status: lrwxrwxrwx 1 root root 13 Apr 15 2006 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 1725328 Aug 15 11:37 /usr/bin/Xorg Contents of /var/lib/x11/xorg.conf.roster: xserver-xorg VGA-compatible devices on PCI bus: 00:02.0 VGA compatible controller: Intel Corporation 82815 Chipset Graphics Controller (CGC) (rev 02) /etc/X11/xorg.conf does not match checksum in /var/lib/x11/xorg.conf.md5sum. Xorg X server configuration file status: -rw-r--r-- 1 root root 2903 May 3 2006 /etc/X11/xorg.conf Contents of /etc/X11/xorg.conf: # /etc/X11/xorg.conf (xorg X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the /etc/X11/xorg.conf manual page. # (Type man /etc/X11/xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades *only* # if it has not been modified since the last upgrade of the xserver-xorg # package. # # If you have edited this file but would like it to be automatically updated # again, run the following command: # sudo dpkg-reconfigure -phigh xserver-xorg Section Files FontPath/usr/share/fonts/X11/misc FontPath/usr/share/fonts/X11/cyrillic FontPath/usr/share/fonts/X11/100dpi/:unscaled FontPath/usr/share/fonts/X11/75dpi/:unscaled FontPath/usr/share/fonts/X11/Type1 FontPath/usr/share/fonts/X11/100dpi FontPath/usr/share/fonts/X11/75dpi # path to defoma fonts FontPath/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType EndSection Section Module Loadbitmap Loadddc Loaddri Loadextmod Loadfreetype Loadglx Loadint10 Loadtype1 Loadvbe EndSection Section InputDevice Identifier Generic Keyboard Driver kbd Option CoreKeyboard Option XkbRules xorg Option XkbModel pc104 Option XkbLayout us EndSection Section InputDevice Identifier Configured Mouse Driver mouse Option CorePointer Option Device/dev/input/mice Option Protocol ExplorerPS/2 Option Emulate3Buttons true EndSection Section Device Identifier Intel Corporation 82815 CGC [Chipset Graphics Controller] Driver i810 BusID PCI:0:2:0 EndSection Section Monitor Identifier Acer AL1715 Option DPMS EndSection Section Screen Identifier Default Screen Device Intel Corporation 82815 CGC [Chipset Graphics Controller] Monitor Acer AL1715 DefaultDepth16 SubSection Display Depth 1 Modes 1280x1024 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 4 Modes 1280x1024 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 8 Modes 1280x1024 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 15 Modes 1280x1024 1280x960 1152x864 1024x768 800x600 640x480 EndSubSection SubSection Display Depth 16 Modes 1280x1024 1280x960 1152x864 1024x768 800x600
Bug#492781: ssh hangs after upgrades
On Tue July 29 2008 03:58:06 am Colin Watson wrote: As a workaround, unsetting SSH_AUTH_SOCK might help? $ SSH_AUTH_SOCK= ssh ... does bypass the problem. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#492781: ssh hangs after upgrades
Package: ssh Version: 1:5.1p1-1 Severity: important With one of the three Unstable boxes I run ssh consistently stops working (hangs without giving me a password prompt) after an upgrade (via dselect, using the APT method) until the system is rebooted. Upgrades appear to go smoothly, and there are no /var/log/* entries on either the client or remote systems when access fails. I can ssh between the other two boxes without any problems (i.e., the client and server on them appear to be functioning properly). The only strange thing I am aware of with the box having the problem is that /usr is an NFS mount over a 100mbps LAN. Here is the debug output from an attempt: --- [EMAIL PROTECTED]:~$ ssh -X -v -v -v smokie OpenSSH_5.1p1 Debian-1, OpenSSL 0.9.8g 19 Oct 2007 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to smokie [192.168.0.100] port 22. debug1: Connection established. debug1: identity file /home/bsass/.ssh/identity type -1 debug1: identity file /home/bsass/.ssh/id_rsa type -1 debug1: identity file /home/bsass/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-1 debug1: match: OpenSSH_5.1p1 Debian-1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-1 debug2: fd 3 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[EMAIL PROTECTED],hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[EMAIL PROTECTED],hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[EMAIL PROTECTED],zlib debug2: kex_parse_kexinit: none,[EMAIL PROTECTED],zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,[EMAIL PROTECTED],aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[EMAIL PROTECTED],hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,[EMAIL PROTECTED],hmac-ripemd160,[EMAIL PROTECTED],hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,[EMAIL PROTECTED] debug2: kex_parse_kexinit: none,[EMAIL PROTECTED] debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server-client aes128-cbc hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client-server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(102410248192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 123/256 debug2: bits set: 508/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/bsass/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug3: check_host_in_hostfile: filename /home/bsass/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host 'smokie' is known and matches the RSA host key. debug1: Found key in /home/bsass/.ssh/known_hosts:1 debug2: bits set: 490/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received --- it hangs at this point until I ctrl-c it --- - Bruce -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell:
Bug#491246: tor: fails to upgrade properly
Package: tor Version: 0.2.0.30-1 Severity: normal While unpacking this message appears: Preparing to replace tor 0.2.0.29-rc-2 (using .../tor_0.2.0.30-1_i386.deb) ... Stopping tor daemon: FAILED (Is 2697 not tor? Is /usr/sbin/tor a different binary now?). Unpacking replacement tor ... Yet: [EMAIL PROTECTED]:~$ ps 2697 PID TTY STAT TIME COMMAND 2697 ?S 0:17 /usr/sbin/tor [EMAIL PROTECTED]:~# ls -l /var/run/tor total 4 -rw-r--r-- 1 debian-tor debian-tor 5 Jul 17 06:44 tor.pid [EMAIL PROTECTED]:~# cat /var/run/tor/tor.pid 2697 While setting up this message appears: Setting up tor (0.2.0.30-1) ... Raising maximum number of filedescriptors (ulimit -n) to 16384. Starting tor daemon: tor... Jul 17 17:19:24.271 [notice] Tor v0.2.0.30 (r15956). This is experimental software. Do not rely on it for strong anonymity. (Running on Linux i686) Jul 17 17:19:24.276 [notice] Initialized libevent version 1.3e using method epoll. Good. Jul 17 17:19:24.278 [notice] Opening Socks listener on 127.0.0.1:9050 Jul 17 17:19:24.279 [warn] Could not bind to 127.0.0.1:9050: Address already in use. Is Tor already running? Jul 17 17:19:24.280 [warn] Failed to parse/validate config: Failed to bind one of the listener ports. Jul 17 17:19:24.280 [err] Reading config failed--see warnings above. invoke-rc.d: initscript tor, action start failed. dpkg: error processing tor (--configure): subprocess post-installation script returned error exit status 1 -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.25-2-686 (SMP w/1 CPU core) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages tor depends on: ii adduser3.108 add and remove users and groups ii libc6 2.7-12GNU C Library: Shared libraries ii libevent1 1.3e-3An asynchronous event notification ii libssl0.9.80.9.8g-11 SSL shared libraries ii tsocks 1.8beta5-9.1 transparent network access through ii zlib1g 1:1.2.3.3.dfsg-12 compression library - runtime Versions of packages tor recommends: ii logrotate 3.7.1-3Log rotation utility ii privoxy 3.0.9-1Privacy enhancing HTTP Proxy ii socat 1.6.0.1-1 multipurpose relay for bidirection pn tor-geoipdb none (no description available) Versions of packages tor suggests: pn anon-proxynone (no description available) pn mixmaster none (no description available) pn mixminion none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463814: Hplip fails to recognize correctly installed devices
On Sat July 12 2008 11:12:29 pm David Baron wrote: On Sunday 13 July 2008 01:08:18 Bruce Sass wrote: That is the setup (the one with an hp: type device URI) we need to see the hp-check.log and actual error messages/reports for. It may well be something as simple as a missing underscore in the URI. I am confused here. The listings for both the HP and the Epson printers (which cannot be around at the same time! is coming from cups. If I attempt to probe the lp0: printer from hplip, it will not detect it. The very old version of hplip (from stable) did detect it and enabled me to try the functions (that the printer does not, in fact use). Both printers are installed via cups. I switch the lp0: between them. You will need to install the printer using HPLIP's software. The URIs were assigned by the cups setup. I manually edited the /etc/cups/printers.conf and changed the parallel: prefix to hp:. This did not help hplip and the printers no longer worked. There are no underscores, just parralel:/dev/lp0. There is more to it than simply substituting hp: for parallel:. Since the older (stable) version worked, I filed this bug. The suggestion was not mine but an earlier poster who found a similar problem. HPLIP changed the way it does things a little while ago, it sounds like some older info has been messing with our idea of what state the system is or should be in. If you have the hplip-doc package installed you should look at: /usr/share/doc/hplip-doc/HTML/setup.html then try one of those methods of setting up the printer. You can also find info at: http://hplip.sourceforge.net/ e.g.: http://hplip.sourceforge.net/troubleshooting/parallel.html Keep in mind the info at the HPLIP site may assume you have build HPLIP yourself and refer to things which Debian has done for you behind the scenes. HTH, and keep us posted. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490640: hp-scan: Aborts with a traceback when trying to scan.
severity 490640 important tag 490640 confirmed On Sun July 13 2008 03:59:43 am Andrew Ruthven wrote: Package: hplip Version: 2.8.6-1 Severity: grave Justification: renders package unusable I have downgraded the reportfrom grave to important because only scanning is affected, although scanning is a significant portion of the package there is more to HPLIP than scanning and none of those other functions appear to be affected. A quick look through src/hplip-2.8.6 shows a couple uses of scan_read and no definition of the function, but there are many more uses of scan_hpaio_read which appears to be defined in scan/sane/hpaio.c---it looks like a name change was incompletely carried out. My C and C-Python skills are a bit rusty so someone more knowledgeable should double check this finding. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483205: [Pkg-hpijs-devel] hplip: group scanner requirements.
On Sat July 12 2008 06:40:30 am Mark Purcell wrote: Thanks for the comment. The other suggestion is to use lp.plugdev But the downside of that is there is then no way to distinguish between plugged in printers and other devices such as cameras. Another downside is the combination of wild cards in the match selector with the setting of OWNER... not only do you need to ensure the hpmud.rules are read before other, more specific, rules which match the same devices, the other .rules (e.g., ghpoto's) need to also start setting OWNER so those devices don't end up owned by lp. Surely having a Photosmart camera device owned by lp.plugdev is not good since it allows anyone in group lp (traditionally, anyone with access to printers) to plug in and use a Photosmart camera even though they may not belong to group plugdev. I think hpmud.rules should stop setting OWNER, which will then default to root. Of course, if HPLIP were to start specifying individual devices instead of blocks of devices, regardless of whether or not they are printers/scanners or cameras, the setting of OWNER would not matter. As far as setting GROUP=lp|scanner|plugdev or using ACL's (eventually, since it is too close to release to to implement?)... shrug I don't know which would be best. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483205: [Pkg-hpijs-devel] hplip: group scanner requirements.
On Sat July 12 2008 08:32:49 am Till Kamppeter wrote: Mark Purcell wrote: Thanks for the comment. The other suggestion is to use lp.plugdev But the downside of that is there is then no way to distinguish between plugged in printers and other devices such as cameras. So the group ownership of a newly appearing device file is used to determine the type of plugged device (at least by certain apps)? Not that I am aware of. Wouldn't such behaviour be buggy since groups are the most basic access control mechanism and sysadmin's often fiddle with group membership--which could easily break any app trying to use group membership in such a way. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#483843: still fails to find SIP with hplip 2.8.6
On Sat July 12 2008 05:27:52 am Mark Purcell wrote: Arthur, Thanks for the update. I haven't had a detailed look into hp-check but I suspect it doesn't check in a way compatible with the way Debian has set things up. However at this stage I think it is diagnostic only and doesn't actually effect the operation of hplip. I have looked into this... Here is what hp-check does: --- from check.py --- log.info() log.info(log.bold(Checking SIP version...)) sip_ver = None try: import pyqtconfig except ImportError: pass else: sip_ver = pyqtconfig.Configuration().sip_version_str if sip_ver is not None: log.info(OK, Version %s installed % sip_ver) else: num_errors += 1 log.error(SIP not installed or version not found.) --- Here is where Debian keeps pyqtconfig: --- [EMAIL PROTECTED]:~$ dpkg -S pyqtconfig python-qt-dev: /usr/lib/python2.5/site-packages/pyqtconfig.py python-qt-dev: /usr/lib/python2.4/site-packages/pyqtconfig.py --- ...so, installing python-qt-dev will make hp-check happy, but it seems a bit silly to have HPLIP depend in any way on that -dev package. I have grep-ed through src/hplip-2.8.6 and the only places sip appears is in the check.py program and installer/distros.dat... I think it should be safe to comment out the sip test in check.py. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463814: Hplip fails to recognize correctly installed devices
On Sat July 12 2008 01:44:41 pm David Baron wrote: On Friday 11 July 2008 22:42:01 Bruce Sass wrote: Hi, The title of this bug is a little misleading. According to this hp-check.log, the device is _not_ correctly installed. hp-check[9601]: info: :| INSTALLED CUPS PRINTER QUEUES | hp-check[9601]: info: :- hp-check[9601]: info: : hp-check[9601]: info: :Type: Unknown hp-check[9601]: info: :Installed in HPLIP?: No, not using the hp: or hpfax: CUPS backend. hp-check[9601]: info: :Device URI: parallel:/dev/lp0 hp-check[9601]: info: :PPD: /etc/cups/ppd/HP690C.ppd hp-check[9601]: info: :PPD Description: HP DeskJet 690C Foomatic/hpijs, hpijs 2.8.4.2 hp-check[9601]: info: :Printer status: printer HP690C is idle. enabled since Thu 15 May 2008 07:31:55 PM IDT warning: Printer is not HPLIP installed. Printers must use the hp: or hpfax: CUPS backend to function in HPLIP. For me, the question is... Why are your attempts to configure the device failing. Where did the parallel:/dev/lp0 device URI come from? Have you tried deleting the parallel: device's entries before setting up the hp: device URI? I have tried reinstalling. The original URI is from the regular cups install. I tried changing that to one with HP stuff in it. I then reinstalled. The printer works just fine. Downgrading the package as recommended on a post found by google had it working. Actually, the printer does not support the functionality that I wanted hplip to control such as head alignment and cleaning. Does this mean we have discovered the problem and the report can be closed? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#463814: Hplip fails to recognize correctly installed devices
On Sat July 12 2008 02:19:33 pm David Baron wrote: The 2.4* and newer packages from Debian Sid do not find the printer at all so are not working correctly. I am a bit confused... The hp-check.log you sent on June 15th showed that HPLIP did indeed find the printer, and that log was generated by HPLIP-2.8.5 which is newer than 2.4*. ...so, your statement which I have included above appears to be incorrect. Like it says in your hp-check.log: --- hp-check[9601]: info: :Printer status: printer HP690C is idle. enabled since Thu 15 May 2008 07:31:55 PM IDT warning: Printer is not HPLIP installed. Printers must use the hp: or hpfax: CUPS backend to function in HPLIP. --- The errors you mention in your original report are to be expected with the configuration indicated in the hp-check.log you have provided. There is nothing buggy with that behaviour; the utilities expect hp: and hpfax: URIs and since none exist they don't find any usable devices, the toolkit finds no devices for the same reason. From a bug report point of view, and taking the additional info into account, this is the interesting bit in your original message: So I try to configure the device, go through all the steps and on finish, am back with no devices or unsupported device. Later on you said: I tried changing that to one with HP stuff in it. That is the setup (the one with an hp: type device URI) we need to see the hp-check.log and actual error messages/reports for. It may well be something as simple as a missing underscore in the URI. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#484801: automatically got a systray app which I don't need
Hello Chris, Could you have a look at bug #484801. printconf automatically drags in hplip (and hence the useless and annoying to some HP systray applet) because of this chain of Depends: printconf -- foomatic-db-hpijs -- hpijs -- hplip I think that either printconf's dependency on foomatic-db-hpijs, or foomatic-db-hpijs's dependency on hpijs is too strong---one of them should be a Suggests or Recommends. Since there is really nothing HPLIP can do to fix this bug, and both printconf and foomatic-db-hpijs are maintained by you---could you please reassign the bug to whichever of those two packages is most appropriate. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#490212: hplip: wrong placing of hp-systray icons on kde4
On Thu July 10 2008 01:05:00 pm Eric Valette wrote: Fo some reasons, this systray applet is wrongly located when other are still at they normal place (Krandrtray, kmix, korganizer, ...) So I do not konw if the bug is in the hplip python code or kde code but it is annoying. Try stopping any existing applet and running: $ hp-systray --qt4 Does that fix the problem? If so, it looks like the best way to fix your problem is to change: force_qt4 = False to force_qt4 = True at line 63 of /usr/share/hplip/systray.py... ...then keep doing so every upgrade until HPLIP is built against PyQT4. :( It doesn't look like HPLIP cares about which QT version is being used (the configure script doesn't check for QT period, and there is no way to pass that info onto the build system), yet the systray.py code has --qt3 and --qt4 options! If this was more than a minor problem I would suggest building HPLIP against PyQT4, patching the systray.py code, and placing the result in Experimental where it can be fetched by anyone trying out KDE4. HTH - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480552: fails to stop hald on upgrade...
On Wed May 14 2008 01:36:10 pm you wrote: On Wed, May 14, 2008, Bruce Sass wrote: This bug is now closed with the new dpkg; could you upgrade and confirm you still have the hal bug? I can confirm the hal package fails to configure (via dpkg-reconfigure) if /var/run/hal/hald.pid is missing. [the hal bug, imo] Well it can happen that the missing pid files confuses hal: if you attempt to start hal a second time because stop didn't find the pid file and hence didn't find hal, it's normal that the second instance may not be able to launch. The bug is that the pid file is absent in this case IMO, and this could well be fixed by the dpkg upgrade. The above only simulates what happens during dpkg's second (and subsequent) attempt to configure the package. The hal package (or any other package which would fail if a PID file disappeared) should be able to deal with that situation, imo. So I suggest you clean up things manually (reboot will clear up things) and see whether you encounter the bug again with the new dpkg. I have no way of testing whether new code in the dpkg package can be relied upon to both remove the PID file and stop the daemon without a new hal package, and even then there is no guarantee of triggering the bug... ...I don't know when I will get the time to roll-back the hal upgrade and try again---and even then I'm not sure the bug would be triggered (based on past experience with exim [which took months and a few upgrades to gather enough data to convince the Maintainer that it was an upgrading problem] and other packages [including previous hal packages] which didn't get a report). AFAICT, this is a problem which has existed for over 4-years (see: #211784)---until s-s-d (or perhaps the new invoke-rc.d) guarantees that it will actually stop the daemon it is up to packages to deal with the situation themselves... which is why I filed the report against hal and not dpkg (and/or whatever pkg invoke-rc.d lives in). IMO, something is horribly broken if a PID file can disappear yet the daemon is left running---why would any code in its right mind rm the PID file before the daemon has stopped! The only way I can envision that happenning is if some code ASSUMES that whatever it has done will result in the daemon being stopped. Assumptions have no place in core infrastructure code (or in any computer program, but that's moot) find it and you will find the cause of these failures... if that is what the latest dpkg package has done then I look forward to not having to, occasionally, manually kill processes to get a clean upgrade. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480552: fails to stop hald on upgrade...
On Thu May 15 2008 01:52:40 pm you wrote: On Thu, May 15, 2008, Bruce Sass wrote: IMO, something is horribly broken if a PID file can disappear yet the daemon is left running- Yes, but please assume that this horribly broken thing only happened with older dpkg and try fixing the system manually and reproducing the error please. I don't know how to reliably reproduce this bug (if I did I'd have sent a trace in years ago :), and don't really have the time to experiment with it right now. Sorry Let's just wait and see if it happens again during the course of the regular update/upgrades. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480552: fails to stop hald on upgrade...
On Mon May 12 2008 01:00:52 pm Loïc Minier wrote: On Mon, May 12, 2008, Bruce Sass wrote: The exim Maintainer called it a heisenbug, see #396944, he also filed #440657 shortly after but I don't know if it is related to the problem I was having or just something he ran across as he experimented. :( This bug is now closed with the new dpkg; could you upgrade and confirm you still have the hal bug? I can confirm the hal package fails to configure (via dpkg-reconfigure) if /var/run/hal/hald.pid is missing. [the hal bug, imo] I have no way of knowing if hald.pid would disappear if hal was upgraded during a normal update/upgrade cycle. [a s-s-d bug?] - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480552: fails to stop hald on upgrade...
On Sat May 10 2008 03:54:33 pm Loïc Minier wrote: On Sat, May 10, 2008, Bruce Sass wrote: Most likely we are being bitten by a start-stop-daemon bug and you may want to see how the exim Maintainer worked around the problem. Yes; there are many bugs in ssd in particular conditions. Could you write more on the conditions under which you encounter this bug? There is not much to write, it was a regular upgrade and hal was left unconfigured; it failed to configure during the next couple upgrades (expected sans a new hal package since there was no PID file), then there was a reboot which seemed to set the sys right (hald started and had a PID file in /var/run) but the package would still not configure with symptoms of the old process still running and no PID file (at which point I did the killall, --configure ---pending, and filed a report). The only strangeness with this setup is that /usr is an NFS mount (from an even less capable box, over a 100Mbps connection). I usually do daily upgrades, sometimes twice a day if a transition is in progress (e.g., like when a new PERL wants to remove 100+ packages :). All three boxes have been running Unstable for many years, this is the only one which has had problems with daemons failing to restart during upgrades. Dselect and its APT method are the only tools I ever use for updating and upgrading. In my experience, the --exec flag to ssd on stop is particularly fragile; it was already fixed for some use cases, but I'm pretty sure it will fail under e.g. unionfs. Could you try without the --exec flag? Sorry, no, I don't really have time to experiment with it in the short term right now and anytime I have done so the only significant result has been that apt-get --reinstall install ... rarely triggers the bug---afaict, I need a new package for each try and it should be part of a regular upgrade cycle. The exim Maintainer called it a heisenbug, see #396944, he also filed #440657 shortly after but I don't know if it is related to the problem I was having or just something he ran across as he experimented. :( However, if there are some specific bits to flip or some code I could wedge into the upgrade process to get better data/finer resolution re the bug I would be happy to to so for future upgrade cycles. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#480552: fails to stop hald on upgrade...
Package: hal Version: 0.5.11-1 Severity: critical Justification: breaks unrelated software ...which causes dpkg to err out, halting the upgrade process. Since neither dpkg or upgrading explicitly depends on hal, its failure is breaking unrelated software/processes. Investigation reveals that /var/run/hal/hald.pid has disappeared, but hald is still running. Manually recreating the PID file then re-attempting to configure hal gets me the same result, specifically: $ ps aux ... 111 1949 0.0 0.3 4964 1972 ?Ss May09 0:01 /usr/sbin/hald ... $ cat /var/run/hal/hald.pid 1949 [ctrl-d] $ dselect ... running dpkg --pending --configure ... Setting up hal (0.5.11-1) ... Reloading system message bus config...done. Starting Hardware abstraction layer: haldinvoke-rc.d: initscript hal, action start failed. dpkg: error processing hal (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: hal dpkg --configure returned error exit status 1. Press enter to continue. $ ps aux ... 111 1949 0.0 0.3 4964 1972 ?Ss May09 0:01 /usr/sbin/hald ... $ ls -l /var/run/hal total 0 Most likely we are being bitten by a start-stop-daemon bug and you may want to see how the exim Maintainer worked around the problem. IIRC, you can not assume that start-stop-daemon (perhaps via invoke-rc.d) will actually stop the process! s-s-d will send the signal, but it is up to you to ensure the process has actually stopped before attempting to restart it if starting will fail when the process is already running. Note: on this system (1GHz PIII, 512M RAM) /usr is an NFS mount, which is pretty much the only difference between it and the two other systems where hal upgrades cleanly. killall hald then dpkg --configure --pending works around the problem. - Bruce P.S. Starting Hardware abstraction layer: haldinvoke-rc.d: initscript hal, should be Starting Hardware abstraction layer: hald invoke-rc.d: initscript hal, i.e., you are missing a newline char somewhere -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Kernel: Linux 2.6.24-onegee (PREEMPT) Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages hal depends on: ii adduser 3.107 add and remove users and groups ii dbus 1.2.1-2 simple interprocess messaging syst ii hal-info 20080508-1 Hardware Abstraction Layer - fdi f ii libc62.7-10 GNU C Library: Shared libraries ii libdbus-1-3 1.2.1-2 simple interprocess messaging syst ii libdbus-glib-1-2 0.74-4 simple interprocess messaging syst ii libexpat11.95.8-4XML parsing C library - runtime li ii libgcc1 1:4.3.0-4 GCC support library ii libglib2.0-0 2.16.3-2The GLib library of C routines ii libhal-storage1 0.5.11-1Hardware Abstraction Layer - share ii libhal1 0.5.11-1Hardware Abstraction Layer - share ii libsmbios1 0.13.13-1 Provide access to (SM)BIOS informa ii libstdc++6 4.3.0-4 The GNU Standard C++ Library v3 ii libusb-0.1-4 2:0.1.12-11 userspace USB programming library ii libvolume-id00.114-2 libvolume_id shared library ii lsb-base 3.2-12 Linux Standard Base 3.2 init scrip ii mount2.13.1.1-1 Tools for mounting and manipulatin ii pciutils 1:3.0.0-3 Linux PCI Utilities ii pm-utils 1.1.0-1 utilities and scripts for power ma ii udev 0.114-2 /dev/ and hotplug management daemo ii usbutils 0.73-7 Linux USB utilities Versions of packages hal recommends: ii eject 2.1.5-7ejects CDs and operates CD-Changer pn libsmbios-bin none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#447860: work-around
Hi, I've been having the `start failed' problem and after snooping around I noticed there was no pidfile yet hald was running. After manually stopping and starting hald (/etc/init.d/hal stop or start) then rerunning dselect (to clear up the failed-config status, which failed) I noticed the pidfile contents did not match the pid. Manually killing hal (# killall hal), rm-ing the pidfile, then rerunning dselect's install function, seems to have fixed things. Curiously, the other two unstable boxes I run didn't have this problem. The only (for the most part) difference between these boxes is that the one with the problem has /usr mounted via NFS... a similar situation has occurred with exim and the problem was traced to start-stop-daemon not properly stopping the process (exim still fails to stop when shutting down, but seems to be working properly during upgrades). I am starting to believe that NFS and start-stop-daemon don't always get along well, but have no evidence that is the case or any theory as to why. HTH - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#452348: HPLIP doesn't mention new user-in-scanner-group requirement, other issues
On Fri November 23 2007 02:08:09 am Josselin Mouette wrote: Is the hplip-gui package part of the default installation? Is there something within the HPLIP suite which would need to change in order for it to be excluded from the default installation? I don't understand why hplip is part of the default install to begin with. I don't understand why you are bringing this here... it sounds like something you need to take up with whatever group decides what goes into the default installation. Furthermore, I think it is ridiculous to try to turn the default Debian installation into a stuff-that-integrates-with-Gnome-only desktop. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#415048: Fwd: Accepted hplip 2.7.10-2 (source i386 all)
On Wed November 21 2007 03:59:55 pm Fabian Greffrath wrote: The icon in the System-Settings Menu in Gnome is still the ugly b/w one. There are colorful icons under Applications-Office though. Are you suggesting using /usr/share/pixmaps/HPmenu.xpm instead of /usr/share/pixmaps/hp-logo.xpm? If so... that would also fit better with the KDE icon sets and as such is a good idea. If not... you will need to edit the Gnome menu yourself. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451502: hplip is NON-FREE as of 2.7.10
On Sat November 17 2007 12:30:16 pm Henrique de Moraes Holschuh wrote: I'd just remove the auto-download functionality, and *package* the plugins in non-free. One can make hplip suggest (but not recommend or depend) on the plugin package, even if it is in non-free, AFAIK.. The plugin package can depend on hplip. That would violate clauses 1. and 3. of the plugins license: 1. License Grant.HP grants you a license to Use one copy of the Software with HP printing products only. Use includes using, storing, loading, installing, executing, and displaying the Software. You may not modify the Software or disable any licensing or control features of the Software. 3. Copies and Adaptations. You may only make copies or adaptations of the Software for archival purposes or when copying or adaptation is an essential step in the authorized Use of the Software. You must reproduce all copyright notices in the original Software on all copies or adaptations. You may not copy the Software onto any public network. 1. is violated because the plugins are being used for something other than with HP printing products only, and having them on the mirrors requires that Debian make use of more than one copy. 3. is violated because we are not allowed to copy the Software onto any public network. We may be able to get permission to make publically available copies of HP's software by claiming it is an essential step in the authorized Use of the Software, but that is a bit of a stretch because it is really only essential for Debian to be able to provide access to the software via Debian's package distribution mechanisms. The way I see it: - if all HP printers required non-free software which a user was required to download then HPLIP would already be in contrib because it would be useless without additional proprietary software - if all HP printers shipped with all drivers and firmware they require then HPLIP would be in main because no other software would be necessary for HPLIP to be fully functional, regardless of whether the drivers and firmware were proprietary or not - if HP shipped Linux drivers and firmare with the printers they would still need to provide an update mechanism and Debian would be pressured to package it So, for me, the question is: Is this a `thin edge of the wedge' situation which Debian should reject because it potentially opens the door to letting installers of non-free software into main via `if it is OK to put drivers and firmware into a blob then why not whatever functionality we want'; or is it a convenience function which makes life easier for everyone (users have the nicest possible experience, no extra work or packages for Debian, HP gets the control they want), and ripping it out could be construed as unnecessarily hampering a users right to use whatever software the want regardless of its freeness (which would violate the Social Contract)? If it is a thin-edge then we may as well just put HPLIP into contrib and save ourselves a bunch of work in the long run. If the convenience of having an update mechanism included in software providing more functionality is great enough then Debian should do the short term work and come up with some guidelines with respect to: how much functionality is needed for the software to be considered more than just an installer, and what kind of functionality the non-free blob being managed is allowed to contain. If it is deemed desirable to have HPLIP in main but undesirable for it to manage non-free blobs of any description the offending code should be ripped out of HPLIP and packaged for inclusion in non-free. However, I think this route pretty much guarantees the maximum amount of work in both the short term and long run because we would need to create and maintain a fork of HPLIP. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#451502: hplip is NON-FREE as of 2.7.10
On Fri November 16 2007 05:25:01 am Rick Richardson wrote: Package: hplip Version: 2.7.10 Note: HPLIP is free, open source software distributed under the MIT, BSD, and GPL licenses. HP does not provide formal consumer or commercial support for this software. Unfortunately, this statement is incorrect as of 2.7.10. hplip/hpijs since 2.7.10 is not open software anymore. It downloads binary libraries and firmware automatically It looks like it is just the plugins needed for a few printers which are non-free[1], HPLIP itself is still GPL. The user is notified of the situation and asked to accept the non-free license before anythying is downloaded. i.e.: it is not automatic and no user will end up in a situation where they've installed Debian and ended up with non-free software as a direct result. Some users will need to install a non-free driver (which HPLIP offers to do) to make full (any?) use of their HP printer, but isn't this much the same situation that X is in when someone has a video card which needs a non-free driver? The *.plugin files can be found here: http://www.linuxprinting.org/download/printdriver/auxfiles/HP/plugins/ The code which looks after installing the plugins resides primarily in: - /usr/share/hplip/setup.py at lines 399-538 - /usr/share/hplip/installer/core_install.py at lines 1257+ I'm not sure if this situation requires: moving HPLIP into contrib, a notice that `some HP printers require a non-free driver which can not be distributed by Debian', or if it can simply be ignored. I'm leaning towards the last option because I don't think HPLIP would be considered non-free if the drivers were shipped with the printer. It is only HPLIP's ability to install non-free sowtware IF necessary which brings this issue to the forefront. - Bruce [1] LICENSE TERMS FOR HP Linux Imaging and Printing (HPLIP) Driver Plug-in These License Terms govern your Use of the HPLIP Driver Plug-in Software (the Software). USE OF THE SOFTWARE INCLUDING, WITHOUT LIMITATION, ANY DOCUMENTATION, IS SUBJECT TO THESE LICENSE TERMS AND THE APPLICABLE AS-IS WARRANTY STATEMENT. BY DOWNLOADING AND INSTALLING THE SOFTWARE, YOU ARE AGREEING TO BE BOUND BY THESE TERMS. IF YOU DO NOT AGREE TO ALL OF THESE TERMS, DO NOT DOWNLOAD AND INSTALL THE SOFTWARE ON YOUR SYSTEM. 1. License Grant.HP grants you a license to Use one copy of the Software with HP printing products only. Use includes using, storing, loading, installing, executing, and displaying the Software. You may not modify the Software or disable any licensing or control features of the Software. 2. Ownership. The Software is owned and copyrighted by HP or its third party suppliers. Your license confers no title to, or ownership in, the Software and is not a sale of any rights in the Software. HP's third party suppliers may protect their rights in the Software in the event of any violation of these license terms. 3. Copies and Adaptations. You may only make copies or adaptations of the Software for archival purposes or when copying or adaptation is an essential step in the authorized Use of the Software. You must reproduce all copyright notices in the original Software on all copies or adaptations. You may not copy the Software onto any public network. 4. No Disassembly. You may not Disassemble the Software unless HP's prior written consent is obtained. Disassemble includes disassembling, decompiling, decrypting, and reverse engineering. In some jurisdictions, HP's consent may not be required for limited Disassembly. Upon request, you will provide HP with reasonably detailed information regarding any Disassembly. 5. No Transfer. You may not assign, sublicense or otherwise transfer all or any part of these License Terms or the Software. 6. Termination.HP may terminate your license, upon notice, for failure to comply with any of these License Terms. Upon termination, you must immediately destroy the Software, together with all copies, adaptations and merged portions in any form. 7. Export Requirements. You may not export or re-export the Software or any copy or adaptation in violation of any applicable laws or regulations. 8. U.S. Government Restricted Rights. The Software has been developed entirely at private expense. It is delivered and licensed, as defined in any applicable DFARS, FARS, or other equivalent federal agency regulation or contract clause, as either commercial computer software or restricted computer software, whichever is applicable. You have only those rights provided for such Software by the applicable clause or regulation or by these License Terms. 9.
Bug#413225: hplip 2.7.7-0ubuntu4
Hi, Attention everyone who has expressed an interest in getting a newer HPLIP into Debian. I have built, installed, and done some basic testing (except for faxing) of this Ubuntu HPLIP package[1] on an up to date sid box. It seems to be working OK. It would be great if you could find the time to do the same and report back to: [EMAIL PROTECTED] In the meantime (and working under the assumption there are no serious issues), I am going to determine which bugs would be closed if it was uploaded, start working on the Ubuntu-Debian changes, and see if I can figure out how to get it into the Alioth pgk-hpijs CVS repository[2] (although I most certainly would not complain if someone who already knows how was to go ahead and check it in ;). These are the packages it builds: hpijs-ppds_2.7.7+2.7.7-0ubuntu4_all.deb hpijs_2.7.7+2.7.7-0ubuntu4_i386.deb hplip-data_2.7.7-0ubuntu4_all.deb hplip-dbg_2.7.7-0ubuntu4_i386.deb hplip-doc_2.7.7-0ubuntu4_all.deb hplip-firmware_2.7.7-0ubuntu4_all.deb hplip_2.7.7-0ubuntu4_i386.deb Hoping to hear from you soon, - Bruce [1] https://launchpad.net/ubuntu/+source/hplip/2.7.7-0ubuntu4 [2] http://alioth.debian.org/scm/?group_id=30176 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: start-stop-daemon can't stop process
[for anyone reading this in the BTS, Ian is responding to http://lists.debian.org/debian-dpkg/2007/08/msg00024.html] On Tue August 28 2007 05:27:52 am Ian Jackson wrote: Bruce Sass writes (start-stop-daemon can't stop process): I have an exim4 daemon (bug #396944) which doesn't stop... The exim4 binary on disk has been changed and now the running program doesn't have the same binary as is on disk. This was probably because you upgraded exim4 but the exim4 maintainer scripts should have arranged to stop the daemon before the upgrade. The exim4 maintainer scripts do stop the daemon before unpacking, s-s-d failed at that point. Here is the debug output of the attempt... Preparing to replace exim4-config 4.67-7 (using .../exim4-config_4.67-8_all.deb) ... Unpacking replacement exim4-config ... now debugging /var/lib/dpkg/info/exim4-config.postrm upgrade 4.67-8 + [ upgrade = purge ] Preparing to replace exim4-base 4.67-7 (using .../exim4-base_4.67-8_i386.deb) ... Unpacking replacement exim4-base ... now debugging /var/lib/dpkg/info/exim4-base.postrm upgrade 4.67-8 + [ upgrade = purge ] Preparing to replace exim4-daemon-light 4.67-7 (using .../exim4-daemon-light_4.67-8_i386.deb) ... now debugging /var/lib/dpkg/info/exim4-daemon-light.prerm upgrade 4.67-8 + [ -x /etc/init.d/exim4 ] + [ -n 1 ] + netstat -tulpen Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp0 0 127.0.0.1:2208 0.0.0.0:* LISTEN 0 290992813195/hpiod tcp0 0 0.0.0.0:20490.0.0.0:* LISTEN 0 2488620- tcp0 0 0.0.0.0:24837 0.0.0.0:* LISTEN 1000 5323638697/knotes tcp0 0 0.0.0.0:57638 0.0.0.0:* LISTEN 0 248866918734/rpc.mountd tcp0 0 0.0.0.0:58000.0.0.0:* LISTEN 1000 5323696640/kded [kdeinit] tcp0 0 0.0.0.0:59000.0.0.0:* LISTEN 1000 5323702640/kded [kdeinit] tcp0 0 127.0.0.1:56204 0.0.0.0:* LISTEN 107290996413198/python tcp0 0 0.0.0.0:59853 0.0.0.0:* LISTEN 0 2333 - tcp0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 172880431135/portmap tcp0 0 0.0.0.0:80 0.0.0.0:* LISTEN 0 3133 1407/boa tcp0 0 0.0.0.0:60010.0.0.0:* LISTEN 0 5322993589/X tcp0 0 0.0.0.0:113 0.0.0.0:* LISTEN 0 3575 1740/inetd tcp0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 704876 19851/sshd tcp0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 355536013218/cupsd tcp0 0 0.0.0.0:39095 0.0.0.0:* LISTEN 0 248787418045/rpc.statd tcp0 0 0.0.0.0:25 0.0.0.0:* LISTEN 0 3441 1685/exim4 tcp0 0 0.0.0.0:57146 0.0.0.0:* LISTEN 1000 5323496685/artsd tcp0 0 0.0.0.0:77410.0.0.0:* LISTEN 0 27901004393/lisa udp0 0 0.0.0.0:20490.0.0.0:* 0 2488619- udp0 0 0.0.0.0:32770 0.0.0.0:* 0 3503 - udp0 0 0.0.0.0:517 0.0.0.0:* 0 27908481740/inetd udp0 0 0.0.0.0:518 0.0.0.0:* 0 27908671740/inetd udp0 0 127.0.0.1:161 0.0.0.0:* 0 797911 31565/snmpd udp0 0 0.0.0.0:177 0.0.0.0:* 0 4207 1940/kdm udp0 0 0.0.0.0:77410.0.0.0:* 0 27904234393/lisa udp0 0 0.0.0.0:60225 0.0.0.0:* 0 248787118045/rpc.statd udp0 0 0.0.0.0:60226 0.0.0.0:* 0 248866418734/rpc.mountd udp0 0 0.0.0.0:68 0.0.0.0:* 0 2210 924/dhclient udp0 0 0.0.0.0:837 0.0.0.0:* 0 248786218045/rpc.statd udp0 0 0.0.0.0:36704 0.0.0.0:* 11426076569308/avahi-daemon: udp0 0 0.0.0.0:53530.0.0.0:* 114
Bug#433133: ASYNCMOUNTNFS=no
On Thu July 19 2007 03:01:30 am you wrote: I can manually start rpc.statd, then mount the missing nfs imports, but since /usr was missing during the boot there is bound to be stuff which didn't start properly. Is there a way to ensure everything is in order besides manually discovering what's broken and doing /etc/init.d/... start for them? Two ways: Either mount /usr with -o nolocks, First thing I tried (with the -10 build, both by adding it to the options list in fstab and mount -o...), mount complained that nolocks was unsupported by(for?) nfs. or try the patch in #433386 against initscripts. I'll give it a try, and I expect it will work because so far the only success I've had is with this hack: - --- /etc/init.d/portmap.orig2007-07-19 01:11:51.0 -0600 +++ /etc/init.d/portmap 2007-07-19 02:29:10.0 -0600 @@ -53,7 +53,7 @@ rm -f /var/run/portmap.state fi fi - + /sbin/start-stop-daemon --start --oknodo --exec /sbin/rpc.statd ;; stop) log_begin_msg Stopping portmap daemon... - which should have the same effect as the patch in #433386. I've seen mention of the problem starting with 2.6.22 kernels: $ uname -a Linux onegee 2.6.21-onegee #1 Sat Jun 9 05:43:37 MDT 2007 i686 GNU/Linux - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433133: init.d/portmap hack still the only one working
On Thu July 19 2007 03:58:58 am I wrote: On Thu July 19 2007 03:01:30 am you wrote: or try the patch in #433386 against initscripts. I'll give it a try, and I expect it will work because so far the only success I've had is with this hack: - --- /etc/init.d/portmap.orig2007-07-19 01:11:51.0 -0600 +++ /etc/init.d/portmap 2007-07-19 02:29:10.0 -0600 @@ -53,7 +53,7 @@ rm -f /var/run/portmap.state fi fi - + /sbin/start-stop-daemon --start --oknodo --exec /sbin/rpc.statd ;; stop) log_begin_msg Stopping portmap daemon... - which should have the same effect as the patch in #433386. It didn't work as I expected. - I applied the patch, reboot, no nfs mounted /usr. - Did: apt-get --reinstall install nfs-common initscripts[1], to make sure I hadn't forgotten to revert any failed attempts and I was on the current page, reboot, no /usr. - Went to apply the patch and found it was already applied (mostly, tried both with and without the initial portmap=no line), reboot, no /usr. - re-hacked the portmap init script, reboot, all nfs imports are mounted. I've had 6 sucessful boot using the portmap script hack above, ~12 failures using the various hacks in the bug reports and trying to start rpc.statd at various points. - Bruce [1] [EMAIL PROTECTED]:~$ dpkg -l nfs-common initscripts Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ Name Version Description +++--- ii initscripts 2.86.ds1-38 Scripts for initializing and shutting down the s ii nfs-common 1:1.1.0-11 NFS support files common to client and server -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433133: ASYNCMOUNTNFS=no
Try setting ASYNCMOUNTNFS=no in /etc/default/rcS. I'm currently talking to the initscripts maintainers to try to find a good solution; it seems like the fix in 1:1.1.0-10 introduced a race condition. This doesn't work for me, it kinda makes things worse because now the messages telling me that statd isn't running disappear off the screen before I can read them. I can manually start rpc.statd, then mount the missing nfs imports, but since /usr was missing during the boot there is bound to be stuff which didn't start properly. Is there a way to ensure everything is in order besides manually discovering what's broken and doing /etc/init.d/... start for them? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#433290: dpkg: /usr/bin/man not found
On Mon July 16 2007 01:05:01 am [EMAIL PROTECTED] wrote: why not found package man? [EMAIL PROTECTED]:/etc# dpkg -S /usr/bin/man dpkg: /usr/bin/man not found. Because /usr/bin/man is a symlink and doesn't exist as a file in any package. dpkg -S searches through the contents of the /var/lib/dpkg/info/*.list files and will only find packaged paths. $ ls -l /usr/bin/man lrwxrwxrwx 1 root root 17 May 23 03:57 /usr/bin/man - ../lib/man-db/man $ dpkg -S /usr/lib/man-db/man man-db: /usr/lib/man-db/man This is a known wishlist item and should either be closed or merged with bug #198220 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=198220) - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: exim4 giving me problems again (#396944)
On Fri June 29 2007 10:26:40 am you wrote: [Please Cc: the BTS on all correspondence, in hard-to-debug cases it is vital that the BTS has complete information.] Please allow me to bounce your message and the ones following into the BTS. sure I neglected sending to the BTS so that you would have a chance to tell me what you want to see before I fill the report with useless/distracting logs or silly questions about what to do next. :) I'll compose a proper message for the BTS containing log extracts to establish the sequence of events I mentioned, and answer the question you just asked, later today. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: exim4 giving me problems again (#396944)
Hi Marc, It happened again! The panic log has an entry at 23:13:21 for a failed start (23:08:50 in mainlog); pidwatch.log shows the pid disappearing between 22:50:01 and 23:00:02; dpkg.log shows an upgrade of exim4 starting with the -config package at 22:54:22 (dpkg started logging at 22:48:07 and finished at 23:10:04). The only other log entries around that time are for the pidwatch cron job itself (in auth and syslog), and scrollkeeper-update unregistering (22:54:28+) then registering (23:08:41+) three exim4 .omf files in scrollkeeper.log. So, how much of which logs should I send to the BTS? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#426752: Ubuntu-specific Maintainer: field processing, safety check
On Wed May 30 2007 12:42:07 pm you wrote: If you have any comments regarding our approach we'd of course be happy to hear about them. I don't think it is a good idea to hard-code downstream specific bits into the source... How about creating a framework for hooking code into the build process. Perhaps running/sourcing scripts out of a dir, trigerred by a setting in the environment---anyone could use it (mitigates any `why should Ubuntu get special treatment' arguments), everyone using it can work at their own pace (never be out-of-sync or behind), couldn't lead to source bloat disease. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: exim4 giving me problems again (#396944)
Hello Marc, I monitored the next two or three upgrades after the problem I was having disappeared, all went well so I removed the flag which was causing exim to spew debugging info out during the install... a few more upgrades later and the problem has reappeared. Exim is running, has no pid file in /var/run/exim, there is a non-empty error log, and I have not touched anything to do with exim4 manually (it has all been the packages scripts triggered by upgrades). :-/ Got any ideas for a script to monitor the health of exim4 on this box? Do you want all the logs? Aside from looking for a running exim4, existing pidfile, and the error log, I haven't touched anything... direct me. :-) - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: exim4 giving me problems again (#396944)
On Mon January 22 2007 01:01, you wrote: On Sun, Jan 21, 2007 at 02:21:10PM -0700, Bruce Sass wrote: I monitored the next two or three upgrades after the problem I was having disappeared, all went well so I removed the flag which was causing exim to spew debugging info out during the install... a few more upgrades later and the problem has reappeared. Exim is running, has no pid file in /var/run/exim, there is a non-empty error log, and I have not touched anything to do with exim4 manually (it has all been the packages scripts triggered by upgrades). Can I forward your message to the BTS? sure Otherwise, I am kind of stumped as you seem to be the only one experiencing this and this is only a heisenbug. races can look like this... /usr is an NFS mount, as is /var/cache apt/archives, and dselect (in addition to KDE and probably a torrent) would be running off the same drive on the box which exports both (a 350MHz, P3, 128M RAM, over a 100Mbps LAN) The only thing I can think of which is likely to get at this bug would be a series of packages designed to troubleshoot the upgrade process. If you were to design such a package, put it in an apt-gettable archive, then give it a new version number every day (simply mv-ing the .deb), I would be able to do a realistic upgrade every day. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#117783: acknowledged by developer (doesn't appear to be a bug)
On Tue December 12 2006 04:08, Michael Piefel wrote: ... Not reproducible, no response from submitter... closing. ‘No response,’ well, I might have responded had I known that I was being talked to. The bug report is five years old, then you come and add something to the report and expect me to react within a month. Am I supposed to monitor each of the bugs I submit? Ever heard of CC? I did CC you, a few hours later: --- From: Bruce Sass [EMAIL PROTECTED] To: Michael Piefel [EMAIL PROTECTED] Subject: Fwd: lines in dselect are cut off Date: Wed, 8 Nov 2006 23:48:08 -0700 Message-Id: [EMAIL PROTECTED] oops, forgot to CC you, sorry. ... --- - Bruce
Bug#396797: updated GIT-DPKG commands, with docs
Hi,
Here is: an expanded set of DPKG commands for GIT, a diff to the current
texinfo docs, and a brief help file for the commands.
- Bruce
--- git.texinfo 2006-11-13 14:10:55.0 -0700
+++ git-bms.texinfo 2006-12-08 05:15:41.0 -0700
@@ -1250,6 +1250,7 @@
* Wiping Files::How to wipe a file.
* Searching Files:: How to search a file.
* Archive Files:: How to manage tar based archive files.
+* DEB Packages::How to work with DEB packages.
* RPM Packages::How to install and uninstall RPM packages.
* File Types:: How to figure out the file type.
* MSDOS Files:: How to access msdos floppies.
@@ -2086,7 +2087,7 @@
@kindex ^X W
[EMAIL PROTECTED] Archive Files, RPM Packages, Searching Files, Files
[EMAIL PROTECTED] Archive Files, DEB Packages, Searching Files, Files
@subsubsection Managing tar based archive files
@noindent
@@ -2197,7 +2198,184 @@
@kindex ^C b V
[EMAIL PROTECTED] RPM Packages, File Types, Archive Files, Files
[EMAIL PROTECTED] DEB Packages, RPM Packages, Archive Files, Files
[EMAIL PROTECTED] Working with DPKG
+
[EMAIL PROTECTED] provides commands for manipulating and querying the dpkg
+database, @code{gitfm}'s DPKG commands allow quick access to most of
+those which operate on binary packages, files, or require package
+names as arguments. All package names can be found as directories in
+/usr/share/doc. Most commands use their single character @code{dpkg}
+option letter as the key command.
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D i}
[EMAIL PROTECTED]
+Install the @code{deb} file(s) selected or pointed by the cursor
+(@samp{DPKG-INSTALL}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] DPKG-INSTALL
[EMAIL PROTECTED] ^C ^D i
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D R i}
[EMAIL PROTECTED]
+Recursively install the @code{deb} file(s) in the directories selected or
+pointed by the cursor (@samp{R-DPKG-INSTALL}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] R-DPKG-INSTALL
[EMAIL PROTECTED] ^C ^D R i
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D u}
[EMAIL PROTECTED]
+Unpack the @code{deb} file(s) selected or pointed by the cursor, but
+don't configure it (@samp{DPKG-UNPACK}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] DPKG-UNPACK
[EMAIL PROTECTED] ^C ^D u
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D R u}
[EMAIL PROTECTED]
+Recursively unpack the @code{deb} file(s) in the directories selected or
+pointed by the cursor, but don't configure them (@samp{R-DPKG-UNPACK}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] R-DPKG-UNPACK
[EMAIL PROTECTED] ^C ^D R u
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D C}
[EMAIL PROTECTED]
+Configure the unpacked package(s) selected or pointed by the cursor
+(@samp{DPKG-CONFIGURE}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] DPKG-CONFIGURE
[EMAIL PROTECTED] ^C ^D C
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D r}
[EMAIL PROTECTED]
+Remove the package(s) selected or pointed by the cursor
+(@samp{DPKG-REMOVE}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] DPKG-REMOVE
[EMAIL PROTECTED] ^C ^D r
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D P}
[EMAIL PROTECTED]
+Purge the package(s) selected or pointed by the cursor
+(@samp{DPKG-PURGE}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] DPKG-PURGE
[EMAIL PROTECTED] ^C ^D P
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D A}
[EMAIL PROTECTED]
+Update dpkg and dselect's idea of which packages are available with
+information from the @code{deb} file(s) selected or pointed by the
+cursor (@samp{DPKG-RECORDAVAIL}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] DPKG-RECORDAVAIL
[EMAIL PROTECTED] ^C ^D A
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D R A}
[EMAIL PROTECTED]
+Recursively update dpkg and dselect's idea of which packages are
+available with information from the @code{deb} file(s) in the directories
+selected or pointed by the cursor (@samp{R-DPKG-RECORDAVAIL}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] R-DPKG-RECORDAVAIL
[EMAIL PROTECTED] ^C ^D R A
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D h}
[EMAIL PROTECTED]
+Display quick help file for GIT's DPKG commands.
+(@samp{DPKG-HELP}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] DPKG-HELP
[EMAIL PROTECTED] ^C ^D h
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D c}
[EMAIL PROTECTED]
+Lists the contents of the filesystem tree archive portion of the
[EMAIL PROTECTED] file pointed by the cursor (@samp{DPKG-CONTENTS}).
[EMAIL PROTECTED] display
[EMAIL PROTECTED] DPKG-CONTENTS
[EMAIL PROTECTED] ^C ^D c
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D f}
[EMAIL PROTECTED]
+Extracts control file information from a @code{deb} file pointed by
+the cursor (@samp{DPKG-FIELD}). You are presented with the file name and
+can either hit ENTER to see all fields, or add control file field names
+to see only those fields.
[EMAIL PROTECTED] display
[EMAIL PROTECTED] DPKG-FIELD
[EMAIL PROTECTED] ^C ^D f
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] ^D I}
[EMAIL PROTECTED]
+Provides information about a @code{deb} file pointed by the
Bug#397073: Fwd: Re: Bug#397073: konsole: not reading ~/.bashrc
-- Forwarded Message -- Subject: Re: Bug#397073: konsole: not reading ~/.bashrc Date: Wed November 29 2006 15:56 From: Bruce Sass [EMAIL PROTECTED] To: Carsten Klein [EMAIL PROTECTED] Hello, On Wed November 29 2006 13:14, you wrote: Sorry for spamming you, Bruce, You've nothing to be sorry about. however, I forgot to mention that if you start konsole using the -ls option and also using a I don't want every konsole session to be login session; there is stuff in my .bash_profile which is useless or inappropriate for non-login sessions. profile.d/bashrc.sh script, you will have to also alias su as su - in order to make it work. Otherwise, su will always stall and return to the originally invoking shell and by that also will take a lot of time. /etc/profile.d is for system wide stuff, I wouldn't want to impose my configs on every account. I'm not sure what su has to do with it. Regards Carsten PS: the same with xterm, so it is not necessarily a malfunction of konsole alone, perhaps it is with the overall system configuration of fedora core 6? FC6?, I'm using Debian, maybe some KDE silliness though. Xterm can't be the same because it doesn't offer pre-defined sessions like konsole does; starting konsole or xterm provides the proper environment (.bashrc is read), starting a konsole session does not. Most of my sessions are started via the Terminal Sessions menu in Kicker. It is possible to work around the problem by defining a session to execute bash -i -c someprg instead of someprg, but that results in an extra bash process (bash-bash-someprg instead of bash-someprg) which is just as silly as Konsole session programs behaving differently depending on whether KDE is started via kdm or startx, imo. Everything works as it is supposed to when I do startx startkde ..., so I've disabled kdm from starting at boot and have the following in my .bash_profile: alias kde='startx /usr/bin/startkde -- :1 -dpi 100 temp/kde-log ' Great for the local box, doesn't help when logging in to KDE via xdmcp though. - Bruce p.s. - what URL did you read the report from (I'm a little surprised to see a response from a FC user)? --- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#394551: Manual pages empty
tags 394551 patch stop Hi, The cause is a missing notangle command... make[2]: Entering directory `/build/buildd/noweb-2.11b/src/xdoc' notangle -t8 -Rnotangle.1 manpage.nw ../shell/noweave.nw docdate.nw | ./doversion notangle.1 /bin/sh: notangle: command not found notangle -t8 -Rcpif.1 manpage.nw docdate.nw | ./doversion cpif.1 /bin/sh: notangle: command not found notangle -t8 -Rnoweb.1 manpage.nw docdate.nw | ./doversion noweb.1 /bin/sh: notangle: command not found notangle -t8 -Rnowebstyle.7 manpage.nw ../tex/support.nw docdate.nw | ./doversion nowebstyle.7 /bin/sh: notangle: command not found notangle -t8 -Rnuweb2noweb.1 manpage.nw docdate.nw | ./doversion nuweb2noweb.1 /bin/sh: notangle: command not found ...the attached dpatch file fixes the problem by replicating what notangle does using the just built markup and nt executables. CCing anyone who may be interested, sorry for any duplicate emails generated. - Bruce 09_tangle_manpages.dpatch Description: application/shellscript
Bug#394551: Manual pages empty
On Fri November 17 2006 20:18, you wrote: ...the attached dpatch file fixes the problem by replicating what notangle does using the just built markup and nt executables. Does anybody know at what point this got broken? I thought Joey and I had everything straightened out in 2.11b-1.3. From the buildd reports: http://buildd.debian.org/build.php?arch=pkg=noweb It looks like a problem which was hidden by the build-dependency on noweb seen in 2.10c-3.4. The last NMU (2.11b-1.4) brought things to light. The build of 2.11b-1.3 did not need to do anything in xdoc, maybe a binary vs. source NMU issue. In case it's not clear, I am the upstream author of this package. I have a version 2.12 that is ready for release, but I am looking for work right now and so will probably not have time to deal with it for several months. I'm not really qualified to maintain the Debian package, but when I do release 2.12 I will try once again to fix things. Ya, that's why I CCed you. I realize it may not be the best fix, but Testing is going to hard-freeze fairly soon so it seemed like a good idea to get those man pages into the package. Would pbuilder have caught this bug? I'm not sure. The error isn't fatal to the build process so it could easily have gone unnoticed if the builder didn't check the resulting package closely. - Bruce
Bug#397073: something deeper going on
Hi, .bashrc is read as expected from the documented behaviour when I start Konsole outside of KDE (specifically, UDE) then start a GIT session. Compare this diff with the one attached to a previous message... - --- env.cmdline 2006-11-14 15:19:42.985477511 -0700 +++ env.session 2006-11-14 15:19:09.568135878 -0700 @@ -2,7 +2,7 @@ MINICOM=-c on GIT_SHELL=/bin/bash LANGUAGE=en_CA:en_US:en_GB:en -KONSOLE_DCOP_SESSION=DCOPRef(konsole-16463,session-2) +KONSOLE_DCOP_SESSION=DCOPRef(konsole-16463,session-3) USER=bsass MAIL=/var/mail/bsass GIT_EDITOR=jed @@ -14,6 +14,7 @@ COLORTERM= LOGNAME=bsass HOSTDISPLAY=onegee:1.0 +_=/usr/bin/gitfm WINDOWID=16777223 COLUMNS=88 GIT_BROWSER=sensible-browser @@ -28,7 +29,7 @@ LESSCLOSE=/usr/bin/lesspipe %s %s UDEdir=/usr/share/ude/ GIT_PAGER=less -PWD=/home/bsass +PWD=/home/bsass/tmpfs PRINTER=lj5n LINES=49 GIT_RMAIL=mail - Something is broken in KDE which causes Konsole to misbehave, but I don't know where or how to track it down... (useful :-) suggestions appreciated. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
On Mon November 13 2006 03:11, Sune Vuorela wrote: On Monday 13 November 2006 05:33, Bruce Sass wrote: Is it something for konsole to run _instead_ of bash? or? hmmm, ya, sure... hmm... so you expect konsole to read conffiles for bash when it is actually running another shell/program. That makes little sense to me---Konsole is a fancy x-terminal and should be doing the equivalent of bash -c someprogram with session programs. It is not konsole that reads your .bashrc, it is bash that reads it. Have another look at the output from env I sent, it contains: SHELL=/bin/bash So, ~/.bashrc should have been read, and it used to work correctly... If I remember correct, kde sources entire .kde/env/* when it boots, so if you adds a file containing #! /bin/bash if [ -e ~/.bashrc ] then .bashrc fi you will have your environment vars set in your .bashrc in entire kde. Alternatively just set the ones you like GITPAGER=foo SOMEVAR=bar and add it to a file in .kde/env/ (If you don't have .kde/env/, you can just create it) ...without polluting the environment for all of KDE, or needing to configure the same thing in multiple places. Your solution is also not good if one wanted a different environment for sh, bash, etc., where the same variable may need to take on different values. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396797: GIT: where to document distro specific pkg management commands
Hi, I am trying to get some DEB specific commands added to Debian's GIT package... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=396797 ...but am unsure as to the best place to document them in the git.html file. Adding DEB Packages to the end of the File operations section is most obvious... but I can't help thinking that a new `Package Management' section is warranted. What do you recommend? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
On Mon November 13 2006 14:50, Sune Vuorela wrote: #first step on unversioned close: tag 397073 +wontfix thanks On Monday 13 November 2006 13:20, Bruce Sass wrote: That makes little sense to me---Konsole is a fancy x-terminal and should be doing the equivalent of bash -c someprogram with session programs. I guess that this is what konsole does - or sh -c someprogram. You seem to be doing a lot of guessing... :-/ which is why I am sending a copy to your Application Manager. Kurt, please have a look at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397073 If you read the bash manpage, it says that bash only read .bashrc when invoked interactively. Since when is a Konsole session not interactive? and this is how bash is supposed to work - so this is not a bug neither in konsole or in bash. You are wrong. ...without polluting the environment for all of KDE, or needing to configure the same thing in multiple places. Your solution is also not good if one wanted a different environment for sh, bash, etc., where the same variable may need to take on different values. if you want _konsole_ to read your .bashrc before spawning random programs, how should konsole be able to differ it you wanted a different environment or not. Konsole should not read random configuration files before invoking a program - wether the program is zsh, bash or mc or - the programs should read the configuration files it need itself. .bashrc is not some random configuration file, and a program should not be required to read a shell's profile or runtime configuration files! You can however create wrappescripts for your own cat __EOF__ ~/bin/commandwrapper #! /bin/bash if [ -e ~/.bashrc ] then . .bashrc fi /usr/bin/realcommand __EOF__ and then have your session invoking bash ~/bin/commandwrapper That is not an acceptable solution, it is a hack-around. I think you should remove the wontfix tags and get some help from a knowledgeable DD, or send it upstream. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
On Mon November 13 2006 16:13, Sune Vuorela wrote: On Monday 13 November 2006 23:38, Bruce Sass wrote: You seem to be doing a lot of guessing... :-/ which is why I am sending a copy to your Application Manager. Thank you. You are most welcome to show my application manager that I do a hard work on the kde bugs. Or how you tackle reports about programs for which you have limited knowledge---sessions are a key feature of konsole, they get their own tab in the config dialog, yet you were unaware of them and blindly went ahead tagging the report as unreproducible. Kurt, please have a look at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=397073 If you read the bash manpage, it says that bash only read .bashrc when invoked interactively. Since when is a Konsole session not interactive? bash is not interactive when not connected to a terminal. This is bash behaviour, not konsole behaviour. From the bash manpage: An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state. Perhaps the underlying bug is that konsole is not properly identifying itself as a terminal. and this is how bash is supposed to work - so this is not a bug neither in konsole or in bash. You are wrong. Please point me where. Konsole should behave like any other x-terminal (which are interactive), sessions are like bash -c somecommand (you have admitted as much)... both point to .bashrc being read. .bashrc is not some random configuration file, and a program should not be required to read a shell's profile or runtime configuration files! .bashrc is just a random canfiguration file. Just try ask any zsh user. What does zsh have to do with Konsole putting SHELL=/bin/bash in the environment? I think you should remove the wontfix tags and get some help from a knowledgeable DD, or send it upstream. I actually have discussed this with several knowledgeable DDs and they agree with me. Then you should send it upstream because sessions are crippled... it should not matter if one starts a shell session then types in a command vs. uses a pre-defined session to start the command. Please stop being abusive. How have I been abusive? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
On Mon November 13 2006 17:27, Clint Adams wrote: An interactive shell is one started without non-option arguments and without the -c option whose standard input and error are both connected to terminals (as determined by isatty(3)), or one started with the -i option. PS1 is set and $- includes i if bash is interactive, allowing a shell script or a startup file to test this state. Perhaps the underlying bug is that konsole is not properly identifying itself as a terminal. The underlying bug is either that you want konsole to exec 'bash -i -c whatever' or that you expect bash to behave differently can it does. That is not correct; Konsole is for interactive use so -i should not be necessary. Furthermore... help:/konsole/sessions.html, point 4. clearly states: Enter a command just as you normally would if you opened a new shell and were going to issue that command. However, that is not what is happening as the attached diff of GIT started from a Konsole commandline and as a KonsoleApplication shows. help:/konsole/menubar.html has a note which says... See the file README.linux.console in the Konsole source package for detailed information on how the Linux® console differs from a typical UNIX® console. ...and help:/konsole/introduction.html contains... Konsole is what is known as an X terminal emulator, often referred to as a terminal or a shell. It gives you the equivalent of an old-fashioned text screen on your desktop, but one which can easily share the screen with your graphical applications. ...yet there is nothing in README.linux.console which indicates such a significant departure from standard x-terminal behaviour, and the README simply states: Konsole is an X terminal emulation. Clearly, it would be a bug if bash was used on an old-fashioned text screen and it didn't read .bashrc... so why is it OK for Konsole to not make sure bash is started in a like manner? - Bruce --- env.cmdline 2006-11-13 17:43:57.691322496 -0700 +++ env.session 2006-11-13 17:43:28.446396194 -0700 @@ -1,22 +1,18 @@ -LESSOPEN=| /usr/bin/lesspipe %s KDE_FULL_SESSION=true -MINICOM=-c on GS_LIB=/home/bsass/.fonts DM_CONTROL=/var/run/xdmctl GIT_SHELL=/bin/bash LANGUAGE=en_CA:en_US:en_GB:en -KONSOLE_DCOP_SESSION=DCOPRef(konsole-28686,session-1) +KONSOLE_DCOP_SESSION=DCOPRef(konsole-28686,session-2) USER=bsass -GIT_EDITOR=jed +GIT_EDITOR=sensible-editor SSH_AGENT_PID=1821 SHLVL=1 HOME=/home/bsass XDM_MANAGED=/var/run/xdmctl/xdmctl-:0,maysd,mayfn,sched,rsvd,method=classic DESKTOP_SESSION=kde -PAGER=less GTK_RC_FILES=/etc/gtk/gtkrc:/home/bsass/.gtkrc:/home/bsass/.kde/share/config/gtkrc DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-K3fvdVLN8B,guid=673558459f7175b0e4354a51639d5400 -VISUAL=kate COLORTERM= LOGNAME=bsass _=/usr/bin/gitfm @@ -30,15 +26,11 @@ XCURSOR_THEME=Chameleon-DarkSkyBlue-Regular KONSOLE_DCOP=DCOPRef(konsole-28686,konsole) DISPLAY=:0.0 -LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.flac=01;35:*.mp3=01;35:*.mpc=01;35:*.ogg=01;35:*.wav=01;35: SSH_AUTH_SOCK=/tmp/ssh-jsYQNr1776/agent.1776 GIT_VMSTAT=free SHELL=/bin/bash -LESSCLOSE=/usr/bin/lesspipe %s %s KDE_MULTIHEAD=false -GIT_PAGER=less -PWD=/home/bsass -PRINTER=lj5n +GIT_PAGER=sensible-pager +PWD=/usr/src/kdebase-3.5.5a.dfsg.1/konsole LINES=49 GIT_RMAIL=mail -EDITOR=jed
Bug#397073: konsole: not reading ~/.bashrc
On Mon November 13 2006 17:35, Sune Vuorela wrote: On Tuesday 14 November 2006 00:55, Bruce Sass wrote: Perhaps the underlying bug is that konsole is not properly identifying itself as a terminal. Maybe. xterm behaves same way. [EMAIL PROTECTED]:~$ echo TESTVAR=brucesass .bashrc ###press alt-f2 - type env kdeenv [EMAIL PROTECTED]:~$ grep TESTVAR kdeenv ###press alt-f2 - type xterm -e env xtermenv [EMAIL PROTECTED]:~$ grep TESTVAR xtermenv [EMAIL PROTECTED]:~$ grep SHELL xtermenv SHELL=/bin/bash XTERM_SHELL=/bin/bash [EMAIL PROTECTED]:~$ so when having xterm invoke another program instead of bash also not read .bashrc - I find it correct for konsole to behave like xterm here. Good point, but I am not doing `konsole -e gitfm' and that is not how sessions are supposed to work according to the Konsole docs. ... this says that .bashrc is _not_ read when doing bash -c It turns out this is not relevent because sessions are supposed to work as if you opened a new shell and were going to issue that command. That is clearly not what is happenning (see my response to Clint's message... for that reason alone this report should be forwarded upstream so they can determine if Konsole sessions are broken or behaviour has changed and the docs need to be updated. I have been using Konsole sessions for years and the lack of behaviour I am describing is recent. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
On Mon November 13 2006 18:02, Sune Vuorela wrote: On Tuesday 14 November 2006 01:35, Sune Vuorela wrote: [EMAIL PROTECTED]:~$ echo TESTVAR=brucesass .bashrc woops. Typo here - it should have been echo export TESTVAR=brucesass shrug So, does that change the outcome? I don't see it as relevent since Konsole is an x-terminal and I'm not doing konsole -e ... which would have been the equivalent of your experiment. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
On Mon November 13 2006 18:34, you wrote: That is not correct; Konsole is for interactive use so -i should not be necessary. Furthermore... You are misunderstanding the bash man page. The '-c' makes bash non-interactive. I understand that, it turns out I was wrong in assuming a Konsole session is like a bash -c ..., it is supposed to be like starting a shell then typing a command---which results in an interactive session. So, ya, a red herring but it doesn't change the buggy behaviour I am seeing. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
On Mon November 13 2006 20:00, Sune Vuorela wrote: On Tuesday 14 November 2006 02:10, Bruce Sass wrote: help:/konsole/sessions.html, point 4. clearly states: Enter a command just as you normally would if you opened a new shell and were going to issue that command. Maybe this line has been thru the sales department, but I can also open new shells that don't read my .bashrc The line maybe could say Enter a command as you normally would if you opened a new shell and were to issue that command. The command will be invoked with sh -c /command/ or maybe: Enter a command as you normally would in a shell. This command will be executed instead of your shell But that is not what it says, maybe you should stop guessing and making things up. Why not take the docs for what they say, or ask upstream. I have looked more into it. I cannot find any evidence that konsole actually invokes bash -c yourcommand, but instead I seem to suggest ... Yes, bash -c ... was an error on my part, and I do have a .profile with the relevent bits just in case Konsole was lying by using sh instead of the indicated SHELL=/bin/bash... as it turns out that is not relevent to this bug. Debian's Konsole behaviour differs from both documented and past behaviour in a way that cripples the use of sessions. Either Debian's Konsole is broken, Konsole is broken, or the behaviour changed and the documentation didn't... any of those situations warrants a bug report and no amount of maybes, guesses, or attempts to remember on your part is going to change that. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
Hi, A konsole shell is fine, but session programs are not. I have a session which starts GNU Interactive Tools (apt-get install git) using the command gitfm. The output of env from within that session is... - KDE_FULL_SESSION=true GS_LIB=/home/bsass/.fonts DM_CONTROL=/var/run/xdmctl GIT_SHELL=/bin/bash LANGUAGE=en_CA:en_US:en_GB:en KONSOLE_DCOP_SESSION=DCOPRef(konsole-22261,session-3) USER=bsass GIT_EDITOR=sensible-editor SSH_AGENT_PID=1820 SHLVL=1 HOME=/home/bsass XDM_MANAGED=/var/run/xdmctl/xdmctl-:0,maysd,mayfn,sched,rsvd,method=classic DESKTOP_SESSION=kde GTK_RC_FILES=/etc/gtk/gtkrc:/home/bsass/.gtkrc:/home/bsass/.kde/share/config/gtkrc DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-r6t9xCKC71,guid=444e5045b49d499aec2c0e679a125000 COLORTERM= LOGNAME=bsass _=/usr/bin/gitfm WINDOWID=48234503 COLUMNS=88 GIT_BROWSER=sensible-browser TERM=xterm GTK2_RC_FILES=/etc/gtk-2.0/gtkrc:/home/bsass/.gtkrc-2.0:/home/bsass/.kde/share/config/gtkrc-2.0 SESSION_MANAGER=local/onegee:/tmp/.ICE-unix/1876 PATH=/home/bsass/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games:/usr/bin XCURSOR_THEME=Chameleon-DarkSkyBlue-Regular KONSOLE_DCOP=DCOPRef(konsole-22261,konsole) DISPLAY=:0.0 SSH_AUTH_SOCK=/tmp/ssh-EFGVug1775/agent.1775 GIT_VMSTAT=free SHELL=/bin/bash KDE_MULTIHEAD=false GIT_PAGER=sensible-pager PWD=/home/bsass LINES=49 GIT_RMAIL=mail Press almost any key to continue - ...but GIT_PAGER should be =less and there should be the results of eval `lesspipe` (LESSOPEN=| /usr/bin/lesspipe %s and LESSCLOSE=/usr/bin/lesspipe %s %s) in the environment. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
hmm.. What is a session program? A program started via the Session menu, maybe I should be calling them Konsole Applications. How do I set up a session program? - start konsole - select Configure Konsole from the Settings menu - select the Session tab - put a descriptive name in the Name field - put a text mode command in the Execute field - put a path to cd to in the Directory field - choose an appropriate Icon, Schema, etc. - hit the Save Session button You'll end up with a .desktop file in ~/.kde/share/apps/konsole, e.g: --- ssh to bms.desktop --- [Desktop Entry] Cwd= Exec=ssh -X bms Font= Icon=konsole KeyTab= Name=ssh to bms Schema= Term=xterm Type=KonsoleApplication -- which shows up in the Session menu as New ssh to bms and starts a SSH login with X-forwarding on the host named bms. Is it something for konsole to run _instead_ of bash? or? hmmm, ya, sure... - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#117783: lines in dselect are cut off
tags unreproducible moreinfo thanks I am not seeing the described behaviour... any info not on the screen is made available via cursor-right. The lack of a newline could indicate that the rest of the line was available but just not visible, and the cut'n'paste behaviour seen could depend on the version of gpm used or a particular x-terminal. Did you try panning the screen? Perhaps it is a bug which was fixed awhile back and the report not closed? - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: running exim4 not found
On Mon November 6 2006 01:58, Marc Haber wrote: On Mon, Nov 06, 2006 at 12:47:45AM -0700, Bruce Sass wrote: [EMAIL PROTECTED]:~# ls -al /var/run/exim4 total 1 drwxr-x--- 2 Debian-exim Debian-exim 48 Nov 5 21:22 . drwxr-xr-x 22 rootroot1048 Nov 5 21:31 .. That looks fine, besides that there is no pidfile written there. Was an exim running when you did that ls? If so, please kill it manually and send me the output of # EX4DEBUG=1 /etc/init.d/exim4 start [EMAIL PROTECTED]:~# /etc/init.d/exim4 stop Stopping MTA:. [EMAIL PROTECTED]:~# ps aux|grep exim 102 26817 0.0 0.1 5348 1000 ?Ss Nov04 0:00 /usr/sbin/exim4 -bd -q30m root 13089 0.0 0.0 1640 504 pts/2R+ 02:35 0:00 grep exim [EMAIL PROTECTED]:~# killall exim4 [EMAIL PROTECTED]:~# ps aux|grep exim [EMAIL PROTECTED]:~# EX4DEBUG=1 /etc/init.d/exim4 start now debugging /etc/init.d/exim4 start + ENV=env -i LANG=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 + QUEUERUNNER=combined + QUEUEINTERVAL=30m + UPEX4OPTS= + PIDFILE=/var/run/exim4/exim.pid + QRPIDFILE=/var/run/exim4/eximqr.pid + [ -f /etc/default/exim4 ] + . /etc/default/exim4 + EX4DEF_VERSION= + QUEUERUNNER=combined + QUEUEINTERVAL=30m + COMMONOPTIONS= + QUEUERUNNEROPTIONS= + QFLAGS= + SMTPLISTENEROPTIONS= + [ -f /etc/inetd.conf ] + grep -E -q ^[[:space:]]*((\*|[[:alnum:].-]+):)?smtp /etc/inetd.conf + DAEMON=/usr/sbin/exim4 + NAME=exim4 + test -x /usr/lib/exim4/exim4 + log_daemon_msg Starting MTA + [ -z Starting MTA ] + [ -z ] + echo -n Starting MTA: Starting MTA:+ return + upex4conf + UPEX4CONF=update-exim4.conf + OLDIFS= + IFS=: + [ -x /usr/local/sbin/update-exim4.conf ] + [ -x /usr/local/bin/update-exim4.conf ] + [ -x /usr/sbin/update-exim4.conf ] + IFS= + /usr/sbin/update-exim4.conf + return 0 + isconfigvalid + /usr/sbin/exim4 -bV + start_exim + [ -e /var/run/exim4 ] + env -i LANG=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 start-stop-daemon --start --pidfile /var/run/exim4/exim.pid --exec /usr/sbin/exim4 -- -bd -q30m + log_progress_msg exim4 + [ -z exim4 ] + echo -n exim4 exim4+ log_end_msg 0 + [ -z 0 ] + log_use_fancy_output + TPUT=/usr/bin/tput + EXPR=/usr/bin/expr + [ xxterm != xdumb ] + [ -x /usr/bin/tput ] + [ -x /usr/bin/expr ] + /usr/bin/tput hpa 60 + /usr/bin/tput setaf 1 + [ -z ] + FANCYTTY=1 + true + /usr/bin/tput setaf 1 + RED= + /usr/bin/tput op + NORMAL= + [ 0 -eq 0 ] + echo . . + return 0 + warn_paniclog + [ -s /var/log/exim4/paniclog ] + exit 0 [EMAIL PROTECTED]:~# tail /var/log/exim4/mainlog 2006-11-06 01:35:02 End queue run: pid=11667 2006-11-06 02:05:02 Start queue run: pid=12427 2006-11-06 02:05:02 End queue run: pid=12427 2006-11-06 02:35:03 Start queue run: pid=13075 2006-11-06 02:35:03 End queue run: pid=13075 2006-11-06 02:36:57 IPv6 socket creation failed: Address family not supported by protocol 2006-11-06 02:36:57 Failed to create IPv6 socket for wildcard listening (Address family not supported by protocol): will use IPv4 2006-11-06 02:36:57 exim 4.63 daemon started: pid=13135, -q30m, listening for SMTP on port 25 (IPv4) 2006-11-06 02:36:57 Start queue run: pid=13141 2006-11-06 02:36:57 End queue run: pid=13141 [EMAIL PROTECTED]:~# ls -al /var/run/exim4 total 5 drwxr-x--- 2 Debian-exim Debian-exim 72 Nov 6 02:36 . drwxr-xr-x 22 rootroot1048 Nov 5 21:31 .. -rw-r--r-- 1 rootDebian-exim6 Nov 6 02:36 exim.pid [EMAIL PROTECTED]:~# cat /var/run/exim4/exim.pid 13135 [EMAIL PROTECTED]:~# su -c cp /etc/exim4/exim4.conf.template /var/run/exim4 Debian-exim [EMAIL PROTECTED]:~# ls -al /var/run/exim4 total 5 drwxr-x--- 2 Debian-exim Debian-exim 72 Nov 6 02:36 . drwxr-xr-x 22 rootroot1048 Nov 5 21:31 .. -rw-r--r-- 1 rootDebian-exim6 Nov 6 02:36 exim.pid Does cp /etc/exim4/exim4.conf.template /var/run/exim4 (done as Debian-exim) work? pauses for a couple of seconds, but nothing written - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: running exim4 not found
oops, too fast on the send with that last message On Mon November 6 2006 01:58, Marc Haber wrote: Does cp /etc/exim4/exim4.conf.template /var/run/exim4 (done as Debian-exim) work? Maybe I'm not getting what you mean by done as Debian-exim. The su command I used is all I can think of, but I would not expect it to work because the Debian-exim user has /bin/false as its shell... [EMAIL PROTECTED]:~$ cat /etc/passwd |grep Debian-exim Debian-exim:x:102:102::/var/spool/exim4:/bin/false what is user mail... [EMAIL PROTECTED]:~$ cat /etc/passwd |grep mail mail:x:8:8:mail:/var/mail:/bin/sh - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: running exim4 not found
On Mon November 6 2006 03:26, Marc Haber wrote: On Mon, Nov 06, 2006 at 02:55:52AM -0700, Bruce Sass wrote: Now, let's see the output of # EX4DEBUG=1 /etc/init.d/exim4 stop [EMAIL PROTECTED]:~# ps aux|grep exim 102 13135 0.0 0.1 5352 1000 ?Ss 02:36 0:00 /usr/sbin/exim4 -bd -q30m root 14696 0.0 0.0 1640 508 pts/3R+ 03:39 0:00 grep exim [EMAIL PROTECTED]:~# EX4DEBUG=1 /etc/init.d/exim4 stop now debugging /etc/init.d/exim4 stop + ENV=env -i LANG=C PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11 + QUEUERUNNER=combined + QUEUEINTERVAL=30m + UPEX4OPTS= + PIDFILE=/var/run/exim4/exim.pid + QRPIDFILE=/var/run/exim4/eximqr.pid + [ -f /etc/default/exim4 ] + . /etc/default/exim4 + EX4DEF_VERSION= + QUEUERUNNER=combined + QUEUEINTERVAL=30m + COMMONOPTIONS= + QUEUERUNNEROPTIONS= + QFLAGS= + SMTPLISTENEROPTIONS= + [ -f /etc/inetd.conf ] + grep -E -q ^[[:space:]]*((\*|[[:alnum:].-]+):)?smtp /etc/inetd.conf + DAEMON=/usr/sbin/exim4 + NAME=exim4 + test -x /usr/lib/exim4/exim4 + log_daemon_msg Stopping MTA + [ -z Stopping MTA ] + [ -z ] + echo -n Stopping MTA: Stopping MTA:+ return + stop_exim + [ -f /var/run/exim4/eximqr.pid ] + [ -f /var/run/exim4/exim.pid ] + start-stop-daemon --stop --pidfile /var/run/exim4/exim.pid --oknodo --retry 30 --exec /usr/sbin/exim4 + log_progress_msg exim4_listener + [ -z exim4_listener ] + echo -n exim4_listener exim4_listener+ rm -f /var/run/exim4/eximqr.pid /var/run/exim4/exim.pid + log_end_msg 0 + [ -z 0 ] + log_use_fancy_output + TPUT=/usr/bin/tput + EXPR=/usr/bin/expr + [ xxterm != xdumb ] + [ -x /usr/bin/tput ] + [ -x /usr/bin/expr ] + /usr/bin/tput hpa 60 + /usr/bin/tput setaf 1 + [ -z ] + FANCYTTY=1 + true + /usr/bin/tput setaf 1 + RED= + /usr/bin/tput op + NORMAL= + [ 0 -eq 0 ] + echo . . + return 0 + warn_paniclog + [ -s /var/log/exim4/paniclog ] + exit 0 [EMAIL PROTECTED]:~# ls -al /var/run/exim4 total 1 drwxr-x--- 2 Debian-exim Debian-exim 48 Nov 6 03:39 . drwxr-xr-x 22 rootroot1048 Nov 5 21:31 .. [EMAIL PROTECTED]:~# ps aux|grep exim [EMAIL PROTECTED]:~# tail /var/log/exim4/mainlog 2006-11-06 02:35:03 End queue run: pid=13075 2006-11-06 02:36:57 IPv6 socket creation failed: Address family not supported by protocol 2006-11-06 02:36:57 Failed to create IPv6 socket for wildcard listening (Address family not supported by protocol): will use IPv4 2006-11-06 02:36:57 exim 4.63 daemon started: pid=13135, -q30m, listening for SMTP on port 25 (IPv4) 2006-11-06 02:36:57 Start queue run: pid=13141 2006-11-06 02:36:57 End queue run: pid=13141 2006-11-06 03:06:57 Start queue run: pid=13922 2006-11-06 03:06:57 End queue run: pid=13922 2006-11-06 03:36:57 Start queue run: pid=14584 2006-11-06 03:36:57 End queue run: pid=14584 [EMAIL PROTECTED]:~# su -c cp /etc/exim4/exim4.conf.template /var/run/exim4 Debian-exim [EMAIL PROTECTED]:~# ls -al /var/run/exim4 total 5 drwxr-x--- 2 Debian-exim Debian-exim 72 Nov 6 02:36 . drwxr-xr-x 22 rootroot1048 Nov 5 21:31 .. -rw-r--r-- 1 rootDebian-exim6 Nov 6 02:36 exim.pid You cannot su to Debian-exim since Debian-exim has /bin/false as shell. Try adding -s /bin/bash to the su call and move the -c out of the quotes. [-s] duh :-/, thanks [EMAIL PROTECTED]:~# su -s /bin/bash -c cp /etc/exim4/exim4.conf.template /var/run/exim4 Debian-exim [EMAIL PROTECTED]:~# ls -al /var/run/exim4 total 73 drwxr-x--- 2 Debian-exim Debian-exim88 Nov 6 03:43 . drwxr-xr-x 22 rootroot 1048 Nov 5 21:31 .. -rw-r--r-- 1 Debian-exim Debian-exim 73147 Nov 6 03:43 exim4.conf.template - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: running exim4 not found
On Mon November 6 2006 04:32, Marc Haber wrote:
Now, kill all running exims manually,
Do you mean with killall (leaving a stale pidfile in /var/run/exim4),
or /etc/init.d/exim4 stop?
I have confirmed that rm-ing the pidfile and reinstalling exim4-daemon-light
results in a paniclog entry, which is what I saw with the last upgrade...
[EMAIL PROTECTED]:~# rm /var/run/exim4/exim.pid
[EMAIL PROTECTED]:~# apt-get --reinstall install exim4-daemon-light
Reading package lists... Done
Building dependency tree... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0B/411kB of archives.
After unpacking 0B of additional disk space will be used.
Do you want to continue [Y/n]?
Preconfiguring packages ...
(Reading database ... 350619 files and directories currently installed.)
Preparing to replace exim4-daemon-light 4.63-10 (using
.../exim4-daemon-light_4.63-10_i386.deb) ...
Stopping MTA:.
Unpacking replacement exim4-daemon-light ...
Setting up exim4-daemon-light (4.63-10) ...
Starting MTA: exim4.
[EMAIL PROTECTED]:~# tail -f /var/log/exim4/mainlog
2006-11-06 04:33:56 IPv6 socket creation failed: Address family not supported
by protocol
2006-11-06 04:33:57 Failed to create IPv6 socket for wildcard listening
(Address family not supported by protocol): will use IPv4
2006-11-06 04:33:57 socket bind() to port 25 for address (any IPv4) failed:
Address already in use: waiting 30s before trying again (9 more tries)
...
2006-11-06 04:38:27 socket bind() to port 25 for address (any IPv4) failed:
Address already in use: daemon abandoned
[EMAIL PROTECTED]:~# killall exim4
...leaving me with no daemon and no pidfile.
start one again, and then invoke start-stop-daemon --stop --pidfile
/var/run/exim4/exim.pid
--oknodo --retry 30 --exec /usr/sbin/exim4 and see whether the daemon
stops, and/or the pid file still exists.
An strace -f of that start-stop-daemon issue would be great as well.
[EMAIL PROTECTED]:~# /etc/init.d/exim4 start
Starting MTA: exim4.
[daemon running and pidfile exists]
[EMAIL PROTECTED]:~# strace -f start-stop-daemon --stop --pidfile
/var/run/exim4/exim.pid --oknodo --retry 30 --exec /usr/sbin/exim4
execve(/sbin/start-stop-daemon, [start-stop-daemon, --stop, --pidfile,
/var/run/exim4/exim.pid, --oknodo, --retry, 30, --exec,
/usr/sbin/exim4], [/* 11 vars */]) = 0
uname({sys=Linux, node=onegee, ...}) = 0
brk(0) = 0x804d000
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xa7fbe000
access(/etc/ld.so.preload, R_OK) = -1 ENOENT (No such file or directory)
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xa7fbd000
open(/etc/ld.so.cache, O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=99, ...}) = 0
mmap2(NULL, 99, PROT_READ, MAP_PRIVATE, 3, 0) = 0xa7fa1000
close(3)= 0
access(/etc/ld.so.nohwcap, F_OK) = -1 ENOENT (No such file or directory)
open(/lib/tls/i686/cmov/libc.so.6, O_RDONLY) = 3
read(3, \177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\240O\1..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0644, st_size=1241580, ...}) = 0
mmap2(NULL, 1247388, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) =
0xa7e7
mmap2(0xa7f97000, 28672, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x127) = 0xa7f97000
mmap2(0xa7f9e000, 10396, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xa7f9e000
close(3)= 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xa7e6f000
mprotect(0xa7f97000, 20480, PROT_READ) = 0
set_thread_area({entry_number:-1 - 6, base_addr:0xa7e6f6c0, limit:1048575,
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0,
useable:1}) = 0
munmap(0xa7fa1000, 99) = 0
brk(0) = 0x804d000
brk(0x806e000) = 0x806e000
stat64(/usr/sbin/exim4, {st_mode=S_IFREG|S_ISUID|0755, st_size=688128, ...})
= 0
open(/var/run/exim4/exim.pid, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xa7e4f000
read(3, 17741\n, 131072) = 6
readlink(/proc/17741/exe, /usr/sbin/exim4, 256) = 15
stat64(/usr/sbin/exim4, {st_mode=S_IFREG|S_ISUID|0755, st_size=688128, ...})
= 0
close(3)= 0
munmap(0xa7e4f000, 131072) = 0
kill(17741, SIGTERM)= 0
gettimeofday({1162813404, 24}, NULL) = 0
gettimeofday({1162813404, 247096}, NULL) = 0
open(/var/run/exim4/exim.pid, O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=6, ...}) = 0
mmap2(NULL, 131072, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xa7e4f000
read(3, 17741\n, 131072) = 6
Bug#396944: running exim4 not found
Hi, Here is what I saw during the last upgrade... /etc/passwd: Debian-exim:x:102:102::/var/spool/exim4:/bin/false [EMAIL PROTECTED]:~$ ps aux|grep exim 102 26817 0.0 0.1 5348 1000 ?Ss Nov04 0:00 /usr/sbin/exim4 -bd -q30m bsass 2312 0.0 0.0 1640 472 pts/5R+ 21:16 0:00 grep exim [dselect, apt access method] Preparing to replace exim4-config 4.63-9 (using .../exim4-config_4.63-10_all.deb) ... Unpacking replacement exim4-config ... Preparing to replace exim4-base 4.63-9 (using .../exim4-base_4.63-10_i386.deb) ... Unpacking replacement exim4-base ... Preparing to replace exim4-daemon-light 4.63-9 (using .../exim4-daemon-light_4.63-10_i386.deb) ... Stopping MTA:No /usr/sbin/exim4 found running; none killed. exim4_listener. Unpacking replacement exim4-daemon-light ... Preparing to replace exim4 4.63-9 (using .../archives/exim4_4.63-10_all.deb) ... Unpacking replacement exim4 ... ... Setting up exim4-config (4.63-10) ... Installing new version of config file /etc/exim4/conf.d/router/400_exim4-config_system_aliases ... Installing new version of config file /etc/exim4/conf.d/auth/30_exim4-config_examples ... Installing new version of config file /etc/exim4/exim4.conf.template ... ... Setting up exim4-base (4.63-10) ... Installing new version of config file /etc/cron.daily/exim4-base ... ... Setting up exim4-daemon-light (4.63-10) ... Starting MTA: exim4. [EMAIL PROTECTED]:~$ ps aux|grep exim 102 26817 0.0 0.1 5348 1000 ?Ss Nov04 0:00 /usr/sbin/exim4 -bd -q30m root 4999 0.0 0.1 5348 880 ?Ss 21:31 0:00 /usr/sbin/exim4 -bd -q30m bsass 6354 0.0 0.0 1636 508 pts/5R+ 21:35 0:00 grep exim [dselect, apt access method] Setting up exim4 (4.63-10) ... /var/log/exim4/mainlog: 2006-11-05 21:05:02 Start queue run: pid=2041 2006-11-05 21:05:02 End queue run: pid=2041 2006-11-05 21:31:21 IPv6 socket creation failed: Address family not supported by protocol 2006-11-05 21:31:21 Failed to create IPv6 socket for wildcard listening (Address family not supported by protocol): will use IPv4 2006-11-05 21:31:21 socket bind() to port 25 for address (any IPv4) failed: Address already in use: waiting 30s before trying again (9 more tries) ... 2006-11-05 21:34:51 socket bind() to port 25 for address (any IPv4) failed: Address already in use: waiting 30s before trying again (2 more tries) 2006-11-05 21:35:02 Start queue run: pid=6349 2006-11-05 21:35:02 End queue run: pid=6349 2006-11-05 21:35:21 socket bind() to port 25 for address (any IPv4) failed: Address already in use: waiting 30s before trying again (1 more try) 2006-11-05 21:35:51 socket bind() to port 25 for address (any IPv4) failed: Address already in use: daemon abandoned [EMAIL PROTECTED]:~$ ps aux|grep exim 102 26817 0.0 0.1 5348 1000 ?Ss Nov04 0:00 /usr/sbin/exim4 -bd -q30m # ls -l /var/run drwxr-x--- 2 Debian-exim Debian-exim 48 Nov 5 21:22 exim4 /var/run/exim4 started and finished empty, but I got distracted when both daemons were running and forgot to check. The exim4 process owned by user 102 was manually started via /etc/init.d/exim4 last night after a killall executed after the two reinstall failures mentioned previously. HTH - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: running exim4 not found
On Mon November 6 2006 00:21, Marc Haber wrote: On Sun, Nov 05, 2006 at 10:38:28PM -0700, Bruce Sass wrote: Stopping MTA:No /usr/sbin/exim4 found running; none killed. /etc/default/exim4 Strange. I'd like to see the contents of your /etc/default/exim4 and an ls -al /var/run/exim4. Additionally, please export EX4DEBUG=1 before doing the next update and capture the (copious) output. [EMAIL PROTECTED]:~$ cat /etc/default/exim4 # /etc/default/exim4 EX4DEF_VERSION='' # 'combined' - one daemon running queue and listening on SMTP port # 'no' - no daemon running the queue # 'separate' - two separate daemons # 'ppp' - only run queue with /etc/ppp/ip-up.d/exim4. # 'nodaemon' - no daemon is started at all. # 'queueonly' - only a queue running daemon is started, no SMTP listener. # setting this to 'no' will also disable queueruns from /etc/ppp/ip-up.d/exim4 QUEUERUNNER='combined' # how often should we run the queue QUEUEINTERVAL='30m' # options common to quez-runner and listening daemon COMMONOPTIONS='' # more options for the daemon/process running the queue (applies to the one # started in /etc/ppp/ip-up.d/exim4, too. QUEUERUNNEROPTIONS='' # special flags given to exim directly after the -q. See exim(8) QFLAGS='' # options for daemon listening on port 25 SMTPLISTENEROPTIONS='' [EMAIL PROTECTED]:~# ls -al /var/run/exim4 total 1 drwxr-x--- 2 Debian-exim Debian-exim 48 Nov 5 21:22 . drwxr-xr-x 22 rootroot1048 Nov 5 21:31 .. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: exim4-daemon-light: upgrading causes panic
On Sat November 4 2006 02:29, Marc Haber wrote: On Fri, Nov 03, 2006 at 01:06:01PM -0700, Bruce Sass wrote: ...would seem to indicate that it is a transitory situation caused by the upgrade process. Probably. Did killing the existing daemon manually help with starting the new daemon? I did not need to restart exim4. I saw the message in the INBOX associated with /var/mail/spool, then ran the ps|grep command you saw the output of. The mainlog just prior to the paniclog entry I included shows periodic Start and End queue run messages, 10 socket bind() failures at 30s intervals, then more Start/End queue runs. The result is daily... -e Subject: exim paniclog on onegee has non-zero size To: root exim paniclog /var/log/exim4/paniclog on onegee has non-zero size, mail system might be broken ...messages when there is no problem. Yes, you'll need to rotate the paniclog away manually. See /usr/share/doc/exim4-base/README.Debian.gz chapter 2.5.1 If the message is continuously being written again and again over and over, you have probably still an old daemon running. I understand that, but it doesn't seem right to have to do it after an upgrade if all is well... hence the report. Unfortunately I can not reliably reproduce this bug. Nine attempts at: #apt-get --reinstall install exim4-daemon-light got me two failures initially then seven successes. I have another box running the light daemon and one running the heavy daemon, neither of them have had a panic. :-/ - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: exim4-daemon-light: upgrading causes panic
On Sat November 4 2006 05:09, Marc Haber wrote: On Sat, Nov 04, 2006 at 04:40:01AM -0700, Bruce Sass wrote: On Sat November 4 2006 02:29, Marc Haber wrote: On Fri, Nov 03, 2006 at 01:06:01PM -0700, Bruce Sass wrote: ...would seem to indicate that it is a transitory situation caused by the upgrade process. Probably. Did killing the existing daemon manually help with starting the new daemon? I did not need to restart exim4. I saw the message in the INBOX associated with /var/mail/spool, then ran the ps|grep command you saw the output of. Anyway, you had an extra daemon running which interfered with your update. I don't think that was the case, and know it wasn't when I had the two failures out of nine reinstalls mentioned in the last message. The mainlog just prior to the paniclog entry I included shows periodic Start and End queue run messages, 10 socket bind() failures at 30s intervals, then more Start/End queue runs. Yes, that's exim4's default behavior if it cannot bind to any configured smtp listening port. Ya. I only mentioned it so you would know I've looked at the logs and didn't see anything unusual. The result is daily... -e Subject: exim paniclog on onegee has non-zero size To: root exim paniclog /var/log/exim4/paniclog on onegee has non-zero size, mail system might be broken ...messages when there is no problem. Yes, you'll need to rotate the paniclog away manually. See /usr/share/doc/exim4-base/README.Debian.gz chapter 2.5.1 If the message is continuously being written again and again over and over, you have probably still an old daemon running. I understand that, but it doesn't seem right to have to do it after an upgrade if all is well... hence the report. Yes. I am desparately trying to find out what went wrong on your system as the issue is not reproducible here and no other users are reporting this. The only possibility I can think of is the daemon not actually stopping during the upgrade. Feel free to ask me to muck about with it if you have ideas. Unfortunately I can not reliably reproduce this bug. Nine attempts at: #apt-get --reinstall install exim4-daemon-light got me two failures initially then seven successes. I have another box running the light daemon and one running the heavy daemon, neither of them have had a panic. :-/ I am afraid that then there is nothing to do except tagging this bug unreproducible and closing it by the end of November. Sounds reasonable. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#397073: konsole: not reading ~/.bashrc
Package: konsole Version: 4:3.5.5a.dfsg.1-1 Severity: important When starting session programs ~/.bashrc is not being read, which results in some programs not operating as configured. For example... My ~/.bashrc contains: eval `lesspipe` export GIT_PAGER=less which tells gitfm to use less as its pager and less to automatically uncompress files for viewing. However, because .bashrc is not read the ^xv key command results in a may be a binary file. See it anyway? message and forces me to type (and often escape) a zless ... command. This is a minor annoyance with short filenames, but with long names it requires cutting back to one pane to see the entire name, and with very long names it requires that plus widening the Konsole window to full width and greatly reducing the font size before the entire name is visible for cut'n'pasting onto the command line... effectively rendering GIT's ^xv command useless. This is a regression from the v3.4.x behaviour (afaict), and I think it is important because it can have a major affect on the useability of programs run in Konsole. - Bruce -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-onegee Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages konsole depends on: ii kdelibs4c2a4:3.5.5a.dfsg.1-3 core libraries and binaries for al ii libc6 2.3.6.ds1-7 GNU C Library: Shared libraries ii libgcc11:4.1.1-19GCC support library ii libstdc++6 4.1.1-19 The GNU Standard C++ Library v3 ii libxrender11:0.9.1-3 X Rendering Extension client libra ii libxtst6 1:1.0.1-5 X11 Testing -- Resource extension konsole recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396944: exim4-daemon-light: upgrading causes panic
Package: exim4-daemon-light Version: 4.63-9 Severity: normal The last couple of upgrades have resulted in the following being sent to the paniclog... 2006-11-03 02:05:38 socket bind() to port 25 for address (any IPv4) failed: Address alre ady in use: daemon abandoned ...about the time an upgrade was in progress, yet... [EMAIL PROTECTED]:~$ ps aux | grep exim 102 9302 0.0 0.1 5352 1000 ?Ss Oct28 0:00 /usr/sbin/exim4 -bd -q30m ...would seem to indicate that it is a transitory situation caused by the upgrade process. The result is daily... -e Subject: exim paniclog on onegee has non-zero size To: root exim paniclog /var/log/exim4/paniclog on onegee has non-zero size, mail system might be broken ...messages when there is no problem. Disabling paniclog monitoring is not a reasonable option because I want to be advised if there is a problem, and using a regexp to filter out the noisy message could result in valid problems being missed. - Bruce -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-onegee Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages exim4-daemon-light depends on: ii debconf [debconf-2.0]1.5.8 Debian configuration management sy ii exim4-base 4.63-9 support files for all exim MTA (v4 ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libdb4.3 4.3.29-6Berkeley v4.3 Database Libraries [ ii libgnutls13 1.4.4-2 the GNU TLS library - runtime libr ii libpcre3 6.7-1 Perl 5 Compatible Regular Expressi exim4-daemon-light recommends no packages. -- debconf information: exim4-daemon-light/drec: -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396794: git: ^Xh help documentation broken
Package: git Version: 4.3.20-10 Severity: normal Tags: patch /usr/share/git/.gitrc.common contains: ^Xh = HTML; $GIT_BROWSER /usr/doc/git-4.3.20/git.html;;n should be: ^Xh = HTML; $GIT_BROWSER /usr/share/doc/git/git.html;;n -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-onegee Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages git depends on: ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libncurses5 5.5-5 Shared libraries for terminal hand ii libreadline5 5.2-1 GNU readline and history libraries git recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#396797: git: supports RPM but not DPKG
Package: git Version: 4.3.20-10 Severity: wishlist Tags: patch GIT ships with key command support for RPM based systems but does not include commands supporting common dpkg operations. To remedy this I suggest adding at least the following to the [GITFM-Keys] section of /usr/share/git/.gitrc.common: ^C^Di = DPKG-INSTALL; dpkg -i %i;;;y ^C^Dl = DPKG-LISTPKGS; dpkg -l %i;;;y ^C^Dp = DPKG-PRINTAVAIL; dpkg -p %i;;;y ^C^Dr = DPKG-REMOVE; dpkg -r %i;;;y ^C^Ds = DPKG-STATUS; dpkg -s %i;;;y ^C^DL = DPKG-LISTFILES; dpkg -L %i;;;y ^C^DP = DPKG-PURGE; dpkg -P %i;;;y ^C^DS = DPKG-SEARCH; dpkg -S %p/%i;;;y I will follow up with appropriate html and info documentation for this, and any other Debian specific commands you come up with, in a seperate report. - Bruce -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-onegee Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages git depends on: ii libc62.3.6.ds1-7 GNU C Library: Shared libraries ii libncurses5 5.5-5 Shared libraries for terminal hand ii libreadline5 5.2-1 GNU readline and history libraries git recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#392570: dselect hard locks the kernel when scrolling thru package names
-- Forwarded Message -- Date: Fri October 20 2006 04:59 From: Lindsay Washusen [EMAIL PROTECTED] To: [EMAIL PROTECTED] On Tue, 17 Oct 2006 17:49:38 Bruce Sass [EMAIL PROTECTED] wrote: tags 392570 moreinfo thanks I think it more likely the /var/lib/dpkg/status or /var/lib/dpkg/available files contain garbage. Could you please check those files (using more, less, or a text editor) along with can not see any problems with these files ... If the DVD archive and dpkg DB files are OK then try strace -o dselect.trace dselect and send the output to [EMAIL PROTECTED] so we can see where dselect is going bad. Much good idea I will give this a try directly,as I am some what intrigued bye this. I will say I had thought of this but had not done it because from memory this produced a HUGE file and slowed done the system somthing chronic. I will get the src for dselect and have a study to try and see how it works when going through the list. Note: the problem occurs with 2 versions of the available file one generated directly from the DVD's and on from converting the the DVD's to a hardidsk based store. The thing that most concerns me is why the corruption or whatever it is causes the system to lockup. Many thanks for the response and suggestions I will give some things a try and get back. Lindsay PS. Just tried to run dselect in a user account to see if the kernels protection mechanism could catch any memory violations. Going through the list as previous works OK HM. Nothing writen to consol or logs. --- -- Forwarded Message -- From: Lindsay Washusen [EMAIL PROTECTED] To: [EMAIL PROTECTED] On Date: Fri, 20 Oct 2006 16:08:59 Bruce Sass [EMAIL PROTECTED] wrote: ... Do I have your permission to forward this private message to the public BTS if necessary? Yes If it turn out to not be reproducible and no similar reports are received from other users then this bug will be tagged unreproducible and closed about a month after Etch is released. ... BTW thanks for the insite into the workings of debian bug track. Lindsay the correct email address is [EMAIL PROTECTED] [EMAIL PROTECTED] is no longer accsessed. --- - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#388084: dselect freezes upon pressing CTRL+S
On Wed October 18 2006 23:27, Christian Perrier wrote: Quoting Guillem Jover ([EMAIL PROTECTED]): No, this is a setting configurable in the terminal, with termios would be just a matter of disabling IXON. So this bug can be fixed, the question is if it should be fixed. As I don't use dselect I don't have a strong opinion over it, although I think the bug closure was precipitated... Well, I'm OK to reopen if you think it's better. Disabling Scroll Lock is a bad idea because some messages are only seen when they are likely to scroll off the screen. E.g. Bug#21758, so unless you watch the long list of filenames which scroll up the screen at a reasonable rate, you don't know that these packages are not on the system. Consider also that dselect should be usable on a default terminal which often has only 25 lines, exacerbating the scroll-off problem. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#21659: dselect doesn't show descriptions for obsolete packages
reopen 21659
severity 21659 wishlist
tags 21659 patch
thanks
Hi,
sorry for the delay
Bernd wrote:
On Fri, Sep 15, 2006 at 12:48:51PM -0700, Debian Bug Tracking System
wrote:
dselect only shows installed control info for obsolete packages,
and given that this report has been ignored for 8+ years it is safe
to say that is the intended behaviour.
It does not show that info by default, and it does not show it in the
description column.
If i am on a local/obsolote package it prints package - no
description available. Which it is clearly wrong, since pressing i
will show me the description. So it should be for your inconvinience
we do not show the description you would expect here until you press
i. Fine with me :)
:-)
Sorry I dont understand the technical issues which arise from showing
that info, I am just a user who would expect that info and find it
helpfull (if I would actually use dselect).
dselect is coded to only show descriptions for *available* packages,
that is the intended behaviour I mentioned and what appears unlikely
to change given the length of time the report has languished in the
BTS.
I could only guess at why it was decided that descriptions should only
be shown for Available packages, so I'll refrain from doing so, but it
does serve to draw attention to the Obsolete ones (which is generally a
good thing, imo.)
Technically, from pkginfo.cc:
void packagelist::itd_description() {
if (table[cursorline]-pkg-name) {
whatinfovb(_(description of ));
whatinfovb(table[cursorline]-pkg-name);
const char *m= table[cursorline]-pkg-available.description;
if (!m || !*m) m= _(no description available.);
const char *p= strchr(m,'\n');
...
Getting dselect to always show a Description would require an additional
test and attempt to set m, afaict, something like:
const char *m= table[cursorline]-pkg-available.description;
if (!m || !*m) m= table[cursorline]-pkg-installed.description;
if (!m || !*m) m= _(no description available.);
Which doesn't seem too difficult, unreasonable, or likely to introduce
bugs... reopening as a wishlist item and tagging with patch, just
because I may have been a bit overzealous with this one.
- Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#9085: String freeze for dselect
On Wed October 4 2006 23:17, Christian Perrier wrote:
Considering the very recent discussions in the maling list, I hereby
consider that translatable strings are now frozen in dpkg.
That means that I urge you fellow developers to please coordinate
with me in case you plan to introduce changes which change a
translatable string IN ANY WAY.
I will post a final call for translation updates and I'll open a
special bug report for that to avoid multiple bug reports, one per
language.
I will also send a call for updates for dselect in case some crazy
dudes absolutely insist to be 100% for that old piece noone really
cares about:-)
I believe the attached diff can be used to close a long standing dselect
bug... because some of us do still care. ;-)
The more verbose descriptions (made possible by removing the redundant
pkg-name) and capitalization of Available and Installed should
result in less confusing status lines.
- Bruce
--- pkginfo.cc 2006-01-18 01:30:03.0 -0700
+++ pkginfo-bms.cc 2006-10-05 14:27:22.0 -0600
@@ -129,10 +129,9 @@
void packagelist::itd_statuscontrol() {
werase(infopad);
if (!table[cursorline]-pkg-name) {
-severalinfoblurb(_(currently installed control info));
+severalinfoblurb(_(control file information for Installed package));
} else {
-whatinfovb(_(installed control info for ));
-whatinfovb(table[cursorline]-pkg-name);
+whatinfovb(_(Installed control file information));
varbuf vb;
varbufrecord(vb,table[cursorline]-pkg,table[cursorline]-pkg-installed);
vb.terminate();
@@ -145,10 +144,9 @@
void packagelist::itd_availablecontrol() {
werase(infopad);
if (!table[cursorline]-pkg-name) {
-severalinfoblurb(_(available version of control file info));
+severalinfoblurb(_(control file information for Available package));
} else {
-whatinfovb(_(available version of control info for ));
-whatinfovb(table[cursorline]-pkg-name);
+whatinfovb(_(Available control file information));
varbuf vb;
varbufrecord(vb,table[cursorline]-pkg,table[cursorline]-pkg-available);
vb.terminate();
Bug#390737: reprepro: mangled --export=force paragraph in man page
Package: reprepro Version: 1.2.0-1 Severity: minor The man page says: --export=force P, but exporting also happens for distributions where some Like normal ^^ error occurred. should probably be: --export=force Like normal, but exporting also happens for distributions where some error occurred. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-onegee Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#390734: reprepro: weather vs. whether
Package: reprepro Version: 1.2.0-1 Severity: minor The man page says: --export=(never|changed|normal|force) This option specify weather and how should be: This option specifies whether and how ^^ -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-onegee Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#130798: obsolete bug
It appears that this bug got fixed at some point and the report didn't
get closed. The problem was that dselect would loop forever when it
received an EOF after spitting out an error message. By inspection,
the current code should not suffer from this problem, compare...
original code:
if (ferror(stderr))
ohshite(_(write error on standard error));
do { c= fgetc(stdin); } while ((c == ERR errno==EINTR) || (c != '\n'));
if (c == ERR)
ohshite(_(error reading acknowledgement of program failure message));
...to...
current code:
if (ferror(stderr))
ohshite(_(write error on standard error));
do { c= fgetc(stdin); } while ((c == ERR errno==EINTR) || ((c != '\n')
c != EOF));
if ((c == ERR) || (c == EOF))
ohshite(_(error reading acknowledgement of program failure message));
...clearly, an EOF is now caught and handled.
Since I could not find this construct in any other dselect code, I'll
close this bug in a week if no one shows just how wrong I am.
- Bruce
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#353116: why is this an important dselect bug?
Hi, I can see why #351406 was cloned to dselect... Date: Thu, 16 Feb 2006 10:53:46 +0100 From: Loïc Minier [EMAIL PROTECTED] To: Gary Koskenmaki [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: Rhythmbox: No volume slider, does not play radio stations or library music Message-ID: [EMAIL PROTECTED] ... This was a missing installation of gstreamer0.10-alsa, which is presumably a synaptic + apt-get problem, and a dselect problem on installs and upgrades. ... ...but a little later on... Date: Tue, 28 Feb 2006 16:24:51 +0100 From: Loïc Minier [EMAIL PROTECTED] To: Filipus Klutiero [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Shouldn't make Recommends useless Message-ID: [EMAIL PROTECTED] ... (BTW, dselect does install Recommends by default.) ... ...and #353115 has been downgraded to wishlist. Even if this issue crops up with dselect+apt-method[1], it is an APT problem and can be worked around in dselect simply by using a different access method. I think this bug should be closed. - Bruce [1] I may have seen it twice in all the time dselect has supported the APT access method, but both times I was aiming for a broken installation (just wanted part of a suite) and didn't feel like wget + dpkg -i.
Bug#21400: this bug is obsolete
[runs dselect, chooses access method - disk, no Distribution top level] --- Enter _main_ binary dir. [] ? /var/cache/apt-build/repository Using `/var/cache/apt-build/repository' as main binary dir. Using `/var/cache/apt-build/repository/Packages.gz' for main. --- I am using Unstable (1.13.22), but the exact same code exists in Stable (1.10.28). See: src/dpkg-1.10.28/methods/disk.setup and src/dpkg-1.13.22/dselect/methods/disk. It looks like this 8+ year old bug was fixed without trying at some point and should be closed. - Bruce -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383383: /usr/share/menu/apollon broken
Package: apollon
Version: 1.0.1-3
Severity: normal
Tags: patch
[EMAIL PROTECTED]:~# update-menus
...
In file /usr/share/menu/apollon, at (or in the definition that ends at) line
1:
[...]sharing daemon giFT command=/usr/bin/apollon
icon=icon=/usr/share/pixma
ps/apollon.xpm needs=package(apollon):needs=X11 package=apollon
section=section
=Apps/Net title=longtitle=Graphical
[...] ^
Expected: =
install-menu: /etc/menu-methods/twm: aborting
update-menus[6654]: Script /etc/menu-methods/twm returned error status 1.
In file /usr/share/menu/apollon, at (or in the definition that ends at) line
1:
[...]sharing daemon giFT command=/usr/bin/apollon
icon=icon=/usr/share/pixma
ps/apollon.xpm needs=package(apollon):needs=X11 package=apollon
section=section
=Apps/Net title=longtitle=Graphical
[...] ^
Expected: =
install-menu: /etc/menu-methods/uwm: aborting
...for every menu-method...
[EMAIL PROTECTED]:~$ diff -u /usr/share/menu/apollon{-orig,}
--- /usr/share/menu/apollon-orig2006-08-16 15:17:58.0 -0600
+++ /usr/share/menu/apollon 2006-08-16 15:25:11.0 -0600
@@ -1,4 +1,4 @@
-package(apollon):needs=X11 section=Apps/Net \
+?package(apollon):needs=X11 section=Apps/Net \
title=Apollon \
icon=/usr/share/pixmaps/apollon.xpm \
longtitle=Graphical interface to the file-sharing daemon giFT \
Just a missing ?
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.17-onegee
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#383412: kappfinder: LyX provides its own .desktop files
Package: kappfinder Version: 4:3.5.4-2 Severity: wishlist The lyx-qt and lyx-xforms packages include .desktop files in /usr/share/applications (shows up in K-Office), making /usr/share/apps/kappfinder/apps/Office/lyx.desktop unnecessary and maybe confusing (most likely to execute lyx-qt, could execute lyx-xforms, but does /usr/local/bin/lyx for me.) I think the lyx.desktop file should be removed from Debian's kappfinder package. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/dash Kernel: Linux 2.6.17-onegee Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages kappfinder depends on: ii kdelibs4c2a 4:3.5.4-3 core libraries and binaries for al ii libc6 2.3.6-19 GNU C Library: Shared libraries ii libgcc1 1:4.1.1-10 GCC support library ii libqt3-mt 3:3.3.6-3 Qt GUI Library (Threaded runtime v ii libstdc++64.1.1-10 The GNU Standard C++ Library v3 kappfinder recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
