Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 768062 - RFE: New version of qhull needed
Summary: RFE: New version of qhull needed
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: qhull
Version: rawhide
Hardware: All
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Ralf Corsepius
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1064719
TreeView+ depends on / blocked
 
Reported: 2011-12-15 16:44 UTC by Jerry James
Modified: 2016-06-23 16:25 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-06-23 16:25:51 UTC


Attachments (Terms of Use)

Description Jerry James 2011-12-15 16:44:32 UTC
Description of problem:
I am packaging some software that lists "qhull 2010.1 or newer" in its requirements.  We currently ship qhull 2003.1.  Version 2011.2 is the latest upstream release.

Version-Release number of selected component (if applicable):
qhull-2003.1-15.fc15.x86_64

How reproducible:
N/A

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
I"m a provenpackager, so if you're too busy to get to this for awhile, I'm happy to do the update myself.

Comment 1 Ralf Corsepius 2011-12-15 17:02:54 UTC
(In reply to comment #0)
> Description of problem:
> I am packaging some software that lists "qhull 2010.1 or newer" in its
> requirements.  We currently ship qhull 2003.1.  Version 2011.2 is the latest
> upstream release.

I will check 
a) whether this requirement actually applies
Many packages simply provide wild claims without justifications.

b) the shape of this "2011.2" version.
Earlier post 2003 versions had been very low quality/broken forks of the original qhull, which did not provide any incompatible feature, which would have justify upgrading.

Last time I checked, all other major distros (Debian, Ubuntu, SuSE) seem to have agreed. All of them had stayed with the 2003 version.

 
> Version-Release number of selected component (if applicable):
> qhull-2003.1-15.fc15.x86_64

> Additional info:
> I"m a provenpackager, so if you're too busy to get to this for awhile, I'm
> happy to do the update myself.
I regret - In this case I can not avoid to be hard: No,

I do not grant you permission to upgrade qhull.

Comment 2 Jerry James 2011-12-15 21:59:22 UTC
(In reply to comment #1)
> I will check 
> a) whether this requirement actually applies
> Many packages simply provide wild claims without justifications.
> 
> b) the shape of this "2011.2" version.
> Earlier post 2003 versions had been very low quality/broken forks of the
> original qhull, which did not provide any incompatible feature, which would
> have justify upgrading.
> 
> Last time I checked, all other major distros (Debian, Ubuntu, SuSE) seem to
> have agreed. All of them had stayed with the 2003 version.

Ah, that's good information.  I will check whether the package I am working on builds and functions properly with the 2003 version, then.

> I regret - In this case I can not avoid to be hard: No,
> 
> I do not grant you permission to upgrade qhull.

No problem.  It was an offer of help, not a threat. :-)

Comment 3 Jerry James 2012-01-04 16:26:06 UTC
I"ve looked into this a little more.  The package I'm working on invokes qhull via the command line, and does not use any options that were not present in the 2003.1 version.  So from a command line perspective, I'm okay.  Whether there is some bug that was not fixed until the 2010.1 version is the question.  I don't know the answer to that yet.  I am attempting to contact the upstream author to see why the docs say that version 2010.1 is required.

Incidentally, Debian switched to the 2009.1 version in squeeze, openSUSE 11.x provided version 2010.1, and openSUSE 12.1 ships version 2011.1.  Also, it appears that Fedora's scipy package is bundling the 2010.1 version (see %{_libdir}/python2.7/site-packages/scipy/spatial/qhull.so).  None of that necessarily means that Fedora should switch, of course, if you think the more recent versions are still inferior.

Comment 4 just18 2013-01-21 13:06:59 UTC
This definitely a +1 from me. The latest release has numerous bugfixes. So please update.
For reference see:
http://www.qhull.org/src/Changes.txt

It's hard that my fedora is behind debian on this one :P

Comment 5 Ralf Corsepius 2013-01-21 13:27:57 UTC
Wh(In reply to comment #4)
> This definitely a +1 from me. The latest release has numerous bugfixes. So
> please update.
> For reference see:
> http://www.qhull.org/src/Changes.txt
Well, last time I checked, there was nothing of importance but upstream massaging his broken cmake-stuff.

I can check again, but let me ask firstly, which of upstream's changes are you after?
 
> It's hard that my fedora is behind debian on this one :P
<rant>
Some people need to understand that "blindly following a upstream" isn't helpful, either. Unfortunately, both Debian and Fedora users have a record in doing so.
</rant>

Comment 6 Orion Poplawski 2013-05-15 04:00:17 UTC
Perhaps time to evaluate 2012.1?  If it doesn't break anything, I would suggest upgrading if only to prevent confusion over whether qhull in Fedora is up to date.  If anything is broken in 2012.1, it should be spelled out explicitly in this bug.  Thanks.

Comment 7 Christopher Meng 2014-02-13 07:19:08 UTC
Wow!

Please use this link to check who is the loser ;)

http://pkgs.org/search/?query=qhull

Comment 8 Ralf Corsepius 2014-02-13 07:53:36 UTC
(In reply to Christopher Meng from comment #7)
> Wow!
> 
> Please use this link to check who is the loser ;)
Please dampen your tone and abstain from being childish - I feel offended and will react accordingly - My patience with your overzealous attitude is exceeded.

