Bug 241549 - Review Request: Pixie - 3D renderer Renderman compliant
Summary: Review Request: Pixie - 3D renderer Renderman compliant
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Xavier Lamien
QA Contact: Fedora Package Reviews List
Depends On:
TreeView+ depends on / blocked
Reported: 2007-05-28 00:45 UTC by Nicolas Chauvet (kwizart)
Modified: 2007-11-30 22:12 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2007-09-08 02:20:43 UTC
lxtnow: fedora-review+
kevin: fedora-cvs+

Attachments (Terms of Use)
pixie-2.1.1-build.log (81.65 KB, text/plain)
2007-06-02 17:08 UTC, Xavier Lamien
no flags Details
fedora-7-x86_64 build.log (327.73 KB, text/plain)
2007-06-27 19:39 UTC, Nicolas Chauvet (kwizart)
no flags Details

Description Nicolas Chauvet (kwizart) 2007-05-28 00:45:35 UTC
Spec URL:
Description: 3D renderer Renderman compliant

rpmlint complaint about non-executable scripts and wrong script interpreter about shaders but theses files aren't mean to be executed...

tested in mock Fedora Core 6 on x86

Comment 1 Philippe Valembois 2007-05-28 13:57:14 UTC
RPMLint output is empty
Compiles under mock fc6-i386

URL of the package is bad : cf

Comment 2 Xavier Lamien 2007-05-31 02:08:55 UTC
[in reply to comment #1]



Avoid to use as more possible a mirror url from sourceforge website.
So, the use of "source0: download.sourceforge.net/pixie/Pixie-2.1.1.tgz" is more
appropriate. ;)


Starting review....

Comment 3 Xavier Lamien 2007-06-02 17:08:48 UTC
Created attachment 155990 [details]

Mock failed on FC-6 and F-7 (i386) and seem freeze on x86_64.
see build log for details.

Comment 4 Nicolas Chauvet (kwizart) 2007-06-02 18:38:24 UTC
g++: Internal error: Killed (program cc1plus)
You should say it if you killed the compiler!

As state in a doc file, compilation take a lot of time because of optimization...
It takes about 20min on my dual core

Comment 5 Xavier Lamien 2007-06-02 23:40:29 UTC
^^ nope, i don't send kill signal to g++.

i will re-launch the build to check

Comment 6 Nicolas Chauvet (kwizart) 2007-06-03 21:23:17 UTC
OK i get wrong it takes around two hours to compile on x86_64 for Fedora 7 with
my AMD64 X2 (it take less time on x86)... I have 2go of dual channel memory...
The system is instable during this indeed... 

My ISP website is offline...
Here is a mirror:
Spec URL:
Description: 3D renderer Renderman compliant

Comment 7 Nicolas Chauvet (kwizart) 2007-06-03 21:24:59 UTC
Well also about URL for sourceforge... All others URL format are failing,
This is the only format that can retrieve sources...

Comment 8 Xavier Lamien 2007-06-06 21:13:38 UTC
mock's on its way

Comment 9 Xavier Lamien 2007-06-07 03:55:57 UTC
it seem still failed to build on my virtual machines with same error above.
i will try on physical one by tomorrow.

