[gentoo-dev] newsitem: k8s split packages round 3
[Note: After chatting on irc, I haven't come up with anything that makes sense for a kubernetes meta package, but I am open to meta packages if others think they might be useful, so let's discuss that idea in a separate thread. The text of the newsitem is below.] Title: kubernetes Split Packages Returning Author: William Hubbs Posted: 2020-10-06 Revision: 1 News-Item-Format: 2.0 Display-If-Installed: sys-cluster/kubernetes In order to fix the ability to upgrade kubernetes components separately, the kubernetes split packages are returning [1]. Starting with kubernetes 1.17.12, 1.18.9 and 1.19.2, you will need to install the following packages in the appropriate configuration for your cluster. sys-cluster/kubeadm sys-cluster/kube-apiserver sys-cluster/kube-controller-manager sys-cluster/kubectl sys-cluster/kubelet sys-cluster/kube-proxy sys-cluster/kube-scheduler Once the split packages are stabilized, sys-cluster/kubernetes will be masked and removed. [1] https://bugs.gentoo.org/741572 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua
пн, 5 окт. 2020 г. в 22:20, Marek Szuba : > > Is there a slotmove that can be applied? > > I am afraid I do not understand the question. What do you want to move, > and why? Currently portage is mostly lua:5.1 aware and the first thing is move dev-lang/lua:0 to 5.1 slot by slotmove in profiles/updates: slotmove dev-lang/lua 0 5.1 and update all ebuilds with dev-lang/lua:0 dependency (there are about 200 ebuilds with that dependency, maybe there need to be an issue news item, since there may need to rebuild all dependencies). After that we need to unmask and stabilize "true" slotted lua:5.1 version, so this would be step 0 on slotted lua migration. After that migration of rest packages to new lua.eclass will be a lot easier. > > I think a better idea is to migrate the base set of lua packages > > Define "base set of lua packages". Well, core build ecosystem of lua packages: dev-lua/ldoc dev-lua/lpeg dev-lua/luacov dev-lua/luacrypto dev-lua/luadoc dev-lua/luarocks dev-lua/luasystem dev-lua/lua-utf8 dev-lua/lua-zlib maybe more. -- >From Siberia with Love!
Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua
On 2020-10-05 20:30, Azamat Hackimov wrote: > Is there a slotmove that can be applied? I am afraid I do not understand the question. What do you want to move, and why? > Can be lua:0 and lua:5.1 coexist? In theory they can (I say "in theory" because app-eselect/eselect-lua ebuild currently block dev-lang/lua:0), except having :0 installed would conflict with using eselect-lua - which I guess might be acceptable during the transition period. Anyway, there are no file collisions between :0 and :5.1, and while the two use the same CMOD and LMOD directories (for the record, so does LuaJIT for now) this should be harmless - files in LMOD would be very much identical, and from what I recall from discussions on IRC compiled modules in CMOD must not link against Lua libraries themselves so they should be implementation-independent. > I think a better idea is to migrate the base set of lua packages Define "base set of lua packages". > (maybe under package.mask) ...meaning that at some point in the future we would have to unmask slotted Lua AND all the ebuilds depending on it, potentially unleashing a torrent of errors. Although we cannot really avoid this step altogether, I would rather let maintainers adapt their Lua ebuilds to the eclasses first and handle slotted Lua as a separate step. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua
Hi. пн, 5 окт. 2020 г. в 21:01, Marek Szuba : > > 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. Is there a slotmove that can be applied? Can be lua:0 and lua:5.1 coexist? Will there be more problems with that approach? I think a better idea is to migrate the base set of lua packages to slotted Lua (maybe under package.mask) and slowly migrate the rest of the portage. -- >From Siberia with Love!
[gentoo-dev] [PATCH 2/2] lua-utils.eclass: support dev-lang/lua:0
This is to make it possible for the maintainers of Lua-dependent ebuilds
to transition to lua{,-single}.eclass without unmasking slotted
dev-lang/lua.
Signed-off-by: Marek Szuba
---
eclass/lua-utils.eclass | 8
profiles/desc/lua_single_target.desc | 1 +
profiles/desc/lua_targets.desc | 1 +
3 files changed, 10 insertions(+)
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 24ef67635d5..b84fb6e9a68 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -38,6 +38,7 @@ inherit toolchain-funcs
# All supported Lua implementations, most preferred last
_LUA_ALL_IMPLS=(
luajit
+ lua0
lua5-1
lua5-2
lua5-3
@@ -211,6 +212,10 @@ _lua_export() {
impl=${1}
shift
;;
+ lua0)
+ impl="lua"
+ shift
+ ;;
lua*)
impl=${1/-/.}
shift
@@ -272,6 +277,9 @@ _lua_export() {
luajit)
LUA_PKG_DEP="dev-lang/luajit:="
;;
+ lua)
+ LUA_PKG_DEP="dev-lang/lua:0"
+ ;;
lua*)
LUA_PKG_DEP="dev-lang/lua:${impl#lua}"
;;
diff --git a/profiles/desc/lua_single_target.desc
b/profiles/desc/lua_single_target.desc
index c3d422e434d..04f71b1fe58 100644
--- a/profiles/desc/lua_single_target.desc
+++ b/profiles/desc/lua_single_target.desc
@@ -3,6 +3,7 @@
# This file contains descriptions of LUA_SINGLE_TARGET USE_EXPAND flags.
+lua0 - Build for unslotted Lua only
lua5-1 - Build for Lua 5.1 only
lua5-2 - Build for Lua 5.2 only
lua5-3 - Build for Lua 5.3 only
diff --git a/profiles/desc/lua_targets.desc b/profiles/desc/lua_targets.desc
index 75b9e0f86af..9f296fe2499 100644
--- a/profiles/desc/lua_targets.desc
+++ b/profiles/desc/lua_targets.desc
@@ -3,6 +3,7 @@
# This file contains descriptions of LUA_TARGETS USE_EXPAND flags.
+lua0 - Build with unslotted Lua
lua5-1 - Build with Lua 5.1
lua5-2 - Build with Lua 5.2
lua5-3 - Build with Lua 5.3
--
2.26.2
[gentoo-dev] [PATCH 1/2] lua-utils.eclass: Support luajit
According to discussions on IRC, luajit should work as a drop-in
replacement for lua5.1 - and indeed, at least for x11-wm/awesome
it has worked.
Note that for the time being dev-lang/luajit uses the same module
directories as dev-lang/lua:5.1, which may lead to weird behaviour in
multi-impl ebuilds supporting both lua5-1 and luajit. Hopefully we will
get luajit to use its own directories so that it is fully independent,
same as we install pypy3 modules in their own directory hierarchy in
spite of compatibility with cpython-3.6.
Signed-off-by: Marek Szuba
---
eclass/lua-utils.eclass | 21 +
profiles/desc/lua_single_target.desc | 1 +
profiles/desc/lua_targets.desc | 1 +
3 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
index 490d19a0019..24ef67635d5 100644
--- a/eclass/lua-utils.eclass
+++ b/eclass/lua-utils.eclass
@@ -14,8 +14,6 @@
# A utility eclass providing functions to query Lua implementations,
# install Lua modules and scripts.
#
-# Please note that for the time being this eclass does NOT support luajit.
-#
# This eclass neither sets any metadata variables nor exports any phase
# functions. It can be inherited safely.
@@ -39,6 +37,7 @@ inherit toolchain-funcs
# @DESCRIPTION:
# All supported Lua implementations, most preferred last
_LUA_ALL_IMPLS=(
+ luajit
lua5-1
lua5-2
lua5-3
@@ -141,9 +140,16 @@ _lua_wrapper_setup() {
local ELUA LUA
_lua_export "${impl}" ELUA LUA
- # Lua interpreter and compiler
+ # Lua interpreter
ln -s "${EPREFIX}"/usr/bin/${ELUA} "${workdir}"/bin/lua || die
- ln -s "${EPREFIX}"/usr/bin/${ELUA/a/ac} "${workdir}"/bin/luac
|| die
+
+ # Lua compiler, or a stub for it in case of luajit
+ if [[ ${ELUA} == luajit ]]; then
+ # Just in case
+ ln -s "${EPREFIX}"/bin/true "${workdir}"/bin/luac || die
+ else
+ ln -s "${EPREFIX}"/usr/bin/${ELUA/a/ac}
"${workdir}"/bin/luac || die
+ fi
# pkg-config
ln -s "${EPREFIX}"/usr/$(get_libdir)/pkgconfig/${ELUA}.pc \
@@ -201,6 +207,10 @@ _lua_export() {
local impl var
case "${1}" in
+ luajit)
+ impl=${1}
+ shift
+ ;;
lua*)
impl=${1/-/.}
shift
@@ -259,6 +269,9 @@ _lua_export() {
LUA_PKG_DEP)
local d
case ${impl} in
+ luajit)
+ LUA_PKG_DEP="dev-lang/luajit:="
+ ;;
lua*)
LUA_PKG_DEP="dev-lang/lua:${impl#lua}"
;;
diff --git a/profiles/desc/lua_single_target.desc
b/profiles/desc/lua_single_target.desc
index 1bee02b6978..c3d422e434d 100644
--- a/profiles/desc/lua_single_target.desc
+++ b/profiles/desc/lua_single_target.desc
@@ -7,3 +7,4 @@ lua5-1 - Build for Lua 5.1 only
lua5-2 - Build for Lua 5.2 only
lua5-3 - Build for Lua 5.3 only
lua5-4 - Build for Lua 5.4 only
+luajit - Build for LuaJIT only
diff --git a/profiles/desc/lua_targets.desc b/profiles/desc/lua_targets.desc
index 2575de0bcfd..75b9e0f86af 100644
--- a/profiles/desc/lua_targets.desc
+++ b/profiles/desc/lua_targets.desc
@@ -7,3 +7,4 @@ lua5-1 - Build with Lua 5.1
lua5-2 - Build with Lua 5.2
lua5-3 - Build with Lua 5.3
lua5-4 - Build with Lua 5.4
+luajit - Build with LuaJIT
--
2.26.2
[gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua
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. 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.
Re: [gentoo-dev] New acct-user/pgbouncer
> On Mon, 05 Oct 2020, Aaron W Swenson wrote: > On 2020-10-05 10:51, Aaron W. Swenson wrote: >> Currently we're just using -1 for pgbouncer. The user does own a >> couple things, but that's managed by checkpath in the init script. >> >> So, given that any UID will do, I'm proposing either 383 (I think >> someone else is asking for 384) or 463. >> >> Pgbouncer only needs a UID. It uses the postgres GID. >> >> Which UID should we use: 383 or 463? > And, I'm seeing my list was slightly out of date as 383 is now taken. > So, which UID should we use: 379 or 463? Either is fine. The guidelines recommend taking the next free one available which would be 463. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] New acct-user/pgbouncer
On 2020-10-05 10:51, Aaron W. Swenson wrote: > Currently we're just using -1 for pgbouncer. The user does own a couple > things, > but that's managed by checkpath in the init script. > > So, given that any UID will do, I'm proposing either 383 (I think someone > else > is asking for 384) or 463. > > Pgbouncer only needs a UID. It uses the postgres GID. > > Which UID should we use: 383 or 463? And, I'm seeing my list was slightly out of date as 383 is now taken. So, which UID should we use: 379 or 463? signature.asc Description: PGP signature
[gentoo-dev] New acct-user/pgbouncer
Currently we're just using -1 for pgbouncer. The user does own a couple things, but that's managed by checkpath in the init script. So, given that any UID will do, I'm proposing either 383 (I think someone else is asking for 384) or 463. Pgbouncer only needs a UID. It uses the postgres GID. Which UID should we use: 383 or 463? signature.asc Description: PGP signature
