Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 317345 - sci-visualization/paraview-3.98.0 version bump
Summary: sci-visualization/paraview-3.98.0 version bump
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High enhancement with 1 vote (vote)
Assignee: Gentoo Science Related Packages
URL:
Whiteboard:
Keywords:
: 362169 406179 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-04-26 18:46 UTC by Oliver Borm
Modified: 2013-02-13 12:44 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
error log and some info (paraview-3.8.0_buildLog.txt,1.63 MB, text/plain)
2010-06-20 08:44 UTC, luca
Details
Files for comment 13 (paraviewProblems.zip,53.87 KB, application/octet-stream)
2010-09-01 11:21 UTC, Bluey The Dog
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Oliver Borm 2010-04-26 18:46:59 UTC
A new version bump is available:

http://www.paraview.org/files/v3.8/ParaView-3.8.0-RC1.tar.gz

It is not clear to me why they are calling the tarball RC1 but on the website as stable release.

Reproducible: Always

Steps to Reproduce:
Comment 1 Thomas 2010-05-09 20:39:23 UTC
The tarball is now called RC2:
http://www.paraview.org/files/v3.8/ParaView-3.8.0-RC2.tar.gz
Comment 2 François Bissey 2010-05-28 11:26:21 UTC
It is now 3.8.0 officially.
Comment 3 Jan Boros 2010-06-01 07:41:07 UTC
I did donwload 3.8.0 and using for few days already
looks stable
please, can someone update portage tree and insert this build
thanks
Comment 4 François Bissey 2010-06-11 22:41:07 UTC
A preliminary version is now in the science overlay.
It is package masked, so you will have to unmask it to use it.
Feedback is particularly welcome on the following fronts:
amd64
mpi
adaptive paraview client

Three notes:
I currently have problems running the paraview client at all #321805
so any testing is good.
The included vtk-5.6.0 is still built as it is extremely complicated
to remove it and after a first go I decided to have something out first.
The Overview application has been removed and its functionality will be
integrated in a future release.
Comment 5 luca 2010-06-20 08:44:36 UTC
Created attachment 236003 [details]
error log and some info
Comment 6 luca 2010-06-20 08:49:41 UTC
For me the ebuild proposed through the science overlay does not work, compilation stops at 100%, apparently without any useful information. 
I have posted the build log with some other infos, i hope i have done a fair thing posting here as attachment my log! sorry if it is not..

> Created an attachment (id=236003) [details]
> error log and some info
> 

Comment 7 François Bissey 2010-06-20 09:53:40 UTC
You could have compressed your build log luca. But apart from that it is 
extremely useful.
Our old friend mpi/hdf5 bug is back from paraview-3.6.x I'll try to get it fixed
in short order. I was afraid there would be a problem finding hdf5 on
amd64 but didn't expect to see that one back.
On an unrelated matter could you tell me personally how the sage ebuild
works for you (you are using python-2.6.5-r99 - I wrote that for sage).
Comment 8 luca 2010-06-20 10:38:25 UTC
might work to compile without MPI support? I does not use mpi now, so i could try disabling it.

let me know if I can be useful in some other way...