Comment 10 Mamoru TASAKA 2007-06-07 06:52:48 UTC
(In reply to comment #5)
> ^^ nope, i don't send kill signal to g++.
> i will re-launch the build to check

Perhaps killed by OOM (Out Of Memory) killer...

On my machine (with 768M RAM + about 780M swaps), g++
on execute.cpp ate all memory + swap and finally was killed
by OOM killer...

Comment 11 Mamoru TASAKA 2007-06-07 06:58:32 UTC
Perhaps you can see the message in /var/log/messages like this:
Jun  7 15:46:50 localhost kernel: printk: 6 messages suppressed.
Jun  7 15:46:50 localhost kernel: xterm invoked oom-killer: gfp_mask=0x201d2,
order=0, oomkilladj=0
Jun  7 15:46:51 localhost kernel:  [<c045c844>] out_of_memory+0x69/0x185
Jun  7 15:47:07 localhost kernel: Out of memory: kill process 9504 (g++) score
129440 or a child
Jun  7 15:47:07 localhost kernel: Killed process 9505 (cc1plus)

Comment 12 Xavier Lamien 2007-06-10 00:58:24 UTC
Hi Mamoru,

i'll check this out and launch the test on my main machine which has 2go of
memory (dual channel) 

Comment 13 Mamoru TASAKA 2007-06-10 02:03:54 UTC
Okay. Please go again. Actually rebuilding this package
is too heavy for my machine...

Comment 14 Xavier Lamien 2007-06-16 00:03:05 UTC

Same things with my main machine :(
it seem that we need a powerfull config to make this package build on x86_64.
Rebuilt on i386 and after few hour successfully done.

Nicolas, could you upload the build log from x86_64 ?

Comment 15 Xavier Lamien 2007-06-21 13:38:23 UTC

Comment 16 Nicolas Chauvet (kwizart) 2007-06-21 21:23:44 UTC
I will submit build for x86_64 next week-end...

Comment 17 Nicolas Chauvet (kwizart) 2007-06-27 19:39:24 UTC
Created attachment 158048 [details]
fedora-7-x86_64 build.log

This take around one hour to build on my amd64 x2 4200+ with 2GO dual

Comment 18 Xavier Lamien 2007-07-08 03:30:19 UTC

Starting review...

Comment 19 Xavier Lamien 2007-07-14 04:48:58 UTC

 [ FAILED ] Package is named according to the Package Naming Guidelines.
 [ FAILED ] Spec file name must match the base package name.
 [ OK ] Package meets the Packaging Guidelines.
 [ OK ] Package successfully builds into binary rpms on at least one
        supported architecture.
 [ CHECK ] Tested on: Mock i386 [FC-devel]

 [ OK ] Package is not relocatable.
 [ OK ] Buildroot is correct
 [ OK ] Package is licensed with an open-source compatible license.
 [ Ok ] License field in the package spec file matches the actual license.
 [ OK ] License type: LGPL
 [ OK ] The source package includes the text of the license(s).
 [ OK ] Spec file is legible and written in American English.
 [ OK ] Package is not known to require ExcludeArch.
 [ OK ] All build dependencies are listed in BuildRequires.
 [ CHECK ] The spec file handles locales properly.
 [ OK ] ldconfig called in %post and %postun if required.
 [ ? ] Package must own all directories that it creates.
 [ OK ] Package requires other packages for directories it uses.
 [ OK ] Package does not contain duplicates in %files.
 [ Ok ] Permissions on files are set properly.
 [ OK ] Package has a %clean section.
 [ OK ] Package consistently uses macros.
 [ OK ] Package contains code, or permissable content.
 [ ? ] Large documentation files are in a -doc subpackage, if required.
 [ ? ] Package uses nothing in %doc for runtime.
 [ SKIP ] Header files in -devel subpackage, if present.
 [ SKIP ] Static libraries in -devel subpackage, if present.
 [ SKIP ] Package requires pkgconfig, if .pc files are present.
 [ Ok ] Development .so files in -devel subpackage, if present.
 [ Ok ] Fully versioned dependency in subpackages, if present.
 [ OK ] Package does not contain any libtool archives (.la).
 [ SKIP ] Package contains a properly installed %{name}.desktop file.
 [ OK ] Package does not own files or directories owned by other packages.
 [ CHECK ] Requires:
libGL.so.1()(64bit) libGLU.so.1()(64bit) libHalf.so.4()(64bit)
libIex.so.4()(64bit) libIlmImf.so.4()(64bit) libImath.so.4()(64bit)
libX11.so.6()(64bit) libXext.so.6()(64bit) libc.so.6()(64bit)
libc.so.6(GLIBC_2.2.5)(64bit) libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit) libc.so.6(GLIBC_2.4)(64bit) libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit) libgcc_s.so.1()(64bit)
libgcc_s.so.1(GCC_3.0)(64bit) libm.so.6()(64bit) libm.so.6(GLIBC_2.2.5)(64bit)
libpixiecommon.so.0()(64bit) libpthread.so.0()(64bit)
libpthread.so.0(GLIBC_2.2.5)(64bit) libri.so.0()(64bit) libsdr.so.0()(64bit)
libstdc++.so.6()(64bit) libstdc++.so.6(CXXABI_1.3)(64bit)
libstdc++.so.6(GLIBCXX_3.4)(64bit) libtiff.so.3()(64bit) libz.so.1()(64bit)

=== ISSUES ===

# Package Name:

The base package name is Pixie (with upper-case letter).
Please move it to Pixie instead of pixie.
That's also imply to move the name of spec file to the right one.

# Timestamps action:

This package have many text/documentations files and png/icons files
so keeping timestamps is desirable.
Does this package accept 'make INSTALL="install -p" install' ?

# Some concerns about Large documentation:

The final package is mostly documentation.I don't think it's mandatory that it
be split into a -doc subpackage. But, it'll be not a bad idea to do so.
Also, any reason to mkdir'ed __doc (with double underscore) ?

# Ownership:

