[SOLVED] Has anyone actually built Grass GIS or QGis in -current using SlackBuilds?

First, sorry for the rant.

I'm asking this question (see subject) because I've spent the last couple of days trying to do it. Both programs (qgis, grass) where easy to build in 14.2. Compilation of QGis was a bit harder but feasible. With the advent of -current building those two is just (almost) impossible!

Starting with QGis

According to the Slackbuild, qgis depends on postgis, libspatialite, libspatialindex, numpy3, qwt-qt5, QScintilla-qt5, qtkeychain, python3-six, qca-qt5, python3-PyYAML, python-requests, Pygments, pytz, OWSLib, psycopg2, and Jinja2!

Ok, let's start building Jinja2. But wait! It depends on MarkupSafe... Ok let's build MarkupSafe... wait! It depends on python3... fortunately python3 is now on -current. All went well, MarkupSafe... built OK, Jinja2... built OK.

Now let's build psycopg2. It depends on postgresql and python3. I've got both (I use postgresql instead of mysql, sad it's not part of slackware). psycopg2... built OK

Now, OSWLib. It depends on python-dateutil, pytz, lxml, and six! I've got lxml already and six is now part of -current (but we will have to build python3-six!). So, er, let's compile python-dateutil. It depends on setuptools-scm and six...

I quit!

Let's try to build Grass GIS

Grass depends on gdal, numpy3, and wxPython4! Great, a modest number of dependencies! I've already gdal and numpy3. So it's easy. Just build wxPython4... Uhmm, wxPython4 depends on either webkit2gtk and pathlib2. Not that bad.

Well, webkit2gtk depends on bubblewrap, enchant2, geoclue2, gst-plugins-bad, hyphen, libseccomp, libwebp, xdg-dbus-proxy, and woff2. Oh no. Let's try pathlib2 first. Oh, it depends on python-scandir! Build python-scandir... OK. Build pathlib2... OK. Time to build webkit2gtk dependencies...

1. woff2: The Slackbuild says it needs brotli and ninja. Both are included in -current! Done.
2. xdg-dbus-proxy: builds ok
3. libwebp: it's already in -current... fine!
4. libseccomp: builds ok
5. hyphen: builds ok, but takes sometime
6. gst-plugins-bad: builds ok
7. geoclue2: depends on json-glib, shipped with -current. builds ok
8. enchant2: builds ok
9. bubblewrap: builds ok
10. webkit2gtk: fails with some comments of a missing wpe library. This dependency is not listed in the Slackbuild. Ok, let's build libwpe. Done.
11. webkit2gtk still complains with missing libwpe! After some goggling I disabled WPE in webkit2gtk slackbuild with a -DUSE_WPE_RENDERER=NO.
12. Finally webkit2gtk starts building.

webkit2gtk is still compiling after more than 3h! It gave me time to write this post! Will I eventually be able to build wxPython4? And grass? Is wxPython4 enough or I also need wxGTK (or some other form of wxWidgets)?

UPDATE: Just before I finished writing this post, webkit2gtk slackbuild failed at 98% with the following message:

[ 98%] Building CXX object Source/WebKit/CMakeFiles/WebKit.dir/__/__/DerivedSources/WebKit/unified-sources/UnifiedSource-88d1702b-26.cpp.o
/tmp/sbopkg.iYvfZs/webkitgtk-2.26.3/Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp: In member function ‘void* WebKit::WaylandCompositor::Buffer::createImage() const’:
/tmp/sbopkg.iYvfZs/webkitgtk-2.26.3/Source/WebKit/UIProcess/gtk/WaylandCompositor.cpp:134:116: error: ‘EGL_WAYLAND_BUFFER_WL’ was not declared in this scope
  134 |     return static_cast<EGLImageKHR*>(eglCreateImage(PlatformDisplay::sharedDisplay().eglDisplay(), EGL_NO_CONTEXT, EGL_WAYLAND_BUFFER_WL, m_resource, nullptr));
      |                                                                                                                    ^~~~~~~~~~~~~~~~~~~~~
make[2]: *** [Source/WebKit/CMakeFiles/WebKit.dir/build.make:5826: Source/WebKit/CMakeFiles/WebKit.dir/UIProcess/gtk/WaylandCompositor.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [CMakeFiles/Makefile2:1244: Source/WebKit/CMakeFiles/WebKit.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

Yes, QGIS has lots of dependencies. But yes, you can build it on current.

I have build qgis 3.10.2 on Slackware current (2020-01-20) using Mr Bosth qgis3-slackbuild Readme from his gitHub page (which are very good). All the QT5 related files I used AlienBob's build files. The reason for this was I had some problems versions of some of the files and QT5 was not in slackware current at that time..

The files I ended up building were :

BeautifulSoup4-4.6.3-x86_64-1_SBo.tgz
MarkupSafe-1.1.1-x86_64-1_SBo.tgz
OWSLib-0.19.0-x86_64-1_SBo.tgz
PyQt-4.12.3-x86_64-1.txz
PyQt5-5.13.2-x86_64-2.txz
QScintilla-2.11.4-x86_64-3.txz
filezilla-3.46.3-x86_64-13_SBo.tgz
freexl-1.0.5-x86_64-3_SBo.tgz
gdal-3.0.0-x86_64-1_SBo.tgz
geos-3.7.2-x86_64-1_SBo.tgz
gpsbabel-1.6.0-x86_64-1_SBo.tgz
html5lib-1.0.1-x86_64-1_SBo.tgz
lablgtk-2.18.4-x86_64-3_SBo.tgz
libfilezilla-0.19.3-x86_64-1_SBo.tgz
libminizip-1.2.11-x86_64-1_SBo.tgz
libspatialindex-1.8.5-x86_64-1_SBo.tgz
libspatialite-4.3.0a-x86_64-1_SBo.tgz
libxkbcommon-0.9.1-x86_64-1_SBo.tgz
lxml-4.4.1-x86_64-1_SBo.tgz
numpy3-1.14.3-x86_64-1_SBo.tgz
ocaml-4.03.0-x86_64-3_SBo.tgz
ocaml-findlib-1.6.2-x86_64-3_SBo.tgz
postgis-3.0.0-x86_64-1_SBo.tgz
postgresql-12.1-x86_64-2-plt.tgz
proj-6.1.0-x86_64-1_SBo.tgz
psycopg2-2.8.4-x86_64-1_SBo.tgz
python-dateutil-2.8.0-x86_64-1_SBo.tgz
python-webencodings-0.5.1-x86_64-1_SBo.tgz
python3-Jinja2-2.10-x86_64-1_SBo.tgz
pytz-2018.9-x86_64-1_SBo.tgz
qca-qt5-2.2.1-x86_64-1.txz
qgis-3.10.2-x86_64-1.txz
qt5-5.13.2-x86_64-1.txz
qt5-webkit-5.212.0_alpha3-x86_64-2.txz
qtkeychain-0.9.1-x86_64-1_SBo.tgz
qwt-6.1.4-x86_64-1.txz
setuptools-scm-3.3.3-x86_64-1_SBo.tgz
sip-4.19.20-x86_64-2.txz
six-1.12.0-x86_64-1_SBo.tgz
unixODBC-2.3.7-x86_64-13-plt.tgz

I do not use grass so I have not tried to build it.

In reply to post #1:

Slackware doesn't do dependency management - sad but true.

I keep a Mint VM( = Ubuntu with go-faster GUI) and another as dual boot install.

The VM serves to run most stuff. My pc is relatively puny, and with only 50% of resources going to the VM(max) speed can be an issue

The dual boot Mint is for those Catch-22 situations where Slackware is belly up, or I need more power. Mint does have dependency tracking.

Originally Posted by business_kid In reply to post #1: Slackware doesn't do dependency management - sad but true. I keep a Mint VM( = Ubuntu with go-faster GUI) and another as dual boot install. The VM serves to run most stuff. My pc is relatively puny, and with only 50% of resources going to the VM(max) speed can be an issue The dual boot Mint is for those Catch-22 situations where Slackware is belly up, or I need more power. Mint does have dependency tracking.

I know Slackware does not do dependency management and I prefer it that way! I've been using Slackware since 1995! My big concern is that there are a few "mammoths" that are becoming rather difficult to install through Slackbuilds because of their size and their list of dependencies. For me, these are QGis, grass and ugene. All failed to build with Ponce's Slackbuilds for -current.

Originally Posted by bosth Yes, QGIS has lots of dependencies. But yes, you can build it on current.

Glad to hear that. But did you use Slackbuilds? Because using the most current ones from Ponce I stopped at Pygments, a requirement that seems not to exist anymore on Slackbuilds. Another one is python-requests, which may have been replaced by python-requests-kerberos (but I'm still investigating this).

I'm pretty sure I can compile and install all of the above with the traditional ./configure; make; make install (eventually using slacktrack) but I rather do it through Slackbuilds as I will keep my systems (and my mind - it does the dependency management) sane and clean.

Originally Posted by sairum Glad to hear that. But did you use Slackbuilds? Because using the most current ones from Ponce I stopped at Pygments, a requirement that seems not to exist anymore on Slackbuilds. Another one is python-requests, which may have been replaced by python-requests-kerberos (but I'm still investigating this). I'm pretty sure I can compile and install all of the above with the traditional ./configure; make; make install (eventually using slacktrack) but I rather do it through Slackbuilds as I will keep my systems (and my mind - it does the dependency management) sane and clean.

Yes, I wrote that SlackBuild and use it on 14.2 and current.

You will need to adapt to the new packages on current, some of which have new names. For example, sip now take the place of python3-sip and so on. The good news is that *most* of the Python packages are not strictly necessary; you will see error messages when running QGIS but they will simply disable certain plugins.

The one change you need to make to the QGIS SlackBuild is change the name of the sip executable because the SlackBuild version of sip uses a different name than the one on current.

See my old notes here: https://github.com/bosth/qgis3-slackbuild

Since I wrote those, current has changed so some things are clearly obsolete (e.g. qt5 now added as an official package).

Originally Posted by sairum Because using the most current ones from Ponce I stopped at Pygments, a requirement that seems not to exist anymore on Slackbuilds. Another one is python-requests, which may have been replaced by python-requests-kerberos (but I'm still investigating this).

This is because these packages have been added to Slackware itself. ponce removes them from his repo, but he does not remove the names from the REQUIRES line, because it would add a TON of extra time to his workflow. The references to those packages will be removed once they start migrating his repo for the eventual Slackware 15.0 release.

+--------------------------+
Mon Jan  6 23:43:17 UTC 2020
l/python-pygments-2.5.2-x86_64-1.txz:  Added.
--snip--
Sat Sep 23 01:02:32 UTC 2017
l/python-requests-2.18.4-x86_64-1.txz:  Added.

First thanks for the guidelines! I'm almost there!

Originally Posted by bosth Yes, I wrote that SlackBuild and use it on 14.2 and current. The one change you need to make to the QGIS SlackBuild is change the name of the sip executable because the SlackBuild version of sip uses a different name than the one on current. [...]

Aahhrg! I should have seen this earlier! I 've made a break while qgis was compiling an it failed at 99% of the process!

[ 99%] Generating 3d/sip_3dpart0.cpp, 3d/sip_3dpart1.cpp, 3d/sip_3dpart2.cpp, 3d/sip_3dpart3.cpp /bin/sh: /usr/bin/python3-sip: No such file or directory make[2]: *** [python/CMakeFiles/python_module_qgis__3d.dir/build.make:578: python/3d/sip_3dpart0.cpp] Error 127 make[2]: *** Deleting file 'python/3d/sip_3dpart0.cpp' make[1]: *** [CMakeFiles/Makefile2:3643: python/CMakeFiles/python_module_qgis__3d.dir/all] Error 2 make: *** [Makefile:152: all] Error 2 Cleaning up...

It failed precisely because of sip3 or python3-sip! I wonder why it didn't detect sip3 (I have nothing named python3-sip). sip and sip3 come from Alien's ktown. Eventually I'll have to symlink sip3 with python3-sip. I'll try again tomorrow...

You can symlink or edit the SlackBuild - either way works.

Originally Posted by sairum It failed precisely because of sip3 or python3-sip! I wonder why it didn't detect sip3 (I have nothing named python3-sip). sip and sip3 come from Alien's ktown. Eventually I'll have to symlink sip3 with python3-sip. I'll try again tomorrow...

Looking at the SlackBuild, the maintainer is explicitly changing the $SIP_BINARY_PATH variable to /usr/bin/python3-sip using the sed line below before configuring with cmake. If you try commenting that out, it may fix your problem (I'm not sure what the original variable ends up being -- but worst case, you could just replace the /usr/bin/python3-sip in that sed line to /usr/bin/sip3).

sed -i 's|${SIP_BINARY_PATH}|/usr/bin/python3-sip|' cmake/SIPMacros.cmake

I'm just here to chime in that I also recently built GRASS and QGIS on -current. I also have Plasma 5, so it just required carefully skipping any package that was already installed (including some that have different names on SBo and -current or ktown) and making the modification discussed above.

-current is always a bit of a moving target, so it can take some extra attention to get complicated packages to build. Once 15.0 comes out, things will be a lot more straightforward because a lot of the dependencies (at least the big ones like Qt5) will be part of the main tree, and all of the SBo metadata will be in sync with it.

I've hit problems too with the rolling-release aspect of ~Current, so I grab the iso when I update. Then I have a snapshot.

Originally Posted by montagdude I'm just here to chime in that I also recently built GRASS and QGIS on -current. I also have Plasma 5, so it just required carefully skipping any package that was already installed (including some that have different names on SBo and -current or ktown) and making the modification discussed above. -current is always a bit of a moving target, so it can take some extra attention to get complicated packages to build. Once 15.0 comes out, things will be a lot more straightforward because a lot of the dependencies (at least the big ones like Qt5) will be part of the main tree, and all of the SBo metadata will be in sync with it.

Thanks montagdude! It's always good to know that someone did it! I am totally aware that -current is a sort of a moving target. That's why I usually avoid jumping into it unless I have to. I was forced to adopt -current mostly because of gcc version (some software used in genomics take advantage of gcc 9 features). I'm only complaining about two or three packages that used to be "easy" to compile, such as grass, qgis and ugene, but are not anymore. I'm old, and I fill that we are moving away from the unix philosophy (if that is a thing), by building larger and more complex software suits.

I'll discard ugene right away since I don't use it that much. For that matter, I prefer the staden package (still based on Tcl/Tk) but which is having its issues with the Slackbuils. QGis was ok for very "light" GIS analysis. It's not a must have, but it's handy. Since grass adopted the python UI (wxPython) it become much harder to compile...

I'm taking the morning to compile QGis. While I was at it, I upgraded the Slackbuild script from qgis-3.10.1 to qgis-3.12.0. It failed complaining that it needs proj-6.3.1 instead of proj-6.3.0! Ok, I downgraded to qgis-3.10.3. It fails complaining that gdal-3.0.2 is to old! It needs gdal-3.0.3. I'll have to recompile geos/proj/gdal (and possibly blas and postgis). So the cycle starts again...

I've already updated the gdal, proj and postgis SlackBuilds, so you'll find them all ready to use. However, I've not gotten QGIS 3.12.0 working on 14.2 quite yet.

I upgraded QGIS from 3.10.2 to 3.10.3 yesterday. Had to upgrade proj to 6.3.1 & gdal to 3.0.4 Did not upgrade any other packages from my Jan 20th build. I usually try to use LTR releases until a new LTR comes out.