Bug 160814 – [GTK] Install script lacks gstreamer related dependencies

• Status: RESOLVED
• Resolution: FIXED
• Component: Tools / Tests

[Carlos Alberto Lopez Perez]

Trying to build webkitgtk+ on a debian testing chroot after running the install dependencies script (but without building the jhbuild) results on this:

-- Checking for module 'gstreamer-1.0 >= 1.0.3'
--   
-- Checking for module 'gstreamer-base-1.0 >= 1.0.3'
--   
-- Checking for module 'gstreamer-app-1.0 >= 1.0.3'
--   
-- Checking for module 'gstreamer-audio-1.0 >= 1.0.3'
--   
-- Checking for module 'gstreamer-fft-1.0 >= 1.0.3'
--   
-- Checking for module 'gstreamer-gl-1.0>=1.8.0'
--   
-- Checking for module 'gstreamer-mpegts-1.0>=1.4.0'
--   
-- Checking for module 'gstreamer-pbutils-1.0 >= 1.0.3'
--   
-- Checking for module 'gstreamer-tag-1.0 >= 1.0.3'
--   
-- Checking for module 'gstreamer-video-1.0 >= 1.0.3'
--   
-- Found GStreamer: GSTREAMER_INCLUDE_DIRS;GSTREAMER_LIBRARIES;GSTREAMER_VERSION;GSTREAMER_BASE_INCLUDE_DIRS;GSTREAMER_BASE_LIBRARIES;GSTREAMER_APP_INCLUDE_DIRS;GSTREAMER_APP_LIBRARIES;GSTREAMER_PBUTILS_INCLUDE_DIRS;GSTREAMER_PBUTILS_LIBRARIES;GSTREAMER_VIDEO_INCLUDE_DIRS;GSTREAMER_VIDEO_LIBRARIES;GSTREAMER_MPEGTS_INCLUDE_DIRS;GSTREAMER_MPEGTS_LIBRARIES;GSTREAMER_TAG_INCLUDE_DIRS;GSTREAMER_TAG_LIBRARIES;GSTREAMER_GL_INCLUDE_DIRS;GSTREAMER_GL_LIBRARIES;GSTREAMER_AUDIO_INCLUDE_DIRS;GSTREAMER_AUDIO_LIBRARIES;GSTREAMER_FFT_INCLUDE_DIRS;GSTREAMER_FFT_LIBRARIES (Required is at least version "1.0.3") 
CMake Error at Source/cmake/OptionsGTK.cmake:339 (message):
  WebAudio requires the audio and fft GStreamer libraries.  Please check your
  gst-plugins-base installation.
Call Stack (most recent call first):
  Source/cmake/WebKitCommon.cmake:47 (include)
  CMakeLists.txt:126 (include)

[Carlos Alberto Lopez Perez]

Created attachment 285937 [details]
Patch

[Philippe Normand]

I thought the install-dependencies script was meant to be used in combination with JHBuild, meaning that it shouldn't install libs built by JHBuild already...

[Carlos Alberto Lopez Perez]

