Due to API breakage in lua-5.1.1 i dropped your keywords. Please test and readd as you see appropiate. Please note that upstreams build system changed quite a bit and i introduced a modified debian patch to fix it. Please keep an extra eye open for possible bugs.
Although I have seen that they have a really ill build system I give away ~x86 today.
added ~ppc64
All I can say is that it seemingly compiles well and that it complained about a couple of sample scripts that I tried. Marked ~hppa.
tolua, ion3 and lighttpd cannot build against lua-5.1.1 because they cannot find -llua Otherwise, it looks ok on ~sparc. Will keyword once we figure out the above.
Narf, bugzie swallowed my comment: i changed the library name, b/c lua-5.0.3 came with liblualib, but seeing they also got a liblua i've reverted to the original behaviour of calling the library liblua.* I also tested the not in tree ion3 w/ it, compiles quite fine.
Whoops. I just opened bug 158460 which looks like it pertains to this. Basically, imapfilter is looking for both liblua and liblualib. With 5.1.1, we only get liblua and the emerge of imapfilter fails. Whoever is working on this bug may want to take a look at imapfilter also.
liblualib and liblua are quite the same actually. liblualib just adds in more libs (libm, readline, dl, et. al) if i read the Makefile correctly. All that is now provided with liblua. Upstream only provides liblua as of my knowledge. This issue is really upstream, and i'll write to them tomorrow. Short term action would be to patch the Makefile they provide or (which i'd find kinda ugly) symlinking of liblua.so to liblualib.so via the lua ebuild. But personally, i'd suggest fix the packages.
Just adding a note about the 5.1.1's liblua+liblualib issue is more dangerous than it seems, for example on lua enabled kde the missing liblualib.so.5.0 and/or liblua.so.5.0 (note the final zero) breaks fatally editor kpart, causing unidentifiable crash for kate session startup, nonfunctionality of kdevelop and partial nonfunctionality of konqueror. Reemerging kdelibs-3.5.5-r7 manually was a good fix for me, so I can keep lua-5.1.1 for other esoteric purposes. However, revdep-rebuild was of no help in this case. (This comment is meant to contain all the relevant keywords to point other searchers this way.)
Here we go: the shiny new, absolutly beautiful *cough* slotted lua has arrived in the tree. The good news is: you now can keep two APIs around, so your programs are all fine, while you try out new shiny stuff. Here's the dark side of it: i'm still trying to figure out how programs can keep to use -llua in their compiles and it will just work[tm]. Currently, due to both lua librarys being installed in parallel, none of them gets the liblua.* slot, which most apps will look out for. Till i've figured out how to release the beast w/o breaking everyones system, it remains in the cage that is package.mask. However, if you're brave enough, test them out and give 'em some keyword love. The librarys are still fine, it's just their interface to the outside world that sucks hard.
portage/dev-lang/lua/files/lua-5.1.1-Makefile.patch was broken as of my --sync last night... the two patch chunks have different relative directories. The relative directories in each chunk have to match. I suppose the two chunks were manually stuck together in the same file. ( the patch is only used by lua-5.1.1-r1 which is hard-masked )
I'm now officially unsure if adding the slotted luas was that a good idea at all. Seems we can get lua-5.1.1 supported in the tree w/o backwards compatibility issues. In plain english: i'm almost sure we can update any lua using app in the tree to use lua-5.1.1 thus obsoleting the need for lua-5.0*. I've therefore removed the slotted versions (lua-wrapper will follow in a bit) from the tree. Arches: please consider marking dev-lang/lua-5.1.1 ~arch. I'll see to the broken apps together with their maintainers and committing fixes as i have them.
I tryed to compile lua 5.1.1 on amd64 and it compiled. What do u think about adding ~amd64 to ebuild.
I confirm successful compilation on amd64 .
(In reply to comment #13) > I confirm successful compilation on amd64 . > ditto, added ~amd64
~sparc'd
alpha, arm, ia64, mips: I have removed your ~arch keywords on =www-servers/lighttpd-1.4.13* until you have lua-5.1* keyworded. When you add yourself back to lua, add yourself to lighttpd-1.4.13* as well.
alpha, arm, ia64, mips: reping, you are missing out out the lighttpd goodness because of this bug.
~ia64 has now lua and lighttpd.
Comment #8 is really important. What about ~x86? Synced tree and updated system pulled in 5.1.1-r2 lua and my kde* parts which use them are broken now, missing the liblualib.so. Manually creating the symlink does help but this is not a fix. Any thoughts about x86?
(In reply to comment #19) > Synced tree and updated system pulled in 5.1.1-r2 lua and my kde* parts which > use them are broken now, missing the liblualib.so. Can you elaborate on what parts exactly are broken and how i can reproduce? The liblualib.so is *gone* in 5.1 and nothing i can/will do about it. Anything depending on it to be there is not 5.1 ready.
~alpha done. Sorry for the delay. - ferdy
To all slackers: lua-5.1.2 is out, fixing bugs from the previous release. Please keyword it.
Hey mips team, i'm kinda stuck with lua-5.0* if you don't keyword and stable anything 5.1* in the future. This bug is over a year old. Please give some love to the newly comitted 5.1.3 and the 5.1.2 version, as that's going stable soon enough. Thanks.
Keywording continues at another bug as this isn't about keywording 5.1.2 anymore. *** This bug has been marked as a duplicate of bug 222243 ***
