Bug 467655 - Review Request: YafaRay - A free open-source raytracing render engine
Review Request: YafaRay - A free open-source raytracing render engine
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ruediger Landmann
Fedora Extras Quality Assurance
http://people.atrpms.net/~pcavalcanti...
:
Depends On: 650471
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-19 22:18 EDT by Paulo Roma Cavalcanti
Modified: 2011-01-27 17:57 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-01-27 17:57:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rlandman: fedora‑review+
tibbs: fedora‑cvs+


Attachments (Terms of Use)
Selinux denial from the yafaray package. (9.75 KB, text/plain)
2009-06-19 17:37 EDT, Nicolas Chauvet (kwizart)
no flags Details
Result of a yafaray test (612.00 KB, image/png)
2009-07-07 13:04 EDT, Jochen Schmitt
no flags Details
backtrace when rendering with a gtk based deskop (15.41 KB, text/plain)
2009-07-30 07:46 EDT, Nicolas Chauvet (kwizart)
no flags Details

  None (edit)
Description Paulo Roma Cavalcanti 2008-10-19 22:18:32 EDT
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:
Comment 1 Nicolas Chauvet (kwizart) 2008-10-20 10:45:08 EDT
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.
Comment 2 Paulo Roma Cavalcanti 2008-10-21 07:45:14 EDT
(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.
Comment 3 Gwyn Ciesla 2008-10-21 08:53:58 EDT
Needs links to spec and srpm.
Comment 4 Paulo Roma Cavalcanti 2008-10-22 16:06:52 EDT
(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
Comment 5 Jochen Schmitt 2008-10-23 13:31:44 EDT
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?
Comment 6 Paulo Roma Cavalcanti 2008-10-23 16:16:53 EDT
(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
Comment 7 Nicolas Chauvet (kwizart) 2008-10-23 19:36:36 EDT
(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.
Comment 8 Paulo Roma Cavalcanti 2008-10-23 21:31:46 EDT
(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...
Comment 9 Paulo Roma Cavalcanti 2008-10-24 05:14:40 EDT
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
Comment 11 Nicolas Chauvet (kwizart) 2008-10-24 09:41:59 EDT
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 ).
Comment 12 Paulo Roma Cavalcanti 2008-10-24 11:00:07 EDT
(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.
Comment 13 Paulo Roma Cavalcanti 2008-10-24 11:36:19 EDT
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.
Comment 14 Paulo Roma Cavalcanti 2008-10-26 09:05:22 EDT
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
Comment 15 Jochen Schmitt 2008-10-26 15:52:50 EDT
(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.
Comment 16 Jochen Schmitt 2008-10-26 15:57:13 EDT
(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.
Comment 17 Jochen Schmitt 2008-10-26 16:49:17 EDT
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.
Comment 18 Paulo Roma Cavalcanti 2008-10-26 19:00:09 EDT
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.
Comment 19 Nicolas Chauvet (kwizart) 2008-10-30 18:53:36 EDT
(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.
Comment 20 Paulo Roma Cavalcanti 2008-10-30 22:19:34 EDT
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
Comment 21 Paulo Roma Cavalcanti 2008-10-31 05:06:05 EDT
#!/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"
Comment 22 Nicolas Chauvet (kwizart) 2008-10-31 05:50:30 EDT
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.
Comment 23 Nicolas Chauvet (kwizart) 2008-10-31 06:37:37 EDT
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).
Comment 24 Paulo Roma Cavalcanti 2008-10-31 12:13:38 EDT
(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).
Comment 25 Paulo Roma Cavalcanti 2008-11-03 12:40:48 EST
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?
Comment 26 Nicolas Chauvet (kwizart) 2008-11-10 18:54:47 EST
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...
Comment 27 Paulo Roma Cavalcanti 2008-11-11 09:34:53 EST
(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
Comment 28 Paulo Roma Cavalcanti 2008-11-11 09:36:18 EST
Sorry. The correct spec is:

http://people.atrpms.net/~pcavalcanti/specs/yafaray.spec
Comment 29 Paulo Roma Cavalcanti 2008-11-11 17:06:30 EST
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
Comment 30 Nicolas Chauvet (kwizart) 2009-01-22 10:35:54 EST
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 ?
Comment 31 Paulo Roma Cavalcanti 2009-01-26 09:05:08 EST
(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}.
Comment 32 Jochen Schmitt 2009-01-26 12:44:12 EST
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.
Comment 33 Jochen Schmitt 2009-05-12 12:30:36 EDT
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.
Comment 34 Paulo Roma Cavalcanti 2009-05-12 16:48:29 EDT
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
Comment 35 Nicolas Chauvet (kwizart) 2009-05-12 17:04:59 EDT
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).
Comment 36 Paulo Roma Cavalcanti 2009-05-12 18:27:05 EDT

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.
Comment 37 Nicolas Chauvet (kwizart) 2009-05-12 19:57:38 EDT
> (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.
Comment 38 Paulo Roma Cavalcanti 2009-05-23 20:29:51 EDT
(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?
Comment 39 Jochen Schmitt 2009-05-24 16:52:40 EDT
(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
Comment 40 Paulo Roma Cavalcanti 2009-05-24 17:09:17 EDT

> 
> 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.
Comment 41 Jochen Schmitt 2009-05-25 11:14:53 EDT
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
Comment 42 Paulo Roma Cavalcanti 2009-05-31 07:12:11 EDT
Thanks, Jochen


There are rpms available for Fedora here:

http://atrpms.net/name/yafaray/


Therefore, anyone willing to test them are welcome.
Comment 43 Nicolas Chauvet (kwizart) 2009-05-31 10:26:00 EDT
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.
Comment 44 Paulo Roma Cavalcanti 2009-05-31 10:49:56 EDT
(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?
Comment 45 Paulo Roma Cavalcanti 2009-05-31 11:09:01 EDT
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.
Comment 46 Nicolas Chauvet (kwizart) 2009-06-01 04:50:55 EDT
(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).
Comment 47 Paulo Roma Cavalcanti 2009-06-01 05:38:06 EDT
(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.
Comment 48 Jochen Schmitt 2009-06-01 16:54:39 EDT
I want to inform you, that blender-2.49 will available in rawhide in the next days.
Comment 49 Paulo Roma Cavalcanti 2009-06-11 14:15:48 EDT
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
Comment 50 Nicolas Chauvet (kwizart) 2009-06-11 19:03:38 EDT
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.
Comment 51 Paulo Roma Cavalcanti 2009-06-11 19:53:09 EDT
(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).
Comment 52 Nicolas Chauvet (kwizart) 2009-06-12 08:09:41 EDT
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/.
Comment 53 Nicolas Chauvet (kwizart) 2009-06-19 10:47:30 EDT
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).
Comment 54 Nicolas Chauvet (kwizart) 2009-06-19 17:37:38 EDT
Created attachment 348714 [details]
Selinux denial from the yafaray package.
Comment 55 Paulo Roma Cavalcanti 2009-06-22 06:57:02 EDT
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.
Comment 56 Jochen Schmitt 2009-06-25 12:15:38 EDT
I want to nofify you, that blender-2.94a is in updates-testing.
Comment 57 Nicolas Chauvet (kwizart) 2009-07-06 16:23:25 EDT
Can I have an update of yafaray package to be compliant with selinux ?
Comment 58 Jochen Schmitt 2009-07-07 13:04:06 EDT
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
Comment 59 Jochen Schmitt 2009-07-07 13:09:14 EDT
Additional information for Comment #58: I have set the enforcing level of SELinux to Enforcing to make sure, that yafaray runs with SELinux.
Comment 60 Nicolas Chauvet (kwizart) 2009-07-07 13:21:28 EDT
(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 !
Comment 61 Jochen Schmitt 2009-07-07 13:48:13 EDT
(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.
Comment 62 Paulo Roma Cavalcanti 2009-07-07 13:58:20 EDT
I have already reported the problem:

https://bugzilla.redhat.com/show_bug.cgi?id=510113
Comment 63 Daniel Walsh 2009-07-07 14:19:25 EDT
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.
Comment 64 Paulo Roma Cavalcanti 2009-07-07 22:42:02 EDT
(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
Comment 65 Daniel Walsh 2009-07-09 08:50:37 EDT
Uli, do you have any ideas?
Comment 66 Ulrich Drepper 2009-07-09 10:13:48 EDT
(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.
Comment 67 Nicolas Chauvet (kwizart) 2009-07-30 03:58:33 EDT
(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
-------------------------------------------
Comment 68 Nicolas Chauvet (kwizart) 2009-07-30 07:46:51 EDT
Created attachment 355661 [details]
backtrace when rendering with a gtk based deskop
Comment 69 Ulrich Drepper 2009-07-30 11:05:26 EDT
(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.
Comment 70 Paulo Roma Cavalcanti 2009-07-30 11:33:37 EDT
(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
Comment 71 Jochen Schmitt 2009-07-30 16:31:29 EDT
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.
Comment 72 Paulo Roma Cavalcanti 2009-07-31 05:41:23 EDT
The links are dead.
Comment 73 Paulo Roma Cavalcanti 2009-08-31 17:01:07 EDT
The latest version is here:

http://atrpms.net/name/yafaray/
Comment 74 Nicolas Chauvet (kwizart) 2009-08-31 17:17:13 EDT
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 ?
Comment 76 Jochen Schmitt 2009-09-08 15:35:16 EDT
I will only inform you, that I have submitted blender-2.49b on rawhode.
Comment 77 Paulo Roma Cavalcanti 2009-12-03 07:12:40 EST
I am NOT having any selinux issue on F12 (enforcing policy).

Anyone still having problems?
Comment 78 Nicolas Chauvet (kwizart) 2010-04-07 10:36:37 EDT
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.
Comment 79 Diogo Lima 2010-05-12 06:09:12 EDT
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.
Comment 80 Ruediger Landmann 2010-11-03 04:28:15 EDT
I built and installed the package linked in comment #75 and it worked fine on 64-bit Fedora 13 with Blender 2.49b-9
Comment 81 Ruediger Landmann 2010-11-03 22:41:48 EDT
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.
Comment 82 Paulo Roma Cavalcanti 2010-11-04 10:12:07 EDT
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?
Comment 83 Rex Dieter 2010-11-06 15:07:20 EDT
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.
Comment 84 Paulo Roma Cavalcanti 2010-11-07 17:07:18 EST
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.
Comment 85 Ruediger Landmann 2010-11-11 20:41:29 EST
(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! :)
Comment 86 Nicolas Chauvet (kwizart) 2010-11-12 07:14:05 EST
(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.
Comment 87 Nicolas Chauvet (kwizart) 2010-12-15 17:33:48 EST
Any update on this bug ?
Comment 88 Ruediger Landmann 2010-12-16 01:00:34 EST
Sorry Nicolas -- I've been delayed elsewhere; I'll take a look again in the next few days

Cheers
Rudi
Comment 89 Ruediger Landmann 2011-01-21 00:35:13 EST
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.
Comment 90 Paulo Roma Cavalcanti 2011-01-21 05:12:37 EST
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.
Comment 91 Ralf Corsepius 2011-01-21 06:14:12 EST
(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
Comment 92 Paulo Roma Cavalcanti 2011-01-21 07:27:48 EST
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.
Comment 93 Ruediger Landmann 2011-01-23 23:24:15 EST
(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}
Comment 94 Paulo Roma Cavalcanti 2011-01-24 03:24:07 EST
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
Comment 95 Ruediger Landmann 2011-01-25 01:18:46 EST
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.
Comment 96 Ruediger Landmann 2011-01-25 01:19:35 EST
Sorry again: of course I meant:

Obsoletes:      %{yname} < %{version}

!
Comment 97 Paulo Roma Cavalcanti 2011-01-25 05:51:11 EST
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.
Comment 98 Nicolas Chauvet (kwizart) 2011-01-25 06:11:52 EST
(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.
Comment 99 Paulo Roma Cavalcanti 2011-01-25 08:30:05 EST
Done.
Comment 100 Ruediger Landmann 2011-01-26 17:52:01 EST
Thanks Nicholas for your input, and Paolo for fixing this last remaining issue.

ACCEPTED

Please go ahead and make your SCM request.
Comment 101 Paulo Roma Cavalcanti 2011-01-26 18:31:04 EST
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
Comment 102 Jason Tibbitts 2011-01-27 10:03:49 EST
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.
Comment 103 Paulo Roma Cavalcanti 2011-01-27 10:13:19 EST
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
Comment 104 Jason Tibbitts 2011-01-27 10:27:15 EST
Git done (by process-git-requests).

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