When you recieve a talk request through 'ktalkd' the default handler invoked is "/usr/kde/3.5/bin/konsole -e talk". This can be altererd in 'kcontrol' but the problem remains that without a 'talk' program installed the 'konsole' opens and fails with an ugly error like "cannot write to PTY" and such (not helpful); this is annoying when someone is trying to get in touch with you. This problem is fixed if you simply install net-misc/netkit-talk to get the talk program. Alternatively. I personally perfer ytalk as a client since it is more up-to-date and functional. In order for ytalk (in place of talk) to work with the default ktalkd configuration we need to create a talk script: Create /usr/bin/talk containing: #!/bin/sh ytalk -x ${*} That's it. Allows ytalk to be a drop-in replacement for talk with the ktalkd daemon without any need to change default kde setup. In this day of X, I consider the combination of kde-base/ktalkd and net-misc/ytalk to be preferable to the old net-misc/netkit-talk system. ---------------------------------------------------------------------------- Portage 2.1.1-r2 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r4, 2.6.18-gentoo-r3 i686) ================================================================= System uname: 2.6.18-gentoo-r3 i686 AMD Athlon(tm) XP 2000+ Gentoo Base System version 1.12.6 Last Sync: Mon, 11 Dec 2006 04:30:01 +0000 app-admin/eselect-compiler: [Not Present] dev-java/java-config: 1.3.7, 2.0.30 dev-lang/python: 2.4.3-r4 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.60 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2 sys-devel/binutils: 2.16.1-r3 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.17-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="en_US" LC_ALL="en_US" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude='/distfiles' --exclude='/local' --exclude='/packages'" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY=" " SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X a52 aac afs alsa apache2 apm berkdb bitmap-fonts bzip2 cairo cdr cli cracklib crypt cups dbus directfb dlloader dri dvd dvdr dvdread eds elibc_glibc emacs emboss encode fam ffmpeg firefox flac fortran gdbm gif gnome gpm gstreamer gtk hal iconv input_devices_joystick input_devices_keyboard input_devices_mouse isdnlog java joystick jpeg kde kerberos kernel_linux krb4 ldap libg++ mad mikmod mono mp3 mpeg mysql ncurses nls nptl nptlonly nsplugin offensive ogg opengl oss pam pcre pdf perl png ppds pppd python qt3 qt4 quicktime readline reflection samba sasl sdl session slp spell spl sqlite ssl svg tcpd theora threads tiff truetype truetype-fonts type1-fonts udev unicode usb userland_GNU video_cards_nv video_cards_nvidia video_cards_vesa vorbis win32codecs xine xinetd xml xorg xv xvid zlib" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
Seemant, would you take into account installing such a wrapper script with ytalk and block ytalk and netkit-talk mutually?
sure I'll look into it
Hm, looking at it netkit-talk comes with a daemon ytalk doesn't, so placing a compatibility script for ytalk leading to a mutual blocker doesn't seem sensible. Sorry for the noise, Seemant.
OR dependencies and post install message are in place since a while, that should suffice.