(In reply to comment #7)
> You could have compressed your build log luca. But apart from that it is 
> extremely useful.
> Our old friend mpi/hdf5 bug is back from paraview-3.6.x I'll try to get it
> fixed
> in short order. I was afraid there would be a problem finding hdf5 on
> amd64 but didn't expect to see that one back.
> On an unrelated matter could you tell me personally how the sage ebuild
> works for you (you are using python-2.6.5-r99 - I wrote that for sage).
> 

Comment 9 François Bissey 2010-06-20 10:45:18 UTC
(In reply to comment #8)
> might work to compile without MPI support? I does not use mpi now, so i could
> try disabling it.
> 
That would probably work but it need to be fixed.
I committed a fix used in paraview-3.6.2 if you would be so kind to try it.

Francois
Comment 10 luca 2010-06-20 13:10:35 UTC
With the patch paraview compiled fine!
thank you Francois.

(In reply to comment #9)
> (In reply to comment #8)
> > might work to compile without MPI support? I does not use mpi now, so i could
> > try disabling it.
> > 
> That would probably work but it need to be fixed.
> I committed a fix used in paraview-3.6.2 if you would be so kind to try it.
> 
> Francois
> 

Comment 11 Bluey The Dog 2010-09-01 07:33:43 UTC
I'm attempting to install paraview V3.8 from the science overlay along with QT V4.7 from the qting-edge overlay. The qt install went fine and appears to be working correctly. When I attempt to emerge paraview, the ebuild starts off doing its checking for int's etc and then dies with the error:

************

CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
QT_QTASSISTANTCLIENT_INCLUDE_DIR (ADVANCED)
   used as include directory in directory /var/tmp/portage/sci-visualization/paraview-3.8.0/work/ParaView-3.8.0/Qt/ApplicationComponents

************

Is this a paraview ebuild problem or something else? I've posted something regarding this on the gentoo forums thread which covers the QT overlay but no-one have replied. If it's a paraview problem, let me know and I can then post logs files and the like. This is on amd64.
Comment 12 François Bissey 2010-09-01 09:03:25 UTC
(In reply to comment #11)
> I'm attempting to install paraview V3.8 from the science overlay along with QT
> V4.7 from the qting-edge overlay. The qt install went fine and appears to be
> working correctly. When I attempt to emerge paraview, the ebuild starts off
> doing its checking for int's etc and then dies with the error:
> 
> ************
> 
> CMake Error: The following variables are used in this project, but they are set
> to NOTFOUND.
> Please set them or make sure they are set and tested correctly in the CMake
> files:
> QT_QTASSISTANTCLIENT_INCLUDE_DIR (ADVANCED)
>    used as include directory in directory
> /var/tmp/portage/sci-visualization/paraview-3.8.0/work/ParaView-3.8.0/Qt/ApplicationComponents
> 
> ************
> 
> Is this a paraview ebuild problem or something else? I've posted something
> regarding this on the gentoo forums thread which covers the QT overlay but
> no-one have replied. If it's a paraview problem, let me know and I can then
> post logs files and the like. This is on amd64.
> 
Hi,

Well I am not sure. I haven't seen anything about that on the paraview mailing
list. I may have a look at the git repo to see if there is anything there.
In the meantime could you attach the output of "equery f qt-assistant" so
I can see the files installed in 4.7.
As a side question, did you try to build vtk-5.6.0 with the qt bindings?
Comment 13 Bluey The Dog 2010-09-01 11:20:10 UTC
(In reply to comment #12)
> (In reply to comment #11)

[snip]
...
...
[snip]

Francois,
    Thank you for your reply. Requested info is further down

> > 
> Hi,
> 
> Well I am not sure. I haven't seen anything about that on the paraview mailing
> list. I may have a look at the git repo to see if there is anything there.
> In the meantime could you attach the output of "equery f qt-assistant" so
> I can see the files installed in 4.7.

agl@bluey ~ $ equery f qt-assistant
 * Searching for qtassistant ...
 * Contents of x11-libs/qt-assistant-4.7.0_rc1:
/usr
/usr/bin
/usr/bin/assistant
/usr/bin/pixeltool
/usr/bin/qcollectiongenerator
/usr/bin/qdoc3
/usr/bin/qhelpconverter
/usr/bin/qhelpgenerator
/usr/include
/usr/include/qt4
/usr/include/qt4/Qt
/usr/include/qt4/Qt/QtHelp
/usr/include/qt4/Qt/qhelp_global.h
/usr/include/qt4/Qt/qhelpcontentwidget.h
/usr/include/qt4/Qt/qhelpengine.h
/usr/include/qt4/Qt/qhelpenginecore.h
/usr/include/qt4/Qt/qhelpindexwidget.h
/usr/include/qt4/Qt/qhelpsearchengine.h
/usr/include/qt4/Qt/qhelpsearchquerywidget.h
/usr/include/qt4/Qt/qhelpsearchresultwidget.h
/usr/include/qt4/QtHelp
/usr/include/qt4/QtHelp/QHelpContentItem
/usr/include/qt4/QtHelp/QHelpContentModel
/usr/include/qt4/QtHelp/QHelpContentWidget
/usr/include/qt4/QtHelp/QHelpEngine
/usr/include/qt4/QtHelp/QHelpEngineCore                                                                                                                                               
/usr/include/qt4/QtHelp/QHelpGlobal                                                                                                                                                   
/usr/include/qt4/QtHelp/QHelpIndexModel                                                                                                                                               
/usr/include/qt4/QtHelp/QHelpIndexWidget                                                                                                                                              
/usr/include/qt4/QtHelp/QHelpSearchEngine                                                                                                                                             
/usr/include/qt4/QtHelp/QHelpSearchQuery                                                                                                                                              
/usr/include/qt4/QtHelp/QHelpSearchQueryWidget                                                                                                                                        
/usr/include/qt4/QtHelp/QHelpSearchResultWidget                                                                                                                                       
/usr/include/qt4/QtHelp/QtHelp                                                                                                                                                        
/usr/include/qt4/QtHelp/qhelp_global.h                                                                                                                                                
/usr/include/qt4/QtHelp/qhelpcontentwidget.h                                                                                                                                          
/usr/include/qt4/QtHelp/qhelpengine.h                                                                                                                                                 
/usr/include/qt4/QtHelp/qhelpenginecore.h                                                                                                                                             
/usr/include/qt4/QtHelp/qhelpindexwidget.h                                                                                                                                            
/usr/include/qt4/QtHelp/qhelpsearchengine.h                                                                                                                                           
/usr/include/qt4/QtHelp/qhelpsearchquerywidget.h                                                                                                                                      
/usr/include/qt4/QtHelp/qhelpsearchresultwidget.h                                                                                                                                     
/usr/lib64                                                                                                                                                                            
/usr/lib64/pkgconfig                                                                                                                                                                  
/usr/lib64/pkgconfig/QtCLucene.pc                                                                                                                                                     
/usr/lib64/pkgconfig/QtHelp.pc                                                                                                                                                        
/usr/lib64/qt4
/usr/lib64/qt4/libQtCLucene.prl
/usr/lib64/qt4/libQtCLucene.so -> libQtCLucene.so.4.7.0
/usr/lib64/qt4/libQtCLucene.so.4 -> libQtCLucene.so.4.7.0
/usr/lib64/qt4/libQtCLucene.so.4.7 -> libQtCLucene.so.4.7.0
/usr/lib64/qt4/libQtCLucene.so.4.7.0
/usr/lib64/qt4/libQtHelp.prl
/usr/lib64/qt4/libQtHelp.so -> libQtHelp.so.4.7.0
/usr/lib64/qt4/libQtHelp.so.4 -> libQtHelp.so.4.7.0
/usr/lib64/qt4/libQtHelp.so.4.7 -> libQtHelp.so.4.7.0
/usr/lib64/qt4/libQtHelp.so.4.7.0
/usr/share
/usr/share/applications
/usr/share/applications/_usr_bin_assistant-qt-assistant-4.desktop
/usr/share/doc
/usr/share/doc/qt-4.7.0_rc1
/usr/share/doc/qt-4.7.0_rc1/qch
/usr/share/doc/qt-4.7.0_rc1/qch/assistant.qch
/usr/share/doc/qt-4.7.0_rc1/qch/designer.qch
/usr/share/doc/qt-4.7.0_rc1/qch/linguist.qch
/usr/share/doc/qt-4.7.0_rc1/qch/qmake.qch
/usr/share/doc/qt-4.7.0_rc1/qch/qml.qch
/usr/share/doc/qt-4.7.0_rc1/qch/qt.qch
/usr/share/pixmaps
/usr/share/pixmaps/assistant.png

> As a side question, did you try to build vtk-5.6.0 with the qt bindings?
> 
    I haven't installed VTK myself, I assumed Paraview would pull it in as a part of the emerge. Pretending to emerge VTK results in the following:

[ebuild  N    ] sci-libs/vtk-5.6.0-r2  USE="boost examples mpi python qt4 theora -R -cg -doc -ffmpeg -java -mysql -odbc -patented -postgres -tcl -threads -tk"

I've also attached my build logs etc.
Comment 14 Bluey The Dog 2010-09-01 11:21:27 UTC
Created attachment 245575 [details]
Files for comment 13
Comment 15 François Bissey 2010-09-01 11:26:28 UTC
(In reply to comment #13)
>     I haven't installed VTK myself, I assumed Paraview would pull it in as a
> part of the emerge. Pretending to emerge VTK results in the following:
> 
Unfortunately, paraview bundles its own copy of vtk-5.6 and removing it is
a difficult problem. Last I looked no linux distro shipping paraview have
done it (but I should check the latest fedora, we never know).

Will look at you log - thanks.
Comment 16 François Bissey 2010-09-01 11:55:27 UTC
(In reply to comment #13)
> agl@bluey ~ $ equery f qt-assistant
>  * Searching for qtassistant ...
>  * Contents of x11-libs/qt-assistant-4.7.0_rc1:
> /usr
> /usr/bin
> /usr/bin/assistant
> /usr/bin/pixeltool
> /usr/bin/qcollectiongenerator
> /usr/bin/qdoc3
> /usr/bin/qhelpconverter
> /usr/bin/qhelpgenerator
> /usr/include
> /usr/include/qt4
> /usr/include/qt4/Qt
> /usr/include/qt4/Qt/QtHelp
> /usr/include/qt4/Qt/qhelp_global.h
> /usr/include/qt4/Qt/qhelpcontentwidget.h
> /usr/include/qt4/Qt/qhelpengine.h
> /usr/include/qt4/Qt/qhelpenginecore.h
> /usr/include/qt4/Qt/qhelpindexwidget.h
> /usr/include/qt4/Qt/qhelpsearchengine.h
> /usr/include/qt4/Qt/qhelpsearchquerywidget.h
> /usr/include/qt4/Qt/qhelpsearchresultwidget.h
> /usr/include/qt4/QtHelp
> /usr/include/qt4/QtHelp/QHelpContentItem
> /usr/include/qt4/QtHelp/QHelpContentModel
> /usr/include/qt4/QtHelp/QHelpContentWidget
> /usr/include/qt4/QtHelp/QHelpEngine
> /usr/include/qt4/QtHelp/QHelpEngineCore                                         
> /usr/include/qt4/QtHelp/QHelpGlobal                                             
> /usr/include/qt4/QtHelp/QHelpIndexModel                                         
> /usr/include/qt4/QtHelp/QHelpIndexWidget                                        
> /usr/include/qt4/QtHelp/QHelpSearchEngine                                       
> /usr/include/qt4/QtHelp/QHelpSearchQuery                                        
> /usr/include/qt4/QtHelp/QHelpSearchQueryWidget                                  
> /usr/include/qt4/QtHelp/QHelpSearchResultWidget                                 
> /usr/include/qt4/QtHelp/QtHelp                                                  
> /usr/include/qt4/QtHelp/qhelp_global.h                                          
> /usr/include/qt4/QtHelp/qhelpcontentwidget.h                                    
> /usr/include/qt4/QtHelp/qhelpengine.h                                           
> /usr/include/qt4/QtHelp/qhelpenginecore.h                                       
> /usr/include/qt4/QtHelp/qhelpindexwidget.h                                      
> /usr/include/qt4/QtHelp/qhelpsearchengine.h                                     
> /usr/include/qt4/QtHelp/qhelpsearchquerywidget.h                                
> /usr/include/qt4/QtHelp/qhelpsearchresultwidget.h                               
> /usr/lib64                                                                      
> /usr/lib64/pkgconfig                                                            
> /usr/lib64/pkgconfig/QtCLucene.pc                                               
> /usr/lib64/pkgconfig/QtHelp.pc                                                  
> /usr/lib64/qt4
> /usr/lib64/qt4/libQtCLucene.prl
> /usr/lib64/qt4/libQtCLucene.so -> libQtCLucene.so.4.7.0
> /usr/lib64/qt4/libQtCLucene.so.4 -> libQtCLucene.so.4.7.0
> /usr/lib64/qt4/libQtCLucene.so.4.7 -> libQtCLucene.so.4.7.0
> /usr/lib64/qt4/libQtCLucene.so.4.7.0
> /usr/lib64/qt4/libQtHelp.prl
> /usr/lib64/qt4/libQtHelp.so -> libQtHelp.so.4.7.0
> /usr/lib64/qt4/libQtHelp.so.4 -> libQtHelp.so.4.7.0
> /usr/lib64/qt4/libQtHelp.so.4.7 -> libQtHelp.so.4.7.0
> /usr/lib64/qt4/libQtHelp.so.4.7.0
> /usr/share
> /usr/share/applications
> /usr/share/applications/_usr_bin_assistant-qt-assistant-4.desktop
> /usr/share/doc
> /usr/share/doc/qt-4.7.0_rc1
> /usr/share/doc/qt-4.7.0_rc1/qch
> /usr/share/doc/qt-4.7.0_rc1/qch/assistant.qch
> /usr/share/doc/qt-4.7.0_rc1/qch/designer.qch
> /usr/share/doc/qt-4.7.0_rc1/qch/linguist.qch
> /usr/share/doc/qt-4.7.0_rc1/qch/qmake.qch
> /usr/share/doc/qt-4.7.0_rc1/qch/qml.qch
> /usr/share/doc/qt-4.7.0_rc1/qch/qt.qch
> /usr/share/pixmaps
> /usr/share/pixmaps/assistant.png
> 
Ok it looks like you are missing files that paraview is looking for.
In qt-assistant-4.6 we have also:
/usr/include/qt4/QtAssistant
/usr/include/qt4/QtAssistant/QAssistantClient
/usr/include/qt4/QtAssistant/QtAssistant
/usr/include/qt4/QtAssistant/qassistantclient.h
/usr/include/qt4/QtAssistant/qassistantclient_global.h
and 
/usr/lib/pkgconfig/QtAssistantClient.pc

And the variable paraview asks for is set by FindQt4.cmake shipped
with cmake:
  # Set QT_QTASSISTANT_INCLUDE_DIR
  FIND_PATH(QT_QTASSISTANT_INCLUDE_DIR QtAssistant
    PATHS
    ${QT_HEADERS_DIR}/QtAssistant
    ${QT_LIBRARY_DIR}/QtAssistant.framework/Headers
    NO_DEFAULT_PATH
    )

Of course it looks for one of the files you are missing.
Either this is a bug (or setting) in qt-assistant and you are genuinely
missing these files or paraview will need porting to Qt-4.7.
I haven't found any activity related to Qt-4.7 in the logs of the git server
for paraview.
Comment 17 Bluey The Dog 2010-09-01 12:27:49 UTC
(In reply to comment #16)
> (In reply to comment #13)
> > agl@bluey ~ $ equery f qt-assistant
> >  * Searching for qtassistant ...
> >  * Contents of x11-libs/qt-assistant-4.7.0_rc1:
> > /usr
> > /usr/bin
> > /usr/bin/assistant
[snip]
...
...
[snip]
> > 
> Ok it looks like you are missing files that paraview is looking for.
> In qt-assistant-4.6 we have also:
> /usr/include/qt4/QtAssistant
> /usr/include/qt4/QtAssistant/QAssistantClient
> /usr/include/qt4/QtAssistant/QtAssistant
> /usr/include/qt4/QtAssistant/qassistantclient.h
> /usr/include/qt4/QtAssistant/qassistantclient_global.h
> and 
> /usr/lib/pkgconfig/QtAssistantClient.pc
> 
> And the variable paraview asks for is set by FindQt4.cmake shipped
> with cmake:
>   # Set QT_QTASSISTANT_INCLUDE_DIR
>   FIND_PATH(QT_QTASSISTANT_INCLUDE_DIR QtAssistant
>     PATHS
>     ${QT_HEADERS_DIR}/QtAssistant
>     ${QT_LIBRARY_DIR}/QtAssistant.framework/Headers
>     NO_DEFAULT_PATH
>     )
> 
> Of course it looks for one of the files you are missing.
> Either this is a bug (or setting) in qt-assistant and you are genuinely
> missing these files or paraview will need porting to Qt-4.7.
> I haven't found any activity related to Qt-4.7 in the logs of the git server
> for paraview.
> 

Thanks for that Francois, I'll go back to the QT 4.7 forum thread and let them know and ask if they have accidentally left out the files in question. 

I just had a "google" for the words "paraview" and "qt 4.7" and from what I see, 4.7 won't be supported for a while so I suppose my "bug" is closed for the time being. Once again, thanks for looking into this.

     Andrew
Comment 18 Oliver Borm 2010-10-10 15:21:12 UTC
I've tested the version from the science overlay and it built and worked ok for me.

There is now also a bugfix release paraview 3.8.1 available:
http://www.paraview.org/files/v3.8/ParaView-3.8.1.tar.gz
Comment 19 François Bissey 2010-10-10 18:05:38 UTC
(In reply to comment #18)
> I've tested the version from the science overlay and it built and worked ok for
> me.
> 
> There is now also a bugfix release paraview 3.8.1 available:
> http://www.paraview.org/files/v3.8/ParaView-3.8.1.tar.gz
> 
I am aware of this. I have been extremely busy working on sage but
I am hoping to bump this to 3.8.1 sometimes this week.

Comment 20 Sebastian Held 2010-10-12 10:04:56 UTC
Portage 2.2_rc94 gives the following error:

# emerge '>=paraview-3.8.0'
Calculating dependencies... done!

!!! All ebuilds that could satisfy ">=paraview-3.8.0" have been masked.
!!! One of the following masked packages is required to complete your request:
- sci-visualization/paraview-3.8.0::science (masked by: invalid: DEPEND: USE flag 'boost' referenced in conditional 'boost?' is not in IUSE)
Comment 21 François Bissey 2010-10-12 10:19:38 UTC
(In reply to comment #20)
> Portage 2.2_rc94 gives the following error:
> 
> # emerge '>=paraview-3.8.0'
> Calculating dependencies... done!
> 
> !!! All ebuilds that could satisfy ">=paraview-3.8.0" have been masked.
> !!! One of the following masked packages is required to complete your request:
> - sci-visualization/paraview-3.8.0::science (masked by: invalid: DEPEND: USE
> flag 'boost' referenced in conditional 'boost?' is not in IUSE)
> 
Fixed. I also moved to qt4-r2 eclass, tell me if that creates any problems for you.

There is a bit too much crunch here for me to bump this to 3.8.1 this week.
It is on my TODO list once I have more time.

Comment 22 Sebastian Held 2010-10-12 12:37:19 UTC
Compiles and works. Thanks.
Comment 23 François Bissey 2010-10-26 22:17:00 UTC
I am preparing 3.8.1, it should hit the overlay later this week.
3.10 is scheduled for the end of November and 3.10.1 for around Christmas.
Comment 24 François Bissey 2010-10-27 08:41:12 UTC
3.8.1 is now in the overlay. It compiles here. I change the dependency to address building against qt-4.7, it should now work.
I don't know if bug #338826 (problems with python 2.7) is addressed in this release, feedback on the matter appreciated. 
It still bundles vtk I may have time to work seriously on that again soon.
Comment 25 Oliver Borm 2010-10-28 12:11:51 UTC
(In reply to comment #24)
> 3.8.1 is now in the overlay. It compiles here. 

I get the following error, when running paraview-3.8.1 from the science overlay:

# /usr/bin/paraview
Error running "/usr/lib64/paraview-3.8/paraview": Permission denied

because /usr/lib64/paraview-3.8/paraview is now a directory. But 

/usr/lib64/paraview-3.8/paraview.backup.0000

is an executable.
Comment 26 François Bissey 2010-10-28 19:33:09 UTC
(In reply to comment #25)
> (In reply to comment #24)
> > 3.8.1 is now in the overlay. It compiles here. 
> 
> I get the following error, when running paraview-3.8.1 from the science
> overlay:
> 
> # /usr/bin/paraview
> Error running "/usr/lib64/paraview-3.8/paraview": Permission denied
> 
> because /usr/lib64/paraview-3.8/paraview is now a directory. But 
> 
> /usr/lib64/paraview-3.8/paraview.backup.0000
> 
> is an executable.
> 
hum looks like they are still messing up with lib64, possibly in new ways.
I will have a look later today.
Would it help if I was putting back 3.8.0 for you?
Comment 27 luca 2010-11-20 18:22:33 UTC
same error for me...
has anybody tried if the 3.8.0 works or if it gives the same error?
in that case i would emerge the 3.8.0 version...

(In reply to comment #25)
> (In reply to comment #24)
> > 3.8.1 is now in the overlay. It compiles here. 
> 
> I get the following error, when running paraview-3.8.1 from the science
> overlay:
> 
> # /usr/bin/paraview
> Error running "/usr/lib64/paraview-3.8/paraview": Permission denied
> 
> because /usr/lib64/paraview-3.8/paraview is now a directory. But 
> 
> /usr/lib64/paraview-3.8/paraview.backup.0000
> 
> is an executable.
> 

Comment 28 François Bissey 2010-11-20 18:58:56 UTC
(In reply to comment #27)
> same error for me...
> has anybody tried if the 3.8.0 works or if it gives the same error?
> in that case i would emerge the 3.8.0 version...
> 
Try 3.8.0, 3.8.1 has so many issues for a bug fix it is not funny.
I should pull it out and wait for the next release. However I didn't 
have the particular problem you guys get. What are your useflags?
Comment 29 luca 2010-11-20 19:35:34 UTC
(In reply to comment #28)

> However I didn't 
> have the particular problem you guys get. What are your useflags?

all useflags are active for me,  but cg and examples
Comment 30 François Bissey 2010-11-20 20:30:41 UTC
OK, can you attach the output of "equery f paraview" so I can the list of files
you get with 3.8.1 ? 
Comment 31 luca 2010-11-20 20:42:46 UTC
(In reply to comment #30)
> OK, can you attach the output of "equery f paraview" so I can the list of files
> you get with 3.8.1 ? 
> 

http://pastebin.com/2DyCgq9b
Comment 32 François Bissey 2010-11-20 20:53:57 UTC
thanks! I am starting to have some ideas, unfortunately that may have to wait a little bit to be put to work as I am relocating next week.
I am also noticing paraview is shipping its own mpi4py which will have to be dealt with amongst other thing.
Comment 33 Oliver Borm 2010-11-30 19:17:23 UTC
The *.backup.0000 seem to be a general portage problem. They seem to appear if some files/directories are not under the version control of portage. Some examples:

x11-libs/qt-phonon-4.6.2: http://forums.gentoo.org/viewtopic-p-6208563.html#6208563
app-misc/fdutils-5.5-r1: bug 328789

In order to install paraview-3.8.1 successful just uninstall paraview completely (emerge -C paraview) and make sure directory /usr/lib/paraview-3.8 is longer present! If not delete it and all it's contest by hand (rm -rf /usr/lib/paraview-3.8). Afterward just install paraview-3.8.1 as normal.

@Francois: I've just committed a new paraview-3.8.1 ebuild to the science overlay, which installs a patched OpenFOAM reader. As the default one has some problems in reading decomposed cases.
Comment 34 François Bissey 2010-12-01 20:44:36 UTC
(In reply to comment #33)
> The *.backup.0000 seem to be a general portage problem. They seem to appear if
> some files/directories are not under the version control of portage. Some
> examples:
> 
> x11-libs/qt-phonon-4.6.2:
> http://forums.gentoo.org/viewtopic-p-6208563.html#6208563
> app-misc/fdutils-5.5-r1: bug 328789
> 
> In order to install paraview-3.8.1 successful just uninstall paraview
> completely (emerge -C paraview) and make sure directory /usr/lib/paraview-3.8
> is longer present! If not delete it and all it's contest by hand (rm -rf
> /usr/lib/paraview-3.8). Afterward just install paraview-3.8.1 as normal.
> 
> @Francois: I've just committed a new paraview-3.8.1 ebuild to the science
> overlay, which installs a patched OpenFOAM reader. As the default one has some
> problems in reading decomposed cases.
> 
Thanks Oliver,

that could remnant from paraview's own python files. We will probably need to
make sure they are gone in pkg_postrm (or whatever it is called).
Does your resulting paraview install some qt4 libs? (supposing you are using the GUI
and if not does it starts at all).

I am still without a Gentoo box atm, and since I'll get a new machine soon it is not worth
my time installing prefix on this mac to test stuff. And of course the new job has to come first.
Comment 35 Oliver Borm 2010-12-02 19:04:18 UTC
(In reply to comment #34)
> Does your resulting paraview install some qt4 libs? (supposing you are using
> the GUI
> and if not does it starts at all).

Yes the GUI starts without any problems. I'm not sure if additional qt4 libs get installed, this is a list of so files with an qt string:

63:/usr/lib64/paraview-3.8/libQtPython.so
64:/usr/lib64/paraview-3.8/libQtTesting.so
162:/usr/lib64/paraview-3.8/libvtkQtChart.so
163:/usr/lib64/paraview-3.8/libvtkQtChart.so.pv3.8

Additionally, would it be possible to install also the cmake stuff, in order to be able to compile additional external plugins for paraview after was installed? I think the actual debian package at ubuntu does this already.
Comment 36 François Bissey 2010-12-02 20:58:18 UTC
(In reply to comment #35)
> (In reply to comment #34)
> > Does your resulting paraview install some qt4 libs? (supposing you are using
> > the GUI
> > and if not does it starts at all).
> 
> Yes the GUI starts without any problems. I'm not sure if additional qt4 libs
> get installed, this is a list of so files with an qt string:
> 
> 63:/usr/lib64/paraview-3.8/libQtPython.so
> 64:/usr/lib64/paraview-3.8/libQtTesting.so
> 162:/usr/lib64/paraview-3.8/libvtkQtChart.so
> 163:/usr/lib64/paraview-3.8/libvtkQtChart.so.pv3.8
> 
> Additionally, would it be possible to install also the cmake stuff, in order to
> be able to compile additional external plugins for paraview after was
> installed? I think the actual debian package at ubuntu does this already.
> 
That's good to know. We need to check if libQtPython and libQtTesting are the duplicate of
anything QT related. vtkQt stuff is almost certainly vtk duplicate stuff but it will be very
complicated to remove.

Installing the cmake files to compile external plugins would certainly be great.
Adding it to the ToDo list.
Comment 37 François Bissey 2010-12-29 08:47:35 UTC
I added a pkg_postrm call in the ebuild to remove rogue python module files
not under portage's control. That would prevent the problems people had when
upgrading from 3.8.0 to 3.8.1 - hopefully.
Any suggestions about these cmake files to build plugins Oliver?
Comment 38 Oliver Borm 2011-01-13 09:49:04 UTC
(In reply to comment #37)
> Any suggestions about these cmake files to build plugins Oliver?
> 
Well not really. I don't know in detail which cmake files are needed in which structure. Maybe a look into the debian package of paraview might help: http://packages.ubuntu.com/natty/paraview

They seem to install the files under /usr/lib/paraview/CMake/
Comment 39 François Bissey 2011-01-31 00:13:51 UTC
Ok some updates. I have a amd64 machine now, so I can test more stuff.
The current ebuild breaks multilib strict so I will have to take care of that
first. I backported the FindPythonLibs.cmake fix to vtk-5.6.1, what it revealed there is that things behave differently after it has been removed. I am not sure
if it is because portage's version is slightly buggy or we should have done something more after the removal. A big symptom is that mayavi won't build because a python file cannot be imported - that's very bad.

So I'll probably re-instate paraview's version of that file. For info vtk misses a fair amount of python modules when you remove FindPythonLibs.cmake (and you have to do some extra magic at the end because it wants to install the file too).
I'll try to have a closer look at those cmake files too.
Comment 40 François Bissey 2011-01-31 03:29:11 UTC
I think I have it almost done. You'll have to check that it has everything you
want Oliver, I have discovered a cmake option called 
PARAVIEW_INSTALL_DEVELOPMENT
which seem to control installation of these files - and probably a little bit more. One of them has to be relocated from /usr/doc before it being 
"main-tree" grade and it looks like it is controlled by PV_INSTALL_DOC_DIR.

I will upload all that in a few hours.
Comment 41 François Bissey 2011-01-31 08:16:52 UTC
New version in overlay.
Comment 42 François Bissey 2011-02-01 09:01:21 UTC
There was a file collision with vtk in the ebuild I posted yesterday.
Fixed now. As a bonus the lproj earlier file collision got solved as well without needing any renaming.
Comment 43 Oliver Borm 2011-03-09 15:24:58 UTC
Removed OFF patch, as I could build this now as an external module, see also bug 358077. So the PARAVIEW_INSTALL_DEVELOPMENT did the job, thanks for figuring this out.

Removed also the lproj renaming warning, because we don't do this any longer. Changes are all in the science overlay.

Maybe it's time now to get this into the main tree, as the next paraview version is already knocking at the door?
Comment 44 François Bissey 2011-03-09 19:09:36 UTC
Thanks for that. I should have removed these. Indeed I just received the message that 3.10 is out.
Comment 45 Justin Lecher (RETIRED) gentoo-dev 2011-04-05 14:30:44 UTC
*** Bug 362169 has been marked as a duplicate of this bug. ***
Comment 46 Luyang Han 2011-05-17 08:52:52 UTC
It there any progress on bringing the new version to the tree?
Comment 47 François Bissey 2011-05-17 11:26:05 UTC
(In reply to comment #46)
> It there any progress on bringing the new version to the tree?

Sorry I have been rather busy (with a baby mainly). To tell you the truth I am glad to have missed the boat on 3.10 given the number of issues reported on the paraview mailing list. I'll try for 3.10.1 in the overlay by the end of the month.
Comment 48 Nico Schlömer 2011-06-08 13:32:26 UTC
What overlay would that be though?
Comment 49 François Bissey 2011-06-08 23:39:31 UTC
(In reply to comment #48)
> What overlay would that be though?
science but I haven't found time yet, sorry.
Comment 50 Nico Schlömer 2011-06-09 21:10:58 UTC
(In reply to comment #49)
> science but I haven't found time yet, sorry.

Ah, too bad; I'd actually need it, and the binary they provide doesn't work for me due to some Python incompatibilities.
Well, just let me know when something's up on science for testing.

Cheers,
Nico
Comment 51 François Bissey 2011-06-09 21:23:00 UTC
(In reply to comment #50)
> (In reply to comment #49)
> > science but I haven't found time yet, sorry.
> 
> Ah, too bad; I'd actually need it, and the binary they provide doesn't work for
> me due to some Python incompatibilities.
> Well, just let me know when something's up on science for testing.
> 
Do you absolutely need 3.10? 3.8.1 won't do?

Francois
Comment 52 Nico Schlömer 2011-06-10 09:02:40 UTC
(In reply to comment #51)
> Do you absolutely need 3.10? 3.8.1 won't do?

Pretty much. I'm working with the Python API which appears to have changed between 3.8 and 3.10, and I need to make sure the code runs on a server where 3.10.1 is installed.
Comment 53 François Bissey 2011-06-16 02:36:14 UTC
OK I have put a first ebuild for 3.10.1 in the science overlay. It seemed to compile and install OK here. Give it a try.

Few issues:
* separation between vtk and paraview takes the back seat again. paraview-3.10 and vtk-5.8 have been branched at the same time but vtk-5.8 has yet to be released.
* there is an internal copy of mpi4py. That probably can be removed without much pain.
* I got a few configuration issues with sip. I have to air it on the paraview mailing list, technically it is a vtk issue but again it is unreleased.
* While we are shipping an internal vtk is there much use in including more than the bare minimum functionalities or are useful features exposed in paraview, like ogg/theora support?
* Does it work with the separate openFoam reader? You can look into that Oliver?
Comment 54 Oliver Borm 2011-06-24 13:19:44 UTC
paraview-3.10.1 is compiling and also seems to work, I have not yet tested the python bindings.

The external OpenFOAM reader is also working as plugin after a manual loading in the plugin management widget, as the search location for plugins seem to have changed.
Comment 55 Oliver Borm 2011-06-24 13:21:36 UTC
For the time being I would like to have both versions 3.8 and 3.10 in the git, that would make a transition a little bit smoother.
Comment 56 Nico Schlömer 2011-06-24 13:22:31 UTC
(In reply to comment #54)
> I have not yet tested the python bindings.

I'm working with Python in ParaView and things seem to work alright.
Comment 57 François Bissey 2011-06-24 13:29:09 UTC
Good to hear all these positive reports. I'll investigate the plugin search path. Where do you install the openFoam reader?
Comment 58 Oliver Borm 2011-06-24 13:42:15 UTC
The OpenFOAM plugin is installed at

/usr/lib64/paraview-3.8/plugins

but in 3.10 the search path seems to be, as all other plugins are also located there

/usr/lib64/paraview-3.10

So I think I have to change the vtkPOFFReader ebuild.
Comment 59 François Bissey 2011-06-25 05:05:00 UTC
(In reply to comment #58)
> The OpenFOAM plugin is installed at
> 
> /usr/lib64/paraview-3.8/plugins
> 
> but in 3.10 the search path seems to be, as all other plugins are also located
> there
> 
> /usr/lib64/paraview-3.10
> 
> So I think I have to change the vtkPOFFReader ebuild.

We could set the location of the plugin directory with a choice of our own. From CMake/ParaViewCommon.cmake: 

IF(NOT PV_INSTALL_PLUGIN_DIR)
  IF(WIN32)
    SET(PV_INSTALL_PLUGIN_DIR ${PV_INSTALL_BIN_DIR})
  ELSE(WIN32)
    SET(PV_INSTALL_PLUGIN_DIR ${PV_INSTALL_LIB_DIR})
  ENDIF(WIN32)
ENDIF(NOT PV_INSTALL_PLUGIN_DIR)

because we don't set PV_INSTALL_PLUGIN_DIR we end up installing plugins in PV_INSTALL_LIB_DIR. We could set this to something that makes more sense in Gentoo. Any suggestions apart from:
$PV_INSTALL_LIB_DIR/plugins
/usr/share/paraview/plugins <- that would mean we can keep the location across paraview versions.

Actually this little file (CMake/ParaViewCommon.cmake) is fascinating I should check where stuff currently install and whether I could put it in a better location.

Would it help for example if the cmake files where installed in /usr/share/paraview/CMake rather than $PV_INSTALL_LIB_DIR/CMake?
Comment 60 Oliver Borm 2011-06-27 19:14:05 UTC
(In reply to comment #59)
> 
> $PV_INSTALL_LIB_DIR/plugins
> /usr/share/paraview/plugins <- that would mean we can keep the location across
> paraview versions.

As the plugins are linked to the paraview libraries, like libvtkGraphics.so.pv3.8, they need to be recompiled anyway. So $PV_INSTALL_LIB_DIR/plugins should just be fine.

> Would it help for example if the cmake files where installed in
> /usr/share/paraview/CMake rather than $PV_INSTALL_LIB_DIR/CMake?

As I need to set the cmake path anyway in the plugin ebuild, I don't really care about the location, I just need to know where they are installed. On the other hand the question might be, is there a 'correct' location / gentoo specific rule, where to place cmake files?
Comment 61 François Bissey 2011-06-27 19:48:15 UTC
(In reply to comment #60)
> (In reply to comment #59)
> > 
> > $PV_INSTALL_LIB_DIR/plugins
> > /usr/share/paraview/plugins <- that would mean we can keep the location across
> > paraview versions.
> 
> As the plugins are linked to the paraview libraries, like
> libvtkGraphics.so.pv3.8, they need to be recompiled anyway. So
> $PV_INSTALL_LIB_DIR/plugins should just be fine.
> 

I was thinking it would be easier to set the installation path in the ebuild but that may be irrelevant. I also don't plan to slot paraview so there is no hope that you can install plugins for two different versions. But I should add a post install message about the need to rebuild plugins when you upgrade paraview.

> > Would it help for example if the cmake files where installed in
> > /usr/share/paraview/CMake rather than $PV_INSTALL_LIB_DIR/CMake?
> 
> As I need to set the cmake path anyway in the plugin ebuild, I don't really
> care about the location, I just need to know where they are installed. On the
> other hand the question might be, is there a 'correct' location / gentoo
> specific rule, where to place cmake files?

I am not sure but cmake put them into /usr/share/cmake and at least one package put its file in /usr/share/cmake/${PN}/ (dev-libs/shared-desktop-ontologies-0.5). /usr/share/cmake/paraview seems a good spot.

A quick use of locate shows a variety of places /usr/lib/${PN}/{something} and /usr/share/${PN}{something} seem to be the more common.
Comment 62 François Bissey 2012-02-03 02:57:59 UTC
I am working on paraview-3.12.0, hopefully I will land it in the overlay at the beginning of next week. We are being hit by:
http://paraview.org/Bug/view.php?id=12852
paraview build its own dev-libs/protobuf-2.3.0 (no way to disable it nicely that I can find) and it is getting confused with or without a system one being installed. Not amusing.
I am currently I am testing removing it, so far it breaks parallel building but the build is progressing nicely at -j1.
Comment 63 François Bissey 2012-02-08 01:17:32 UTC
The overlay is back and an ebuild for 3.12.0 is in.

It is a bit ugly right now - I need to polish the protobuf stuff. Comments welcome.
Comment 64 François Bissey 2012-08-28 04:01:37 UTC
I should finally put a paraview 3.14.1 ebuild in the overlay soon. I am doing some finishing touches.
It will have more dependencies and a few options reflecting stuff I see on paraview.org.
It will probably need some more testing after I land it in the science overlay.
It doesn't try to install ffmpeg anymore if enabled and I still need to check if theora filters have been built as well.
I may be able to enable the test suite for real as well.

Stuff in here may also be useful for vtk.
Comment 65 François Bissey 2012-08-28 21:45:53 UTC
3.14.1 in science overlay.
Comment 66 François Bissey 2012-08-30 11:33:00 UTC
The hornet nest this thing is. I have looked at debian and found a patch for gcc 4.7 - welcome. They also have a patch to remove sqlite from it! No one had spotted that in gentoo - this is also in vtk...
I just found out that setting 
PARAVIEW_USE_SYSTEM_HDF5 doesn't imply VTK_USE_SYSTEM_HDF5 and vtkhdf5 is still currently shipped in paraview and used in the internal copy of vtk (fix is easy).
I am trying to untangle the python install to make it work normally but cannot find where the rule are for the python *.so extension.
there are .cmake files all over the place I hope I can tidy that up as well.
Comment 67 François Bissey 2012-08-31 00:24:30 UTC
Grumble. Python module not easily fixable without doing upstream's work. Not sure why we have all those cmake files shipped  - outside of $libidr/paraview-3.14/CMake/.

New bundled dependency spotted in vtk: netcdf, with cxx binding and v4 enabled by default and by the look of livtknetcdf: hdf5.
The other thing that could be considered is trying to use exodus2 from the science overlay instead of the bundled copy but it could be heavily patched.
Comment 68 François Bissey 2012-08-31 01:24:34 UTC
Add ftgl.
Comment 69 Daniel Marmander 2012-09-15 09:50:07 UTC
Useflag ps together with $(cmake-utils_use ps VTK_USE_GL2PS) in the use flag triggered options should be added. Needed for salome-gui to compile.
Comment 70 François Bissey 2012-09-16 10:36:41 UTC
(In reply to comment #69)
> Useflag ps together with $(cmake-utils_use ps VTK_USE_GL2PS) in the use flag
> triggered options should be added. Needed for salome-gui to compile.

ok so VTK_USE_GL2PS and VTK_USE_SYSTEM_GL2PS I presume.
Any other vtk options that should be added?
Comment 71 François Bissey 2012-09-16 10:48:56 UTC
used the postscript flag rather than ps since it exists.
Comment 72 François Bissey 2012-09-17 02:12:45 UTC
(In reply to comment #69)
> Useflag ps together with $(cmake-utils_use ps VTK_USE_GL2PS) in the use flag
> triggered options should be added. Needed for salome-gui to compile.

I just had a look at the salome-gui ebuild. Did you mean to ask for this in the vtk ebuild? Actually the vtk ebuild set VTK_USE_GL2PS but do not use the system gl2ps. Also I see the salome-gui ebuild look at vtk up to version 5.6 while only 5.10.0 is left in the tree.
Comment 73 Daniel Marmander 2012-09-19 20:13:04 UTC
The salome ebuilds are very old. I am updating and version bumping, will post them, as soon as they are ok (there is quite a lot of cleaning to do). It seems like some ebuilds use gl2ps as a flag, and that would be the best one here as well.

If I try to compile salome-gui without the gl2ps flag, it will fail. I am not trying to compile with the vtk flag.

The salome-gui-6.3.1 ebuild contains this code, in order to check for glps:
       if use paraview ; then
               test -e /usr/include/paraview-3.10/vtkGL2PSExporter.h \
                       || die "recompile paraview with -DVTK_USE_GL2PS=on"
       fi

This obviously does not work, and is not the correct way to handle it either. I now have a use-flag requirement instead:

paraview? ( >=sci-visualization/paraview-3.10[gl2ps] )

Thanks for the vtk version info, updated my ebuild with version 5.10.
Comment 74 Daniel Marmander 2012-09-19 20:29:02 UTC
For salome-gui, the VTK_USE_GL2PS is enough. Might be good to include VTK_USE_SYSTEM_GL2PS of other reasons, I have no idea, but it's not needed for salome-gui-6.5.0.
Comment 75 François Bissey 2012-09-19 22:45:43 UTC
I use the system gl2ps as we should. Do I understand that you want me to use gl2ps useflag. I just realised that their was already a use of that flag in opencascade so I guess I should switch anyway.

At the moment I am investigating the visit bridge and using cgnslib-2.5 to read cgns files. The cgns* ebuilds could use some TLC and a bump and possibly a slotting (paraview uses 2.5 and 3.1.3 is out).
At the moment a normal will fail if sip (python) is enabled at the same time because a folder is not created during the build process.
Comment 76 Julian Ospald 2013-02-11 17:02:55 UTC
*** Bug 406179 has been marked as a duplicate of this bug. ***
Comment 77 Julian Ospald 2013-02-11 21:32:31 UTC
+*paraview-3.98.0 (11 Feb 2013)
+
+  11 Feb 2013; Julian Ospald <hasufell@gentoo.org> -paraview-3.6.2.ebuild,
+  -files/paraview-3.6.2-about.html.patch,
+  -files/paraview-3.6.2-assistant.patch,
+  -files/paraview-3.6.2-boost-property_map.patch,
+  -files/paraview-3.6.2-findcg-cmake.patch, -files/paraview-3.6.2-h5part.patch,
+  -files/paraview-3.6.2-hdf-1.8.3.patch, -files/paraview-3.6.2-libpng14.patch,
+  -files/paraview-3.6.2-libpng15.patch,
+  -files/paraview-3.6.2-no-doc-finder.patch, -files/paraview-3.6.2-odbc.patch,
+  -files/paraview-3.6.2-pointsprite-disable.patch,
+  -files/paraview-3.6.2-qt.patch, +paraview-3.98.0.ebuild,
+  +files/paraview-3.98.0-gcc-4.7.patch, +files/paraview-3.98.0-mpi4py.patch,
+  +files/paraview-3.98.0-pvblot.patch,
+  +files/paraview-3.98.0-removesqlite.patch,
+  +files/paraview-3.98.0-vtk-cg-path.patch,
+  +files/paraview-3.98.0-vtknetcd.patch,
+  +files/paraview-3.98.0-xdmf-cstring.patch:
+  version bump wrt #317345



MOOOOOTHER OF GOOOD

I probably wasn't able to test everything, but I compiled with all useflags except mpi successfully. Please post bug reports if you need enhancements or if the useflag logic is flawed. There are way too many configuration options.
Comment 78 François Bissey 2013-02-11 21:58:02 UTC
You are welcome to one of my pet ebuild. Good job because the changes from 3.14 are so drastic. And now someone will ask for 3.98.1....
Comment 79 Julian Ospald 2013-02-11 22:03:39 UTC
yeah, proxy maintainers welcome^^
Comment 80 Alexander Danilov 2013-02-13 07:31:22 UTC
paraview-3.98.0.ebuild should depend on >=x11-libs/gl2ps-1.3.8
Function gl2psTextOptColor was added in recent version of gl2ps, that is why paraview-3.98.0 does not work with (stable) gl2ps-1.3.6.
Comment 81 François Bissey 2013-02-13 08:07:36 UTC
You are absolutely correct - I had noticed when I was experimenting with 3.98.0_rc2. At the time it was unreleased. 

But you should really open a new bug, this one is closed and Julian may rightfully ignore further comments.
Comment 82 Julian Ospald 2013-02-13 12:44:32 UTC
+  13 Feb 2013; Julian Ospald <hasufell@gentoo.org> paraview-3.98.0.ebuild:
+  fix gl2ps dep