This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes

Bug 718681

Summary: Review Request: luajit - Just-In-Time Compiler for Lua
Product: [Fedora] Fedora Reporter: Andrei Lapshin <alapshin>
Component: Package ReviewAssignee: Nobody's working on this, feel free to take it <nobody>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: rawhideCC: alex, alsadi, apatil, cwt, ignatenko, psedlak,, zbyszek, znmeb
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-28 04:30:07 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Spec file diff
Latest spec file
Spec file diff with fixed typo
Latest spec file
Spec file diff from previous version
Latest spec file
Spec diff
luajit-2.0.2.spec none

Description Andrei Lapshin 2011-07-04 05:13:08 EDT
Spec URL:

LuaJIT implements the full set of language features defined by Lua 5.1.
The virtual machine (VM) is API- and ABI-compatible to the standard
Lua interpreter and can be deployed as a drop-in replacement.
Comment 1 Damian L Brasher 2011-07-04 07:19:21 EDT
Informal review, initial check,

rpmlint -i luajit.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

rpmlint -i luajit-2.0.0-0.1.beta8.fc16.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.

Damian Brasher
Comment 2 Andrei Lapshin 2011-07-04 13:28:31 EDT
After build was not executable and rpmbuild created wrong cyclic dependencies. Fixed.

Spec URL:
SRPM URL: file:///home/alapshin/Dropbox/Public/luajit.spec

[alapshin@localhost rpmbuild]$ rpmlint -i SPECS/luajit.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

[alapshin@localhost rpmbuild]$ rpmlint -i SRPMS/luajit-2.0.0-0.1.beta8.fc16.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Comment 3 Andrei Lapshin 2011-07-04 14:12:48 EDT
Sorry, SRPM URL:
Comment 4 Andrei Lapshin 2011-07-05 03:17:51 EDT
Apply upstream hotfix #1


rpmlint -i SPECS/luajit.spec 
0 packages and 1 specfiles checked; 0 errors, 0 warnings.

rpmlint -i SRPMS/luajit-2.0.0-0.2.beta8.fc16.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
Comment 5 anish 2011-08-30 06:45:08 EDT
Here's an unofficial review for F15,

+ rpmlint output

rpmlint output is  silent 
[makerpm@dhcp201-181 SOURCES]$ rpmlint luajit-2.0.0-0.2.beta8.fc16.src.rpm 
1 packages and 0 specfiles checked; 0 errors, 0 warnings.
+ License mentioned in the spec file are "MIT  which looks okie

+ Sepc file is in American English 

+ Change log indicates the revised versions


1: According to packaging rules, please use naming conventions such as lua-luajit
Comment 6 john5342 2011-09-27 12:15:42 EDT
Just a few initial notes looking at the spec file:

The actual shared library (*) is in the main package as it should be but should only be used for linking against and should therefore be in the devel package.

The buildroot tag is not one of the standard ones so far as i remember but either way it has not been needed for some time now and is ignored on our build system.

The hotfix patch (which is obviously upstream) should be provided as a full URL just like the source package.

%{optflags} must always be used. Adding CFLAGS="%{optflags}" to the build commandline should do the trick according to the in Makefile documentation.

All build output should be in verbose mode to aid in debugging failed builds as well as verifying that correct flags are used. I don't know of an easy way with these hand written Makefiles but it certainly should be investigated.

A quick build and rpmlint of the resulting output:
$ rpmlint luajit-*.rpm
luajit.x86_64: W: shared-lib-calls-exit /usr/lib64/ exit@GLIBC_2.2.5

Can probably be ignored since it is required to implement os.exit()

luajit.x86_64: W: no-manual-page-for-binary luajit-2.0.0-beta8

Not ideal but upstream don't provide one.

luajit-debuginfo.x86_64: E: empty-debuginfo-package

This is an error. Not sure if it is because it's failing to pick up the debug options in %{optflags} or something else but difficult to tell without knowing what commands are run.

luajit-devel.x86_64: W: no-documentation

devel requires the main package which does contain docs

luajit-static.x86_64: W: spelling-error %description -l en_US libluajit -> liberality


luajit-static.x86_64: W: no-documentation

Same as above

5 packages and 0 specfiles checked; 1 errors, 5 warnings.

If these things are sorted i can probably do a proper review when i get some time.
Comment 7 john5342 2011-09-27 12:16:48 EDT
Apologies. I can't do the review. Didn't spot the FE-NEEDSPONSOR but the above points still apply.
Comment 8 Andrei Lapshin 2011-10-09 10:31:48 EDT
Created attachment 527095 [details]
Spec file diff
Comment 9 Andrei Lapshin 2011-10-09 10:32:41 EDT
Created attachment 527096 [details]
Latest spec file
Comment 10 Andrei Lapshin 2011-10-09 10:40:37 EDT
Latest SRPM
Comment 11 Andrei Lapshin 2011-10-09 10:48:28 EDT
Fixed errors pointed out by john5342.
Comment 12 Andrei Lapshin 2011-10-09 13:04:56 EDT
Created attachment 527109 [details]
Spec file diff with fixed typo
Comment 13 Andrei Lapshin 2011-10-09 13:06:07 EDT
Created attachment 527110 [details]
Latest spec file
Comment 14 Andrei Lapshin 2011-10-09 13:07:57 EDT
Created attachment 527111 [details]
Spec file diff from previous version
Comment 15 Andrei Lapshin 2011-10-09 13:10:55 EDT
Sorry, found typo in %build section. Fixed and rebuild. New SRPM available by same address
Comment 16 Scott Tsai 2011-12-13 19:18:38 EST
Informal review. I also can't sponsor people in Fedora.

