[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Debian specific gpm brokenness



using std::hi;

I'm currently writing an input multiplexer for the cPad (an LCD backed
touchpad) and while testing the repeater for that with gpm appear to
have discovered (one of the reasons at least) why it now fails for a
large number of users who previously used it successfully.

The debian patches to 'rework' the ps2 interface happily ignore the
ps2 protocol.  While it appears to work for some accepting and/or
slow to respond devices, anything that promptly sends an ACK after
receiving a command request (as per the protocol description I've
seen) will cause (debian) gpm to (incorrectly) fail.

This bug is not present in the original sources, so the question now
is what to do about it.  There appears to be an active upstream
maintainer and there is a 1.20.1 release -- he also appears to be aware
of the large array of debian patches to it but has not applied them all
(though they are distributed in the upstream tarball)

What I'd like to see is the new upstream source in Debian but there are
a couple of problems with this.  One being the apparent non-responsiveness
of the maintainer, two being the the upstream source has not changed the
soname, three being unless we bump it, reverting the debian patches (as
I believe we should in the absence of evidence for their continued
usefulness) will cause things using libgpm to silently break.

I've uploaded 1.20.1 .debs to people.d.o/~ron -- they aren't lintian
clean (though no worse than the current package), and they will cause
things like mc &c that use libgpm1, to stop accepting mouse input unless
recompiled with it.  (Though it won't prevent them from running without
mouse support).  They've also been tested a whole 5 minutes, so caveat
emptor. -- they should however work for many people who gpm 'suddenly'
stopped working for.

I'm also prepared to NMU them if someone asks nicely and if we can
arrive at some consensus on an acceptable solution to the soname
problem, though I'd rather see someone pick them up, clean them up,
and actively maintain them.

Thoughts?

  Ron

(who's not currently subscribed to -devel so cc away :)



Reply to: