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:
The tarball is now called RC2: http://www.paraview.org/files/v3.8/ParaView-3.8.0-RC2.tar.gz
It is now 3.8.0 officially.
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
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.
Created attachment 236003 [details] error log and some info
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 >
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).
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). >
(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
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 >
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.
(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?
(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.
Created attachment 245575 [details] Files for comment 13
(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.
(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.
(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
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
(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.
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)
(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.
Compiles and works. Thanks.
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.
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.
(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.
(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?
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. >
(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?
(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
OK, can you attach the output of "equery f paraview" so I can the list of files you get with 3.8.1 ?
(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
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.
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.
(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.
(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.
(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.
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?
(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/
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.
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.
New version in overlay.
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.
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?
Thanks for that. I should have removed these. Indeed I just received the message that 3.10 is out.
*** Bug 362169 has been marked as a duplicate of this bug. ***
It there any progress on bringing the new version to the tree?
(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.
What overlay would that be though?
(In reply to comment #48) > What overlay would that be though? science but I haven't found time yet, sorry.
(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
(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
(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.
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?
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.
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.
(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.
Good to hear all these positive reports. I'll investigate the plugin search path. Where do you install the openFoam reader?
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.
(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?
(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?
(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.
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.
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.
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.
3.14.1 in science overlay.
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.
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.
Add ftgl.
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.
(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?
used the postscript flag rather than ps since it exists.
(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.
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.
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.
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.
*** Bug 406179 has been marked as a duplicate of this bug. ***
+*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.
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....
yeah, proxy maintainers welcome^^
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.
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.
+ 13 Feb 2013; Julian Ospald <hasufell@gentoo.org> paraview-3.98.0.ebuild: + fix gl2ps dep