[PATCH] libinput: Upgrade 1.7.3 -> 1.8.1

[PATCH] libinput: Upgrade 1.7.3 -> 1.8.1

[Jussi Kukkonen]

New feature release, see
https://lists.freedesktop.org/archives/wayland-devel/2017-June/034286.html
for the major features. This is the last major release to support
autotools.

Configure flag "--enable-event-gui" changed name.

Configure flags no longer default to "auto": explicitly disable the
things that were previously automatically disabled.

Package the binaries into libinput-bin while being careful with
packaging as the main package gets renamed to libinput10.

Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>
---
 .../wayland/{libinput_1.7.3.bb => libinput_1.8.1.bb}      | 15 ++++++++++-----
 1 file changed, 10 insertions(+), 5 deletions(-)
 rename meta/recipes-graphics/wayland/{libinput_1.7.3.bb => libinput_1.8.1.bb} (57%)

diff --git a/meta/recipes-graphics/wayland/libinput_1.7.3.bb b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
similarity index 57%
rename from meta/recipes-graphics/wayland/libinput_1.7.3.bb
rename to meta/recipes-graphics/wayland/libinput_1.8.1.bb
index 6194fba..fdae3f8 100644
--- a/meta/recipes-graphics/wayland/libinput_1.7.3.bb
+++ b/meta/recipes-graphics/wayland/libinput_1.8.1.bb
@@ -10,16 +10,21 @@ DEPENDS = "libevdev udev mtdev"
 SRC_URI = "http://www.freedesktop.org/software/${BPN}/${BP}.tar.xz \
            file://touchpad-serial-synaptics-need-to-fake-new-touches-on-TRIPLETAP.patch \
 "
-SRC_URI[md5sum] = "f2993b477db8d7ec0e785ce04ffecb03"
-SRC_URI[sha256sum] = "096d612d2711f0caa2de544976ff3729e6233511ab373808644cc2dd5affcb1d"
+SRC_URI[md5sum] = "8247f0bb67052ffb272c50c3cb9c5998"
+SRC_URI[sha256sum] = "e3590a9037e561a5791c8bd3b34bfd30fad5cacd8cbefc0d75fafe3a41d07147"
 
-inherit autotools pkgconfig
+inherit autotools pkgconfig lib_package
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG[libunwind] = "--with-libunwind,--without-libunwind,libunwind"
 PACKAGECONFIG[libwacom] = "--enable-libwacom,--disable-libwacom,libwacom"
-PACKAGECONFIG[gui] = "--enable-event-gui,--disable-event-gui,cairo gtk+3"
+PACKAGECONFIG[gui] = "--enable-debug-gui,--disable-debug-gui,cairo gtk+3"
 
 UDEVDIR = "`pkg-config --variable=udevdir udev`"
 
-EXTRA_OECONF += "--with-udev-dir=${UDEVDIR}"
+EXTRA_OECONF += "--with-udev-dir=${UDEVDIR} --disable-documentation --disable-tests"
+
+# package name changed in 1.8.1 upgrade: make sure package upgrades work
+RPROVIDES_${PN} = "libinput"
+RREPLACES_${PN} = "libinput"
+RCONFLICTS_${PN} = "libinput"
-- 
2.1.4

Meson support in oe-core

[Alexander Kanavin]

On 08/07/2017 03:09 PM, Jussi Kukkonen wrote:
> New feature release, see
> https://lists.freedesktop.org/archives/wayland-devel/2017-June/034286.html
> for the major features. This is the last major release to support
> autotools.

Looks like 2017 is when autotools is finally being replaced en masse by 
various projects, particularly those related to gnome stack. Even 
relatively large projects like gstreamer are going forward with it. The 
replacement is meson, whose advantages over autotools are major, and 
disadvantages are minor:
http://mesonbuild.com/

Ross and I have done some work on bringing meson support into oe-core. 
One recipe has been fully migrated to meson (including tricker bits like
gtkdoc, and gobject introspection). Going forward that will be the 
default when a project has both that and autotools, and of course we 
should be ready for the situation when autotools support is removed from 
the upstream altogether.

http://git.openembedded.org/meta-openembedded-contrib/log/?h=akanavin/meson
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavin/meson



Alex

Re: Meson support in oe-core

[Richard Purdie]

