On 12/23/20 6:18 PM, Michael Orlitzky wrote:
Using pkg-config has a related problem. If lua-5.1 is eselected and if
the upstream build system runs $(pkg-config ... lua), it's going to get
the information for lua-5.1, even if you're trying to build against
lua-5.2. So, first I have to patch upstr
On 12/23/20 4:51 PM, Mart Raudsepp wrote:
Ühel kenal päeval, K, 23.12.2020 kell 07:49, kirjutas Michael Orlitzky:
AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"])
How do I pass the name "lua5.2" to that, without hacking configure.ac
and running autoreconf? The only option that comes to
Ühel kenal päeval, K, 23.12.2020 kell 07:49, kirjutas Michael Orlitzky:
> AC_SEARCH_LIBS([whatever], [lua], [lua_found="yes"])
>
> How do I pass the name "lua5.2" to that, without hacking configure.ac
> and running autoreconf? The only option that comes to mind is to
> build
> the entire proje
On 12/23/20 8:35 AM, Jaco Kroon wrote:
Michael,
I'm busy disecting what Marek has done for asterisk as I need to make
that work for multiple versions of net-misc/asterisk-16.14.0-r100, not
merely the one he did it for - perhaps that would be helpful for you as
well?
I don't know lua at all.
An
Michael,
I'm busy disecting what Marek has done for asterisk as I need to make
that work for multiple versions of net-misc/asterisk-16.14.0-r100, not
merely the one he did it for - perhaps that would be helpful for you as
well?
I don't know lua at all.
Anyway, I'm on IRC as jkroon if you'd like
On 12/23/20 4:09 AM, Marek Szuba wrote:
I think what you are looking for is lua_get_shared_lib() from
lua-utils.eclass. We have already got ebuilds in the tree which use
it.
Knowing the library name only helps if I patch the build system; that's
what I'm getting at. The few packages where th
On December 23, 2020 2:56:05 AM UTC, Michael Orlitzky wrote:
>One last design issue that I ran into during the migration.
>
>The slotted lua ebuilds install the headers into subdirectories like
>/usr/include/lua5.2, but otherwise with their upstream names. The
>libraries, on the other hand,
On 12/22/20 6:15 PM, Marek Szuba wrote:
> Dear all,
>
> As of right now, the blocking slotted-lua tracker depends on 5 (FIVE) open
> bugs. The still-to-be migrated packages are:
>
> app-metrics/collectd - ebuild under review of the maintainer
> games-strategy/megaglest - no response from maintai
On 12/22/20 6:15 PM, Marek Szuba wrote:
Dear all,
mail-filter/opendkim - committed ebuild needs one extra fix
One last design issue that I ran into during the migration.
The slotted lua ebuilds install the headers into subdirectories like
/usr/include/lua5.2, but otherwise with their upstrea
Dear all,
As of right now, the blocking slotted-lua tracker depends on 5 (FIVE) open
bugs. The still-to-be migrated packages are:
app-metrics/collectd - ebuild under review of the maintainer
games-strategy/megaglest - no response from maintainers (games@g.o)
mail-filter/opendkim - committed ebui
On 2020-12-09 16:21, Michael Orlitzky wrote:
LUA_DEPS itself will not but the change of LUA_SINGLE_TARGET in the
package in question will, same way other packages can be rebuilt on
USE-flag changes.
So lua has inherited the python approach of requiring everyone to use
portage? =/
I don't know
On 12/9/20 10:10 AM, Marek Szuba wrote:
LUA_DEPS itself will not but the change of LUA_SINGLE_TARGET in the
package in question will, same way other packages can be rebuilt on
USE-flag changes.
So lua has inherited the python approach of requiring everyone to use
portage? =/
On 2020-12-09 15:56, Michael Orlitzky wrote:
I think the slotted lua ebuilds should be doing some eselect-lua stuff
in pkg_postinst() and pkg_postrm(). For example:
* I have lua-5.1 and lua-5.2 installed
* Lua-5.2 is eselected
* I uninstall lua-5.2
* Now /usr/lib64/pkgconfig/lua.pc
On 12/7/20 9:11 AM, Marek Szuba wrote:
On 2020-12-04 13:16, Marek Szuba wrote:
Since a week ago the number of open bugs blocking the slotted-Lua
tracker has been reduced from 119 to under 80.
Updated count as of a few minutes ago: 64 open tickets! Full list:
https://dev.gentoo.org/~marecki/o
On 2020-12-04 13:16, Marek Szuba wrote:
Since a week ago the number of open bugs blocking the slotted-Lua
tracker has been reduced from 119 to under 80.
Updated count as of a few minutes ago: 64 open tickets! Full list:
https://dev.gentoo.org/~marecki/open_blocking_lua_eclass_bugs-20201207135
Dear everyone,
Since a week ago the number of open bugs blocking the slotted-Lua tracker has
been reduced from 119 to under 80. A few of these have been either made no
longer dependent on dev-lang/lua, last-rited, or moved to a separate tracker
(it is linked to the old one under See Also) owing
Let me begin by giving my sincere thanks to everyone who has already
taken time in the last several weeks to either migrate their
Lua-dependent packages to lua{,-single}.eclass or otherwise made sure
said packages will not block migration to slotted dev-lang/lua. Your
efforts have been VERY muc
Dear everyone,
tl;dr: This is an appeal to everyone in Gentoo who maintains packages
depending on dev-lang/lua, dev-lang/luajit or dev-lua/*: please migrate
your packages to lua.eclass (ones which have to be installed for
multiple Lua implementations, i.e. most likely Lua modules) and
lua-sin
All,
I'm trying again because I didn't see my last msg come back.
Someone mentioned issues with slotted lua on a thread earlier but didn't
give any details.
What are the issues that you have found? are there open bugs for them?
I would like to take a look.
Thanks,
William
signature.asc
Desc
19 matches
Mail list logo
