[gentoo-dev] Stabilisation of the slotted-Lua ecosystem
Ladies and germs, The time has come for the final big push towards widespread deployment on slotted Lua - this monstrosity: https://bugs.gentoo.org/766528 . Many thanks in advance to all the arch testers who will deal with this. Nb. I am happy with this bug being split into several if that makes the tests easier to manage for those who will run them, just keep in mind that the stabilisation commits for an arch should be pushed to the repo over as short a time span as possible - the more spread this is the more annoyed our users might get by the dependency conflicts between slotted and unslotted and dev-lang/lua. -- Marecki
Re: [gentoo-dev] Packages up for grabs
On 17/01/2021 09:26, Michał Górny wrote: [bv] x11-plugins/vicious [B ] x11-wm/awesome I'll take these two. -- MS
Re: [gentoo-dev] [News review] LibreSSL support discontinued
On January 4, 2021 8:25:21 AM UTC, Stefan Strogin wrote: >Doesn't work for me. Have you got libressl in your world file, perchance? -- Marecki
Re: [gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
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, all get installed directly to $libdir.. >but with NON-standard names like liblua5.2.a (as opposed to simply >liblua.a). > >This makes it impossible to build against a specific version of Lua >without using pkg-config. The usual way would be to add >/usr/include/lua5.2 to the compiler's include path, and $libdir/lua5.2 >to its library path (via -I and -L)... but there's no way to tell the >build system to look for a library of an entirely different name. >Things >like AC_SEARCH_LIBS are going to try -llua, and that's it. 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. -- MS
[gentoo-dev] Slotted Lua + revdeps to be unmasked on Christmas Eve
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 ebuild needs one extra fix sci-geosciences/osm2pgsql - no response from maintainers (sci-geo@g.o) www-apps/cgit - to be migrated by bman Therefore, the unmasking of slotted Lua + all the ebuilds migrated to Lua eclasses will take place on Christmas Eve, i.e. this Thursday, around noon UTC. -- Marecki
[gentoo-dev] [PATCH] waf-utils.eclass: support EAPI-7
Trivial bump. Tested with a modified media-video/mpv ebuild (which package
requires this change before it can be migrated to Lua eclasses), seems to work
fine.
--- a/eclass/waf-utils.eclass
+++ b/eclass/waf-utils.eclass
@@ -8,7 +8,7 @@
# Original Author: Gilles Dartiguelongue
# Various improvements based on cmake-utils.eclass: Tomáš Chvátal
# Proper prefix support: Jonathan Callen
-# @SUPPORTED_EAPIS: 4 5 6
+# @SUPPORTED_EAPIS: 4 5 6 7
# @BLURB: common ebuild functions for waf-based packages
# @DESCRIPTION:
# The waf-utils eclass contains functions that make creating ebuild for
@@ -19,7 +19,7 @@
inherit multilib toolchain-funcs multiprocessing
case ${EAPI:-0} in
- 4|5|6) EXPORT_FUNCTIONS src_configure src_compile src_install ;;
+ 4|5|6|7) EXPORT_FUNCTIONS src_configure src_compile src_install ;;
*) die "EAPI=${EAPI} is not supported" ;;
esac
--
Marecki
Re: [gentoo-dev] Slotted Lua: 2020-12-04 status update
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 about requiring everyone to use Portage but Lua eclasses *are* indeed strongly based on Python ones - as openly admitted both in eclassdoc of the three Lua eclasses and during their public review on this mailing list. -- MS OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Slotted Lua: 2020-12-04 status update
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 is a dangling symlink I've already mentioned this to WilliamH, it is expected to be done before the unmasking of slotted Lua. Meanwhile (i.e. during work on migrating packages so that they among other things respect the current values of LUA_TARGETS and LUA_SINGLE_TARGET), not having any "current" Lua versions makes it easier to catch looking for Lua where they shouldn't. Related to the above: is there a way to trigger rebuilds of consumers when the "single implementation" changes? If I have a package that links against liblua and if I upgrade from lua-5.1 to lua-5.2, then my package should rebuild. I don't think $LUA_DEPS from lua-single.eclass can do that? 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. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Slotted Lua: 2020-12-04 status update
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-20201207135752.txt -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Python 2 cleanup: remaining packages, Dec 2020 update
On December 5, 2020 12:31:33 PM UTC, Andrew Savchenko wrote: >Looks like you misunderstood what "Python 3 compatibility mode" >means. See official explanation: >https://www.renpy.org/dev-doc/html/changelog.html#python-2-python-3-compatibility-mode So I have. Oh well, last rites it most likely is then. Or move py2 versions of RenPy and their revdeps to a dedicated overlay, maybe. I am not quite convinced simply having then masked in the main tree makes sense, as these will have to stay masked even after RenPy 8.0 has come out. -- MS
[gentoo-dev] Slotted Lua: 2020-12-04 status update
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 to the fact they or their Lua support had been masked to begin with - but I am happy to say that most of them have indeed been migrated to Lua eclasses. This includes most (if not all) multi-impl packages. Many thanks to everyone who has helped with this effort, with particular to ConiKost for his *massive* offensive against multi-impl packages populating the category dev-lua. At this point I would like to strongly encourage everyone who has got any open "please migrate to Lua eclasses" tickets assigned to make an effort to address them within the next couple of weeks. These should (almost?) all be single-impl by now and therefore quite straightforward to migrate, and should you need inspiration we have by now got a lot successful migrations to lua-single in three tree covering a wide range of build systems. Last but not least, you can always ask for advice via IRC in #gentoo-lua. On a related note, please make sure that any and all unmigrated ebuilds of your packages depending on dev-lang/lua explicitly request slot 0 of that package. This will help spare our users some nasty conflicts once slotted Lua has been unmasked. At this point I strongly feel the end of migration to slotted Lua is very much in sight. Let's do this! -- Marecki
Re: [gentoo-dev] Python 2 cleanup: remaining packages, Dec 2020 update
On 2020-12-04 01:54, Michał Górny wrote: Waiting for py3 port (likely last rite candidates): - games-engines/renpy RenPy 7.4.0, released on the 26th of November, features "new Python 3 compatibility mode". It is of course up to the maintainer of this package to decide how to proceed but were this up to me, I would very much rather version-bump games-engines/renpy (in spite of 7.4.0 being described by upstream as a pre-release) than last-rite it altogether. Sure but I'm afraid the games will need explicit porting to py3 as well. Well, the games will probably have to go - if I see correctly we have currently got 4 games-engines/renpy revdeps in the tree (games-misc/katawa-shoujo, games-rpg/asphyxia, games-rpg/sakura-spirit, games-rpg/the-royal-trap) and they all explicitly depend on a slotted older version of the engine. -- MS OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Slotted Lua: eclass migration status
On 2020-11-28 20:09, Marek Szuba wrote: While the migration of some of depends on various Lua modules which have not themselves been migrated (from a glance at the dependency tree, it seems dev-lua/lpeg and dev-lua/LuaBitOp are the ones we need the most urgently), the vast majority of these packages depend on dev-lang/lua only i.e. could already be migrated. Update: thanks to the valiant efforts of ConiKost and the others over the weekend, the dependency tree of the tracker bug is now flat. No migrations remain blocked by other unmigrated packages. -- MS OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Dissolving project desktop-misc
On 2020-11-29 16:48, Andreas K. Hüttel wrote: app-text/xchm x11-misc/cbatticon x11-misc/fracplanet x11-misc/hsetroot > x11-misc/read-edid > x11-misc/xdotool > x11-misc/xnots I'll take these. x11-misc/i3lock Will add myself as the second maintainer if Jakov is okay with it. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Python 2 cleanup: remaining packages, Dec 2020 update
On 2020-11-28 22:47, Michał Górny wrote: Waiting for py3 port (likely last rite candidates): - games-engines/renpy RenPy 7.4.0, released on the 26th of November, features "new Python 3 compatibility mode". It is of course up to the maintainer of this package to decide how to proceed but were this up to me, I would very much rather version-bump games-engines/renpy (in spite of 7.4.0 being described by upstream as a pre-release) than last-rite it altogether. -- Marecki OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Slotted Lua: eclass migration status
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 much appreciated!
On the less positive side, the slotted-Lua tracker bug [1] has still got
119 open "migrate to lua eclasses" tickets attached to it. You can find
the complete list at [2]. While the migration of some of depends on
various Lua modules which have not themselves been migrated (from a
glance at the dependency tree, it seems dev-lua/lpeg and
dev-lua/LuaBitOp are the ones we need the most urgently), the vast
majority of these packages depend on dev-lang/lua only i.e. could
already be migrated.
[1] https://bugs.gentoo.org/657722
[2] https://dev.gentoo.org/~marecki/open_lua_eclass_bugs-20201128184637.txt
--
MS
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-lua/luadoc
# Marek Szuba (2020-11-24) # No releases since 2008, deprecated upstream in favour of dev-lua/ldoc, # unmaintained, no revdeps. Removal in 30 days (Bug #756343). dev-lua/luadoc -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: app-backup/burp + account/group
Dear everyone, Owing to the fact I decommissioned the last bit of my Burp-based backup infrastructure last week, the following packages: acct-group/burp acct-user/burp app-backup/burp are now up for grabs. I have just dropped all three to m-n. Burp releases are divided into two categories, stable (currently the 2.2 branch) and development (currently 2.3). The former is generally quiet, the latter sees a new release every month or so. Upstream is friendly and quick to respond. There currently one open bug, for two test failures in the development version 2.3.36 [1]. This particular one seems to me to be related to tinderbox configuration, as I continue to be unable to reproduce it in spite of having tried running the burp test suite with PORTAGE_TMPDIR on several different file systems (specifically: btrfs, ext4, tmpfs). That said, I have observed recent development builds to produce intermittent test timeouts. [1] https://bugs.gentoo.org/753967 -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On 2020-11-08 23:17, Kent Fredric wrote: If you strike an issue that you think should be followed upstream, rope me in. (put me on the bottom of the maintainer list if you want) I'm not interested in maintaining it directly, but I use it, and do have workable rapport with upstream :) I'll keep that in mind, thank you! I won't add you to the maintainer list because it would pretty much guarantee you getting Cc'd on all bugs. -- MS OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 0/1] depend.apache.eclass: support EAPI-7
On 2020-11-03 20:04, Michael Orlitzky wrote: It's likely broken in EAPI=7, because it was in EAPI=6: https://bugs.gentoo.org/616612 I left a comment there with a proposal for how to fix it, but I haven't thought about it much since then. Indeed, by default this is broken - but in exactly the same way as with EAPI-6, and at least the main issue mentioned in this bug can be addressed by the same workaround. In the long run it would IMHO very much make sense to retire this eclass, looks like it will still take a while though... I might have a look at it but only once I've got Lua and NodeJS taken care of. In the meantime, patch merged. -- MS OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] A feedback about the CI bug reporting system
On 2020-11-07 12:30, Agostino Sarubbo wrote: What looks strange is that ci/tinderbox opened ~4700 bugs, sure, there are invalid/duplicate bugs but the majority are fixed so in my opinion they were useful, but looking at the mailing list feedback looks to be a completely crap. I think this might be the case of a "silent majority, vocal minority" scenario. For the record: I for one have found your tinderbox bugs very useful, not in the least because you test unusual configurations my own build testing does not cover. There have been glitches - but IMHO very few of them, and human operators make mistakes too. I still very much wish your tickets were tagged in a way which would make it possible to separate failures from QA notices (especially those that show up during normal emerge runs, such as that suspected DISTUTILS_USE_SETUPTOOLS mismatches), though. I really do not need e-mail notifications about the latter, looking them up via my p.g.o page is quite sufficient. -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Deprecating AMD64 17.0 profiles?
On 2020-11-09 12:09, Jaco Kroon wrote: equery has some answers that there are still stuff installed into /usr/lib32 (which will likely clear over time, and the symlink will be unmerged). There is this one potential pitfall down the line that I'm seeing, fairly certain this would have been covered and that a remerge of glibc will fix this: As a matter of fact the complete migration procedure (including cleaning up lib32 symlinks) was described in the news items introducing 17.1, for instance "2019-06-05-amd64-17-1-profiles-are-now-stable". In short, run emerge -1v --deep /lib32 /usr/lib32 /usr/lib/llvm/*/lib32 and the lib32 symlinks should go. -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Re: Slotted Lua: let's get this done!
On 2020-11-03 16:43, Marek Szuba wrote: I'll likely start opening please-migrate tickets for them on Friday, i.e. once my latest proposed change set to the eclasses (which will likely be needed by e.g. x11-wm/awesome) has been merged. Sorry about the delay, ended up almost entirely offline for the second half of October. All tickets have been opened. FYI, the slotted-lua tracker bug (https://bugs.gentoo.org/657722) now links to all the recently created "please migrate" tickets. Moreover, I have created and linked tickets for previously updated packages so that it is easier for everyone concerned to find examples of successful (I hope!) migrations. -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] Packages & projects up for grabs due to jer's retirement
On 2020-11-03 22:32, Michał Górny wrote: app-text/pinfo I'll take this one. net-misc/chrony I do use some of the fancy features of chrony so I would be interested in taking it, that said with both sam and chewi being interested to some degree I'll discuss this with them first. net-misc/youtube-dl Willing to co-maintain with mgorny and/or polynomial-c. x11-terms/rxvt-unicode Will co-maintain this one with conikost, don't mind being listed as primary maintainer. > net-libs/nodejs Would be willing to maintain it but only with a co-maintainer. -- MS OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH] depend.apache.eclass: support EAPI-7
Signed-off-by: Marek Szuba
---
eclass/depend.apache.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/depend.apache.eclass b/eclass/depend.apache.eclass
index 79bfdcc493f..5aa55254268 100644
--- a/eclass/depend.apache.eclass
+++ b/eclass/depend.apache.eclass
@@ -1,10 +1,10 @@
-# Copyright 1999-2012 Gentoo Foundation
+# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
# @ECLASS: depend.apache.eclass
# @MAINTAINER:
# apache-d...@gentoo.org
-# @SUPPORTED_EAPIS: 0 2 3 4 5 6
+# @SUPPORTED_EAPIS: 0 2 3 4 5 6 7
# @BLURB: Functions to allow ebuilds to depend on apache
# @DESCRIPTION:
# This eclass handles depending on apache in a sane way and provides
information
@@ -44,7 +44,7 @@ case ${EAPI:-0} in
0|2|3|4|5)
inherit multilib
;;
- 6)
+ 6|7)
;;
*)
die "EAPI=${EAPI} is not supported by depend.apache.eclass"
--
2.26.2
[gentoo-dev] [PATCH 0/1] depend.apache.eclass: support EAPI-7
The fact this eclass does not support EAPI-7 yet blocks migration of www-apache/mod_security to Lua eclasses. Seems simple enough to address though, likely simpler than adding EAPI-6 support to lua.eclass.
[gentoo-dev] Re: Slotted Lua: let's get this done!
On 2020-10-14 17:29, Marek Szuba wrote: I'll likely start opening please-migrate tickets for them on Friday, i.e. once my latest proposed change set to the eclasses (which will likely be needed by e.g. x11-wm/awesome) has been merged. Sorry about the delay, ended up almost entirely offline for the second half of October. All tickets have been opened. -- MS OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] Packages up for grabs: dev-libs/intel-neo and dependencies
I haven't got any Intel APUs available to test this any more, and with upstream pushing towards a move to LLVM-11, being able to conduct runtime testing will likely be important. Therefore, effective immediately I no longer maintain: dev-libs/intel-neo dev-libs/level-zero dev-libs/opencl-clang dev-libs/vc-intrinsics [1] dev-util/intel-graphics-compiler dev-util/spirv-llvm-translator media-libs/gmmlib [2] [1] currently unused because intel-graphics-compiler upstream hasn't it made it possible to build against a non-bundled version yet [2] still has got one maintainer (media-video) but with newer versions of NEO frequently depending on new gmmlib features, it will IMHO make sense for the NEO maintainer to co-maintain this library as well No open bugs. Intel upstream (i.e. all but SPIRV-LLVM-Translator) is generally friendly but their response time varies a lot, plus while they do officially support building against system-wide dependencies their own testing focuses primarily on bundling everything together so the distro approach doesn't always work (case in point: VectorCompiler support in recent versions of intel-graphics-compiler, which I have so far only been able to build without errors while using locally available LLVM sources). SPIRV-LLVM-Translator mostly seems to pretend they are not there so chances are you will have to package release snapshots (separately for different LLVM major versions) in order for recent versions of NEO to work; this is why the current stable version in Gentoo is so behind upstream releases. -- Marecki OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
[gentoo-dev] [PATCH 3/3] profiles/base/make.defaults: set default Lua targets
These are currently both set to lua5-1 only because that is the version
we have got in slot 0 of dev-lang/lua.
Signed-off-by: Marek Szuba
---
profiles/base/make.defaults | 5 +
1 file changed, 5 insertions(+)
diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults
index f0432935720..4dcbeb8f33a 100644
--- a/profiles/base/make.defaults
+++ b/profiles/base/make.defaults
@@ -172,3 +172,8 @@ PHP_TARGETS="php7-2 php7-3 php7-4"
#
# Default ADA target
ADA_TARGET="gnat_2018"
+
+# Marek Szuba (2020-10-15)
+# Default targets for lua{,-single}.eclass
+LUA_SINGLE_TARGET="lua5-1"
+LUA_TARGETS="lua5-1"
--
2.26.2
[gentoo-dev] [PATCH 1/3] profiles/base/make.defaults: add Lua-target variables to USE_EXPAND
Signed-off-by: Marek Szuba --- profiles/base/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/profiles/base/make.defaults b/profiles/base/make.defaults index f2b15dd9a7e..f0432935720 100644 --- a/profiles/base/make.defaults +++ b/profiles/base/make.defaults @@ -13,7 +13,7 @@ USE_EXPAND_VALUES_USERLAND="BSD GNU" # Env vars to expand into USE vars. Modifying this requires prior # discussion on gentoo-dev@lists.gentoo.org. -USE_EXPAND="ABI_MIPS ABI_PPC ABI_RISCV ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC ENLIGHTENMENT_MODULES FFTOOLS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS LIRC_DEVICES LLVM_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS" +USE_EXPAND="ABI_MIPS ABI_PPC ABI_RISCV ABI_S390 ABI_X86 ADA_TARGET ALSA_CARDS APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_ARM CPU_FLAGS_PPC CPU_FLAGS_X86 CURL_SSL ELIBC ENLIGHTENMENT_MODULES FFTOOLS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS LIRC_DEVICES LLVM_TARGETS LUA_SINGLE_TARGET LUA_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS" # USE_EXPAND variables whose contents are not shown in package manager # output. Changes need discussion on gentoo-dev. -- 2.26.2
[gentoo-dev] [PATCH 2/3] profiles/embedded/make.defaults: add Lua-target variables to USE_EXPAND
Signed-off-by: Marek Szuba --- profiles/embedded/make.defaults | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/profiles/embedded/make.defaults b/profiles/embedded/make.defaults index 97be65cd4cb..d5337bc35a2 100644 --- a/profiles/embedded/make.defaults +++ b/profiles/embedded/make.defaults @@ -30,7 +30,7 @@ USE_EXPAND_VALUES_USERLAND="BSD GNU" # Env vars to expand into USE vars. Modifying this requires prior # discussion on gentoo-dev@lists.gentoo.org. -USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_ARM CPU_FLAGS_X86 CURL_SSL ELIBC ENLIGHTENMENT_MODULES FFTOOLS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS LIRC_DEVICES LLVM_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS" +USE_EXPAND="ABI_MIPS ABI_PPC ABI_S390 ABI_X86 ALSA_CARDS APACHE2_MODULES APACHE2_MPMS CALLIGRA_FEATURES CAMERAS COLLECTD_PLUGINS CPU_FLAGS_ARM CPU_FLAGS_X86 CURL_SSL ELIBC ENLIGHTENMENT_MODULES FFTOOLS GPSD_PROTOCOLS GRUB_PLATFORMS INPUT_DEVICES KERNEL L10N LCD_DEVICES LIBREOFFICE_EXTENSIONS LIRC_DEVICES LLVM_TARGETS LUA_SINGLE_TARGET LUA_TARGETS MONKEYD_PLUGINS NGINX_MODULES_HTTP NGINX_MODULES_MAIL NGINX_MODULES_STREAM OFED_DRIVERS OFFICE_IMPLEMENTATION OPENMPI_FABRICS OPENMPI_OFED_FEATURES OPENMPI_RM PHP_TARGETS POSTGRES_TARGETS PYTHON_SINGLE_TARGET PYTHON_TARGETS QEMU_SOFTMMU_TARGETS QEMU_USER_TARGETS ROS_MESSAGES RUBY_TARGETS SANE_BACKENDS USERLAND UWSGI_PLUGINS VIDEO_CARDS VOICEMAIL_STORAGE XFCE_PLUGINS XTABLES_ADDONS" # USE_EXPAND variables whose contents are not shown in package manager # output. Changes need discussion on gentoo-dev. -- 2.26.2
[gentoo-dev] [PATCH 0/3] Set default LUA_TARGETS and LUA_SINGLE_TARGET
Should be harmless to do this already, these flags have only got an
effect on ebuilds inheriting lua{,-single}.eclass i.e. will not do
anything to legacy ones.
Re: [gentoo-dev] [PATCH 0/3] lua-utils.eclass: expose header and library locations
On 2020-10-12 16:05, Marek Szuba wrote:
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.
Merged in lua_get_include_dir() and lua_get_shared_lib(), dropped
lua_get_static_lib().
--
MS
OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] Slotted Lua: let's get this done!
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-single.eclass (those that simply link against liblua or are
otherwise bound to a single implementation)! We are, if I say so myself
as the author of these eclasses, finally REALLY close now to unleashing
slotted Lua on the general public and if we make that final push, we
might finally put this long-overdue matter to rest.
Details
In addition to my packages, I have just migrated all but one [1] m-n
packages currently in the tree which depend on dev-lang/lua, to the new
eclasses. This has turned out to be much easier than I anticipated - in
quite a few number of single-impl cases it Just Worked (TM), multi-impl
requires a bit more typing but in general has worked easily too, and
even for packages using CMake it was usually the simple matter of
patching the build scripts to look for Lua as
find_package(Lua ${LUA_VERSION} EXACT REQUIRED)
and setting LUA_VERSION=$(ver_cut 1-2 $(lua_get_version)) in
src_configure. For anyone who prefers to learn by example, you can look
at e.g.:
=www-servers/lighttpd-1.4.55-r100 - single-impl, autoconf-based, Lua
support controlled by USE=lua, requires an explicit call to
lua-single_pkg_setup due to having defined its own pkg_setup;
=media-gfx/darktable-3.2.1-r1 - single-impl, cmake-based but no patching
required because it is locked by upstream to Lua5.3, Lua support
controlled USE=lua, slotted Lua pulled in by USE=system-lua;
=net-analyzer/suricata-6.0.0-r100 - single-impl, autoconf-based, Lua
support controlled by USE=lua, explicitly supports LuaJIT (i.e. there is
an upstream configure option distinguishing that from PUC Lua), has been
migrated from USE=luajit to LUA_SINGLE_TARGET=luajit;
=dev-lua/messagepack/messagepack-0.3.2-r100 - multi-impl, no build
system (it's a pure-Lua module), installs a different version for lua5-3
than for other implementations
Anyway, this leaves us with about [2] 120 packages depending directly on
dev-lang/lua (23 of them in dev-lua so likely multi-implementation
candidates, the rest most likely single-impl) and just under 30 ones
depending on something from the category dev-lua (which do include 6
lacking maintainers, which I'll migrate once their dependencies have
been taken care of). I'll likely start opening please-migrate tickets
for them on Friday, i.e. once my latest proposed change set to the
eclasses (which will likely be needed by e.g. x11-wm/awesome) has been
merged.
We can do this, guys! And do let us [3] know should you run into
problems looking at already-migrated ebuilds hasn't helped you with.
[1] www-apache/mod_security, which cannot currently be bumped to EAPI 7
because Apache eclasses do not support it
[2] I haven't excluded last-rited maintained packages from the search
[3] i.e. people haunting #gentoo-lua on Freenode, preferably via said
channel
--
MS
OpenPGP_0xD4945FFDD7FE7E37_and_old_rev.asc
Description: application/pgp-keys
OpenPGP_signature
Description: OpenPGP digital signature
[gentoo-dev] dev-lua/luacrypto: last rites
# Marek Szuba (2020-10-13) # Not compatible with >=dev-libs/openssl-1.1.0, no maintainer in Gentoo, # no new commits to the upstream Git repository since September 2013. # No reverse dependencies. Removal in 30 days (Bug #736190). dev-lua/luacrypto -- 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 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
[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
[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 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.
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
Re: [gentoo-dev] [PATCH 0/2] lua-utils.eclass: support LuaJIT and unslotted Lua
On 2020-10-05 23:17, 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? > > 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 The file structure of dev-lang/lua:0 differs from dev-lang/lua:5.x, meaning that introducing such a slot move would require Lua eclasses to treat lua5-1 differently from other targets. In other words, we would *still* need lua0 support but without a clearly distinct name. >> 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. And the advantage of having those migrated would be? It would make sense if these really were core to Lua support in other packages, like e.g. setuptools and the like in the Python world - but this varies wildly from package to package, with a large number of them depending on nothing but the Lua interpreter itself. -- MS signature.asc Description: OpenPGP digital signature
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
[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] [PATCH 0/4] Eclass for single-impl Lua ebuilds
On 2020-10-01 20:31, Daniel Pielmeier wrote: > I already had slotted lua 5.1 and 5.3 installed and the modified ebuild > built fine with lua-5.3 as before. However when I tried setting > LUA_SINGLE_TARGET="lua5-2", lua-5.2 was pulled in as a dependency but > conky still built against lua-5.3. The temporary pkg-config environment > was set correct but somehow it seems not used. Conky uses cmake and > pkg_search_module [1] to detect lua preferring 5.3 over 5.2. > > Am I doing something wrong using the eclass or is there an issue with > the lua detection in conky or maybe the the eclass? I noticed the same thing while adapting x11-wm/awesome, it's caused by how the CMake module FindLua works. You will have to make sure that cmake looks for a specific version. -- MS
[gentoo-dev] [PATCH 4/4] lua-single.eclass: new eclass for single-implementation Lua ebuilds
With many thanks to Michał Górny and other authors of
python-single-r1.eclass.
Signed-off-by: Marek Szuba
---
eclass/lua-single.eclass | 510 +++
1 file changed, 510 insertions(+)
create mode 100644 eclass/lua-single.eclass
diff --git a/eclass/lua-single.eclass b/eclass/lua-single.eclass
new file mode 100644
index 000..2233fdd33b6
--- /dev/null
+++ b/eclass/lua-single.eclass
@@ -0,0 +1,510 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: lua-single.eclass
+# @MAINTAINER:
+# William Hubbs
+# Marek Szuba
+# @AUTHOR:
+# Marek Szuba
+# Based on python-single-r1.eclass by Michał Górny et al.
+# @SUPPORTED_EAPIS: 7
+# @BLURB: An eclass for Lua packages not installed for multiple
implementations.
+# @DESCRIPTION:
+# An extension of lua.eclass suite for packages which don't support being
+# installed for multiple Lua implementations. This mostly includes software
+# embedding Lua.
+#
+# This eclass sets correct IUSE. It also provides LUA_DEPS
+# and LUA_REQUIRED_USE that need to be added to appropriate ebuild
+# metadata variables.
+#
+# The eclass exports LUA_SINGLE_USEDEP that is suitable for depending
+# on other packages using the eclass. Dependencies on packages using
+# lua.eclass should be created via lua_gen_cond_dep() function, using
+# LUA_USEDEP placeholder.
+#
+# Please note that packages support multiple Lua implementations
+# (using lua.eclass) cannot depend on packages not supporting
+# them (using this eclass).
+#
+# Note that since this eclass always inherits lua-utils as well, in ebuilds
+# using the former there is no need to explicitly inherit the latter in order
+# to use helper functions such as lua_get_CFLAGS.
+
+case ${EAPI:-0} in
+ 0|1|2|3|4|5|6)
+ die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
+ ;;
+ 7)
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
+esac
+
+if [[ ! ${_LUA_SINGLE_R0} ]]; then
+
+if [[ ${_LUA_R0} ]]; then
+ die 'lua-single.eclass cannot be used with lua.eclass.'
+fi
+
+inherit lua-utils
+
+fi
+
+EXPORT_FUNCTIONS pkg_setup
+
+# @ECLASS-VARIABLE: LUA_COMPAT
+# @REQUIRED
+# @PRE_INHERIT
+# @DESCRIPTION:
+# This variable contains a list of Lua implementations the package
+# supports. It must be set before the `inherit' call. It has to be
+# an array.
+#
+# Example:
+# @CODE
+# LUA_COMPAT=( lua5-1 lua5-2 lua5-3 )
+# @CODE
+#
+# Please note that you can also use bash brace expansion if you like:
+# @CODE
+# LUA_COMPAT=( lua5-{1..3} )
+# @CODE
+
+# @ECLASS-VARIABLE: LUA_COMPAT_OVERRIDE
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# This variable can be used when working with ebuilds to override
+# the in-ebuild LUA_COMPAT. It is a string listing all
+# the implementations which package will be built for. It need be
+# specified in the calling environment, and not in ebuilds.
+#
+# It should be noted that in order to preserve metadata immutability,
+# LUA_COMPAT_OVERRIDE does not affect IUSE nor dependencies.
+# The state of LUA_TARGETS is ignored, and all the implementations
+# in LUA_COMPAT_OVERRIDE are built. Dependencies need to be satisfied
+# manually.
+#
+# Example:
+# @CODE
+# LUA_COMPAT_OVERRIDE='lua5-2' emerge -1v dev-lua/foo
+# @CODE
+
+# @ECLASS-VARIABLE: LUA_REQ_USE
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# The list of USE flags required to be enabled on the chosen Lua
+# implementations, formed as a USE-dependency string. It should be valid
+# for all implementations in LUA_COMPAT, so it may be necessary to
+# use USE defaults.
+# This must be set before calling `inherit'.
+#
+# Example:
+# @CODE
+# LUA_REQ_USE="deprecated"
+# @CODE
+#
+# It will cause the Lua dependencies to look like:
+# @CODE
+# lua_targets_luaX-Y? ( dev-lang/lua:X.Y[deprecated] )
+# @CODE
+
+# @ECLASS-VARIABLE: LUA_DEPS
+# @OUTPUT_VARIABLE
+# @DESCRIPTION:
+# This is an eclass-generated Lua dependency string for all
+# implementations listed in LUA_COMPAT.
+#
+# Example use:
+# @CODE
+# RDEPEND="${LUA_DEPS}
+# dev-foo/mydep"
+# DEPEND="${RDEPEND}"
+# @CODE
+#
+# Example value:
+# @CODE
+# lua_targets_lua5-1? ( dev-lang/lua:5.1 )
+# lua_targets_lua5-2? ( dev-lang/lua:5.2 )
+# @CODE
+
+# @ECLASS-VARIABLE: LUA_REQUIRED_USE
+# @OUTPUT_VARIABLE
+# @DESCRIPTION:
+# This is an eclass-generated required-use expression which ensures at
+# least one Lua implementation has been enabled.
+#
+# This expression should be utilized in an ebuild by including it in
+# REQUIRED_USE, optionally behind a use flag.
+#
+# Example use:
+# @CODE
+# REQUIRED_USE="lua? ( ${LUA_REQUIRED_USE} )"
+# @CODE
+#
+# Example value:
+# @CODE
+# || ( lua_targets_lua5-1 lua_targets_lua5-2 )
+# @CODE
+
+# @ECLASS-VARIABLE: LUA_SINGLE_USEDEP
+# @OUTPUT_VARIABLE
+# @DESCRIPTION:
+# This is an eclass-ge
[gentoo-dev] [PATCH 3/4] profiles/desc: describe LUA_SINGLE_TARGET
Already includes lua-5.4. Signed-off-by: Marek Szuba --- profiles/desc/lua_single_target.desc | 9 + 1 file changed, 9 insertions(+) create mode 100644 profiles/desc/lua_single_target.desc diff --git a/profiles/desc/lua_single_target.desc b/profiles/desc/lua_single_target.desc new file mode 100644 index 000..1bee02b6978 --- /dev/null +++ b/profiles/desc/lua_single_target.desc @@ -0,0 +1,9 @@ +# Copyright 1999-2020 Gentoo Authors. +# Distributed under the terms of the GNU General Public License v2 + +# This file contains descriptions of LUA_SINGLE_TARGET USE_EXPAND flags. + +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 -- 2.26.2
[gentoo-dev] [PATCH 2/4] lua.eclass: die if lua-single.eclass has already been loaded
Signed-off-by: Marek Szuba
---
eclass/lua.eclass | 4
1 file changed, 4 insertions(+)
diff --git a/eclass/lua.eclass b/eclass/lua.eclass
index f4594872e58..8ade9c0f079 100644
--- a/eclass/lua.eclass
+++ b/eclass/lua.eclass
@@ -63,6 +63,10 @@ esac
if [[ ! ${_LUA_R0} ]]; then
+if [[ ${_LUA_SINGLE_R0} ]]; then
+ die 'lua.eclass cannot be used with lua-single.eclass.'
+fi
+
inherit multibuild lua-utils
fi
--
2.26.2
[gentoo-dev] [PATCH 1/4] lua.eclass: split some stuff out as lua-utils.eclass
These are the things that will be used by both lua and lua-single.
Signed-off-by: Marek Szuba
---
eclass/lua-utils.eclass | 373
eclass/lua.eclass | 345 +
2 files changed, 379 insertions(+), 339 deletions(-)
create mode 100644 eclass/lua-utils.eclass
diff --git a/eclass/lua-utils.eclass b/eclass/lua-utils.eclass
new file mode 100644
index 000..490d19a0019
--- /dev/null
+++ b/eclass/lua-utils.eclass
@@ -0,0 +1,373 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: lua-utils.eclass
+# @MAINTAINER:
+# William Hubbs
+# Marek Szuba
+# @AUTHOR:
+# Marek Szuba
+# Based on python-utils-r1.eclass by Michał Górny et al.
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Utility functions for packages with Lua parts
+# @DESCRIPTION:
+# 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.
+
+case ${EAPI:-0} in
+ 0|1|2|3|4|5|6)
+ die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
+ ;;
+ 7)
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
+esac
+
+if [[ ! ${_LUA_UTILS_R0} ]]; then
+
+inherit toolchain-funcs
+
+# @ECLASS-VARIABLE: _LUA_ALL_IMPLS
+# @INTERNAL
+# @DESCRIPTION:
+# All supported Lua implementations, most preferred last
+_LUA_ALL_IMPLS=(
+ lua5-1
+ lua5-2
+ lua5-3
+ lua5-4
+)
+readonly _LUA_ALL_IMPLS
+
+# @FUNCTION: _lua_set_impls
+# @INTERNAL
+# @DESCRIPTION:
+# Check LUA_COMPAT for well-formedness and validity, then set
+# two global variables:
+#
+# - _LUA_SUPPORTED_IMPLS containing valid implementations supported
+# by the ebuild (LUA_COMPAT minus dead implementations),
+#
+# - and _LUA_UNSUPPORTED_IMPLS containing valid implementations that
+# are not supported by the ebuild.
+#
+# Implementations in both variables are ordered using the pre-defined
+# eclass implementation ordering.
+#
+# This function must only be called once.
+_lua_set_impls() {
+ local i
+
+ if ! declare -p LUA_COMPAT &>/dev/null; then
+ die 'LUA_COMPAT not declared.'
+ fi
+ if [[ $(declare -p LUA_COMPAT) != "declare -a"* ]]; then
+ die 'LUA_COMPAT must be an array.'
+ fi
+
+ local supp=() unsupp=()
+
+ for i in "${_LUA_ALL_IMPLS[@]}"; do
+ if has "${i}" "${LUA_COMPAT[@]}"; then
+ supp+=( "${i}" )
+ else
+ unsupp+=( "${i}" )
+ fi
+ done
+
+ if [[ ! ${supp[@]} ]]; then
+ die "No supported implementation in LUA_COMPAT."
+ fi
+
+ if [[ ${_LUA_SUPPORTED_IMPLS[@]} ]]; then
+ # set once already, verify integrity
+ if [[ ${_LUA_SUPPORTED_IMPLS[@]} != ${supp[@]} ]]; then
+ eerror "Supported impls (LUA_COMPAT) changed between
inherits!"
+ eerror "Before: ${_LUA_SUPPORTED_IMPLS[*]}"
+ eerror "Now : ${supp[*]}"
+ die "_LUA_SUPPORTED_IMPLS integrity check failed"
+ fi
+ if [[ ${_LUA_UNSUPPORTED_IMPLS[@]} != ${unsupp[@]} ]]; then
+ eerror "Unsupported impls changed between inherits!"
+ eerror "Before: ${_LUA_UNSUPPORTED_IMPLS[*]}"
+ eerror "Now : ${unsupp[*]}"
+ die "_LUA_UNSUPPORTED_IMPLS integrity check failed"
+ fi
+ else
+ _LUA_SUPPORTED_IMPLS=( "${supp[@]}" )
+ _LUA_UNSUPPORTED_IMPLS=( "${unsupp[@]}" )
+ readonly _LUA_SUPPORTED_IMPLS _LUA_UNSUPPORTED_IMPLS
+ fi
+}
+
+# @FUNCTION: _lua_wrapper_setup
+# @USAGE: [ []]
+# @INTERNAL
+# @DESCRIPTION:
+# Create proper Lua executables and pkg-config wrappers
+# (if available) in the directory named by . Set up PATH
+# and PKG_CONFIG_PATH appropriately. defaults to ${T}/${ELUA}.
+#
+# The wrappers will be created for implementation named by ,
+# or for one named by ${ELUA} if no passed.
+#
+# If the named directory contains a lua symlink already, it will
+# be assumed to contain proper wrappers already and only environment
+# setup will be done. If wrapper update is requested, the directory
+# shall be removed first.
+_lua_wrapper_setup() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ local workdir=${1:-${T}/${ELUA}}
+ local impl=${2:-${ELUA}}
+
+
[gentoo-dev] [PATCH 0/4] Eclass for single-impl Lua ebuilds
Same as lua.eclass and python-r1, this is a Lua version of python-single-r1. Setting LUA_SINGLE_TARGETS allows one to choose the (slotted) Lua implementation to build your ebuild against, optionally including both single- and multi-implementation Lua packages as dependencies. Tested using modified ebuilds of the following packages: - dev-lua/lgi - the multi-impl package I previously used to test lua.eclass, rebuilt this time to make sure said eclass still works properly after having moved some variables and functions to lua-utils.eclass (it does); - x11-wm/awesome - single-implementation, unconditionally depends on both dev-lang/lua itself and dev-lua/lgi (as well as some other dev-lua packages used by the test suite, which however I ignored). Links fine against whichever Lua version is selected by LUA_SINGLE_TARGET, requiring correct LUA_TARGETS to be enabled for dev-lua/lgi in either case; - media-gfx/darktable - conditional dependency on dev-lang/lua controlled by USE=lua. Also builds fine, although with it only supporting lua-5.3+ there wasn't much I could do in terms of version switching beyond confirming that LUA_REQUIRED_USE correctly specifies that exactly one single target must be specified.
Re: [gentoo-dev] [RFC] Subslots for sys-devel/llvm and sys-devel/clang
On 2020-09-24 12:50, Michał Górny wrote: > That's really weird, point releases should not include breaking > changes. Could you try to figure out why this happens? Also, are you > aware if 9.0.0 vs 9.0.1 had the same problem? Maybe it's one time > upstream screwup. Let's hope so, this was very much an unpleasant surprise. Regarding slot 9, I do not remember anyone complaining about it - but then again, I think we only began supporting it in opencl-clang after llvm-9.0.1 had already been stabilised. > A somewhat ugly alternative would be to ~ dep on specific version and > make revbumps for minor llvm bumps. Somewhat ugly indeed, could be worse though - at least dev-util/spirv-llvm-translator and dev-libs/opencl-clang ebuilds support exactly one llvm/clang major version each so no ugly "|| ( ver1:9 ver2:10 ver3:11 )" dependencies will be required. -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-dev] [RFC] Subslots for sys-devel/llvm and sys-devel/clang
Hi all, While fighting with https://bugs.gentoo.org/743992 I discovered that it is necessary for dev-libs/opencl-clang to be rebuilt after EVERY update of LLVM and Clang - even such a supposedly trivial one as from 10.0.0 to 10.0.1. To the best of my knowledge there is currently no way in-slot LLVM/Clang updates to trigger rebuilds of dependent packages, and the simplest (only?) way of doing this would be to add subslots to sys-devel/llvm and sys-devel/clang ebuilds. Therefore: 1. Is the above correct? I shall be happy to be proven wrong if there is a simpler way of achieving this after all; 2. If I am not wrong about the current state of affairs, what are your opinions about adding subslots to LLVM and Clang ebuilds? -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-dev] Stabilisation of app-admin/ansible-2.10.0
Dear Matthew, I notice that you have recently stabilised app-admin/ansible-2.10.0 in Gentoo. Ansible upstream has introduced in that version major changes to their project structure [1] which given the current state of Ansible packaging in Gentoo can be considered severely breaking for our users. Therefore, please: 1. Revert stabilisation of 2.10.0, and 2. Either * by no means remove 2.9.12 from the tree for the time being, and before attempting to stabilise 2.10+ again either prepare a news item warning the users about upcoming breaking changes or package a suitable set of formerly-core modules; or * simply pull the current incarnation of 2.10.0 from the tree and only reintroduce it once the ansible (*not* ansible-base) on PyPI has actually been upgraded to 2.10. Explanation for the ML: Starting with version 2.10, the upstream package previously known as ansible is formally known as "ansible-base" and only provides the bare minimum of functionality - the core programs, some documentation, and a tiny subset of modules and plugins to allow for a functioning controller. All the other modules which were previously part of core ansible (see [2]) are now independent modules. Note that this only pertains to upstream packages of Ansible released on GitHub. On PyPI, "ansible" will continue to bundle the "core" modules; this is explicitly mentioned in several places in [1]. The problem is, =app-admin/ansible-2.10.0 has quietly replaced pypi:ansible with pypi:ansible-base in SRC_URI. This may or may not have had something to do with the fact pypi:ansible has not been updated to 2.10.0 yet (for now it's only pre-releases for that branch). References: [1] https://github.com/ansible-collections/overview/blob/main/README.rst [2] https://github.com/ansible-community/ansible-build-data/blob/main/2.10/ansible.in -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files
On 2020-09-13 13:21, Andrew Savchenko wrote: > So it will be reasonable to add USE="systemd" to acct-* eclasses > to control the changes proposed above. Having thought about this some more, another benefit of this approach would be - unless I am wrong of course - that all currently installed acct-* ebuilds will automatically pick up the eclass change of a world update with --newuse or --changed-use. In other words, I second making this conditional on USE=systemd. -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation
Merged, thank you everyone who has weighed in with their comments both on IRC and here. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] lua.eclass: initial implementation
On 2020-09-06 17:46, David Seifert wrote: > Unfortunately we won't get around a single-r1-style eclass too. What > about all those programs embedding a specific lua version as plugin > architecture? This is still very much on my to-do list, I simply figured it would make it easier for everyone reviewing this to leave it until the next iteration. > But the basic principles underlying your eclass > are finally correct, unlike the previous lua.eclass attempt. Thank you! Of course it would have been much more difficult to achieve were it not for Michał's work on python-r1. On 2020-09-06 19:13, Azamat Hackimov wrote: >> +# @ECLASS-VARIABLE: LUA >> +# @DEFAULT_UNSET >> +# @DESCRIPTION: >> +# The absolute path to the current Lua interpreter. This variable is set >> +# automatically in functions called by lua_foreach_impl(). >> +# >> +# Example value: >> +# @CODE >> +# /usr/bin/lua5.1 > > I think there also needs a LUAC variable that points to the current > Lua compiler. Possibly, then again I have begun to wonder if we even need LUA itself... Moreover, there would be no LUAC were the eclass made to support luajit. I guess we'll see how many ebuilds actually need these once we have begun porting them to lua.eclass. > There needs a LUA_MAJOR_VERSION (V variable in lua.pc, i.e. 5.1, 5.2, > 5.3) instead of full version (R variable in lua.pc, i.e 5.1.5, 5.2.4). > Some obscure Lua packages are required to define V variable to work > properly. Nah, one can easily go from the full version to the ABI version (LUA_MAJOR_VERSION would just be 5 signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 1/2] eclass: Add first version of lua.eclass
On 2020-09-03 15:37, Marek Szuba wrote:
For the record, some mostly-cosmetic issues that have already been
identified. Will include them in the next revision:
> +if [[ ! ${_LUA_R0} ]]; then
> +
> +inherit multibuild toolchain-funcs
> +
> +BDEPEND="virtual/pkgconfig"
There should be no BDEPEND in the eclass any more, it's a leftover from
an earlier iteration which retrieved module directories in less
conditional fashion.
> +# Please note that you can also use bash brace expansion if you like:
> +# @CODE
> +# LUA_COMPAT=( lua5_{1..3} )
s/_/-/
> + eerror "No Lua implementation selected for the build. Please add one"
> + eerror "of the following values to your LUA_TARGETS (in make.conf):"
Will add "or package.use" here.
> +# @FUNCTION: _lua_wrapper_setup
> +# @USAGE: [ []]
> +# @INTERNAL
> +# @DESCRIPTION:
> +# Create proper 'lua' executable and pkg-config wrappers
Should be "proper Lua executables" - for dev-lang/lua we have got both
'lua' and 'luac', and for dev-lang/luajit we'll probably have 'luajit'
(have yet to see if invoking 'luajit' as 'lua' works).
> +# Check LUA_COMPAT for well-formedness and validity, then set
> +# two global variables:
> +#
> +# - _LUA_SUPPORTED_IMPLS containing valid implementations supported
> +# by the ebuild (LUA_COMPAT - dead implementations),
Just say "minus" here, as it stands it is a bit confusing (at least to
me) because my first reaction is to read the - as a dash, not as an
arithmetic minus.
--
MS
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] [PATCH 2/2] profiles/desc: describe LUA_TARGETS
Already includes lua-5.4. Signed-off-by: Marek Szuba --- profiles/desc/lua_targets.desc | 9 + 1 file changed, 9 insertions(+) create mode 100644 profiles/desc/lua_targets.desc diff --git a/profiles/desc/lua_targets.desc b/profiles/desc/lua_targets.desc new file mode 100644 index 000..2575de0bcfd --- /dev/null +++ b/profiles/desc/lua_targets.desc @@ -0,0 +1,9 @@ +# Copyright 1999-2020 Gentoo Authors. +# Distributed under the terms of the GNU General Public License v2 + +# This file contains descriptions of LUA_TARGETS USE_EXPAND flags. + +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 -- 2.26.2
[gentoo-dev] [PATCH 1/2] eclass: Add first version of lua.eclass
This eclass should be to Lua what python-r1 is to Python. Indeed, most
of the plumbing has been shamelessly stolen from that eclass.
What works:
- support for slotted dev-lang/lua
- building and installing Lua modules, for multiple Lua implementations
- dependencies on other Lua modules
What doesn't work yet:
- support for dev-lang/luajit (not in the least because the versions
currently in the tree share module directories with dev-lang/lua)
- proper support for building against a single Lua target
Signed-off-by: Marek Szuba
---
eclass/lua.eclass | 710 ++
1 file changed, 710 insertions(+)
create mode 100644 eclass/lua.eclass
diff --git a/eclass/lua.eclass b/eclass/lua.eclass
new file mode 100644
index 000..1b104b31cda
--- /dev/null
+++ b/eclass/lua.eclass
@@ -0,0 +1,710 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+# @ECLASS: lua.eclass
+# @MAINTAINER:
+# Marek Szuba
+# @AUTHOR:
+# Marek Szuba
+# Based on python{,-utils}-r1.eclass by Michał Górny et al.
+# @SUPPORTED_EAPIS: 7
+# @BLURB: A common eclass for Lua packages
+# @DESCRIPTION:
+# A common eclass providing helper functions to build and install
+# packages supporting being installed for multiple Lua implementations.
+#
+# This eclass sets correct IUSE. Modification of REQUIRED_USE has to
+# be done by the author of the ebuild (but LUA_REQUIRED_USE is
+# provided for convenience, see below). The eclass exports LUA_DEPS
+# and LUA_USEDEP so you can create correct dependencies for your
+# package easily. It also provides methods to easily run a command for
+# each enabled Lua implementation and duplicate the sources for them.
+#
+# Please note that for the time being this eclass does NOT support luajit.
+#
+# @EXAMPLE:
+# @CODE
+# EAPI=7
+#
+# LUA_COMPAT=( lua5-{1..3} )
+#
+# inherit lua
+#
+# [...]
+#
+# REQUIRED_USE="${LUA_REQUIRED_USE}"
+# DEPEND="${LUA_DEPS}"
+# RDEPEND="${DEPEND}
+# dev-lua/foo[${LUA_USEDEP}]"
+# BDEPEND="virtual/pkgconfig"
+#
+# lua_src_install() {
+# emake LUA_VERSION="$(lua_get_version)" install
+# }
+#
+# src_install() {
+# lua_foreach_impl lua_src_install
+# }
+# @CODE
+
+case ${EAPI:-0} in
+ 0|1|2|3|4|5|6)
+ die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
+ ;;
+ 7)
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
+esac
+
+if [[ ! ${_LUA_R0} ]]; then
+
+inherit multibuild toolchain-funcs
+
+BDEPEND="virtual/pkgconfig"
+
+fi
+
+# @ECLASS-VARIABLE: LUA_COMPAT
+# @REQUIRED
+# @PRE_INHERIT
+# @DESCRIPTION:
+# This variable contains a list of Lua implementations the package
+# supports. It must be set before the `inherit' call. It has to be
+# an array.
+#
+# Example:
+# @CODE
+# LUA_COMPAT=( lua5-1 lua5-2 lua5-3 )
+# @CODE
+#
+# Please note that you can also use bash brace expansion if you like:
+# @CODE
+# LUA_COMPAT=( lua5_{1..3} )
+# @CODE
+
+# @ECLASS-VARIABLE: LUA_COMPAT_OVERRIDE
+# @USER_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# This variable can be used when working with ebuilds to override
+# the in-ebuild LUA_COMPAT. It is a string listing all
+# the implementations which package will be built for. It need be
+# specified in the calling environment, and not in ebuilds.
+#
+# It should be noted that in order to preserve metadata immutability,
+# LUA_COMPAT_OVERRIDE does not affect IUSE nor dependencies.
+# The state of LUA_TARGETS is ignored, and all the implementations
+# in LUA_COMPAT_OVERRIDE are built. Dependencies need to be satisfied
+# manually.
+#
+# Example:
+# @CODE
+# LUA_COMPAT_OVERRIDE='lua5-2' emerge -1v dev-lua/foo
+# @CODE
+
+# @ECLASS-VARIABLE: LUA_REQ_USE
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# The list of USE flags required to be enabled on the chosen Lua
+# implementations, formed as a USE-dependency string. It should be valid
+# for all implementations in LUA_COMPAT, so it may be necessary to
+# use USE defaults.
+# This must be set before calling `inherit'.
+#
+# Example:
+# @CODE
+# LUA_REQ_USE="deprecated"
+# @CODE
+#
+# It will cause the Lua dependencies to look like:
+# @CODE
+# lua_targets_luaX-Y? ( dev-lang/lua:X.Y[deprecated] )
+# @CODE
+
+# @ECLASS-VARIABLE: BUILD_DIR
+# @OUTPUT_VARIABLE
+# @DEFAULT_UNSET
+# @DESCRIPTION:
+# The current build directory. In global scope, it is supposed to
+# contain an initial build directory; if unset, it defaults to ${S}.
+#
+# In functions run by lua_foreach_impl(), the BUILD_DIR is locally
+# set to an implementation-specific build directory. That path is
+# created through appending a hyphen and the implementation name
+# to the final component of the initial BUILD_DIR.
+#
+# Example value:
+# @CODE
+# ${WORKDIR}/foo-1.3-lua5-1
+# @CODE
+
+# @ECLASS-VARIABLE: ELUA
+# @DEFAULT_U
[gentoo-dev] [PATCH] lua.eclass: initial implementation
Ladies and gentlemen, Here is my first attempt on creating an eclass which would handle installation of Lua modules for multiple implementations. As some of you are aware of, the lack of such an eclass has been a major issue for our efforts on slotting dev-lang/lua. With many, many thanks to mgorny and everyone else who has worked on python-r1.eclass, to whom lua.eclass bears, ahem, striking resemblance. At the moment this is only really useful for installing Lua modules but assuming it doesn't turn out to be a total failure, I'll work on single-target support as the next step. We should probably think about adding LuaJIT support at some point too. Comments are very much welcome!
[gentoo-dev] Last rites: dev-go/siphash
# Marek Szuba (2020-09-01) # Uses golang-* eclasses, only a library, all former reverse # dependencies have long since switched to vendoring. # Removal in 30 days. Bug #732130. dev-go/siphash -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-*.eclass: Create sysusers.d files
On 2020-08-29 21:53, Michał Górny wrote:
> + newins - ${CATEGORY}-${ACCT_USER_NAME}.conf < <(
> + printf "u\t%q\t%q\t%q\t%q\t%q\n" \
> + "${ACCT_USER_NAME}" \
> + "${ACCT_USER_ID/#-*/-}:${ACCT_USER_GROUPS[0]}" \
> + "${DESCRIPTION//[:,=]/;}" \
Maybe it's a fault in how I have tested this (i.e. in an interactive
bash session, by setting all the variables and copy-pasting the relevant
printf lines by hand) but for me this results in an unquoted GECOS
string with spaces escaped with backslashes, whereas sysusers.d(5)
explicitly states this should be enclosed in quotation marks. Could you
double-check, please?
Otherwise LGTM.
--
MS
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] Improving warnings on packages.g.o
On 2020-08-26 20:57, Max Magorsch wrote: > To avoid these false warnings it's now possible to filter the repology > checks. No more false warnings due to Repology not understanding the Gentoo Perl version scheme? Yes please! Thank you *very* much for this feature, and in case I haven't said it yet for all your work on packages.g.o in the first place. On a related note, how hard would it in your opinion be to implement the handling of said Perl versioning scheme? In this particular case querying remote-IDs instead of / addition to Repology will not help because it's the difference between Gentoo and upstream. -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Enable "gui" flag in desktop profile
On 2020-08-27 11:46, Ulrich Mueller wrote: > IMHO this means that the "gui" flag should be enabled in desktop > profiles (similar to "X"). > > Any comments? If not, I'll enable it in two days from now. Makes sense to me, go ahead. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: New "Accept Github contributions" metadata flag
On 2020-08-18 14:05, Joonas Niilola wrote: > I'm suggesting of adding a new metadata flag to our Wiki's > User:/Project: page which then prints a message to this page saying > whether the maintainer (be it project or user), "accepts" or "deals > with" Github contributions. The wording can be a bit better, but it'd be > there to **notify** our **contributors** whether their time and effort > will most likely be wasted making a pull request for this particular > maintainer. I like this idea. While I do use GitHub PRs and GitLab MRs in the course of my work I personally have found them more trouble than they are worth as far as Gentoo is concerned - and GitHub in particular I am not a huge fan of. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-libs/hsa-ext-rocr
# Marek Szuba (2020-08-26) # ROCm has had open-source OpenCL image support since 3.3, and since 3.7 # it no longer attempts to use the proprietary library even when it is # present. Last but not least, upstream no longer publishes this. # Removal in 30 days. Bug #739066. dev-libs/hsa-ext-rocr -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] eclass/sword-module.eclass: update SRC_URI, expand a bit, clean up
On 2020-07-29 12:10, Michał Górny wrote: > LGTM. Thanks! Okay then, merged! -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Last rites: */*: More Py2 stuff
On 2020-07-29 16:22, Alexis Ballier wrote: > I think you've been told several times already, but impacting users > with a mask (that can't do anything useful about it) and not bothering > to file bugs for developers (that *can* do something about it) is not > the proper way to achieve anything here. This. Very much this. Especially the part about communicating with other Gentoo developers by last-rite messages. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: app-dicts/sword-{Cro,Dan,FarsiOPV,FreLSG,FreMartin,HNV,KJVD,RST,SpaRVG2004,SpaSEV,WEB,WebstersDict}
# Marek Szuba (2020-07-27) # No longer available upstream. Potentially copyrighted. # Removal in 30 days. Bug #734116. app-dicts/sword-Cro app-dicts/sword-Dan app-dicts/sword-FarsiOPV app-dicts/sword-FreLSG app-dicts/sword-FreMartin app-dicts/sword-HNV app-dicts/sword-KJVD app-dicts/sword-RST app-dicts/sword-SpaRVG2004 app-dicts/sword-SpaSEV app-dicts/sword-WEB app-dicts/sword-WebstersDict -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH v2] sword-module.eclass: update SRC_URI, expand a bit, clean up
Second iteration of proposed changes to sword-module.eclass, this time without incrementing revision because I am fairly confident that it should all be backwards-compatible. Changes with respect to the first iteration: - SWORD_MODULE now defaults to a value extracted from PN; - do not bother with versioning files in advance and hosting them at d.g.o., just version files fetched from upstream and let Gentoo mirrors do their magic.
[gentoo-dev] [PATCH] eclass/sword-module.eclass: update SRC_URI, expand a bit, clean up
1. The old version expected versioned source archives to have been
manually uploaded to the Gentoo mirror network by package
maintainers. This is no longer allowed, or indeed possible for most
Gentoo developers. Instead, use the SRC_URI arrow mechanism to
version archives fetched directly from upstream. SWORD Project
updates their modules quite infrequently so it isn't really necessary
to worry the file having changed between looking the version number
up on the module page and fetching the archive for digest generation,
and while users who do not use Gentoo mirrors will see digest
conflicts when an update does occur, this would effectively encourage
them to notify maintainers whenever a new version is released;
2. If SWORD_MODULE is not set, attempt to generate it from PN by
stripping the prefix 'sword-'. This will allow explicit declarations
of SWORD_MODULE from all app-dicts/sword-* ebuilds currently in the
tree;
3. Add the optional variable SWORD_MINIMUM_VERSION to specify the lowest
version of app-text/sword supported by the module at hand;
4. Remove redundant declarations of HOMEPAGE and IUSE;
5. app-arch/unzip is now in BDEPEND rather than DEPEND;
6. As a consequence of the above, enforce the use of EAPI-7 in ebuilds
inheriting this eclass. Those in the tree have all already been
updated to that EAPI version;
7. Remove redundant references to ${S} from doins() calls;
8. Add eclassdoc blocks.
No revision change in the end because all the changes should be
backwards-compatible.
Closes: https://bugs.gentoo.org/637882
Signed-off-by: Marek Szuba
---
eclass/sword-module.eclass | 92 +++---
1 file changed, 77 insertions(+), 15 deletions(-)
diff --git a/eclass/sword-module.eclass b/eclass/sword-module.eclass
index c66c9987e9f..2ae58d1e51b 100644
--- a/eclass/sword-module.eclass
+++ b/eclass/sword-module.eclass
@@ -1,33 +1,95 @@
# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
+# @ECLASS: sword-module.eclass
+# @MAINTAINER:
+# Marek Szuba
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Simplify installation of SWORD modules
+# @DESCRIPTION:
+# This eclass provides dependencies, ebuild environment and the src_install
+# function common to all app-text/sword modules published by the SWORD Project.
#
-# eclass to simplify installation of Sword modules
-# Bugs to mare...@gentoo.org
+# Note that as of 2020-07-26 module archives published by SWORD are still
+# not versioned and it is necessary to look at respective module pages in
+# order to see what versions the currently available files are. Once
+# a module file has been replicated to the Gentoo mirror network it will be
+# versioned and remain available even after upstream has changed their
+# version, however users not using mirrors will encounter hash conflicts
+# on updated modules. Should that happen, please notify the relevant
+# package maintainers that a new version is available.
#
+# @EXAMPLE:
+# sword-Personal-1.0.ebuild, a typical ebuild using sword-module.eclass:
+#
+# @CODE
+# EAPI=7
+#
+# SWORD_MINIMUM_VERSION="1.5.1a"
+#
+# inherit sword-module
+#
+# DESCRIPTION="SWORD module for storing one's own commentary"
+# HOMEPAGE="https://crosswire.org/sword/modules/ModInfo.jsp?modName=Personal;
+# LICENSE="public-domain"
+# KEYWORDS="~amd64 ~ppc ~x86"
+#
+# @CODE
-HOMEPAGE="http://www.crosswire.org/sword/modules/;
+case ${EAPI:-0} in
+ 0|1|2|3|4|5|6)
+ die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
+ ;;
+ 7)
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
+esac
-# Sword packages are generally released as FooBar.zip in their 'rawzip' form
-# The files are also unversioned, so the packager will need to rename the
-# original file to something else and host it somewhere to avoid breaking
-# the digest when new versions are released.
+# @ECLASS-VARIABLE: SWORD_MINIMUM_VERSION
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# If set to a non-null value, specifies the minimum version of app-text/sword
+# the module requires. This will be included in RDEPEND. If null or unset,
+# the dependency will be unversioned.
+# Needs to be set before the inherit line.
-SRC_URI="mirror://gentoo/${SWORD_MODULE}-${PV}.zip"
+# @ECLASS-VARIABLE: SWORD_MODULE
+# @PRE_INHERIT
+# @DESCRIPTION:
+# Case-sensitive name of the SWORD-Project module to install. If unset
+# or null, use the name produced by removing the prefix 'sword-' from PN.
+# Needs to be set before the inherit line.
+: ${SWORD_MODULE:=${PN#sword-}}
+
+EXPORT_FUNCTIONS src_install
+
+# Unless overridden at ebuild level, append version to the name of the file
+# fetched from upstream and let the Gentoo mirror network take care of
+# persisting the versioned archive.
+SRC_UR
Re: [gentoo-dev] [RFC] sword-module.eclass: update, extend, increment revision
On 2020-07-27 12:02, Michał Górny wrote: > +# Note that while all SWORD modules which do not require prior registration > > s/which/that/ Not quite sure if this is really necessary, as far as I remember both "which" and "that" are grammatically correct in this context - in British English anyway. >> +# in order to see when they have last been updated. Therefore, maintainers >> +# must rename module files to include the version number and host them >> +# somewhere to avoid breaking digests when new versions are released. > > Technically speaking, this isn't strictly necessary. You could just use > SRC_URI arrows to rename them, and then Gentoo mirrors would jump in. > On the minus side, things would occasionally break for people not using > Gentoo mirrors. On the plus side, they would effectively ping you > whenever new version happens ;-). On the plus side, no need for tedious file-renaming steps. And finally on the plus side, no need to store 500+ MB of renamed-but-otherwise-same-as-upstream files on dev.gentoo.org. You've convinced me :-) >> +# @ECLASS-VARIABLE: SWORD_MODULE >> +# @DEFAULT_UNSET >> +# @PRE_INHERIT >> +# @REQUIRED >> +# @DESCRIPTION: >> +# Name of the module as used by the SWORD Project. Case-sensitive. >> +# Needs to be set before the inherit line. > > Wouldn't using a default generated from PN work most of the time? Until just a moment ago, it was not - all the app-dicts/sword-* we have in the tree had been named using upstream module names converted to all-lowercase. I thought about changing this but thought it might be better to leave it until after the eclass update. That was until just a moment ago, though - having read your comment and having confirmed that we use upstream names for source archives, I have just renamed those packages to match the case of upstream names. Will update the eclass with a PN-derived default of SWORD_MODULE before the next iteration. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] sword-module.eclass: update, extend, increment revision
On 2020-07-26 21:19, Michał Górny wrote:
> Please use git-send-email, so that we can reply in context without
> jumping through hoops.
Funny, last time I used git-send-email to post a diff introducing a new
revision of a file (it was virtual/opencl, IIRC) I got told it was too
difficult to follow the changes that way and a plain diff would have
been more useful.
Anyway, here is the same diff but inline. I'll also repeat the summary
of proposed changes here so that it isn't necessary to switch to a
different message to see it:
- add eclassdoc blocks;
- add the optional variable SWORD_MINIMUM_VERSION to specify the lowest
version of app-text/sword supported by the module at hand;
- check if SWORD_MODULE is set and not null, and die otherwise;
- change the default SRC_URI from mirror://gentoo to my Web space on
dev.gentoo.org;
- remove redundant declarations of HOMEPAGE and IUSE;
- app-arch/unzip is now in BDEPEND rather than DEPEND;
- as a consequence of the above, enforce the use of EAPI-7 in ebuilds
inheriting this eclass;
- remove redundant references to ${S} from doins() calls.
* * *
--- eclass/sword-module.eclass
+++ eclass/sword-module-r1.eclass
@@ -1,33 +1,100 @@
# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
+# @ECLASS: sword-module-r1.eclass
+# @MAINTAINER:
+# Marek Szuba
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Simplify installations of SWORD modules
+# @DESCRIPTION:
+# This eclass provides dependencies, ebuild environment and the src_install
+# function common to all app-text/sword modules published by the SWORD Project.
#
-# eclass to simplify installation of Sword modules
-# Bugs to mare...@gentoo.org
+# Note that while all SWORD modules which do not require prior registration
+# to unlock can easily be downloaded from the upstream Web site, as of
+# 2020-07-26 all the files available at
+# https://crosswire.org/ftpmirror/pub/sword/packages/rawzip/
+# are unversioned and it is necessary to look at respective module pages
+# in order to see when they have last been updated. Therefore, maintainers
+# must rename module files to include the version number and host them
+# somewhere to avoid breaking digests when new versions are released.
#
+# @EXAMPLE:
+# Typical ebuild using sword-module-r1.eclass:
+#
+# @CODE
+# EAPI=7
+#
+# SWORD_MODULE="Personal"
+# SWORD_MINIMUM_VERSION="1.5.1a"
+#
+# inherit sword-module-r1
+#
+# DESCRIPTION="SWORD module for storing one's own commentary"
+# HOMEPAGE="https://crosswire.org/sword/modules/ModInfo.jsp?modName=Personal;
+# LICENSE="public-domain"
+# KEYWORDS="~amd64"
+#
+# @CODE
-HOMEPAGE="http://www.crosswire.org/sword/modules/;
+case ${EAPI:-0} in
+ 0|1|2|3|4|5|6)
+ die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
+ ;;
+ 7)
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
+esac
+
+# @ECLASS-VARIABLE: SWORD_MODULE
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @REQUIRED
+# @DESCRIPTION:
+# Name of the module as used by the SWORD Project. Case-sensitive.
+# Needs to be set before the inherit line.
+
+if [[ ! ${SWORD_MODULE} ]]; then
+ die 'SWORD_MODULE not declared or null'
+fi
+
+# @ECLASS-VARIABLE: SWORD_MINIMUM_VERSION
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# If set to a non-null value, specifies the minimum version of app-text/sword
+# the module requires. This will be included in RDEPEND. If null or unset,
+# the dependency will be unversioned.
+# Needs to be set before the inherit line.
-# Sword packages are generally released as FooBar.zip in their 'rawzip' form
-# The files are also unversioned, so the packager will need to rename the
-# original file to something else and host it somewhere to avoid breaking
-# the digest when new versions are released.
+EXPORT_FUNCTIONS src_install
-SRC_URI="mirror://gentoo/${SWORD_MODULE}-${PV}.zip"
+# Default location of versioned files. In general this is obviously
+# maintainer-specific, then again all the 133 modules present in the tree
+# as of mid-July 2020 are maintained by the same person.
+SRC_URI="https://dev.gentoo.org/~marecki/dists/sword-modules/${SWORD_MODULE}-${PV}.zip;
SLOT="0"
-IUSE=""
+# Module archives contain no top-level directory.
S="${WORKDIR}"
-RDEPEND="app-text/sword"
-DEPEND="app-arch/unzip"
-
-sword-module_src_install() {
+if [[ ${SWORD_MINIMUM_VERSION} ]]; then
+ RDEPEND=">=app-text/sword-${SWORD_MINIMUM_VERSION}"
+else
+ RDEPEND="app-text/sword"
+fi
+
+BDEPEND="app-arch/unzip"
+
+# @FUNCTION: sword-module-r1_src_install
+# @DESCRIPTION:
+# Install all the module files into directories expected by app-text/sword.
+sword-module-r1_src_install() {
insinto /usr/share/sword/modules
-
[gentoo-dev] [RFC] sword-module.eclass: update, extend, increment revision
Dear all,
sword-module.eclass needs some changes, not in the least because it
assumes versioned source files are uploaded directly to the Gentoo
mirror network. The complete list of proposed changes is as follows:
- add eclassdoc blocks;
- add the optional variable SWORD_MINIMUM_VERSION to specify the lowest
version of app-text/sword supported by the module at hand;
- check if SWORD_MODULE is set and not null, and die otherwise;
- change the default SRC_URI from mirror://gentoo to my Web space on
dev.gentoo.org;
- remove redundant declarations of HOMEPAGE and IUSE;
- app-arch/unzip is now in BDEPEND rather than DEPEND;
- as a consequence of the above, enforce the use of EAPI-7 in ebuilds
inheriting this eclass;
- remove redundant references to ${S} from doins() calls.
A diff is attached.
This is the first time I change anything other than documentation in any
eclass so I would very, very much appreciate your comments. In
particular, do we really need a revision bump? I initially decided to
err on the side of caution because I would rather not have the SRC_URI
change break all the app-dicts/sword-* modules, that said Portage
usually (always?) queries Gentoo mirrors before attempting to fetch
directly from SRC_URI so maybe it is harmless after all?
Cheers,
--
Marecki
--- eclass/sword-module.eclass
+++ eclass/sword-module-r1.eclass
@@ -1,33 +1,100 @@
# Copyright 1999-2020 Gentoo Authors
# Distributed under the terms of the GNU General Public License v2
+# @ECLASS: sword-module-r1.eclass
+# @MAINTAINER:
+# Marek Szuba
+# @SUPPORTED_EAPIS: 7
+# @BLURB: Simplify installations of SWORD modules
+# @DESCRIPTION:
+# This eclass provides dependencies, ebuild environment and the src_install
+# function common to all app-text/sword modules published by the SWORD Project.
#
-# eclass to simplify installation of Sword modules
-# Bugs to mare...@gentoo.org
+# Note that while all SWORD modules which do not require prior registration
+# to unlock can easily be downloaded from the upstream Web site, as of
+# 2020-07-26 all the files available at
+# https://crosswire.org/ftpmirror/pub/sword/packages/rawzip/
+# are unversioned and it is necessary to look at respective module pages
+# in order to see when they have last been updated. Therefore, maintainers
+# must rename module files to include the version number and host them
+# somewhere to avoid breaking digests when new versions are released.
#
+# @EXAMPLE:
+# Typical ebuild using sword-module-r1.eclass:
+#
+# @CODE
+# EAPI=7
+#
+# SWORD_MODULE="Personal"
+# SWORD_MINIMUM_VERSION="1.5.1a"
+#
+# inherit sword-module-r1
+#
+# DESCRIPTION="SWORD module for storing one's own commentary"
+# HOMEPAGE="https://crosswire.org/sword/modules/ModInfo.jsp?modName=Personal;
+# LICENSE="public-domain"
+# KEYWORDS="~amd64"
+#
+# @CODE
-HOMEPAGE="http://www.crosswire.org/sword/modules/;
+case ${EAPI:-0} in
+ 0|1|2|3|4|5|6)
+ die "Unsupported EAPI=${EAPI} (too old) for ${ECLASS}"
+ ;;
+ 7)
+ ;;
+ *)
+ die "Unsupported EAPI=${EAPI} (unknown) for ${ECLASS}"
+ ;;
+esac
+
+# @ECLASS-VARIABLE: SWORD_MODULE
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @REQUIRED
+# @DESCRIPTION:
+# Name of the module as used by the SWORD Project. Case-sensitive.
+# Needs to be set before the inherit line.
+
+if [[ ! ${SWORD_MODULE} ]]; then
+ die 'SWORD_MODULE not declared or null'
+fi
+
+# @ECLASS-VARIABLE: SWORD_MINIMUM_VERSION
+# @DEFAULT_UNSET
+# @PRE_INHERIT
+# @DESCRIPTION:
+# If set to a non-null value, specifies the minimum version of app-text/sword
+# the module requires. This will be included in RDEPEND. If null or unset,
+# the dependency will be unversioned.
+# Needs to be set before the inherit line.
-# Sword packages are generally released as FooBar.zip in their 'rawzip' form
-# The files are also unversioned, so the packager will need to rename the
-# original file to something else and host it somewhere to avoid breaking
-# the digest when new versions are released.
+EXPORT_FUNCTIONS src_install
-SRC_URI="mirror://gentoo/${SWORD_MODULE}-${PV}.zip"
+# Default location of versioned files. In general this is obviously
+# maintainer-specific, then again all the 133 modules present in the tree
+# as of mid-July 2020 are maintained by the same person.
+SRC_URI="https://dev.gentoo.org/~marecki/dists/sword-modules/${SWORD_MODULE}-${PV}.zip;
SLOT="0"
-IUSE=""
+# Module archives contain no top-level directory.
S="${WORKDIR}"
-RDEPEND="app-text/sword"
-DEPEND="app-arch/unzip"
-
-sword-module_src_install() {
+if [[ ${SWORD_MINIMUM_VERSION} ]]; then
+ RDEPEND=">=app-text/sword-${SWORD_MINIMUM_VERSION}"
+else
+ RDEPEND="app-text/sword"
+fi
+
+BDEPEND="app-arch/unzip"
+
+# @FUNCTION: sword-module-r1_src_install
+# @DESCRIPTION:
+# Install all the module files into directories expected by app-text/s
Re: [gentoo-dev] Project:Theology is now empty
On 2020-07-25 11:47, Michał Górny wrote: > The project maintains the following packages (and one eclass): I'll take the whole stock. Will take care of all the reassignments over the weekend. -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-dev] Last rites: dev-go/goptlib
# Marek Szuba (2020-07-11) # Uses golang-* eclasses, only a library, all former reverse # dependencies have long since switched to vendoring. # Removal in 30 days. Bug #732136. dev-go/goptlib -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-dev] Co-maintainer needed for dev-libs/intel-neo and friends
Guys, Over the course of the last 6 months I have for various reasons gone from 3 systems with an integrated Intel GPU to only 1, and it is quite likely that the last one will be gone quite soon as well. This means I am slowly becoming unable to perform any runtime testing of dev-libs/intel-neo. Therefore, I am looking for a co-maintainer of parts of the NEO stack which currently have only got me as the maintainer, namely: - dev-libs/intel-neo - dev-libs/opencl-clang - dev-util/intel-graphics-compiler - dev-util/spirv-llvm-translator Note that I do NOT intend to stop maintaining these packages (nor media-libs/gmmlib, the last part of the NEO stack, which is also maintained by media-video) any time soon, as dev-libs/intel-neo is the only one among them that actually depends on hardware and even there it usually isn't necessary to actually *run* anything. Thanks in advance! -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Packages up for grabs: dev-python/pyopencl, dev-python/pytools
On 2020-05-17 15:46, Michał Górny wrote: > Hello, > > The following packages are looking for a new maintainer: > > dev-python/pyopencl > dev-python/pytools I'll take them. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Graphics Project disbanded [pkgs up for grabs]
On 2020-06-06 20:50, Aaron Bauman wrote: > media-gfx/darktable > media-gfx/pngcrush I'll take these. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader
On 2020-04-20 06:13, Joonas Niilola wrote: > He has been on devaway for a while. > > I would've much rather seen the differences between -r0 -r1 ebuilds to > focus on what is actually done there. Not that I have any say what will > be done in the end, but it's easier for the eyes... Indeed, that is a bit of a problem with revbumps. That said, jer did update the ebuilds today (jer: thank you!) so no list review will be required after all... OpenCL status update: looks like we are good to go, I'll run some tests to confirm that there are no obvious issues with the deptree and assuming there aren't, will unleash the whole thing (by which I mean "post the news item and unmask the updated loader packages") on the unsuspecting public this weekend. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH] x11-drivers/nvidia-drivers: migrate to >=virtual-opencl-3
Revbump each driver branch, with the following changes:
* drop keywords to ~arch where applicable
* do not depend on app-eselect/eselect-opencl
* if USE='kernel_linux uvm' [1,2], depend on >=virtual/opencl-3
* do not call 'eselect opencl nvidia'
[1] only USE=kernel_linux for 340.108 due to lack of IUSE=uvm
[2] check for kernel_linux because virtual/opencl is not, and now
likely never will be, keyworded for FreeBSD
Closes: https://bugs.gentoo.org/717042
Signed-off-by: Marek Szuba
---
.../nvidia-drivers-340.108-r1.ebuild | 497 +++
.../nvidia-drivers-390.132-r3.ebuild | 582 ++
.../nvidia-drivers-430.64-r2.ebuild | 553 +
.../nvidia-drivers-435.21-r2.ebuild | 571 +
.../nvidia-drivers-440.64-r1.ebuild | 577 +
.../nvidia-drivers-440.82-r1.ebuild | 577 +
6 files changed, 3357 insertions(+)
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-340.108-r1.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-390.132-r3.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-430.64-r2.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-435.21-r2.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-440.64-r1.ebuild
create mode 100644 x11-drivers/nvidia-drivers/nvidia-drivers-440.82-r1.ebuild
diff --git a/x11-drivers/nvidia-drivers/nvidia-drivers-340.108-r1.ebuild
b/x11-drivers/nvidia-drivers/nvidia-drivers-340.108-r1.ebuild
new file mode 100644
index 000..63c4692b345
--- /dev/null
+++ b/x11-drivers/nvidia-drivers/nvidia-drivers-340.108-r1.ebuild
@@ -0,0 +1,497 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+inherit desktop flag-o-matic linux-info linux-mod multilib-minimal \
+ nvidia-driver portability toolchain-funcs unpacker udev
+
+NV_URI="https://us.download.nvidia.com/XFree86/;
+X86_NV_PACKAGE="NVIDIA-Linux-x86-${PV}"
+AMD64_NV_PACKAGE="NVIDIA-Linux-x86_64-${PV}"
+X86_FBSD_NV_PACKAGE="NVIDIA-FreeBSD-x86-${PV}"
+AMD64_FBSD_NV_PACKAGE="NVIDIA-FreeBSD-x86_64-${PV}"
+
+DESCRIPTION="NVIDIA Accelerated Graphics Driver"
+HOMEPAGE="https://www.nvidia.com/;
+SRC_URI="
+ amd64-fbsd? (
${NV_URI}FreeBSD-x86_64/${PV}/${AMD64_FBSD_NV_PACKAGE}.tar.gz )
+ amd64? ( ${NV_URI}Linux-x86_64/${PV}/${AMD64_NV_PACKAGE}.run )
+ x86-fbsd? ( ${NV_URI}FreeBSD-x86/${PV}/${X86_FBSD_NV_PACKAGE}.tar.gz )
+ x86? ( ${NV_URI}Linux-x86/${PV}/${X86_NV_PACKAGE}.run )
+ tools? (
+
https://download.nvidia.com/XFree86/nvidia-settings/nvidia-settings-${PV}.tar.bz2
+ )
+"
+
+EMULTILIB_PKG="true"
+IUSE="acpi multilib kernel_FreeBSD kernel_linux static-libs +tools +X"
+KEYWORDS="-* ~amd64 ~x86"
+LICENSE="GPL-2 NVIDIA-r2"
+SLOT="0/${PV%.*}"
+
+COMMON="
+ kernel_linux? (
+ >=virtual/opencl-3
+ >=sys-libs/glibc-2.6.1
+ acct-group/video
+ )
+ tools? (
+ >=x11-libs/gtk+-2.4:2
+ dev-libs/atk
+ dev-libs/glib:2
+ dev-libs/jansson
+ x11-libs/gdk-pixbuf[X]
+ x11-libs/libX11
+ x11-libs/libXext
+ x11-libs/libXv
+ x11-libs/pango[X]
+ )
+ X? (
+ >=app-eselect/eselect-opengl-1.0.9
+ )
+"
+DEPEND="
+ ${COMMON}
+ app-arch/xz-utils
+ kernel_linux? ( virtual/linux-sources )
+"
+RDEPEND="
+ ${COMMON}
+ acpi? ( sys-power/acpid )
+ tools? ( !media-video/nvidia-settings )
+ X? (
+ =x11-libs/libvdpau-0.3-r1
+ sys-libs/zlib[${MULTILIB_USEDEP}]
+ multilib? (
+ >=x11-libs/libX11-1.6.2[${MULTILIB_USEDEP}]
+ >=x11-libs/libXext-1.3.2[${MULTILIB_USEDEP}]
+ )
+ )
+"
+REQUIRED_USE="tools? ( X )"
+QA_PREBUILT="opt/* usr/lib*"
+S=${WORKDIR}/
+NV_KV_MAX_PLUS="5.5"
+CONFIG_CHECK="!DEBUG_MUTEXES ~!LOCKDEP ~MTRR ~SYSVIPC ~ZONE_DMA"
+
+pkg_pretend() {
+ use x86 && CONFIG_CHECK+=" ~HIGHMEM"
+ nvidia-driver_check
+}
+
+pkg_setup() {
+ use x86 && CONFIG_CHECK+=" ~HIGHMEM"
+ nvidia-driver_check
+
+ # try to turn off distcc and ccache for people that have a problem with
it
+ export DISTCC_DISABLE=1
+ export CCACHE_DISABLE=1
+
+ if use kernel_linux; then
+ MODULE_NAMES="nvidia(video:${S}/kernel)"
+
+ # This needs to run after MODULE_NAMES (so that the eclass
checks
+ # whether the kernel supports loadable mod
[gentoo-dev] [PATCH] Have x11-drivers/nvidia-drivers use an ICD loader
As previously mentioned, x11-drivers/nvidia-drivers is the last OpenCL runtime we have got in the tree to be migrated to the "must use an ICD loader" approach to virtual/opencl. Unfortunately I have so far failed to reach the maintainer of this package (jer) by either e-mail, Bugzilla, or IRC - so I'm submitting this for review here.
[gentoo-dev] [PATCH] meson.eclass: update the example to use modern helper functions
We have now got meson_use and meson_feature yet the example still
used usex.
Signed-off-by: Marek Szuba
---
eclass/meson.eclass | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/eclass/meson.eclass b/eclass/meson.eclass
index 0932a7ed427..2bd1dc01760 100644
--- a/eclass/meson.eclass
+++ b/eclass/meson.eclass
@@ -23,9 +23,9 @@
#
# src_configure() {
# local emesonargs=(
-# -Dqt4=$(usex qt4 true false)
-# -Dthreads=$(usex threads true false)
-# -Dtiff=$(usex tiff true false)
+# $(meson_use qt4)
+# $(meson_feature threads)
+# $(meson_use bindist official_branding)
# )
# meson_src_configure
# }
--
2.24.1
Re: [gentoo-dev] Stabilizations and src_test
On 2020-04-12 09:43, Agostino Sarubbo wrote: > If you work on the stabilization workflow you may have noticed that: > > - There are people that rant if you don't run src_test against their packages; > - There are people that rant if you open a test failure bug against their > packages and you block the stabilization. > > So, unless there will be a clear policy about that, I'd suggest to introduce > a > way to establish if a package is expected to pass src_test or not. My first reaction was "not against this, even though I personally very much try (as in, that I occasionally fail or forget) to make sure even unstable ebuilds I push into the tree pass all tests on amd64", having thought about it more however it feels like lowering quality standards for stable arch trees. Test failures in ~arch are one thing but I would be somewhat suspicious of stabilising anything which fails tests unless it is a known (as in, known to the upstream) issue with no easy solution. There is also the slight image problem which could arise from a user running tests themselves and reporting the failure back to us, with the "I thought this was supposed to be *stable*, guys?" undertone. In summary, I am not entirely decided but leaning towards continuing to always run tests during stabilisation. -- Marecki signature.asc Description: OpenPGP digital signature
[gentoo-dev] News item v2: potential file collisions during OpenCL upgrade
All the comments made so far have been considered. Regarding the
possibility of automating the process, I think I would rather not
bother... It feels hacky indeed, it would likely have to persist in
loader ebuilds until eselect-opencl has been removed, and it would
either require an eclass or have to be implemented independently in each
of the loader packages (not that I expect to have more than two any time
soon - but still, that's one copy of the same hack too many) - and all
of this to address a configuration that isn't even the Gentoo default.
Besides, letting the users know that something's changing in how we
handle OpenCL will IMHO not hurt even if they in the end do not have to
change anything by hand.
* * *
Title: Potential file collisions during OpenCL upgrade
Author: Marek Szuba
Posted: 2020-05-01
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-eselect/eselect-opencl
OpenCL support in Gentoo is now being migrated to having all
implementations operate through an ICD loader (dev-libs/ocl-icd or
dev-libs/opencl-icd-loader) installed directly into /usr rather than
using eselect-opencl to switch between implementations, with updated
loader ebuilds having just been released to the public. Unfortunately
although the upgrade process will automatically uninstall
app-eselect/eselect-opencl, it will not remove the symbolic links to
libOpenCL.so created by this tool in library directories because those
links are not owned by the package in question.
For everyone using the default Gentoo configuration of collision
protection (FEATURES='-collision-protect protect-owned'), this should
cause no trouble because this configuration allows the overwriting of
orphaned files. Obviously, systems with collision protection completely
disabled (not recommended but technically possible) will not be affected
either. However, if your system is configured for full collision
protection (FEATURES=collision-protect), it will be necessary to
manually remove those links
rm -i /usr/lib{,64}/libOpenCL.so*
before running the upgrade.
--
MS
signature.asc
Description: OpenPGP digital signature
Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use
On 2020-04-11 14:54, Brian Evans wrote:
> I would mention that FEATURES='-collision-protect protect-owned' is
> the default so most people won't have any action to take at all.
I've been wondering what the default is these days. Good point, in fact
I'll swap the case around so that the flow of the news item is "with
default configuration nothing will happen, if however you have strict
collision check do this".
On 2020-04-11 17:04, Ulrich Mueller wrote:
>> Title: Manual steps required during upgrade to an eselect-free
>> OpenCL set-up
>
> Title is too long.
OK, I'll shorten it.
>> We are now in the process of migrating OpenCL in Gentoo to having
>> all
>
> Maybe avoid first person?
Can do.
> "eselect-free versions" is a strange term.
How about simply "updated versions"?
> Also, why a line break after "versions"?
It's just because Thunderbird breaks lines at fewer characters than Vim
in text-file mode. It isn't present in the actual news item.
> Another funny line break.
Again, Thunderbird's fault.
>> libOpenCL.so created by this tool in library directories because
>> those links are not owned by the package in question. If your
>> system is configured for full collision protection
>> (FEATURES=collision-protect), it will be necessary to manually
>> remove those links
>
>> rm -i /usr/lib{,64}/libOpenCL.so*
>
>> before running the upgrade.
>
> Can't this be done automatically, e.g., in pkg_preinst of the
> replacing package?
I have tried doing this in pkg_preinst but alas, I have found out
collision checks are performed before that function is invoked. I have
also tried setting COLLISION_IGNORE in the replacing package but it
seems that variable only works in make.conf and make.defaults - in which
case it's simpler to simply tell the users to delete those symlinks.
--
MS
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use
Does this look okay to you, guys? The date is preliminary and dependent
on how quickly we can get nvidia-drivers migrated to the new approach,
hopefully we can get this to happen sooner.
* * *
Title: Manual steps required during upgrade to an eselect-free OpenCL set-up
Author: Marek Szuba
Posted: 2020-05-01
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-eselect/eselect-opencl
We are now in the process of migrating OpenCL in Gentoo to having all
implementations operate through an ICD loader (dev-libs/ocl-icd or
dev-libs/opencl-icd-loader) installed directly into /usr instead of
using eselect-opencl to switch between implementations. eselect-free
versions
of loader packages have just been released to the public.
Unfortunately although the upgrade to those versions will automatically
uninstall app-eselect/eselect-opencl, it will not remove the symbolic
links to
libOpenCL.so created by this tool in library directories because those links
are not owned by the package in question. If your system is configured for
full collision protection (FEATURES=collision-protect), it will be necessary
to manually remove those links
rm -i /usr/lib{,64}/libOpenCL.so*
before running the upgrade.
Systems whose collision protection either allows overwriting orphaned files
(FEATURES='-collision-protect protect-owned') or which do not use collision
protection at all (not recommended) should be unaffected.
--
MS
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] OpenCL refactoring: status report, 2020-04-11
Dear everyone, I am happy to say that we are now almost ready for switching to eselect-opencl-free handling of OpenCL in Gentoo. Both ocl-icd and opencl-icd-loader have now got (masked) versions in the tree which install directly into /usr, the switching between the two works seamlessly, and I have yet to see any OpenCL-aware package - OpenCL runtimes included - which fails to build in this configuration, regardless of which of the two loaders is used. As far as I can see, there are only two things left to do: 1. Migrate x11-drivers/nvidia-drivers to the new approach. This is a major one because with >=virtual/opencl-3 no longer depending on any runtimes and the adapted incarnations of both ICD loaders block eselect-opencl in order to avoid file collisions, unmasking the latter right now would effectively kill OpenCL support for Nvidia users. I have just opened a ticket regarding this: https://bugs.gentoo.org/717042 Perhaps fast-tracking stabilisation of the latest version of virtual/opencl might help too? 2. On systems with FEATURES=collision-protect set it will be necessary to manually clean up the libOpenCL.so symlinks created by eselect-opencl, before starting an upgrade - those symlinks are *not* owned by eselect-opencl as far as Portage is concerned so neither the standard weak-blocker resolution nor uninstalling this package prior to the upgrade prevent file collisions. I will prepare a news item (attached to eselect-opencl) explaining this soon. Again, many thanks to everyone who has contributed to making this happen! -- Marecki signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH 3/3] dev-util/intel-ocl-sdk: require an ICD loader instead of running standalone
On 2020-04-08 16:28, Marek Szuba wrote: > using an OpenCL implementation which exclusively targets CPUs is of > limited use. Clarification on the above: I meant using an implementation of this sort *in standalone mode* i.e. set as THE OpenCL implementation by eselect-opencl. It has never been my intention to criticise the package itself, if anything I have found it quite useful while benchmarking first Beignet and then NEO - but *it* is rather more handy to use it via an ICD loader, e.g. in order to have OpenCL support for both Intel CPUs and Intel GPUs active at the same time. I have already updated the commit message on my end accordingly. -- MS signature.asc Description: OpenPGP digital signature
[gentoo-dev] [PATCH 3/3] dev-util/intel-ocl-sdk: require an ICD loader instead of running standalone
At least version 4.4.0.117 works fine with a loader, and in any case
using an OpenCL implementation which exclusively targets CPUs is of
limited use.
Pending maintainer approval, and letting the stable ebuild be.
Signed-off-by: Marek Szuba
---
dev-util/intel-ocl-sdk/intel-ocl-sdk-4.4.0.117-r1.ebuild | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/dev-util/intel-ocl-sdk/intel-ocl-sdk-4.4.0.117-r1.ebuild
b/dev-util/intel-ocl-sdk/intel-ocl-sdk-4.4.0.117-r1.ebuild
index df63eebf81f..afdbe2891d5 100644
--- a/dev-util/intel-ocl-sdk/intel-ocl-sdk-4.4.0.117-r1.ebuild
+++ b/dev-util/intel-ocl-sdk/intel-ocl-sdk-4.4.0.117-r1.ebuild
@@ -15,7 +15,7 @@ IUSE="android +system-tbb system-clang +system-boost"
KEYWORDS="-* ~amd64"
RESTRICT="bindist mirror"
-RDEPEND="app-eselect/eselect-opencl
+RDEPEND=">=virtual/opencl-3
sys-process/numactl
system-tbb? ( >=dev-cpp/tbb-4.2.20131118 )
system-clang? ( =sys-devel/clang-3.4* )
@@ -76,7 +76,3 @@ src_install() {
dosym "/opt/intel/opencl-1.2-${PV}/lib64/libOpenCL.so.1"
"${INTEL_VENDOR_DIR}/libOpenCL.so.1"
dosym "/opt/intel/opencl-1.2-${PV}/lib64/libOpenCL.so.1.2"
"${INTEL_VENDOR_DIR}/libOpenCL.so.1.2"
}
-
-pkg_postinst() {
- eselect opencl set --use-old intel
-}
--
2.24.1
[gentoo-dev] [PATCH 1/3] dev-libs/rocm-opencl-runtime: do not force use of specific ICD loader
Pending maintainer's approval.
Signed-off-by: Marek Szuba
---
dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild | 2 +-
dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild | 2 +-
dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild
b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild
index d965949c197..390f4de5e07 100644
--- a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild
+++ b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.0.0.ebuild
@@ -25,7 +25,7 @@ SLOT="0/$(ver_cut 1-2)"
RDEPEND=">=dev-libs/rocr-runtime-${PV}
>=dev-libs/rocm-comgr-${PV}
>=dev-libs/rocm-device-libs-${PV}
- dev-libs/ocl-icd[khronos-headers]
+ >=virtual/opencl-3
media-libs/mesa"
DEPEND="${RDEPEND}
dev-lang/ocaml
diff --git a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild
b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild
index ec654ae4857..45a3fcd5324 100644
--- a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild
+++ b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.1.0.ebuild
@@ -25,7 +25,7 @@ SLOT="0/$(ver_cut 1-2)"
RDEPEND=">=dev-libs/rocr-runtime-${PV}
>=dev-libs/rocm-comgr-${PV}
>=dev-libs/rocm-device-libs-${PV}
- dev-libs/ocl-icd[khronos-headers]
+ >=virtual/opencl-3
media-libs/mesa"
DEPEND="${RDEPEND}
dev-lang/ocaml
diff --git a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild
b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild
index ec654ae4857..45a3fcd5324 100644
--- a/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild
+++ b/dev-libs/rocm-opencl-runtime/rocm-opencl-runtime-3.3.0.ebuild
@@ -25,7 +25,7 @@ SLOT="0/$(ver_cut 1-2)"
RDEPEND=">=dev-libs/rocr-runtime-${PV}
>=dev-libs/rocm-comgr-${PV}
>=dev-libs/rocm-device-libs-${PV}
- dev-libs/ocl-icd[khronos-headers]
+ >=virtual/opencl-3
media-libs/mesa"
DEPEND="${RDEPEND}
dev-lang/ocaml
--
2.24.1
[gentoo-dev] [PATCH 2/3] media-libs/mesa: do not force use of specific ICD loader
Pending maintainer approval, and letting the stable ebuild be.
Signed-off-by: Marek Szuba
---
media-libs/mesa/mesa-20.0.4.ebuild | 2 +-
media-libs/mesa/mesa-.ebuild | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/media-libs/mesa/mesa-20.0.4.ebuild
b/media-libs/mesa/mesa-20.0.4.ebuild
index 2e2725b40c9..18accf194ed 100644
--- a/media-libs/mesa/mesa-20.0.4.ebuild
+++ b/media-libs/mesa/mesa-20.0.4.ebuild
@@ -98,7 +98,7 @@ RDEPEND="
)
lm-sensors? ( sys-apps/lm-sensors:=[${MULTILIB_USEDEP}] )
opencl? (
-
dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]
+ >=virtual/opencl-3[${MULTILIB_USEDEP}]
dev-libs/libclc
virtual/libelf:0=[${MULTILIB_USEDEP}]
)
diff --git a/media-libs/mesa/mesa-.ebuild b/media-libs/mesa/mesa-.ebuild
index 91f99eee5b6..1b76d10ee80 100644
--- a/media-libs/mesa/mesa-.ebuild
+++ b/media-libs/mesa/mesa-.ebuild
@@ -98,7 +98,7 @@ RDEPEND="
)
lm-sensors? ( sys-apps/lm-sensors:=[${MULTILIB_USEDEP}] )
opencl? (
-
dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]
+ >=virtual/opencl-3[${MULTILIB_USEDEP}]
dev-libs/libclc
virtual/libelf:0=[${MULTILIB_USEDEP}]
)
--
2.24.1
[gentoo-dev] [PATCH] Migrate (non-Nvidia) OpenCL providers to virtual/opencl-3
Now that we have got two OpenCL ICD loaders in the tree, that starting with version 3, virtual/opencl will only pull an ICD loader rather than any specific implementation, and that we are in the process of following the footsteps of OpenGL in migrating away from using eselect to switch between OpenCL implementations in favour of always going through a loader, update implementations accordingly. Specifically: depend on >=virtual/opencl-3 rather than on any specific ICD loader, and make sure even implementations which previously ran standalone use one. Note that while the same should be done for x11-drivers/nvidia-drivers, all the ebuilds there are marked stable so they will have to be handled with more care. Maintainers whose sign-off is needed: candrews for ROCm, zerochaos for intel-ocl-sdk, the X11 project for Mesa.
[gentoo-dev] [PATCH] virtual/opencl: new version
One, instead of pulling in various OpenCL runtimes, only depend on
an OpenCL ICD loader (dev-libs/ocl-icd, with dev-libs/opencl-icd-loader
to be added later) in order to provide hardware-independent header
files and libraries for OpenCL-aware software to build against.
Actual runtimes are now simply suggested to the user via a postinst
message / README.gentoo file.
Two, do not depend on eselect-opencl either - both ICD loaders pull in
their own OpenCL headers so there is no need to depend on the legacy
headers provided by this package, and for being able to switch to a
specific loader it is enough for loaders themselves to depend on this.
Signed-off-by: Marek Szuba
---
virtual/opencl/files/README.gentoo | 18 ++
virtual/opencl/opencl-3.ebuild | 25 +
2 files changed, 43 insertions(+)
create mode 100644 virtual/opencl/files/README.gentoo
create mode 100644 virtual/opencl/opencl-3.ebuild
diff --git a/virtual/opencl/files/README.gentoo
b/virtual/opencl/files/README.gentoo
new file mode 100644
index 000..aa2dc0ef519
--- /dev/null
+++ b/virtual/opencl/files/README.gentoo
@@ -0,0 +1,18 @@
+In order to take advantage of OpenCL you will need a runtime for your hardware.
+Currently included in Gentoo are:
+
+ * open:
+- dev-libs/intel-neo - integrated Intel GPUs from Broadwell onwards.
64-bit only;
+- dev-libs/rocm-opencl-runtime - AMD GPUs supported by the amdgpu kernel
driver.
+ Image support still requires a proprietary extension [1]. 64-bit only;
+- media-libs/mesa[opencl] - some older AMD GPUs; see [2]. 32-bit support;
+
+ * proprietary:
+- dev-libs/amdgpu-pro-opencl - AMD Polaris GPUs. 32-bit support;
+- dev-util/intel-ocl-sdk - Intel CPUs (*not* GPUs). 64-bit only;
+- x11-drivers/nvidia-drivers[uvm] - Nvidia GPUs; specific package versions
+ required for older devices [3]. 32-bit support.
+
+ [1] dev-libs/hsa-ext-rocr
+ [2] https://dri.freedesktop.org/wiki/GalliumCompute/
+ [3] https://www.nvidia.com/en-us/drivers/unix/legacy-gpu/
diff --git a/virtual/opencl/opencl-3.ebuild b/virtual/opencl/opencl-3.ebuild
new file mode 100644
index 000..6268723a166
--- /dev/null
+++ b/virtual/opencl/opencl-3.ebuild
@@ -0,0 +1,25 @@
+# Copyright 1999-2020 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=7
+
+inherit multilib-build readme.gentoo-r1
+
+DESCRIPTION="Virtual for OpenCL API"
+SLOT="0"
+KEYWORDS="~amd64 ~x86"
+
+# Will add dev-libs/opencl-icd-loader here as an alternative once all potential
+# file collisions with eselect-opencl have been resolved
+RDEPEND="dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]"
+
+# so that src_install() doesn't fail on missing directory
+S="${WORKDIR}"
+
+src_install() {
+ readme.gentoo_create_doc
+}
+
+pkg_postinst() {
+ readme.gentoo_print_elog
+}
--
2.24.1
[gentoo-dev] [PATCH v2] Refactor virtual/opencl to provide the API, not an implementation
Changes since v1: * bump EAPI to 7 * use readme.gentoo for the postinst message * do not depend on app-eselect/eselect-opencl * make note in the comments about dev-libs/opencl-icd-loader to explain why we need a virtual in the first place
Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl
On 2020-04-06 06:27, Michał Górny wrote: > While at it, is there any chance to rewrite eselect-opencl so that it > stops writing into /usr and uses environment approach like eselect- > opengl does? I think I'd rather just nuke eselect-opencl altogether and force the use of an ICD loader for all implementations. Looks like it will be easier than Matt and I thought too, touch wood: - as previously mentioned, most of the runtimes currently in the tree actually REQUIRE using an ICD loader. Of the remaining two, I know for a fact at least the latest version of intel-ocl-sdk works fine via a loader so the only one that remains to be verified is x11-drivers/nvidia-drivers[uvm]; - likewise, I have confirmed that with the possible exception of x11-drivers/nvidia-drivers[uvm], none of the presently available runtimes install their own header files that would have to be symlinked into place by eselect-opencl. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: Rethinking virtual/opencl and eselect-opencl
On 2020-04-02 15:31, Marek Szuba wrote: > 3. Test if downstream applications are happy with the new unified OpenCL > headers required by the Khronos Group ICD loader and if they are, add > dev-libs/opencl-icd-loader to virtual/opencl as an alternative to ocl-icd; Quick update on this: today I have attempted to rebuild and test various OpenCL-dependent packages using the unified headers and dev-libs/opencl-icd-loader. The good news is, they have all been perfectly happy with them. The bad news is, I actually had to manually symlink all contents /usr/lib/OpenCL/vendors/opencl-icd-loader/include/CL/ into /usr/include/CL/ for this to work because eselect-opencl contains a hard-coded list of expected vendor header files. In other words, it will be necessary to either teach eselect-opencl how to handle the unified headers or make it possible for it to let the contents of /usr/include/CL be. Personally I am leaning towards the latter - it doesn't even handle legacy headers that well (it installs several versions into /usr/lib/OpenCL/global but in the end offers no way of switching between them), and in any case even its description suggests its job is to switch between implementations rather than handle global headers. -- MS signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] virtual/opencl: new version
On 2020-04-05 06:44, Michał Górny wrote:
>> +EAPI=6
> Is there really a good reason to use an old EAPI here?
None other than me having assumed that there must have been an important
reason why such a simple ebuild had not been bumped to EAPI 7 yet. Will
change this in the next iteration.
>> +RDEPEND="app-eselect/eselect-opencl
>> +dev-libs/ocl-icd[khronos-headers,${MULTILIB_USEDEP}]"
>
> Wouldn't it make sense to remove the virtual and just have stuff depend
> on that instead?
It would if there only were only one ICD loader in the tree - but there
are two, this one and dev-libs/opencl-icd-loader. Overall it seems the
latter might be preferable in the long run (official Khronos Group
loader, much smaller output library, supports the new unified headers,
the last ocl-icd release came out in November 2017 and there has been
minimal repo activity since then) but with it having only been
officially released in mid-March and with me having only just added it
to Gentoo, I feel I'd rather test it for a while before listing it as an
alternative in the virtual.
Moreover, for the time being we still need eselect-opencl here even if
we are no longer to use to switch between implementations because
somewhat surprisingly (to me anyway), the package in questions installs
OpenCL header files too.
> This looks like README.gentoo material.
Will do.
--
MS
signature.asc
Description: OpenPGP digital signature