On Mon, 2017-08-07 at 15:19 +0300, Alexander Kanavin wrote:
> On 08/07/2017 03:09 PM, Jussi Kukkonen wrote:
> Looks like 2017 is when autotools is finally being replaced en masse
> by 
> various projects, particularly those related to gnome stack. Even 
> relatively large projects like gstreamer are going forward with it.
> The 
> replacement is meson, whose advantages over autotools are major, and 
> disadvantages are minor:
> http://mesonbuild.com/
> 
> Ross and I have done some work on bringing meson support into oe-
> core. 
> One recipe has been fully migrated to meson (including tricker bits
> like
> gtkdoc, and gobject introspection). Going forward that will be the 
> default when a project has both that and autotools, and of course we 
> should be ready for the situation when autotools support is removed
> from 
> the upstream altogether.
> 
> http://git.openembedded.org/meta-openembedded-contrib/log/?h=akanavin
> /meson
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/log/?h=akanavi
> n/meson

Thanks for looking at this. Whilst some project still have some support
for both, could we get timings of do_{configure|compile|install} for
autotools vs. meson?

Cheers,

Richard

Re: Meson support in oe-core

[Alexander Kanavin]

On 08/07/2017 04:00 PM, Richard Purdie wrote:

> Thanks for looking at this. Whilst some project still have some support
> for both, could we get timings of do_{configure|compile|install} for
> autotools vs. meson?

So far there's just one recipe that I can test, json-glib, which is 
fairly small, and so there's not a lot of difference between 
compile+install steps. configure however is vastly faster:

autotools with gtk-doc

configure 16.53
compile 12.56
install 1.94
total 31.03

meson with gtk-doc

configure 2.04
compile 4.87
install 9.16
total 16.07

autotools without gtk-doc
configure 16.26
compile 5.49
install 1.59
total 23.34

meson without gtk-doc
configure 1.95
compile 5.04
install 2.26
total 9.25


Alex

Re: [PATCH] libinput: Upgrade 1.7.3 -> 1.8.1

[Richard Purdie]

On Mon, 2017-08-07 at 15:09 +0300, Jussi Kukkonen wrote:
> New feature release, see
> https://lists.freedesktop.org/archives/wayland-devel/2017-June/034286
> .html
> for the major features. This is the last major release to support
> autotools.
> 
> Configure flag "--enable-event-gui" changed name.
> 
> Configure flags no longer default to "auto": explicitly disable the
> things that were previously automatically disabled.
> 
> Package the binaries into libinput-bin while being careful with
> packaging as the main package gets renamed to libinput10.
> 
> Signed-off-by: Jussi Kukkonen <jussi.kukkonen@intel.com>

Looks like there is a race somewhere in the new version:

https://autobuilder.yocto.io/builders/nightly-wic/builds/411/steps/BuildImages_1/logs/stdio

Cheers,

Richard

Re: Meson support in oe-core

[Randy MacLeod]

On 2017-08-07 09:47 AM, Alexander Kanavin wrote:
> On 08/07/2017 04:00 PM, Richard Purdie wrote:
> 
>> Thanks for looking at this. Whilst some project still have some support
>> for both, could we get timings of do_{configure|compile|install} for
>> autotools vs. meson?
> 
> So far there's just one recipe that I can test, json-glib, which is 
> fairly small, and so there's not a lot of difference between 
> compile+install steps. configure however is vastly faster:
> 
> autotools with gtk-doc
> 
> configure 16.53
> compile 12.56
> install 1.94
> total 31.03
> 
> meson with gtk-doc
> 
> configure 2.04
> compile 4.87
> install 9.16
> total 16.07
> 
> autotools without gtk-doc
> configure 16.26
> compile 5.49
> install 1.59
> total 23.34
> 
> meson without gtk-doc
> configure 1.95
> compile 5.04
> install 2.26
> total 9.25

Yep, total time for 'without gtk-doc' is *more* than cut in half!

The drop in configure time is certainly expected but the compilation
stage should be dominated by the compiler rather than make or ninja.
The 'without gtk-doc' compile difference mostly confirms that
but the 9% drop is odd. A couple of sources I've found assert that
for large projects and parallel builds a full build time is essentially
the same with ninja:
    http://david.rothlis.net/ninja-benchmark/
That work was done on a MacBook (!!) so it would be interesting to
see what the results are on a 24+ core Linux system. I might
give that a try tonight if there's nothing good on NetFlix.

