Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver-0.10.1-1.src.rpm Description: 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.
License is ClearSilver Software License, 'derived' from Apache Software License v1.1. It generates a rpmlint error: W: clearsilver invalid-license Apache License style See: /usr/share/doc/clearsilver-0.10.1/CS_LICENSE
Initial comments, not a full review: I'd suggest taking the patches and some other bits from my package of this at http://cachalot.mine.nu/4/SRPMS/clearsilver-0.10.1-0.1.src.rpm (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.
(In reply to comment #2) > Perl stuff must be installed into vendor install dirs. ...and it apparently already is, duh.
* Switched to the spec file and patches from http://cachalot.mine.nu/4/SRPMS/clearsilver-0.10.1-0.1.src.rpm (credit to Ville Skytta) * added -devel subpackage Spec Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver.spec SRPM Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver-0.10.1-1.src.rpm
Badly broken on x86_64.
Could you elaborate? Not everyone has access to a x86_64 box.
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
Here is an excerpt from a discussion with Axel.Thimm at ATrpms.net: 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 fail. 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.
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. http://packages.debian.org/cgi-bin/search_packages.pl?exact=0&searchon=names&version=all&case=insensitive&release=all&keywords=clearsilver&arch=any
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== ==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)
I've contacted upstream. Will fix in next version 0.10.2, hopefully released end of this week.
No news from upstream yet?
0.10.2 is out.
And it almost builds/installs on x86_64. Not quite. configure doesn't detect PYTHON_SITE, so install fails.
Sounds promising and probably easy enough to patch in the specfile...
Rebuild for clearsilver 0.10.2 Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver-0.10.2-1.src.rpm Please, someone verify this RPM builds on FC4/x86_64.
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 stories EOM arf.1 = farming arf.2 = sewing arf.3 = bowling arf.party.1 [Drool="True"] = baloons arf.party.2 [Pink] = noise makers arf.party.3 << EOM telling long stories EOM party.2 attr (Pink=1) ---hdftest.out--- ---hdftest.err--- 19a20,27 > This is a funny test. farming. > > baloons > > noise makers > > telling long > stories ---hdftest.err--- Dunno if that helps, but thought I would throw it in...
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/libclearsilver-jni.so /var/tmp/rpm/clearsilver-0.10.2-2-root-nbecker/usr/lib64/java/libclearsilver-jni.so mv: cannot stat `/var/tmp/rpm/clearsilver-0.10.2-2-root-nbecker/usr/lib64/libclearsilver-jni.so': 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?
(In reply to comment #18) > I added --disable-ruby. > [snip] > > 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?
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.
Rebuild for clearsilver 0.10.2-2: Using ifarch to disable building java and ruby sub-packages on x86_64. Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver-0.10.2-2.src.rpm Please, someone verify this RPM builds correctly on FC4/x86_64.
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
Neal, have you found time to test the built package on x86_64 yet?
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".
Rebuild (0.10.2-2): changed all "%ifarch i386"s to "%ifarch %{ix86} ppc" Spec Name or Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver-0.10.2-2.src.rpm
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).
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: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver.spec SRPM Name or Url: http://www.soeterbroek.com/linux/fedora/extras/clearsilver/clearsilver-0.10.2-2.src.rpm
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.
(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. Imported
Successfully built in Plague. Can this bug be closed now?
(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.
Package Change Request ====================== Package Name: clearsilver New Branches: EL-4 EL-5 Current owner approved me to own package for EPEL From: "Jeffrey C. Ollie" <jeff> To: Jesse Keating <jkeating> Date: 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. Jeff
cvs done.