Bug 1305276 - geos: FTBFS in rawhide
geos: FTBFS in rawhide
Product: Fedora
Classification: Fedora
Component: geos (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Devrim GÜNDÜZ
Fedora Extras Quality Assurance
Depends On:
Blocks: F24FTBFS BaseRuntimeFTBFS
  Show dependency treegraph
Reported: 2016-02-06 10:35 EST by Tom Hughes
Modified: 2017-07-25 17:21 EDT (History)
6 users (show)

See Also:
Fixed In Version: geos-3.6.1-1.fc26
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-07-25 17:21:12 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to fix FTBFS (1.16 KB, patch)
2016-04-05 05:04 EDT, Tom Hughes
no flags Details | Diff
Patch for disable PHP support (2.47 KB, patch)
2016-12-07 12:04 EST, Jitka Plesnikova
no flags Details | Diff

  None (edit)
Description Tom Hughes 2016-02-06 10:35:09 EST
No doubt there will be an official FTBFS bug shortly, but I noticed that geos had failed to rebuild in the mass rebuild and tracked it down to geo assuming that including cmath will get isnan while it now only seems to get std::isnan.

This should probably be reported upstream but a quick fix is to add to %build:

# isnan is in math.h, std::isnan is in cmath
sed -i -e 's|= isnan(|= std::isnan(|g' configure
sed -i -e 's|(isnan(|(std::isnan(|g' include/geos/platform.h.in

A scratch build with that change applied is here:

Comment 1 Tom Hughes 2016-02-11 09:36:13 EST
Is there any chance this good get applied? Only the current gcc 5 built geos doesn't seem to play well with other gcc 6 built stuff on arm and rebuilding it seems to fix things.

I'm happy to request ACLs and fix it myself if you want.
Comment 2 Tom Hughes 2016-02-17 18:13:53 EST
I've requested ACLs now, if you feel like granting them so I can fix this myself.
Comment 3 Jan Kurik 2016-02-24 09:25:42 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
Comment 4 Tom Hughes 2016-04-05 05:04 EDT
Created attachment 1143721 [details]
Patch to fix FTBFS

Here's a patch to the spec to fix the FTBFS as outlined in my original report, if that helps get this sorted.
Comment 5 Devrim GÜNDÜZ 2016-04-07 08:31:30 EDT
Pushed patch to repo. Building packages now.
Comment 6 Tom Hughes 2016-04-18 09:16:23 EDT
Thanks for taking care of this.
Comment 7 Remi Collet 2016-10-29 03:26:15 EDT
This packages is still FTBFS, mostly because swig is not yet compatible with PHP 7.

I think for now, the geos-php sub-package should be disabled.

BTW, some comments about this sub package.

1/ macros

%{!?php_sitearch: %define php_sitearch %{_libdir}/php/modules}

better to use %php_extdir  (from php-devel)


better to use %php_inidir

2/ Missing API dependency check

# ABI check
Requires:      php(zend-abi) = %{php_zend_api}
Requires:      php(api) = %{php_core_api}

see: https://fedoraproject.org/wiki/Packaging:PHP#C_extensions_.28PECL_and_others.29

3/ ini name

Bad ini name, numerical prefix needed to ensure correct load order (since PHP 5.6), so

%if "%{php_version}" < "5.6"
%global ininame       %{name}.ini
%global ininame       40-%{name}.ini

cat > %{buildroot}%{php_inidir}/%{ininame} <<EOF

4/ namespace

Probably a good idea to provides package name in the php namespace

Provides: php-%{name}         = %{version}
Provides: php-%{name}%{?_isa} = %{version}
Comment 8 Jitka Plesnikova 2016-12-07 12:04 EST
Created attachment 1229138 [details]
Patch for disable PHP support

SWIG upstream implemented support for PHP 7 (not released yet), but it can't solve the build issue. The reason is that PHP code is not generated by swig. 

SWIG is used only for generating python and ruby bindings. 

The only way, how to solve the FTBFS, is disabling PHP support.

BTW, there is a new release of geos and one of the changes is moving PHP bingings to separate repo

Changes in 3.6.0
- Important / Breaking Changes:
  - The PHP binding moved to its own repository:
    http://git.osgeo.org/gogs/geos/php-geos (#765)
- New things:
  - CAPI: GEOSGeom_{get,set}UserData (Rashad Kanavath)
  - CAPI: GEOSGeom_{set,get}Precision (#713)
  - CAPI: GEOSMinimumRotatedRectangle and GEOSMinimumWidth
    (#729, Nyall Dawson)
  - CAPI: GEOSSTRtree_nearest (#768, Dan Baston)
  - CAPI: GEOSMinimumClearance and GEOSMinimumClearanceLine
    (#776, Dan Baston)
- C++ API changes:
  - Automatic memory management for GeometryFactory objects
Comment 9 Remi Collet 2016-12-11 04:55:22 EST
Indeed, php-geos seems the right way.

I just give it a try on F25 using geos-devel 5.3.0

- build + test suite ok against PHP 5.6, 7.0 and 7.1

If you want I can quickly create a php-geos new package (and thus, will take care of it)
Comment 10 Remi Collet 2016-12-11 05:34:12 EST
See https://github.com/remicollet/remirepo/blob/master/php/php-geos/php-geos.spec

Test build against PHP 5.4, 5.5, 5.6, 7.0, 7.1, geos 3.4, 3.4, i386, x86_64, NTS and ZTS (for my repository).

Tell me if you agree to drop the geos-php sub-package and want me to submit the php-geos new package.
Comment 11 Remi Collet 2016-12-16 01:42:25 EST
See bug #1405298 (php-geos review)
Comment 12 Stephen Gallagher 2017-01-04 10:46:59 EST
Can we get an update on this?
Comment 13 Jitka Plesnikova 2017-02-10 07:06:03 EST
This issue is fixed by update to geos-3.6.1-1.fc26 in Fedora Rawhide.

However, geos still fails to build in Fedora 25.
Comment 14 Fedora End Of Life 2017-07-25 15:53:50 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Note You need to log in before you can comment on or make changes to this bug.