Description of problem: On 64-bit platforms, all of the Fedora lua-* packages place libraries in /usr/lib64/lua/5.2 and Lua itself searches in that directory when loading modules. However, the Fedora package for luarocks is configured to install shared modules to /usr/lib/lua/5.2, which isn't included in the Lua module paths. This could be fixed by specifying the --with-lua-lib=DIR option appropriately in the package spec. (http://luarocks.org/en/Installation_instructions_for_Unix) Version-Release number of selected component (if applicable): Tested on luarocks 2.1.2 but it's seems to have been this way for quite a few releases. How reproducible: Always Steps to Reproduce: 1. Log into a 64-bit Fedora 20 system 2. sudo luarocks install bcrypt 3. lua -e 'require "bcrypt"' Actual results: lua: (command line):1: module 'bcrypt' not found: no field package.preload['bcrypt'] no file '/usr/share/lua/5.2/bcrypt.lua' no file '/usr/share/lua/5.2/bcrypt/init.lua' no file '/usr/lib64/lua/5.2/bcrypt.lua' no file '/usr/lib64/lua/5.2/bcrypt/init.lua' no file './bcrypt.lua' no file '/usr/lib64/lua/5.2/bcrypt.so' no file '/usr/lib64/lua/5.2/loadall.so' no file './bcrypt.so' stack traceback: [C]: in function 'require' (command line):1: in main chunk [C]: in ? Expected results: Module loads without error.
Thanks. I've tended to use luarocks to install to the user tree, not the system one -- hoping to rework Fedora's lua packaging in general so packages installed via RPM are also picked up by luarocks -- but one might as well start by making sure packages installed by luarocks are picked up by the system.
Turns out not to be that easy, there are lots of hard-coding of "lib" in the code. Will try and fix this in time for the next release though.
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Any progress on this? Moreover, luarocks is created as .noarch package. This completely messes up arch support. See https://github.com/keplerproject/luarocks/blob/master/configure#L433 On my system site_config.lua lists only "/usr/lib" as library dir and LUAROCKS_UNAME_M as "armv7l", duh. LUAROCKS_EXTERNAL_DEPS_SUBDIRS is missing completely. Basically, this renders luarocks completely unusable.
Also, due to wrong LUAROCKS_UNAME_M installing or creating arch-dependent binary rocks are impossible: https://github.com/keplerproject/luarocks/blob/master/src/luarocks/install.lua#L49 and https://github.com/keplerproject/luarocks/blob/master/src/luarocks/pack.lua#L131 That's not critical, though, as it seems there's currently no binary linux rocks in tree.
Proposition: Create per-arch site_config.<arch>.lua files, symlink on post-install. Either this or patch with autodetection of arch/paths at runtime.
Seriously, it's been 1.5 years since this bug was posted. Could someone pick up maintaining luarocks, as it seems original maintainer can't/doesn't want to?
Sending out bugmail telling other people to do some work is never going to be well received and doesn't really accomplish much. I'd delete myself from CC if I could...
It's not about doing or not doing work. It's not a demand. If maintainer can't maintain, well, then the package should be orphaned, so someone can take over maintainership, or it can be retired from fedora completely, because absence of package is still better than broken one. You can remove yourself by closing this report, if you want, i'll open another one.
luarocks-2.2.3-0.2.rc2.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-1b10c6bdc6
luarocks-2.2.3-0.2.rc2.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update luarocks' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-1b10c6bdc6
luarocks-2.2.3-0.2.rc2.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update luarocks' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-8bf175462a
luarocks-2.2.3-0.2.rc2.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
luarocks-2.2.3-0.2.rc2.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.