Please do not reply directly to this email. All additional comments should be made in the comments box of this bug. https://bugzilla.redhat.com/show_bug.cgi?id=634909 --- Comment #17 from Lubomir Rintel <lkundrak@xxxxx> 2010-12-10 10:33:25 EST --- Thank you (In reply to comment #15) > v8.x86_64: W: shared-lib-calls-exit /usr/lib64/libv8-2.5.9.so exit@xxxxxxxxxxx > v8.x86_64: W: no-manual-page-for-binary d8 > 1 packages and 0 specfiles checked; 0 errors, 2 warnings. > > I suggest we can ignore these two errors, although even a minimal man page for > d8 would be nice to have. I don't have resources to write the manual myself (I sort of hoped Debian would create one; they're quite good at that ;) -- I don't know much about d8 myself and nothing that would help me is included in the source. I guess this is best left as it is. > rpmlint RPMS/x86_64/v8-devel-2.5.9-1.fc14.x86_64.rpm: > > v8-devel.x86_64: W: no-documentation > v8-devel.x86_64: E: non-executable-script > /usr/lib/python2.7/site-packages/js2c.py 0644L /usr/bin/env > v8-devel.x86_64: E: non-executable-script > /usr/lib/python2.7/site-packages/jsmin.py 0644L /usr/bin/python2.4 > 1 packages and 0 specfiles checked; 2 errors, 1 warnings. > > I'm not mega worried about the lack of docs (although again, shipping the > samples/* code would be nice I think), These probably are not of much use to most -devel package users; they are built and used as part of the test use, but I don't think it's very wise or useful to ship them with the package. > but the python stuff needs to be fixed > imho. Arguably the jsmin.py error isn't a problem, although I would much rather > it not have a shebang unless it's actually an executable (esp. since most > Fedora won't have python2.4 around anyway). > > Also, I'm not sure js2c.py really is a library - it looks like a utility to me. > I don't think that is the right location for it. Stripped the shebang from both, made a /usr/bin/js2c wrapper for js2c.py which is supposed to be an user-called tool as well. > > rpmlint RPMS/x86_64/v8-debuginfo-2.5.9-1.fc14.x86_64.rpm: > > v8-debuginfo.x86_64: E: script-without-shebang > /usr/src/debug/v8-2.5.9/src/compiler.cc > v8-debuginfo.x86_64: E: script-without-shebang > /usr/src/debug/v8-2.5.9/src/scanner.cc > v8-debuginfo.x86_64: W: spurious-executable-perm > /usr/src/debug/v8-2.5.9/include/v8-debug.h > 1 packages and 0 specfiles checked; 2 errors, 1 warnings. > > Various permissions errors here which should be fixed. The install -pm approach > used in part of the specfile I think would be better - you could then lose the > chmods and it would look a bit tidier. Fixed. Still had to use chmod for -debuginfo. > - if you're going to use %{} macros, %{buildroot} looks nicer than > $RPM_BUILD_ROOT rather than mixing the two styles Well, the consistent use of macros guideline forbids mixing of %{buildroot} with $RPM_BUILD_ROOT or %{optflags} with $RPM_OPT_FLAGS, which I don't do. I believe that consistency with existing SPEC files is more important than anything else here. Most packages use $RPM_BUILD_ROOT for build root (and %{optflags} for compiler flags) and so do many tools that generate SPEC files (e.g. cpanspec). I'm really accustomed to that, it makes the SPEC files more legible to me and would like it to stay it that way (at least until a guideline deals with this diversity). > - the .spec has some tabs and spaces mixed /me looks down in shame uh, okay, fixed. > - Packaging guildelines state use of "ExcludeArch" with appropriate BZ > references per-arch instead of "ExclusiveArch". A guideline is probably wrong here. In this case the package it's really not a bug, given it is really specific to certain architectures those are only ones v8 JIT compilers were written for. SPEC: http://v3.sk/~lkundrak/SPECS/v8.spec SRPM: http://v3.sk/~lkundrak/SRPMS/v8-2.5.9-2.fc14.src.rpm -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/package-review