-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GRASS 7/Processing stopped to work with Processing 2.10.1 #21142
Comments
Author Name: Donovan Cameron (@saultdon) I noticed that NVIZ7 is the only GRASS 7 tool that opening up a dialog. I checked how QGIS had the variables set in the settings. Some have double entries for grass 6: I tried using the custom variables option and prepending the /opt/grass folders for GRASS 7 to those and it didn't make a difference. Then I tried to set them at the command line before running qgis from there, didn't change the missing dependency error. |
Author Name: Filipe Dias (@fsdias) Grass 7 doesn't work in Processing with QGIS >= 2.10. Confirmed in Ubuntu while using QGIS 2.10 and QGIS 2.8.2 with Processing code installed via the plugins installer.
|
Author Name: Bernd Vogelgesang (Bernd Vogelgesang) When installing QGIS 2.8 under Ubuntu from the http://qgis.org/ubuntugis-ltr with http://ppa.launchpad.net/ubuntugis/ubuntugis-unstable , processing version 2.6 is shipped with it, which is working. Manually downloading version 2.9.3 (http://plugins.qgis.org/plugins/processing/version/2.9.3/download/) and copying to the plugins folder restores the GRASS functions. |
Author Name: Giovanni Manghi (@gioman)
|
Author Name: Markus Neteler (Markus Neteler) Failure also confirmed in Fedora 21 and Windows (https://gis.stackexchange.com/questions/156767/64-bit-win-8-1-grass-7-missing-dependency). For msg improvement wish, see also bug #21250 |
Author Name: Donovan Cameron (@saultdon) Looks like there is some success in master version of QGIS[1] - hopefully those changes can be backported to the ltr and stable release. [1] http://osgeo-org.1560.x6.nabble.com/Any-working-GRASS-in-QGIS-available-tp5218136p5218781.html |
Author Name: Donovan Cameron (@saultdon) Also noticed that QGIS adds duplicate entries for some the environment variables that are only for grass64. For some reason, there isn't any entries for grass7, not sure if it's related or not so I tried updating them by prepending the related grass 7 locations (or exporting from command line prior to launch), but no dice. PATH=/opt/grass64/bin:/opt/grass64/scripts:/usr/share/qgis/grass/scripts/:/opt/grass64/bin:/opt/grass64/scripts:/usr/share/qgis/grass/scripts/:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl GRASS_PAGER=cat GISBASE=/opt/grass64 PYTHONPATH=/opt/grass64/etc/python:/opt/grass64/etc/python: GRASS_MESSAGE_FORMAT=gui GRASS_BATCH_JOB=/home/saultdon/.qgis2//processing/grass_batch_job.sh LD_LIBRARY_PATH=.::/jre/lib But ld.conf.d files exist for both grass64 and grass (v7): % cat /etc/ld.so.conf.d/grass64.conf % cat /etc/ld.so.conf.d/grass.conf |
Author Name: Markus Neteler (Markus Neteler) I tried locally, it doesn't fix it for me. And the message is still obscure (no idea what Processing is looking for or expecting) so that I could rename( better: use a link) the GRASS binary as Processing wishes it to see. |
Author Name: Donovan Cameron (@saultdon) Re-compiled QGIS from release-2_10 branch and looks like I'm still getting Missing Dependency error. |
Author Name: Markus Neteler (Markus Neteler) Sorry to bother. Any chance to get a fix? I wanted to show this functionality on the Geostat2015 in a few days... I still don't know even the name of the GRASS "binary" which is expected by Processing. Thanks. |
Author Name: Jürgen Fischer (@jef-n) Markus Neteler - wrote:
Not sure how to reproduce. But did you try @strace -f -e execve -p $(pidof qgis)@ (or @qgis@). Trying @r.info@ on an inserted tif here produced:
|
Author Name: Victor Olaya (@volaya) Markus The Grass7 provider calls grass70, previously setting a batch job in the GRASS_BATCH_JOB env variable. In case of running linux (as I guess it's your case), there is no need to configure any path to GRASS in QGIS. Instead, you should just make sure that the grass executable is in your PATH env var. Hope that helps |
Author Name: Markus Neteler (Markus Neteler) Good hint, I got this (Fedora): qgis & sleep 2; strace -f -e execve -p $(pidof qgis) My local installation is: ls -la /usr/local/bin/grass70 ls -la /home/neteler/software/grass70/bin.x86_64-unknown-linux-gnu/grass70 "grass70" is installed and in the path: [neteler@oboe ~]$ grass70 --config path (the software does not reside in /usr/lib64/grass/ on my machine but it can be "anywhere" - the grass70 startup script knows where) Why does it search in /usr/lib64/grass/bin/python? Is that hardcoded anywhere? |
Author Name: Jürgen Fischer (@jef-n) Markus Neteler - wrote:
I guess it's just traversing @path@ looking for @python@ to run @grass70@. Doesn't it find any? I suppose it does, so next thing I'd do would be to dump the environment in @grass70@ to a file and look for differences when run from the command line and from processing. |
Author Name: Markus Neteler (Markus Neteler) Jürgen Fischer wrote:
There well is the system python which should be used:
I observe another issue:
but the files are there:
This is not clear to me: Processing calls the GRASS startup script for the batch processing. How should that differ? Printing the env shows that GISBASE is set wrongly to GRASS 6 which subsequently affects $PATH:
As earlier indicated, Processing should ask grass70 where it is by running:
Also these env vars are set wrongly by Processing:
This cannot work (the path exists on my machine but it is GRASS 6). Somewhere Processing picks up GRASS 6 albeit disabled in the settings rather than querying grass70 itself for where it is installed and use that information. This happens somewhere in processing/algs/grass7/Grass7Utils.py, I suppose in createGrass7Script(). PS: A pity to announce tomorrow in my Geostat2015 workshop that QGIS-Processing got broken in 2.10.x.
|
Author Name: Markus Neteler (Markus Neteler) Here some code written by myself with support by Luca Delucchi for potential integration (...to speed up things):
I suppose that a change in git itself is not possible since you may have other ideas about style and integration. Otherwise let me know. |
Author Name: Jürgen Fischer (@jef-n) Markus Neteler - wrote:
Sure, you just quoted the strace output with the failing @execve@s - so it's was unclear whether it finds one.
Probably from some external plugin - Generic maybe (never heard of it)?
Maybe from the grass(6)plugin? processing doesn't seem to touch @gisbase@ (except on windows; at least from what I see in @git grep GISBASE python/plugins/processing/@) - maybe @grass70@ should.
Shouldn't @grass70@ just execute the @GRASS_BATCH_JOB@ in a GRASS7 environment (even if it's called from what seems to be a GRASS6 environment)?
Not sure that Processing does that. I imaging it's the grassplugin that does that. Is it activated in your setup?
Maybe it's just a problem if you have both GRASS 6 & 7 and are using the grassplugin (which doesn't support GRASS7 yet). |
Author Name: Jürgen Fischer (@jef-n) Markus Neteler - wrote:
Does that break the grassplugin (if the above assumption is correct that grassplugin set GISBASE)? What would happen if you just call @gisbase= grass70 ...@, would @grass70@ then setup @gisbase@ itself? Seems odd that you need to first fetch a value from a script, set an environment variable and then call it again. |
Author Name: Markus Neteler (Markus Neteler) Jürgen Fischer wrote:
Yes, I think so.
No, it is not even installed. I have a rather minimalistic QGIS installation.
I am not using the grassplugin. And Processing-GRASS worked in earlier versions (since I did most of the update to GRASS GIS 7 I know that :-). |
Author Name: Markus Neteler (Markus Neteler) Jürgen Fischer wrote:
No idea, I don't use the grassplugin since it is not ready for G7 yet.
No need to fetch that when you use the batch job. |
Author Name: Jürgen Fischer (@jef-n) Markus Neteler - wrote:
I removed libgrassplugin7, libgrassprovider7 and libgrassrasterprovider7 from the plugins directory and @gisbase@ disappeared (which previously was set to @/usr/lib/grass70@). So it's not Processing. Do you have @gisbase@ set in the @[GRASS]@ section of your @~/.config/QGIS/QGIS2.conf@? That's where the plugin/provider gets @gisbase@ from, when it's not already set (after calling @G_no_gisinit()@) |
Author Name: Markus Neteler (Markus Neteler) Jürgen Fischer wrote:
Again, please don't hardcode where it is. If QGIS needs to figure out, ask grass70 itself.
This is what is (not) set there:
So, GISBASE is empty. |
Author Name: Jürgen Fischer (@jef-n) Markus Neteler - wrote:
Hey, I don't to either processing or the grass plugin/provider. I don't even use them. I'm just trying to help. I don't actually know where GISBASE comes from, I didn't set it, and it's apparently not hardcoded either (that would be a quick find). But it's set to an invalid directory on your machine, while it's apparently correct on mine - so there must be something different. Maybe there's cruft on your end, I don't know. What does:
give in the python console? Looks like the grass plugin/provider either uses a preset GISBASE (inherited from where qgis was called), checks if it's valid (to some extent), if that fails tries the @GRASS/gisbase@ setting, if that also fails, a local directory some packages apparently bundle grass in and if that also fails asks the user for one. The final result is written to @/GRASS/gisbase@ to be used next time around (see "qgsgrass.cpp, line 268":https://github.com/qgis/QGIS/blob/master/src/providers/grass/qgsgrass.cpp#L268). |
Author Name: Markus Neteler (Markus Neteler) Jürgen Fischer wrote:
I appreciate that. I just spent hour and hours on this topic alias a formerly working integration... ...
Something in QGIS is setting it - I didn't.
I start QGIS from command line, no GISBASE is set. So, now I just trash my local settings:
This indicates that something in QGIS is setting it.
I cannot judge that but IMHO Processing should be clearly disentangled from the grassplugin since Processing just uses a batch job approach. It worked earlier this year... |
Author Name: Markus Neteler (Markus Neteler) FWIW - Nothing strange on my machine: I just uninstalled QGIS 2.10 and installed back the version 2.8. The Processing-GRASS interface works in this older QGIS version. |
Author Name: Jürgen Fischer (@jef-n) Markus Neteler - wrote:
So you don't have a grassplugin there - and that's what (mis-)sets GISBASE. If you remove the grass plugin/provider from 2.10 GISBASE will disappear (like it did above) and processing will very likely work. |
Author Name: Markus Neteler (Markus Neteler) Jürgen Fischer wrote:
I'm afraid that I don't understand the suggestion. What is the "grassplugin" compared to "grass plugin/provider"? |
Author Name: Jürgen Fischer (@jef-n) Markus Neteler - wrote:
well the plugin is libgrassplugin7.so and the providers are libgrassprovider7.so and libgrassrasterprovider7.so - all use libqgisgrass7.so. |
Author Name: Donovan Cameron (@saultdon) -Would anyone know the cmake options to compile without the grass plugin but with the providers so I can test processing?- @-DWITH_GRASS7=OFF \ I tried setting WITH_GRASS to OFF thinking that was for the plugin and that GRASS_PREFIX and GRASS_INCLUDE_DIR were for the provider, but setting WITH_GRASS=OFF disabled the other grass options in cmake. |
Author Name: Donovan Cameron (@saultdon) Processing tools for GRASS 7 work after setting WITH_GRASS7=OFF and WITH_GRASS=OFF |
Author Name: Jürgen Fischer (@jef-n) Fixed in changeset "d2282a77c7967a8c5bb9e0599b5602be5317a7db".
|
Author Name: Donovan Cameron (@saultdon) Just compiled QGIS Master (r14205.gd2282a7) with that latest commit and it looks like GRASS 7 tools in processing don't run with either cmake options @-DWITH_GRASS7=ON@ or @-DWITH_GRASS=ON@. Have to set them to off. This is the same thing I noticed when the bug was opened. Let me know if I've done something wrong on my end!
|
Author Name: Donovan Cameron (@saultdon) Looks like processing was still using the 2.10.1 version from the home folder. Made a symlink from /usr/share/qgis/python/plugins/processing to .qgis2/python/plugins/ and grass 7 algorithms are running, even in QGIS 2.10.1 using that version of processing.
|
Author Name: Donovan Cameron (@saultdon)
Original Redmine Issue: 13072
Affected QGIS version: 2.10.1
Redmine category:processing/grass
Assignee: Victor Olaya
I've got QGIS 2.10.0 compiled on linux 64bit with the following cmake options:
@ -DWITH_GRASS7=ON \
-DGRASS_PREFIX7=/opt/grass \
-DGRASS_INCLUDE_DIR7=/opt/grass/include/ \
-DWITH_GRASS=ON \
-DGRASS_PREFIX=/opt/grass64 \
-DGRASS_INCLUDE_DIR=/opt/grass64/include@
The grass6 algorithms open and run fine from processing but trying to run any grass 7 tools results in a popup:
The text was updated successfully, but these errors were encountered: