Bruce Dubbs wrote:
I am in the process of updating libinput and have a couple of issues
I'd like to discuss.
First, several months ago I moved libinput into xorg drivers. Upon
review, that may have been a mistake. There is nothing in Xorg that
uses it. The references in the book are:
general/sysutils/weston.xml: <xref linkend="libinput"/>,
gnome/platform/mutter.xml: <xref linkend="libinput"/>,
kde/plasma5/plasma-all.xml: <xref linkend="libinput"/>,
x/lib/qt5.xml: <xref linkend="libinput"/>
x/lib/clutter.xml: <xref linkend="libinput"/>,
xfce/core/xfce4-settings.xml: <xref linkend="libinput"/>
IIRC, I moved libinput from General Libraries where Armin placed it
initially. I now propose moving it back.
Second, the build and install of libinput-1.4.0 is straight forward,
but virtually all the checks fail. In order to run the checks both
the check program and valgrind need to be installed. However most of
the checks are based on valgrind and valgrind fails. This is because
we strip /lib/ld-2.23.so with --strip unneeded in LFS.
When checking some major distros, they make a ld-2.23.so.dbg file
available as a replacement for the normally stripped ld-2.23.so file
that would be installed with something like:
ld-linux-x86-64.so.2 -> ld-2.23.so.dbg
This file comes from glibc.
The question here is how to handle it. We can change the LFS
stripping procedure to do something like:
cp /lib/ld-2.23.so /tmp/ld-2.23.so.dbg
and then continue with
/tools/bin/find /lib /usr/lib -type f -name \*.so* \
-exec /tools/bin/strip --strip-unneeded {} ';'
mv /tmp/ld-2.23.so.dbg /lib
Then users can use the .dbg version just by changing the
ld-linux-x86-64.so.2 symlink.
Another option is to say that libinput does not come with a workable
test suite.
A third option is to describe the issue and say how to test the
package but that we have not run the tests.
I'm leaning toward this third option, but only slightly.
I appreciate any thoughts you may have about this package.
I'd say moving it back to General Libraries would be a great idea.
Test suite is much worse than previous version. It actually crashed
plain twm where I ran it. I had to hard-reset the machine. I could
switch to another VT, but actually using it was another story.
The third option seems OK to me. I would prefer someone to test the 1st
though to see if that will solve the hang that I got. It spewed garbage
over all 4 xterms I had open in TWM as well, mainly trying to repeat the
line "renodr [/sources]" as a command in all of them, all of them
returning more garbage. I would prefer the 1st option, but then again,
we need to be sure that it actually solves it. I might have run into an
obscure systemd issue as well, but I highly doubt it.
Note that after hard-booting the machine, I was unable to get access to
the log file. My guess is that once since I had to hard boot it, the
file wasn't closed.
--
Douglas R. Reno
--LFS/BLFS systemd maintainer
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
