Bug 458090 - Review Request: LuxRender - Lux Renderer, an unbiased rendering system
Review Request: LuxRender - Lux Renderer, an unbiased rendering system
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jochen Schmitt
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-06 10:01 EDT by Nicolas Chauvet (kwizart)
Modified: 2009-05-18 07:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 481676 (view as bug list)
Environment:
Last Closed: 2009-05-18 07:46:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
jochen: fedora‑review+
kevin: fedora‑cvs+


Attachments (Terms of Use)

  None (edit)
Description Nicolas Chauvet (kwizart) 2008-08-06 10:01:52 EDT
Spec URL:
http://kwizart.fedorapeople.org/SPECS/LuxRender.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/LuxRender-0.5-1.fc9.kwizart.src.rpm
Description: Lux Renderer, an unbiased rendering system
Comment 1 Jason Tibbitts 2008-08-16 13:24:37 EDT
This fails to build for me:

error:
syntax error in expression
error:
/builddir/build/SPECS/LuxRender.spec:79: parseExpressionBoolean returns -1

I've starred line 79:

  %cmake \
    -CMAKE_VERBOSE_MAKEFILE:BOOL=TRUE \
    -DCMAKE_SKIP_RPATH:BOOL=ON \
* %if %{?_lib} == "lib64"
    -DLIBDIR=%{_lib} \
  %endif
  ..
Comment 2 Nicolas Chauvet (kwizart) 2008-09-03 10:54:08 EDT
This was fixed in yesterday rpm update

Unfortunately re-submit failed. (need to handle newer boost update probably)
http://koji.fedoraproject.org/koji/getfile?taskID=802082&name=build.log
Comment 3 Nicolas Chauvet (kwizart) 2009-01-20 10:28:54 EST
Spec URL:
http://kwizart.fedorapeople.org/SPECS/LuxRender.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/LuxRender-0.5-2.fc10.src.rpm
Description: Lux Renderer, an unbiased rendering system

Koji build on Rawhide
http://koji.fedoraproject.org/koji/taskinfo?taskID=1068814

Changelog
- Fix compilation with boost 1.34 - (backport)
- Subpackage the Blender_Exporter plugin 
- Subpackage -devel-docs for doxygen docs.

Note, despite been checked with cmake, the libXdamage-devel aren't needed. I will remove the dependency before import.
Comment 4 Jochen Schmitt 2009-01-20 15:01:57 EST
I couldn't download the source rpm. I have got a 404 Page not found.
Comment 5 Nicolas Chauvet (kwizart) 2009-01-20 15:15:01 EST
fixed, (deleted the new src.rpm instead of the older by mistake).

@Jochen
btw. I have a very bad problem with the way blender create the ~/.blender directory nowadays. the main issue is that directories created with the "blender-wrapper"  script are set root:root even in /home/user directories.
Can we be more in shape with what upstream does in this area ?
Comment 6 Jochen Schmitt 2009-01-20 15:34:44 EST
I have a look on my own system. On my system the .blender directory is owned by my onw userid. The Directory should be create on the first start of blender.
Comment 7 Nicolas Chauvet (kwizart) 2009-01-20 15:55:30 EST
------------------------
LuxBlend v0.5

WARNING: LuxPath "" is not valid

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "/usr/share/blender/scripts/bpymodules/BPyRegistry.py", line 267, in SaveConfigData
    raise Warning(e) # Resend exception as warning
Warning: [Errno 13] Permission denied: '/home/kwizart/.blender/scripts/bpydata/config/luxblend.cfg'
------------------------

And as ~/.blender/scripts/bpydata/readme.txt say.the bpydata directory is a place for plugin to put their data into. Unfortunately, in the current state of the blender-wrapper script, it is a symlink to /usr/share/blender/scripts/bpydata, hence, cannot be written unless root.

I don't know if there is a solution that can avoid to duplicate the system plugins while allowing for system plugins to write their data into by-users directory.
Can we just patch the config directory for python plugin instead ? (so both system/users and arch/noarches plugins can use the same config directory?).
Comment 8 Nicolas Chauvet (kwizart) 2009-01-20 16:52:52 EST
This is not easy: 
- to ease the installation of the LuxBlend plugin, I should put a luxrender.cfg into /usr/share/blender/scripts/bpydata/config/luxblend.cfg and that file need to be transferred to the user directory even if the ~/.blender directory was already created but not if the luxrender.cfg file is already present.

