No talking here. If you have a package filing, file a new bug and make it block this one.
this is over 1 year old... I feel it should be exposed to ~arch
(In reply to Julian Ospald (hasufell) from comment #1) > this is over 1 year old... I feel it should be exposed to ~arch Maybe... I'll review the open bugs this weekend.
i'd unmask at this point despite of remaining broken packages, they'll have to be dealt with, maybe with more radical hand, stupid for our lua to be behind like this anyways, the decision should come from lua maintainers, not me
Most of the breakages happened because we decided to go in a way that isn't supported by upstream (build lua dynamically), so most upstreams don't care about our breakage, and I'd say that they are correct, despite all our "policies" wrt not build things statically, etc. I'm planning on suggest removing that patch and just build lua in the way that upstream supports, so we get a better experience, and better support from upstream. But I agree with Samuli, let's unmask the beast.
(In reply to Rafael G. Martins from comment #4) > Most of the breakages happened because we decided to go in a way that isn't > supported by upstream (build lua dynamically), so most upstreams don't care > about our breakage, and I'd say that they are correct, despite all our > "policies" wrt not build things statically, etc. I'm planning on suggest > removing that patch and just build lua in the way that upstream supports, so > we get a better experience, and better support from upstream. > I have heard that before as well from some upstreams like games-action/minetest which uses lua, but I am not sure if I understand the details. One reason was that they built lua with a flag that we did not have. But that was simply fixed by adding the "deprecated" USE flag to dev-lang/lua. I'd say we should discuss this with QA.
(In reply to Julian Ospald (hasufell) from comment #5) > (In reply to Rafael G. Martins from comment #4) > > Most of the breakages happened because we decided to go in a way that isn't > > supported by upstream (build lua dynamically), so most upstreams don't care > > about our breakage, and I'd say that they are correct, despite all our > > "policies" wrt not build things statically, etc. I'm planning on suggest > > removing that patch and just build lua in the way that upstream supports, so > > we get a better experience, and better support from upstream. > > > > I have heard that before as well from some upstreams like > games-action/minetest which uses lua, but I am not sure if I understand the > details. One reason was that they built lua with a flag that we did not > have. But that was simply fixed by adding the "deprecated" USE flag to > dev-lang/lua. I'd say we should discuss this with QA. +1 on discuss with QA.
CCing qa@ Guys, what's the progress here? I understand that there is some work that needs to be done here, but can we please discuss generic direction about what should we do here? Maybe some help needed?
5.2.x has a number of advantages for embedded Lua. What work needs to be done to get it unmasked? Thanks - Will
Having looked through the comments of all dependent bugs, almost all of them are resolvable through updating to current upstream releases or restricting dependencies. The only one still being open after that will be prosody-0.9, as lua-5.2 support will be introduced only in 0.10 which is the current development version. So we have to consider whether we want to keep all lua packages back only because of prosody or whether we can consider lua-5.1 as a prosody-runtime component then.
Is anyone actively working on this? Lua 5.2 is currently 6+ years old, can this (along with 5.3) please be stabilized? If there are still packages that don't work it probably makes sense to either drop them or make sure they depend on an older lua version.
(In reply to Simon from comment #10) > Is anyone actively working on this? Lua 5.2 is currently 6+ years old, can > this (along with 5.3) please be stabilized? If there are still packages that > don't work it probably makes sense to either drop them or make sure they > depend on an older lua version. Although this is a tracker, and thus "no talking here", I second the cited comment. Six whole years have already passed since the OP, lua is now at v5.3 but Gentoo only has ONE version unmasked: 5.1.5-r4. Why is that? As a regular user I cannot understand the situation.
Reference Manual --> Incompatibilities: http://www.lua.org/manual/5.2/manual.html#8 And the same for Lua 5.3: http://www.lua.org/manual/5.3/manual.html#8
dev-lang/lua slots have been unmasked so I guess this can be closed now.