(In reply to comment #2)
> I thought the install-dependencies script was meant to be used in
> combination with JHBuild, meaning that it shouldn't install libs built by
> JHBuild already...

I also thought this, but then I saw listed several dependencies that we build on the JHBuild, like atk, gtk+, cairo ...

So, then I thought that it actually made sense to also included the dependencies to build WebKitGTK+ without using the JHBuild (which is something that you want to do sometimes).

this makes sense to you also?

[Carlos Garcia Campos]

(In reply to comment #3)
> (In reply to comment #2)
> > I thought the install-dependencies script was meant to be used in
> > combination with JHBuild, meaning that it shouldn't install libs built by
> > JHBuild already...
> 
> I also thought this, but then I saw listed several dependencies that we
> build on the JHBuild, like atk, gtk+, cairo ...
> 
> So, then I thought that it actually made sense to also included the
> dependencies to build WebKitGTK+ without using the JHBuild (which is
> something that you want to do sometimes).
> 
> this makes sense to you also?

yes

[Carlos Alberto Lopez Perez]

Comment on attachment 285937 [details]
Patch

Clearing flags on attachment: 285937

Committed r204448: <http://trac.webkit.org/changeset/204448>

[Carlos Alberto Lopez Perez]

All reviewed patches have been landed.  Closing bug.

[Konstantin Tokarev]

(In reply to comment #3)
> (In reply to comment #2)
> > I thought the install-dependencies script was meant to be used in
> > combination with JHBuild, meaning that it shouldn't install libs built by
> > JHBuild already...
> 
> I also thought this, but then I saw listed several dependencies that we
> build on the JHBuild, like atk, gtk+, cairo ...

I even was cleaning up such cases, following advise of Michael Catanzaro, see https://bugs.webkit.org/show_bug.cgi?id=159628

[Carlos Alberto Lopez Perez]

(In reply to comment #7)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > I thought the install-dependencies script was meant to be used in
> > > combination with JHBuild, meaning that it shouldn't install libs built by
> > > JHBuild already...
> > 
> > I also thought this, but then I saw listed several dependencies that we
> > build on the JHBuild, like atk, gtk+, cairo ...
> 
> I even was cleaning up such cases, following advise of Michael Catanzaro,
> see https://bugs.webkit.org/show_bug.cgi?id=159628

Well... I guess we need to add some comment on the script clarifying which kind of dependency is ok or not.

Personally, I see value on having listed the dependencies that allow to build WebKitGTK+ without using the internal jhbuild.


Perhaps an idea is to add a --nojhbuild parameter that installs the dependencies which are only needed when no using the jhbuild ?

[Michael Catanzaro]

(In reply to comment #2)
> I thought the install-dependencies script was meant to be used in
> combination with JHBuild, meaning that it shouldn't install libs built by
> JHBuild already...

I agree; why should it install extra stuff?

FYI: I'm planning to delete this script and replace it with jhbuild sysdeps.

[Konstantin Tokarev]

As for jhbuild sysdeps: AFAIU installation of system packages would require running jhbuild as root, but we should run main jhbuild as root for obvious reasons. Also, jhbuild itself is installed as a part of update-webkit-libs-jhbuild which is normally run after install-dependencies.

[Michael Catanzaro]

(In reply to comment #10)
> As for jhbuild sysdeps: AFAIU installation of system packages would require
> running jhbuild as root

That's a Debian-specific problem. PackageKit allows package installation without authentication by default, and PackageKit is the default, cross-platform jhbuild sysdeps backend. (And it uses polkit, so it works without any root account.) But on Debian, jhbuild defaults to a Debian-specific sysdeps backend that uses apt-cache; I'm not completely sure why, but I think it's because Debian's PackageKit backend doesn't support searching for files? It's slower and does not use polkit, so we really do have to run it as root, but that is not any problem because the existing install-dependencies script already requires root. So the change is actually that root will no longer be required on other distros.

> but we should run main jhbuild as root for obvious
> reasons.

Of course not, only the sysdeps --install portion would need to be run as root (I guess with sudo), and *only* on Debian/Ubuntu. (We would need to check /etc/os-release before deciding to use sudo.) Actually building stuff should obviously not be done as root.

> Also, jhbuild itself is installed as a part of
> update-webkit-libs-jhbuild which is normally run after install-dependencies.

We would have to change that. The order would be:

 * Install jhbuild
 * jhbuild sysdeps --install
 * jhbuild build

[Carlos Alberto Lopez Perez]

(In reply to comment #9)
> (In reply to comment #2)
> > I thought the install-dependencies script was meant to be used in
> > combination with JHBuild, meaning that it shouldn't install libs built by
> > JHBuild already...
> 
> I agree; why should it install extra stuff?
> 

Because sometimes I want to build WebKit without the JHBuild???? And sometimes I want to build it on distros that are not my usual distro (like Fedora). And I find it handy to just execute an script that installs all the deps.

> FYI: I'm planning to delete this script and replace it with jhbuild sysdeps.

In this case, rather than deleting it, please rename it to install-dependencies-nojhbuild

[Konstantin Tokarev]

1. Package lists for these 2 cases are going to be different

2. Sysdeps of jhbuild can be used for "non-jhbuild" set up as well, it's not very productive to maintain parallel package lists for different distros.

[Konstantin Tokarev]

(though it will have to be different jhbuild sysdeps module)

[Michael Catanzaro]

You could just run 'jhbuild sysdeps --install' to install the dependencies, you don't need to build the full jhbuild environment if you don't want to. The point of switching to jhbuild sysdeps is to be able to remove this script, so we don't have to maintain three different sets of dependencies for each distro, there's no value in doing it otherwise.

[Carlos Alberto Lopez Perez]

(In reply to comment #15)
> You could just run 'jhbuild sysdeps --install' to install the dependencies,
> you don't need to build the full jhbuild environment if you don't want to.
> The point of switching to jhbuild sysdeps is to be able to remove this
> script, so we don't have to maintain three different sets of dependencies
> for each distro, there's no value in doing it otherwise.

That won't work.

For example, I want the cairo-devel from the system in order to be able to built WebKit without the JHBuild.

And jhbuild sysdeps --install should not install Cairo because we want to build our own very specific version of Cairo in order to have reliable test results for the layout tests.

[Konstantin Tokarev]

Solution is separate modulesets for 2 use cases.

[Konstantin Tokarev]

(In reply to comment #11)
> That's a Debian-specific problem. PackageKit allows package installation
> without authentication by default, and PackageKit is the default,
> cross-platform jhbuild sysdeps backend. (And it uses polkit, so it works
> without any root account.) But on Debian, jhbuild defaults to a
> Debian-specific sysdeps backend that uses apt-cache; I'm not completely sure
> why, but I think it's because Debian's PackageKit backend doesn't support
> searching for files?

FWIW, apt-cache does not require root access, and pkexec could be used to run apt-get