By the way, systemd-234 has meson support and you (Alex) have sent
a patch update to 242 to the oe-core list but without switching to meson
as is reasonable. Anyway, 232 takes 51 seconds on my 16+16 core machine
so it would be a useful benchmark as well. Want to take a stab at that?

../Randy



> 
> 
> Alex


-- 
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, 
Canada, K2K 2W5

Re: Meson support in oe-core

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

On 9 August 2017 at 22:10, Randy MacLeod <randy.macleod@windriver.com>
wrote:

> Yep, total time for 'without gtk-doc' is *more* than cut in half!
>

gtk-doc does some large XSLT transforms, which are single-threaded.  There
is a plan to move gtk-doc to use a simpler set of transformations which
should give an improvement there (or rewrite libxslt to be parallel, but
thats harder).

Ross

[-- Attachment #2: Type: text/html, Size: 956 bytes --]

Re: Meson support in oe-core

[Khem Raj]

On Wed, Aug 9, 2017 at 2:10 PM, Randy MacLeod
<randy.macleod@windriver.com> wrote:
> On 2017-08-07 09:47 AM, Alexander Kanavin wrote:
>>
>> On 08/07/2017 04:00 PM, Richard Purdie wrote:
>>
>>> Thanks for looking at this. Whilst some project still have some support
>>> for both, could we get timings of do_{configure|compile|install} for
>>> autotools vs. meson?
>>
>>
>> So far there's just one recipe that I can test, json-glib, which is fairly
>> small, and so there's not a lot of difference between compile+install steps.
>> configure however is vastly faster:
>>
>> autotools with gtk-doc
>>
>> configure 16.53
>> compile 12.56
>> install 1.94
>> total 31.03
>>
>> meson with gtk-doc
>>
>> configure 2.04
>> compile 4.87
>> install 9.16
>> total 16.07
>>
>> autotools without gtk-doc
>> configure 16.26
>> compile 5.49
>> install 1.59
>> total 23.34
>>
>> meson without gtk-doc
>> configure 1.95
>> compile 5.04
>> install 2.26
>> total 9.25
>
>
> Yep, total time for 'without gtk-doc' is *more* than cut in half!
>
> The drop in configure time is certainly expected but the compilation
> stage should be dominated by the compiler rather than make or ninja.
> The 'without gtk-doc' compile difference mostly confirms that
> but the 9% drop is odd. A couple of sources I've found assert that
> for large projects and parallel builds a full build time is essentially
> the same with ninja:
>    http://david.rothlis.net/ninja-benchmark/
> That work was done on a MacBook (!!) so it would be interesting to
> see what the results are on a 24+ core Linux system. I might
> give that a try tonight if there's nothing good on NetFlix.
>

try chromium builds from meta-browser and play with ninja its a big enough
package.

> By the way, systemd-234 has meson support and you (Alex) have sent
> a patch update to 242 to the oe-core list but without switching to meson
> as is reasonable. Anyway, 232 takes 51 seconds on my 16+16 core machine
> so it would be a useful benchmark as well. Want to take a stab at that?
>
> ../Randy
>
>
>
>>
>>
>> Alex
>
>
>
> --
> # Randy MacLeod. SMTS, Linux, Wind River
> Direct: 613.963.1350 | 350 Terry Fox Drive, Suite 200, Ottawa, ON, Canada,
> K2K 2W5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: Meson support in oe-core

[Alexander Kanavin]

On 08/10/2017 12:10 AM, Randy MacLeod wrote:
> Yep, total time for 'without gtk-doc' is *more* than cut in half!
> 
> The drop in configure time is certainly expected but the compilation
> stage should be dominated by the compiler rather than make or ninja.
> The 'without gtk-doc' compile difference mostly confirms that
> but the 9% drop is odd. A couple of sources I've found assert that
> for large projects and parallel builds a full build time is essentially
> the same with ninja:
>     http://david.rothlis.net/ninja-benchmark/
> That work was done on a MacBook (!!) so it would be interesting to
> see what the results are on a 24+ core Linux system. I might
> give that a try tonight if there's nothing good on NetFlix.

To be honest, achieving faster build times is secondary in importance to 
me. The important part is that autotools is one of the most awful pieces 
of software ever written, and the less we have to deal with it in Yocto, 
the happier we all will be. Upstreans generally share that POV.

Read this:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html
and this:
http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/

> By the way, systemd-234 has meson support and you (Alex) have sent
> a patch update to 242 to the oe-core list but without switching to meson
> as is reasonable. Anyway, 232 takes 51 seconds on my 16+16 core machine
> so it would be a useful benchmark as well. Want to take a stab at that?

Oe-core master does not yet have any support for meson. We've done some 
private work to bring it in, but it's not ready for submission yet. I 
also want to build a few different recipes with it to make sure it 
'basically works' for several different things.

After meson support is in master, we can start converting recipes from 
autotools to meson. That requires careful manual work, but the good news 
is that it can be done piece-meal; there's no need to switch everything 
at once.

My plan is to try gstreamer next, and after that, implement meson 
support for gettext. It's a notorious bottleneck in many builds, due to 
inexplicably slow autoconf (that even RP couldn't get down to the root 
cause of).

Alex

Re: Meson support in oe-core

[Leonardo Sandoval]

On Thu, 2017-08-10 at 13:11 +0300, Alexander Kanavin wrote:
> On 08/10/2017 12:10 AM, Randy MacLeod wrote:
> > Yep, total time for 'without gtk-doc' is *more* than cut in half!
> > 
> > The drop in configure time is certainly expected but the compilation
> > stage should be dominated by the compiler rather than make or ninja.
> > The 'without gtk-doc' compile difference mostly confirms that
> > but the 9% drop is odd. A couple of sources I've found assert that
> > for large projects and parallel builds a full build time is essentially
> > the same with ninja:
> >     http://david.rothlis.net/ninja-benchmark/
> > That work was done on a MacBook (!!) so it would be interesting to
> > see what the results are on a 24+ core Linux system. I might
> > give that a try tonight if there's nothing good on NetFlix.
> 
> To be honest, achieving faster build times is secondary in importance to 
> me. The important part is that autotools is one of the most awful pieces 
> of software ever written, and the less we have to deal with it in Yocto, 
> the happier we all will be. Upstreans generally share that POV.
> 
> Read this:
> http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.html
> and this:
> http://voices.canonical.com/jussi.pakkanen/2011/09/13/autotools/
> 
> > By the way, systemd-234 has meson support and you (Alex) have sent
> > a patch update to 242 to the oe-core list but without switching to meson
> > as is reasonable. Anyway, 232 takes 51 seconds on my 16+16 core machine
> > so it would be a useful benchmark as well. Want to take a stab at that?
> 
> Oe-core master does not yet have any support for meson. We've done some 
> private work to bring it in, but it's not ready for submission yet. I 
> also want to build a few different recipes with it to make sure it 
> 'basically works' for several different things.
> 
> After meson support is in master, we can start converting recipes from 
> autotools to meson. That requires careful manual work, but the good news 
> is that it can be done piece-meal; there's no need to switch everything 
> at once.
> 

Alex, is there a autotools-to-meson guide? I like to participate on this
migration.

Leo

> My plan is to try gstreamer next, and after that, implement meson 
> support for gettext. It's a notorious bottleneck in many builds, due to 
> inexplicably slow autoconf (that even RP couldn't get down to the root 
> cause of).


> 
> Alex

Re: Meson support in oe-core

[Alexander Kanavin]

On 08/10/2017 05:05 PM, Leonardo Sandoval wrote:

>> After meson support is in master, we can start converting recipes from
>> autotools to meson. That requires careful manual work, but the good news
>> is that it can be done piece-meal; there's no need to switch everything
>> at once.
>>
> 
> Alex, is there a autotools-to-meson guide? I like to participate on this
> migration.


If you mean a guide for how to switch yocto recipes from building using 
autotools to building using meson (when upstream provides both options, 
or switched from one to the other), then no. No one has done this before 
:) You can get a rough idea of what is involved by looking here:

http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=akanavin/meson&id=7442c79a8e03ac457bca34bbbf0c5c74c89dba6a

So:

1) inherit meson instead of autotools
2) replace autotools specific build flags with meson-specific ones (in 
PACKAGECONFIG etc.)
3) fix other issues until no errors happen
4) verify that everything that was previously installed and packaged is 
still installed and packaged.

I don't think there can be a generic guide, it's manual work which 
requires the broad recipe maintenance skillset :)

Now, If you meant writing meson support into the upstream source code, 
then that is even more specific to each project. You need to first 
carefully study what is being built, using which toolchain, and what are 
the various options, and then write meson.build files that do the same 
thing. And you also need to convince the upstream to take it, because 
it's generally not something we want to maintain as custom patches. 
Actually it's complicated enough, that I only want to attempt it for 
gettext.

Alex