Currently your %file section (main package) sound good.
however, i've some comment about ownership (which can be improved).
%dir %{_libdir}/Pixie
The use of %{_libdir}/Pixie is enough and owned by the package (including

%dir %{_datadir}/Pixie
%dir %{_datadir}/Pixie/shaders
You don't need to own sub-folders if you already own parent directory.
And, As above, this can be improved by %{_datadir}/Pixie (which's enough to be

# Quick request:

Nicolas, will you upload somewhere the packaged x86_64 binaries please ?

Comment 20 Nicolas Chauvet (kwizart) 2007-07-14 19:49:23 UTC
Ok, so...
- Update to 2.2.1
- Rename to Pixie
- Preserve timestamp at install step
- Improve directory ownership
- Move docs to sub-package
- Add a dyn patch to link to shared ftgl

# Quick answear: The rpm package was already in the same directory for x86_64
(previous version)

Spec URL:
Description: 3D renderer Renderman compliant

I've tested to rebuild autotools because if sometime solve the rpath issue at
source... But not in this case! so i leave it commented...

Comment 21 Nicolas Chauvet (kwizart) 2007-07-15 13:01:53 UTC
ok i finally experienced this Out of memory: kill process 9504 (g++) score...
(only on x86_64 tought - i386 built fine)
I will give a retry, but i think this is more related to swap size (as kswapd
has taken most of the ressources - top command show it)...
I will give a retry with more swap size (i currently have 2Gio of RAM and 3Gio
of swap size)

Comment 22 Xavier Lamien 2007-07-15 19:44:16 UTC
[comment #20]
Sound Good.
Will you also upload the updated packages x86_64 (including -doc and -devel
sub-packages and build.log)

[comment #21]
if this happened with the updated release ?

Comment 23 Xavier Lamien 2007-07-16 19:01:43 UTC
Checked on mock_i386

# About timestamps action

'make INSTALL="install -p" install' doesn't sounds to work well on docs/images
files as we want.
'Cause the Makefile called install-sh script to install all shipped data.
So you will have to sed or patch the Makefile. Or also, if you like improvment,
try this in %install stage 'make install_sh_DATA="$(install_sh) -c -pm 0644"

# Sub-packages

-libs and -devel subpackage don't seem good.
this: %{_libdir}/*.so should be moved to -devel.
this: %{_libdir}/*.so.* should be moved to -lib(s) if other applications require
them for developing work, otherwhise keeping them in main package it's good.

Also, don't forget to upload packaged x86_64 rpm files.

Comment 24 Xavier Lamien 2007-07-25 21:43:29 UTC
ping ?

Comment 25 Nicolas Chauvet (kwizart) 2007-08-15 19:59:53 UTC
Spec URL:
Description: 3D renderer Renderman compliant

building in mock x86_64 (fc6) might need to test also in devel and maybe ppc (ppc64)

Comment 26 Mamoru TASAKA 2007-08-16 03:46:00 UTC
Failed at least on ppc64, both rawhide & F-7, perhaps due to
OOM killer *on koji*.

http://koji.fedoraproject.org/koji/taskinfo?taskID=104258 (rawhide)
http://koji.fedoraproject.org/koji/taskinfo?taskID=104314 (F-7)

IMO codes must be fixed to reduce the burden on compilation

Comment 27 Xavier Lamien 2007-08-23 13:49:26 UTC
ping !

Comment 28 Nicolas Chauvet (kwizart) 2007-08-26 12:46:48 UTC
Well i don't know if it is normal for 64bit arch to need hours to compile
instead of 10min for 32bit...
Upstream says it takes times because of some expensive optimized macros within
the  source code. I supposed that theses macros needed a lot of swap size
(Mamoru: do you know how much swap have the koji builders?) I expect that it
needs around 5Gio , maybe more (3Gio was used when it fails on x86_64 for me -
swap was full and kswap took lot of cpu time before OOM killer).

There is some changes upstream in the rib.c, maybe I can backport this change
and see if something is better, anyway, i will try to contact upstream about
this subject...

Comment 29 Nicolas Chauvet (kwizart) 2007-08-26 12:49:42 UTC
@Mamoru thx for this test!

I will try to backport changes from cvs...

Comment 30 Mamoru TASAKA 2007-08-26 17:44:43 UTC
(In reply to comment #26)
> Failed at least on ppc64, both rawhide & F-7, perhaps due to
> OOM killer *on koji*.
> http://koji.fedoraproject.org/koji/taskinfo?taskID=104258 (rawhide)
> http://koji.fedoraproject.org/koji/taskinfo?taskID=104314 (F-7)
> IMO codes must be fixed to reduce the burden on compilation
> anyway...

Well, I retried and this time it was okay for all arch...


Comment 31 Xavier Lamien 2007-09-05 09:40:51 UTC
All issues has been fixed.

This package can be apporved now.

Comment 32 Nicolas Chauvet (kwizart) 2007-09-05 13:21:01 UTC
New Package CVS Request
Package Name:      Pixie
Short Description: 3D renderer Renderman compliant
Owners:            kwizart
Branches:          devel FC-6 F-7 EL-4 EL-5
InitialCC:         <empty>
Commits by cvsextras: yes

Comment 33 Kevin Fenzi 2007-09-05 21:28:21 UTC
cvs done. 

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