Re: [gentoo-dev] details on the PMS
On Fri, Feb 23, 2018 at 8:48 PM, Michael Lienhardt < michael.lienha...@laposte.net> wrote: > I noticed that the following files are not mentioned, or stated optional > in the PMS: > - profiles/repo_name > - metadata/layout.conf > > It seems to me that without these files, portage complains. Shouldn't them > be declared as mandatory? > > - profiles/package.use and profiles/make.defaults ( > https://wiki.gentoo.org/wiki/USE_ORDER) > These files are not documented in the PMS: should the package manager > recognize these files? (if so, I think it would be clearer to document them > in the PMS) > > Also, in https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-430004.7.1 the > directory is named metadata/cache while it is named metadata/md5-cache in > my repository. > > > Should I report something on the Gentoo Bugzilla? > > Best, > Michael Lienhardt > > repo_name is mentioned in https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-350004.4, "All contents of this directory, with the exception of repo_name, are optional". And with regards to metadata directory, from https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-420004.7, "All contents are optional". I would assume layout.conf is Gentoo Portage specific instead of PMS specific.
Re: [gentoo-dev] details on the PMS
Hi Michael Saturday 24 Feb 2018 02:48:02, Michael Lienhardt wrote : > I noticed that the following files are not mentioned, or stated optional in > the PMS: > - profiles/repo_name > - metadata/layout.conf > > It seems to me that without these files, portage complains. Shouldn't them be > declared as mandatory? > > - profiles/package.use and profiles/make.defaults > (https://wiki.gentoo.org/wiki/USE_ORDER) > These files are not documented in the PMS: should the package manager > recognize these files? (if so, I think it would be clearer to document them > in the PMS) > > Also, in https://dev.gentoo.org/~ulm/pms/head/pms.html#x1-430004.7.1 the > directory is named metadata/cache while it is named metadata/md5-cache in my > repository. > > > Should I report something on the Gentoo Bugzilla? > > Best, > Michael Lienhardt > Please do. If the documentation is lacking for these files, it must be fixed ASAP. Thanks for picking this up! -- Patrice Clement Gentoo Linux developer http://www.gentoo.org
[gentoo-dev] [PATCH 5/5] dev-libs/libpeas: USE=jit -> USE=luajit
Closes: https://bugs.gentoo.org/648188
---
dev-libs/libpeas/libpeas-1.20.0-r1.ebuild | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/dev-libs/libpeas/libpeas-1.20.0-r1.ebuild
b/dev-libs/libpeas/libpeas-1.20.0-r1.ebuild
index 71803c6cb7fe..ead15aa6969b 100644
--- a/dev-libs/libpeas/libpeas-1.20.0-r1.ebuild
+++ b/dev-libs/libpeas/libpeas-1.20.0-r1.ebuild
@@ -14,7 +14,7 @@ LICENSE="LGPL-2+"
SLOT="0"
KEYWORDS="~alpha amd64 ~arm ~arm64 ~ia64 ~ppc ~ppc64 ~sparc x86 ~amd64-fbsd
~amd64-linux ~x86-linux"
-IUSE="+gtk glade jit lua +python"
+IUSE="+gtk glade lua luajit +python"
REQUIRED_USE="python? ( ${PYTHON_REQUIRED_USE} )"
RDEPEND="
@@ -24,8 +24,8 @@ RDEPEND="
gtk? ( >=x11-libs/gtk+-3:3[introspection] )
lua? (
>=dev-lua/lgi-0.9.0
- jit? ( >=dev-lang/luajit-2:2 )
- !jit? ( =dev-lang/lua-5.1*:0 ) )
+ luajit? ( >=dev-lang/luajit-2:2 )
+ !luajit? ( =dev-lang/lua-5.1*:0 ) )
python? (
${PYTHON_DEPS}
>=dev-python/pygobject-3.2:3[${PYTHON_USEDEP}] )
@@ -65,7 +65,7 @@ src_configure() {
# lua
$(use_enable lua lua5.1)
- $(use_enable $(usex jit lua jit) luajit)
+ $(use_enable $(usex luajit lua luajit) luajit)
)
gnome2_src_configure "${myconf[@]}"
--
2.16.2
[gentoo-dev] [PATCH 4/5] net-dns/pdns: [QA] Use standard meaning of USE=luajit
Fix the package to use standard meaning for USE=luajit instead of making
it exclusive with USE=lua.
---
net-dns/pdns/metadata.xml | 1 -
net-dns/pdns/pdns-4.0.5.ebuild | 12 +++-
net-dns/pdns/pdns-4.1.0.ebuild | 12 +++-
net-dns/pdns/pdns-4.1.1.ebuild | 12 +++-
4 files changed, 21 insertions(+), 16 deletions(-)
diff --git a/net-dns/pdns/metadata.xml b/net-dns/pdns/metadata.xml
index 36c754fdabc7..57e0d147b337 100644
--- a/net-dns/pdns/metadata.xml
+++ b/net-dns/pdns/metadata.xml
@@ -12,7 +12,6 @@ standards documents. Furthermore, PowerDNS interfaces with
almost any database.
Make it possible to use the
dev-libs/botan library for crypto-related stuff (like DNSSec) which
can be significantly faster than PolarSSL.
- Enable support for dev-lang/luajit
Making it possible to use a MyDNS MySQL database
with PowerDNS (not recommended for new deployments).
Use a database supported by
dev-db/opendbx as backend.
Enable support for
dev-libs/protobuf.
diff --git a/net-dns/pdns/pdns-4.0.5.ebuild b/net-dns/pdns/pdns-4.0.5.ebuild
index 90ac1b5b3306..bd6f0e93330f 100644
--- a/net-dns/pdns/pdns-4.0.5.ebuild
+++ b/net-dns/pdns/pdns-4.0.5.ebuild
@@ -20,15 +20,17 @@ KEYWORDS="amd64 x86"
IUSE="botan debug doc geoip ldap libressl lua luajit mydns mysql opendbx
postgres protobuf remote sqlite systemd tools tinydns test"
-REQUIRED_USE="mydns? ( mysql ) ?? ( lua luajit )"
+REQUIRED_USE="mydns? ( mysql )"
RDEPEND="
libressl? ( dev-libs/libressl:= )
!libressl? ( dev-libs/openssl:= )
>=dev-libs/boost-1.35:=
botan? ( dev-libs/botan:2= )
- lua? ( dev-lang/lua:= )
- luajit? ( dev-lang/luajit:= )
+ lua? (
+ !luajit? ( dev-lang/lua:= )
+ luajit? ( dev-lang/luajit:= )
+ )
mysql? ( virtual/mysql )
postgres? ( dev-db/postgresql:= )
ldap? ( >=net-nds/openldap-2.0.27-r4 )
@@ -74,8 +76,8 @@ src_configure() {
$(use_enable test unit-tests) \
$(use_enable tools) \
$(use_enable systemd) \
- $(use_with lua) \
- $(use_with luajit) \
+ $(usex lua "$(use_with !luajit lua) $(use_with luajit)" \
+ '--without-lua --without-luajit') \
$(use_with protobuf) \
${myconf}
}
diff --git a/net-dns/pdns/pdns-4.1.0.ebuild b/net-dns/pdns/pdns-4.1.0.ebuild
index 476a969f8a9a..60d5320f505e 100644
--- a/net-dns/pdns/pdns-4.1.0.ebuild
+++ b/net-dns/pdns/pdns-4.1.0.ebuild
@@ -20,15 +20,17 @@ KEYWORDS="~amd64 ~x86"
IUSE="botan debug doc geoip ldap libressl lua luajit mydns mysql opendbx
postgres protobuf remote sodium sqlite systemd tools tinydns test"
-REQUIRED_USE="mydns? ( mysql ) ?? ( lua luajit )"
+REQUIRED_USE="mydns? ( mysql )"
RDEPEND="
libressl? ( dev-libs/libressl:= )
!libressl? ( dev-libs/openssl:= )
>=dev-libs/boost-1.35:=
botan? ( dev-libs/botan:2= )
- lua? ( dev-lang/lua:= )
- luajit? ( dev-lang/luajit:= )
+ lua? (
+ !luajit? ( dev-lang/lua:= )
+ luajit? ( dev-lang/luajit:= )
+ )
mysql? ( virtual/mysql )
postgres? ( dev-db/postgresql:= )
ldap? ( >=net-nds/openldap-2.0.27-r4 app-crypt/mit-krb5 )
@@ -74,8 +76,8 @@ src_configure() {
$(use_enable tools) \
$(use_enable systemd) \
$(use_enable sodium libsodium) \
- $(use_with lua) \
- $(use_with luajit) \
+ $(usex lua "$(use_with !luajit lua) $(use_with luajit)" \
+ '--without-lua --without-luajit') \
$(use_with protobuf) \
${myconf}
}
diff --git a/net-dns/pdns/pdns-4.1.1.ebuild b/net-dns/pdns/pdns-4.1.1.ebuild
index 7ec5508cb26b..1dd30fc18958 100644
--- a/net-dns/pdns/pdns-4.1.1.ebuild
+++ b/net-dns/pdns/pdns-4.1.1.ebuild
@@ -20,15 +20,17 @@ KEYWORDS="~amd64 ~x86"
IUSE="botan debug doc geoip ldap libressl lua luajit mydns mysql opendbx
postgres protobuf remote sodium sqlite systemd tools tinydns test"
-REQUIRED_USE="mydns? ( mysql ) ?? ( lua luajit )"
+REQUIRED_USE="mydns? ( mysql )"
RDEPEND="
libressl? ( dev-libs/libressl:= )
!libressl? ( dev-libs/openssl:= )
>=dev-libs/boost-1.35:=
botan? ( dev-libs/botan:2= )
- lua? ( dev-lang/lua:= )
- luajit? ( dev-lang/luajit:= )
+ lua? (
+ !luajit? ( dev-lang/lua:= )
+ luajit? ( dev-lang/luajit:= )
+ )
mysql? ( virtual/mysql )
postgres? ( dev-db/postgresql:= )
ldap? ( >=net-nds/openldap-2.0.27-r4 app-crypt/mit-krb5 )
@@ -74,8 +76,8 @@ src_configure() {
$(use_enable tools) \
$(use_enable systemd) \
$(use_enable sodium libsodium) \
- $(use_with lua) \
- $(use_with luajit) \
+ $(us
[gentoo-dev] [PATCH 3/5] net-analyzer/suricata: [QA] Use standard meaning of USE=luajit
Fix the package to use standard meaning for USE=luajit instead of making
it exclusive with USE=lua.
---
net-analyzer/suricata/metadata.xml | 1 -
net-analyzer/suricata/suricata-4.0.3.ebuild | 21 +
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/net-analyzer/suricata/metadata.xml
b/net-analyzer/suricata/metadata.xml
index 58878c64f05c..0afee5625d1a 100644
--- a/net-analyzer/suricata/metadata.xml
+++ b/net-analyzer/suricata/metadata.xml
@@ -9,7 +9,6 @@
Enable unix socket
Enable NVIDIA Cuda computations support
Enable detection modules
-Enable Luajit support
Enable libnetfilter_log support
Enable NFQUEUE support for inline IDP
Enable Redis support
diff --git a/net-analyzer/suricata/suricata-4.0.3.ebuild
b/net-analyzer/suricata/suricata-4.0.3.ebuild
index 604eae665be7..e501c9c775b2 100644
--- a/net-analyzer/suricata/suricata-4.0.3.ebuild
+++ b/net-analyzer/suricata/suricata-4.0.3.ebuild
@@ -14,8 +14,6 @@ SLOT="0"
KEYWORDS="~amd64 ~x86"
IUSE="+af-packet control-socket cuda debug +detection geoip hardened logrotate
lua luajit nflog +nfqueue redis +rules test"
-REQUIRED_USE="lua? ( !luajit )"
-
DEPEND="
>=dev-libs/jansson-2.2
dev-libs/libpcre
@@ -29,8 +27,10 @@ DEPEND="
sys-apps/file
cuda? ( dev-util/nvidia-cuda-toolkit )
geoip? ( dev-libs/geoip )
- lua?( dev-lang/lua:* )
- luajit? ( dev-lang/luajit:* )
+ lua? (
+ !luajit? ( dev-lang/lua:* )
+ luajit? ( dev-lang/luajit:* )
+ )
nflog? ( net-libs/libnetfilter_log )
nfqueue?( net-libs/libnetfilter_queue )
redis? ( dev-libs/hiredis )
@@ -87,10 +87,15 @@ src_configure() {
# myeconfargs+=( $(use_enable prelude) )
# fi
if use lua ; then
- myeconfargs+=( $(use_enable lua) )
- fi
- if use luajit ; then
- myeconfargs+=( $(use_enable luajit) )
+ myeconfargs+=(
+ $(use_enable !luajit lua)
+ $(use_enable luajit)
+ )
+ else
+ myeconfargs+=(
+ --disable-lua
+ --disable-luajit
+ )
fi
# this should be used when pf_ring use flag support will be added
--
2.16.2
[gentoo-dev] [PATCH 2/5] */*: Remove redundant local descriptions for USE=luajit
--- app-editors/gvim/metadata.xml | 1 - app-editors/neovim/metadata.xml | 2 -- app-editors/vim/metadata.xml| 1 - app-shells/mpv-bash-completion/metadata.xml | 3 --- dev-db/redis/metadata.xml | 1 - dev-lua/lpeg/metadata.xml | 4 dev-lua/lua-openssl/metadata.xml| 4 dev-lua/luacheck/metadata.xml | 4 dev-lua/luafilesystem/metadata.xml | 3 --- dev-lua/luaossl/metadata.xml| 4 dev-lua/luassert/metadata.xml | 4 dev-lua/messagepack/metadata.xml| 7 +-- dev-lua/mpack/metadata.xml | 4 dev-lua/say/metadata.xml| 4 games-action/minetest/metadata.xml | 4 games-engines/solarus/metadata.xml | 1 - games-roguelike/stone-soup/metadata.xml | 2 -- mail-filter/opensmtpd-extras/metadata.xml | 1 - media-sound/csound/metadata.xml | 1 - media-video/mpv/metadata.xml| 1 - net-dns/dnsdist/metadata.xml| 1 - net-dns/pdns-recursor/metadata.xml | 1 - www-client/luakit/metadata.xml | 4 x11-wm/awesome/metadata.xml | 3 --- 24 files changed, 1 insertion(+), 64 deletions(-) diff --git a/app-editors/gvim/metadata.xml b/app-editors/gvim/metadata.xml index bd2205f57da1..aa4ea747bcc9 100644 --- a/app-editors/gvim/metadata.xml +++ b/app-editors/gvim/metadata.xml @@ -7,7 +7,6 @@ Enable GTK+3 interface -Use dev-lang/luajit instead of dev-lang/lua Include netbeans external editor integration support Enable support for Scheme using dev-scheme/racket diff --git a/app-editors/neovim/metadata.xml b/app-editors/neovim/metadata.xml index 158212f33e00..57f11481bec1 100644 --- a/app-editors/neovim/metadata.xml +++ b/app-editors/neovim/metadata.xml @@ -11,8 +11,6 @@ Use dev-libs/jemalloc for allocations Enable support for remote options using nvr Build the neovim unix tui -Use dev-lang/luajit instead of - dev-lang/lua neovim/neovim diff --git a/app-editors/vim/metadata.xml b/app-editors/vim/metadata.xml index fb8e0f11fb37..f65afcd7454c 100644 --- a/app-editors/vim/metadata.xml +++ b/app-editors/vim/metadata.xml @@ -6,7 +6,6 @@ Gentoo Vim Project -Use dev-lang/luajit instead of dev-lang/lua Enable support for Scheme using dev-scheme/racket Enable terminal emulation support Install vimpager and vimmanpager links diff --git a/app-shells/mpv-bash-completion/metadata.xml b/app-shells/mpv-bash-completion/metadata.xml index 9c81b8770e4c..1d75e0fd49a8 100644 --- a/app-shells/mpv-bash-completion/metadata.xml +++ b/app-shells/mpv-bash-completion/metadata.xml @@ -9,9 +9,6 @@ proxy-ma...@gentoo.org Proxy Maintainers - - Use dev-lang/luajit instead of dev-lang/lua - https://github.com/2ion/mpv-bash-completion/releases 2ion/mpv-bash-completion diff --git a/dev-db/redis/metadata.xml b/dev-db/redis/metadata.xml index 872bd8ba741e..19c095efc2a0 100644 --- a/dev-db/redis/metadata.xml +++ b/dev-db/redis/metadata.xml @@ -14,6 +14,5 @@ Use tcmalloc from dev-util/google-perftools for allocations. -Use dev-lang/luajit instead of dev-lang/lua diff --git a/dev-lua/lpeg/metadata.xml b/dev-lua/lpeg/metadata.xml index 8bc501c65d7d..fb7b91969e10 100644 --- a/dev-lua/lpeg/metadata.xml +++ b/dev-lua/lpeg/metadata.xml @@ -13,8 +13,4 @@ llui...@gmail.com Aric Belsito - -Use dev-lang/luajit instead of - dev-lang/lua - diff --git a/dev-lua/lua-openssl/metadata.xml b/dev-lua/lua-openssl/metadata.xml index 8d55d018568a..f4da03ad0c56 100644 --- a/dev-lua/lua-openssl/metadata.xml +++ b/dev-lua/lua-openssl/metadata.xml @@ -9,10 +9,6 @@ proxy-ma...@gentoo.org Proxy Maintainers - - Use dev-lang/luajit instead of - dev-lang/lua - zhaozg/lua-openssl diff --git a/dev-lua/luacheck/metadata.xml b/dev-lua/luacheck/metadata.xml index b79aded448ba..76ed9960fb57 100644 --- a/dev-lua/luacheck/metadata.xml +++ b/dev-lua/luacheck/metadata.xml @@ -9,8 +9,4 @@ proxy-ma...@gentoo.org Proxy Maintainers - - Use dev-lang/luajit instead of - dev-lang/lua - diff --git a/dev-lua/luafilesystem/metadata.xml b/dev-lua/luafilesystem/metadata.xml index fb533186d653..59f1123dc93b 100644 --- a/dev-lua/luafilesystem/metadata.xml +++ b/dev-lua/luafilesystem/metadata.xml @@ -11,7 +11,4 @@ LuaFileSystem offers a portable way to access the underlying directory structure and file attributes. - - Use dev-lang/luajit instead
[gentoo-dev] [PATCH 1/5] use.desc: Introduce 'luajit' as a global flag
'luajit' is used consistently in 25+ packages. Make it a global flag. --- profiles/use.desc | 1 + 1 file changed, 1 insertion(+) diff --git a/profiles/use.desc b/profiles/use.desc index 5cdf9808d2b6..5bf9a1d7f693 100644 --- a/profiles/use.desc +++ b/profiles/use.desc @@ -186,6 +186,7 @@ lirc - Add support for lirc (Linux's Infra-Red Remote Control) livecd - !!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used during livecd building lm_sensors - Add linux lm_sensors (hardware sensors) support lua - Enable Lua scripting support +luajit - Use dev-lang/luajit instead of dev-lang/lua (ineffective with USE=-lua) lzma - Support for LZMA (de)compression algorithm lzo - Enable support for lzo compression m17n-lib - Enable m17n-lib support -- 2.16.2
Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels
W dniu nie, 25.02.2018 o godzinie 19∶31 +0900, użytkownik Benda Xu napisał: > Hi Michał, > > Michał Górny writes: > > > I don't think this is the first old version Prefix team needs keeping. > > Another example are old versions of LLVM. > > I am sure you are aware that Prefix has two variants: one is > prefix-rpath targeting MacOS, Solaris, AIX, Cygwin, Interix and a subset > of GNU/Linux; the other is prefix-standalone, targeting GNU/Linux and > Android/Linux.[1] > > For LLVM example, it is prefix-rpath, which hosts its own overlay at > repo/proj/prefix.git. Besides LLVM there are other hacks at present in > the overlay. But we still keep the ultimate goal of merging prefix.git > into gentoo.git. I am also keeping old versions of LLVM for Prefix team. That's why I'd really prefer to get rid of them and have them in some common overlay that all Prefix users can use. > What we are discussing in this thread, however, is prefix-standalone, it > uses the official gentoo repository without any overlay. It works > perfectly for kernel-2.6.26+ and linux-3.2+. So, creating an overlay of > 2 ebuilds for prefix-standalone is an overkill. Maybe it is. But isn't making maintenance of Gentoo packages more complexity for Prefix an overkill? We are effectively switching from trivial model of 'assign bug with X to maintainer' to checking which maintainer applies to which version of X. > > Yours, > Benda > > 1. https://wiki.gentoo.org/wiki/Project:Prefix -- Best regards, Michał Górny
Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels
Am Sonntag, 25. Februar 2018, 07:17:47 CET schrieb Benda Xu: > Hi all, > > Yes, it's 2018. But there are still RHEL 4 and 5 systems running > antique kernels such as 2.6.8 and 2.6.18. In my experience, many of > them are data acquisition hubs or computing clusters. No administrator > cares about security as long as they "work". > > Under the form "Prefix", Gentoo is set out to rescue users trapped in > these abandoned wastelands of antiques. After years of work, we have > achieved that goal, except one minor thing: glibc periodically drop > support for old linux kernels, the lastest glibc supporting linux 2.6.8 > is 2.16 and for linux-2.6.18 it is glibc-2.19. > > With the recent reunion of the Toolchain Project, old glibc versions are > masked and removed, accelerating the adoption of new versions. This > opens a new oppotunity for the Prefix: people stops caring about > unsupported glibc versions, the Prefix Project can take them over > without worrying about breaking other peoples' machines. Well, in principle the idea is OK. We already/still keep some old glibc, gcc, and binutils versions for that reason. However, I have a few conditions. * Only masked. Only prefix keywords. If you really must unmask them in a specific prefix profile, you must provide big fat warnings about the resulting security risks. (I dont know how things went in prehistoric times, but recently there have been a LOT of glibc-related CVEs. Many fixes can be backported, but definitely not all of them.) * No toolchain-glibc.eclass or eblits or similar abominations. Standard QA rules apply. * Try to stick to a minimum of required features (and a minimum of required versions). We want to strongly avoid adding conditionals to other packages. [#] * Please use our gentoo glibc repo to keep track of branches and patchsets. Happy to show you the details sometime soon. [#] If not for such "old version" considerations, we could soon move the libtirpc headers to the place where the glibc headers used to live. That could save us a ...load of patching and bugfixing. By keeping flexibility and compatibility, that is unfortunately not possible. -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, toolchain, perl, libreoffice, comrel) signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels
On Mon, Feb 26, 2018 at 12:22 PM, William Hubbs wrote: > On Sun, Feb 25, 2018 at 10:10:26AM +0100, Michał Górny wrote: > > W dniu nie, 25.02.2018 o godzinie 15∶17 +0900, użytkownik Benda Xu > > napisał: > > > Hi all, > > > > > > Yes, it's 2018. But there are still RHEL 4 and 5 systems running > > > antique kernels such as 2.6.8 and 2.6.18. In my experience, many of > > > them are data acquisition hubs or computing clusters. No administrator > > > cares about security as long as they "work". > > > > > > Under the form "Prefix", Gentoo is set out to rescue users trapped in > > > these abandoned wastelands of antiques. After years of work, we have > > > achieved that goal, except one minor thing: glibc periodically drop > > > support for old linux kernels, the lastest glibc supporting linux 2.6.8 > > > is 2.16 and for linux-2.6.18 it is glibc-2.19. > > > > > > With the recent reunion of the Toolchain Project, old glibc versions > are > > > masked and removed, accelerating the adoption of new versions. This > > > opens a new oppotunity for the Prefix: people stops caring about > > > unsupported glibc versions, the Prefix Project can take them over > > > without worrying about breaking other peoples' machines. > > > > > > Now, profiles/default/linux/amd64/17.0/no-multilib/prefix/ > kernel-2.6.16+ > > > unmasks > > /lib/gentoo/functions.sh transition. prefix/kernel-2.6+ with > glibc-2.16 > > > is also planned. In addition, glibc have to be patched to get python3 > > > built[1-3], which is urgent once portage drops python2[4]. > > > > > > > > > So I would like to hear what you guys think if I: > > > > > > - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the > > > selected Prefix profiles; > > > > > > - maintain those selected outdated glibc versions on the > > > infrastructure of the Toolchain Project[5]; > > > > > > - (optional) add an exception to the toolchain support policy[6]. > > > > > > How about moving them to an overlay? > > I am with mgorny on this, this sort of specialized support does not > belong in the main tree. So I actually originally thought this as well and settled on some logic that is: The problem we are trying to solve is supporting very old distros. This has two impacts on the tree: a) Very old versions of some packages stay in the tree because they are needed to support these old platforms. b) Very old versions of some packages will need to drop keywords for 'rolling' platforms. E.g. I'd expect glibc-really-old to be keyworded only for 'prefix' but not for 'x86' or 'amd64'. This is because the latter two are not well tested[1] A and B are both mostly about control and maintenance of the tree itself (these do not necessarily reflect the quality or stability of prefix as a platform.) The separate problem is: Given some prefix users are running prefix on these old platforms, how do we detect when support for them breaks (as it did for py3, and will again in the future when something else critical breaks.) I'm curious to hear more about this process, but I think its orthogonal to in-tree or in-overlay support; other than the overlay gives you more control over when to release / withdraw various package versions (more control than just keywords do in the main tree.) Note that Gentoo itself purports to offer only 1 year of support for the main tree; so just based on that axiom alone I think trying to support 10+ year old platforms goes against what the main-tree is targeting. -A > The kernel versions you are talking about aren't even supported by the > upstream kernel folks any more -- the oldest lts version is 3.2.99. > > Thanks, > > William > >
Re: [gentoo-dev] glibc 2.16/19 for Gentoo Prefix on antique kernels
On Sun, Feb 25, 2018 at 10:10:26AM +0100, Michał Górny wrote: > W dniu nie, 25.02.2018 o godzinie 15∶17 +0900, użytkownik Benda Xu > napisał: > > Hi all, > > > > Yes, it's 2018. But there are still RHEL 4 and 5 systems running > > antique kernels such as 2.6.8 and 2.6.18. In my experience, many of > > them are data acquisition hubs or computing clusters. No administrator > > cares about security as long as they "work". > > > > Under the form "Prefix", Gentoo is set out to rescue users trapped in > > these abandoned wastelands of antiques. After years of work, we have > > achieved that goal, except one minor thing: glibc periodically drop > > support for old linux kernels, the lastest glibc supporting linux 2.6.8 > > is 2.16 and for linux-2.6.18 it is glibc-2.19. > > > > With the recent reunion of the Toolchain Project, old glibc versions are > > masked and removed, accelerating the adoption of new versions. This > > opens a new oppotunity for the Prefix: people stops caring about > > unsupported glibc versions, the Prefix Project can take them over > > without worrying about breaking other peoples' machines. > > > > Now, profiles/default/linux/amd64/17.0/no-multilib/prefix/kernel-2.6.16+ > > unmasks > /lib/gentoo/functions.sh transition. prefix/kernel-2.6+ with glibc-2.16 > > is also planned. In addition, glibc have to be patched to get python3 > > built[1-3], which is urgent once portage drops python2[4]. > > > > > > So I would like to hear what you guys think if I: > > > > - keep glibc-2.19 and glibc-2.16 in tree and unmasking them in the > > selected Prefix profiles; > > > > - maintain those selected outdated glibc versions on the > > infrastructure of the Toolchain Project[5]; > > > > - (optional) add an exception to the toolchain support policy[6]. > > > How about moving them to an overlay? I am with mgorny on this, this sort of specialized support does not belong in the main tree. The kernel versions you are talking about aren't even supported by the upstream kernel folks any more -- the oldest lts version is 3.2.99. Thanks, William signature.asc Description: Digital signature
