Description of problem: Yaf(a)Ray 0.1.0 is a new raytracing render engine written from scratch, and it replaces YafRay 0.0.9. After two years of development, it already features a complete set of lighting and rendering options. http://wiki.yafray.org/bin/view.pl/UserDoc/YafaRay Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Hi Paulo That's really nice to see you participating as a Fedora contributor. You should have a look at https://fedoraproject.org/wiki/PackageMaintainers And specially for the yarafray package: https://fedoraproject.org/wiki/Package_Review_Process I will give you few advices on the yafaray package soon. Jon Ciesla should sponsor you once one (or more) packages will be reviewed and accepted. So it should be fine if you can submit another package to be reviewed.
(In reply to comment #1) > Hi Paulo > > That's really nice to see you participating as a Fedora contributor. > You should have a look at > https://fedoraproject.org/wiki/PackageMaintainers > And specially for the yarafray package: > https://fedoraproject.org/wiki/Package_Review_Process > I will give you few advices on the yafaray package soon. > Jon Ciesla should sponsor you once one (or more) packages will be reviewed and > accepted. So it should be fine if you can submit another package to be > reviewed. Hi, I submitted two more packages: parprouted and litmus https://bugzilla.redhat.com/show_bug.cgi?id=467856 https://bugzilla.redhat.com/show_bug.cgi?id=467854 Thanks for the welcome and guidelines.
Needs links to spec and srpm.
(In reply to comment #3) > Needs links to spec and srpm. Spec URL: http://people.atrpms.net/~pcavalcanti/specs/yafaray.spec SRPM URL: http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-4.fc8.src.rpm
Some Comments: Good: + Local build works fine + Blender scripts are in the right directory: Bad: - Build failed on koji http://koji.fedoraproject.org/koji/taskinfo?taskID=898469 Reason: Wrong BR to libxml-devel, You will need a BR to libxml2-devel. - Rpmlint complaints source rpm $ rpmlint -i yafaray-0.1.0-4.fc9.src.rpm yafaray.src:43: W: rpm-buildroot-usage %prep # fixes %{buildroot} in libyafaraycore.so $RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it will break short circuiting. - Rpmlint warning to yafaray binary rpm: $ rpmlint -i yafaray-0.1.0-4.fc9.x86_64.rpm yafaray.x86_64: W: no-soname /usr/lib64/libyafaraycore.so yafaray.x86_64: W: no-soname /usr/lib64/libyafarayqt.so yafaray.x86_64: W: no-soname /usr/lib64/libyafarayplugin.so 1 packages and 0 specfiles checked; 0 errors, 3 warnings. - Rpmlint complaints yafary-blender rpm: $ rpmlint -i yafaray-blender-0.1.0-4.fc9.x86_64.rpm yafaray-blender.x86_64: W: no-documentation The package contains no documentation (README, doc, etc). You have to include documentation files. yafaray-blender.x86_64: E: wrong-script-interpreter /usr/share/blender/scripts/yaf_export.py "BPY" This script uses an incorrect interpreter. yafaray-blender.x86_64: E: non-executable-script /usr/share/blender/scripts/yaf_export.py 0644 This text file contains a shebang or is located in a path dedicated for executables, but lacks the executable bits and cannot thus be executed. If the file is meant to be an executable script, add the executable bits, otherwise remove the shebang or move the file elsewhere. yafaray-blender.x86_64: E: wrong-script-interpreter /usr/share/blender/scripts/yaf_light.py "BPY" This script uses an incorrect interpreter. yafaray-blender.x86_64: E: non-executable-script /usr/share/blender/scripts/yaf_light.py 0644 This text file contains a shebang or is located in a path dedicated for executables, but lacks the executable bits and cannot thus be executed. If the file is meant to be an executable script, add the executable bits, otherwise remove the shebang or move the file elsewhere. yafaray-blender.x86_64: E: wrong-script-interpreter /usr/share/blender/scripts/yafaray_ui.py "BPY" This script uses an incorrect interpreter. yafaray-blender.x86_64: E: non-executable-script /usr/share/blender/scripts/yafaray_ui.py 0644 This text file contains a shebang or is located in a path dedicated for executables, but lacks the executable bits and cannot thus be executed. If the file is meant to be an executable script, add the executable bits, otherwise remove the shebang or move the file elsewhere. yafaray-blender.x86_64: E: arch-dependent-file-in-usr-share /usr/share/blender/scripts/_yafrayinterface.so This package installs an ELF binary in the /usr/share hierarchy, which is reserved for architecture-independent files. yafaray-blender.x86_64: E: arch-dependent-file-in-usr-share /usr/share/blender/scripts/_yafqt.so This package installs an ELF binary in the /usr/share hierarchy, which is reserved for architecture-independent files. - Source contains not full qualified URI. If you have got the sources from svn, please add a comment on top of the source Statement. Please specified the release wihich you have chechout from svn. - %{datadir}/blender/scripts is owned by the blender package. Questions: * Why do you have the sub packages yarafay and yarafay-blender? * Why did you have uncomment the Provides and Obsoletes Statements?
(In reply to comment #5) > Some Comments: > > Good: > > + Local build works fine > + Blender scripts are in the right directory: > > Bad: > > - Build failed on koji > http://koji.fedoraproject.org/koji/taskinfo?taskID=898469 > > Reason: Wrong BR to libxml-devel, You will need a BR to libxml2-devel. Fixed in the new .src.rpm version. Please, see link at the end. > > - Rpmlint complaints source rpm > > $ rpmlint -i yafaray-0.1.0-4.fc9.src.rpm > yafaray.src:43: W: rpm-buildroot-usage %prep # fixes %{buildroot} in > libyafaraycore.so > $RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it will > break short circuiting. > It was just a comment. I am using %%{buildroot} now. > - Rpmlint warning to yafaray binary rpm: > $ rpmlint -i yafaray-0.1.0-4.fc9.x86_64.rpm > yafaray.x86_64: W: no-soname /usr/lib64/libyafaraycore.so > yafaray.x86_64: W: no-soname /usr/lib64/libyafarayqt.so > yafaray.x86_64: W: no-soname /usr/lib64/libyafarayplugin.so > 1 packages and 0 specfiles checked; 0 errors, 3 warnings. > This is an upstream issue. They are not using sonames. > - Rpmlint complaints yafary-blender rpm: > $ rpmlint -i yafaray-blender-0.1.0-4.fc9.x86_64.rpm > yafaray-blender.x86_64: W: no-documentation > The package contains no documentation (README, doc, etc). You have to include > documentation files. > > yafaray-blender.x86_64: E: wrong-script-interpreter > /usr/share/blender/scripts/yaf_export.py "BPY" > This script uses an incorrect interpreter. > > yafaray-blender.x86_64: E: non-executable-script > /usr/share/blender/scripts/yaf_export.py 0644 > This text file contains a shebang or is located in a path dedicated for > executables, but lacks the executable bits and cannot thus be executed. If > the file is meant to be an executable script, add the executable bits, > otherwise remove the shebang or move the file elsewhere. > > yafaray-blender.x86_64: E: wrong-script-interpreter > /usr/share/blender/scripts/yaf_light.py "BPY" > This script uses an incorrect interpreter. > > yafaray-blender.x86_64: E: non-executable-script > /usr/share/blender/scripts/yaf_light.py 0644 > This text file contains a shebang or is located in a path dedicated for > executables, but lacks the executable bits and cannot thus be executed. If > the file is meant to be an executable script, add the executable bits, > otherwise remove the shebang or move the file elsewhere. > > yafaray-blender.x86_64: E: wrong-script-interpreter > /usr/share/blender/scripts/yafaray_ui.py "BPY" > This script uses an incorrect interpreter. > > yafaray-blender.x86_64: E: non-executable-script > /usr/share/blender/scripts/yafaray_ui.py 0644 > This text file contains a shebang or is located in a path dedicated for > executables, but lacks the executable bits and cannot thus be executed. If > the file is meant to be an executable script, add the executable bits, > otherwise remove the shebang or move the file elsewhere. > > yafaray-blender.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/blender/scripts/_yafrayinterface.so > This package installs an ELF binary in the /usr/share hierarchy, which is > reserved for architecture-independent files. > > yafaray-blender.x86_64: E: arch-dependent-file-in-usr-share > /usr/share/blender/scripts/_yafqt.so > This package installs an ELF binary in the /usr/share hierarchy, which is > reserved for architecture-independent files. All the other blender scripts (in /usr/share/blender/scripts) are this way. > > - Source contains not full qualified URI. > If you have got the sources from svn, please add a comment on top of the > source Statement. Please specified the release wihich you have chechout > from svn. > The comments are in the changelog section, including the version (286). > - %{datadir}/blender/scripts is owned by the blender package. These scripts are just for the integration between blender and yafaray. > > Questions: > * Why do you have the sub packages yarafay and yarafay-blender? yafaray-blender contains scripts to allow blender to use yafaray. They should disappear in the future when yafaray replace yafray. For now, both renderers (yafray and yafaray) can coexist, and be called trough different menu options. In the yafaray home page, these scripts are supplied as a zip file for ubuntu. http://www.yafray.org/downloads/yaf_blender_282_amd64.zip > * Why did you have uncomment the Provides and Obsoletes Statements? The statements are commented, because we do not want to eliminate yafray right now. UPDATED VERSIONS: Spec URL: http://people.atrpms.net/~pcavalcanti/specs/yafaray.spec SRPM URL: http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-5.fc8.src.rpm
(In reply to comment #5) > Questions: > * Why do you have the sub packages yarafay and yarafay-blender? > * Why did you have uncomment the Provides and Obsoletes Statements? Good questions. I answear the second one first: Because yafray and yafaray can co-exist. (until the contrary is proven - but there is no namespace conflict yet). Do yafaray can work with another modeler than blender ? Actually I guess it can, I think it should even be possible to run it without blender or even without Xorg installed. This minimal yafaray (-core ?) would be composed of %{_bindir}yafaray-xml and %{_libdir}/libyafaraycore.so along with %{_libdir}/libyafaray/ Now about %{_libdir}/libyafarayplugin.so, I guess it is the interface with blender that is meant to be dlopened somehow. But it can stay with the -core sub-package according to the library requirements it has. About %{_libdir}/libyafarayqt.so ? It can probably go to the main package. But as there is no more binary to run the qt interface I guess it is used by the blender plugin (it failed while testing with blender, so it is just guesses). So the main package needs to require the core sub-package and blender, along with provides the scripts and .so . It will ends to have: %files %defattr(-, root, root) %doc CODING LICENSE INSTALL %{_libdir}/libyafarayqt.so %{_datadir}/blender/scripts #And to fix the arch dependant file %{_libdir}/blender/yafaray/ #or what will be needed %files core %defattr(-, root, root) %{_bindir}/%{name}-xml %{_libdir}/libyafaraycore.so %{_libdir}/libyafarayqt.so %dir %{_libdir}/%{name} %{_libdir}/%{name}/*.so / Few others notes / * License is LGPLv2+ According to headers of the sources. "...either version 2.1 of the License, or (at your option) any later version." * Developer file in Binrary package: (it should be removed) /usr/share/doc/yafaray-0.1.0/SConstruct * Rpmlint output on installed package. ----- [root@kwizatz sequence]# rpmlint yafaray yafaray.x86_64: W: incoherent-version-in-changelog 0.1.0-5 0.1.0-5.fc8.kwizart yafaray.x86_64: W: no-soname /usr/lib64/libyafarayqt.so yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafarayqt.so /lib64/libm.so.6 yafaray.x86_64: W: no-soname /usr/lib64/libyafaraycore.so yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafaraycore.so /usr/lib64/libIex.so.6 yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafaraycore.so /usr/lib64/libImath.so.6 yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafaraycore.so /lib64/libz.so.1 yafaray.x86_64: W: no-soname /usr/lib64/libyafarayplugin.so yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafarayplugin.so /lib64/libdl.so.2 1 packages and 0 specfiles checked; 0 errors, 9 warnings. ------------------ unused-direct-shlib-dependency should be reported upstream. no-soname could be also be reported upstreal, even if the libraries are meant to be dlopened. (as it is the case for yafray). * gcc-c++ is already in the default buildroot. It shouldn't be specified. * Compilation must use our CFLAGS. The package is compiled with -O3, But instead it should use our $RPM_OPT_FLAGS. * Testing yafaray with blender failed. Or at least i didn't get how to make it work. (both package are installed) [kwizart@kwizatz ~]$ blender Compiled with Python version 2.5.1. Checking for installed Python... got it! Traceback (most recent call last): File "<string>", line 25, in <module> File "/usr/share/blender/scripts/yaf_export.py", line 35, in <module> import yafrayinterface File "/usr/share/blender/scripts/yafrayinterface.py", line 7, in <module> import _yafrayinterface ImportError: No module named _yafrayinterface So for now, I don't know how to make it works.
(In reply to comment #7) > (In reply to comment #5) > > Questions: > > * Why do you have the sub packages yarafay and yarafay-blender? > > * Why did you have uncomment the Provides and Obsoletes Statements? > Good questions. > I answear the second one first: > Because yafray and yafaray can co-exist. (until the contrary is proven - but > there is no namespace conflict yet). > > Do yafaray can work with another modeler than blender ? > Actually I guess it can, I think it should even be possible to run it without > blender or even without Xorg installed. > This minimal yafaray (-core ?) would be composed of %{_bindir}yafaray-xml and > %{_libdir}/libyafaraycore.so along with %{_libdir}/libyafaray/ I downloaded this xml file from an yafaray forum: http://people.atrpms.net/~pcavalcanti/specs/yaf.xml Running /usr/bin/yafaray-xml yaf.xml produces a file containing an image: http://people.atrpms.net/~pcavalcanti/specs/yafaray.tga It is a silly image (just white, grey and black), but exactly the same that was published on the forum. > Now about %{_libdir}/libyafarayplugin.so, I guess it is the interface with > blender that is meant to be dlopened somehow. But it can stay with the -core > sub-package according to the library requirements it has. > About %{_libdir}/libyafarayqt.so ? It can probably go to the main package. But > as there is no more binary to run the qt interface I guess it is used by the > blender plugin (it failed while testing with blender, so it is just guesses). > So the main package needs to require the core sub-package and blender, along > with provides the scripts and .so . > > It will ends to have: > %files > %defattr(-, root, root) > %doc CODING LICENSE INSTALL > %{_libdir}/libyafarayqt.so > %{_datadir}/blender/scripts > #And to fix the arch dependant file > %{_libdir}/blender/yafaray/ #or what will be needed > > %files core > %defattr(-, root, root) > %{_bindir}/%{name}-xml > %{_libdir}/libyafaraycore.so > %{_libdir}/libyafarayqt.so > %dir %{_libdir}/%{name} > %{_libdir}/%{name}/*.so > > > / Few others notes / > > * License is LGPLv2+ > According to headers of the sources. "...either version 2.1 of the License, or > (at your option) any later version." > * Developer file in Binrary package: (it should be removed) > /usr/share/doc/yafaray-0.1.0/SConstruct > * Rpmlint output on installed package. > ----- > [root@kwizatz sequence]# rpmlint yafaray > yafaray.x86_64: W: incoherent-version-in-changelog 0.1.0-5 0.1.0-5.fc8.kwizart > yafaray.x86_64: W: no-soname /usr/lib64/libyafarayqt.so > yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafarayqt.so > /lib64/libm.so.6 > yafaray.x86_64: W: no-soname /usr/lib64/libyafaraycore.so > yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafaraycore.so > /usr/lib64/libIex.so.6 > yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafaraycore.so > /usr/lib64/libImath.so.6 > yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafaraycore.so > /lib64/libz.so.1 > yafaray.x86_64: W: no-soname /usr/lib64/libyafarayplugin.so > yafaray.x86_64: W: unused-direct-shlib-dependency > /usr/lib64/libyafarayplugin.so /lib64/libdl.so.2 > 1 packages and 0 specfiles checked; 0 errors, 9 warnings. > ------------------ > unused-direct-shlib-dependency should be reported upstream. > no-soname could be also be reported upstreal, even if the libraries are meant > to be dlopened. (as it is the case for yafray). > > * gcc-c++ is already in the default buildroot. > It shouldn't be specified. > > * Compilation must use our CFLAGS. > The package is compiled with -O3, But instead it should use our > $RPM_OPT_FLAGS. > > * Testing yafaray with blender failed. > Or at least i didn't get how to make it work. (both package are installed) > [kwizart@kwizatz ~]$ blender > Compiled with Python version 2.5.1. > Checking for installed Python... got it! > Traceback (most recent call last): > File "<string>", line 25, in <module> > File "/usr/share/blender/scripts/yaf_export.py", line 35, in <module> > import yafrayinterface > File "/usr/share/blender/scripts/yafrayinterface.py", line 7, in <module> > import _yafrayinterface > ImportError: No module named _yafrayinterface > > So for now, I don't know how to make it works. I can run blender 2.48 on F8 x86_64, and access yafaray. I compiled blender myself, mainly because I want ffmpeg enabled, to create some avi files with video animations: http://people.atrpms.net/~pcavalcanti/srpms/blender-2.48-15.fc8.src.rpm I think the minimum blender version that works with yafaray is 2.47. You can see how to call yafaray render, through the menus, here: http://www.yafray.org/forum/viewtopic.php?t=1701 I can change yafaray spec file, but It would be nice if people could get yafaray running the way I described...
I also downloaded these scenes from the previous link: http://people.atrpms.net/~pcavalcanti/specs/example_scenes.zip and got this very nice result: http://people.atrpms.net/~pcavalcanti/specs/Yafaray_Graphical_Rendering_Output.png This is the view of my blender window with yafaray: http://people.atrpms.net/~pcavalcanti/specs/quick_exterior_yafa.blend.png
Here are the other images: http://people.atrpms.net/~pcavalcanti/specs/max3d_house3.png http://people.atrpms.net/~pcavalcanti/specs/max3d_kuchnia.png http://people.atrpms.net/~pcavalcanti/specs/test_transpshadows.png http://people.atrpms.net/~pcavalcanti/specs/zarowki.png http://people.atrpms.net/~pcavalcanti/specs/yafaray_test.png http://people.atrpms.net/~pcavalcanti/specs/glossy_tests.png Blender is a really very, very nice software ...
OK, but the problem isn't with yafaray-xml ( which works - even if blender isn't installed). But with the communication between blender and yafaray. I don't know if blender needs to be built with yafaray support somehow. The site only tell that yafaray now works with "official blender" without telling which options/code are used for this official build. It should be possible to reproduce a "official like" built of blender to support yafaray (if needed). Actually I was using the "official" Fedora 8 x86_64 package of blender.(blender-2.47-5.fc8 ).
(In reply to comment #11) > OK, but the problem isn't with yafaray-xml ( which works - even if blender > isn't installed). But with the communication between blender and yafaray. > I don't know if blender needs to be built with yafaray support somehow. The > site only tell that yafaray now works with "official blender" without telling > which options/code are used for this official build. It should be possible to > reproduce a "official like" built of blender to support yafaray (if needed). > > Actually I was using the "official" Fedora 8 x86_64 package of > blender.(blender-2.47-5.fc8 ). I tried the official Fedora 8 package and got the same problem you had. In fact, the problem seems to be the blender scrits. When blender starts, it creates symbolic links for all of its scripts in ~/.blender/scripts. If I use my version (even the 2.47 one), leave the links in ~/.blender/scripts, and then install Fedora version, I can load yafaray. I do not have anything special in the version I compile, but ffmpeg. We have to try to figure out what is causing the problem. Can you just try this version and see if it works for you? http://people.atrpms.net/~pcavalcanti/rpms/rpms8/blender-2.48-15.fc8.i386.rpm I am going to make a diff of the spec files. Thanks.
I think I got it: Just do: cd ~/.blender/scripts ln -s /usr/share/blender/scripts/_yafrayinterface.so . ln -s /usr/share/blender/scripts/_yafqt.so . and it should work with the official Fedora version. These two shared libraries are in the yafaray-blender package. My blender version creates these two symbolic links in the user home directory, but the Fedora version does not.
ATrpms seems to be down. This is an alternative location for downloading the files: Spec URL: http://orion.lcg.ufrj.br/RPMS/SPECS/yafaray.spec SRPMS URL: http://orion.lcg.ufrj.br/RPMS/src/yafaray-0.1.0-5.fc8.src.rpm
(In reply to comment #13) > Just do: > > cd ~/.blender/scripts > > ln -s /usr/share/blender/scripts/_yafrayinterface.so . > > ln -s /usr/share/blender/scripts/_yafqt.so . > > and it should work with the official Fedora version. OK, I see the issue, I will create a future version of blender, which should fix this issue. But in may be nice, if you may put the .so files into %{_libdir}/blender so we can create multilib aware packages without any trouble.
(In reply to comment #6) > > - %{datadir}/blender/scripts is owned by the blender package. > > These scripts are just for the integration between blender and yafaray. Yes, thats is okay, but if you wrote %{datadir}/blender/scripts in the %files stanza, you calims ownership of this directory, which is not right. you should wrote something like %{datadir}/blender/scripts/* or anything else to put files into this directory without calming wonership.
ON rawhide I have create a blender package - release 2.48a-2 - which create symlinks from %{_libdir}/blender/scripts to ~/.blender/.scripts for executables. This should avoids the steps descriped in comment #13.
I changed the license to LGPLv2+ and I am using %{_datadir}/blender/scripts/* for the blender-yafaray package. It is not clear for me if we should keep _yafrayinterface.so and _yafqt.so in blender's scripts directory or in %{_libdir}/blender, as Jochen suggested. Either way is fine for me. Anyway, I can not go any further from here, because I am still being sponsored. Someone has to take over and try to build the package in koji. The links (spec and srpm) were updated, and ATrpms is up again. Spec URL: http://orion.lcg.ufrj.br/RPMS/SPECS/yafaray.spec http://people.atrpms.net/~pcavalcanti/specs/yafaray.spec SRPM URL: http://orion.lcg.ufrj.br/RPMS/src/yafaray-0.1.0-5.fc8.src.rpm http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-5.fc8.src.rpm Thanks.
(In reply to comment #18) > It is not clear for me if we should keep > > _yafrayinterface.so and _yafqt.so > > in blender's scripts directory or in %{_libdir}/blender, as > Jochen suggested. Either way is fine for me. The Shared Object are architecture dependent, thus needs to be in %{_libdir}/blender (which will ends in the blender sub-package) But /usr/lib64/libyafarayqt.so (and probably /usr/lib64/libyafarayplugin.so also needs to be in the blender sub-pacakge. I don't think it is necessary to run ldconfig in %post/%postun for the blender sub packages, as theses SO are meant to be dlopened. (only needed for by /usr/lib64/libyafaraycore.so which yafaray-xml links to). Please check permissions for _yafqt.so and _yafrayinterface.so because they are meant to be executable (if not they won't be stripped). Please use Source0: instead of Source: (there is some side-effects without versioned source). The source archives cannot be downloaded over the internet. You need to create a yafaray-snapshot.sh that will repackage such archtive for you. gcc-c++ is already in the buildroot. it have to be removed. %{SOURCE1} is manually extracted. You have to move this task in %prep using : %setup -q -n %{name} %setup -q -D -T -a 1 -n %{name} If you need to copy files that are not installed. Please use cp -p. That will prevent to change the timestamps.
If I move _yafrayinterface.so and _yafqt.so to %{_libdir}/blender, I will have to make symbolic links to %{_datadir}/blender/scripts. This is because these symbolic links must appear in ~/.blender/scripts, so yafrayinterface.py can load (import) them. The spec will have something like this: pushd %{buildroot}%{_datadir}/blender/scripts ln -s ../../../%{_lib}/_yafqt.so . ln -s ../../../%{_lib}/_yafrayinterface.so . popd The script yafaray-snapshot.sh is just for preparing the tarballi, right? I mean, it will not download the source via svn. This is the new spec file (I tested it): http://people.atrpms.net/~pcavalcanti/specs/yafaray.spec
#!/bin/sh # # Repackages a snapshtot, removing any .svn # directory. # # Input: directory # Output: tarball (directory.tar.gz) # # Usage: yafaray-snapshot.sh yafaray if [[ $# < 1 ]]; then echo "yafaray-snapshot.sh dir" exit 0; fi DIR="$1" find "$DIR" -name .svn -print0 | xargs -0 rm -rf tar -zcvf "$DIR".tar.gz ./"$DIR"
You should be able to "also" download from svn. Take a look on this sample: http://cvs.fedoraproject.org/viewvc/rpms/dirac/FC-5/dirac-snapshot.sh?view=markup It would be better for the tarball to have a date (not only versioned). @Jochen using a ~/.blender/script directory should be avoided. we need to use a dual system directory with %{_libdir}/blender/ and %{_datadir}/blender/scripts. Any chances that this kind of improvements can be thought with blender upstream? Everything that use users setting against system availability for libraries should be avoided.
I've just received few advices from #blendercoders I think we shouldn't duplicate code from how python module, and 'try to' consider yafaray blender dso and python script as usual python modules... (using python-site-arch directory for arch dependant code).
(In reply to comment #23) > I've just received few advices from #blendercoders > I think we shouldn't duplicate code from how python module, and 'try to' > consider yafaray blender dso and python script as usual python modules... > (using python-site-arch directory for arch dependant code). Hi, I updated the spec and the .src.rpm. I also created yafaray-snapshot.sh based on dirac-snapshot. I put the script in the doc section of the package. Regarding your last comment, the problem is that /usr/share/blender/scripts/yafrayinterface.py imports _yafrayinterface.so, via swig: ------------------------------------ # This file was automatically generated by SWIG (http://www.swig.org). # Version 1.3.33 # # Don't modify this file, modify the SWIG interface instead. # This file is compatible with both classic and new-style classes. import _yafrayinterface ------------------------------------ The only way (I see) for not having _yafrayinterface.so in the same directory of the script (/usr/share/blender/scripts) is to use: import sys sys.path.append ("/usr/lib64/blender/plugins/yafaray") import _yafrayinterface or whatever location we put the shared library. Therefore, I will have to patch the script ... (but it works).
I removed the symbolic links and added the search path in the scripts. It is working fine this way. Same URLS as before. Any comments? Is this acceptable?
quick comments. I will have more time on wednesday... The snapshot is good, can be I've regenerated from today and the package built fine. What need to be improved. * The package release should notice it is a snapshot. So, either the version (0.1.0) is pre, or post. then the release will be <1 (aka: 0.1svn%{date}%{?dist} or >1 ( 1svn%{date}%{?dist}. * Package must use our $RPM_OPT_CFLAGS. For now it use -O3 -ffast-math, you will probably need another dynamic patch here as $RPM_OPT_CFLAGS depends on the cpu architecture. * rpmlint on installed packages (rpmlint yafaray yafaray-blender) aren't empty, specially there are a lot of undefined-non-weak-symbols. This is because of a missing library at linking time, This have to be repored upstream. /usr/lib64/_yafqt.so /usr/lib64/_yafrayinterface.so * I still cannot have yarafray blender plugin detected when blender-2.48a-4.fc8.x86_64 is used. I will ivestigate this, but maybe it would be easier to define a blender python plugins directory within the python libdir pathes. %{python_sitearch}/blender/ for architecture dependent plugin (like yafaray) %{python_sitelib}/blender for architecture independant plugin. Then every files from a given plugin will be shipped either in the architecture dependent python directory or the architecture independent one... I will give more testing on wednesday as i'm not sure for now...
(In reply to comment #26) > quick comments. I will have more time on wednesday... > > The snapshot is good, can be I've regenerated from today and the package built > fine. > > What need to be improved. > * The package release should notice it is a snapshot. So, either the version > (0.1.0) is pre, or post. then the release will be <1 (aka: > 0.1svn%{date}%{?dist} or >1 ( 1svn%{date}%{?dist}. Done. I used: 0.1.svn.%{date}%{?dist} > > * Package must use our $RPM_OPT_CFLAGS. > For now it use -O3 -ffast-math, you will probably need another dynamic patch > here as $RPM_OPT_CFLAGS depends on the cpu architecture. > > > * rpmlint on installed packages (rpmlint yafaray yafaray-blender) aren't empty, > specially there are a lot of undefined-non-weak-symbols. This is because of a > missing library at linking time, This have to be repored upstream. > /usr/lib64/_yafqt.so > /usr/lib64/_yafrayinterface.so This is what I get: [cascavel:~/SRPMS] rpmlint yafaray yafaray.x86_64: W: no-soname /usr/lib64/libyafaraycore.so yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafaraycore.so /usr/lib64/libIex.so.6 yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafaraycore.so /usr/lib64/libImath.so.6 yafaray.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafaraycore.so /lib64/libz.so.1 [cascavel:~/SRPMS] rpmlint yafaray-blender yafaray-blender.x86_64: E: wrong-script-interpreter /usr/share/blender/scripts/yafaray_ui.py "BPY" yafaray-blender.x86_64: E: non-executable-script /usr/share/blender/scripts/yafaray_ui.py 0644 yafaray-blender.x86_64: E: wrong-script-interpreter /usr/share/blender/scripts/yaf_export.py "BPY" yafaray-blender.x86_64: E: non-executable-script /usr/share/blender/scripts/yaf_export.py 0644 yafaray-blender.x86_64: E: wrong-script-interpreter /usr/share/blender/scripts/yaf_light.py "BPY" yafaray-blender.x86_64: E: non-executable-script /usr/share/blender/scripts/yaf_light.py 0644 yafaray-blender.x86_64: W: no-soname /usr/lib64/libyafarayqt.so yafaray-blender.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafarayqt.so /lib64/libm.so.6 yafaray-blender.x86_64: W: no-soname /usr/lib64/libyafarayplugin.so yafaray-blender.x86_64: W: unused-direct-shlib-dependency /usr/lib64/libyafarayplugin.so /lib64/libdl.so.2 1 packages and 0 specfiles checked; 6 errors, 4 warnings. > > * I still cannot have yarafray blender plugin detected when > blender-2.48a-4.fc8.x86_64 is used. I will ivestigate this, but maybe it would > be easier to define a blender python plugins directory within the python libdir > pathes. > > %{python_sitearch}/blender/ for architecture dependent plugin (like yafaray) > %{python_sitelib}/blender for architecture independant plugin. I put _yaf*.so in %{python_sitearch} and it also worked. Maybe this way you can get them detected. The scrpits (.py), I think they should go where the other blender scripts are: /usr/share/blender/scripts new URLs: http://people.atrpms.net/~pcavalcanti/specs/yafray.spec http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0-0.1.svn.20081031.fc8.src.rpm
Sorry. The correct spec is: http://people.atrpms.net/~pcavalcanti/specs/yafaray.spec
I am also using: sed -i -e"s|REL_CCFLAGS = '-O3 -ffast-math'|REL_CCFLAGS = '-ffast-math %{optflags}'|g" config/linux2-config.py for the RPM_OPT_FLAGS. The compiler uses now: -ffast-math -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
So according to the newest blender.spec in devel (at least), we now have a blender arch dependent plugins directory. Once that said i'm not sure how it can be useful; specially if yafaray needs to writte it's own configuration and content data. You can look at https://bugzilla.redhat.com/show_bug.cgi?id=458090 for some discution with the blender maintainer. On your side, did you have improved the yafaray package. Is it possible to have some clean patches adopted upstream so you don't needs the tweaks in %prep ?
(In reply to comment #30) > So according to the newest blender.spec in devel (at least), we now have a > blender arch dependent plugins directory. > Once that said i'm not sure how it can be useful; specially if yafaray needs to > writte it's own configuration and content data. > You can look at https://bugzilla.redhat.com/show_bug.cgi?id=458090 > for some discution with the blender maintainer. > > On your side, did you have improved the yafaray package. > Is it possible to have some clean patches adopted upstream so you don't needs > the tweaks in %prep ? No. Surprisinly enough, it still builds with today's snapshot. Unless you have another suggestion, I think everything is in its appropriate place. The problem is that I cannot test it in F10. I have an Intel card and, besides the performance being really poor, blender segfaults all the time. Using F8, however, I had no problem whatsoever. Can you test yafaray in F10? Regarding the patches, they can be done, but they would have to be Fedora independent, and I do not know how to select the architecture without using macros, such as %{_lib}.
I will notify you, that I have create a new package of blender (blender-2.48a-13) which a modivied release of blender-wrapper of rawhide.
Can you update to 0.1.0.305 as an official release? Second, it seem, that there are to source tar ball Yarafay and Yarafay-blender. It may be nice, if you can get a look on it.
It is done. Revision 315.It is working fine for me on F10 nvidia 7600. It would be nice if someone could finish the review. The .src.rpm creates two rpms: yafaray and yafaray blender. SRPMS URL: http://orion.lcg.ufrj.br/RPMS/src/yafaray-0.1.0-0.1.svn.20090512.fc10.src.rpm Spec URL: http://orion.lcg.ufrj.br/RPMS/SPECS/yafaray.spec [cascavel:~/SRPMS] listrpm yafaray /usr/bin/yafaray-xml /usr/lib64/libyafaraycore.so /usr/lib64/yafaray/libDarkSky.so /usr/lib64/yafaray/libDebugIntegrator.so /usr/lib64/yafaray/libEmissionIntegrator.so /usr/lib64/yafaray/libEmptyVolumeIntegrator.so /usr/lib64/yafaray/libExpDensityVolume.so /usr/lib64/yafaray/libGridVolume.so /usr/lib64/yafaray/libNoiseVolume.so /usr/lib64/yafaray/libSingleScatterIntegrator.so /usr/lib64/yafaray/libSkyIntegrator.so /usr/lib64/yafaray/libSkyVolume.so /usr/lib64/yafaray/libUniformVolume.so /usr/lib64/yafaray/libarealight.so /usr/lib64/yafaray/libbasicnodes.so /usr/lib64/yafaray/libbasictex.so /usr/lib64/yafaray/libbidirpath.so /usr/lib64/yafaray/libblendermat.so /usr/lib64/yafaray/libcoatedglossy.so /usr/lib64/yafaray/libdirectional.so /usr/lib64/yafaray/libdirectlight.so /usr/lib64/yafaray/libglass.so /usr/lib64/yafaray/libglossymat.so /usr/lib64/yafaray/libgradientback.so /usr/lib64/yafaray/libpathtrace.so /usr/lib64/yafaray/libphotonmap.so /usr/lib64/yafaray/libpointlight.so /usr/lib64/yafaray/libshinydiffuse.so /usr/lib64/yafaray/libsimplemats.so /usr/lib64/yafaray/libspherelight.so /usr/lib64/yafaray/libspotlight.so /usr/lib64/yafaray/libsunlight.so /usr/lib64/yafaray/libsunsky.so /usr/lib64/yafaray/libtextureback.so /usr/lib64/yafaray/libvolumetrics.so /usr/share/doc/yafaray-0.1.0 /usr/share/doc/yafaray-0.1.0/CODING /usr/share/doc/yafaray-0.1.0/INSTALL /usr/share/doc/yafaray-0.1.0/LICENSE /usr/share/doc/yafaray-0.1.0/SConstruct [cascavel:~/SRPMS] listrpm yafaray-blender /usr/lib64/libyafarayplugin.so /usr/lib64/libyafarayqt.so /usr/lib64/python2.5/site-packages/_yafqt.so /usr/lib64/python2.5/site-packages/_yafrayinterface.so /usr/share/blender/scripts/yaf_export.py /usr/share/blender/scripts/yaf_light.py /usr/share/blender/scripts/yaf_material.py /usr/share/blender/scripts/yaf_object.py /usr/share/blender/scripts/yaf_texture.py /usr/share/blender/scripts/yafaray_ui.py /usr/share/blender/scripts/yafqt.py /usr/share/blender/scripts/yafrayinterface.py /usr/share/doc/yafaray-blender-0.1.0 /usr/share/doc/yafaray-blender-0.1.0/yafaray-snapshot.sh
Is there many differences between 0.1.0 stable and the today's snapshot. /usr/share/doc/yafaray-0.1.0/SConstruct is probably not wanted there. Abput /usr/share/blender/scripts/yaf_export.py , Are you sure we haven't any problem with the use of such architecture independant directory, against files been in /usr/lib64/python*/site-packages/ ? (every .so and .py? should be in the same architecture dependent directory, probably - at least It, that's what I would expect) Furthermore, yafaray may require to write configuration files (relative to the given user), so this is aimed to be This file : /usr/share/doc/yafaray-blender-0.1.0/yafaray-snapshot.sh Doesn't need to be in %doc as it has nothing to do with yafaray-blender subpackage. (can be provided within the cvs anyway).
SRPMS URL: http://orion.lcg.ufrj.br/RPMS/src/yafaray-0.1.0-1.fc10.src.rpm (In reply to comment #35) > Is there many differences between 0.1.0 stable and the today's snapshot. Is this a question or an affirmative? > > /usr/share/doc/yafaray-0.1.0/SConstruct is probably not wanted there. > I adapted the spec for building either the snapshot or the official release. > Abput /usr/share/blender/scripts/yaf_export.py , Are you sure we haven't any > problem with the use of such architecture independant directory, against files > been in /usr/lib64/python*/site-packages/ ? > (every .so and .py? should be in the same architecture dependent directory, > probably - at least It, that's what I would expect) > Furthermore, yafaray may require to write configuration files (relative to the > given user), so this is aimed to be > I did not change this yet. I have to think what to do. > > This file : /usr/share/doc/yafaray-blender-0.1.0/yafaray-snapshot.sh > Doesn't need to be in %doc as it has nothing to do with yafaray-blender > subpackage. (can be provided within the cvs anyway). Done.
> (In reply to comment #35) > > Is there many differences between 0.1.0 stable and the today's snapshot. > > Is this a question or an affirmative? yes, it's a question. > > given user), so this is aimed to be > > > > I did not change this yet. I have to think what to do. Probably need to be tought along with upstream (blender, yafaray) advices.
(In reply to comment #37) > > (In reply to comment #35) > > > Is there many differences between 0.1.0 stable and the today's snapshot. > > > > Is this a question or an affirmative? > yes, it's a question. The official release is now the 315. Therefore, it is equal to the snapshot I used on my previous message. SRPMS URL: http://people.atrpms.net/~pcavalcanti/srpms/yafaray-0.1.0.315-1.fc10.src.rpm > > > > given user), so this is aimed to be > > > > > > > I did not change this yet. I have to think what to do. > Probably need to be tought along with upstream (blender, yafaray) advices. The symbolic links are being created in ~/.blender/scripts just fine. I have deleted them many times and they are always automatically recreated. For instance: lrwxrwxrwx 1 roma 40 2009-05-23 21:14 yafaray_ui.py -> /usr/share/blender/scripts/yafaray_ui.py lrwxrwxrwx 1 roma 40 2009-05-23 21:14 yaf_export.py -> /usr/share/blender/scripts/yaf_export.py The plugins seems to have been installed in the appropriate locations, according to Jochen Schmitt, suggestions. The .so and the plugins were once in the same directories, but I was asked to move them. What exactly are you concerns?
(In reply to comment #38) > The symbolic links are being created in ~/.blender/scripts > just fine. I have deleted them many times and they are always automatically > recreated. For instance: > > lrwxrwxrwx 1 roma 40 2009-05-23 21:14 yafaray_ui.py -> > /usr/share/blender/scripts/yafaray_ui.py > lrwxrwxrwx 1 roma 40 2009-05-23 21:14 yaf_export.py -> > /usr/share/blender/scripts/yaf_export.py > > The plugins seems to have been installed in the appropriate locations, > according to Jochen Schmitt, suggestions. The .so and the plugins were once in > the same directories, but I was asked to move them. > > What exactly are you concerns? I assume, that you ask why I create the symlinks in `/.blender/scripts? the answer is, that blender only recorgnise the script and plugins which are available on this place. Best Regards: Jochen Schmitt
> > I assume, that you ask why I create the symlinks in `/.blender/scripts? No. I know that. > > the answer is, that blender only recorgnise the script and plugins which are > available on this place. This part is just fine. The problem, as I understand, are the shared libraries x python scripts: /usr/lib64/libyafarayplugin.so /usr/lib64/libyafarayqt.so /usr/lib64/python2.5/site-packages/_yafqt.so /usr/lib64/python2.5/site-packages/_yafrayinterface.so /usr/share/blender/scripts/yaf_export.py /usr/share/blender/scripts/yaf_light.py /usr/share/blender/scripts/yaf_material.py /usr/share/blender/scripts/yaf_object.py /usr/share/blender/scripts/yaf_texture.py /usr/share/blender/scripts/yafaray_ui.py /usr/share/blender/scripts/yafqt.py The shared libraries are architecture dependent, but the scripts are not (but they reference the libraries). Therefore, they can be in the same directory (as they were in previous versions), or in separate directories as they are now. The package seems to be working just fine the way it is now, and I am going to make them available soon in Yafaray forum, so people can test them. If there is a Fedora guideline for this situation, please let me know. Thanks.
As far as I can see, we have three kind of files: 1.) Pure python scripts which will be used from blender. This files has to been installed into /usr/share/blender/scripts 2.) Nativ so files which are python extension used by the blender python scripts. This files are installed into the architecure-depending python-sitelib. 3.) Native so files which will called by applications or other so files. This files should be installed into %{_libdir} For my judgement the location of the installed files looks fine. Best Regards: Jochen Schmitt
Thanks, Jochen There are rpms available for Fedora here: http://atrpms.net/name/yafaray/ Therefore, anyone willing to test them are welcome.
Can someone send me a picture of blender to see where the yafaray render option take place... I've never seen this from the whole review... (at least on x86_64). yafaray should be at version 1.0. That a rather common sense that a stable release have matching svn revision, that's very incorrect to have it mentioned talking from a stable release. quoting theses directories: %{_datadir}/blender/scripts/* %{_libdir}/libyafarayqt.so %{_libdir}/libyafarayplugin.so %{python_sitearch}/_yaf*.so IMO, you should only uses one directory from the script and the _yaf*.so. Again, that was meant to be asked with upstream blender/yafaray. The current package provided above doesn't work at all.
(In reply to comment #43) > Can someone send me a picture of blender to see where the yafaray render option > take place... I've never seen this from the whole review... (at least on > x86_64). > I am also using x86_64. Here is the picture: http://orion.lcg.ufrj.br/temp/blender-yafaray.png This is an archive with some scenes prepared to be rendered with blender/yafaray: http://orion.lcg.ufrj.br/temp/example_scenes.tar.bz2 The first one, bed_0001.blend, took more than 2 hours in a quadcore 2.4. Therefore, I would try the other ones first. > > yafaray should be at version 1.0. That a rather common sense that a stable > release have matching svn revision, that's very incorrect to have it mentioned > talking from a stable release. That is how upstream is doing. They moved from 1.0 - 305 to 1.0 - 315: http://www.yafaray.org/download/yafaray > > quoting theses directories: > %{_datadir}/blender/scripts/* > %{_libdir}/libyafarayqt.so > %{_libdir}/libyafarayplugin.so > %{python_sitearch}/_yaf*.so > > IMO, you should only uses one directory from the script and the _yaf*.so. > > Again, that was meant to be asked with upstream blender/yafaray. I have posted a message in yafaray Building forum and did not receive a single reply. They are Debian oriented, and I do not think they are concerned where we are going to install our files. > > The current package provided above doesn't work at all. What do you mean by that? It is working for me just fine. Have you tried it? Does it segfault?
Another thing. Old models prepared for yafray 0.9 will not be rendered correctly. They must be adapted. That is why I sent you some new models for you to run.
(In reply to comment #44) > (In reply to comment #43) .. > I am also using x86_64. Here is the picture: > http://orion.lcg.ufrj.br/temp/blender-yafaray.png I'm using a modified version of blender-2.48a-22 and that's the first time I see it, I will retry with an unmodified version from F-11 x86_64. > That is how upstream is doing. They moved from 1.0 - 305 to 1.0 - 315: Okay, that was my bad, the version is indeed 0.1.0.315. > I have posted a message in yafaray Building forum and did not receive a > single reply. Please reminds that the docs is the source code itself at the end. If you cannot have a > > The current package provided above doesn't work at all. > > What do you mean by that? It is working for me just fine. Have you tried > it? Does it segfault? Funny that you talk about segfault, because there is indeed one. Quoting: ---------------- creating new QApplication /usr/bin/blender: line 88: 7113 Segmentation fault /usr/bin/${blend}.bin $@ ---------------- Now what remains weird, is that even before the segfault the yafaray plugin doesn't seems to remind the previous configuration. (example: for using the xml parser for rendering).
(In reply to comment #46) > (In reply to comment #44) > > (In reply to comment #43) > .. > > I am also using x86_64. Here is the picture: > > http://orion.lcg.ufrj.br/temp/blender-yafaray.png > I'm using a modified version of blender-2.48a-22 and that's the first time I > see it, I will retry with an unmodified version from F-11 x86_64. I am using F10 x86_64. > > > That is how upstream is doing. They moved from 1.0 - 305 to 1.0 - 315: > Okay, that was my bad, the version is indeed 0.1.0.315. > > > I have posted a message in yafaray Building forum and did not receive a > > single reply. > Please reminds that the docs is the source code itself at the end. If you > cannot have a > > > > The current package provided above doesn't work at all. > > > > What do you mean by that? It is working for me just fine. Have you tried > > it? Does it segfault? > Funny that you talk about segfault, because there is indeed one. Quoting: > ---------------- > creating new QApplication > /usr/bin/blender: line 88: 7113 Segmentation fault /usr/bin/${blend}.bin > $@ > ---------------- I used to have segfaults before the 1.0.305 version. It worked with F8 but not with F10. I think it was because of different xorg versions. Since the official 1.0 release, I did not have any problem at all with F10, though. What video card are you using? > > Now what remains weird, is that even before the segfault the yafaray plugin > doesn't seems to remind the previous configuration. (example: for using the xml > parser for rendering). I would suggest that you try on F10 first, if possible. Then, you go to F11 so we can compare the results. There are packages for F9 to F11. Hopefully, we can get some people willing to test them.
I want to inform you, that blender-2.49 will available in rawhide in the next days.
Thanks. I have built it for F10. yafaray is still running fine with blender 2.49. At least one user acknowledged that yafaray rpms are working: http://www.yafaray.org/community/forum/viewtopic.php?f=12&t=2257
libsunsky.so from yafaray-blender requires text relocation. http://people.redhat.com/drepper/textrelocs.html This requirement have to be either removed, or handled by the appropriate selinux-policy-targeted package (you have to submit a bug against the said package). Unfornately I was still not able to have a working yafaray rendering with blender. I was testing it with a newly installed F-10 i686 with flgrx. I was not able to test with F-11 because some artifacts with the radeon driver... Given that blender 2.48 seems to be the lastest version to support yafray. I would request blender to be keepted at 2.48a for F-10.
(In reply to comment #50) > libsunsky.so from yafaray-blender requires text relocation. > http://people.redhat.com/drepper/textrelocs.html > This requirement have to be either removed, or handled by the appropriate > selinux-policy-targeted package (you have to submit a bug against the said > package). > I always deactivate selinux on my systems. That is why I have never noticed the problem. > > Unfortunately I was still not able to have a working yafaray rendering with > blender. I was testing it with a newly installed F-10 i686 with flgrx. I was > not able to test with F-11 because some artifacts with the radeon driver... Why not? Because of the selinux problem or because of the ATI driver? I only have nvidia cards running the proprietary driver. > > Given that blender 2.48 seems to be the lastest version to support yafray. I > would request blender to be keepted at 2.48a for F-10. I am running blender 2.49 just fine with yafaray on F10 x86_64, but I cannot say if version 2.49 is stable enough (despite of yafaray).
So to sum-up, needworks: 1- Get the package compliant with SElinux (either allowing selinux-policy, or fixing the package at source). 2- Fix the package to actually work. (my wild guess it that the code isn't compliant with -Wp,-D_FORTIFY_SOURCE=2). About the directory problem (and the fact that the package seems to split .py and .so despite they seems to be targeted to be used from the same directory). The directory scheme used in this package heavily rely on the blender-wrapper script which yet, isn't upstreamed. This is bad, as this may (will have to) evolve. Nevertheless If such changes, appears from the blender package, it can be tweaks for Rawhide only. According that the directory scheme seems to more or less works, please Fix 1/ and 2/.
Can I have a change to have an answear and for the remaining fix to be done ? blender 2.49a is been built, please give it a try. (but it's still crash with yafaray).
Created attachment 348714 [details] Selinux denial from the yafaray package.
The source code for 2.49a seems not to be available yet: http://www.blender.org/download/source-code/ I have installed F11 on an Intel N270 Atom netbook, and blender 2.49/yafaray is running just fine. The graphics card is: "Mobile 945GME Express Integrated Graphics Controller". Unfortunately, I do not have any ATI card to try, but I would suggest that you delete the contents of ~/.blender/scripts and restart blender so the symlinks are recreated. I also had the selinux denial because of the text relocation and this has to be fixed. However, selinux gave so much trouble that I had to disable it again. Regarding the location of the scripts/.so, I think I have to follow what the Fedora blender maintainer recommends. Yafaray has to be integrated into blender and Jochen has to agree with the location of the files. If you convince him, I can change the installation once more (I have no problem with that). Yafaray installation is very "loose", and they still have just a zip file for Ubuntu with the scripts to be uncompressed manually.
I want to nofify you, that blender-2.94a is in updates-testing.
Can I have an update of yafaray package to be compliant with selinux ?
Created attachment 350835 [details] Result of a yafaray test For me yafaray works fine, as you can see on the attached picture. This test was made with: blender-2.49a-2 yafaray-0.1.0.315
Additional information for Comment #58: I have set the enforcing level of SELinux to Enforcing to make sure, that yafaray runs with SELinux.
(In reply to comment #59) > Additional information for Comment #58: I have set the enforcing level of > SELinux to Enforcing to make sure, that yafaray runs with SELinux. You need to reboot in order to relabel ! yafaray remains not compliant with selinux, either the code needs to be fixed either the correct selinux context need to be set (as such it need to be reported as a bug in selinux-policy-targeted) This need 5min of time !
(In reply to comment #60) > yafaray remains not compliant with selinux, either the code needs to be fixed > either the correct selinux context need to be set (as such it need to be > reported as a bug in selinux-policy-targeted) > This need 5min of time ! @kwizrart: Then Do it.
I have already reported the problem: https://bugzilla.redhat.com/show_bug.cgi?id=510113
Can you fix the libraries to not require text relocation. This usually means that the libraries are not being built with -PIC flags. http://people.redhat.com/~drepper/selinux-mem.html http://people.redhat.com/drepper/textrelocs.html Fix the libraries, we do not want to disable SELinux features to accept a new package.
(In reply to comment #63) > Can you fix the libraries to not require text relocation. This usually means > that the libraries are not being built with -PIC flags. All the code is already being compiled with -fPIC. For instance: g++ -o build/integrators/SkyIntegrator.os -c -Wall -fPIC -ffast-math -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DHAVE_PTHREAD -DHAVE_EXR -DHAVE_XML -DHAVE_JPEG -DHAVE_PNG -DHAVE_ZLIB -DHAVE_FREETYPE -DHAVE_QT -DBUILDING_YAFRAYPLUGIN -I. -Iinclude src/integrators/SkyIntegrator.cc
Uli, do you have any ideas?
(In reply to comment #65) > Uli, do you have any ideas? Probably some assembler code. I haven't looked at the source code. But most multi-media code is using streaming instructions and unfortunately the people writing the code use asm code and then do it incorrectly. Compile with debug info and then use eu-findtextrel.
(In reply to comment #66) > (In reply to comment #65) > > Uli, do you have any ideas? > > Probably some assembler code. I haven't looked at the source code. But most > multi-media code is using streaming instructions and unfortunately the people > writing the code use asm code and then do it incorrectly. > > Compile with debug info and then use eu-findtextrel. Everything goes fine on x86_64, But on i586 (F-11): ------------------------------------------- # find -name "*.so" -exec eu-findtextrel {} ';' eu-findtextrel: no text relocations reported in './build/interface/libyafarayplugin.so' eu-findtextrel: no text relocations reported in './build/integrators/libSkyIntegrator.so' eu-findtextrel: no text relocations reported in './build/integrators/libdirectlight.so' eu-findtextrel: no text relocations reported in './build/integrators/libSingleScatterIntegrator.so' eu-findtextrel: no text relocations reported in './build/integrators/libpathtrace.so' eu-findtextrel: no text relocations reported in './build/integrators/libphotonmap.so' eu-findtextrel: no text relocations reported in './build/integrators/libDebugIntegrator.so' eu-findtextrel: no text relocations reported in './build/integrators/libbidirpath.so' eu-findtextrel: no text relocations reported in './build/integrators/libEmissionIntegrator.so' eu-findtextrel: no text relocations reported in './build/integrators/libEmptyVolumeIntegrator.so' eu-findtextrel: no text relocations reported in './build/materials/libsimplemats.so' eu-findtextrel: no text relocations reported in './build/materials/libglossymat.so' eu-findtextrel: no text relocations reported in './build/materials/libglass.so' eu-findtextrel: no text relocations reported in './build/materials/libblendermat.so' eu-findtextrel: no text relocations reported in './build/materials/libvolumetrics.so' eu-findtextrel: no text relocations reported in './build/materials/libshinydiffuse.so' eu-findtextrel: no text relocations reported in './build/materials/libcoatedglossy.so' eu-findtextrel: no text relocations reported in './build/lights/libarealight.so' eu-findtextrel: no text relocations reported in './build/lights/libspotlight.so' eu-findtextrel: no text relocations reported in './build/lights/libdirectional.so' eu-findtextrel: no text relocations reported in './build/lights/libsunlight.so' eu-findtextrel: no text relocations reported in './build/lights/libpointlight.so' eu-findtextrel: no text relocations reported in './build/lights/libspherelight.so' eu-findtextrel: no text relocations reported in './build/textures/libbasictex.so' eu-findtextrel: no text relocations reported in './build/textures/libbasicnodes.so' eu-findtextrel: no text relocations reported in './build/gui/libyafarayqt.so' eu-findtextrel: no text relocations reported in './build/yafraycore/libyafaraycore.so' eu-findtextrel: no text relocations reported in './build/bindings/_yafrayinterface.so' eu-findtextrel: no text relocations reported in './build/bindings/_yafqt.so' eu-findtextrel: no text relocations reported in './build/volumes/libUniformVolume.so' eu-findtextrel: no text relocations reported in './build/volumes/libGridVolume.so' eu-findtextrel: no text relocations reported in './build/volumes/libNoiseVolume.so' eu-findtextrel: no text relocations reported in './build/volumes/libExpDensityVolume.so' eu-findtextrel: no text relocations reported in './build/volumes/libSkyVolume.so' eu-findtextrel: no text relocations reported in './build/backgrounds/libgradientback.so' src/lights/bglight.cc not compiled with -fpic/-fPIC /usr/lib/gcc/i586-redhat-linux/4.4.0/../../../../include/c++/4.4.0/iostream not compiled with -fpic/-fPIC include/core_api/vector3d.h not compiled with -fpic/-fPIC include/core_api/texture.h not compiled with -fpic/-fPIC include/utilities/sample_utils.h not compiled with -fpic/-fPIC include/core_api/light.h not compiled with -fpic/-fPIC /usr/include/bits/string3.h not compiled with -fpic/-fPIC the file containing the function '_ZTVN7yafaray9bgLight_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTSN7yafaray9bgLight_tE' or the file containing the function '_ZTVN7yafaray17constBackground_tE' is not compiled with -fpic/-fPIC the file containing the function '_ZTIN7yafaray9bgLight_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTIN7yafaray9bgLight_tE' or the file containing the function '_ZTVN7yafaray17constBackground_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTIN7yafaray9bgLight_tE' or the file containing the function '_ZTVN7yafaray17constBackground_tE' is not compiled with -fpic/-fPIC src/lights/bglight.cc not compiled with -fpic/-fPIC /usr/lib/gcc/i586-redhat-linux/4.4.0/../../../../include/c++/4.4.0/iostream not compiled with -fpic/-fPIC include/core_api/vector3d.h not compiled with -fpic/-fPIC include/core_api/texture.h not compiled with -fpic/-fPIC include/utilities/sample_utils.h not compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC include/core_api/light.h not compiled with -fpic/-fPIC /usr/include/bits/string3.h not compiled with -fpic/-fPIC the file containing the function '_ZTVN7yafaray9bgLight_tE' is not compiled with -fpic/-fPIC the file containing the function '_ZTVN7yafaray7light_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTSN7yafaray9bgLight_tE' or the file containing the function '_ZTIN7yafaray7light_tE' is not compiled with -fpic/-fPIC the file containing the function '_ZTIN7yafaray9bgLight_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTIN7yafaray9bgLight_tE' or the file containing the function '_ZTSN7yafaray7light_tE' is not compiled with -fpic/-fPIC the file containing the function '_ZTIN7yafaray7light_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTVN7yafaray7light_tE' or the file containing the function '_ZTVN7yafaray18sunskyBackground_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTVN7yafaray7light_tE' or the file containing the function '_ZTVN7yafaray18sunskyBackground_tE' is not compiled with -fpic/-fPIC src/lights/bglight.cc not compiled with -fpic/-fPIC /usr/lib/gcc/i586-redhat-linux/4.4.0/../../../../include/c++/4.4.0/iostream not compiled with -fpic/-fPIC include/core_api/vector3d.h not compiled with -fpic/-fPIC include/core_api/texture.h not compiled with -fpic/-fPIC include/utilities/sample_utils.h not compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC the file containing the function '_init' might not be compiled with -fpic/-fPIC include/core_api/light.h not compiled with -fpic/-fPIC /usr/include/bits/string3.h not compiled with -fpic/-fPIC the file containing the function '_ZTVN7yafaray9bgLight_tE' is not compiled with -fpic/-fPIC the file containing the function '_ZTVN7yafaray7light_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTSN7yafaray9bgLight_tE' or the file containing the function '_ZTIN7yafaray7light_tE' is not compiled with -fpic/-fPIC the file containing the function '_ZTIN7yafaray9bgLight_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTIN7yafaray9bgLight_tE' or the file containing the function '_ZTSN7yafaray7light_tE' is not compiled with -fpic/-fPIC the file containing the function '_ZTIN7yafaray7light_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTVN7yafaray7light_tE' or the file containing the function '_ZTVN7yafaray19darkSkyBackground_tE' is not compiled with -fpic/-fPIC either the file containing the function '_ZTVN7yafaray7light_tE' or the file containing the function '_ZTVN7yafaray19darkSkyBackground_tE' is not compiled with -fpic/-fPIC eu-findtextrel: no text relocations reported in './bindings/python/_yafrayinterface.so' eu-findtextrel: no text relocations reported in './bindings/python/_yafqt.so -------------------------------------------
Created attachment 355661 [details] backtrace when rendering with a gtk based deskop
(In reply to comment #67) > src/lights/bglight.cc not compiled with -fpic/-fPIC > /usr/lib/gcc/i586-redhat-linux/4.4.0/../../../../include/c++/4.4.0/iostream not > compiled with -fpic/-fPIC > include/core_api/vector3d.h not compiled with -fpic/-fPIC > include/core_api/texture.h not compiled with -fpic/-fPIC > include/utilities/sample_utils.h not compiled with -fpic/-fPIC > include/core_api/light.h not compiled with -fpic/-fPIC > /usr/include/bits/string3.h not compiled with -fpic/-fPIC > the file containing the function '_ZTVN7yafaray9bgLight_tE' is not compiled > with -fpic/-fPIC > either the file containing the function '_ZTSN7yafaray9bgLight_tE' or the file > containing the function '_ZTVN7yafaray17constBackground_tE' is not compiled > with -fpic/-fPIC > the file containing the function '_ZTIN7yafaray9bgLight_tE' is not compiled > with -fpic/-fPIC > either the file containing the function '_ZTIN7yafaray9bgLight_tE' or the file > containing the function '_ZTVN7yafaray17constBackground_tE' is not compiled > with -fpic/-fPIC > either the file containing the function '_ZTIN7yafaray9bgLight_tE' or the file > containing the function '_ZTVN7yafaray17constBackground_tE' is not compiled > with -fpic/-fPIC > src/lights/bglight.cc not compiled with -fpic/-fPIC > /usr/lib/gcc/i586-redhat-linux/4.4.0/../../../../include/c++/4.4.0/iostream not > compiled with -fpic/-fPIC > include/core_api/vector3d.h not compiled with -fpic/-fPIC > include/core_api/texture.h not compiled with -fpic/-fPIC > include/utilities/sample_utils.h not compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > include/core_api/light.h not compiled with -fpic/-fPIC > /usr/include/bits/string3.h not compiled with -fpic/-fPIC > the file containing the function '_ZTVN7yafaray9bgLight_tE' is not compiled > with -fpic/-fPIC > the file containing the function '_ZTVN7yafaray7light_tE' is not compiled with > -fpic/-fPIC > either the file containing the function '_ZTSN7yafaray9bgLight_tE' or the file > containing the function '_ZTIN7yafaray7light_tE' is not compiled with > -fpic/-fPIC > the file containing the function '_ZTIN7yafaray9bgLight_tE' is not compiled > with -fpic/-fPIC > either the file containing the function '_ZTIN7yafaray9bgLight_tE' or the file > containing the function '_ZTSN7yafaray7light_tE' is not compiled with > -fpic/-fPIC > the file containing the function '_ZTIN7yafaray7light_tE' is not compiled with > -fpic/-fPIC > either the file containing the function '_ZTVN7yafaray7light_tE' or the file > containing the function '_ZTVN7yafaray18sunskyBackground_tE' is not compiled > with -fpic/-fPIC > either the file containing the function '_ZTVN7yafaray7light_tE' or the file > containing the function '_ZTVN7yafaray18sunskyBackground_tE' is not compiled > with -fpic/-fPIC > src/lights/bglight.cc not compiled with -fpic/-fPIC > /usr/lib/gcc/i586-redhat-linux/4.4.0/../../../../include/c++/4.4.0/iostream not > compiled with -fpic/-fPIC > include/core_api/vector3d.h not compiled with -fpic/-fPIC > include/core_api/texture.h not compiled with -fpic/-fPIC > include/utilities/sample_utils.h not compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > the file containing the function '_init' might not be compiled with -fpic/-fPIC > include/core_api/light.h not compiled with -fpic/-fPIC > /usr/include/bits/string3.h not compiled with -fpic/-fPIC > the file containing the function '_ZTVN7yafaray9bgLight_tE' is not compiled > with -fpic/-fPIC > the file containing the function '_ZTVN7yafaray7light_tE' is not compiled with > -fpic/-fPIC > either the file containing the function '_ZTSN7yafaray9bgLight_tE' or the file > containing the function '_ZTIN7yafaray7light_tE' is not compiled with > -fpic/-fPIC > the file containing the function '_ZTIN7yafaray9bgLight_tE' is not compiled > with -fpic/-fPIC > either the file containing the function '_ZTIN7yafaray9bgLight_tE' or the file > containing the function '_ZTSN7yafaray7light_tE' is not compiled with > -fpic/-fPIC > the file containing the function '_ZTIN7yafaray7light_tE' is not compiled with > -fpic/-fPIC > either the file containing the function '_ZTVN7yafaray7light_tE' or the file > containing the function '_ZTVN7yafaray19darkSkyBackground_tE' is not compiled > with -fpic/-fPIC > either the file containing the function '_ZTVN7yafaray7light_tE' or the file > containing the function '_ZTVN7yafaray19darkSkyBackground_tE' is not compiled > with -fpic/-fPIC There you have a sign of problems. Because of the way you ran eu-findtextrel we don't know what .so file is the problem (and maybe there is more than one). But you can easily find out. Then go on and look how the file is compiled and what it contains etc.
(In reply to comment #68) > Created an attachment (id=355661) [details] > backtrace when rendering with a gtk based deskop Niolas, what version are you using? yafaray is 0.1.1 now. Maybe some problems have been fixed. I opened a bug regarding selinux, but it seems that the developers are not very concerned about it at the moment: http://www.yafaray.org/node/200
Hallo, for testing I have create http://www.herr-schmitt.de/pub/yarafay/yarafay.spec http://www.herr-schmitt.de/pub/yarafay/yarafay-0.1.1-1.fc11.src.rpm I hope this max be helpful.
The links are dead.
The latest version is here: http://atrpms.net/name/yafaray/
Still doesn't work for me ... (even on x86_64 ) Where is a build.log ? Please submit a direct link to src.rpm/spec. Have you tried to force compilation with -fPIC -DPIC ?
The compilation used -fPIC only: http://people.atrpms.net/~pcavalcanti/patches/build.log http://dl.atrpms.net/all/yafaray-0.1.1-1.src.rpm http://dl.atrpms.net/all/yafaray.spec
I will only inform you, that I have submitted blender-2.49b on rawhode.
I am NOT having any selinux issue on F12 (enforcing policy). Anyone still having problems?
I'm still having problem with every single hardware I am testing this package. Either built locally or with koji. (tested x64_64) http://koji.fedoraproject.org/koji/taskinfo?taskID=2099632 Hence I cannot give a + on this. That been said, it could not be a problem with yafaray but blender, or whatever. I could leave a chance for another reviewer/user to make this package goes in. (So I leave review). I will obsoletes yafray (without an a) given that the current blender version doesn't support it anyway. A last note, I guess usage of %if %{with snap} conditional seems too much for such package.
I have been trying to install it correctly but the QT interface makes blender and yafaray crash with a segfault. Either with F12 or F13 (Yafaray does everything for exporting) Then when it tries: " creating new QApplication /usr/bin/blender: line 92: 8607 Segmentation fault (core dumped) /usr/bin/${blend}.bin $@ " Now there are people on yafaray forums saying you should change qt4 stype to plastique, but It doesn't work for me. If I don't enable th Qt4 gui... yafaray works normally. So I thought it was either QT4 or PyQT4. But some people with mandriva and other distributions say that this problems happened and then when they switched the blender to the original from the blender.org it worked like a charm. And so I did that and it did work. I think there may be a blender patch that is beeing problematic to yafaray.
I built and installed the package linked in comment #75 and it worked fine on 64-bit Fedora 13 with Blender 2.49b-9
And I rebuilt and reinstalled today on F14 and it's still working fine, so I've reviewed the package. There are quite a few issues here. I'll start with a few basic ones: * The project consistently calls the tool YafaRay, so I think this is an instance where we should not change the capitalization * The project website says that the license is LGPL2.1, with no "or later", so you need to correct the License: to state the specific version * You should not use the name YafaRay in the Summary: * The upstream sources have moved to new URLs, so you need to update the Source0: and Source1: lines * In comment #78, kwizart said that he would obsolete Yafray; so I guess you should now uncomment the Obsoletes: and Provides: lines * Typo in Description: "capabilties" * If you added "YafaRay can be used with official releases of Blender 3D" to the Description: because of previous problems people reported with using this package with the version of Blender shipped in Fedora, I think you can remove this now -- it seems to work with the Blender we currently ship. Other issues: * normally, .so files belong in a -devel subpackage, but I'm not sure this is the case here. I will investigate further. * rpmlint gives "no-soname" warnings for: /usr/lib64/libyafaraycore.so /usr/lib64/libyafarayqt.so /usr/lib64/libyafarayplugin.so Take a look at the suggestion here: http://fedoraproject.org/wiki/PackageMaintainers/Common_Rpmlint_Issues#no-soname * rpmlint gives "private-shared-object-provides" warnings for: /usr/lib64/python2.7/site-packages/_yafqt.so _yafqt.so() /usr/lib64/python2.7/site-packages/_yafrayinterface.so _yafrayinterface.so() Take a look at: http://fedoraproject.org/wiki/PackageMaintainers/Common_Rpmlint_Issues#private-shared-object-provides ==FULL REVIEW== - = N/A / = Check ! = Problem ? = Not evaluated === REQUIRED ITEMS === [!] Rpmlint output is clean: $ rpmlint SPECS/yafaray.spec SPECS/yafaray.spec:32: W: macro-in-comment %{version} SPECS/yafaray.spec:33: W: macro-in-comment %{version} SPECS/yafaray.spec:33: W: macro-in-comment %{release} SPECS/yafaray.spec: W: invalid-url Source1: http://www.yafaray.org/sites/default/files/download/builds/YafaRay-blender.0.1.1.zip HTTP Error 404: Not Found SPECS/yafaray.spec: W: invalid-url Source0: http://www.yafaray.org/sites/default/files/download/builds/YafaRay.0.1.1.zip HTTP Error 404: Not Found 0 packages and 1 specfiles checked; 0 errors, 5 warnings. $ rpmlint SRPMS/yafaray-0.1.1-1.fc14.src.rpm yafaray.src: W: spelling-error Summary(en_US) raytracing -> ray tracing, ray-tracing, tracing yafaray.src: W: name-repeated-in-summary C YafaRay yafaray.src: W: spelling-error %description -l en_US raytracing -> ray tracing, ray-tracing, tracing yafaray.src: W: spelling-error %description -l en_US Raytracing -> Ray tracing, Ray-tracing, Tracing yafaray.src: W: spelling-error %description -l en_US capabilties -> capabilities, capability, capacities yafaray.src:32: W: macro-in-comment %{version} yafaray.src:33: W: macro-in-comment %{version} yafaray.src:33: W: macro-in-comment %{release} yafaray.src: W: invalid-url Source1: http://www.yafaray.org/sites/default/files/download/builds/YafaRay-blender.0.1.1.zip HTTP Error 404: Not Found yafaray.src: W: invalid-url Source0: http://www.yafaray.org/sites/default/files/download/builds/YafaRay.0.1.1.zip HTTP Error 404: Not Found 1 packages and 0 specfiles checked; 0 errors, 10 warnings. $ rpmlint RPMS/x86_64/yafaray-0.1.1-1.fc14.x86_64.rpm yafaray.x86_64: W: spelling-error Summary(en_US) raytracing -> ray tracing, ray-tracing, tracing yafaray.x86_64: W: name-repeated-in-summary C YafaRay yafaray.x86_64: W: spelling-error %description -l en_US raytracing -> ray tracing, ray-tracing, tracing yafaray.x86_64: W: spelling-error %description -l en_US Raytracing -> Ray tracing, Ray-tracing, Tracing yafaray.x86_64: W: spelling-error %description -l en_US capabilties -> capabilities, capability, capacities yafaray.x86_64: W: no-soname /usr/lib64/libyafaraycore.so yafaray.x86_64: W: no-manual-page-for-binary yafaray-xml 1 packages and 0 specfiles checked; 0 errors, 7 warnings. $ rpmlint RPMS/x86_64/yafaray-blender-0.1.1-1.fc14.x86_64.rpm yafaray-blender.x86_64: W: spelling-error %description -l en_US Yaf -> Yafo, Oaf, Yap yafaray-blender.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/_yafqt.so _yafqt.so()(64bit) yafaray-blender.x86_64: W: private-shared-object-provides /usr/lib64/python2.7/site-packages/_yafrayinterface.so _yafrayinterface.so()(64bit) yafaray-blender.x86_64: W: no-soname /usr/lib64/libyafarayqt.so yafaray-blender.x86_64: W: no-soname /usr/lib64/libyafarayplugin.so yafaray-blender.x86_64: W: no-documentation 1 packages and 0 specfiles checked; 0 errors, 6 warnings. $ rpmlint RPMS/x86_64/yafaray-debuginfo-0.1.1-1.fc14.x86_64.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [!] Package is named according to the Package Naming Guidelines. "Keep in mind to respect the wishes of the upstream maintainers. If they refer to their application as "ORBit", you should use "ORBit" as the package name, and not "orbit". However, if they do not express any preference of case, you should default to lowercase naming." -- http://fedoraproject.org/wiki/PackageNamingGuidelines Upstream consistently capitalizes the name as "YafaRay". Unless you've contacted them to determine that they don't care, Fedora should follow their guidance. [/] Spec file name must match the base package %{name}, in the format %{name}.spec. [/] Package meets the Packaging Guidelines including the Language specific items [/] Package is licensed with an open-source compatible license and meets other legal requirements as defined in the legal section of Packaging Guidelines. [!] License field in the package spec file matches the actual license. From the project website: "YafaRay is released under the LGPL 2.1 license." specfile says "LGPLv2+" [/] If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package is included in %doc. [/] Spec file is legible and written in American English. [!] Sources used to build the package matches the upstream source, as provided in the spec URL. Sources are no longer available at URL in spec; however, they match what is available on the project website: $ md5sum SOURCES/YafaRay.0.1.1.zip d1722dec25299f6f3fcc1d7c661a4e90 SOURCES/YafaRay.0.1.1.zip $ md5sum ~/Download/YafaRay.0.1.1.zip d1722dec25299f6f3fcc1d7c661a4e90 /home/rlandmann/Download/YafaRay.0.1.1.zip $ md5sum SOURCES/YafaRay-blender.0.1.1.zip d7e7f86b9e90e7f960707ebaea1843ab SOURCES/YafaRay-blender.0.1.1.zip $ md5sum ~/Download/YafaRay-blender.0.1.1.zip d7e7f86b9e90e7f960707ebaea1843ab /home/rlandmann/Download/YafaRay-blender.0.1.1.zip [] Package successfully compiles and builds into binary rpms on at least one supported architecture. Tested: http://koji.fedoraproject.org/koji/taskinfo?taskID=2575603 [/] Package is not known to require ExcludeArch [/] All build dependencies are listed in BuildRequires, except for any that are listed in the exceptions section of Packaging Guidelines. [-] The spec file handles locales properly (with the %find_lang macro) [-] ldconfig called in %post and %postun if required. [/] Package does not bundle copies of system libraries [/] Package is not relocatable. [/] Package must own all directories that it creates. [/] Package does not contain duplicates in %files. [-] Permissions on files are set properly [/] %files section includes a %defattr(...) line [/] Package consistently uses macros. [-] Large documentation files are in a -doc subpackage, if required. [/] Package uses nothing in %doc for runtime. [-] Header files in -devel subpackage, if present. [-] Static libraries in -static subpackage, if present. [!] Development .so files in -devel subpackage, if present. [!] -devel packages require base package with full versioning. [/] Package does not contain any libtool archives (.la). [-] Package contains a properly installed %{name}.desktop file if it is a GUI application. [/] Package does not own files or directories owned by other packages. [/] Filenames are valid UTF-8 === SUGGESTED ITEMS === [/] Package does not include license text files separate from upstream. [-] Description and summary sections in the package spec file contains translations for supported Non-English languages, if available. [/] Reviewer should test that the package builds in mock. Tested through koji [/] Package should compile and build into binary rpms on all supported architectures. Tested on: f14 [/] Package functions as described. [/] Scriptlets must be sane, if used. [/] Subpackages other than -devel require the base package as a fully versioned dependency [-] The placement of pkgconfig(.pc) files is correct (normally in -devel) [-] File based requires are sane. [!] Package contains man pages for binaries and scripts.
Hi, In fact, there still is a problem. With the Qt interface active, it only works for me in KDE. In gnome, it crashes as people mentioned before. I think it is the qt gui stile, but running qtconfig-qt4 and changing the style to "plastique" does not seem to change anything in gnome. Any suggestion?
I wouldn't consider that a review blocker. As a matter of fact, fixing would likely be much easier once the app was in fedora already.
The problem with yafaray+blender was gettext. Upgrading to gettext 0.18.1.1 on my systems running F10/F12, avoids crashing, when using the qt style GTK+. https://bugzilla.redhat.com/show_bug.cgi?id=650471 However, I have a new .src.rpm here: Spec URL:http://orion.lcg.ufrj.br/RPMS/SPECS/yafaray.spec SRPM URL:http://roma.fedorapeople.org/srpms/yafaray-0.1.1-2.fc12.src.rpm I was not able to address the soname issue, because yafaray is compiled using scons and it is difficul to access the ldd flags. I put a comment in the spec file where the soname option should be passed, but the compilation fails in this case. But I am really not sure what is the exact syntax. Maybe someone else has a suggestion on how to proceed ... #YF_SHLINKFLAGS = "-Wl,-soname,libyafaraycore.so.1.0" This is the rpmlint output: yafaray.x86_64: W: spelling-error Summary(en_US) raytracing -> ray tracing, ray-tracing, tracing yafaray.x86_64: W: spelling-error %description -l en_US raytracing -> ray tracing, ray-tracing, tracing yafaray.x86_64: W: spelling-error %description -l en_US Raytracing -> Ray tracing, Ray-tracing, Tracing yafaray.x86_64: W: invalid-license LGPLv2.1 yafaray.x86_64: W: no-soname /usr/lib64/libyafaraycore.so yafaray.x86_64: W: no-manual-page-for-binary yafaray-xml 1 packages and 0 specfiles checked; 0 errors, 6 warnings.
(In reply to comment #84) > However, I have a new .src.rpm here: Thanks Paulo I see you have kept the name as "yafaray" instead of "YafaRay". Did you talk to upstream about this? > I was not able to address the soname issue, because yafaray is compiled using > scons and it is difficul to access the ldd flags. I put a comment in the spec > file where the soname option should be passed, but the compilation fails in > this case. But I am really not sure what is the exact syntax. > > Maybe someone else has a suggestion on how to proceed ... Unfortunately, I can't help with this -- maybe the folks on the SCons mailing list might have an idea? -- http://www.scons.org/lists.php Other than this, I think we're getting close! :)
(In reply to comment #84) ... > I was not able to address the soname issue, because yafaray is compiled using > scons and it is difficul to access the ldd flags. I put a comment in the spec > file where the soname option should be passed, but the compilation fails in > this case. But I am really not sure what is the exact syntax. > > Maybe someone else has a suggestion on how to proceed ... > > #YF_SHLINKFLAGS = "-Wl,-soname,libyafaraycore.so.1.0" Should have be: #YF_SHLINKFLAGS = "-Wl,-soname,libyafaraycore.so.1" But the problem of using such standardized SONAME is that the blender binding to yafaray need to be fixed accordingly to use the new SONAME instead of the unversioned one. This will still work, but only because it will use the yafaray cmd line binary instead of the library. And in this case the rendering option will not be the same. IMO Using unversioned SO is correct by itslef when the said shared object is meant to be dlopen at runtime instead of been linked at build time.
Any update on this bug ?
Sorry Nicolas -- I've been delayed elsewhere; I'll take a look again in the next few days Cheers Rudi
Sorry everyone for the long delay. Paolo, can you comment on the package name please? In light of comment #86 I don't think the SONAME issue should be a blocker.
Hi, I personally do not like capital letters in package names. Every time I have to install the package via yum I never know what is the real package name, for instance, MySQL-python. Furthermore, in the tarball, the main directory is called just yafaray: ------------------------------------------------------------------------ [cascavel:~/redhat/SOURCES] als YafaRay.0.1.1.zip Archive: YafaRay.0.1.1.zip Length Date Time Name --------- ---------- ----- ---- 0 07-30-2009 13:19 yafaray/ 2248 10-03-2007 07:29 yafaray/INSTALL 0 07-30-2009 13:19 yafaray/tools/ 0 07-30-2009 13:19 yafaray/tools/winsetup/ 1560 09-14-2008 13:53 yafaray/tools/winsetup/yafray.iss 532 09-14-2008 13:53 yafaray/tools/winsetup/README_WIN32.txt ------------------------------------------------------------------------ However, I can change the name to YafaRay, just fine, if people think it is more appropriate. I can also include a README.Fedora commenting on the problem with gettext. What do you think? Thanks.
(In reply to comment #90) > Hi, > > I personally do not like capital letters in package names. well paulo, the FPG recommends the package name to match tarball's name: https://fedoraproject.org/wiki/Packaging:NamingGuidelines YafaRay*.zip => %name = YafaRay
Here it goes: SPEC: http://roma.fedorapeople.org/specs/YafaRay.spec SRPM: http://roma.fedorapeople.org/srpms/YafaRay-0.1.1-3.fc14.src.rpm Thanks.
(In reply to comment #92) > Here it goes: > > SPEC: http://roma.fedorapeople.org/specs/YafaRay.spec > > SRPM: http://roma.fedorapeople.org/srpms/YafaRay-0.1.1-3.fc14.src.rpm > > > Thanks. Thanks Paulo, but now we have the package and its subpackages obsoleting themselves: %define yname yafaray ... Provides: yafray = %{version}-%{release} Obsoletes: %{yname} <= %{version}
yafray (without the "a") is the name of the old package until version 0.9 %{ynane) is YafaRay (with lower letters), and it is necessary to force the removal of the package we were using until the previous release. The package is installing just fine: rpm -qi --provides YafaRay YafaRay was written from scratch, and replaces YafRay 0.0.9. After two years of development, it already features a complete set of lighting and rendering options. yafray = 0.1.1-3.fc14 yafaray = 0.1.1-3.fc14 YafaRay = 0.1.1-3.fc14 YafaRay(x86-64) = 0.1.1-3.fc14 ----------------------------- rpm -qi --obsoletes YafaRay YafaRay was written from scratch, and replaces YafRay 0.0.9. After two years of development, it already features a complete set of lighting and rendering options. yafray < 0.1.1 yafaray <= 0.1.1
Sorry; I pasted the wrong "provides" line. The problem is here: Obsoletes: %{yname} <= %{version} Provides: %{yname} = %{version}-%{release} Since we never shipped yafaray, we arguably don't need this Obsoletes: at all, but I agree it's nice to have. If you can change this to: Obsoletes: %{yname} = %{version} (and equivalent for the subpackages) I think we will be done here.
Sorry again: of course I meant: Obsoletes: %{yname} < %{version} !
I see what you mean: YafaRay.x86_64: W: self-obsoletion yafaray <= 0.1.1 obsoletes yafaray = 0.1.1-3.fc14 I fixed it this way: Obsoletes: %{yname} < %{version}-%{release} SRPM: http://roma.fedorapeople.org/srpms/YafaRay-0.1.1-4.fc14.src.rpm Thanks.
(In reply to comment #96) > Sorry again: of course I meant: > > Obsoletes: %{yname} < %{version} That will not work given that %version-%release of the last %{yname} package to Obsoletes (0.1.1-3) is higher than %version of the Obsoletes directive (0.1.1). Usually, it's better to hardcode the Obsoletes field to a value. Specially if you can consider that no yafaray package will not be created anymore from a given %version %release. So I would suggest that: #Introduced in F-15, Can be dropped by F-17 Obsoletes: yafray < 0.1.0 Provides: yafray = %{version}-%{release} Obsoletes: %{yname} < 0.1.1-4 Provides: %{yname} = %{version}-%{release} But I would keep the Provides %{yname} = %{version}-%{release} to avoid case sensitive mess.
Done.
Thanks Nicholas for your input, and Paolo for fixing this last remaining issue. ACCEPTED Please go ahead and make your SCM request.
Thanks, Ruediger and Nicolas, for finishing this review. New Package SCM Request ======================= Package Name: YafaRay Short Description: A raytracing open source render engine Owners: roma Branches: f13 f14 el5 el6 InitialCC:roma
The requested package name doesn't match what's in the ticket summary. Please fix either the ticket summary or the SCM request and re-raise the fedora-cvs flag.
New Package SCM Request ======================= Package Name: YafaRay Short Description: A free open-source raytracing render engine Owners: roma Branches: f13 f14 el5 el6 InitialCC:roma
Git done (by process-git-requests).