Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at

Bug 174529

Summary: Review Request: clearsilver
Product: [Fedora] Fedora Reporter: Joost Soeterbroek <joost.soeterbroek>
Component: Package ReviewAssignee: Ville Skyttä <scop>
Status: CLOSED NEXTRELEASE QA Contact: David Lawrence <dkl>
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: dcantrell, fedora-extras-list, ndbecker2
Target Milestone: ---Flags: tcallawa: fedora-cvs+
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-01-09 16:23:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 163779, 174546    

Description Joost Soeterbroek 2005-11-29 19:46:04 UTC
Spec Name or Url:
SRPM Name or Url:
ClearSilver is a fast, powerful, and language-neutral HTML template system. 
In both static content sites and dynamic HTML applications, it provides a separation between presentation code and application logic which makes 
working with your project easier.

Comment 1 Joost Soeterbroek 2005-11-29 19:49:31 UTC
License is ClearSilver Software License, 'derived' from Apache Software License
It generates a rpmlint error:
W: clearsilver invalid-license Apache License style


Comment 2 Ville Skyttä 2005-11-29 20:16:42 UTC
Initial comments, not a full review:

I'd suggest taking the patches and some other bits from my package of this at
(most of the issues found below are fixed in it)

All the perl_* and need_buildroot defines can be removed, they work just fine in
the scope of all supported (and some past) Fedora Core versions.

Most of the conditional subpackages could be just be made unconditional, and a
lot of specfile cruft would disappear.

Why isn't the ruby subpackage built by default?

IIRC the java subpackage could be built with FC4+'s java.

The minimum required version of the python* build dependency is probably bogus;
I've built and used this on a FC2 box recently.  (My package has >= 2.1, but I'm
not 100% sure about its correctness.)

"2.4" is hardcoded for the python version in %prep, needs to be fixed.  Ditto
hardcoded python site packages path which would be incorrect for x86_64.

The python subpackage does not require the main package.  This is probably true
for the perl, ruby, and forthcoming ;) java subpackage too.

perllocal.pod cannot be packaged; it'll conflict with other packages.

Perl stuff must be installed into vendor install dirs.

