Comment 1 Marcus von Appen 2014-10-03 07:04:14 UTC

Asking maintainer for feedback. Also involving thierry@, since we had a similar issue with py-numpy in ports r369447, bug 188114.

Comment 2 Thierry Thomas 2014-10-03 07:19:29 UTC

When `USES=	fortran' is defined, LDFLAGS is set to:

LDFLAGS+= -Wl,-rpath=${LOCALBASE}/lib/gcc${_GCC_VER} \
 	-L${LOCALBASE}/lib/gcc${_GCC_VER} -B${LOCALBASE}/bin

and usually this error is caused by this missing flags.

Check that LDFLAGS is propagated to the Makefiles and not overwritten, and that should fix it.
(Sorry, I cannot check it at the moment)

Comment 3 Thierry Thomas 2014-10-04 19:20:28 UTC

Created attachment 147980 [details]
Patch adding fortran and LDFLAGS + modernizing

Could you please check the attached patch? It seems to work for me.

There is still some warnings:

- Warning: loading of qt translation failed [/usr/local/share/qt4/translations/qt_fr_FR]

- Couldn't load plugin 'processing' from ...

- ImportError: No module named psycopg2
	Could be solved by adding a RUN_DEPENDS on databases/py-psycopg2

but these are just warnings...

Yes!

I was trying to enforce LD_LIBRARY_PATH in the python interpreter initialization at first, but it was not working. This works very well, it indeed gives the psycopg2, but at least, this is a "clean" missing dep error :)

Thank you very much

Comment 5 Rainer Hurling 2014-10-06 08:51:09 UTC

Sorry for the late response of me (maintainer). I am on a business trip until tomorrow evening and so have to wait until then for a deeper look. 

Some days ago (2014-09-09) I filed a patch [1] which should solve much of the problems we have with gcc4[78], python dependencies, brokeness on FreeBSD < 9.0 and a dated GRASS dependency. It is not committed until now.

Could you please try the patch in Bug 192605 against the original port (without your FORTRAN and LDFLAGS approach) and report back, if it solves your described problems?


[1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192605

No problem,

No, if I apply only Bug 192605 patch on vanilla port directory, the loading still fails with a "cannot load scimath" from the processing plugin (but linker messages about libgfortran/libgcc messages disappeared from stderr)

Comment 7 Rainer Hurling 2014-10-07 08:51:32 UTC

Ok, thanks for testing.

So I will try to merge the two patches in a way, that the LDFLAGS and python problems disappear and my other fixes also work. Because I am very busy at the moment, that could take a few days (including testing).

Comment 8 Rainer Hurling 2014-10-08 20:37:15 UTC

Created attachment 148115 [details]
merge of patches from Bugs 192605 and 194060 (previous one)

Enhancements are:
- Enable Fortran again (thanks to thierry@)
- Add python and pgsql to USES=
- Correct grass dependency version: 6.4.3 to 6.4.4 (bug 192624)
- Ensure presence of GRASS, if option enabled
- Use ${PYTHON_PKGNAMEPREFIX}name>[compatible-version] scheme
- Broken on FreeBSD < 9.0, if option GRASS enabled (utempter.h problem)
- Correct typo for 'RUN_DEPENDS' in previous patch, sorry.
- Remove dirrmtry entries

-------------------------------------------------------

#portlint -AC
WARN: /usr/ports/graphics/qgis/pkg-plist: [495]: enumerating info files
in the plist is deprecated in favor of adding info files into the
Makefile using the INFO macro.
0 fatal errors and 1 warnings found.

This warning is wrong, because it relates to qgis.g.info, a QGIS pendant
for the GRASS command 'g.info'. It is not an info file.

-------------------------------------------------------

Tested with RedPorts. RedPorts is not fully functional at the moment:
[1] https://redports.org/buildarchive/20141008192546-34197/

No problems on my side, still working like a charm.

Comment 10 Rainer Hurling 2014-10-11 14:03:40 UTC

Created attachment 148189 [details]
Additionally use mapserver

Enhancements are now:
- Enable Fortran again (thanks to thierry@)
- Add python and pgsql to USES=
- Correct grass dependency version: 6.4.3 to 6.4.4 (bug 192624)
- Ensure presence of GRASS, if option enabled
- Use ${PYTHON_PKGNAMEPREFIX}name>[compatible-version] scheme
- Broken on FreeBSD < 9.0, if option GRASS enabled (utempter.h problem)
- Correct typo for 'RUN_DEPENDS' in previous patch, sorry.
- Remove dirrmtry entries
- graphics/mapserver (+ www/fcgi) for mapscript capabilities
- rename %%QGIS_FCGI%% to %% QGIS_MAPSERVER%%

The usage of 'real' mapserver port is important to get QGIS extensions like 'RT MapServer Explorer' working. They depend on mapscript functionality from MapServer port. For this, python bindings option in graphics/mapserver must be enabled.

(In reply to Rainer Hurling from comment #10)
> Created attachment 148189 [details]
> Additionally use mapserver
> 
> Enhancements are now:
> - Enable Fortran again (thanks to thierry@)
> - Add python and pgsql to USES=
> - Correct grass dependency version: 6.4.3 to 6.4.4 (bug 192624)
> - Ensure presence of GRASS, if option enabled
> - Use ${PYTHON_PKGNAMEPREFIX}name>[compatible-version] scheme
> - Broken on FreeBSD < 9.0, if option GRASS enabled (utempter.h problem)
> - Correct typo for 'RUN_DEPENDS' in previous patch, sorry.
> - Remove dirrmtry entries
> - graphics/mapserver (+ www/fcgi) for mapscript capabilities
> - rename %%QGIS_FCGI%% to %% QGIS_MAPSERVER%%
> 
> The usage of 'real' mapserver port is important to get QGIS extensions like
> 'RT MapServer Explorer' working. They depend on mapscript functionality from
> MapServer port. For this, python bindings option in graphics/mapserver must
> be enabled.

I tried it, I see a side problem that was here since the begining: regarding python support, a lot of options are put in the "BUILD_DEPENDS" variable, which is wrong: qgis will need them at runtime (there will be problems if autoremove is run, or probably if gqis is installed via pkg repos).

Not sure which part of them should be also put in RUN_DEPENDS, but I'm guessing everything except devel/py-sip.

Aside from that, I don't see any problem.

Comment 12 Rainer Hurling 2014-10-20 13:08:20 UTC

Created attachment 148499 [details]
repeat most BUILD_DEPENDS also in RUN_DEPENDS

Thanks for your testing. I think, you are right. So I include most python deps also in RUN_DEPENDS.

Comment 13 Rainer Hurling 2014-10-20 19:55:21 UTC

Created attachment 148520 [details]
updated patch against r371283

Yet another patch, after r371293 from bapt@, who removed all @dirrm entries in pkg-plist. Apart from that, no functional change against the previous, now obsolete patch [1].

[1] https://bugs.freebsd.org/bugzilla/attachment.cgi?id=148499

Comment 14 Rainer Hurling 2014-10-26 11:46:34 UTC

Created attachment 148661 [details]
updated USES=

After r371326 from mva@, which integrates python into USES=, another QGIS patch is necessary. No functional changes against bug 148520

Comment 15 John Marino 2014-10-31 17:49:10 UTC

I would have liked to have seen a poudriere log, but I am taking pity on poor Rainer who had had to regenerate the patch a few times and moving this to patch-ready now.

Comment 16 Loïc Bartoletti 2014-11-02 19:48:10 UTC

and now QGis 2.6 is out. Do you wait to update the version and apply the new patch ?

Thanks

(In reply to coder from comment #16)
> and now QGis 2.6 is out. Do you wait to update the version and apply the new
> patch ?
> 
> Thanks

I don't think qgis 2.6 will fix that kind of problems (since it is relatively FreeBSD/ports centric), and since the patch only affect the port Makefile, it should not either affect it. I'm 100% happy since I can live with a patched port tree, but this issue was resolved a while ago and maybe it would be nice to push it to everybody?

On the other hand, delaying it until qgis 2.6 is commited seems a bit more fuzzy, since we don't know how fast the port will be updated?

But great news btw, I guess I'll try to bump my local version and see what happens :)

Comment 18 Rainer Hurling 2014-11-03 08:02:28 UTC

(In reply to Matthieu Volat from comment #17)

> I don't think qgis 2.6 will fix that kind of problems (since it is
> relatively FreeBSD/ports centric), and since the patch only affect the port
> Makefile, it should not either affect it. I'm 100% happy since I can live
> with a patched port tree, but this issue was resolved a while ago and maybe
> it would be nice to push it to everybody?

You are right. Most of the changes, which are in my last submitted patch (148661), is not relevant upstream.

> On the other hand, delaying it until qgis 2.6 is commited seems a bit more
> fuzzy, since we don't know how fast the port will be updated?

I am working on an update towards 2.6.0 yet. But it could take some days, since I don't want to introduce new problems ;)

> But great news btw, I guess I'll try to bump my local version and see what
> happens :)

I would suggest, that in the meantime, someone with a commit bit should bring this patch (148661) into the tree. Then I will prepare the update from 2.4.0 to 2.6.0 in a new bugzilla report.

Comment 19 commit-hook 2014-11-08 07:53:21 UTC

A commit references this bug:

Author: riggs
Date: Sat Nov  8 07:53:09 UTC 2014
New revision: 372306
URL: https://svnweb.freebsd.org/changeset/ports/372306

Log:
  Fix runtime errors with gcc 4.8

  Additional enhancements:
  - Enable Fortran again (thanks to thierry@)
  - Add python and pgsql to USES=
  - Correct grass dependency version: 6.4.3 to 6.4.4 (bug 192624)
  - Ensure presence of GRASS, if option enabled
  - Use ${PYTHON_PKGNAMEPREFIX}name>[compatible-version] scheme
  - Broken on FreeBSD < 9.0, if option GRASS enabled (utempter.h problem)
  - Correct typo for 'RUN_DEPENDS' in previous patch, sorry.
  - Remove dirrmtry entries
  - graphics/mapserver (+ www/fcgi) for mapscript capabilities
  - rename %%QGIS_FCGI%% to %% QGIS_MAPSERVER%%

  PR:		194060
  Submitted by:	mazhe@alkumuna.eu
  Reviewed by:	rhurlin@gwdg.de (maintainer)

Changes:
  head/graphics/qgis/Makefile
  head/graphics/qgis/pkg-plist

Comment 20 Thomas Zander 2014-11-08 07:56:19 UTC

Building the various OPTIONS permutations took a while, but now committed, thanks!

Thanks a lot! It feels nice to have FreeBSD strong even in specialized field of study :)