Will you accept extensions to your blender-wrapper script ?
Something like:
for f in /etc/blender-wrapper.d ; do 
  sh ${f}
done
Comment 9 Jochen Schmitt 2009-01-21 12:29:01 EST
I don't unterstand you issue: 

I have done the following:
1.) Build your package locally.
2.) Install it
3.) Start blender, so the wrapper script should create the symlinks
4.) View the ~/.blender/scripts directory

I have got the following expected result:

lrwxrwxrwx 1 s4504kr s4504kr   42 21. Jan 18:24 LuxBlend_0.1.py -> /usr/share/blender/scripts/LuxBlend_0.1.py
lrwxrwxrwx 1 s4504kr s4504kr   43 21. Jan 18:24 LuxBlend_0.1.pyc -> /usr/share/blender/scripts/LuxBlend_0.1.pyc
lrwxrwxrwx 1 s4504kr s4504kr   43 21. Jan 18:24 LuxBlend_0.1.pyo -> /usr/share/blender/scripts/LuxBlend_0.1.pyo
Comment 10 Nicolas Chauvet (kwizart) 2009-01-21 12:44:49 EST
that's not what will append for real:
1- As the per user ~/.blender directory is already created no more files will be copied to the user directory.
2- Nobody wants to write on LuxBlend_0.1.py?. Instead what the plugin expects is to write in its config directory and in its content directory. (see the readme.txt).
Please note that the permission you have showed are the perm of the symlinks, not the perms of the files.
Comment 11 Jochen Schmitt 2009-01-21 12:53:20 EST
(In reply to comment #10)
> that's not what will append for real:
> 1- As the per user ~/.blender directory is already created no more files will
> be copied to the user directory.

Sorry, On eatch start of blender there will be creating symlink from ~/.blnder/scripts to /usr/share/blender/scripts.

> 2- Nobody wants to write on LuxBlend_0.1.py?. Instead what the plugin expects
> is to write in its config directory and in its content directory. (see the
> readme.txt).

I can't find your readme.txt file
Comment 12 Nicolas Chauvet (kwizart) 2009-01-21 13:16:43 EST
(In reply to comment #11)
> (In reply to comment #10)
> > that's not what will append for real:
> > 1- As the per user ~/.blender directory is already created no more files will
> > be copied to the user directory.
> 
> Sorry, On eatch start of blender there will be creating symlink from
> ~/.blnder/scripts to /usr/share/blender/scripts.
It depends on where you consider your error is, so as you like: but quoting blender-wrapper:
When "" if [ ! -d ~/.blender ]; then ""
    install -d ~/.blender/scripts
    ln -sf /usr/share/blender/scripts/bpydata ~/blender/scripts/bpydata
^^ this part is wrong - and a misunderstanding of what bpydata and bpydata/config directories are
(namely the content and configuration directories for scripts that are meant to be user <<<writable>>>).
But there is a typo (blender instead of .blender) so it doesn't work anyway.

Then,:
rm -r ~/.blender/scripts/*.p*
Why end-users aren't allowed to have their own scripts ?


> > 2- Nobody wants to write on LuxBlend_0.1.py?. Instead what the plugin expects
> > is to write in its config directory and in its content directory. (see the
> > readme.txt).
> 
> I can't find your readme.txt file
rpm -ql blender |grep readme.txt


I'm still unsure of the accurate solution, so it is just workinprogress thoughts.
Comment 13 Nicolas Chauvet (kwizart) 2009-03-16 22:19:08 EDT
Spec URL:
http://kwizart.fedorapeople.org/SPECS/LuxRender.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/LuxRender-0.5-3.fc10.src.rpm
Description: Lux Renderer, an unbiased rendering system

http://koji.fedoraproject.org/koji/taskinfo?taskID=1245132

As said in /usr/share/blender/scripts/bpydata/config/readme.txt
"This folder is for automatically saved scripts configuration data."
It means user writable. Nevertheless it remains relative to the blender script directory which is ~/.blender/scripts. (Thus, ~/.blender/scripts/bpydata/config/* should be user writable along with ./scripts/bpydata/)

This directory (/usr/share/blender/scripts/bpydata/config/ ) can be seen as where to store the configuration files for each blender plugin to provide the default configuration. Each files are meant to be copied into ~/.blender/scripts/bpydata/config/ so end-user can tweak their configuration. This directory aren't meant to be deleted in anycase in the cost of loosing the user's plugin configuration.
Comment 14 Nicolas Chauvet (kwizart) 2009-03-16 22:26:24 EDT
There was a typo in the submitted src.rpm:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1245151
Comment 15 Nicolas Chauvet (kwizart) 2009-03-16 22:33:08 EDT
Again:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1245169
Comment 16 Jochen Schmitt 2009-05-06 15:41:15 EDT
I would take a look on your source RPM. But It's seems, it is not available on koji anymore.
Comment 17 Nicolas Chauvet (kwizart) 2009-05-06 16:14:01 EDT
(In reply to comment #16)
> I would take a look on your source RPM. But It's seems, it is not available on
> koji anymore.  
Spec URL:
http://kwizart.fedorapeople.org/SPECS/LuxRender.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/LuxRender-0.5-3.fc10.src.rpm
Description: Lux Renderer, an unbiased rendering system

^^ This one is still valid (0.6 is nearing, but 0.5 is fine also)
Comment 18 Jochen Schmitt 2009-05-06 16:41:06 EDT
I have test the symlink createn in ~/.blender/scripts with installed blender and blender-freeworld. the accept symlinks was created during the start of blender.
Comment 19 Nicolas Chauvet (kwizart) 2009-05-06 17:05:03 EDT
(In reply to comment #18)
> I have test the symlink createn in ~/.blender/scripts with installed blender
> and blender-freeworld. the accept symlinks was created during the start of
> blender.  

I'm not sure to understand well...
Anyway, would you take this test case:
- Install blender (or the other variant).
- Run blender to ensure the user script directory got created
- Install LuxRender
- Check that the LuxRender scripts ends in the end-user directory.
- Verify that the LuxRender exports scripts are available from the blender window, and that end-user can tweak LuxRender configuration (which must persist on next blender run).
Comment 20 Jochen Schmitt 2009-05-07 12:56:50 EDT
Sorry, You have to install blender and TuxRender first.

If you run blender after install both packages the ~/.blener/script directory and all symlinks will been created.

I have taken a look on my installation and could found the Texblender export menu entry.
Comment 21 Nicolas Chauvet (kwizart) 2009-05-07 13:04:31 EDT
(In reply to comment #20)
> Sorry, You have to install blender and TuxRender first.
> 
> If you run blender after install both packages the ~/.blener/script directory
> and all symlinks will been created.
Right, and that's "the" problem... What upstream think about that ?
Of course, most blender plugin extensions will be installed next to blender is run. the blender plugin directory isn't meant to be used only by blender, but plugins such as LuxRender should be allowed to store per-user configuration files...
 
> I have taken a look on my installation and could found the Texblender export
> menu entry.  
right but once blender is first run when LuxRender was previously installed...
Comment 22 Jochen Schmitt 2009-05-07 13:54:46 EDT
Good:
+ Base name of the SPEC files matches with package name.
+ Package name fits with the naming convention
* URI tag shows on proper project homepage
* Could downloads sources with spectool -g
+ Sources in Source package matches with upstream
(md5sum: 02174b85917b68ac5f681a4f117b7bd  LuxRender_v05_Source.zip
         7cb0920c7c77ebaa5d7a721be124a27f LuxBlend_v05_Blender_Exporter.zip)
* Package contains several subpackage
+ Package contains valid license tag
+ License Tag contains GPLv3+ and BSD as valid OpenSource licenses
+ Upstream sources contains verbatins copy of the licenses
+ License note in source files seems to mach license tag
+ Consistently usage of rpm macros
+ Proper BuildRoot tag
+ Buildroot will be cleaned on the start of %install and %clean
+ Rpmlint is silent on source RPM.
+ RPM_OPT_FLAGS will honoured.
+ Debuginfo package contains sources
+ Koji scratch build works fine.
* Local build works fine.
* Local install and uninstall works fine.
+ Start of the application works fine
+ Menu entry is ok
+ %files stanza contains no duplicates
+ Package contains proper %Changelog entries


TODO
- Please set blender requirement to bleder >= 2.48a-21 to
  make sure, that the script are available in a corret was.
- Why you add an Req rom the devel-docs package to the main
  Package.
- Please moveove content of the %doc stanza of the libs subpackage
  to the main package
- Rpmlint complaints on binary RPMs:
pmlint LuxRender-*
LuxRender.x86_64: W: no-documentation
LuxRender-blender.x86_64: W: no-documentation
LuxRender-blender.x86_64: E: wrong-script-interpreter /usr/share/blender/scripts/LuxBlend_0.1.py "BPY"
OK.: Blender specific
LuxRender-blender.x86_64: E: non-executable-script /usr/share/blender/scripts/LuxBlend_0.1.py 0644
Should be fixed.
LuxRender-blender.x86_64: E: wrong-script-end-of-line-encoding /usr/share/blender/scripts/LuxBlend_0.1.py
Should be fixed.
LuxRender-core.x86_64: W: no-documentation
OK.
LuxRender-devel.x86_64: W: no-documentation
OK.
LuxRender-lib.x86_64: W: shared-lib-calls-exit /usr/lib64/liblux.so.1.0 exit@GLIBC_2.2.5
May be OK.
Comment 23 Jochen Schmitt 2009-05-07 13:58:07 EDT
(In reply to comment #21)
> (In reply to comment #20)
> > Sorry, You have to install blender and TuxRender first.
> > 
> > If you run blender after install both packages the ~/.blener/script directory
> > and all symlinks will been created.
> Right, and that's "the" problem... What upstream think about that ?

Which upstream?

> Of course, most blender plugin extensions will be installed next to blender is
> run. the blender plugin directory isn't meant to be used only by blender, but
> plugins such as LuxRender should be allowed to store per-user configuration
> files...

???

> 
> > I have taken a look on my installation and could found the Texblender export
> > menu entry.  
> right but once blender is first run when LuxRender was previously installed... 

Yes, Yout must install LuxRender first, before you can see this entries. What is your issue?
Comment 24 Nicolas Chauvet (kwizart) 2009-05-13 11:56:19 EDT
(In reply to comment #22)
...
> TODO
> - Please set blender requirement to bleder >= 2.48a-21 to
>   make sure, that the script are available in a corret was.
You contradict yourself with this demand:

Either you consider that blender isn't installed and having unversioned requires will be enought to bring the lastest blender release, either blender is already installed despite not up2date, and we chances are hight that the LuxRender-blender files will never be copied to the end-user directory anyway.

As a consequence, using a versioned requires will introduce another problem:
LuxRender works pretty well with blender version < 2.48a.
I would like to avoid the introduction of other problem.

> - Why you add an Req rom the devel-docs package to the main
>   Package.
Thx for having noticed, I've removed it

> - Please moveove content of the %doc stanza of the libs subpackage
>   to the main package
The original
> - Rpmlint complaints on binary RPMs:
> pmlint LuxRender-*
> LuxRender.x86_64: W: no-documentation
> LuxRender-blender.x86_64: W: no-documentation
> LuxRender-blender.x86_64: E: wrong-script-interpreter
> /usr/share/blender/scripts/LuxBlend_0.1.py "BPY"
> OK.: Blender specific
> LuxRender-blender.x86_64: E: non-executable-script
> /usr/share/blender/scripts/LuxBlend_0.1.py 0644
> Should be fixed.
Not necessarily, it depends upon the said script is meant to be sourced or executed directly.If you look at /usr/lib64/python*/, you will see that very few files are set +x (probably by misstake actually)

> LuxRender-blender.x86_64: E: wrong-script-end-of-line-encoding
> /usr/share/blender/scripts/LuxBlend_0.1.py
> Should be fixed.
Fixed, thx for having noticed.


Upload in Progress...
Comment 25 Nicolas Chauvet (kwizart) 2009-05-13 12:00:05 EDT
> - Please moveove content of the %doc stanza of the libs subpackage
>   to the main package
The original reason was that -lib subpackage will be installed anyway.
But it can be moved to the main also.
Comment 26 Nicolas Chauvet (kwizart) 2009-05-13 12:06:01 EDT
Spec URL:
http://kwizart.fedorapeople.org/SPECS/LuxRender.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/LuxRender-0.5-4.fc10.src.rpm
Description: Lux Renderer, an unbiased rendering system

Changelog
- Move %%doc from -lib to main
- Remove Requires main from -devel-docs
- Disable wrong-end-of-line-encoding for LuxBlend_0.1.py
Comment 27 Nicolas Chauvet (kwizart) 2009-05-13 12:35:11 EDT
for the blender plugin directory and the plugin installation problem.
I think the solution is to symlinks every files present from /usr/share/blender/scripts/*.py* to the ~/.blender/scripts directory unconditionaly when blender is run.
Then, each files from /usr/share/blender/scripts/bpydata/config/* but not present in the ~/.blender/scripts/bpydata/config/ directory need to be copied to the end-user directory
(file aren't expected to be copied from /usr/share/blender/scripts/bpydata/* since they are meant to be temporary files.)

Unfortunately, I'm not sure what Blender.Get("datadir") is. It probably doesn't match our datadir, specially as it may be used for architecture dependent plugin (thinking about the yafaray case). But I wonder if it wouldn't have been easier to take theses:

%{python_sitelib}/blender/
%if %{_lib} == "lib64"
%{python_sitearch}/blender/
%endif
Comment 28 Jochen Schmitt 2009-05-13 13:54:33 EDT
(In reply to comment #27)
> for the blender plugin directory and the plugin installation problem.
> I think the solution is to symlinks every files present from
> /usr/share/blender/scripts/*.py* to the ~/.blender/scripts directory
> unconditionaly when blender is run.

This should be done by the current blender-wrapper script in the devel branch.

> Then, each files from /usr/share/blender/scripts/bpydata/config/* but not
> present in the ~/.blender/scripts/bpydata/config/ directory need to be copied
> to the end-user directory
> (file aren't expected to be copied from /usr/share/blender/scripts/bpydata/*
> since they are meant to be temporary files.)

Should be done in 2.48a-22
> 
> Unfortunately, I'm not sure what Blender.Get("datadir") is. It probably doesn't
> match our datadir, specially as it may be used for architecture dependent
> plugin (thinking about the yafaray case). But I wonder if it wouldn't have been
> easier to take theses:
> 
> %{python_sitelib}/blender/
> %if %{_lib} == "lib64"
> %{python_sitearch}/blender/
> %endif  

This should no be an issue.
Comment 29 Jochen Schmitt 2009-05-13 13:58:37 EDT
(In reply to comment #24)
> (In reply to comment #22)
> ...
> > TODO
> > - Please set blender requirement to bleder >= 2.48a-21 to
> >   make sure, that the script are available in a corret was.
> You contradict yourself with this demand:
> 
> Either you consider that blender isn't installed and having unversioned
> requires will be enought to bring the lastest blender release, either blender
> is already installed despite not up2date, and we chances are hight that the
> LuxRender-blender files will never be copied to the end-user directory anyway.
> 
> As a consequence, using a versioned requires will introduce another problem:
> LuxRender works pretty well with blender version < 2.48a.
> I would like to avoid the introduction of other problem.
> 

Regarding to the last comment pleas set the Req. to blender >= 2.48a-22. This release or a later release will be introduced  on F-11 and F-10 after APPROVING of this review

Please keep in mind, that belder-2.49 is upcomming soom.
Comment 30 Nicolas Chauvet (kwizart) 2009-05-14 08:07:16 EDT
From the blender -22 commit, it should be okay now, so : Wonderfull !
Okay, I've added blender >= 2.48a-22 to the -blender sub package !
(Can I avoid a re-upload ?)
Comment 31 Jochen Schmitt 2009-05-14 11:06:35 EDT
OK, As far as I can see, all is OK, so you are APPROVED.
Comment 32 Nicolas Chauvet (kwizart) 2009-05-14 11:33:16 EDT
New Package CVS Request
=======================
Package Name: LuxRender
Short Description: Lux Renderer, an unbiased rendering system
Owners: kwizart
Branches: F-11 F-10 EL-5
Cvsextras Commits: yes
Comment 33 Kevin Fenzi 2009-05-15 19:45:29 EDT
cvs done.
Comment 34 Jochen Schmitt 2009-05-17 14:46:32 EDT
I have build the -22 release for F-11 and F-10. It will be nice, if you can bundeled it which your update request.

At least I want to offer you the co-maintainership for blender if you want.
Comment 35 Nicolas Chauvet (kwizart) 2009-05-18 07:46:11 EDT
(In reply to comment #34)
> I have build the -22 release for F-11 and F-10. It will be nice, if you can
> bundeled it which your update request.
OK, I've just imported LuxRender.
> 
> At least I want to offer you the co-maintainership for blender if you want.  
Thx, I accept.

I guess I need to be approved on the blender acl in order to request an update.
So I will update both blender/LuxRender then.


Thx for this review.

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