Comment 3 Ville Skyttä 2005-11-29 20:33:43 UTC
(In reply to comment #2)
> Perl stuff must be installed into vendor install dirs.

...and it apparently already is, duh.

Comment 4 Joost Soeterbroek 2005-11-29 21:05:39 UTC
* Switched to the spec file and patches from (credit to Ville
* added -devel subpackage

Spec Url:

Comment 5 Neal Becker 2005-11-29 23:36:26 UTC
Badly broken on x86_64. 

Comment 6 Ville Skyttä 2005-11-29 23:43:37 UTC
Could you elaborate?  Not everyone has access to a x86_64 box.

Comment 7 Neal Becker 2005-11-30 01:29:17 UTC
There are serious problems building on x86_64, and with gcc4.  I have 
discussed this on some other lists.  AFAIK, nobody has managed to fix it. 
The first hurdle is this one (but it's not the last hurdle): 
gcc -o static.cgi static.o -L../libs/ -lneo_cgi -lneo_cs -lneo_utl  -lz 
gcc -shared -fPIC -o static.cso static.o -L../libs/ -lneo_cgi -lneo_cs 
-lneo_utl  -lz 
/usr/bin/ld: static.o: relocation R_X86_64_32 against `a local symbol' can not 
be used when making a shared object; recompile with -fPIC 
static.o: could not read symbols: Bad value 
collect2: ld returned 1 exit status 
make[1]: *** [static.cso] Error 1 

Comment 8 Neal Becker 2005-11-30 13:05:51 UTC
Here is an excerpt from a discussion with Axel.Thimm at 
But to come to the original point: clearsilver will not build on 64 
bits and gcc4. Or rephrased: It will build, but the testsuite will 
That's why the FC4/x86_64 repo has the FC3/x86_64 package in it, and 
probably why you wanted to rebuild clearsilver. 
There is a guy from the clearsilver mailing list claiming to have a 
patch for that, but he hasn't submitted it yet. Anyway, it's an 
upstream issue. 
I am concerned that these problems indicate an overall low quality of code. 

Comment 9 Ville Skyttä 2005-11-30 13:47:34 UTC
Damn.  How about focusing on just getting the Python bindings built and shipped,
then?  They're the only thing that are needed to satisfy dependencies of other
packages (trac) at the moment, and that would narrow the problem scope considerably.

FWIW, that's what Debian does, and they ship the Python bindings for apparently
all their architectures.

Comment 10 Neal Becker 2005-11-30 15:49:07 UTC
Did that.  Also, build with CC=-fPIC (kluge).  Now it builds, but like Axel 
said, segfaults. 
Here is what valgrind says: 
Check end of string slice: 
==24039== Invalid read of size 1 
==24039==    at 0x40BEEE: _builtin_str_slice 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x407A33: eval_expr 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x408210: var_eval 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x40B597: render_node 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x40B64E: cs_render 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x401F92: main (cstest.c:86) 
==24039==  Address 0xFFFFFFFF is not stack'd, malloc'd or (recently) free'd 
==24039== Process terminating with default action of signal 11 (SIGSEGV) 
==24039==  Access not within mapped region at address 0xFFFFFFFF 
==24039==    at 0x40BEEE: _builtin_str_slice 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x407A33: eval_expr 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x408210: var_eval 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x40B597: render_node 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x40B64E: cs_render 
(in /home/nbecker/RPM/BUILD/clearsilver-0.10.1/cs/cstest) 
==24039==    by 0x401F92: main (cstest.c:86) 

Comment 11 Joost Soeterbroek 2005-12-02 07:42:20 UTC
I've contacted upstream. Will fix in next version 0.10.2, hopefully released end
of this week.

Comment 12 Ville Skyttä 2005-12-13 16:41:42 UTC
No news from upstream yet?

Comment 13 Ville Skyttä 2005-12-15 16:41:47 UTC
0.10.2 is out.

Comment 14 Neal Becker 2005-12-15 16:46:02 UTC
And it almost builds/installs on x86_64.  Not quite.  configure doesn't detect 
PYTHON_SITE, so install fails. 

Comment 15 Ville Skyttä 2005-12-15 16:51:18 UTC
Sounds promising and probably easy enough to patch in the specfile...

Comment 16 Joost Soeterbroek 2005-12-15 21:09:04 UTC
Rebuild for clearsilver 0.10.2

Spec Name or Url:
SRPM Name or Url:

Please, someone verify this RPM builds on FC4/x86_64.

Comment 17 Kevin Fenzi 2005-12-16 03:10:02 UTC
On a fc4 x86_64 machine I have access to the src.rpm in comment #16 fails to
build with: 

make[2]: Leaving directory `/u/u2/kevin/rpm/BUILD/clearsilver-0.10.2/ruby/ext/hdf'
<--- ext/hdf
<--- ext
install.rb: setup done.
Running ruby test
test/hdftest.rb:36: [BUG] Segmentation fault
ruby 1.8.2 (2004-12-25) [x86_64-linux]

/bin/sh: line 1: 26495 Aborted                 /usr/bin/ruby -Ilib -Iext/hdf
test/hdftest.rb >hdftest.out
Failed Ruby Test: hdftest.rb
    See hdftest.out and hdftest.err
make[1]: *** [testrb] Error 1
make[1]: Leaving directory `/u/u2/kevin/rpm/BUILD/clearsilver-0.10.2/ruby'
make: *** [cs] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.87193 (%build)

--- hdftest.out ---
1 = farming
2 = sewing
3 = bowling
party.1 [Drool="True"]  = baloons
party.2 [Pink]  = noise makers
party.3 << EOM
telling long
arf.1 = farming
arf.2 = sewing
arf.3 = bowling [Drool="True"]  = baloons [Pink]  = noise makers << EOM
telling long
party.2 attr (Pink=1)

> This is a funny test. farming.
> baloons
> noise makers
> telling long
> stories

Dunno if that helps, but thought I would throw it in...

Comment 18 Neal Becker 2005-12-16 13:28:55 UTC
I added --disable-ruby. 
Now it gets further, but stops here: 
+ find /var/tmp/rpm/clearsilver-0.10.2-2-root-nbecker -type f -name .packlist 
-exec rm -f '{}' ';' 
+ find /var/tmp/rpm/clearsilver-0.10.2-2-root-nbecker -type f -name 
perllocal.pod -exec rm -f '{}' ';' 
+ find /var/tmp/rpm/clearsilver-0.10.2-2-root-nbecker -type f -name '*.bs' -a 
-size 0 -exec rm -f '{}' ';' 
+ chmod -R u+w /var/tmp/rpm/clearsilver-0.10.2-2-root-nbecker/usr 
+ install -dm 
755 /var/tmp/rpm/clearsilver-0.10.2-2-root-nbecker/usr/lib64/java 
mv /var/tmp/rpm/clearsilver-0.10.2-2-root-nbecker/usr/lib64/ /var/tmp/rpm/clearsilver-0.10.2-2-root-nbecker/usr/lib64/java/ 
mv: cannot stat 
No such file or directory 
error: Bad exit status from /var/tmp/rpm/rpm-tmp.96805 (%install) 
Funny, search back for '-jni' shows nothing. 
Maybe just disable java? 

Comment 19 Joost Soeterbroek 2005-12-31 13:58:44 UTC
(In reply to comment #18)
> I added --disable-ruby. 
> Maybe just disable java? 

I am now thinking about just building with --disable-ruby and --disable-java in
order to at least have the package build on 64-bit also. 

It's not the most elegant solution, but something is better than nothing. I
suspect that the majority of folks who would want this package is because Trac (
#174546) depends on it.

Any comments?

Comment 20 Jeff Pitman 2005-12-31 14:46:47 UTC
Use ifarch. If there happens to be a cross-section between a ruby OR java AND
x86_64 AND clearsilver user, then they can push upstream to get ruby or java to
work. In the meantime, it works on x86.

Comment 21 Joost Soeterbroek 2005-12-31 15:50:14 UTC
Rebuild for clearsilver 0.10.2-2:
Using ifarch to disable building java and ruby sub-packages on x86_64.

Spec Name or Url:
SRPM Name or Url:

Please, someone verify this RPM builds correctly on FC4/x86_64.

Comment 22 Neal Becker 2006-01-01 14:04:39 UTC
Confirmed - built OK on FC4/x86_64.  Not tested.  
One scary warning: 
 gcc -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m64 -mtune=nocona 
-Wall -I..  -fPIC -o neo_hash.o -c neo_hash.c 
neo_hash.c: In function 'ne_hash_int_hash': 
neo_hash.c:292: warning: cast from pointer to integer of different size 

Comment 23 Ville Skyttä 2006-01-04 06:55:53 UTC
Neal, have you found time to test the built package on x86_64 yet?

Comment 24 Ville Skyttä 2006-01-04 22:27:35 UTC
All subpackages seem to build ok on i386/rawhide and ppc/fc4, and IMO there's no
need to hardcode "i386", so I'd suggest changing all "%ifarch i386"s to "%ifarch
%{ix86} ppc".

Comment 25 Joost Soeterbroek 2006-01-05 18:16:47 UTC
Rebuild (0.10.2-2):
changed all "%ifarch i386"s to "%ifarch %{ix86} ppc"

Spec Name or Url:
SRPM Name or Url:

Comment 26 Ville Skyttä 2006-01-05 21:40:11 UTC
A couple of final suggestions:

- hardcode 0.10.2 instead of using %{version} in Patch0 -> maybe less juggling
on upgrades

- in %prep: find python/examples -type f | xargs chmod -x # see rpmlint output

- subpackages don't have any interdependencies, so license files should be
included in all of them

Approved with the above changes (which can be done after importing to CVS and
before the first build).

Comment 27 Joost Soeterbroek 2006-01-07 10:01:40 UTC
Rebuild (0.10.2-2):
- hardcoded 0.10.2 instead of using %{version} in Patch0
- in %prep: find python/examples -type f | xargs chmod -x
- license in all sub-packages

Spec Name or Url:
SRPM Name or Url:

Comment 28 Ville Skyttä 2006-01-08 10:50:24 UTC
Joost, do you have a sponsor and an Extras account already?  If yes, the package
was already approved in comment 26 and you can go ahead and import it.

Comment 29 Joost Soeterbroek 2006-01-08 17:27:21 UTC
(In reply to comment #28)
> Joost, do you have a sponsor and an Extras account already?  If yes, the package
> was already approved in comment 26 and you can go ahead and import it.


Comment 30 Joost Soeterbroek 2006-01-08 21:07:19 UTC
Successfully built in Plague. Can this bug be closed now?

Comment 31 Christian Iseli 2006-01-09 08:13:06 UTC
(In reply to comment #30)
> Successfully built in Plague. Can this bug be closed now?

Yes, that's point 9 of the review process for contributor:
 9. Once the package is built, close the bugzilla review ticket as NEXTRELEASE.

Comment 32 Jesse Keating 2007-06-01 21:05:57 UTC
Package Change Request
Package Name: clearsilver
New Branches: EL-4 EL-5

Current owner approved me to own package for EPEL

"Jeffrey C. Ollie" <jeff>
Jesse Keating <jkeating>
Today 16:29:32
Message was signed with unknown key 0xAED93BC72C884111.
The validity of the signature cannot be verified.
Status: No public key to verify the signature
  On Fri, 2007-06-01 at 15:17 -0400, Jesse Keating wrote:
> I'd like clearsilver in EPEL, so that I can use Trac in EPEL.  Would you be 
> opposed to me branching these and building them for EPEL?  

Nope... go right ahead.


Comment 33 Tom "spot" Callaway 2007-06-01 21:23:13 UTC
cvs done.