[Konsole-devel] [Bug 112840] kwrited not displaying the "wall" commands output

Martin von Gagern Martin.vGagern at gmx.net
Sun Feb 4 13:11:00 UTC 2007


------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=112840         




------- Additional Comments From Martin.vGagern gmx net  2007-02-04 14:10 -------
Created an attachment (id=19544)
 --> (http://bugs.kde.org/attachment.cgi?id=19544&action=view)
Patch to kdelibs-3.5.6 to use libutempter "New interface"

> Is it possible to update it to use the "new interface" instead?

Sure, but this would break compatibility with the old RedHat utempter
implementation. As far as I can tell even Fedora Core has switched to
libutempter, so I don't know whether there are any distros out there still
using the old utempter. Neither do I know how long the compatibility interface
is going to stay around in libutempter.

Looking at the source code from libutempter 1.1.4 available at
http://altlinux.org/index.php?module=sisyphus&package=libutempter
you will see in iface.c how the wrappers are implemented.
It boils down to this, already with the kdelibs arguments:

Old interface:
addToUtmp (d->ttyName, remotehost, d->masterFd);
removeLineFromUtmp(d->ttyName, d->masterFd);

New interface:
utempter_add_record(d->masterFd, remotehost);
utempter_remove_record(d->masterFd);

As the new interface uses another function from the library, configure has to
be modified as well. Is configure.in.in the correct file for this? My patch
changed the symbol name there, seems to work all right.

Of course, from the compatibility point of view it might be best to use
configure to check for the new interface, and fall back on the old interface if
that is available and the new one isn't. As the interfaces are similar enough,
the impact on the source files would be minimal. But configure itself would
have more work to do, I'll leave this to someone with at least a bit of
experience with autotools.



More information about the konsole-devel mailing list