Douglas R. Reno wrote:
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.
It happened that I had a copy of ld-2.23.so without being stripped. The
tests ran without hanging but take a long time (38 minutes). There are 18
tests but it takes two passes. The first run everything was OK, but the
2nd pass had 17 failures. The test log is 6.1 MB. I ran the tests over
ssh on a system with an incomplete Xorg build.
The first failing test has 19400 lines in the log. The summary is weird:
100%: Checks: 914, Failures: 0, Errors: 0
FAIL test-touchpad (exit status: 3)
In fact none of the tests indicated any Failures or Errors. They did
have valgrind issues that are all the same:
Running suite(s): tap:drag
==31485== Invalid read of size 16
==31485== at 0x6055DDF: ??? (in /lib/libc-2.23.so)
==31485== by 0x600C401: getenv (in /lib/libc-2.23.so)
==31485== by 0x50486CF: ignore_litest_test_suite_device (libinput.c:1725)
...
libinput.c line 1725 is doing:
getenv("LIBINPUT_RUNNING_TEST_SUITE")
In the test suite, that var is set to "1" (string digit one).
It could be because the ld-2.23.so.dbg was built with gcc-5.3 and
libinput/valgrind and everything else with gcc-6.1.
I really don't want to build an entire system just to check this. There
is no assurance that we would get better results anyway.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