Technically to what I wrote in previous comments. May-be something has changed, but last time I checked there had be _no_ reasons to switch to a new upstream version, because all they did was changing their packaging in pretty poor ways.

Comment 9 just18 2014-02-13 09:51:55 UTC
I'm no longer a Fedora user, but I really don't get how you can say that nothing has changed. If I have a look at the changelog at
http://www.qhull.org/src/Changes.txt
There a plenty of bugfixes
 - Fixed qset.c for -fno-strict-aliasing. This gcc option is no longer needed
   (disallow two pointers of differing types to the same memory location)
 - Fixed error in qh_setappend_set if first set full and second set empty
 - qh_setdelnth, qh_setdelnth_sorted: fixed wording of error message
 - qh_setcheck: error message listed size and max backwards.
 - qh_setequal: Allow NULL set as documented
 - qh_setindex: Allow NULL set as documented
 - qh_settemppush: report error if NULL
 - qh_new_qhull: Call qh_prepare_output if !outfile [A. Aldoma]
   No effect on qhull users since qh_prepare_output is always called.
 - Replace Qhull-go.pif with Qhull-go.lnk for Windows 7 64-bit [lots]
 - Error if qh_newhashtable, qh_setnew, or qh_memalloc overflows [X. Cheng]
   For example, 'rbox 64 D32' overflows hash table for qh_matchnewfacets
   Qhull uses 32-bit ints for identifiers, counts, and sizes. See "WARN64"
 - q_eg, q_test: change tail +3 to tail -n +3 [N. Dubray, M. Atzeri]
 - Qhull-go.bat: Changed 'cmd' to '%comspec%'
 - Fixed serious bug in qh_gethash [poly.c]
- 'QJn': Fix qh.STOPcone in qh_build_withrestart().  It was not cleared.
- qh_initqhull_outputflags [global.c]: warn about Qc only if QHULLfinished
    otherwise set if needed
- qh_gethash [poly.c]: fix sign conversion.
    Previously, the result may be negative, leading to a segfault.
    The bug is more likely with large address spaces
    Reviewed all uses of %(modulo) for remainder with negative arguments
- Reviewed output of q_test and compared to results from 2003.1

And this is only some bugs from the last few Versions. So I still think this package needs a version bump and if its only to satisfy some third party libraries like PCL (pointclouds.org) or the latest version of Octave.

Comment 10 Christopher Meng 2014-02-21 10:06:03 UTC
Ralf, do you think that comment 9 is bullshit?

My worry is for the bug 1064719, if you can ensure that it works well, I will keep quiet.

Comment 11 Christopher Meng 2014-07-09 07:10:54 UTC
Ralf, please update this package to the latest version.

I don't care if you still consider there is no changes at all in the codebase, the problem is that I can't build my package anymore:

In file included from /usr/lib/python2.7/site-packages/numpy/core/include/./numpy/ndarraytypes.h:1761:0,
                 from /usr/lib/python2.7/site-packages/numpy/core/include/./numpy/ndarrayobject.h:17,
                 from /usr/lib/python2.7/site-packages/numpy/core/include/./numpy/arrayobject.h:4,
                 from PyMca/Object3D/Object3DQhull/Object3DQhull.c:5:
/usr/lib/python2.7/site-packages/numpy/core/include/./numpy/npy_1_7_deprecated_api.h:15:2: warning: #warning "Using deprecated NumPy API, disable it by " "#defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
 #warning "Using deprecated NumPy API, disable it by " \
  ^
PyMca/Object3D/Object3DQhull/Object3DQhull.c:7:22: fatal error: libqhull.h: No such file or directory
 #include "libqhull.h"

Comment 12 Ralf Corsepius 2014-07-10 13:48:57 UTC
May-be you should improve your "C"-skills?

Patching pymca to let it compile against Fedora's qhull is pretty simply.

c.f. https://bugzilla.redhat.com/attachment.cgi?id=917083

Wrt. upgrading qhull: I am still very hesitant to upgrade.
If I should do so, I'll probably only upgrade rawhide only and not Fedora < 22.

Comment 13 Christopher Meng 2014-07-10 14:00:45 UTC
(In reply to Ralf Corsepius from comment #12)
> May-be you should improve your "C"-skills?
> 
> Patching pymca to let it compile against Fedora's qhull is pretty simply.
> 
> c.f. https://bugzilla.redhat.com/attachment.cgi?id=917083
> 
> Wrt. upgrading qhull: I am still very hesitant to upgrade.
> If I should do so, I'll probably only upgrade rawhide only and not Fedora <
> 22.

I don't think you have any qualifications to ask me to improve my C skills.(and the issue here is nothing relevant to C, only header path changes) No need to use your sarcastic tongue with me.

Regarding which Fedora version, that's not important, I just want the fix from the right package instead of letting other packages to carry a lot of patches.

Comment 14 Ralf Corsepius 2016-06-23 16:25:51 UTC
qhull-2015.2 now is in rawhide/f25.

I do not intend to upgrade fedora < 25 to a newer version.


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