1) Upgraded to new libutempter package whardin@freeman ~ $ equery list utemp [ Searching for package 'utemp' in all categories among: ] * installed packages [I--] [ ] sys-libs/libutempter-1.1.2.1 (0) whardin@freeman ~ $ slocate *utempter.so /usr/lib/libutempter.so.0 /usr/lib/libutempter.so /usr/lib/libutempter.so.1.1.2 2) Login (via Entrance) to KDE whardin@freeman ~ $ ps -ef |grep kded whardin 24892 1 0 15:11 ? 00:00:01 kded [kdeinit] --new-startup whardin 27886 25158 0 15:23 pts/15 00:00:00 grep kded 3) UTMP information does not get recorded whardin@freeman ~ $ w 15:25:29 up 6 days, 3:55, 2 users, load average: 2.23, 1.57, 1.33 USER TTY LOGIN@ IDLE JCPU PCPU WHAT whardin tty1 11:57 3:06m 0.02s 0.02s -bash whardin@freeman ~ $ who whardin tty1 Jun 6 11:57 4) In the past (or when using sys-apps/utempter package), another line would appear in 'w' with me logged in on pts/0 and the what was "kded [kdeinit] --new-startup" Troubleshooting so far: 1) re-emerged kdelibs numerous times (this is the package that contains kded and kdeinit) 2) "emerge -e world" (For GCC 4.1.1 upgrade) 3) replaced sys-libs/libutempter with older sys-apps/utempter package (to confirm issue with libutempter. KDE works as expected with utempter) 4) revdep-rebuild finds no breakage freeman ~ # revdep-rebuild --pretend --library "/usr/lib/libutempter.so*" Configuring search environment for revdep-rebuild Checking reverse dependencies... Packages containing binaries and libraries using /usr/lib/libutempter.so* will be emerged. Collecting system binaries and libraries... done. (/root/.revdep-rebuild.1_files) Checking dynamic linking... done. (/root/.revdep-rebuild_a5f9d8e2.3_rebuild) Assigning files to ebuilds... Nothing to rebuild Evaluating package order... done. (/root/.revdep-rebuild_a5f9d8e2.5_order) There are no dynamic links to /usr/lib/libutempter.so*... All done. whardin@freeman ~ $ emerge --info Portage 2.1_rc4-r3 (default-linux/x86, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.16-ck11 i686) ================================================================= System uname: 2.6.16-ck11 i686 Intel(R) Pentium(R) 4 CPU 3.00GHz Gentoo Base System version 1.12.1 dev-lang/python: 2.3.5-r2, 2.4.3-r1 dev-python/pycrypto: 2.0.1-r5 dev-util/ccache: [Not Present] dev-util/confcache: [Not Present] sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.59-r7 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-r2 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -pipe -fomit-frame-pointer -march=pentium4" 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/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config" CONFIG_PROTECT_MASK="/etc/eselect/compiler /etc/gconf /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -pipe -fomit-frame-pointer -march=pentium4" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox" GENTOO_MIRRORS="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ ftp://gentoo.chem.wisc.edu/gentoo/ ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo" 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="/opt/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage/" USE="X Xaw3d a52 aac aalib acl acpi aim alsa apache2 audiofile avahi avi bash-completion berkdb bitmap-fonts bluetooth bzip2 cairo caps cddb cdparanoia cdr cgi clamav cli cracklib crypt cups curl dar32 dar64 dba dbm dbus dga directfb divx4linux doc dri dts dv dvd dvdr dvdread encode ethereal expat fam fbcon ffmpeg firefox flac fltk foomaticdb ftp gd gdbm ggi gif gpm graphviz gstreamer gtk gtk2 gtkhtml hal imagemagick imap imlib innodb isdnlog jabber jack java javascript jikes jpeg jpeg2k kde kdeenablefinal kdehiddenvisibility kerberos ldap lesstif libcaca libg++ libwww live lm_sensors logitech-mouse logrotate lzo mad maildir mailwrapper matroska mbox mikmod mime ming mmap mmx mmxext mng modplug mono motif mozdevelop mozilla moznocompose moznoirc mozsvg mp3 mpeg mplayer msn musicbrainz mysql ncurses network nis nptl nsplugin odbc offensive ogg oggvorbis openal openexr opengl oscar pam pcre pda pdflib perl php png posix povray ppds pppd python qt quicktime readline real reflection ruby samba sdl sharedext sharedmem slang slp sndfile snmp spell srvdir sse sse2 ssl svg svga sysfs syslog sysvipc tcltk tetex theora threads tidy tiff truetype truetype-fonts type1-fonts udev unicode usb v4l v4l2 vcd verbose vhosts videos vidix visualization vorbis wifi win32codecs wmf wxwindows x86 xcomposite xine xinerama xinetd xml xml2 xmlrpc xmms xorg xosd xpm xscreensaver xsl xv xvid xvmc yahoo zeroconf zlib elibc_glibc input_devices_keyboard input_devices_mouse input_devices_evdev kernel_linux userland_GNU video_cards_fglrx video_cards_vesa video_cards_fbdev video_cards_ati video_cards_radeon" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTAGE_RSYNC_EXTRA_OPTS
the code in kdelibs relies on the /usr/sbin/utempter binary (in http://websvn.kde.org/branches/KDE/3.5/kdelibs/kdecore/kpty.cpp?view=markup) even if configure checks for the library. So probably the virtual/utempter dependency is not exact.
*kdelibs-3.5.3-r1 (09 Jun 2006) 09 Jun 2006; Diego Petten
*kdelibs-3.5.3-r1 (09 Jun 2006) 09 Jun 2006; Diego Pettenò <flameeyes@gentoo.org> +kdelibs-3.5.3-r1.ebuild: Add new revision of kdelibs without utempter dependency, disabling utempter entirely as kdelibs has its own better code to handle that. I will upgrade and re-test. This may fix the issue.
I forgot to update when using -r1, but I'm running -r2 right now and it still doesn't work. With the libutempter dependency removed from kdelibs, I'm tempted to go back to the utempter package. I notice the x11-term/xterm-215 package now requires libutempter though. Should xterm be made to depend on virtual/utempter or are we still trying to fix kdelibs to work with libutempter?
Created attachment 92189 [details, diff] kdelibs-3.5.3-libutempter.patch Patch to kdelibs to use libutempter. I also submitted this upstream.
Created attachment 92190 [details] kdelibs-3.5.3-r4.ebuild Ebuild that uses my patch, based on kdelibs-3.5.3-r3. I explicitly depend on libutempter now, not virtual/utempter. As using utempter has some security implications, I made utempter an USE flag, in accordance with the rfe bug 109395. To make things work out of the box for the average user, you might want to add this to the profile. Or should the utempter use flag be reversed and named noutempter? Or is the preferred default to not use utempter?
As configure checks for a library, I assumed that it would depend on libutempter. But I just checked that utempter-0.5.5.6 installs a libutempter.so as well, providing just the "old interface". Therefore my patch should work for this setup as well. The dependency in comment 5 could therefore be changed back to virtual/utempter.
tested the -r4 ebuild and libutempter patch and it works for me (~x86) As for the USE flag issue, I think its generally a good idea to at least have the initial login to KDE recorded, so as a user I lean to having utempter support on by default in kdelibs. Its been included by default into the Kdelibs in the past and the complaint in bug 109395 seems to focus on the utmp spam from Konsole, which I agree with disabling by default, if possible, but that is outside the scope of this bug.
*** Bug 143324 has been marked as a duplicate of this bug. ***
Thanks for the patch Martin. Fixed with kdelibs-3.5.4-r1.
*** Bug 140977 has been marked as a duplicate of this bug. ***
Created attachment 100909 [details, diff] kdelibs-3.5.5-libutempter.patch This is attachment #92189 [details, diff] from comment #4 again for kdelibs-3.5.5.
kdelibs-3.5.5 is without this patch. Please reopen this bug until the patch is included again in a future revision.
I can confirm that the bug needs to be reopened, kdelibs 3.5.5 doesn't record utmp info even with utempter use flag active
*** Bug 156774 has been marked as a duplicate of this bug. ***
Reopen... (In reply to comment #4) > Patch to kdelibs to use libutempter. I also submitted this upstream. A link to the bug would be useful.
(In reply to comment #15) > Reopen... > > (In reply to comment #4) > > Patch to kdelibs to use libutempter. I also submitted this upstream. > > A link to the bug would be useful. > I believe that would be http://bugs.kde.org/show_bug.cgi?id=112840
(In reply to comment #16) > I believe that would be http://bugs.kde.org/show_bug.cgi?id=112840 That's the one. Sorry, I stated the URL in the preamble of the 3.5.3 patch. Not the most obvious place too look for it.
Hi! Any news regarding this? kde-base/kdelibs-3.5.6-r2 with USE utempter still don't broadcast wall. Thanks.
Created attachment 110456 [details, diff] kdelibs-3.5.6-libutempter.patch I was informed of a more matching upstream bug; maybe it should become the URL of this bug here: http://bugs.kde.org/show_bug.cgi?id=140308 You can vote for this bug. :-) I'm confident that my patch does the right thing, so I see no problem applying it to current Gentoo ebuilds. Here is a version for kdelibs-3.5.6.
Works for me! (attachment#110456 [details, diff])
Still not included in latest 3.5.6-r5 ebuild. So yet again I have to copy the ebuild to my overlay to get this included. :( It would be really nice to get this patch included again in the portage tree.
Seemant: Any reason why you didn't push the bug back to the KDE team? No idea, why it was reassigned in the first place...
(In reply to comment #22) > Still not included in latest 3.5.6-r5 ebuild. I'm running kdelibs-3.5.6-r5 and utmp works for me. I was under the impression this was fixed upstream. I have rebuilt my system since first reporting this and now use KDM instead of Entrance as my login manager, but that's the only difference in the login chain I can think of. whardin@freeman ~ $ w 12:03:06 up 14 days, 22:13, 4 users, load average: 0.64, 0.57, 0.52 USER TTY LOGIN@ IDLE JCPU PCPU WHAT whardin :0 10Apr07 ?xdm? 3:59m 0.03s /bin/sh /usr/kde/3.5/bin/startkde whardin@freeman ~ $ equery list kdelibs [ Searching for package 'kdelibs' in all categories among: ] * installed packages [I--] [ ] kde-base/kdelibs-3.5.6-r5 (3.5) whardin@freeman ~ $ equery list libutempter [ Searching for package 'libutempter' in all categories among: ] * installed packages [I--] [ ] sys-libs/libutempter-1.1.5 (0) whardin@freeman ~ $ equery list kdm [ Searching for package 'kdm' in all categories among: ] * installed packages [I--] [ ] kde-base/kdm-3.5.6 (3.5) The configure command used when compiling kdelibs: (notice --with-utempter) ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --with-distribution=Gentoo --disable-fast-malloc --enable-libfam --enable-dnotify --with-libart --with-libidn --with-acl --with-ssl --with-alsa --without-arts --with-gssapi --with-tiff --with-jasper --with-openexr --enable-cups --with-utempter --without-lua --enable-sendfile --enable-mitshm --with-aspell --disable-dnssd --without-hspell --with-rgbfile=/usr/share/X11/rgb.txt --with-x --enable-mitshm --with-xinerama --with-qt-dir=/usr/qt/3 --enable-mt --with-qt-libraries=/usr/qt/3/lib --disable-dependency-tracking --disable-debug --without-debug --enable-final --without-arts --enable-gcc-hidden-visibility --prefix=/usr/kde/3.5 --mandir=/usr/kde/3.5/share/man --infodir=/usr/kde/3.5/share/info --datadir=/usr/kde/3.5/share --sysconfdir=/usr/kde/3.5/etc --build=i686-pc-linux-gnu And from the configure output... checking for addToUtmp in -lutempter... yes So kdelibs seems to be happy with the libutempter implementation.
(In reply to comment #24) > (In reply to comment #22) > > Still not included in latest 3.5.6-r5 ebuild. > > I'm running kdelibs-3.5.6-r5 and utmp works for me. I was under the impression > this was fixed upstream. I have rebuilt my system since first reporting this > and now use KDM instead of Entrance as my login manager, but that's the only > difference in the login chain I can think of. > > whardin@freeman ~ $ w > 12:03:06 up 14 days, 22:13, 4 users, load average: 0.64, 0.57, 0.52 > USER TTY LOGIN@ IDLE JCPU PCPU WHAT > whardin :0 10Apr07 ?xdm? 3:59m 0.03s /bin/sh > /usr/kde/3.5/bin/startkde It's not working: I suppose you are launching w from a konsole window. There should be a second line in the w output with something like whardin pts/0 date ecc. ecc. bash but there is not, because konsole still doesn't write utmp info. Try to launch w from a plain xterm, you should see the difference. The line you get is from kdm/startkde and is not related to this bug.
(In reply to comment #25) > It's not working: I suppose you are launching w from a konsole window. There > should be a second line in the w output with something like > whardin pts/0 date ecc. ecc. bash > but there is not, because konsole still doesn't write utmp info. > Try to launch w from a plain xterm, you should see the difference. > The line you get is from kdm/startkde and is not related to this bug. For starters, since I am the originator of the bug, I think I have a pretty good idea what it's about. It has nothing to do with Konsole, because I don't use Konsole, I use rxvt. And rxvt does not record any UTMP info, which is the behavior I want. I don't need a record of every terminal window I open. The original report was about when logging into KDE (via Entrance), no record was added to UTMP. So after logging in and opening an rxvt window, doing a 'w' returned nothing. And that was my problem. The only mention of Konsole in this bug report was made by me in referencing another bug. Perhaps using KDM is what 'fixed' this for me, I don't know, although I seem to remember testing various GUI login managers after initially reporting the bug to see if that had any effect, with no luck. I haven't seen anyone else say what GUI login manager they're using. I really don't think the login manager has much effect because, originally, the combination of entrance-utempter-kde did work while entrance-libutempter-kde did not. These days, KDM-libutempter-kde does work. At least for me.
(In reply to comment #26) > These days, KDM-libutempter-kde does work. At least for me. What does "work" mean? You are referring to the output from w, but to me and some others it is most important to receive wall messages via kwrited. Have you checked this? I always assumed the two to be connected, but I'm not sure anymore. I'm surprised it works for you. The problem was there in -r2, for me and for comment #19. From that to -r5 the tarball has stayed the same, and no patches concerning utempter have been added. My patch still applies, which is basically proof that the code in kdelibs is still incompatible with libutempter. As kdm belongs to kde, if anything I would have assumed it to suffer from the same problem, not to solve it. I'm happy it works for you, but I cannot understand how it can. I'm starting my KDE using startx from a console login here, and right now I'm compiling an unpatched -r5 to try to reproduce your results.
(In reply to comment #27) > What does "work" mean? You are referring to the output from w My original problem was simply the lack of a line in the w output for the login to KDE. I have scripts that check that output and they 'broke' when KDE stopped recording my login. >but to me and > some others it is most important to receive wall messages via kwrited. Have you > checked this? Nope, I was never concerned with this. I'd be more than willing to test this, but it was outside the scope of my initial bug report. I checked the Services Manager in kcontrol and the KDE Write Daemon is listed as running. I don't see a kwrited process in "ps -ef". slocate only finds a library and some .desktop files. If you can give me an action and its expected reaction, I'll test it out.
(In reply to comment #28) > If you can give me an action and its expected reaction, I'll test it out. Type "wall Test". A window should open titled "KWrited - Listening on Device /dev/pts/#" and containing Text like "Broadcast message from ... Test". Notice that wall writes to all users, so keep this in mind if there are other users logged into your machine.
(In reply to comment #27) > (In reply to comment #26) > > These days, KDM-libutempter-kde does work. At least for me. > > I'm happy it works for you, but I cannot understand how it can. I'm starting > my KDE using startx from a console login here, and right now I'm compiling an > unpatched -r5 to try to reproduce your results. "startx & logout" - libutempter-1.1.5 - kdelibs-3.5.6-r5 (unmodified) still does not work: neither an entry in the w output nor a response to wall.
OK, I could reproduce the w line with kdm. kwrited still does not work. I used to have a line about "kded --new-startup" owning /dev/pts/0. kdm has root privileges, right? So it can modify UTMP without using utempter. Probably that's the reason why kdm generates such a line even when libutempter support is broken in kdelibs. To summarize: from comment #24 to now we have some indications of maybe a partial workaround based on kdm, but no real solution supporting kwrited. Therefore this is still a patch to be included by the kde team. PLEASE?
fixed with kdelibs-3.5.6-r6
