Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua
On 2020-10-05 20:01, Marek Szuba wrote:
I have decided to add support for dev-lang/lua:0 because having thought
quite a lot about the transition path from Lua ebuilds as they are to
the new eclasses, it seems to be the most sane approach. Still, I hope
this will not stay around for too long.
NOT pushed because having poked around various Lua revdeps in the tree I
realised that with the way Lua detection works in e.g. CMake, the only
way of making sure an ebuild really honours the values of LUA_TARGETS /
LUA_SINGLE_TARGET, or indeed LUA_COMPAT, is to have multiple Lua
versions installed side by side. In other words, migrating ebuilds to
lua{,-single}.eclass prior to unmasking dev-lang/lua:5.x could in fact
result in quite a mess.
Nothing particularly noteworthy about LuaJIT support, possibly apart
from the fact that we take advantage of it being allegedly being a
drop-in replacement for lua-5.1.
Pushed.
--
MS
OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Python 2 cleanup: remaining packages
Hi, Here's a list of remaining packages that need to be handled as part of Python 2.7 removal. Note that I've assembled that list a few days ago but I think it's up-to-date. It does not include packages that were last-rited or otherwise masked. Stabilization of py3/no-py version in progress: - app-i18n/sunpinyin - app-mobilephone/sobexsrv - dev-cpp/gtest - dev-libs/libdnet - dev-libs/libxslt - dev-tcltk/snack - media-gfx/gimp - net-wireless/aircrack-ng - sys-cluster/pacemaker Waiting for future stabilization (build-time deps): - mail-client/thunderbird - www-client/firefox Waiting for cleanup of old (non-trivial!): - dev-db/mongodb - dev-db/percona-server - media-tv/kodi - media-tv/mythtv - x11-plugins/enigmail Unresolved issues in py3 version, need urgent help: - dev-java/javatoolkit Build-time deps, to stay: - dev-lang/spidermonkey - dev-python/pypy* - dev-python/typing - dev-qt/qtwebengine - games-strategy/0ad - www-client/chromium - www-client/seamonkey Waiting for py3 port (potential last rite candidates): - games-engines/renpy - kde-apps/kross-interpreters Dependencies of other packages on the list: - dev-python/cheetah (dev-db/mongodb) - dev-python/numpy-python2 (games-engines/renpy) - net-wireless/lorcon (net-wireless/aircrack-ng) -- Best regards, Michał Górny signature.asc Description: This is a digitally signed message part
[gentoo-dev] [PATCH 0/3] lua-utils.eclass: expose header and library locations
Having had a gander at some of the revdeps of dev-lang/lua{,jit}
currently present in the tree, it is fairly common to force the use of
the right Lua version by pointing src_configure() to the right include
directory and library files. Unfortunately doing it this way seems to
be the sanest way of dealing with Lua detection in CMake so it is
unlikely to go away any time soon... Therefore, provide functions
returning this information in an implementation-independent way.
[gentoo-dev] [PATCH 3/3] lua-utils.eclass: Add lua_get_static_lib()
For build systems which must be pointed directly to the relevant files,
e.g. CMake.
Signed-off-by: Marek Szuba
---
eclass/lua-utils.eclass | 24
1 file changed, 24 insertions(+)
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 100be14cb08..922f72b80d6 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -329,6 +329,11 @@ _lua_export() {
export LUA_SHARED_LIB="${val}".so
debug-print "${FUNCNAME}: LUA_SHARED_LIB =
${LUA_SHARED_LIB}"
;;
+ LUA_STATIC_LIB)
+ local val=$(_lua_get_library_file ${impl})
+ export LUA_STATIC_LIB="${val}".a
+ debug-print "${FUNCNAME}: LUA_STATIC_LIB =
${LUA_STATIC_LIB}"
+ ;;
LUA_VERSION)
local val
@@ -443,6 +448,25 @@ lua_get_shared_lib() {
echo "${LUA_SHARED_LIB}"
}
+# @FUNCTION: lua_get_static_lib
+# @USAGE: []
+# @DESCRIPTION:
+# Obtain and print the expected name, with path, of the main static library
+# of the given Lua implementation. If no implementation is provided,
+# ${ELUA} will be used.
+#
+# Note that it is up to the ebuild maintainer to ensure Lua actually
+# provides a static library.
+#
+# Please note that this function requires Lua and pkg-config installed,
+# and therefore proper build-time dependencies need be added to the ebuild.
+lua_get_static_lib() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ _lua_export "${@}" LUA_STATIC_LIB
+ echo "${LUA_STATIC_LIB}"
+}
+
# @FUNCTION: lua_get_version
# @USAGE: []
# @DESCRIPTION:
--
2.26.2
[gentoo-dev] [PATCH 2/3] lua-utils.eclass: Add lua_get_shared_lib()
For build systems which must be pointed directly to the relevant files,
e.g. CMake.
Signed-off-by: Marek Szuba
---
eclass/lua-utils.eclass | 52 +
1 file changed, 52 insertions(+)
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 8f54e57dbd7..100be14cb08 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -190,6 +190,34 @@ _lua_wrapper_setup() {
# /usr/bin/lua5.1
# @CODE
+# @FUNCTION: _lua_get_library_file
+# @USAGE:
+# @INTERNAL
+# @DESCRIPTION:
+# Get the core part (i.e. without the extension) of the library name,
+# with path, of the given Lua implementation.
+# Used internally by _lua_export().
+_lua_get_library_file() {
+ local impl="${1}"
+ local libdir libname
+
+ case ${impl} in
+ luajit)
+ libname=lib$($(tc-getPKG_CONFIG) --variable libname
${impl}) || die
+ ;;
+ lua*)
+ libname=lib${impl}
+ ;;
+ *)
+ die "Invalid implementation: ${impl}"
+ ;;
+ esac
+ libdir=$($(tc-getPKG_CONFIG) --variable libdir ${impl}) || die
+
+ debug-print "${FUNCNAME}: libdir = ${libdir}, libname = ${libname}"
+ echo "${libdir}/${libname}"
+}
+
# @FUNCTION: _lua_export
# @USAGE: [] ...
# @INTERNAL
@@ -296,6 +324,11 @@ _lua_export() {
export LUA_PKG_DEP
debug-print "${FUNCNAME}: LUA_PKG_DEP =
${LUA_PKG_DEP}"
;;
+ LUA_SHARED_LIB)
+ local val=$(_lua_get_library_file ${impl})
+ export LUA_SHARED_LIB="${val}".so
+ debug-print "${FUNCNAME}: LUA_SHARED_LIB =
${LUA_SHARED_LIB}"
+ ;;
LUA_VERSION)
local val
@@ -391,6 +424,25 @@ lua_get_lmod_dir() {
echo "${LUA_LMOD_DIR}"
}
+# @FUNCTION: lua_get_shared_lib
+# @USAGE: []
+# @DESCRIPTION:
+# Obtain and print the expected name, with path, of the main shared library
+# of the given Lua implementation. If no implementation is provided,
+# ${ELUA} will be used.
+#
+# Note that it is up to the ebuild maintainer to ensure Lua actually
+# provides a shared library.
+#
+# Please note that this function requires Lua and pkg-config installed,
+# and therefore proper build-time dependencies need be added to the ebuild.
+lua_get_shared_lib() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ _lua_export "${@}" LUA_SHARED_LIB
+ echo "${LUA_SHARED_LIB}"
+}
+
# @FUNCTION: lua_get_version
# @USAGE: []
# @DESCRIPTION:
--
2.26.2
[gentoo-dev] [PATCH 1/3] lua-utils.eclass: Add lua_get_include_dir()
For build systems which must be pointed directly to the relevant files,
e.g. CMake.
Signed-off-by: Marek Szuba
---
eclass/lua-utils.eclass | 24
1 file changed, 24 insertions(+)
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 24ef67635d5..8f54e57dbd7 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -250,6 +250,14 @@ _lua_export() {
export LUA_CMOD_DIR=${val}
debug-print "${FUNCNAME}: LUA_CMOD_DIR =
${LUA_CMOD_DIR}"
;;
+ LUA_INCLUDE_DIR)
+ local val
+
+ val=$($(tc-getPKG_CONFIG) --variable includedir
${impl}) || die
+
+ export LUA_INCLUDE_DIR=${val}
+ debug-print "${FUNCNAME}: LUA_INCLUDE_DIR =
${LUA_INCLUDE_DIR}"
+ ;;
LUA_LIBS)
local val
@@ -335,6 +343,22 @@ lua_get_cmod_dir() {
echo "${LUA_CMOD_DIR}"
}
+# @FUNCTION: lua_get_include_dir
+# @USAGE: []
+# @DESCRIPTION:
+# Obtain and print the name of the directory containing header files
+# of the given Lua implementation. If no implementation is provided,
+# ${ELUA} will be used.
+#
+# Please note that this function requires Lua and pkg-config installed,
+# and therefore proper build-time dependencies need be added to the ebuild.
+lua_get_include_dir() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ _lua_export "${@}" LUA_INCLUDE_DIR
+ echo "${LUA_INCLUDE_DIR}"
+}
+
# @FUNCTION: lua_get_LIBS
# @USAGE: []
# @DESCRIPTION:
--
2.26.2
Re: [gentoo-dev] [PATCH 1/5] verify-sig.eclass: New eclass to verify OpenPGP sigs
On Sun, Oct 11, 2020 at 7:35 AM Joonas Niilola wrote: > > > On 10/11/20 4:40 PM, Thomas Deutschmann wrote: > > > > > > First of all, calm down. You are reading too much into this. Just > > revert your own logic: You obviously like your idea, worked on this > > and pushed it to repository. Don't you see that anyone could ask the > > same? Who are you? Why do believe that you can force something like > > that down to everyone's system? That feature got enabled in developers > > profiles by default, it will blow up distfiles with useless data (a > > view you can have when you share my concerns and don't see any > > problems with current Manifest system; For example we banned stuff in > > $FILESDIR before and asked developers to move them to d.g.o when >25kb > > in total arguing that large distfile is affecting *any* user... I am > > not comparing this 1:1 but to repeat your question: Who are you that > > you can decide to force something similar down to everyone). > > > > > > Sure, if I am the only having that opinion and most people see a value > > in this and disagree with me... > I split this into three parts: (1) Is there a problem? I like to think there is general agreement that developers do not cryptographically verify distfiles for most upstreams when bumping, and thus we could all agree there is room for improvement here. In an ideal world we are relying on existing systems (https, CAs, etc) to prevent MITM attacks on source downloads, but not much is used beyond that. (2) Does the proposed solution help? This is not a yes or no question; its nuanced. Having a keyring makes verifying easier. As Whissi notes, we don't discuss much the managing of said keyrings (or revocation) and so I think the proposed solution does have similar problems to the existing solution. Instead of managing and verifying upstream tarballs, we have to verify keys. There is no automation for this either...and so we end up with a similar attack surface. There is *improvement* (if someone MITMs your download, the verification will notice.) Is that the most likely attack, or is it stolen upstream signing keys? Who can really say? (3) The implementation. This is honestly the part that I dislike the most, particularly in the original draft, some of the problems have been fixed already. I'm not excited about thousands of new packages, nor am I excited about the key management in the proposal. The biggest problem (that it was on by default) were already fixed which is good; I don't even see this as a feature for end users at all; instead its a feature for developers and maybe a QA bot (that verifies the distfiles.) Leading out of 3, maybe that is a decent solution also. Can we build a QA bot that detects bad bumps but also has not terrible key management? Is there an automated protocol for fetching *and* verifying upstream files like this? Could we annotate SRC_URI somehow with verification metadata? -A > > > > > I vote for disabling that USE flag in developer profile. There are more > than 1 person using it not yet buying or understanding this "draft". I > also believe such a profile flag change should be discussed first. > > -- juippis > >
Re: [gentoo-dev] [PATCH 3/3] lua-utils.eclass: Add lua_get_static_lib()
On Mon, 2020-10-12 at 16:05 +0200, Marek Szuba wrote:
> For build systems which must be pointed directly to the relevant
> files,
> e.g. CMake.
>
> Signed-off-by: Marek Szuba
> ---
> eclass/lua-utils.eclass | 24
> 1 file changed, 24 insertions(+)
>
> diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
> index 100be14cb08..922f72b80d6 100644
> --- a/eclass/lua-utils.eclass
> +++ b/eclass/lua-utils.eclass
> @@ -329,6 +329,11 @@ _lua_export() {
> export LUA_SHARED_LIB="${val}".so
> debug-print "${FUNCNAME}:
> LUA_SHARED_LIB = ${LUA_SHARED_LIB}"
> ;;
> + LUA_STATIC_LIB)
> + local val=$(_lua_get_library_file
> ${impl})
> + export LUA_STATIC_LIB="${val}".a
> + debug-print "${FUNCNAME}:
> LUA_STATIC_LIB = ${LUA_STATIC_LIB}"
> + ;;
> LUA_VERSION)
> local val
>
> @@ -443,6 +448,25 @@ lua_get_shared_lib() {
> echo "${LUA_SHARED_LIB}"
> }
>
> +# @FUNCTION: lua_get_static_lib
> +# @USAGE: []
> +# @DESCRIPTION:
> +# Obtain and print the expected name, with path, of the main static
> library
> +# of the given Lua implementation. If no implementation is provided,
> +# ${ELUA} will be used.
> +#
> +# Note that it is up to the ebuild maintainer to ensure Lua actually
> +# provides a static library.
> +#
> +# Please note that this function requires Lua and pkg-config
> installed,
> +# and therefore proper build-time dependencies need be added to the
> ebuild.
> +lua_get_static_lib() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + _lua_export "${@}" LUA_STATIC_LIB
> + echo "${LUA_STATIC_LIB}"
> +}
> +
> # @FUNCTION: lua_get_version
> # @USAGE: []
> # @DESCRIPTION:
When is passing static libs ever useful for Lua?
Re: [gentoo-dev] [PATCH 3/3] lua-utils.eclass: Add lua_get_static_lib()
On 2020-10-12 17:39, David Seifert wrote: When is passing static libs ever useful for Lua? No idea - but both Lua and LuaJIT install them, if conditionally on USE=static-libs in the latter case. -- MS OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] lua-utils.eclass: Add lua_get_static_lib()
On Mon, 2020-10-12 at 17:57 +0200, Marek Szuba wrote: > On 2020-10-12 17:39, David Seifert wrote: > > > When is passing static libs ever useful for Lua? > > No idea - but both Lua and LuaJIT install them, if conditionally on > USE=static-libs in the latter case. > Then please don't provide this helper function. Consumers should just use lua_get_shared_lib(). We similarly don't provide getters for libpythonX.Y.a either, for the same reason.