1. Specify URL of Patch0 like this:
- Patch0:         beta8_hotfix1.patch
+ Patch0:
- Source1:

2. Rename /usr/bin/luajit-2.0.0-beta8 to /usr/bin/luajit
The main command is only installed as:
having the 'luajit' binary name change from under the user as
we update to newer beta releases seems clearly undesirable.

Quoting from upstream
"to avoid overwriting a previous version,
the beta test releases only install the LuaJIT executable under the versioned name
(i.e. luajit-2.0.0-beta8). You probably want to create a symlink for convenience ..."

Since we're not packaging multiple versions of luajit in Fedora at this time,
I recommend you simply rename the binary as /usr/bin/luajit
This would also get rid of the "no-manual-page-for-binary" rpmlint warning. 

3. Make up your mind on whether to support older rpmb versions
If support for EPEL5 is desired, then the -devel package should require pkgconfig.
Otherwise we can rely on newer rpm features and remove BuildRoot and "rm -rf %{buildroot}" from the spec.

Other comments:
I ran the small collection of Lua 5.1 tests from and
they worked.

Regarding libluajit calling exit, I did a quick scan of the source and besides implementing
os.exit() luajit may also call exit() during exception handling errors (lj_err.c).
rpmlint complaining about shared libraries calling exit seems to be codifying a policy
that's not universally applicable in the wrong place anyway.
Comment 17 Andrei Lapshin 2012-02-06 11:53:03 EST
Created attachment 559690 [details]
Latest spec file
Comment 18 Andrei Lapshin 2012-02-06 11:54:12 EST
Created attachment 559691 [details]
Spec diff
Comment 20 Michael Schwendt 2012-03-24 12:47:51 EDT
A brief but hopefully helpful look at the spec file:

> %package devel
> Summary:        Development files for %{name}
> Group:          System Environment/Libraries

Library -devel packages typically are in group "Development/Libraries" whereas "System Environment/Libraries" is for the base library packages.

> Requires:       %{name} = %{version}-%{release}

> Requires:       pkgconfig

This can be removed because it is automatic. Take a look at the built rpms with "rpm -qpR ..."

> %package static
> Summary:        Static library for %{name}
> Group:          System Environment/Libraries
> Requires:       %{name} = %{version}-%{release}

Same here as above, plus: It makes no sense for the -static package to require the base package. If at all, it could require the -devel package.

> %post devel -p /sbin/ldconfig
> %postun devel -p /sbin/ldconfig

The are not needed for the -devel package. There is nothing in the -devel package that would be affected by running ldconfig. This is library base package stuff.

> %files
> %defattr(-,root,root,-)

This %defattr is the default and need not be specified anymore:

> %{_datadir}/%{name}-%{version}/jit/*
> %dir %{_datadir}/%{name}-%{version}
> %dir %{_datadir}/%{name}-%{version}/jit

Strange order of lines. Due to the '*' wildcard, you could reduce these three lines to just


to include that directory and everything in it properly.

> %dir %{_libdir}/lua
> %dir %{_libdir}/lua/5.1
> %dir %{_datadir}/lua
> %dir %{_datadir}/lua/5.1

Empty directories so far. Intentional? If so, a comment in the spec file would be appropriate.
Comment 21 M. Edward (Ed) Borasky 2012-09-07 01:17:00 EDT
I don't know if I'm quite ready to take over this package, but it's required by a package that I do want to use (LuaAV), so I'll certainly take a look at it.
Comment 22 Muayyad Alsadi 2013-09-02 02:40:50 EDT
I've updated .spec to the latest upstream and fixed the issues

.spec file

the .src.rpm file
Comment 23 Muayyad Alsadi 2013-09-02 02:41:58 EDT
Created attachment 792723 [details]
Comment 24 Zbigniew Jędrzejewski-Szmek 2013-10-06 10:05:34 EDT
(In reply to Muayyad Alsadi from comment #23)
> Created attachment 792723 [details]
> luajit-2.0.2.spec

Are you taking over this package? If so, is FE-NEEDSPONSOR still required?
Comment 25 Igor Gnatenko 2013-11-27 17:16:41 EST
I want to get this package in Fedora.
Comment 26 Zbigniew Jędrzejewski-Szmek 2013-11-27 19:10:40 EST
(In reply to Igor Gnatenko from comment #25)
> I want to get this package in Fedora.
That'd be nice. Looking at the lack of recent responses from other people on this bug, I think you should just take over the review request, and maybe add other people as co-maintainers if they ever get sponsored.
Comment 27 Igor Gnatenko 2013-11-28 04:30:07 EST
I submitted new review. If anyone want to maintain - I can add as co-maintainer.

*** This bug has been marked as a duplicate of bug 1035661 ***